Файл: Практическая работа по дисциплине Методы и средства проектирования информационных систем и технологий Унифицированный язык моделирования (uml). Диаграмма вариантов использования системы.pdf

1
Практическая работа по дисциплине «Методы и средства проектирования
информационных систем и технологий» Унифицированный язык моделирования (UML).
Диаграмма вариантов использования системы.
Унифицированный язык моделирования (UML) является языком диаграмм и обозначений для спецификации, визуализации и документирования проекта ИС . UML не является методом разработки. Он помогает описать некоторую идею и взаимодействовать с другими разработчиками системы. UML управляется Object Management Group (OMG) и является промышленным стандартом, описывающим модели программного обеспечения.
UML создан для применения в разработке объектно-ориентированного программного обеспечения. Элементы UML используются для создания диаграмм.
Задание. В соответствии с выбранной темой:
1. Разработать спецификации требований ИС для заказчика и разработчика. Пользовательские требования (свойства пользовательского интерфейса). Системные требования (функциональные и нефункциональные).
Примечание Выполнить, ознакомившись с лекциями по курсу
2. Создать диаграмму прецедентов.
Диаграммы прецедентов (вариантов использования) отображают действующих лиц (людей или пользователей системы), варианты использования (сценарии использования системы) и их взаимодействие.
Диаграмма прецедентов
В диаграмме прецедентов есть два основных понятия – исполнитель (актер – действующее лицо) и прецедент.
Исполнитель представляет один из двух аспектов.
• Роль, которую пользователь играет по отношению к системе.
• Сущность (например, другую систему или базу данных) за пределами системы.
Исполнитель изображается в виде фигурки человека с кратким описательным именем.
Покупатель Таможенная система Бухгалтер
Рис.1. Обозначение исполнителя в UML
Имя исполнителя не должно быть именем конкретной личности. Пользователь может быть исполнителем нескольких прецедентов.
Прецедент— это набор действий, совершаемых исполнителем в системе, для достижения определенной цели.
Прецедент должен описывать вариант использования системы без ориентации на определенное проектное решение или реализацию. Другими словами, прецедент описывает, что должна делать система, не определяя, как она это делает.
Прецедент обозначается эллипсом и кратким именем. На рис. 2 видно, что имя прецедента может находиться как внутри эллипса, так и под ним.

2
Рис. 2 Примеры прецедентов для Internet-магазина
Полный набор исполнителей в модели прецедентов должен отражать все объекты, взаимодействующие с моделируемой системой.
Полный набор прецедентов из этой модели должен обеспечивать покрытие всех функциональных требований, поставленных заказчиками.
Исполнители и прецеденты изображаются на диаграммах обычно следующим образом:

Исполнитель, инициирующий определенный прецедент, обычно изображается на диаграмме слева.

Прецеденты помещаются в центре.

Все остальные исполнители, задействованные в данных прецедентах, изображаются в правой части диаграммы.
Стрелки указывают на то, какие исполнители заняты в каких прецедентах.
На рис. 3 показано, как исполнители и прецеденты изображаются на диаграмме прецедентов UML.
Из рисунка также видно, что Исполнитель 1 занят во всех трех прецедентах. Исполнитель 3 активно участвует в Прецеденте 3, а Исполнитель 2 просто получает результаты Прецедента 2.
Рис 3 Диаграмма прецедентов
При работе с прецедентами следует помнить:
1. Каждый прецедент относится как минимум к одному исполнителю.
2. Каждый прецедент имеет инициатора.
3. Прецеденты могут взаимодействовать с другими прецедентами.
Здесь имеется в виду:
- включение - данный прецедент встраивается в другой прецедент,
- добавление – означает, что в определенной ситуации прецедент может быть расширен другим,
- обобщение – прецедент наследует свойства родительского прецедента.
На рис. показан пример такой диаграммы для банкомата (Automated Teller Machine, ATM).
На данной диаграмме человеческие фигурки обозначают действующих лиц, овалы – варианты использования, а линии и стрелки – различные связи между действующими лицами и
Печать отчета
Поиск по автору
Печать отчета
Прецедент 1
Прецедент 2
Прецедент 3
Исполнитель 1
Исполнитель 2
Исполнитель 3

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

4
Потоки событий
Одним из требований языка UML является самодостаточность диаграмм для представления информации о моделях проектируемых систем. Однако, как уже отмечалось выше, диаграммы вариантов использования описывают то, что делает система, без уточнения того, как она это делает.
Для реального описания системы потребуются более специфические данные, которые отражены в потоке событий. Потоки событий уточняют или детализируют последовательность действий, совершаемых системой при выполнении ее вариантов использования, а также описывают логику переходов через варианты использования.
Поток событий – это определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста.
Потоки событий – это текстовые описания пошагового выполнения прецедентов, они понятны не только разработчику, но и стороннему читателю. Их задача – еще больше детализировать описание функциональности системы до того, как разработчики приступят к написанию программного кода, и устранить возможное недопонимание требуемой функциональности, как можно больше сблизить представления разработчика о системе и заказчика.
Потоки событий бывают трех типов:

основной,

альтернативный,

поток ошибок.
Основной (главный) поток описывает наилучший сценарий либо наиболее используемый путь исполнения прецедента.
Альтернативный поток специфицирует отклонения от основного потока, которые не рассматриваются как ошибочные.
Поток ошибок рассматривается как отклонение от альтернативного или основного, которое порождает условия формирования ошибки.
ПРИМЕР
Вариант Использования «Перевести деньги» позволяет клиенту или служащему банка
переводить деньги с одного счета до востребования или сберегательного счета на другой.
Предусловия
Предусловия варианта использования – это такие условия, которые должны быть выполнены, прежде чем вариант использования начнет выполняться сам. Например, таким условием может быть выполнение другого варианта использования или наличие у пользователя прав доступа, требуемых для запуска этого. Не у всех вариантов использования бывают предварительные условия.
Ранее упоминалось, что диаграммы вариантов использования не должны отражать порядок их выполнения. С помощью предусловий, однако, можно документировать и такую информацию.
Например, предусловием одного варианта использования может быть то, что в это время должен выполняться другой.
Основной и альтернативный потоки событий
Конкретные детали вариантов использования описываются в основном и альтернативных потоках событий. Поток событий поэтапно описывает, что должно происходить во время выполнения заложенной в варианты использования функциональности. Поток событий уделяет внимание тому, что будет делать система, а не как она будет делать это, причем описывает все это с точки зрения пользователя. Основной и альтернативный потоки событий включают следующее описание:
– способ запуска варианта использования;
– различные пути выполнения варианта использования;
– нормальный, или основной, поток событий варианта использования;
– отклонения от основного потока событий (так называемые альтернативные потоки);
– потоки ошибок;
– способ завершения варианта использования.

5
Например, поток событий варианта использования «Снять деньги» может выглядеть следующим образом:
Основной поток
1. Вариант использования начинается, когда клиент вставляет свою карточку в АТМ.
2. АТМ выводит приветствие и предлагает клиенту ввести свой персональный идентификационный номер.
3. Клиент вводит номер.
4. АТМ подтверждает введённый номер. Если номер не подтвержден, выполняется альтернативный поток событий А1.
5. АТМ выводит список доступных действий:
– положить деньги на счет;
– снять деньги со счета;
– перевести деньги.
6. Клиент выбирает пункт «Снять деньги».
7. АТМ запрашивает, сколько денег надо снять.
8. Клиент вводит требуемую сумму.
9. АТМ определяет, имеется ли на счету достаточно денег. Если денег недостаточно, выполняется альтернативный поток А2. Если во время подтверждения суммы возникают ошибки, выполняется поток ошибок Е1.
10. АТМ вычитает требуемую сумму из счета клиента.
11. АТМ выдает клиенту требуемую сумму наличными.
12. АТМ возвращает клиенту его карточку.
13. АТМ печатает чек для клиента.
14. Вариант использования завершается.
Альтернативный поток А1. Ввод неправильного идентификационного
номера.
1. АТМ информирует клиента, что идентификационный номер введён неправильно.
2. АТМ возвращает клиенту его карточку.
3. Вариант использования завершается.
Альтернативный вариант использования А2. Недостаточно денег на счету.
1. АТМ информирует клиента, что денег на его счету недостаточно.
2. АТМ возвращает клиенту его карточку.
3. Вариант использования завершается.
Поток ошибок Е1. Ошибка в подтверждении запрашиваемой суммы.
1. АТМ сообщает пользователю, что при подтверждении запрашиваемой суммы произошла ошибка и дает ему номер телефона службы поддержки клиентов банка.
2. АТМ заносит сведения об ошибке в журнал ошибок. Каждая запись содержит дату и время ошибки, имя клиента, номер его счета и код ошибки.
3. АТМ возвращает клиенту его карточку.
4. Вариант использования завершается.
Пример. Определим актеров и прецеденты системы заказов магазина «Style».
Напомним, что покупатель делает заказ, складывая товары в корзину. Возможна только одна форма оплаты: банковской картой по интернету, невозможно оформление заказа без оплаты. Заказ имеет статус: оплачен, передан на комплектацию, собран, получен. Статус заказа изменяется автоматически либо сотрудником магазина. Покупатель может узнать статус своего заказа по уникальному номеру заказа.
Система не занимается поставками товаров в магазин. Этим занимается другая система, назовем ее
Cклад.
Покупатель использует нашу систему для того, чтобы заказать вещи, он просматривает каталог, добавляет понравившиеся ему товары в корзину, открывает корзину, удаляет из нее товары или изменяет их количество и, наконец, может оформить свой заказ, при этом его оплатив. В конечном итоге результат использования системы покупателем будет получен, если он выполнил все эти

6 действия от начала до конца. Поэтому не будем разделять заказ товаров на несколько прецедентов, а выделим только один: Заказ товаров.
Покупатель, сделав заказ в магазине «Style», может в дальнейшем узнавать статус своего заказа, это тоже случай использования системы, назовем его Получение информации о заказе.
Сотрудник должен изменять статус сделанного заказа, для него определим прецедент Управление статусом заказа.
Система Склад должна получать информацию о сделанных заказах для возможности управления наличием товаров на складе, для нее также должен быть доступен прецедент Получение информации о заказе.
В основном на диаграммах прецедентов используются следующие типы отношений:
ассоциации (association relationship);
включения (include relationship);
расширения (extend relationship);
обобщения (generalization relationship).
Ассоциация – это структурное отношение, показывающее, что объект неким образом связан с другим объектом.
Если отношение направленно от актера к прецеденту, то это означает, что актер инициирует выполнение прецедента.
Включение (include) говорит о том, что исходный прецедент явным образом включает в себя поведение целевого [2].
Пример. В системе заказов магазина «Style» невозможен заказ товаров без оплаты. На диаграмме прецедентов это можно отразить так, как это показано на рисунке 11.
Расширение (extend) показывает, что целевой прецедент расширяет поведение исходного.
Пример. При заказе товаров в системе заказов магазина «Style» покупатель может изменить содержание корзины перед тем, как оформить заказ окончательно, а может оставить корзину без изменений. Изменение корзины – это опция, которую на диаграмме вариантов использования мы можем изобразить с помощью расширения (рис. 12).
Обобщение (Generalization) – это отношение между общей сущностью и ее конкретным воплощением [2].
Пример. Для изменения статуса заказов в магазине «Style» с проектируемой системой будут работать сотрудник отдела продаж и кладовщик. На диаграмме мы можем показать с помощью отношения обобщения взаимосвязь между актером Сотрудник и актерами Сотрудник отдела продаж и Кладовщик (рис. 13).
Пример. Для системы заказов магазина «Style» мы определили актеров Покупатель, Сотрудник,
Система Склад и прецеденты Заказ товаров, Управление статусом заказа, Получение информации о заказе. Построим основную диаграмму прецедентов (рис. 18).