Для чего нужна диаграмма вариантов использования
Для чего нужна диаграмма вариантов использования
Диаграмма прецедентов (вариантов использования или Use Case)
Диаграмма вариантов использования, общие понятия
Диаграмма вариантов использования (use case diagram) — диаграмма, на которой изображаются отношения между акторами и вариантами использования (прецедентами).
Назначение данной диаграммы состоит в следующем: проектируемая информационная система представляется в форме так называемых вариантов использования, с которыми взаимодействуют внешние сущности или акторы. При этом актором или действующим лицом называется любой объект, субъект или система, взаимодействующая с моделируемой бизнес-системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актору. Другими словами каждый вариант использования определяет набор действий, совершаемый системой при диалоге с актором. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие акторов с системой и собственно выполнение вариантов использования.
Рассматривая диаграмму вариантов использования в качестве модели бизнес-системы, можно ассоциировать ее с «черным ящиком». Концептуальный характер этой диаграммы проявляется в том, что подробная детализация диаграммы или включение в нее элементов физического уровня представления на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. Эти аспекты должны быть сознательно скрыты от разработчика на диаграмме вариантов использования.
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, акторов и отношений между этими элементами. При этом отдельные элементы диаграммы заключают в прямоугольник, который обозначает границы проектируемой системы. В то же время отношения, которые могут быть изображены на данном графе, представляют собой только фиксированные типы взаимосвязей между акторами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.
Базовыми элементами диаграммы вариантов использования являются вариант использования и актор.
Вариант использования представляет собой спецификацию общих особенностей поведения или функционирования моделируемой системы без рассмотрения внутренней структуры этой системы. Несмотря на то, что каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актором, сами эти действия не изображаются на рассматриваемой диаграмме.
Содержание варианта использования может быть представлено в форме дополнительного пояснительного текста, который раскрывает смысл или семантику действий при выполнении данного варианта использования. Такой пояснительный текст получил название текста-сценария или просто сценария. Далее рассматривается один из шаблонов, который может быть рекомендован для написания сценариев вариантов использования.
Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое имя в форме существительного или глагола с пояснительными словами. Сам текст имени варианта использования должен начинаться с заглавной буквы.
Цель варианта использования заключается в том, чтобы зафиксировать некоторый аспект или фрагмент поведения проектируемой системы без указания особенностей реализации данной функциональности. В этом смысле каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемая система по запросу актора, т.е. определяет один из способов применения системы. Сервис, который инициализируется по запросу актора, должен представлять собой законченную последовательность действий. Это означает, что после того как система закончит обработку запроса актора, она должна возвратиться в исходное состояние, в котором снова готова к выполнению следующих запросов.
Диаграмма вариантов использования содержит конечное множество вариантов использования, которые в целом должны определять все возможные стороны ожидаемого поведения системы. Для удобства множество вариантов использования может рассматриваться как отдельный пакет. Применение вариантов использования на всех этапах работы над проектом позволяет не только достичь требуемого уровня унификации обозначений для представления функциональности подсистем и системы в целом, но и является мощным средством последовательного уточнения требований к проектируемой системе на основе их итеративного обсуждения со всеми заинтересованными специалистами.
Примерами вариантов использования могут быть следующие действия: проверка состояния текущего счета клиента, оформление заказа на покупку товара, получение дополнительной информации о кредитоспособности клиента, отображение графической формы на экране монитора и другие действия.
Актор (actor) — согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними.
Актор представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Каждый актор может рассматриваться как некая отдельная роль относительно конкретного варианта использования. Стандартным графическим обозначением актора на диаграммах является фигурка «человечка», под которой записывается имя актора
Имена акторов должны начинаться с заглавной буквы и следовать рекомендациям использования имен для типов и классов модели.
Имя актора должно быть достаточно информативным с точки зрения семантики. Для этой цели подходят наименования должностей в компании (например, продавец, кассир, менеджер, президент).
Акторы используются для моделирования внешних по отношению к проектируемой системе сущностей, которые взаимодействуют с системой. В качестве акторов могут выступать другие системы, в том числе подсистемы проектируемой системы или ее отдельные классы. Важно понимать, что каждый актор определяет согласованное множество ролей, в которых могут выступать пользователи данной системы в процессе взаимодействия с ней. В каждый момент времени с системой взаимодействует вполне определенный пользователь, при этом он играет или выступает в одной из таких ролей. Наиболее наглядный пример актора — конкретный покупатель в магазине автозапчастей.
Поскольку в общем случае актор всегда находится вне системы, его внутренняя структура никак не определяется. Для актора имеет значение только его внешнее представление, т.е. то, как он воспринимается со стороны системы. Акторы взаимодействуют с системой посредством передачи и приема сообщений от вариантов использования. Сообщение представляет собой запрос актором сервиса от системы и получение этого сервиса. Это взаимодействие может быть выражено посредством ассоциаций между отдельными акторами и вариантами использования. Кроме этого, с акторами могут быть связаны интерфейсы, которые определяют, каким образом другие элементы модели взаимодействуют с этими акторами.
Отношения на диаграмме вариантов использования
Между элементами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних акторов и вариантов использования с экземплярами других акторов и вариантов. Один актор может взаимодействовать с несколькими вариантами использования. В этом случае этот актор обращается к нескольким сервисам данной системы. В свою очередь один вариант использования может взаимодействовать с несколькими акторами, предоставляя для всех них свой сервис.
В то же время два варианта использования, определенные в рамках одной моделируемой системы, также могут взаимодействовать друг с другом, однако характер этого взаимодействия будет отличаться от взаимодействия с акторами. В обоих случаях способы взаимодействия элементов модели предполагают обмен сигналами или сообщениями, которые инициируют реализацию функционального поведения моделируемой системы.
В языке UML имеется несколько стандартных видов отношений между акторами и вариантами использования:
Отношение ассоциации – одно из фундаментальных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм. Применительно к диаграммам вариантов использования ассоциация служит для обозначения специфической роли актора при его взаимодействии с отдельным вариантом использования. На диаграмме вариантов использования отношение ассоциации обозначается сплошной линией между актором и вариантом использования. Эта линия может иметь некоторые дополнительные обозначения, например, имя и кратность.
В контексте диаграммы вариантов использования отношение ассоциации между актором и вариантом использования может указывать на то, что актор инициирует соответствующий вариант использования. Такого актора называют главным. В других случаях подобная ассоциация может указывать на актора, которому предоставляется справочная информация о результатах функционирования моделируемой системы. Таких акторов часто называют второстепенными.
Включение (include) в языке UML — это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем. При этом отношением зависимости (dependency) является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого).
Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве составного фрагмента в последовательность поведения другого варианта использования.
Так, например, отношение включения, направленное от варианта использования «Предоставление кредита в банке» к варианту использования «Проверка платежеспособности клиента», указывает на то, что каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования на данной диаграмме. Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового варианта использования к включаемому варианту использования. При этом данная линия помечается стереотипом «include».
Семантика этого отношения определяется следующим образом. Процесс выполнения базового варианта использования включает в себя, как собственное, подмножество последовательность действий, которая определена для включаемого варианта использования. При этом выполнение включаемой последовательности действий происходит всегда при инициировании базового варианта использования.
Один вариант использования может входить в несколько других вариантов, а также содержать в себе другие варианты. Включаемый вариант использования является независимым от базового варианта в том смысле, что он предоставляет последнему инкапсулированное поведение, детали реализации которого скрыты от последнего и могут быть легко перераспределены между несколькими включаемыми вариантами использования. Более того, базовый вариант зависит только от результатов выполнения включаемого в него варианта использования, но не от структуры включаемых в него вариантов.
В нашем случае прецедент «оплатить заказ» на входе получает список товаров (причем не важно откуда, от клиента в магазине или от онлайн-покупателя на сайте).
Отношение расширения (extend) определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.
В языке UML отношение расширения является зависимостью, направленной к базовому варианту использования и соединенной с ним в так называемой точке расширения. Отношение расширения между вариантами использования обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от того варианта использования, который является расширением для базового варианта использования. Данная линия со стрелкой должна быть помечена стереотипом «extend».
В нашем случае, при оплате в магазине доступны оба расширения, а при оплате на сайте только оплата картой (на самом деле второй вариант сложнее: нужно выделить отдельный прецедент «онлайн оплата» с расширениями «оплата картой», «оплата при получении» и т.п.)
Два и более актора могут иметь общие свойства, т.е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным актором, который моделирует соответствующую общность ролей.
Графически отношение обобщения обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования.
Рассматривая наш магазин при автосервисе, мы можем применить обобщение для закупок запчастей при тех.обслуживании автомобиля. Понятно, что делает это не клиент, а внутренняя служба, которая потом просто выставляет счёт со списком запчастей (и это еще один прецедент к варианту оплаты).
НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛЬЗУЙТЕ ЭТУ ДИАГРАММУ КАК ПРИМЕР ДЛЯ ПОДРАЖАНИЯ. Это первый «сырой» вариант, как минимум автосервис нужно выносить в отдельную подсистему и прецедент «покупка запчастей» инициируется менеджером автосервиса, а не сам по себе.
Мы рассмотрели только базовые элементы для диаграммы вариантов использования, на самом деле их больше. Но для нашего уровня обучения этого достаточно.
7) Диаграмма вариантов использования UML
Что такое диаграмма вариантов использования?
Диаграмма вариантов использования отражает функциональные возможности и требования системы с использованием действующих лиц и вариантов использования. Варианты использования моделируют службы, задачи, функции, которые должна выполнять система. Варианты использования представляют функциональные возможности высокого уровня и то, как пользователь будет обращаться с системой. Варианты использования являются основными концепциями моделирования языка Unified Modeling.
В этом уроке UML Diagram вы узнаете больше о:
Зачем нужна схема использования?
Вариант использования состоит из вариантов использования, лиц или различных вещей, которые вызывают функции, называемые актерами, и элементов, отвечающих за реализацию вариантов использования. Диаграммы прецедентов отражают динамическое поведение работающей системы. Он моделирует, как внешняя сущность взаимодействует с системой, чтобы заставить ее работать. Диаграммы прецедентов отвечают за визуализацию внешних вещей, которые взаимодействуют с частью системы.
Обозначения диаграмм вариантов использования
Ниже приведены общие обозначения, используемые в диаграмме прецедентов:
Использование регистра:
Варианты использования используются для представления функций высокого уровня и того, как пользователь будет обращаться с системой. Вариант использования представляет отдельную функциональность системы, компонента, пакета или класса. Он обозначен овальной формой с названием варианта использования, написанным внутри овальной формы. Обозначение варианта использования в UML приведено ниже:
UML UseCase Нотация
Актер:
Он используется внутри диаграмм вариантов использования. Актер — это сущность, которая взаимодействует с системой. Пользователь — лучший пример актера. Актер — это сущность, которая инициирует вариант использования вне области использования. Это может быть любой элемент, который может инициировать взаимодействие со случаем использования. Один субъект может быть связан с несколькими вариантами использования в системе. Обозначение актера в UML приведено ниже.
Как нарисовать диаграмму вариантов использования?
Чтобы нарисовать диаграмму вариантов использования в UML, сначала необходимо тщательно проанализировать всю систему. Вы должны выяснить каждую функцию, предоставляемую системой. После того, как все функциональные возможности системы обнаружены, эти функциональные возможности преобразуются в различные варианты использования, которые будут использоваться в диаграмме вариантов использования.
Вариант использования — это не что иное, как основная функциональность любой работающей системы. После организации сценариев использования мы должны привлечь различных участников или вещи, которые будут взаимодействовать с системой. Эти субъекты несут ответственность за использование функциональности системы. Актеры могут быть человеком или вещью. Это также может быть частное лицо системы. Эти субъекты должны соответствовать функциональности или системе, с которой они взаимодействуют.
После того, как актеры и варианты использования зачислены, вам необходимо изучить связь конкретного актера с вариантом использования или системой. Нужно определить общее количество способов взаимодействия актера с системой. Один субъект может взаимодействовать с несколькими вариантами использования одновременно или одновременно с несколькими вариантами использования.
Следующие правила должны соблюдаться при рисовании сценария использования для любой системы:
Советы по составлению схемы использования
Пример диаграммы варианта использования
Следующая схема использования представляет работу системы управления студентами:
UML UseCase Diagram
На приведенной выше диаграмме сценариев использования есть два актера: ученик и учитель. Всего существует пять вариантов использования, которые представляют специфическую функциональность системы управления студентами. Каждый актер взаимодействует с конкретным вариантом использования. Студент-актер может проверить посещаемость, расписание, а также тестовые отметки в приложении или системе. Этот субъект может выполнять только эти взаимодействия с системой, даже если в системе остаются другие варианты использования.
Не обязательно, чтобы каждый актер взаимодействовал со всеми вариантами использования, но это может произойти.
Второй актер по имени учитель может взаимодействовать со всеми функциями или вариантами использования системы. Этот актер также может обновлять посещаемость ученика и оценки ученика. Эти взаимодействия как студента, так и актера-учителя вместе подводят итог всего приложения управления студентами.
Когда использовать диаграмму прецедентов?
Вариант использования — это уникальная функциональность системы, которую выполняет пользователь. Цель диаграммы вариантов использования состоит в том, чтобы охватить основные функциональные возможности системы и визуализировать взаимодействия различных вещей, называемых субъектами варианта использования. Это общее использование диаграммы вариантов использования.
Диаграммы прецедентов представляют основные части системы и рабочий процесс между ними. В случае использования детали реализации скрыты от внешнего использования, только поток событий представлен.
С помощью диаграмм вариантов использования мы можем выяснить предварительные и последующие условия после взаимодействия с актером. Эти условия могут быть определены с использованием различных тестовых случаев.
В общем случае сценарии использования используются для:
Варианты использования предназначены для передачи желаемой функциональности, поэтому точная область применения может варьироваться в зависимости от системы и цели создания модели UML.
Диаграмма вариантов использования UML
Диаграмма вариантов использования UML
Что такое диаграмма вариантов использования UML?
Звучит как довольно тяжелое название, не так ли? Что ж, давайте разберем это с каждым словом.
UML-диаграммы
Представьте себе эти реальные масштабные модели различных огромных архитектур, таких как торговый центр или жилищное общество, разбросанные по акрам, помещенные в красивые блестящие стеклянные коробки на стойке регистрации здания. Разве не легко понять всю структуру, когда она смоделирована как единое целое на ваших глазах?
Диаграмма вариантов использования UML
Но зачем нужна диаграмма вариантов?
Это любопытная сторона вашего разговора. Давайте проанализируем через некоторые QnA.
Ответ: Да, но диаграмма вариантов использования делает это с точки зрения конечного пользователя, тогда как диаграмма действий делает это с точки зрения системы. Конечный пользователь может не знать свою роль через диаграмму действий.
Ответ: Диаграммы последовательности представляют собой более подробные версии взаимодействия пользователя и системы. Они также включают внутреннее функционирование системы, взаимодействие между субмодулями и время, прошедшее во время внутреннего функционирования. Конечный пользователь может быть не заинтересован в таких деталях. Он обеспокоен общим выходом системы.
Отв. Диаграммы сотрудничества действительно проще, но они в основном сосредоточены на связи между компонентами. Это по-прежнему требует большего внимания к сообщениям, которыми обмениваются система и субмодули. Конечный пользователь все еще может найти его слишком подробным для своих целей.
Итак, вывод из этого обсуждения заключается в том, что, хотя многие диаграммы UML выполняют аналогичные функции, они играют выдающуюся роль в понимании системы. Диаграмма вариантов использования так же важна, как и любая другая диаграмма, для общей документации компонентов системы диаграмм вариантов использования.
пример
Ниже приведен простой пример схемы вариантов использования для системы бронирования авиабилетов. Эту диаграмму можно сделать более полной с введением других участников, таких как операторы бронирования, банки и т. Д. Она была упрощена, чтобы продемонстрировать, как составляется диаграмма варианта использования.
Вывод
Диаграммы прецедентов просты, но эффективны для понимания системы извне. Они очень полезны для бизнеса, чтобы определить требования высокого уровня и проанализировать недостатки в требованиях. Понимание диаграмм прецедентов помогает бизнесу и технической команде попасть на одну страницу с точки зрения требований.
Рекомендуемые статьи
Использование диаграммы вариантов использования UML при проектировании программного обеспечения
Проектирование – один из важных шагов при разработке программы, который очень часто игнорируется начинающими разработчиками. Обычно они пытаются удержать всё в голове или, в лучшем случае, записать некоторые важные сведения на листе бумаги. Как результат, у них нет чёткого плана дальнейших действий, и проект может быть отложен в долгий ящик.
Обычно при проектировании разработчики изображают систему графически, поскольку человеку легко разобраться в таком представлении. Именно поэтому вместо написания громоздких текстов про каждую возможность будущей программы разработчики строят различные диаграммы для описания своих систем. Это помогает им не забывать, что нужно реализовать в программе, и быстро вводить в курс дела своих коллег.
Сегодня мы разберемся с тем, как использовать диаграмму вариантов использования UML (Unified Modeling Language – стандартизированный язык моделирования) при проектировании программ.
Данная статья предназначена для начинающих разработчиков и для разработчиков, не знакомых с UML, поэтому никаких предварительных знаний о диаграмме вариантов использования не требуется. Со всеми необходимыми сведениями я познакомлю читателя по ходу статьи.
Когда разработчик создаёт своё приложение, он в первую очередь задумывается над двумя вопросами:
Что будет делать приложение?
Кто будет пользоваться этим приложением?
Некоторыми программами может пользоваться множество людей, поэтому часто необходимо выделять различные группы пользователей системы. У каждой такой группы могут быть свои права и возможности в системе.
Для того чтобы описать различные группы пользователей и их возможности в будущей программе, создаётся так называемая диаграмма вариантов использования.
Диаграмма вариантов использования
Диаграмма вариантов использования (use-case diagram) – диаграмма, описывающая, какой функционал разрабатываемой программной системы доступен каждой группе пользователей.
По ходу этой статьи мы разберём элементы этой диаграммы, которые чаще всего применяются при построении, на множестве небольших примеров диаграмм и на примере одной большой диаграммы. Эта большая диаграмма будет использоваться при проектировании какой-нибудь программной системы. В качестве такой системы давайте выберем информационную систему для школы (можно рассматривать ее как сайт или как отдельное приложение). Пример, разумеется, демонстрационный и не претендует на законченность.
В этой системе можно выделить следующие группы пользователей:
Заместители директора есть, а где же сам директор?
В целом, в реальной жизни директор имеет множество обязанностей (пожалуй, не будем их перечислять). Однако в электронной системе каких-то особенных действий у него нет, поэтому мы не будем изображать его на нашей диаграмме.
Каждая из групп пользователей может пользоваться нашей системой по-своему.
Просматривать свои оценки
Размещать материалы для уроков
Выставлять оценки в электронный журнал
Классные руководители могут делать все то же самое, что и преподаватели плюс:
Составлять расписание родительских собраний
Заместители директора могут:
Публиковать посты с важной информацией
Кроме того, у системы есть функционал, который доступен всем группам пользователей. В разрабатываемой нами системе актуально будет добавить мессенджер, в котором можно будет быстро связываться с интересующим человеком. Получается, эта функциональность должна быть доступна каждому пользователю. Так и запишем. Все пользователи могут:
Получилось много пунктов, которые может быть сложно уложить в голове. Для того чтобы быстро ориентироваться в этих пунктах, мы и хотим научиться строить диаграммы вариантов использования.
А почему мы описываем так мало возможностей?
Заметьте, что на диаграмме мы хотим отобразить только ключевой функционал системы. Например, действия «войти в систему», «выйти из системы» или «восстановить пароль» могут присутствовать в любой системе, и их наличие не стоит дополнительно описывать, поскольку это загрязняет диаграмму несущественными элементами.
Вообще добавление некоторых действий на диаграмме зависит от глубины детализации. Если вам все же требуется изобразить некоторые стандартные действия, ничто не помешает быстро это сделать.
А теперь, когда мы выделили группы пользователей и функциональность системы, начнём строить диаграмму, чтобы зафиксировать и структурировать полученные данные.
Построение диаграммы
Каждая группа пользователей на диаграмме вариантов использования обозначается человечком, под которым записывается имя группы людей, которую он обозначает. Давайте изобразим группу пользователей «Преподаватели»:
Этот человечек обозначает всех преподавателей, которые будут пользоваться системой
Обратите внимание, что имя группы записывается в единственном числе. Символ человечка уже обозначает группу пользователей, поэтому не нужно дополнительно отражать это в имени.
В терминологии UML, этот человечек называется актёром (actor). В общем случае, актер обозначает любые сущности, использующие систему. Этими сущностями могут быть люди, технические устройства или даже другие системы.
Так же изобразим актёров для оставшихся групп пользователей:
Здесь изображены все группы пользователей, которые могут пользоваться нашей системой
Как я упоминал ранее, каждая группа пользователей использует определённые функции системы. На диаграмме вариантов использования функция системы изображается эллипсом, внутри которого записывается имя функции в форме глагола с пояснительными словами.
Этот эллипс представляет действие «Выставить оценки в электронный журнал»
В терминологии UML, этот эллипс называется вариантом использования (use-case). В общем случае, вариант использования – набор действий, который может быть использован актёром для взаимодействия с системой.
Связи между элементами
На диаграммах UML для связывания элементов используются различные соединительные линии, которые называются отношениями. Каждое такое отношение имеет собственное название и используется для достижения определённой цели. В качестве справочной информации перечислю все виды отношений, которые мы будем использовать в этой статье.
Отношение ассоциации Association relationship 
Отношение обобщения Generalization relationship 
Отношение включения Include relationship 
Отношение расширения Extend relationship
Отношение ассоциации
Мы хотим отображать на диаграмме информацию о том, какие варианты использования могут быть использованы каждым актёром. Сейчас, например, мы хотим показать, что выставлять оценки могут только преподаватели.
Изображаем на диаграмме информацию о том, что преподаватели могут выставлять оценки
Мы соединили актеров с вариантом использования с помощью сплошной линии без стрелки. Такая линия называется отношением ассоциации.
Отношение ассоциации предназначено только для соединения актёров и вариантов использования. Нет никакого смысла соединять отношением ассоциации двух актёров или два варианта использования.
Изображаем на диаграмме возможность покупателей оплачивать заказы
Если на диаграмме вариантов использования актёр соединен с вариантом использования с помощью отношения ассоциации, это означает, что данный актёр может выполнять действия, описанные вариантом использования.
Почему отношение ассоциации называется так и не иначе?
Чтобы лучше понять это отношение, вспомним, каким образом мы выделяли функционал для различных групп пользователей. Некоторые обязанности у нас ассоциируются с определённой группой людей, поэтому мы связываем актёров с ассоциируемыми с ними действиями.
Добавим еще вариантов использования и соединим их с соответствующими актёрами:
Первая версия диаграммы
Пока что наша диаграмма совсем не впечатляет, поэтому мы продолжим наполнять ее информацией. Заодно мы узнаем все возможности этого вида диаграмм.
Отношение обобщения
Заметим, что в нашей системе группы пользователей «Преподаватель» и «Классный руководитель» обладают схожими возможностями. Чтобы изобразить это на диаграмме, мы можем пойти одним из трёх путей:
Дублировать варианты использования, чтобы связать их с каждым схожим актёром (очевидно, неудачный вариант)
Соединить каждого актёра со всеми нужными вариантами использования. Это может породить множество пересечений линий, что не самым лучшим образом скажется на читаемости диаграммы.
Показать с помощью одного из видов отношений, что актёры связаны между собой. Это будет означать, что один из них может пользоваться всеми вариантами использования, с которыми соединён другой актёр.
Последний вариант похож на принцип повторного использования кода при написании программ или на наследование классов в ООП (Объектно-ориентированное программирование). Преимущество этого варианта в том, чтобы уменьшить количество связей на диаграмме.
Разумеется, мы воспользуемся третьим путём. В этом нам поможет, так называемое, отношение обобщения. Отношение обобщения обозначается сплошной линией с полой треугольной стрелкой.
Отношение обобщения означает, что некоторый актёр (вариант использования) может быть обобщен до другого актёра (варианта использования). Стрелка направлена от частного случая(специализации) к общему случаю.
Ниже представлены несколько примеров использования отношение обобщения.
Как можно заметить, отношение обобщения используется, чтобы показать, что одно действие является частным случаем другого действия или что одну группу людей можно обобщить до другой группы.
Вернёмся к нашему основному примеру. Изобразим отношение обобщения от актёра «Кл. руководитель» к актёру «Преподаватель».
На рисунке вверху сразу видно, насколько понятнее стала диаграмма при использовании отношения обобщения: исчезли все повторы вариантов использования и пересечения линий. Разумеется, это огромный плюс для тех, кто будет читать эту диаграмму.
Давайте обратим внимание на действие «Узнать свои оценки». Логично предположить, что обучающиеся захотят не только знать список своих оценок, но и знать свою среднюю оценку за некоторый период времени или среднюю оценку по определённому предмету.
Изобразим это на диаграмме. Для этого создадим два варианта использования «Узнать среднюю оценку за некоторый период времени» и «Узнать среднюю оценку по предмету» и соединим их с вариантом использования «Узнать свои оценки» отношением обобщения.
Уточнили на диаграмме, что у обучающихся есть возможность узнать среднюю оценку за некоторый период времени и средний балл по некоторому предмету
Присоединим это к основной диаграмме:
Вторая версия диаграммы
Отношение включения
Для заместителя директора мы отмечали, что ему нужно составлять расписания. Условно расписание можно поделить на три категории:
Всё это составляется заместителем директора, поэтому покажем это на диаграмме. Чтобы это отобразить, будем использовать отношение включения. Отношение включения обозначается пунктирной линией с V-образной стрелкой на конце, над стрелкой добавляется надпись “include”.
В общем случае, отношение включения используется, чтобы показать, что некоторый вариант использования включает в себя другие варианты использования в качестве составных частей.
Когда мы используем отношение включения, мы подразумеваем, что составные варианты использования ОБЯЗАТЕЛЬНО входят в состав общего варианта использования.
Поясню смысл и этого отношения на небольшом примере. Когда пользователь сохраняет результаты своей работы в файл, он указывает место сохранения и расширение файла (например, если он редактировал фотографию в photoshop, он может сохранить ее в различных форматах). Это можно изобразить на диаграмме вариантов использования следующим образом:
Отношение включения используется для изображения составного действия
Снова вернёмся к нашему основному примеру.
Составление расписания ВКЛЮЧАЕТ в себя составление расписания занятий, мероприятий, каникул(обязательно)
Как итог, наша диаграмма принимает следующий вид:
Третья версия диаграммы
В целом, на этом можно остановиться. Хоть наш пример и демонстрационный, он хотя бы немного отражал функциональность реального приложения. Тем не менее, остался еще один элемент, который мы не рассмотрели.
Отношение расширения
Нужно сказать, что в диаграммах вариантов использования применяется ещё один вид связи – отношение расширения. На мой взгляд, применение отношение расширения несколько специфично, поскольку неправильное его использование может запутать читателя диаграммы. Тем не менее, для полноты картины мы всё равно рассмотрим применение этого отношения на практике. В последний раз модифицируем нашу диаграмму!
Во время дистанционного обучения школьникам необходимо выполнять домашние задания и присылать их в виде архива или фотографий учителям. Получается, нужно добавить возможность прикреплять файл к сообщению в нашей системе. Чтобы отобразить это на диаграмме мы будем использовать отношение расширения. Отношение расширения обозначается пунктирной линией с V-образной стрелкой на конце (похоже на отношение включения), над стрелкой добавляется надпись “extend ”.
Зачем над пунктирными линиями добавлять надписи “include” и “extend”?
В UML пунктирная линия с V-образной стрелкой называется отношением зависимости. Для диаграммы вариантов использования выделяют различные виды зависимостей: отношение включения и отношение расширения. Чтобы их различать, над стрелками пунктирной линией пишут “include” и “extend” соответственно.
Чтобы лучше понять этот тип отношений рассмотрим пример. Допустим, вы делаете заказ в сети быстрого питания. Вы хотите заказать бургер. Вам, скорее всего, вам предложат расширить ваш заказ картошкой фри или соусом. Давайте изобразим процесс заказа на диаграмме вариантов использования.
На диаграмме предполагается, что к заказу МОЖЕТ БЫТЬ добавлена картошка фри или соус(необязательно)
Два нижних варианта использования описывают возможные «расширения» для базового варианта использования. Исходя из этого примера, мы можем сделать важное замечание.
Понимание этого критически важно для грамотного использования этого вида отношений.
Вернёмся к нашему основному примеру. Мы хотим, чтобы действие «прикрепить файл к сообщению» расширяло действие «отправить сообщение». На диаграмме это изображается следующим образом:
Расширяем функционал отправки сообщений с помощью функции прикрепления файлов к сообщению (Необязательно прикреплять файл к каждому сообщению)
Как итог, получим такую диаграмму:
Четвёртая версия диаграммы
Вот и всё. Я постарался рассказать вам про все моменты построения диаграммы вариантов использования при проектировании программных систем. В следующем вашем проекте обязательно попробуйте построить данную диаграмму на стадии проектирования. Ваши усилия обязательно окупятся!
Что делать, если я путаюсь в направлении стрелок?
При построении диаграмм UML часто возникает путаница, в какую сторону направлена та или иная стрелка. Это пройдёт после небольшой практики. Общая рекомендация к запоминанию правильного направления стрелок на диаграмме вариантов использования: стрелка ОБЫЧНО направлена от «зависимого» объекта к «независимому» (от специального к общему). Например:
Проектирование программы ЗАВИСИТ от составления функ. требований,обдумывания функционалапрограммы, выделения групп пользователей,потому что ВКЛЮЧАЕТ в себя эти этапы
Программист на каждом следующем уровне должности ПЕРЕНИМАЕТ знания с предыдущих уровней, без которых не может развиваться дальше. Получается, что актёры ЗАВИСЯТ от предыдущих ступеней
Тем не менее, в любом правиле есть исключение. Этим исключением является отношение расширение:
Если DLC было куплено, то игра зависит от контента, который содержится в нём. Наше правило «зависимости» рушится 🙁
Диаграммы очень просто изменять. Не нужно пугаться того, что требования к программе могут измениться или что вы что-то забыли отобразить на диаграмме. Вы можете добавить элементы к диаграмме, когда вам угодно.
Не нужно засорять диаграмму слишком мелкими действиями. Объедините все общие действия в одну группу под общим названием, чтобы было просто читать диаграмму.
Старайтесь не допускать пересечений соединительных линий. Это может затруднить чтение диаграммы для вас и для ваших коллег.
Не дублируйте варианты использования на диаграмме. Если приходится дублировать варианты использования, то элементы диаграммы надо постараться расставить по-другому.