Файл: Практическое задание №1 Создание диаграмм вариантов использования.pdf
Добавлен: 15.11.2018
Просмотров: 4031
Скачиваний: 58
Практикум по
объектно-ориентированному
моделированию с помощью UML
Практическое задание №1
6
Вариант использования (прецедент, use case) — описание множества
последовательности действий (включая варианты), выполняемых системой для
того, чтобы актер мог получить определенный результат.
Каждый вариант использования должен быть независимым в том смысле,
что если он всегда выполняется совместно с другим вариантом использования,
то, скорее всего, это один прецедент, а не два, либо они связаны отношением
включения или расширения, о чем речь пойдет позже. Как следует из
определения, прецедент (или вариант использования) должен обладать
результирующей ценностью для актера, актер должен получить некоторый
результат исполнения прецедента. Скорее всего, после исполнения прецедента в
системе произойдут некоторые изменения: появятся новые данные, изменится
поведение. Каждый вариант использования должен исполняться от начала до
конца.
Прецедент описывает, что делает система, но никак не уточняет, как она
это делает. Заметим, что диаграмма прецедентов не отображает
последовательность, в которой будут выполняться варианты использования. На
диаграмме прецедент изображается в виде эллипса.
Имя прецедента может состоять из нескольких слов и знаков препинания
(за исключением двоеточия), как правило, имя выбирают в виде словосочетания
или глагольного выражения (рисунок 3.2).
Рисунок 3.2 – Варианты использования (прецеденты)
Одним из наиболее важных (и дорогостоящих) этапов проектирования
информационных систем является этап определения требований к системе. Если
требования заказчика информационной системы разработчиками будут
определены не корректно, то в итоге заказчик может получить совсем не ту
систему, которую он ожидал.
Моделирование прецедентов и актеров помогает нам лучше понять
требования, предъявляемые к системе, и согласовать их с заказчиком с помощью
демонстрации и обсуждения диаграммы прецедентов. Прецеденты и актеры –
это отражение требований к системе, они показывают, кто и для чего будет
использовать будущую систему.
Практикум по
объектно-ориентированному
моделированию с помощью UML
Практическое задание №1
7
Разрабатывая диаграммы Use Case, придерживаются определенных правил:
1. Не моделируют связи между действующими лицами. По определению они
находятся вне сферы действия системы. Связи между ними не относятся к
ее компетенции.
2. Не соединяют стрелкой непосредственно два варианта использования
(кроме связей использования и расширения). Диаграмма описывает
только, какие варианты использования доступны системе, а не порядок их
выполнения.
3. Каждый вариант использования должен быть инициирован действующим
лицом. Всегда должна быть стрелка, начинающаяся на действующем лице
и заканчивающаяся на варианте использования (кроме связей
использования и расширения).
4. Не рисуют стрелки от одного варианта к другому для изображения потока
информации.
5. Предполагается, что БД располагается на более низком уровне (слое),
находящемся под диаграммой. С помощью одного варианта использования
можно вводить данные в базу, а получать их – с помощью другого.
Пример. Определим актеров и прецеденты системы заказов магазина
«Style». Напомним, что покупатель делает заказ, складывая товары в корзину.
Возможна только одна форма оплаты: банковской картой по интернету,
невозможно оформление заказа без оплаты. Заказ имеет статус: оплачен,
передан на комплектацию, собран, получен. Статус заказа изменяется
автоматически либо сотрудником магазина. Покупатель может узнать статус
своего заказа по уникальному номеру заказа.
Система не занимается поставками товаров в магазин. Этим занимается
другая система, назовем ее Cклад.
Таким образом, с нашей системой взаимодействуют покупатель,
сотрудники магазина и внешняя система Склад. С нашей системой
взаимодействуют сотрудник отдела продаж, который проверяет оплату заказа и
отправляет его на комплектацию, и кладовщик, который собирает заказ и выдает
его покупателю. С точки зрения бизнеса – это две разных должности,
выполняющих разные функции, но с точки зрения системы они играют одну
роль сотрудника, изменяющего статус заказа покупателя с использованием
программного обеспечения моделируемой системы. В этом смысле для системы
нет разницы между сотрудником отдела продаж и кладовщиком. Выбирая
Практикум по
объектно-ориентированному
моделированию с помощью UML
Практическое задание №1
8
действующих лиц, нужно помнить о том, что мы должны отразить их роль, а не
должность. Введем обобщающее сотрудников действующее лицо – Сотрудник.
Другой пример: сотрудник магазина «Style» (положим, кладовщик) может
выступать в роли сотрудника и общаться с системой как сотрудник магазина, а
может выступать и в роли покупателя, сделав заказ в магазине. Не смотря на то,
что физически это один человек, он выступает в роли двух актеров: покупателя
и сотрудника. Итак, актеры системы заказов магазина «Style» будут следующие:
Покупатель, Сотрудник, Система Склад.
Покупатель использует нашу систему для того, чтобы заказать вещи, он
просматривает каталог, добавляет понравившиеся ему товары в корзину,
открывает корзину, удаляет из нее товары или изменяет их количество и,
наконец, может оформить свой заказ, при этом его оплатив. В конечном итоге
результат использования системы покупателем будет получен, если он
выполнил все эти действия от начала до конца. Поэтому не будем разделять
заказ товаров на несколько прецедентов, а выделим только один: Заказ
товаров.
Покупатель, сделав заказ в магазине «Style», может в дальнейшем
узнавать статус своего заказа, это тоже случай использования системы, назовем
его Получение информации о заказе.
Сотрудник должен изменять статус сделанного заказа, для него определим
прецедент Управление статусом заказа.
Система Склад должна получать информацию о сделанных заказах для
возможности управления наличием товаров на складе, для нее также должен
быть доступен прецедент Получение информации о заказе.
Итак, прецеденты системы заказов магазина «Style»: Заказ товаров,
Управление статусом заказа, Получение информации о заказе.
3.1.
Отношения между прецедентами и актерами
Связи и взаимоотношения, существующие между элементами модели, в
UML описываются с помощью отношений, изображаемых на диаграммах.
Отношение (relationship) — это семантическая связь между отдельными
элементами модели.
Между актерами и прецедентами диаграммы вариантов использования
могут существовать разного рода отношения, показывающие, что экземпляры
действующих лиц и вариантов использования взаимодействуют друг с другом.
Практикум по
объектно-ориентированному
моделированию с помощью UML
Практическое задание №1
9
Действующие лица могут взаимодействовать с несколькими прецедентами и
между собой, равно как и прецеденты могут быть связаны между собой особого
типа отношениями. В основном на диаграммах прецедентов используются
следующие типы отношений:
ассоциации (association relationship);
включения (include relationship);
расширения (extend relationship);
обобщения (generalization relationship).
Ассоциация – это структурное отношение, показывающее, что объект
неким образом связан с другим объектом.
Отношение этого типа используется не только на диаграммах прецедентов,
но и на других диаграммах. Если между элементами модели показано
отношение ассоциации, то это означает, что между ними существует
семантическая связь. Ассоциативное отношение может быть направленным. В
этом случае направление связи показывает, кто является инициатором. Если
отношение направленно от актера к прецеденту, то это означает, что актер
инициирует выполнение прецедента.
Пример. Покупатель в системе заказов магазина «Style» инициирует
выполнение прецедента Заказ товаров (рисунок 3.3).
Рисунок 3.3 – Отношение ассоциации между актером и прецедентом
Между прецедентами также возможны взаимоотношения, которые
описываются отношениями двух типов: включения и расширения (дополнения).
Включение (include) говорит о том, что исходный прецедент явным
образом включает в себя поведение целевого.
Другими словами, включение создается, когда один прецедент использует
другой. При этом исполнение базового прецедента невозможно без исполнения
используемого. Изображается включение в виде пунктирной стрелки с надписью
<<include>>, которая направлена от базового элемента к используемому.
Пример. В системе заказов магазина «Style» невозможен заказ товаров без
оплаты. На диаграмме прецедентов это можно отразить так, как это показано на
рисунке 3.4.
Практикум по
объектно-ориентированному
моделированию с помощью UML
Практическое задание №1
10
Рисунок 3.4 – Отношение включения между прецедентами
Расширение (extend) показывает, что целевой прецедент расширяет
поведение исходного прецедента.
Используемый прецедент выполняется не всегда вместе с базовым, а
только при выполнении дополнительных условий, таким образом, расширяя
функциональность базового элемента. Изображается расширение пунктирной
стрелкой с надписью <<extend>>, направленной от используемого варианта
использования к базовому.
Пример. При заказе товаров в системе заказов магазина «Style» покупатель
может изменить содержание корзины перед тем, как оформить заказ
окончательно, а может оставить корзину без изменений. Изменение корзины –
это опция, которую на диаграмме вариантов использования мы можем
изобразить с помощью расширения (рисунок 3.5).
Рисунок 3.5 – Отношение расширения между прецедентами
Обозначения отношений <<include>> и <<extend>> есть не что иное, как
обозначения стереотипов, которые широко используются в UML для создания
новых элементов модели путем расширения функциональности базовых
элементов.
Стереотип (Stereotype) – это механизм, позволяющий систематизировать
элементы модели с помощью категорий. С помощью стереотипов мы можем
создавать своего рода подтипы типов. Это позволяет UML иметь минимальный
набор элементов, которые могут быть дополнены при необходимости для
создания связующих базовых элементов в системе. В UML стереотип
обозначается именем, которое записывается в двойных угловых скобках: <<имя
стереотипа>>. В UML мы можем создавать собственные стереотипы на основе
уже имеющихся типов, но также существуют и стандартные, заранее
определенные стереотипы нотации UML. Так, отношение зависимости (о
котором мы еще будем говорить) расширяется для прецедентов и актеров с
помощью двух стереотипов <<include>> и <<extend>>.