Диаграмма вариантов использования школа

Обновлено: 05.07.2024

Краткие сведения о диаграмме вариантов использования

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

Достоинства модели вариантов использования заключаются в том, что она:

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

Основные элементы диаграмм вариантов использования

Активный субъект ( actor ) отождествляется с чем-то или с кем-то, взаимодействующим с системой, т.е. играет определённую роль по отношению к системе, это может быть не обязательно пользователь будущей системы, также это может быть внешняя система.

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

Между активным субъектом и вариантом использования устанавливаются связь ассоциация ( association relationship ), которая выполняет коммуникативную функцию, сообщая о взаимодействии субъекта с системой в рамках определенного варианта использования. Направление связи указывает, кто (субъект или система) является инициатором взаимодействия.
Помимо связей между субъектом и вариантом использования, связи могут устанавливаться и между вариантами использования. Связи бывают двух типов - включающими ( inclusive ) и расширяющими ( extensive ).

ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

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

Суть данной диаграммы состоит в следующем [28]: проектируемая система представляется в виде множества актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (действующим лицом, актантом, актором) называется любой объект, субъект или система, взаимодействующая с моделируемой системой извне. В свою очередь вариант использования – это спецификация сервисов (функций), которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемых системой при взаимодействии с актером. При этом в модели никак не отражается то, каким образом будет реализован этот набор действий.

В структурном подходе аналогом диаграммы вариантов использования являются диаграммы IDEF0 и DFD, вариантов использования – работы (IDEF0) и процессы (DFD), актеров – внешние сущности (DFD).

Согласно UML актера графически можно отобразить тремя способами.

Рис. 12.2. Примеры отображения актеров

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

Рис. 12.3. Примеры вариантов использования

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

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

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

Рис. 12.4. Пример примечания

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

Применительно к рассматриваемой диаграмме отношение ассоциации служит для обозначения взаимодействия актера с вариантом использования.

Рис. 12.5. Пример ассоциации

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

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

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

Рис. 12.6. Примеры обобщения

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

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

Рис. 12.7. Пример включения

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

Рис. 12.8. Пример расширения

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

Варианты использования, которые расширяют базовый, подключаются к нему (активируются при его выполнении) через так называемые точки расширения (англ. extension points). Каждая точка расширения маркируется меткой (на рис. 12.8 - calculateH) и условием (англ. condition) активации. Обычно перечень точек расширения указывается в базовом варианте использования ниже горизонтальной линии.

12.3. Правила и рекомендации по разработке диаграмм вариантов использования

Вследствие того, что диаграммы вариантов использования являются аналогом диаграмм IDEF0 и DFD, методологии их разработки во многом совпадают.

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

2. Контекстная диаграмма может представлять собой несвязный граф (в отличие от IDEF0 и DFD).

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

4. Для лучшего восприятия отдельная диаграмма (контекстная или декомпозиции) не должна быть перенасыщена элементами. Рекомендуется отображать на диаграмме не более 15 вариантов использования.

5. Располагать элементы следует так, чтобы была видна логическая последовательность выполнения вариантов использования и было минимум пересечений между отношениями.

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

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

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

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

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

- постусловия – условия, которые должны быть выполнены после завершения варианта использования. Например, таким условием может быть обязательное сохранение результатов расчета в базе данных на сервере.

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

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

В качестве примера в этой и последующих разделах будет использоваться проект системы ИСКРА-ПУТЬ, применяемой в службах пути всех железных дорог России. Описание системы приводится в теме № 6. На следующем рисунке показана контекстная диаграмма вариантов использования, разработанная с помощью Case-средства Borland Together Architect 2006 for Eclipse.

Рис. 12.9. Контекстная диаграмма вариантов использования системы определения допускаемых скоростей

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

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

В этом уроке UML Diagram вы узнаете больше о:

Зачем нужна схема использования?

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

Обозначения диаграмм вариантов использования

Ниже приведены общие обозначения, используемые в диаграмме прецедентов:

Использование регистра:

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

Актер:

Он используется внутри диаграмм вариантов использования. Актер — это сущность, которая взаимодействует с системой. Пользователь — лучший пример актера. Актер — это сущность, которая инициирует вариант использования вне области использования. Это может быть любой элемент, который может инициировать взаимодействие со случаем использования. Один субъект может быть связан с несколькими вариантами использования в системе. Обозначение актера в UML приведено ниже.

Как нарисовать диаграмму вариантов использования?

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

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

После того, как актеры и варианты использования зачислены, вам необходимо изучить связь конкретного актера с вариантом использования или системой. Нужно определить общее количество способов взаимодействия актера с системой. Один субъект может взаимодействовать с несколькими вариантами использования одновременно или одновременно с несколькими вариантами использования.

Следующие правила должны соблюдаться при рисовании сценария использования для любой системы:

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

Советы по составлению схемы использования

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

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

Следующая схема использования представляет работу системы управления студентами:

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

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

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

Когда использовать диаграмму прецедентов?

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

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

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

В общем случае сценарии использования используются для:

Анализ требований системы
Визуальное программное обеспечение высокого уровня
Захват функциональных возможностей системы
Моделирование основной идеи системы
Прямое и обратное проектирование системы с использованием различных тестовых случаев.

Варианты использования предназначены для передачи желаемой функциональности, поэтому точная область применения может варьироваться в зависимости от системы и цели создания модели UML.

Диаграмма вариантов прецедентов – это тип поведенческой диаграммы UML, который часто используется для анализа различных систем. Они позволяют визуализировать различные типы ролей в системе и то, как эти роли взаимодействуют с системой. Это руководство по диаграмме вариантов использования охватывает следующие темы и поможет вам лучше создавать сценарии использования.

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

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

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

Объекты диаграммы прецедентов

Использовать диаграммы корпуса состоят из 4 объектов.

Актер
Случай использования
Система
Пакет

Объекты более подробно описаны ниже.

Актер

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

Случай использования

Случай использования представляет собой функцию или действие внутри системы. Она нарисована как овал и названа функцией.

Система

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

Пакет

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

Отношения в диаграммах вариантов использования

Существует пять типов отношений на диаграмме прецедентов. Они

Ассоциация между актером и случаем использования
Обобщение актера
Расширить отношения между двумя случаями использования
Включить взаимосвязь между двумя случаями использования
Обобщение случая использования

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

Как создавать диаграммы прецедентов использования

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

Выявление актеров

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

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

Определение случаев использования

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

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

После того, как вы определили актёров и верхний уровень использования, у вас есть базовое представление о системе. Теперь вы можете точно настроить его и добавить к нему дополнительные слои деталей.

Ищите общие функциональные возможности для использования Включать

Ищите общие функциональные возможности, которые могут быть повторно использованы в системе. Если вы найдете два или более случаев использования, которые имеют общую функциональность, вы можете извлечь общие функции и добавить его в отдельный случай использования. Затем вы можете подключить его через include relationship, чтобы показать, что он всегда вызывается, когда выполняется исходный сценарий использования. ( см. диаграмму для примера ).

Возможно ли обобщение актеров и случаев использования

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

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

Необязательные функции или дополнительные функции

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

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

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

Шаблоны диаграмм прецедентов использования

Шаблон варианта прецедентов для системы банкомата

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

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

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

Читайте также: