UML-Варианты использования

государственный университет Кафедра программного обеспечения автоматизированных систем К У Р С

Л Е К Ц И Й по дисциплине ВВЕДЕНИЕ В ПРОГРАММНУЮ ИНЖЕНЕРИЮ для студентов направления 231000.62 «Программная инженерия»

данных
2. UML-диаграммы вариантов использования
2.1. Назначение и компоненты UseCase-диаграммы
2.2. Компонент диаграммы

"Актер"
2.3. Компонент диаграммы "Вариант использования"
2.4. Компонент диаграммы "Интерфейс"
2.5. Компонент диаграммы "Связь"("Отношение")
2.5.1. Отношение ассоциации
2.5.2. Отношение расширения
2.5.3. Отношение обобщения
2.5.4. Отношение включения
2.6. Примеры UseCase-диаграмм
2.7. Обозначения компонентов UseCase-диаграмм
2.8. Сценарии вариантов использования
2.9. Рекомендации и типичные ошибки при разработке UseCase-диаграмм
3. Выявление и анализ требований
Контрольные вопросы и задания

любого другого).
Требования к программной системе определяют, какие свойства и

характеристики она должна иметь для удовлетворения потребностей пользователей и других заинтересованных лиц.
Для выявления этих потребностей проводится анализ предметной области или моделирование бизнес-процессов, в результате которого разработчики должны:
научиться понимать язык, на котором говорят пользователи;
выявить цели деятельности пользователей;
определить набор задач, решаемых пользователями.
определить набор сущностей, с которыми приходится иметь дело при разработке системы;
выяснить свойства результатов, которые хотелось бы получить.
Анализом предметной области занимаются системные аналитики или бизнес-аналитики, которые передают полученные ими знания другим членам команды проекта, сформулировав их на более понятном разработчикам языке.
Для передачи этих знаний обычно служит некоторый набор моделей, оформляемых в виде графических схем и текстовых документов.
В данной лекции будут рассмотрены способы графического представления моделей бизнес-процессов предметной области, разработанные в рамках методологий структурного и объектно-ориентированного анализа.

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

схема предприятия (enterprise architecture framework) - схема Захмана.
В основе схемы Захмана лежит следующая идея: деятельность даже очень большой организации можно описать, используя ответы на простые вопросы:
Зачем ?
Кто ?
Что ?
Как ?
Где ?
Когда?
Ответы на эти шесть вопросов следует получить, анализируя деятельность предприятия на шести разных уровнях рассмотрения.
Результаты анализа представляются в матричной форме.

перечисленных выше вопросов):
Цели организации и базовые правила, по которым она

работает (Зачем ?).
Персонал, подразделения и другие элементы организационной структуры, связи между ними (Кто ?).
Сущности и данные, с которыми имеет дело организация (Что ?).
Функции и операции над данными, выполняемые организацией и различными ее подразделениями (Как?).
Географическое распределение элементов организации и связи между ее частями (Где ?).
Временные характеристики и ограничения на деятельность организации, значимые для ее деятельности события (Когда ?).

при бизнес-моделировании особенно важны три верхних уровня:
Самый крупный — уровень

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

рассматривались на одной из предыдущих лекций в качестве иллюстрации средств

визуального моделирования, разработанных в рамках методологии структурного анализа систем.
DFD-диаграммы использовались (и используются в настоящее время) для графического представления поведения сложных систем и деятельности крупных организаций.
DFD-диаграмма содержат 4 вида графических элементов:
процессы, представляющие собой любые трансформации данных в рамках описываемой системы;
хранилища данных;
сущности, внешние по отношению к системе;
потоки данных между элементами трех предыдущих видов.
Используются несколько систем обозначений для элементов DFD-диаграмм.
На следующих слайдах представлены две наиболее известные нотации: нотация Йордана-ДеМарко и нотация Гэйна-Сарсона, предложенные в 1979 году.

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

потоки данных внутри этого процесса. На рисунке показана детализация процесса №6 "Управление персоналом".

– в русскоязычных источниках называется иногда диаграммой прецедентов) – это

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

лица или актеры (actors) - любые сущности, взаимодействующие с системой

извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему или потребителем информации, генерируемой системой.
варианты использования (use case) - служат для описания сервисов, которые система предоставляет актерам. Каждый вариант использования определяет некоторый набор действий, выполняемых системой при взаимодействии с актером, причем детали реализации такого взаимодействия не раскрываются.
связи или отношения (relationships) - используются для обозначения отношений между компонентами модели.
интерфейсы (interface) - определяют совокупность операций, обеспечивающих выполнение вариантов использования.
примечания (notes) - произвольные текстовые комментарии разработчика, имеющие отношение к компонентам UseCase-диаграммы.

Актеры взаимодействует с вариантами использования посредством ассоциативных связей, передавая вариантам

использования запросы и получая от них соответствующие сервисы.
Кроме этого, с актерами могут быть связаны интерфейсы, которые определяют, каким образом другие элементы модели взаимодействуют с этими актерами.
Актер представляет определенную роль (группу) пользователей системы или внешних систем, взаимодействующих с проектируемой системой.
Два и более актера могут иметь общие свойства, т. е. одинаково взаимодействовать с одним и тем же множеством вариантов использования. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей. 
Реально с системой будут взаимодействовать отдельные субъекты или объекты - экземпляры актеров, каждый из которых может принадлежать к одной или нескольким ролям.
Актер – это именованный элемент модели, имя актера должно быть кратким и информативным.
Поскольку актер является внешней сущностью по отношению к моделируемой системе, его внутренняя структура в контексте данной диаграммы никак не определяется.
Актер представляется на диаграмме вершиной графа и изображается в виде схематичного человечка, помеченного соответствующим именем

служит для описания функционального поведения системы - сервисов, которые система

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

быть определены следующие атрибуты:
Имя, ясно говорящее о назначении варианта использования.
Описание

- несколько предложений, описывающих этот вариант использования.
Частота – показывает, как часто возникает данный вариант использования.
Предусловия - все условия запуска варианта использования.
Постусловия - все условия, которые должны быть выполнены после успешного выполнения варианта использования.
Основной сценарий работы, который используется в большинстве случаев.
Альтернативные сценарии, используемые иногда: для каждого альтернативного сценария указываются условия его запуска.
(Необязательно) Задействованные актеры.
(Необязательно) Расширяемые варианты использования.
(Необязательно) Включаемые варианты использования.
(Необязательно) Статус: "в разработке", "готов к проверке", "в процессе проверки", "подтвержден", "отвергнут".
(Необязательно) Допущения об окружении и ходе работы системы, использованные при разработке данного варианта.

выполнение сценариев вариантов использования.
Интерфейсы UseCase-диаграмм не могут содержать ни

атрибутов, ни состояний, ни направленных ассоциаций - они содержат только операции без указания особенностей их реализации.
Интерфейс представляется на UseCase-диаграмме вершиной графа и изображается в виде маленького круга, рядом с которым записывается имя интерфейса. В качестве имени может быть существительное или короткий текст, характеризующие соответствующую информацию или сервис: например, «датчик», «видеокамера», «запрос к базе данных», «форма ввода», «устройство подачи звукового сигнала».
Графический символ отдельного интерфейса может соединяться на диаграмме сплошной линией с тем вариантом использования, который его поддерживает (рисунок а). Сплошная линия в этом случае указывает на тот факт, что связанный с интерфейсом вариант использования должен реализовывать все операции, необходимые для данного интерфейса, а возможно и больше.
Если интерфейс соединен с вариантом использования пунктирной линией со стрелкой (рисунок б), то это означает, что вариант использования предназначен для спецификации только того сервиса, который необходим для реализации данного интерфейса.

между компонентами модели.
Связи представляются на UseCase-диаграмме дугами графа и изображаются

линиями со стрелками определенного вида, которые могут попарно соединять другие компоненты диаграммы (актеров, варианты использования и интерфейсы) в различных комбинациях.
Связь на UseCase-диаграмме может принадлежать к одному из четырех типов отношений, устанавливаемых между парой компонентов модели:
Отношение ассоциации (association relationship)
Отношение расширения (extend relationship)
Отношение обобщения (generalization relationship)
Отношение включения (include relationship).

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

к диаграммам вариантов использования ассоциативная связь специфицирует особенности взаимодействия актера и варианта использования.
Ассоциативная связь обозначается на диаграмме сплошной линией, соединяющей актера с вариантом использования, которая может иметь дополнительные условные обозначения:
Имя связи, указывающее на конкретную роль актера при его взаимодействии с вариантом использования
Кратность связи, которая определяет количество экземпляров актера и варианта использования, участвующих в связи.
Стрелка, всегда направленная от актера к варианту использования, что отображает тот факт, что сервис будет активизирован по запросу актера (так как стрелка всегда направлена однозначно, ее часто не показывают).

обозначениями связанных компонентов диаграммы, и характеризует общее количество экземпляров соответствующего

компонента, которые могут выступать в качестве элементов данной ассоциации.
Применительно к UseCase-диаграммам для указания кратности связи используются следующие обозначения:
Целое неотрицательное число: указывает на кратность, строго равную указанному числу. Например, кратность "1" для актера "Клиент банка" на предыдущем слайде означает, что конкретный кредит не может быть выдан нескольким или неопределенному числу клиентов банка.
Два целых неотрицательных числа, разделенные двумя точками: обозначает интервал целых чисел, следующих в последовательно возрастающем порядке. Если бы, например, на предыдущем слайде правый конец связи был помечен как "0..5", то это означало бы, что клиент банка не может оформить более пяти кредитов.
"N..*": обозначает диапазон числовых значений, ограниченный только слева значением N (символ "*" обозначает произвольное конечное целое неотрицательное число, значение которого неизвестно на момент задания соответствующего отношения ассоциации).
Единственный символ "*" является сокращением записи интервала "0..*", что означает "любое целое неотрицательное число".
Если кратность отношения ассоциации на диаграмме не указана, то по умолчанию принимается ее значение, равное 1.

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

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

– потомок", которая служит для указания того факта, что потомок

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

и является направленным бинарным отношением в том смысле, что некоторое

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

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

специальным стереотипом - ключевым словом "include"

оказывается недостаточно, она может быть дополнена текстовыми сценариями вариантов использования,

уточняющими детали функционального поведения системы.
При написании сценария важно понимать, что текст сценария не должен заменять собой UseCase-диаграмму – иначе будут потеряны все достоинства визуального представления модели.
Сценарии вариантов использования разрабатываются на базе шаблонов, один из которых, рекомендуемый для применения на начальных этапах концептуального моделирования, приведен ниже.
Шаблон состоит из 4-х разделов и представляется в табличной форме:
Главный раздел
Раздел «Типичный ход событий»
Раздел «Исключения»
Раздел «Примечания»

желательно, чтобы их количество не превышало 20.
Определить цели всех базовых

актеров по отношению к системе.
Определить "второстепенных" актеров модели, уточнить их частные цели по отношению к системе, установить отношения обобщения между базовыми (предками) и частными (потомками) актерами.
Определить базовые варианты использования – желательно, чтобы их общее количество не превышало 50.
Определить включаемые варианты использования (последовательности действий, представленные в нескольких базовых вариантах) и обозначить стереотипом "include" их связи с соответствующими базовыми вариантами.
Для каждого варианта использования:
обозначить на диаграмме актеров-участников, определить их интересы;
определить предусловия и постусловия использования варианта;
написать сценарий успешного выполнения ("типичный ход событий");
определить неуспешные ситуации – "исключения";
написать сценарии для всех "исключений".
Для каждого "исключения" предусмотреть расширяющий вариант использования и обозначить стереотипом "extend" его связь с соответствующим базовым вариантом.
Проверить диаграмму на отсутствие дублирования актеров и вариантов использования; исключить дубликаты.

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

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

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

и о функциях системы, реализуемых ею в процессе взаимодействия с пользователями.
На основе информации о функциях системы, представленной на UseCase-диаграмме, разработчик должен конкретизировать состав задач, которые система будет решать, и сформулировать требования к системе, которые представляют собой детализацию работы этих функций.
Правила работы с требованиями к ПО определяются следующими двумя стандартами IEEE:
IEEE 830-1998 Recommended Practice for Software Requirements Specifications (Рекомендуемые методы спецификации требований к ПО).
IEEE 1233-2002 Guide for Developing System Requirements Specifications (Руководство по разработке спецификаций требований к системам), описывающий правила построения требований для программно-аппаратных систем в целом..

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

бакалавров 231000.62 – "Программная инженерия" в 6-м и 7-м семестрах.

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

назначение каждого из них и приведите примеры их условных обозначений на диаграмме.
Перечислите основные и опциональные атрибуты варианта использования, указываемые в спецификации UseCase-диаграммы.
Определите понятие "интерфейс" как компонент UseCase-диаграммы.
Определите понятие "связь (отношение)" как компонент UseCase-диаграммы.
Рассмотрите примеры UseCase-диаграмм, приведенных на слайдах №26, №27 и №28:
Дополните обозначения отношений ассоциации параметрами "имя связи" и "кратность связи", обоснуйте значения параметра кратности.
Приведите примеры отношений включения и расширения между вариантами использования, показанных на этих диаграммах. В чем разница между этими типами отношений? К каким последствиям (при разработке сценариев вариантов использования и при их программной реализации) приведет факт установления этих типов отношений?
Приведите примеры отношений обобщения, показанных на этих диаграммах. Могут ли "потомки" не участвовать в связях, обозначенных на диаграмме для их "предков"? Могут ли "потомки" участвовать в связях, в которых не участвуют их "предки"?
Определите понятие "сценарий варианта использования", опишите структуру основных разделов типового шаблона разработки сценариев.
Разработайте сценарии вариантов использования, приведенных на слайде №28.
Опишите типовой алгоритм разработки UseCase-диаграммы.
Перечислите типичные ошибки, допускаемых разработчиками UseCase-диаграмм.
Нарисуйте UseCase-диаграмму системы доступа клиента банка к своим банковским счетам с целью снятия наличных денег или пополнения своих счетов через банкомат.
Нарисуйте UseCase-диаграмму системы доступа клиента банка к своему банковскому счету с целью перевода безналичных денежных средств со своего счета на другие счета через банкомат.