Диаграммы UML Диаграмма вариантов использования языка UML

Содержание

Слайд 2

Канонические диаграммы языка UML 1.х

Канонические диаграммы языка UML 1.х

Слайд 3

Канонические диаграммы языка UML 1.х

Канонические диаграммы языка UML 1.х

Слайд 4

Диаграммы UML 1.х Наиболее часто используются диаграммы, помеченные голубым цветом

Диаграммы UML 1.х

Наиболее часто используются диаграммы, помеченные голубым цветом

Слайд 5

Терминология – проблемы с переводом отдельных терминов Событие – это описание

Терминология – проблемы с переводом отдельных терминов

Событие – это описание группы

возможных вхождений.
История (трассировка) описывает уникальные объекты и вхождения, но модели имеют дело с паттернами, применимыми ко многим объектам и вхождениям (неточный перевод англ. occurrence).
Линия жизни представляет собой последовательность спецификации вхождений.

source state – исходное состояние (правильно -состояние источник)
opaque expression – непрозрачное выражение (правильно – неопределенное выражение)

Слайд 6

Классификация моделей в языке UML Структурные модели (structured models) – модели,

Классификация моделей в языке UML

Структурные модели (structured models) – модели, предназначенные

для описания статической структуры сущностей или элементов некоторой системы, включая их классы, интерфейсы, атрибуты и отношения.
Модели поведения (behavioral models) – модели, предназначенные для описания процесса функционирования элементов системы, включая их методы и взаимодействие между ними, а также процесс изменения состояний отдельных элементов и системы в целом.
Слайд 7

Канонические диаграммы языка UML 2.х Новые типы диаграмм: Composite structure, Interaction

Канонические диаграммы языка UML 2.х

Новые типы диаграмм: Composite structure, Interaction overview,

Timing
Упрощение Cooperation diagram и переименование в Communication diagram
Слайд 8

Канонические диаграммы языка UML 2.х

Канонические диаграммы языка UML 2.х

Слайд 9

Канонические диаграммы языка UML 2.х

Канонические диаграммы языка UML 2.х

Слайд 10

Взаимосвязь представлений сложной системы

Взаимосвязь представлений сложной системы

Слайд 11

Рекомендации по изображению диаграмм в нотации языка UML Количество диаграмм различных

Рекомендации по изображению диаграмм в нотации языка UML

Количество диаграмм различных типов

для модели конкретного приложения не является строго фиксированным
Любая из моделей системы должна содержать только те элементы, которые определены в соответствующей версии языка UML
Каждая диаграмма в нотации языка UML 2.х имеет область содержания для изображения графических узлов и путей между ними, которые представляют собой собственно элементы модели в нотации UML 2.х
Фрейм в нотации UML 2.х используется в тех случаях, когда отдельные элементы диаграммы имеют графическую границу с другими элементами диаграммы
Слайд 12

Изображение диаграмм языка UML 2 в виде фрейма Заголовок диаграммы является

Изображение диаграмм языка UML 2 в виде фрейма

Заголовок диаграммы является строкой

текста, записанной в прямоугольнике с обрезанным углом в верхнем левом углу фрейма и имеющей следующий синтаксис:
[<тип диаграммы>]<имя>[<параметры>]
Слайд 13

Теги заголовков и их сокращения для диаграмм UML 2.х activity (для

Теги заголовков и их сокращения для диаграмм UML 2.х

activity (для фреймов

диаграммы деятельности)
class (для фреймов диаграммы классов)
component (для фреймов диаграммы компонентов)
interaction (для фреймов диаграмм взаимодействия)
package (для фреймов диаграммы пакетов)
state machine (для фреймов диаграммы конечного
автомата)
use case (для фреймов диаграммы вариантов использования)
Слайд 14

Механизмы расширения языка UML

Механизмы расширения языка UML

Слайд 15

Механизмы расширения языка UML Стереотип (stereotype) — новый тип элемента модели,

Механизмы расширения языка UML

Стереотип (stereotype) — новый тип элемента модели, который

расширяет семантику базового типа метамодели языка UML
Помеченное значение (tagged value) — явное определение некоторого свойства объекта как пары "имя = значение"
Ограничение (constraint) — некоторое логическое условие, ограничивающее семантику выбранного элемента модели
Слайд 16

Стереотипы в языке UML Стереотипы предназначены для расширения семантики отдельных элементов

Стереотипы в языке UML

Стереотипы предназначены для расширения семантики отдельных элементов

языка UML, но не структуры уже описанных типов или классов
Некоторые стереотипы предопределены в языке UML, другие могут быть определены разработчиками
Текстовые Стереотипы — ключевые слова языка UML
Примеры: «entity», «control», «boundary»
Графические Стереотипы — описываются в профилях языка UML и поддерживаются некоторыми CASE-средствами
Слайд 17

Использование стереотипов В форме текста, заключенного в двойные угловые кавычки и

Использование стереотипов

В форме текста, заключенного в двойные угловые кавычки и размещенного

выше или перед именем элемента модели
Первая буква текста имени стереотипа не должна быть заглавной буквой.
Если применяются несколько стереотипов, то имена применяемых стереотипов изображаются в форме разделенного запятыми списка с парой кавычек.
В форме графической пиктограммы, которая заменяет текст имени соответствующего стереотипа
В форме прямоугольника класса с уменьшенной пиктограммой стереотипа внутри этого прямоугольника, расположенного, как правило, в верхнем правом углу
Слайд 18

Графические стереотипы компонентов в IBM Rational Rose Обычный компонент Тело пакета

Графические стереотипы компонентов в IBM Rational Rose

Обычный компонент

Тело пакета (файл с

текстом программы в С++ с расширением «.cpp», в Java – «.java»)

База данных

Спецификация пакета (заголовочный файл в С++ с расширением «.h»)

Слайд 19

Ограничения в языке UML Спецификация UML 2: Only binary associations can

Ограничения в языке UML

Спецификация UML 2: Only binary associations can be

aggregations
self.memberEnd->exists(aggregation <> Aggregation::none) implies self.memberEnd->size() = 2

Некоторые ограничения предопределены в языке UML, другие могут быть специфицированы самим разработчиком
Для корректной записи ограничений предназначен специальный язык — язык объектных ограничений (Object Constraint Language - OCL)

Слайд 20

Помеченные значения в языке UML В помеченном значении само имя называют

Помеченные значения в языке UML

В помеченном значении само имя называют

тегом (tag). Отдельные теги предопределены в языке UML, другие могут быть определены пользователем
Определяющим символом помеченного значения является знак равенства, который отделяет тег от его значения
Слайд 21

Диаграмма вариантов использования (use case diagram)

Диаграмма вариантов использования (use case diagram)

Слайд 22

Диаграмма вариантов использования (UC) Диаграммы вариантов использования применяют для моделирования статического

Диаграмма вариантов использования (UC)

Диаграммы вариантов использования применяют для моделирования статического вида

системы с точки зрения вариантов использования. Этот вид охватывает поведение системы, т.е. видимые извне сервисы, предоставляемые системой в контексте ее окружения
Конце́пция (от лат. conceptio — понимание, система) — определённый способ понимания — понимание, система) — определённый способ понимания, трактовки каких-либо явлений, основная точка зрения, руководящая идея — понимание, система) — определённый способ понимания, трактовки каких-либо явлений, основная точка зрения, руководящая идея для их освещения; система взглядов на явления в мире, в природе, в обществе; ведущий замысел, конструктивный принцип — понимание, система) — определённый способ понимания, трактовки каких-либо явлений, основная точка зрения, руководящая идея для их освещения; система взглядов на явления в мире, в природе, в обществе; ведущий замысел, конструктивный принцип в научной — понимание, система) — определённый способ понимания, трактовки каких-либо явлений, основная точка зрения, руководящая идея для их освещения; система взглядов на явления в мире, в природе, в обществе; ведущий замысел, конструктивный принцип в научной, художественной — понимание, система) — определённый способ понимания, трактовки каких-либо явлений, основная точка зрения, руководящая идея для их освещения; система взглядов на явления в мире, в природе, в обществе; ведущий замысел, конструктивный принцип в научной, художественной, технической — понимание, система) — определённый способ понимания, трактовки каких-либо явлений, основная точка зрения, руководящая идея для их освещения; система взглядов на явления в мире, в природе, в обществе; ведущий замысел, конструктивный принцип в научной, художественной, технической, политической — понимание, система) — определённый способ понимания, трактовки каких-либо явлений, основная точка зрения, руководящая идея для их освещения; система взглядов на явления в мире, в природе, в обществе; ведущий замысел, конструктивный принцип в научной, художественной, технической, политической и других видах деятельности; комплекс взглядов, связанных между собой и вытекающих один из другого, система путей решения выбранной задачи; способ понимания, различения и трактовки каких-либо явлений, порождающие присущие только для данного способа соображения и выводы. Концепция определяет стратегию — понимание, система) — определённый способ понимания, трактовки каких-либо явлений, основная точка зрения, руководящая идея для их освещения; система взглядов на явления в мире, в природе, в обществе; ведущий замысел, конструктивный принцип в научной, художественной, технической, политической и других видах деятельности; комплекс взглядов, связанных между собой и вытекающих один из другого, система путей решения выбранной задачи; способ понимания, различения и трактовки каких-либо явлений, порождающие присущие только для данного способа соображения и выводы. Концепция определяет стратегию действий. Различным концепциям соответствует свой терминологический аппарат.
Слайд 23

Диаграмма вариантов использования (use case diagram) диаграмма, на которой изображаются варианты

Диаграмма вариантов использования (use case diagram)

диаграмма, на которой изображаются варианты использования проектируемой

системы, заключенные в границу системы,
внешние актеры,
а также определенные отношения между актерами и вариантами использования
Слайд 24

Назначение диаграммы вариантов использования Определить общие границы функциональности проектируемой системы в

Назначение диаграммы вариантов использования

Определить общие границы функциональности проектируемой системы в контексте

моделируемой предметной области.
Специфицировать требования к функциональному поведению проектируемой системы в форме вариантов использования.
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями
Слайд 25

Проектируемая система и ее окружение Субъект (subject) – любой элемент модели, который обладает функциональным поведением

Проектируемая система и ее окружение

Субъект (subject) – любой элемент модели, который

обладает функциональным поведением
Слайд 26

Основные обозначения на диаграмме вариантов использования Ассоциация в контексте коммуникации Обобщение

Основные обозначения на диаграмме вариантов использования

Ассоциация в контексте коммуникации
Обобщение
Расширение
Включение,
Как 2 разновидности

отношения зависимости
Слайд 27

Вариант использования (use case) – представляет собой общую спецификацию совокупности выполняемых

Вариант использования (use case)

– представляет собой общую спецификацию совокупности выполняемых системой действий

с целью предоставления некоторого наблюдаемого результата, который имеет значение для одного или нескольких актеров
Отвечает на вопрос «Что должна выполнять система?», не отвечая на вопрос «Как она должна выполнять это?»
Имена – отглагольное существительное или глагол в неопределенной форме
Слайд 28

Актер (actor) – любая внешняя по отношению к проектируемой системе сущность,

Актер (actor)

– любая внешняя по отношению к проектируемой системе сущность, которая

взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач
Примеры актеров: кассир, клиент банка, банковский служащий, президент, продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, администратор гостиницы, сотовый телефон
Слайд 29

Вопросы для идентификации актеров в системе Какие организации или лица будут

Вопросы для идентификации актеров в системе

Какие организации или лица будут использовать

систему
Кто будет получать пользу от использования системы
Кто будет использовать информацию от системы
Будет ли использовать система внешние ресурсы
Может ли один пользователь играть несколько ролей при взаимодействии с системой
Могут ли различные пользователи играть одну роль при взаимодействии с системой
Будет ли система взаимодействовать с законодательными, исполнительными, налоговыми или другими органами
Слайд 30

Отношения на диаграмме вариантов использования

Отношения на диаграмме вариантов использования

Слайд 31

Отношения на диаграмме UC

Отношения на диаграмме UC

Слайд 32

Отношение ассоциации Ассоциация (association) является одним из фундаментальных понятий в языке

Отношение ассоциации

Ассоциация (association) является одним из фундаментальных понятий в языке

UML 2.х и может использоваться на различных канонических диаграммах при построении визуальных моделей
Применительно к диаграммам вариантов использования отношение ассоциации может служить только для обозначения взаимодействия актера с вариантом использования.
Слайд 33

Отношение включения Отношение зависимости (dependency) определяется как форма взаимосвязи между двумя

Отношение включения

Отношение зависимости (dependency) определяется как форма взаимосвязи между двумя

элементами модели, предназначенная для спецификации того обстоятельства, что изменение одного элемента модели приводит к изменению некоторого другого элемента
Отношение включения (include) специфицирует тот факт, что некоторый вариант использования содержит поведение, определенное в другом варианте использования

источник зависимости
(независимый элемент)

клиент зависимости
(зависимый элемент)

Слайд 34

Отношение расширения Отношение расширения (extend) определяет взаимосвязь одного варианта использования с

Отношение расширения

Отношение расширения (extend) определяет взаимосвязь одного варианта использования с

некоторым другим вариантом использования, функциональность или поведение которого задействуется первым не всегда, а только при выполнении некоторых ДОПОЛНИТЕЛЬНЫХ условий.

источник зависимости
(независимый элемент)

клиент зависимости
(зависимый элемент)

Слайд 35

Изображение отношения расширения с условием выполнения

Изображение отношения расширения с условием выполнения

Слайд 36

Отношение обобщения Отношение обобщения (generalization relationship) предназначено для спецификации того факта,

Отношение обобщения

Отношение обобщения (generalization relationship) предназначено для спецификации того факта,

что один элемент модели является специальным или частным случаем другого элемента модели

предок

потомок

Слайд 37

Что внутри UC? Событие Основной поток Альтернативный поток Исключительный поток Событие

Что внутри UC?

Событие

Основной поток

Альтернативный поток

Исключительный поток

Событие

Слайд 38

Диаграмма вариантов использования для модели банкомата

Диаграмма вариантов использования для модели банкомата

Слайд 39

Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине

Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине

Слайд 40

Типичные ошибки при разработке диаграмм вариантов использования Превращение диаграммы вариантов использования

Типичные ошибки при разработке диаграмм вариантов использования

Превращение диаграммы вариантов использования в

диаграмму деятельности за счет желания отразить все функциональные действия
Инициатором действий является разрабатываемая система
Спецификация атрибутов и операций классов до того, как сформулированы все варианты использования
Задание слишком кратких имен вариантам использования
Описание вариантов использования в терминологии, непонятной пользователям системы или заказчику
Отсутствие описаний альтернативных последовательностей действий
Тратится слишком много времени на решение вопросов о том, какие стереотипы и ассоциации использовать на диаграмме
Слайд 41

Контрольный опрос: Прокомментировать смысл графического изображения на рисунке Рис 1 Рис 2 Рис 3 Рис 4

Контрольный опрос: Прокомментировать смысл графического изображения на рисунке
Рис 1
Рис 2
Рис 3
Рис 4

Слайд 42

Формализация функциональных требований с помощью диаграммы ВИ Требование (requirement) – желательное

Формализация функциональных требований с помощью диаграммы ВИ

Требование (requirement) – желательное свойство,

характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации
Требование к ПО – некоторое свойство ПО, которым должна обладать система или ее компонент, чтобы удовлетворять условиям контракта, положениям стандартов, формальной спецификации или технической документации
Управление требованиями – это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и разработчиком по поводу меняющихся требований к системе
Слайд 43

Классификация требований – модель FURPS+ Functionality функциональные требования Usability (требования практичности)

Классификация требований – модель FURPS+

Functionality
функциональные требования
Usability (требования практичности)
Reliability

(требования надежности)
Performance (требования производительности)
Supportability (требования обслуживания и сопровождения)
Дополнительно + IEEE 610.12.1990
Проектные ограничения
Требования выполнения
Требования к GUI
Физические требования
Слайд 44

Functionality – функциональные требования Функциональные требования определяют действия, которые должна быть

Functionality – функциональные требования

Функциональные требования определяют действия, которые должна быть способна

выполнить система, без рассмотрения физических особенностей их реализации
Тем самым функциональные требования определяют внешнее поведение системы
Лучше всего они описываются в форме модели вариантов использования
Каждому функциональному требованию в этом случае будет соответствовать отдельный вариант использования
Слайд 45

Текстовые сценарии в UML Центральное место занимают функциональные требования, специфицирующие особенности

Текстовые сценарии в UML

Центральное место занимают функциональные требования, специфицирующие особенности

реализации отдельных бизнес-процессов моделируемой системы. Они служат исходной информацией для построения диаграмм ВИ. Однако графических средств языка UML на практике оказывается недостаточно для спецификации функциональных требований.
Одним из требований языка UML является самодостаточность диаграмм для представления информации о моделях проектируемых систем. Однако большинство разработчиков и экспертов согласны с тем, что изобразительных средств языка UML явно не хватает для того, чтобы учесть на диаграммах вариантов использования особенности функционального поведения сложной системы. С этой целью рекомендуется дополнять этот тип диаграмм текстовыми сценариями, которые уточняют или детализируют последовательность действий, совершаемых системой при выполнении ее вариантов использования.
Слайд 46

Спецификация ВИ с помощью текстовых сценариев Сценарий (scenario) – специально написанный

Спецификация ВИ с помощью текстовых сценариев

Сценарий (scenario) – специально написанный текст,

который описывает поведение моделируемой системы в форме последовательности выполняемых действий актеров и самой системы.
В контексте языка UML сценарий используется для дополнительной иллюстрации взаимодействия актеров и вариантов использования. Предлагаются различные способы представления или написания подобных сценариев.
Слайд 47

Шаблон для написания сценария отдельного варианта использования

Шаблон для написания сценария отдельного варианта использования

Слайд 48

Шаблон для написания сценария отдельного варианта использования

Шаблон для написания сценария отдельного варианта использования

Слайд 49

ГЛАВНЫЙ РАЗДЕЛ сценария выполнения варианта использования "Снятие наличных по кредитной карточке"

ГЛАВНЫЙ РАЗДЕЛ сценария выполнения варианта использования "Снятие наличных по кредитной карточке"


Слайд 50

Раздел ТИПИЧНЫЙ ход событий сценария выполнения варианта использования "Снятие наличных по кредитной карточке"

Раздел ТИПИЧНЫЙ ход событий сценария выполнения варианта использования "Снятие наличных по

кредитной карточке"
Слайд 51

Раздел ИСКЛЮЧЕНИЯ сценария выполнения варианта использования "Снятие наличных по кредитной карточке"

Раздел ИСКЛЮЧЕНИЯ сценария выполнения варианта использования "Снятие наличных по кредитной карточке"


Слайд 52

Последовательность разработки вариантов использования Определить главных (первичных) актеров и определить их

Последовательность разработки вариантов использования

Определить главных (первичных) актеров и определить их цели

по отношению к системе
Специфицировать все базовые (основные) варианты использования (они соответствуют высокоуровневым требованиям, предъявляемым к системе)
Выделить цели базовых ВИ, интересы актеров в контексте этих ВИ, предусловия и постусловия ВИ
Написать успешный сценарий выполнения базовых ВИ
Определить исключения (неуспех) в сценариях ВИ и написать сценарии для всех исключений (может быть изображено на отдельном UC)
Выделить ВИ исключений и изобразить их со стереотипом «extend» (может быть изображено на отдельном UC)
Выделить общие фрагменты функциональности ВИ (для нескольких UC) и изобразить их отдельными ВИ со стереотипом «include»
Слайд 53

Показатели качества для модели вариантов использования Все ли функциональные требования описываются

Показатели качества для модели вариантов использования

Все ли функциональные требования описываются вариантами

использования?
Не содержит ли модель вариантов использования ненужное поведение, которое отсутствует в требованиях?
Действительно ли в модели необходимы все выявленные связи включения, расширения и обобщения?
Правильно ли произведено деление модели на пакеты вариантов использования?
Стала ли модель в результате деления на пакеты проще и удобнее для восприятия и сопровождения?
Можно ли на основе модели вариантов использования составить четкое представление о функционировании системы в контексте ее пользователей?
Слайд 54

UML Profile for Business Modeling Бизнес вариант использования – элемент модели,

UML Profile for Business Modeling

Бизнес вариант использования – элемент модели, предназначенный

для представления отдельного бизнес процесса
Реализация бизнес варианта использования – описывает реализацию отдельного бизнес варианта использования в терминах кооперации объектов, экземпляров сотрудников и бизнес сущностей
Слайд 55

UML Profile for Business Modeling Бизнес актер – индивидуум, группа, организация,

UML Profile for Business Modeling

Бизнес актер – индивидуум, группа, организация, компания

или система, которые взаимодействуют с моделируемой системой (компанией), но не входят в нее. Примеры – клиенты, поставщики, партнеры.
Сотрудник – индивидуум, который действует внутри моделируемой системы (компании), взаимодействует с другими сотрудниками и манипулирует бизнес сущностями.
Организационная единица – пакет, в состав которого могут входить сотрудники, бизнес сущности, реализации бизнес вариантов использования, диаграммы языка UML и другие организационные единицы
Слайд 56

Диаграмма вариантов использования для системы продажи товаров по каталогу в UML Profile for Business Modeling

Диаграмма вариантов использования для системы продажи товаров по каталогу в UML

Profile for Business Modeling
Слайд 57

Примеры оформления сценариев

Примеры оформления сценариев

Слайд 58

Сценарий №1 выполнения ВИ "Снятие наличных по кредитной карточке" Главный раздел

Сценарий №1 выполнения ВИ "Снятие наличных по кредитной карточке"

Главный раздел
Вариант использования: Снятие

наличных по кредитной карточке
Актеры: Клиент Банкомата, Банк
Цель: Получение требуемой суммы наличными
Краткое описание: Клиент использует свою карточку для снятия наличных. Клиент запрашивает требуемую сумму. Банкомат обеспечивает доступ к счету клиента. Банкомат выдает клиенту наличные.
Тип: Базовый
Ссылки на другие варианты использования: Включает в себя ВИ:
Проверка ПИН-кода кредитной карточки
Слайд 59

Раздел Типичный ход событий 1. Клиент вставляет кредитную карточку в устройство

Раздел Типичный ход событий

1. Клиент вставляет кредитную карточку в устройство чтения

банкомата
2. Банкомат передает информацию о кредитной карточке в Банк
3. Банк проверяет информацию о кредитной карточке
Исключение №1: Кредитная карточка недействительна (утрачена)
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит PIN-код
6. Банкомат проверяет ПИН-код
Исключение №3: Введенный ПИН-код неверный
Исключение №4: Клиент ввел неверный ПИН-код 3 раза
7. Банкомат отображает опции меню
8. Клиент выбирает снятие наличных со своего счета
9. Банкомат предлагает ввести требуемую сумму
Слайд 60

Раздел Типичный ход событий 10. Клиент вводит требуемую сумму 11. Банкомат

Раздел Типичный ход событий

10. Клиент вводит требуемую сумму
11. Банкомат делает соответствующий

запрос в Банк
12. Банк проверяет введенную сумму
Исключение №5: Требуемая сумма превышает сумму на счете клиента
13. Банк изменяет состояние счета клиента
15. Клиент получает свою кредитную карточку
Исключение №6: Клиент выбрал печать чека
14. Банкомат предлагает клиенту забрать его кредитную карточку
16. Банкомат выдает наличные и предлагает забрать их клиенту
17. Клиент получает наличные
18. Банкомат отображает сообщение о готовности к дальнейшей работе
Слайд 61

Раздел Исключений Исключение №1. Кредитная карточка недействительна (утрачена) 4. Банкомат блокирует

Раздел Исключений

Исключение №1. Кредитная карточка недействительна (утрачена)
4. Банкомат блокирует кредитную карточку
18.

Банкомат отображает сообщение о готовности к дальнейшей работе
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает клиенту забрать его кредитную карточку
15. Клиент получает свою кредитную карточку
18. Банкомат отображает сообщение о готовности к дальнейшей работе
Исключение №3. Введенный ПИН-код неверный
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит ПИН-код
Слайд 62

Сценарий №2 "Получение справки о состоянии счета" Главный раздел Вариант использования:

Сценарий №2 "Получение справки о состоянии счета"

Главный раздел
Вариант использования: Получение справки о

состоянии счета
Актеры: Клиент Банкомата, Банк
Цель: Получение информации о балансе
Краткое описание: Клиент использует свою карточку для получения справки о состоянии счета. Банкомат обеспечивает доступ к счету клиента. Банкомат выдает клиенту справку в форме чека.
Тип: Базовый
Ссылки на другие варианты использования: Включает в себя ВИ:
Проверка ПИН-кода кредитной карточки
Слайд 63

Типичный ход событий 1. Клиент вставляет кредитную карточку в устройство чтения

Типичный ход событий

1. Клиент вставляет кредитную карточку в устройство чтения банкомата
2.

Банкомат передает информацию о кредитной карточке в Банк
3. Банк проверяет информацию о кредитной карточке
Исключение №1: Кредитная карточка недействительна (утрачена)
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит PIN-код
6. Банкомат проверяет ПИН-код
Исключение №3: Введенный ПИН-код неверный
Исключение №4: Клиент ввел неверный ПИН-код 3 раза
Слайд 64

Типичный ход событий 7. Банкомат отображает опции меню 8. Клиент выбирает

Типичный ход событий

7. Банкомат отображает опции меню
8. Клиент выбирает получение справки

о состоянии счета
9. Банкомат делает соответствующий запрос в Банк
10. Банкомат предлагает клиенту забрать его кредитную карточку
11. Клиент получает свою кредитную карточку
12. Банкомат выдает справку о состоянии счета и предлагает забрать ее клиенту
13. Клиент получает справку о состоянии своего счета
14. Банкомат отображает сообщение о готовности к дальнейшей работе
Слайд 65

Раздел Исключений Исключение №1. Кредитная карточка недействительна (утрачена) 4. Банкомат блокирует

Раздел Исключений

Исключение №1. Кредитная карточка недействительна (утрачена)
4. Банкомат блокирует кредитную карточку
14.

Банкомат отображает сообщение о готовности к дальнейшей работе
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает клиенту забрать его кредитную карточку
11. Клиент получает свою кредитную карточку
14. Банкомат отображает сообщение о готовности к дальнейшей работе
Исключение №3. Введенный ПИН-код неверный
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит ПИН-код
Исключение №4: Клиент вводит неверный ПИН-код 3 раза
4. Банкомат блокирует кредитную карточку
18. Банкомат отображает сообщение о готовности к дальнейшей работе
Слайд 66

Раздел Исключений Исключение №4: Клиент вводит неверный ПИН-код 3 раза 4.

Раздел Исключений

Исключение №4: Клиент вводит неверный ПИН-код 3 раза
4. Банкомат блокирует

кредитную карточку
18. Банкомат отображает сообщение о готовности к дальнейшей работе
Исключение №5. Требуемая сумма превышает сумму на счете клиента
9. Банкомат предлагает ввести новую сумму
10. Клиент вводит новую требуемую сумму
Исключение №6: Клиент выбрал печать чека
16.1. Банкомат предлагает клиенту забрать чек
Примечание. Клиент может отказаться от выполнения транзакции "Снятие наличных по кредитной карточке" при введении ПИН-кода, при выборе типа транзакции и при вводе суммы.
Слайд 67

Существует два вида принципиально разных диаграмм случаев использования - для ПО

Существует два вида принципиально разных диаграмм случаев использования - для ПО

и для всей системы в целом. Ведь, как правило, ПО является частью более крупной системы. Последняя может включать другое ПО, а также некоторый бизнес-процесс. Пользователями такой системы будут различные клиенты системы (бизнес-актеры), поскольку система создается именно для них. А сама система будет предоставлять для них бизнес-случаи использования. Пример диаграммы бизнес-случаев использования для системы обработки телефонных заявок

Примеры использования диаграммы UC

Слайд 68

Пример диаграммы бизнес-случаев использования для системы обработки телефонных заявок

Пример диаграммы бизнес-случаев использования для системы обработки телефонных заявок

Слайд 69

Диаграмма вариантов использования. Бизнес UC.

Диаграмма вариантов использования. Бизнес UC.

Слайд 70

Диаграмма UC. Моделирование контекста системы

Диаграмма UC. Моделирование контекста системы

- Предыдущая
Сравнение методологий разработки программ по степени формальности и отношению к каскадной или итеративной разработке
Следующая -
Символы христианства. Богослужебная утварь

Похожие презентации

Волшебство зимних праздников начинается у нас. Аксеновская сельская модельная библиотека
The foreign policy of Kazakhstan
Австралийский Союз. «Противоречие» между законами Союза и Штатов
Гигиена труда в сельскохозяйственном производстве
Технологический процесс изготовления детали шестерня полуоси
Характеристика отрасли связи, управление
Квадратный корень - презентация по Алгебре
Министерство спорта РФ
Михаил Александрович Врубель
История гендерной психологи
Презентация на тему "Мульт физминутка" - скачать презентации по Педагогике
Разработка программы для шифрования и дешифрования осмысленного текста без ключа
Портрет Натюрморт Пейзаж Описание
ЖИВОПИСЬ РОССИИ XVIII ВЕКА
Обучение и инструктаж по охране труда (ГУМ)
Вихревые расходомеры
Періодична науково-технічна література з теорії та практики фізичної культури
Основы web дизайна
Портфолио - презентация для начальной школы_
1 класс Браткова Е. С., учитель начальных классов МОБУСОШ № 7 п. Кирова
Предмет, назначение и функции философии
Баскетбол – техника игры. Краткая история баскетбола
Правовые основы охраны труда
Изменения в пенсионной системе Украины
Компрессорные машины
Анализ техники выполнения 7-метровых штрафных бросков
Социально-психологический портрет русской революционерки на примере Надежды Крупской
Устный счёт - презентация для начальной школы
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть