ОО Проектирование Лекция 2

1. 2. Диаграмма вариантов использования

2. 2.1. Основные понятия и назначение

Просмотреть список
накладных
2.1. Основные понятия и назначение
extend
extend
extend
Заведующий
складом
Добавить новую
накладную
Удалить
выбранную
накладную
extend
Выбрать
накладную
Изменить
выбранную
накладную
Диаграмма вариантов использования (англ. Use Case Diagram) в UML — диаграмма,
отражающая отношения между действующими лицами (англ. actor) и вариантами
использования (англ. use case), являющаяся составной частью модели прецедентов,
позволяющей описать систему на концептуальном уровне, выработать системные требования.
Основное назначение диаграммы — описание функциональности и поведения,
позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать
проектируемую или существующую систему.
При моделировании системы с помощью диаграммы прецедентов системный
аналитик стремится:
• чётко отделить систему от её окружения;
• определить действующих лиц (экторов), их взаимодействие с системой и ожидаемую
функциональность системы;
• определить в глоссарии (словаре) предметной области понятия, относящиеся к детальному
описанию функциональности системы (то есть прецедентов).

3. 2.2. Элементы диаграммы и нотационные соглашения

Могу описать основные
Могу описать что нужно
аспекты работы
мне,
для
руководства
Хочу
быть
Владычицей
предприятия
на
верхнем
Они в Вашем
предприятием.
Морской,
на–дне
Вуровне.
принципе
всежить
верно,
но,
Подробности
у
распоряжении.
Я
Подробности
опять
–
у
океана-моря
и чтобы
в некоторые
рисунки
я бы
конкретных
исполнителей
подготовил
конкретных
исполнителей
Золотая
была у
хотел
внестиРыбка
изменения
соответствующее
меня на посылках!
распоряжение
Лицо,
принимающее
решение
Давайте на всякий
случай проверим по
У меня появились
Какие
описанных
моим из
диаграммам,
вопросы
к Вашим
Чем
вами
занимается
Вы
Чем
мыфункций
можем
быть
правильно
ли я Ваше
Вас
подчиненным.
предприятие?
хотели
бы
для
вас
полезны?
понял?
автоматизировать?
Аналитик

4. 2.2. Элементы диаграммы и нотационные соглашения

Действующее лицо, актант, эктор, исполонитель (англ. actor) — абстрактное описание
сущности (роль), находящейся вне системы, подсистемы или класса, которая напрямую
взаимодействует с системой. Действующее лицо участвует в варианте использования или
множестве вариантов использования с целью воплощения определенных намерений. В широком
смысле действующее лицо – это внешняя сущность, взаимодействующая с с описываемой
системой или ее частью. Один физический объект может играть роль множества
действующих лиц.
Виды действующих лиц:
1. Физические личности, или пользователи системы. Они наиболее типичны и имеются
практически в каждой системе.
2. Другая система, внешняя по отношению к проектируемой.
3. Время.

5. 2.2. Элементы диаграммы и нотационные соглашения

Вариант использования (прецедент) — эллипс с надписью, обозначающий
выполняемые системой транзакции, приводящие к значащим для конкретного
действующего лица результатам. Надпись может быть именем или описанием (с
точки зрения действующего лица) того, «что» делает система (а не «как»). Имя
прецедента связано с непрерывным (атомарным) сценарием — конкретной
последовательностью действий (транзакцией), иллюстрирующей поведение
системы . В ходе сценария действующие лица обмениваются с системой
сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде
UML-комментария. С одним прецедентом может быть связано несколько различных
сценариев. При работе с вариантами использования важно помнить несколько
простых правил:
1. каждый прецедент относится как минимум к одному действующему лицу;
2. каждый прецедент имеет инициатора, в роли которого может выступать только
действующее лицо;
3. каждый прецедент является транзакцией и всегда приводит к логически
завершенному результату.

6. 2.2. Элементы диаграммы и нотационные соглашения

Отношениe (англ. relationship) – воплощение семантической связи между элементами модели.
Существует несколько видов отношений. К ним относятся ассоциация, обобщение,
метаотношение, поток и еще несколько других отношений, объединенных под общим названием
зависимость.
Отношение ассоциации (коммуникации) — в диаграммах вариантов использования
это связь между вариантом использования и действующим лицом. На языке UML ее
показывают с помощью обычной стрелки. Направление стрелки определяет кто
инициирует коммуникацию. В ряде случаев ассоциация может быть двунаправленной. В
этом случае направление указывать не обязательно. Связь ассоциации никогда не
возникает между двумя вариантами использования. Для отображения последовательности
действий используются другие диаграммы.

7. 2.2. Элементы диаграммы и нотационные соглашения

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

8. 2.2. Элементы диаграммы и нотационные соглашения

Зависимость (англ. dependency) – отношение зависимости обозначается
пунктирной стрелкой, на диаграммах использования этой связи соответствует
один из двух стереотипов, название которого при необходимости указывается
рядом со стрелкой
include
extend
1. Зависимость по типу включения (англ. include), позволяет основному
варианту использования автоматически включать в себя функциональность
другого. С помощью таких связей обычно моделируют многократно
используемую функциональность, встречающуюся в двух или более
вариантах использования. Направление стрелки от основного варианта
использования к вспомогательному.
2. Зависимость типа расширения (англ. extend) , позволяют основному
варианту использования при необходимости вызывать функциональные
возможности, предоставляемые вспомогательным
. Направление стрелки от вспомогательного варианта использования к
основному

9. 2.2. Элементы диаграммы и нотационные соглашения

С ее помощью он может
положить деньги на счет
include
include
Положить деньги на
счет
Пользователем
проектируемой ИС является
клиент банка
При этом ему будет
предложено
аутентифицироваться
Аутентифицировать
клиента
Клиент может снять деньги
со счета
Снять деньги
со счета
Клиент банка
Пользователем проектируемой
информационной системы является клиент
банка. С ее помощью он может
1. Положить деньги на счет.
2. Снять деньги со счета.
Выполняя любую из этих операции он в
обязательном порядке каждый раз должен
проходить процедуру аутентификации

10. 2.2. Элементы диаграммы и нотационные соглашения

Просматривая список
накладных завскладом
Просматривая список
может удалить выбранную
накладных завскладом
накладную
может изменить выбранную
накладную
Просмотреть список
накладных
extend
extend
extend
Заведующий
складом
Добавить новую
накладную
Пользователем
проектируемой ИС является
заведующий складом
Удалить
выбранную
накладную
extend
Изменить
выбранную
С
ее
помощью
он может
Просматривая
список
накладную
Выбрать
просматривать
список
накладных
завскладом
накладную
накладных
может добавить
новую
накладную
Пользователем проектируемой
информационной системы является
Просматривая
список С ее
заведующий
складом.
накладных
завскладом
помощью он
может просматривать
может
выбрать
накладную
список
накладных.
При этом он
из списка
имеет возможность
1. Добавить новую накладную.
2. Выбрать накладную из списка
3. Изменить выбранную
накладную
4. Удалить выбранную накладную

11. 2.2. Элементы диаграммы и нотационные соглашения

Обобщение (англ. generalization) – это связь между сущностью общего
характера (родителем) и более специфичной сущностью (потомком). Дочерняя
сущность наследует свойства родителя. На диаграммах вариантов
ипользования обобщения применяются для выделения общих черт у групп
похожих действующих лиц или вариантов использования

12. 2.2. Элементы диаграммы и нотационные соглашения

Редактировать
финансовый отчет
Редактировать
приказ
Бухгалтер с ее помощью
может Редактировать приказ
и Редактировать финансовый
отчет
Кроме этого Главный
Главный бухгалтер может
бухгалтер может Утвердить
Утвердить
делать
все то же, что и
финансовый
приказ и Утвердить
Бухгалтер
отчет
финансовый отчет
Утвердить
финансовый
отчет
Бухгалтер
Пользователями
проектируемой ИС являются
Бухгалтер и Главный
бухгалтер
Главный
бухгалтер
Пользователем проектируемой
информационной системы являются
Бухгалтер и Главный бухгалтер.
Бухгалтер с ее помощью может
Редактировать приказ и
Редактировать финансовый отчет
Главный бухгалтер наследует все
права на информационный ресурс,
которые имеет бухгалтер. Кроме
этого он может Утвердить приказ и
Утвердить финансовый отчет

13. 2.2. Элементы диаграммы и нотационные соглашения

Продать оружие
С ее помощью Продавец
Либо нарезное оружие
может Продать
оружие
Либоон
гладкоствольное
При этом
может продать
оружие
либо пневматику
Продать
нарезное
оружие
Продавец
оружейного
магазина
Продать
пневматику
Продать
гладкоствол
Пользователем
проектируемой ИС является
Продавец оружейного
магазина
Пользователем проектируемой
информационной системы является
Продавец оружейного магазина,
который с ее помощью может
выполнить операции по Продаже
оружия. При этом предусматриваются 3
возможных способа оформления
покупки:
1. Продажа пневматического оружия
2. Продажа огнестрельного
гладкоствольного оружия
3. Продажа огнестрельного нарезного
оружия

14. 2.3. Типовые ошибки

Не моделируйте связи коммуникации и зависимости между
действующими лицами. Действующие лица находятся вне сферы
действия системы и связи между ними не относятся к ее
компетенции.
Не соединяйте стрелкой ассоциации (коммуникации) два варианта
использования. Диаграммы данного типа описывают что должна
делать система, какие функции ей доступны, их иерархию. Для
отображения порядка выполнения вариантов использования
применяют диаграммы деятельностей.
Каждый вариант использования должен быть инициирован действующим лицом. Сама по себе никакая
функция системы не может инициироваться. Это означает, что всегда должна быть стрелка
коммуникации, начинающаяся на действующем лице и заканчивающаяся на варианте использования.
Границы системы четко не определены;
Варианты использования рассматриваются с точки зрения системы, а не действующих лиц;
Слишком много вариантов использования;
Многочисленные и запутанные связи между действующими лицами и вариантами использования;
Слишком объемные или нечеткие спецификации вариантов использования;
Варианты использования не соответствуют реальным функциям;
Пользователи плохо понимают варианты использования.

15. 2.4. Как искать варианты использования?

1. Любая документация заказчика.
2. Изучение документов концептуального характера
3. Учесть мнение каждого из заинтересованных лиц проекта.
Что он хочет делать с системой
Нужно ли ему с ее помощью работать с информацией
(вводить, получать, обновлять, удалять)?
Нужно ли ему будет информировать систему о каких-либо
внешних событиях?
Должна ли система информировать пользователя о какихлибо событиях?
4. Учесть события, на которые система должна отреагировать.
5. Учесть
события,
на
которые
должен
отреагировать
пользователь

16. Все ли найдено?

2.4. Как искать варианты использования?
Все ли найдено?
• Присутствует ли каждое функциональное требование, сформулированное
заказчиком хотя бы в одном варианте использования?
• Учли ли вы, как с системой будет работать каждое заинтересованное лицо?
• Какую информацию каждое заинтересованное лицо будет передавать
системе?
• Какую информацию каждое заинтересованное лицо будет получать от
системы?
• Учли ли вы проблемы, связанные с эксплуатацией?
• Учли ли вы все внешние системы?
• Какой информацией каждая внешняя система будет обмениваться с
проектируемой?

17. 2.5. Пример: «Проект ПО для банкомата»

Аутентифицировать клиента
АСУ банка
Выполнить
оплату
Перевести
деньги
Оплатить
покупку
Оплатить
штраф
Показать
балланс
Клиент
Сделать вклад Снять деньги
Подкрепить
наличность
Инкассировать
наличность
Обслужить
банкомат
Инкассатор

18. 2.6. Выводы

Диаграмма вариантов использования представляет
собой функциональную модель информационной
системы – иерархически упорядоченный список ее
функций. Она показывает ЧТО должна делать система.
Для моделирования поведения системы используются
диаграммы поведения, которые показывают, КАК
должна работать система при реализации того или
иного варианта использования или сценария,
включающего несколько вариантов