Создание диаграммы прецедентов

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

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

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

Действующие лица делятся на три основных типа – пользова­тели системы, другие системы, взаимодействующие с данной, и время. Время становится действующим лицом, если от него зави­сит запуск каких-либо событий в системе.

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

Рисунок 2.1 – Пример диаграммы вариантов использования

для банковской системы с банкоматами

 

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

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

На диаграмме вариантов использования показано взаимодей­ствие между вариантами использования и действующими лица­ми. Она отражает требования к системе с точки зрения пользова­теля. Таким образом, варианты использования – это функции, выполняемые системой, а действующие лица – это заинтересо­ванные лица (stakeholders) по отношению к создаваемой систе­ме. Такие диаграммы показывают, какие действующие лица ини­циируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использо­вания. Данная диаграмма, например, отражает взаимодействие между вариантами использования и действующими лицами бан­ковской системы. В сущности, диаграмма вариантов использо­вания иллюстрирует требования к системе. В нашем примере кли­ент банка инициирует большое количество различных вариан­тов использования: «Снять деньги со счета», «Перевести деньги», «Сделать вклад», «Просмотреть баланс» и «Изменить PIN-код». От варианта использования «Сделать платеж» стрелка указывает на «Кредитную систему». Действующими лицами могут быть внеш­ние системы, и потому в данном случае «Кредитная система» показана именно как действующее лицо - она внешняя для бан­ковской системы. Направленная от варианта использования к дей­ствующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действу­ющим лицом. В данном случае вариант использования «Сделать платеж» предоставляет «Кредитной системе» информацию об оп­лате по кредитной карточке.

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

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

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

- не моделируйте связи между действующими лицами. По оп­ределению действующие лица находятся вне сферы действия сис­темы. Это означает, что связи между ними также не относятся к ее компетенции;

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

- каждый вариант использования должен быть инициирован действующим лицом. Это означает, что всегда имеется стрелка, начинающаяся на действующем лице и заканчивающаяся на ва­рианте использования.

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

Варианты использования начинают описывать, что должна будет делать система. Для того чтобы фактически разработать систему, однако потребуются более конкретные детали. Эти де­тали описываются в документе, называемом «поток событий» (flowofevents). Целью потока событий является документирова­ние процесса обработки данных, реализуемого в рамках вариан­та использования. Этот документ подробно описывает, что бу­дут делать пользователи системы и что – сама система.

Хотя поток событий и описывается подробно, он также не должен зависеть от реализации. Цель – описать то, что будет де­лать система, а не как она будет делать это. Обычно поток собы­тий включает:

- краткое описание;

- предусловия (pre-conditions);

- основной поток событий;

- альтернативный поток событий;

- постусловия (post-conditions). Последовательно рассмотрим эти составные части.

Краткое описание. Каждый вариант использования должен иметь краткое опи­сание того, что он будет делать. Например, вариант использова­ния «Перевести деньги» может содержать следующее описание:

 

Вариант использования «Перевести деньги» позволяет клиен­ту или служащему банка переводить деньги с одного счета до вос­требования или сберегательного счета на другой.

 

Предусловия. Предусловия варианта использования – это такие условия, которые должны быть выполнены, прежде чем вариант исполь­зования начнет выполняться сам. Например, таким условием может быть выполнение другого варианта использования или наличие у пользователя прав доступа, требуемых для запуска это­го. Не у всех вариантов использования бывают предусловия.

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

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

- каким образом запускается вариант использования;

- различные пути выполнения варианта использования;

- нормальный, или основной, поток событий варианта ис­пользования;

- отклонения от основного потока событий (так называемые альтернативные потоки);

- потоки ошибок;

- каким образом завершается вариант использования.

Например, поток событий варианта использования «Снять деньги со счета» может выглядеть следующим образом:

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

а) банкомат выводит приветствие и предлагает клиенту ввести свой персональный PIN-код;

б) клиент вводит PIN-код;

в) банкомат подтверждает введенный код. Если код не подтверж­ден, выполняется альтернативный поток событий А1;

г) банкомат выводит список доступных действий:

1) сделать вклад;

2) снять деньги со счета;

3) перевести деньги.

д) клиент выбирает пункт «Снять деньги со счета»;

е) банкомат запрашивает, сколько денег надо снять;

ж) клиент вводит требуемую сумму;

з) банкомат определяет, имеется ли на счете достаточно денег. Если денег недостаточно, выполняется альтернативный поток А2. Если во время подтверждения суммы возникают ошибки, выполняется поток ошибок Е1;

и) банкомат вычитает требуемую сумму из счета клиента;

к) банкомат выдает клиенту требуемую сумму наличными;

л) банкомат возвращает клиенту его карточку;

м) банкомат печатает чек для клиента;

н) вариант использования завершается.

Альтернативный поток А1. Ввод неправильногоPIN-кода:

а) банкомат информирует клиента, что код введен неправильно;

б) банкомат возвращает клиенту его карточку;

в) вариант использования завершается.

Альтернативный вариант использования А2. Недостаточно денег

на счете:

а) банкомат информирует клиента, что денег на его счете недоста­точно;

б) банкомат возвращает клиенту его карточку;

в) вариант использования завершается.

Поток ошибок El. Ошибка в подтверждении запраши­ваемой суммы:

а) банкомат сообщает пользователю, что при подтверждении зап­рашиваемой суммы произошла ошибка, и дает ему номер телефона служ­бы поддержки клиентов банка;

б) банкомат заносит сведения об ошибке в журнал ошибок. Каждая запись содержит дату и время ошибки, имя клиента, номер его счета и код ошибки;

в) банкомат возвращает клиенту его карточку;

г) вариант использования завершается.

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

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

Такой пояснительный текст применительно к диаграммам вариантов исполь­зования получил специальное название текста-сценария или просто − сценария.

Сценарий (scenario)– специально написанный текст, описывающий поведение моделируемой системы в форме последова­тельности выполняемых действий актеров и самой системы.

 

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

Таблица 2.1 – Шаблон для написания сценария отдельного прецедента

Главный раздел	Раздел «Типичный ход событий»	Раздел «Исключения»	Раздел «Примечания»
Имя варианта использования Актеры Цель Краткое описание Тип Ссылки на другие варианты использования	Типичный ход собы­тий, приводящий к успешному выполнению данного варианта использования	Исключение № 1	Примечание № 1
Исключение № 2	Примечание № 2
...	...
Исключение № n	Примечание № n

 

Для удобства записи и чтения сценария часто используют модификацию дан­ного шаблона, располагая разделы последовательно сверху вниз. При этом написание сценариев модели начинают с базовых или основных вариантов использования, после чего рассматриваются сценарии второстепенных или включаемых вариантов использования.

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

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

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

Пример сценария для системы продажи товаров в интернет-магазине. Для иллюстрации рассмотренного материала дополним диаграмму вариантов использования для системы продажи товаров в интер­нет-магазине (рисунок 2.2) текстовым сценарием, написанным на основе предложенного шаблона (таблица 2.2).

Рисунок 2.2 – Диаграмма вариантов использования

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

 

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

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

 

Таблица 2.2 – Главный раздел сценария выполнения варианта использования«Просмотр списка товаров»

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

 

Поскольку для варианта использования «Просмотр списка товаров» отсутст­вуют включаемые варианты использования, ссылки на другие варианты ис­пользования также будут отсутствовать. В следующем разделе сценария (таблица 2.3) описывается последовательность действий, приводящая к успеш­ному выполнению рассматриваемого варианта использования. В качестве инициатора действий выступает актер «Посетитель интернет-магазина». Для удобства каждое действие помечается порядковым номером в последова­тельности.

 

Таблица 2.3 – Раздел типичного хода событий сценария выполнения вариантаиспользования «Просмотр списка товаров»

Действия актеров	Отклик системы
1. Посетитель загружает исходную стра­ницу интернет-магазина в браузер	2. Система отображает исходную стра­ницу интернет-магазина
3. Посетитель интернет-магазина вы­бирает категорию то­варов	4. Система отображает информацию о выбранной категории товаров
5. Посетитель интернет-магазина вы­бирает интересующий товар	6. Система отображает общую инфор­мацию о выбранном товаре
7. Посетитель интернет-магазина вы­бирает просмотр детальной инфор­мации об интересующем товаре	8. Система отображает детальную ин­формацию о выбранном товаре
9. Посетитель интернет-магазина мо­жет пожелать вернуться на исходную страницу интернет-магазина	10. Система отображает исходную стра­ницу интернет-магазина

Поскольку для рассматриваемого варианта использования отсутствуют рас­ширяющие варианты использования, секции исключений останутся пустыми.

Связи между вариантами использования и действующими ли­цами. В языке UML для вариантов использования и действующих лиц поддерживается несколько типов связей. Это связи комму­никации (communication), включения (include), расширения (extend) и обобщения (generalization).

Связь коммуникации–это связь между вариантом использо­вания и действующим лицом. На языке UML связи коммуника­ции показывают с помощью однонаправленной ассоциации (ли­нии со стрелкой). Направление стрелки позволяет понять, кто инициирует коммуникацию.

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

Связь расширенияприменяется при описании изменений в нор­мальном поведении системы. Она позволяет варианту использо­вания только при необходимости применять функциональные воз­можности другого.

На языке UML связи включения и расширения показывают в виде зависимостей с соответствующими стереотипами (рисунке 2.3).

Рисунок 2. 3 – Связи использования и расширения

 

Сформулируем следующие определения.

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

Отношение расширения (extend) – определяет взаимосвязь одного варианта использования с некоторым другим вариантом использования, функциональность или поведение которого задействуется первым не всегда, а только при выполнении некоторых дополнительных условий.

Стереотип (stereotype) - элемент модели, который расширяет се­мантику базового элемента метамодели языка UML.

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

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

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

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

Рисунок 2. 4 – Обобщение действующего лица

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

Внимание! Ни в коем случае не следует включать в текст первого и последующих пунктов пояснительной записки определения (что такое актер, что такое диаграмма вариантов использования и пр.).