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

Время на прочтение
10 мин

Количество просмотров 191K

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

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

---

Сегодня мы разберемся с тем, как использовать диаграмму вариантов использования UML (англ. «Unified Modeling Language») – стандартизированный язык моделирования при проектировании программ.

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

Когда разработчик создаёт своё приложение, он в первую очередь задумывается над двумя вопросами:

• Что будет делать приложение?

• Кто будет пользоваться этим приложением?

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

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

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

Диаграмма вариантов использования (англ. use-case diagram) – диаграмма, описывающая, какой функционал разрабатываемой программной системы доступен каждой группе пользователей.

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

В этой системе можно выделить следующие группы пользователей:

• Обучающиеся

• Преподаватели

• Классные руководители

• Заместители директора

Заместители директора есть, а где же сам директор?

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

Каждая из групп пользователей может пользоваться нашей системой по-своему.

Обучающиеся могут:

• Смотреть расписание

• Просматривать свои оценки

Преподаватели могут:

• Размещать материалы для уроков

• Выставлять оценки в электронный журнал

Классные руководители могут делать все то же самое, что и преподаватели плюс:

• Составлять расписание родительских собраний

Заместители директора могут:

• Составлять расписание

• Публиковать посты с важной информацией

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

• Отправлять сообщения

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

А почему мы описываем так мало возможностей?

А теперь, когда мы выделили группы пользователей и функциональность системы, начнём строить диаграмму, чтобы зафиксировать и структурировать полученные данные.

Построение диаграммы

Каждая группа пользователей на диаграмме вариантов использования обозначается человечком, под которым записывается имя группы людей, которую он обозначает. Давайте изобразим группу пользователей «Преподаватели»:

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

В терминологии UML, этот человечек называется актёром (англ. «actor»). В общем случае, актёр обозначает любые сущности, использующие систему. Этими сущностями могут быть люди, технические устройства или даже другие системы.

Так же изобразим актёров для оставшихся групп пользователей:

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

В терминологии UML, этот эллипс называется вариантом использования (англ. «use-case»). В общем случае, вариант использования – набор действий, который может быть использован актёром для взаимодействия с системой.

Связи между элементами

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

Отношение ассоциации

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

Мы соединили актеров с вариантом использования с помощью сплошной линии без стрелки. Такая линия называется отношением ассоциации.

Отношение ассоциации предназначено только для соединения актёров и вариантов использования. Нет никакого смысла соединять отношением ассоциации двух актёров или два варианта использования.

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

Почему отношение ассоциации называется так и не иначе?

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

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

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

Отношение обобщения

Заметим, что в нашей системе группы пользователей «Преподаватель» и «Классный руководитель» обладают схожими возможностями. Чтобы изобразить это на диаграмме, мы можем пойти одним из трёх путей:

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

2. Соединить каждого актёра со всеми нужными вариантами использования. Это может породить множество пересечений линий, что не самым лучшим образом скажется на читаемости диаграммы.

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

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

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

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

Ниже представлены несколько примеров использования отношения обобщения.

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

Вернёмся к нашему основному примеру. Изобразим отношение обобщения от актёра «Кл. руководитель» к актёру «Преподаватель».

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

Давайте обратим внимание на действие «Узнать свои оценки». Логично предположить, что обучающиеся захотят не только знать список своих оценок, но и знать свою среднюю оценку за некоторый период времени или среднюю оценку по определённому предмету.

Изобразим это на диаграмме. Для этого создадим два варианта использования «Узнать среднюю оценку за некоторый период времени» и «Узнать среднюю оценку по предмету» и соединим их с вариантом использования «Узнать свои оценки» отношением обобщения.

Присоединим это к основной диаграмме:

Отношение включения

Для заместителя директора мы отмечали, что ему нужно составлять расписания. Условно расписание можно поделить на три категории:

1. Расписание занятий

2. Расписание мероприятий

3. Расписание каникул

Всё это составляется заместителем директора, поэтому покажем это на диаграмме. Для этого будем использовать отношение включения. Отношение включения обозначается пунктирной линией с V-образной стрелкой на конце, над стрелкой добавляется надпись “include”.

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

Когда мы используем отношение включения, мы подразумеваем, что составные варианты использования ОБЯЗАТЕЛЬНО входят в состав общего варианта использования.

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

Снова вернёмся к нашему основному примеру.

Как итог, наша диаграмма принимает следующий вид:

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

Отношение расширения

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

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

Зачем над пунктирными линиями добавлять надписи “include” и “extend”?

В UML пунктирная линия с V-образной стрелкой, в общем случае, называется отношением зависимости. Для диаграммы вариантов использования выделяют различные виды зависимостей: отношение включения и отношение расширения. Чтобы их различать, над стрелками пунктирной линией пишут “include” и “extend” соответственно.

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

Два нижних варианта использования описывают возможные «расширения» для базового варианта использования. Исходя из этого примера, мы можем сделать важное замечание.

Можно сказать, что отношение расширения — это выборочное отношение включения. Если отношение включения обозначает, что элемент обязательно включается в состав другого элемента, то в случае отношения расширения это включение необязательно.

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

Вернёмся к нашему основному примеру. Мы хотим, чтобы действие «прикрепить файл к сообщению» расширяло действие «отправить сообщение». На диаграмме это изображается следующим образом:

Как итог, получим такую диаграмму:

Вот и всё. Я постарался рассказать вам про все моменты построения диаграммы вариантов использования при проектировании программных систем. В следующем вашем проекте обязательно попробуйте построить данную диаграмму на стадии проектирования. Ваши усилия обязательно окупятся!

Что делать, если я путаюсь в направлении стрелок?

Общие рекомендации:

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

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

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

4. Не дублируйте варианты использования на диаграмме. Если приходится дублировать варианты использования, то элементы диаграммы надо постараться расставить по-другому.

5. Пользуйтесь специальными компьютерными программами для построения диаграмм. Это существенно упростит весь процесс моделирования.

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

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

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

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

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

Вариант использования

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

Как составить правильный Use Case?

Каждый вариант использования может иметь свои варианты выполнения (Alternate Flows). Они описывают возможные варианты поведения в определенных условиях, таких как ошибки ввода или некорректные данные. Эти варианты выполнения отображаются на диаграмме прецедентов в виде ветвей, которые выходят из основного эллипса варианта использования.

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

Акторы

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

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

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

Extension points

«Extension points» (точки расширения) — это особый элемент на диаграмме вариантов использования (use case diagram), который позволяет представить возможность расширения функциональности системы путем внедрения дополнительных вариантов использования (use cases) без изменения основной логики приложения.

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

Таким образом, использование «Extension points» позволяет лучше структурировать функциональность системы и уменьшить сложность ее разработки, позволяя добавлять новые варианты использования без внесения изменений в существующий код.

Отношения (связи)

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

Существует несколько типов отношений на диаграмме вариантов использования:

Отношение «ассоциации» (association) — используется для связи между прецедентами и акторами. Оно показывает, что актор взаимодействует с прецедентом. Отношение ассоциации связывает прецеденты с акторами и показывает, какой актор использует данный прецедент.

Отношение «включение» (include) — используется, когда один вариант использования использует функциональность другого варианта использования. Это отношение показывает, что один вариант использования является составной частью другого варианта использования.

Отношение «расширение» (extend) — используется, когда один вариант использования может быть расширен другим вариантом использования, если возникают определенные условия. Это отношение показывает, что расширенный вариант использования является необязательным и может быть выполнен только при определенных условиях.

Отношение «общий актор» (generalization) — используется, когда несколько акторов имеют общие характеристики, но один актор является более общим, чем другой. Например, акторы «Клиент» и «Администратор» могут быть представлены более общим автором «Пользователь».

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

Системная граница

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

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

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

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

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

Определить цели и задачи

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

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

Цель — описать, как пользователь может выполнить вход в систему.

Задачи:

1. Идентифицировать и описать все возможные варианты использования для авторизации пользователя.
2. Выявить действия, которые пользователь может выполнять на каждом этапе авторизации.
3. Идентифицировать все взаимодействия между пользователями и системой, связанные с авторизацией.
4. Предоставить четкое понимание, как система реагирует на каждое действие пользователя, связанное с авторизацией.
5. Помочь уточнить требования к системе по авторизации пользователя и выявить возможные проблемы и улучшения.

Определить акторов

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

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

1. Клиент – пользователь, который использует систему для авторизации и входа в свой аккаунт.
2. Администратор – пользователь, который имеет права на управление настройками авторизации.

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

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

Вариант использования	Акторы
Авторизация по логину и паролю	Клиент, Администратор
Авторизация по e-mail и паролю	Клиент
Выход из системы	Клиент, Администратор
Создать новое правило авторизации	Администратор
Изменить правила авторизации	Администратор
Удалить правила авторизации	Администратор

Установить отношения (связи) между акторами и вариантами использования

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

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

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

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

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

• Важность использования диаграммы прецедентов
• Объекты диаграммы прецедентов
• Рекомендации по диаграммам прецедентов
• Отношения в диаграммах вариантов использования
• Как создавать диаграммы вариантов использования ( с примером )
  • идентификация актеров
  • Определение вариантов использования
  • Когда использовать “Включить”
  • Как использовать обобщение
  • Когда использовать «Расширить»
• Шаблоны диаграмм вариантов использования для распространенных сценариев

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

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

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

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

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

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

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

Актер

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

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

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

Система

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

Пакет

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

Рекомендации по диаграммам прецедентов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше руководств по диаграммам

• Учебное пособие по диаграммам последовательностей: полное руководство с примерами
• Учебное пособие по моделированию бизнес-процессов (руководство по BPM с объяснением функций)
• Окончательное руководство по блок-схеме (полное руководство по блок-схеме с примерами)

Что такое вариант использования?

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

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

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

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

( Редактировать приведенный выше пример диаграммы вариантов использования )

Диаграмма вариантов использования состоит из ряда элементов модели. Наиболее важными элементами модели являются:

Актер

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

Вариант использования

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

Отношение

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

Системная граница

Граница системы определяет интересующую систему по отношению к окружающему миру.

Характеристики варианта использования

Вариант использования (или набор вариантов использования) имеет следующие характеристики:

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

Вариант использования и сценарий использования?

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

Что внутри варианта использования?

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

Тип вариантов использования

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

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

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

Структурирование вариантов использования

UML определяет три стереотипа связи между вариантами использования:

<<включить>> Пример использования

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

<<расширить>> Вариант использования

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

Абстрактный и обобщенный вариант использования

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

Пример

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

После того, как базовые варианты использования были определены в первом варианте, возможно, мы могли бы дополнительно структурировать эти варианты использования с помощью <<extend>> и <<include>> вариантов использования во втором раунде, как показано на рисунке ниже:

( Редактировать приведенный выше пример диаграммы вариантов использования )

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

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

( Редактировать приведенный выше пример диаграммы вариантов использования )

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

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

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

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

• Чтобы написать содержание варианта использования, вы начинаете с выбора одного из сценариев в качестве основного сценария.
• Вы начинаете основную часть варианта использования с написания основного сценария успеха в виде последовательности пронумерованных шагов.
• Затем вы берете другие сценарии и записываете их как расширения. Расширения могут быть успешными, как в 3a ниже, или неудачными, как в 6b ниже.
• У каждого варианта использования есть основное действующее лицо, которое обращается к системе для предоставления услуги.
• Каждый шаг варианта использования является элементом взаимодействия между пользователем и системой.
• Общий набор действий в варианте использования может быть повторно использован другим вариантом использования с помощью варианта использования <include>.
• В терминах UML мы говорим, что первый вариант использования включает в себя второй.

Купить продукт  (взято из UML Distilled p101)

Основной сценарий успеха:

1. Клиент просматривает каталог и выбирает товар для покупки.
2. Клиент идет к кассе.
3. Клиент заполняет информацию о доставке
4. Система предоставляет полную информацию о ценах
5. Клиент заполняет данные кредитной карты
6. система разрешает покупку
7. Система подтверждает продажу
8. Система отправляет электронное письмо с подтверждением клиенту

Расширения

3а: Клиент является постоянным клиентом

.1 Система отображает текущую информацию о доставке

.2 Заказчик может принять или отменить

6a: Системе не удается авторизовать покупки в кредит

.1 Клиент может повторно ввести информацию о кредитной карте или отменить

Описание варианта использования, иллюстрированное Visual Paradigm

Поток событий и расширение

• Записывает пути (называемые  сценариями ) от триггерных событий к целям .

Варианты использования и UML-моделирование

Сценарии использования можно использовать на нескольких этапах разработки программного обеспечения, таких как планирование системных требований, проверка проекта, тестирование программного обеспечения и создание схемы интерактивной справки и руководств пользователя. Итак, какова связь диаграммы вариантов использования с другими диаграммами UML в SDLC?

Выбор модели важен

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

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

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

использованная литература

Это первая статья из цикла про методологию ICONIX, посвящена UML-диаграммам вариантов использования. В публикациях и книгах по ICONIX, use-case диаграммы обычно описываются очень бегло, а в книгах по UML — слишком подробно. Я постараюсь сделать это настолько подробно, чтобы можно было приступить к использованию диаграмм, но при этом не было скучно. Важно, что до тех пор, до знакомства с ICONIX я не считал use-case диаграммы хоть сколько-нибудь полезными, поэтому в статье я попробую сконцентрироваться на том, что они могут принести проекту.

Вне зависимости от методологии разработки, которую вы применяете, первым этапом разработки будет являться формулировка требований к продукту (Градди Буч описывает Rational Unified Process [1], а Розенберг — ICONIX [2]). Набор требований к продукту представляет собой техническое задание, при этом требования делятся на функциональные (то, что система позволяет сделать, желаемая функциональность) и нефункциональные (требования к оборудованию, операционной системе и т.п.). В языке UML для формализации функциональных требований применяются диаграммы использования.

Диаграмму вариантов использования есть смысл строить во время изучения технического задания, она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных последовательностей действий (потока событий), которые выполняет пользователь при работе с системой. Спецификация затем станет основой для тестирования и документации, а на следующих этапах проектирования она дополняется и оформляется в виде диаграммы (в рамках ICONIX используется диаграмма последовательности, но в UML для этого имеются также диаграммы деятельности). Кроме того, use-case диаграмма достаточно проста, чтобы ее мог понять заказчик, следовательно вы можете использовать ее для согласования ТЗ (ведь диаграмма описывает функциональные требования к системе).

На диаграмме использования изображаются:

• акторы — группы лиц или систем, взаимодействующих с нашей системой;
• варианты использования (прецеденты) — сервисы, которые наша система предоставляет акторам;
• комментарии;
• отношения между элементами диаграммы.

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

1. выделить группы действующих лиц (работающих с системой по-разному, часто из-за различных прав доступа);
2. идентифицировать как можно больше вариантов использования (процессов, которые могут выполнять пользователи). При этом не следует делить процессы слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый результат. Например, кассир может «продать товар» (это будет являться прецедентом), однако «ввод штрих-кода товара для получения цены» самостоятельным прецедентом не является;
3. дополнить прецеденты словесным описанием (сценарием):
   • для каждого прецедента создать разделы: «главная последовательность» и «альтернативные последовательности»;
   • при составлении сценария нужно упорно задавать заказчику вопросы «что происходит?», «что дальше?», «что еще может происходить?» и записывать ответы на них.

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

Рассмотрим разработку диаграмм вариантов использования на примере — пусть заказчик дал нам следующее техническое задание:

Цель — развитие у детей математических навыков.
Платформа: Linux, Windows, Android.
Функциональность:

• для учеников:
  • выбор подготовленного учителем блока заданий;
  • выполнение заданий;
• для учителя:
  • подготовка для учеников блоков заданий;
  • добавление в систему ученика;
  • просмотр отчетов.

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

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

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

Название прецедента: регистрация ученика

Действующее лицо: учитель

Цель: добавить ученика в систему, получив его пароль

Предусловия: учитель осуществил вход в систему

Главная последовательность:

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. система добавляет ученика;
5. учителю открывается главное меню и в течении 5 секунд выводится уведомление о том, что ученик был добавлен успешно.

Альтернативная последовательность (возврат в главное меню без добавления ученика):

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель нажимает кнопку «назад»;
4. учителю открывается главное меню (при этом данные, введенные в формы окна добавления ученика не сохраняются).

Альтернативная последовательность (добавление ученика, уже имеющегося в системе):

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. учителю в течении 5 секунд отображается уведомление о том, что запрашиваемый логин занят.

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

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

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

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

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

На последней диаграмме используется символ комментария для задания условий расширения, при этом комментарий связывается пунктирной линией с отношением расширения, т.к. относится к нему. В ряде публикаций по UML и ICONIX предлагается описывать с помощью комментариев на диаграмме прецедентов:

• нефункциональные требования к системе (при этом используется стереотип <<requirement>>);
• сценарии вариантов использования (связывая комментарий с соответствующим прецедентом);
• детали реализации и другие выводы, к которым разработчики пришли в процессе обсуждения задачи (не все с этим согласны, т.к. use-case диаграмма показывается заказчику, которому не нужны детали).

Наиболее типичными ошибками при построении этого вида диаграмм являются:

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

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

Стоит отметить, что нет единого мнения по поводу использования в текстах сценария условных операторов или циклов. Ряд аналитиков считают, что наличие слов типа «если» в сценарии является ошибкой, которая исправляется добавлением альтернативной последовательности. Другие — допускают использование 1-2 ветвлений в сценарии, при этом отмечают, что такой подход улучшает читабельность сценариев.

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

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

1. Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. – М.: ООО “И.Д. Вильямс”, 2010. – 720 с.
2. Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
3. Бабич А. В. Введение в UML // Интернет университет информационных технологий. 2008. URL: http://www.intuit.ru/studies/courses/1007/229/info (дата обращения: 19.03.2016).
4. Леоненков, A.B. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose: учеб. пособие Текст. / A.B. Леоненков. М.: Интернет-Ун-т информ. технологий: БИНОМ, Лаборатория знаний, 2006. — 320 с.