Лекция
Привет, сегодня поговорим про диаграмма вариантов использования, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое диаграмма вариантов использования, use case diagram, диаграмма прецедентов, структурирование прецедентов , настоятельно рекомендую прочитать все из категории Технологии компьютерного проектирования.
диаграмма вариантов использования (англ. use case diagram) в UML — диаграмма, отражающая отношения между акторами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне .
Прецедент — возможность моделируемой системы (часть ее функциональности), благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат. Прецедент соответствует отдельному сервису системы, определяет один из вариантов ее использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе .
Поведение системы (т.е. функциональность, которую она обеспечивает) описывают с помощью функциональной модели, которая отображает системные прецеденты (use cases, случаи использования), системное окружение (действующих лиц, актеров, actors) и связи между ними (use cases diagrams).
Диаграмма вариантов использования ( диаграмма прецедентов , use case diagram) — это диаграмма, на которой изображаются отношения между актерами и вариантами использования.
Пример диаграммы прецедентов
Рис. Диаграмма вариантов использования
Таким образом Прецедентная модель бизнеса - Отражает основные бизнес-процессы, их взаимодействие с окружением. Начинается с построения внешней диаграммы (вариантов использования — Use Case Diagram), показывающей, как бизнес виден извне.
Рис. Прецедентная модель бизнеса
Диаграмма прецедентов является графом , состоящий из множества актеров, прецедентов (вариантов использования) ограниченных границей системы (прямоугольник), ассоциаций между актерами и прецедентами, отношений среди прецедентов, и отношений обобщения между актерами. Диаграммы прецедентов отражают элементы модели вариантов использования.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. Вариант использования ( англ. Use case ) используют для описания услуг, система предоставляет актеру. Иными словами, каждый вариант использования определяет некоторый набор действий, который выполняет система при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализована взаимодействие актеров с системой.
В языке UML есть несколько стандартных видов отношений между актерами и вариантами использования:
При этом общие свойства вариантов использования могут быть представлены тремя различными способами, а именно - с помощью отношений включения, расширения и обобщения.
Отношение ассоциации - одно из фундаментальных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм.
Включение ( англ. Include ) в языке UML - это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем. При этом отношением зависимости ( англ. Dependency ) есть такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого).
Отношение расширения ( англ. Extend ) определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональная поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.
Рис. Элементы диаграммы Use Case
Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate). Они моделируют взаимосвязи прецедентов с окружением (информационные и материальные потоки) Между прецедентами, как правило, устанавливаются только отношения зависимости а также отношения, структурирующие прецеденты – отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend). 
Для каждого из элементов модели составляется спецификация. Об этом говорит сайт https://intellect.icu . В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.
В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов
Для каждого из элементов модели составляется спецификация.
В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.
В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов
Спомощью этой диаграммы можно:
Диаграмма вариантов использования (прецедентов) представляет собой
граф, в вершинах которого расположены актеры или прецеденты, связи между вершинами – это разного вида отношения.
Актером (действующее лицо, actor) называется любой объект,
субъект или система, взаимодействующая с моделируемой системой извне. Это может быть человек, техническое устройство, программа или
любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. На диаграммах вариантов использования актер изображается в виде человечка, под которым записывается его имя (рис. 8).
Рисунок 8. Действующее лицо (актер)
Вариант использования (прецедент, use case) — описание множества последовательности действий (включая варианты), выполняемых системой для того, чтобы актер мог получить определенный результат .
Каждый вариант использования должен быть независимым в том смысле, что если он всегда выполняется совместно с другим вариантом использования, то, скорее всего, это один прецедент, а не два, либо они связаны отношением включения или расширения, о чем речь пойдет позже. Как следует из определения, прецедент (или вариант использования) должен обладать результирующей ценностью для актера, актер должен получить некоторый результат исполнения прецедента. Скорее всего, после исполнения прецедента в системе произойдут некоторые изменения: появятся новые данные, изменится поведение. Каждый вариант использования должен исполняться от начала до конца.
Прецедент описывает, что делает система, но никак не уточняет, какона это делает. Заметим, что диаграмма прецедентов не отображает последовательность, в которой будут выполняться варианты использования. На диаграмме прецедент изображается в виде эллипса. Имя прецедента может состоять из нескольких слов и знаков препинания (за исключением
двоеточия), как правило, имя выбирают в виде словосочетания или глагольного выражения (рис. 9).
Рисунок 9. Варианты использования (прецеденты)
Одним из наиболее важных (и дорогостоящих) этапов проектирования информационных систем является этап определения требований к системе. Если требования заказчика информационной системы разработчиками будут определены не корректно, то в итоге заказчик может получить совсем не ту систему, которую он ожидал.
Моделирование прецедентов и актеров помогает нам лучше понять требования, предъявляемые к системе, и согласовать их с заказчиком с помощью демонстрации и обсуждения диаграммы прецедентов. Прецеденты и актеры – это отражение требований к системе, они показывают, кто и для чего будет использовать будущую систему.
Пример. Определим актеров и прецеденты системы заказов магазина
«Style».
Напомним, что покупатель делает заказ, складывая товары в корзину. Возможна только одна форма оплаты: банковской картой по интернету, невозможно оформление заказа без оплаты. Заказ имеет статус: оплачен, передан на комплектацию, собран, получен. Статус заказа изменяется автоматически либо сотрудником магазина. Покупатель может узнать статус своего заказа по уникальному номеру заказа.
Система не занимается поставками товаров в магазин. Этим занимается другая система, назовем ее Cклад.
Таким образом, с нашей системой взаимодействуют покупатель, сотрудники магазина и внешняя система Склад. С нашей системой взаимодействуют сотрудник отдела продаж, который проверяет оплату заказа и отправляет его на комплектацию, и кладовщик, который собирает заказ и выдает его покупателю. С точки зрения бизнеса – это две разных должности, выполняющих разные функции, но с точки зрения системы они играют одну роль сотрудника, изменяющего статус заказа покупателя с использованием программного обеспечения моделируемой системы. В этом смысле для системы нет разницы между сотрудником отдела продаж и кладовщиком. Выбирая действующих лиц, нужно помнить о том, что мы должны отразить их роль, а не должность. Введем обобщающее сотрудников действующее лицо – Сотрудник. Другой пример: сотрудник магазина «Style» (положим,
кладовщик) может выступать в роли сотрудника и общаться с системой как сотрудник магазина, а может выступать и в роли покупателя, сделав заказ в магазине. Не смотря на то, что физически это один человек, он выступает в роли двух актеров: покупателя и сотрудника. Итак, актеры системы заказов магазина «Style» будут следующие:
Покупатель, Сотрудник, Система Склад.
Покупатель использует нашу систему для того, чтобы заказать вещи, он просматривает каталог, добавляет понравившиеся ему товары в корзину, открывает корзину, удаляет из нее товары или изменяет их количество и, наконец, может оформить свой заказ, при этом его оплатив. В конечном итоге результат использования системы покупателем будет получен, если он выполнил все эти действия от начала до конца. Поэтому не будем разделять заказ товаров на несколько прецедентов, а выделим только один:Заказ товаров.
Покупатель, сделав заказ в магазине «Style», может в дальнейшем узнавать статус своего заказа, это тоже случай использования системы,
назовем его Получение информации о заказе.
Сотрудник должен изменять статус сделанного заказа, для него определим прецедент Управление статусом заказа.
Система Склад должна получать информацию о сделанных заказах для возможности управления наличием товаров на складе, для нее также должен быть доступен прецедент Получение информации о заказе.
Итак, прецеденты системы заказов магазина «Style»: Заказ товаров,
Управление статусом заказа, Получение информации о заказе.
Основное назначение диаграммы — описание функциональности и поведения, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать проектируемую или существующую систему.
При моделировании системы с помощью диаграммы прецедентов системный аналитик стремится:
Работа над диаграммой может начаться с текстового описания, полученного при работе с заказчиком. При этом нефункциональные требования (например, конкретный язык или система программирования) при составлении модели прецедентов опускаются (для них составляется другой документ) .
Для отражения модели прецедентов на диаграмме используются :
Часть дублирующейся информации в модели прецедентов можно устранить указанием связей между прецедентами :
При работе с вариантами использования важно помнить несколько простых правил:
Чтобы упростить описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования.
1. Выделение фрагментов
Если из описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент. Между выделенным прецедентом и базовым устанавливается отношения включения (include).
Иногда используют отношение расширения (extend). Оно устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях.
2. Обобщение
Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский). Между каждым из частных прецедентов и родительским устанавливается отношение обобщения (generali-zation).
Рис. Структурирование прецедентов обобщением
Рис. Структурирование прецедентов выделением фрагментов
Рис. Структурирование прецедентов обобщением
Надеюсь, эта статья об увлекательном мире диаграмма вариантов использования, была вам интересна и не так сложна для восприятия как могло показаться. Желаю вам бесконечной удачи в ваших начинаниях, будьте свободными от ограничений восприятия и позвольте себе делать больше активности в изученном направлени . Надеюсь, что теперь ты понял что такое диаграмма вариантов использования, use case diagram, диаграмма прецедентов, структурирование прецедентов и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Технологии компьютерного проектирования
Комментарии
Оставить комментарий
Технологии компьютерного проектирования
Термины: Технологии компьютерного проектирования