Для чего нужна диаграммы использования
Элементы графической нотации диаграммы вариантов использования
Диаграмма вариантов использования как концептуальное представление бизнес-системы в процессе ее разработки.
Визуальное моделирование с использованием нотации UML можно представить как процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной бизнес-системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram ), которая описывает функциональное назначение системы или, другими словами, то, что бизнес-система должна делать в процессе своего функционирования.
Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое имя в форме существительного (рис. 3.1, а) или глагола (рис. 3.1, б) с пояснительными словами. Сам текст имени варианта использования должен начинаться с заглавной буквы.
Имя (name) — строка текста, которая используется для идентификации любого элемента модели.
Примерами вариантов использования могут быть следующие действия: проверка состояния текущего счета клиента, оформление заказа на покупку товара, получение дополнительной информации о кредитоспособности клиента, отображение графической формы на экране монитора и другие действия.
Актер (actor) — согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними.
В некоторых случаях актер может обозначаться в виде прямоугольника класса со стереотипом и обычными составляющими элементами класса. Имена актеров должны начинаться с заглавной буквы и следовать рекомендациям использования имен для типов и классов модели. При этом символ отдельного актера связывает соответствующее описание актера с конкретным именем.
UML — диаграмма вариантов использования (use case diagram)
Диаграммы вариантов использования описывают взаимоотношения и зависимости между группами вариантов использования и действующих лиц, участвующими в процессе.
Важно понимать, что диаграммы вариантов использования не предназначены для отображения проекта и не могут описывать внутреннее устройство системы. Диаграммы вариантов использования предназначены для упрощения взаимодействия с будущими пользователями системы, с клиентами, и особенно пригодятся для определения необходимых характеристик системы. Другими словами, диаграммы вариантов использования говорят о том, что система должна делать, не указывая сами применяемые методы.
Вариант использования (use case)
В данном примере вариант использования Part включается в вариант использования Base.
В данном примере вариант использования Base расширяется вариантом использования Another.
В данном примере вариант использования Child обобщает вариант использования Base.
Действующее лицо (actor)
Действующее лицо является внешним источником (не элементом системы), который взаимодействует с системой через вариант использования. Действующие лица могут быть как реальными людьми (например, пользователями системы), так и другими компьютерными системами или внешними событиями.
Действующие лица представляют не физических людей или системы, а их роли. Эти означает, что когда человек взаимодействует с системой различными способами (предполагая различные роли), он отображается несколькими действующими лицами. Например, человек, работающий в службе поддержки и принимающий от клиентов заказы, будет отображаться в системе как «участник отдела поддержки» и «участник отдела продаж».
Описание варианта использования
Описания вариантов использования являются текстовыми пояснениями. Они обычно принимают форму заметки или документа, который каким-то образом прикрепляется к варианту использования и описывает процесс или активность.
Диаграмма вариантов использования UML
Диаграмма вариантов использования UML
Что такое диаграмма вариантов использования UML?
Звучит как довольно тяжелое название, не так ли? Что ж, давайте разберем это с каждым словом.
UML-диаграммы
Представьте себе эти реальные масштабные модели различных огромных архитектур, таких как торговый центр или жилищное общество, разбросанные по акрам, помещенные в красивые блестящие стеклянные коробки на стойке регистрации здания. Разве не легко понять всю структуру, когда она смоделирована как единое целое на ваших глазах?
Диаграмма вариантов использования UML
Но зачем нужна диаграмма вариантов?
Это любопытная сторона вашего разговора. Давайте проанализируем через некоторые QnA.
Ответ: Да, но диаграмма вариантов использования делает это с точки зрения конечного пользователя, тогда как диаграмма действий делает это с точки зрения системы. Конечный пользователь может не знать свою роль через диаграмму действий.
Ответ: Диаграммы последовательности представляют собой более подробные версии взаимодействия пользователя и системы. Они также включают внутреннее функционирование системы, взаимодействие между субмодулями и время, прошедшее во время внутреннего функционирования. Конечный пользователь может быть не заинтересован в таких деталях. Он обеспокоен общим выходом системы.
Отв. Диаграммы сотрудничества действительно проще, но они в основном сосредоточены на связи между компонентами. Это по-прежнему требует большего внимания к сообщениям, которыми обмениваются система и субмодули. Конечный пользователь все еще может найти его слишком подробным для своих целей.
Итак, вывод из этого обсуждения заключается в том, что, хотя многие диаграммы UML выполняют аналогичные функции, они играют выдающуюся роль в понимании системы. Диаграмма вариантов использования так же важна, как и любая другая диаграмма, для общей документации компонентов системы диаграмм вариантов использования.
пример
Ниже приведен простой пример схемы вариантов использования для системы бронирования авиабилетов. Эту диаграмму можно сделать более полной с введением других участников, таких как операторы бронирования, банки и т. Д. Она была упрощена, чтобы продемонстрировать, как составляется диаграмма варианта использования.
Вывод
Диаграммы прецедентов просты, но эффективны для понимания системы извне. Они очень полезны для бизнеса, чтобы определить требования высокого уровня и проанализировать недостатки в требованиях. Понимание диаграмм прецедентов помогает бизнесу и технической команде попасть на одну страницу с точки зрения требований.
Рекомендуемые статьи
Основы UML — диаграммы использования (use-case)
Это первая статья из цикла про методологию ICONIX, посвящена UML-диаграммам вариантов использования. В публикациях и книгах по ICONIX, use-case диаграммы обычно описываются очень бегло, а в книгах по UML — слишком подробно. Я постараюсь сделать это настолько подробно, чтобы можно было приступить к использованию диаграмм, но при этом не было скучно. Важно, что до тех пор, до знакомства с ICONIX я не считал use-case диаграммы хоть сколько-нибудь полезными, поэтому в статье я попробую сконцентрироваться на том, что они могут принести проекту.
Вне зависимости от методологии разработки, которую вы применяете, первым этапом разработки будет являться формулировка требований к продукту (Градди Буч описывает Rational Unified Process [1], а Розенберг — ICONIX [2]). Набор требований к продукту представляет собой техническое задание, при этом требования делятся на функциональные (то, что система позволяет сделать, желаемая функциональность) и нефункциональные (требования к оборудованию, операционной системе и т.п.). В языке UML для формализации функциональных требований применяются диаграммы использования.
Диаграмму вариантов использования есть смысл строить во время изучения технического задания, она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных последовательностей действий (потока событий), которые выполняет пользователь при работе с системой. Спецификация затем станет основой для тестирования и документации, а на следующих этапах проектирования она дополняется и оформляется в виде диаграммы (в рамках ICONIX используется диаграмма последовательности, но в UML для этого имеются также диаграммы деятельности). Кроме того, use-case диаграмма достаточно проста, чтобы ее мог понять заказчик, следовательно вы можете использовать ее для согласования ТЗ (ведь диаграмма описывает функциональные требования к системе).
На диаграмме использования изображаются:
На мой взгляд, наиболее правильный порядок построения диаграммы следующий:
Сценарии являются очень важной частью диаграмм использования, хотя их формат и не регламентирован. Ряд авторов предлагает использовать псевдокод для представления сценария и даже сразу строить диаграммы деятельности или взаимодействия, но на мой взгляд, наиболее предпочтительным вариантом на этапе построения use-case диаграмм является текстовый, описывающий систему с точки зрения пользователя (т.к. именно этот формат будет наиболее понятен заказчику, с которым вам предстоит согласовывать техническое задание).
Рассмотрим разработку диаграмм вариантов использования на примере — пусть заказчик дал нам следующее техническое задание:
Цель — развитие у детей математических навыков.
Платформа: Linux, Windows, Android.
Функциональность:
При первом запуске система должна позволять ввести пароль учителя. Задания представляют собой математические задачи на сложение, вычитание, умножение и деление. В блоке задач могут быть задачи различных типов (указывается количество). Помимо ввода типа выполняемой в примере операции необходимо указывать допустимые диапазоны чисел (или даже отдельные числа, т.к. при изучении таблицы умножения часто сначала учат умножение на 2, затем на 5, а только потом все остальное). Кроме того, для операции вычитания необходимо иметь возможность установить вычитаемое меньше уменьшаемого (т.к. в противном случае результат будет отрицательным, а отрицательные числа в школе проходят гораздо позже).
Очевидно, несмотря на то, что заказчик очень подробно описал некоторые детали, мы не можем не только приступить к реализации задачи, но даже приблизительно оценить стоимость и сроки выполнения. Из такого задания не понятно, например, что должны содержать отчеты. Однако, мы сразу можем выделить две группы пользователей и несколько видов их деятельности.
Пример диаграммы использования
Сплошные линии на диаграмме представляют собой отношения ассоциации, отражающие возможность использования актором прецедента. После того, как определен набор вариантов использования, можно приступать к составлению сценариев. Сценарии должны описываться с точки зрения пользователя, при этом важно описывать взаимодействие пользователя с элементами интерфейса. Так например сценарий прецедента регистрации ученика мог бы выглядеть следующим образом:
Название прецедента: регистрация ученика
Действующее лицо: учитель
Цель: добавить ученика в систему, получив его пароль
Предусловия: учитель осуществил вход в систему
Главная последовательность:
Альтернативная последовательность (возврат в главное меню без добавления ученика):
Альтернативная последовательность (добавление ученика, уже имеющегося в системе):
Аналогичным образом должны быть прописаны все прецеденты, изображенные на диаграмме. Составлять сценарии нужно достаточно упорно чтобы описать все возможные варианты действий пользователя в системе. Заказчик может делать это с большим удовольствием, а программист за счет этого раньше узнает возможные пожелания заказчика (так из приведенного сценария он мог бы выяснить, что программа должна отображать всплывающие уведомления).
Несмотря на простоту приведенного сценария, в его последовательностях можно найти дублирование, если оно имеет место в ваших сценариях — вы можете выделить некоторые фрагменты описания в отдельные прецеденты (которые могут быть как самостоятельными, так и являться лишь частью других вариантов использования). При этом между прецедентами появится либо отношение расширения (extend), либо включения (include), которые отображаются на диаграммах (в UML также существует отношение обобщения, а в OML — вызова и предшествования).
Отношение включения указывает на то, что поведение одного прецедента включается в некоторой точке в другой прецедент в качестве составного компонента. Особенности включения заключаются в том, что включаемый прецедент должен быть обязательным для дополняемого (включение должно быть безусловным, а дополняемый вариант использования без включения не сможет выполняться), т.е. это это отношение задает очень сильную связь. Например, если мы хотим изобразить на диаграмме тот факт, что удаление набора задач учителем и выполнение задач учеником не должно происходить без обязательного просмотра всех наборов задач — то нам нужно использовать отношение включения:
Отношение включения на диаграмме использования
Отношение расширения отражает возможное присоединение одного варианта использования к другому в некоторой точке (точке расширения). При этом подчеркивается то, что расширяющий вариант использования выполняется лишь при определенных условиях и не является обязательным для выполнения основного прецедента. На диаграмме такой вид отношения изображается стрелкой, направленной к расширяемому прецеденту, в отдельном разделе которого может быть описана точка расширения, а условия расширения могут быть приведены в комментарии с ключевым словом Condition. Таким образом, расширение позволяет моделировать необязательное поведение системы, которое является условным и не изменяет поведение основного прецедента. Например отношение расширения нужно применить, если по техническому заданию требуется возможность удаления набора задач в прецеденте просмотра отчетов при условии, что все ученики решили этот набор.
Отношение расширения на диаграмме использования
Таким образом можно показать, что у учителя появляется возможность (но не обязанность) удалить набор задач при просмотре отчетов если все ученики выполнили этот набор.
На последней диаграмме используется символ комментария для задания условий расширения, при этом комментарий связывается пунктирной линией с отношением расширения, т.к. относится к нему. В ряде публикаций по UML и ICONIX предлагается описывать с помощью комментариев на диаграмме прецедентов:
Наиболее типичными ошибками при построении этого вида диаграмм являются:
Важно, что процесс ICONIX является итеративным, поэтому если вы допустите неточности на этапе разработке диаграмм использования — их можно будет найти и исправить на следующих этапах (в частности, пропущенные объекты могут быть выделены при работе над диаграммами робастности, а сценарии детально проработаны при построении диаграмм последовательности).
Стоит отметить, что нет единого мнения по поводу использования в текстах сценария условных операторов или циклов. Ряд аналитиков считают, что наличие слов типа «если» в сценарии является ошибкой, которая исправляется добавлением альтернативной последовательности. Другие — допускают использование 1-2 ветвлений в сценарии, при этом отмечают, что такой подход улучшает читабельность сценариев.
Если следовать всем приведенным правилам составления диаграмм вариантов использования, с их помощью можно достаточно подробно проработать техническое задание чтобы оценить сроки и стоимость его выполнения, описать конкретные сценарии взаимодействия с системой, которые лягут в основу тестов и документации, и согласовать всё это с заказчиком.
В статье приведены основные возможности use-case диаграмм, по моему мнению их должно быть достаточно для разработки подавляющего большинства систем, при необходимости большее количество информации и примеров можно почерпнуть в следующей литературе:
7) Диаграмма вариантов использования UML
Что такое диаграмма вариантов использования?
Диаграмма вариантов использования отражает функциональные возможности и требования системы с использованием действующих лиц и вариантов использования. Варианты использования моделируют службы, задачи, функции, которые должна выполнять система. Варианты использования представляют функциональные возможности высокого уровня и то, как пользователь будет обращаться с системой. Варианты использования являются основными концепциями моделирования языка Unified Modeling.
В этом уроке UML Diagram вы узнаете больше о:
Зачем нужна схема использования?
Вариант использования состоит из вариантов использования, лиц или различных вещей, которые вызывают функции, называемые актерами, и элементов, отвечающих за реализацию вариантов использования. Диаграммы прецедентов отражают динамическое поведение работающей системы. Он моделирует, как внешняя сущность взаимодействует с системой, чтобы заставить ее работать. Диаграммы прецедентов отвечают за визуализацию внешних вещей, которые взаимодействуют с частью системы.
Обозначения диаграмм вариантов использования
Ниже приведены общие обозначения, используемые в диаграмме прецедентов:
Использование регистра:
Варианты использования используются для представления функций высокого уровня и того, как пользователь будет обращаться с системой. Вариант использования представляет отдельную функциональность системы, компонента, пакета или класса. Он обозначен овальной формой с названием варианта использования, написанным внутри овальной формы. Обозначение варианта использования в UML приведено ниже:
UML UseCase Нотация
Актер:
Он используется внутри диаграмм вариантов использования. Актер — это сущность, которая взаимодействует с системой. Пользователь — лучший пример актера. Актер — это сущность, которая инициирует вариант использования вне области использования. Это может быть любой элемент, который может инициировать взаимодействие со случаем использования. Один субъект может быть связан с несколькими вариантами использования в системе. Обозначение актера в UML приведено ниже.
Как нарисовать диаграмму вариантов использования?
Чтобы нарисовать диаграмму вариантов использования в UML, сначала необходимо тщательно проанализировать всю систему. Вы должны выяснить каждую функцию, предоставляемую системой. После того, как все функциональные возможности системы обнаружены, эти функциональные возможности преобразуются в различные варианты использования, которые будут использоваться в диаграмме вариантов использования.
Вариант использования — это не что иное, как основная функциональность любой работающей системы. После организации сценариев использования мы должны привлечь различных участников или вещи, которые будут взаимодействовать с системой. Эти субъекты несут ответственность за использование функциональности системы. Актеры могут быть человеком или вещью. Это также может быть частное лицо системы. Эти субъекты должны соответствовать функциональности или системе, с которой они взаимодействуют.
После того, как актеры и варианты использования зачислены, вам необходимо изучить связь конкретного актера с вариантом использования или системой. Нужно определить общее количество способов взаимодействия актера с системой. Один субъект может взаимодействовать с несколькими вариантами использования одновременно или одновременно с несколькими вариантами использования.
Следующие правила должны соблюдаться при рисовании сценария использования для любой системы:
Советы по составлению схемы использования
Пример диаграммы варианта использования
Следующая схема использования представляет работу системы управления студентами:
UML UseCase Diagram
На приведенной выше диаграмме сценариев использования есть два актера: ученик и учитель. Всего существует пять вариантов использования, которые представляют специфическую функциональность системы управления студентами. Каждый актер взаимодействует с конкретным вариантом использования. Студент-актер может проверить посещаемость, расписание, а также тестовые отметки в приложении или системе. Этот субъект может выполнять только эти взаимодействия с системой, даже если в системе остаются другие варианты использования.
Не обязательно, чтобы каждый актер взаимодействовал со всеми вариантами использования, но это может произойти.
Второй актер по имени учитель может взаимодействовать со всеми функциями или вариантами использования системы. Этот актер также может обновлять посещаемость ученика и оценки ученика. Эти взаимодействия как студента, так и актера-учителя вместе подводят итог всего приложения управления студентами.
Когда использовать диаграмму прецедентов?
Вариант использования — это уникальная функциональность системы, которую выполняет пользователь. Цель диаграммы вариантов использования состоит в том, чтобы охватить основные функциональные возможности системы и визуализировать взаимодействия различных вещей, называемых субъектами варианта использования. Это общее использование диаграммы вариантов использования.
Диаграммы прецедентов представляют основные части системы и рабочий процесс между ними. В случае использования детали реализации скрыты от внешнего использования, только поток событий представлен.
С помощью диаграмм вариантов использования мы можем выяснить предварительные и последующие условия после взаимодействия с актером. Эти условия могут быть определены с использованием различных тестовых случаев.
В общем случае сценарии использования используются для:
Варианты использования предназначены для передачи желаемой функциональности, поэтому точная область применения может варьироваться в зависимости от системы и цели создания модели UML.