Use case диаграмма как составить

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

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

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

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

---

Сегодня мы разберемся с тем, как использовать диаграмму вариантов использования 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 и паролю	Клиент
Выход из системы	Клиент, Администратор
Создать новое правило авторизации	Администратор
Изменить правила авторизации	Администратор
Удалить правила авторизации	Администратор

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

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

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

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

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

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

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

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

Это первая статья из цикла про методологию 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 с.

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

Границы системы, акторы и варианты использования: что такое диаграмма Use Case

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

В качестве иллюстративного примера рассмотрим систему онлайн-оплаты учебного курса. Пользователем этой системы является клиент. В терминологии UML он будет называться актор – сущность за пределами системы, которая взаимодействует с ней. На UML-диаграмме Use Case он изображается в виде человечка. Актору «Клиент» доступен основной вариант использования – «Оплатить договор» (на проведение обучающего курса по бизнес-анализу).  Расширением этого варианта использования является «Оплатить со скидкой по промокоду», который уменьшает сумму платежа. Этот вариант использования является опциональным и расширяет основной, поэтому он будет связан с основным через связь extend, которая выглядит как пунктирная стрелочка с соответствующей надписью.

Далее следует детализировать, как именно выполняется процесс оплаты, раскрыв прецедент со схемы Use Case на UML-диаграмме последовательности. Однако, чтобы сделать это с привязкой к внутренним сущностям нашей программной системы, классам, следует сперва описать их на UML-диаграмме классов. Как это сделать, мы рассмотрим далее.

Ликбез по ООП или как построить UML-диаграмму классов

UML соответствует объектно-ориентированной парадигме программирования (ООП), ключевым понятием которой является класс. Класс – это абстракция сущностей с одинаковыми свойствами (атрибутами, полями) и поведением (методами, функциями). Классы могут быть связаны друг с другом через наследование и ассоциации. При наследовании класс-потомки имеют (наследуют) атрибуты и методы класса-родителя, а также свои собственные. А конкретные значения этих атрибутов задаются в реализации классов в виде их отдельных экземпляров, называемых объектами. Например, ООО «Рога и Копыта» и Иванов Иван Иваныч – это конкретные реализации классов «Юрлицо» и «Физлицо» соответственно. В частности, у объекта класса Физлицо есть поля с паспортными данными (ФИО и № паспорта), а у юрлица обязательно должны быть название и ИНН. При этом оба этих класса наследуют от родителя (Класс «Клиент») общие для них атрибуты (тип, номер телефона, email и адрес).

Ассоциация означает логическую связь между объектами разных классов. Например, договор на обучение связан с курсом. Поскольку в договоре нужно обязательно указать курс, эти классы будут связаны не простой ассоциацией, а ее более сложным вариантом – агрегацией. В этом случае у класса, который является целым, появится значок в виде незакрашенного ромбика. Если связь между объектами разных классов настолько сильная, что при уничтожении целого, уничтожаются и его части, ромбик будет закрашенным. Такая связь называется композицией и является самым сильным вариантом ассоциации. Можно также указать кратность связи, к примеру, в 1-м договоре на обучение могут быть указаны сразу несколько курсов. При этом над концами связи отобразятся мультипликаторы, обозначающие ее кратность.

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

• Клиент – абстрактный класс-родитель для классов «Юрлицо» и «Физлицо»;
• Физлицо;
• Юрлицо;
• Договор;
• Курс;
• Промокод;
• Платеж.

Объекты разных классов могут взаимодействовать друг с другом через интерфейсы. В ООП интерфейс можно рассматривать как класс без атрибутов, но с методами, которые описывают поведение объекта класса, реализующего этот интерфейс, отвечая за предоставляемые функции. Это позволяет обеспечить один из ключевых принципов ООП – полиморфизм, чтобы унифицировать методы работы с разными объектами, вне зависимости от их типа и внутренней структуры. Например, класс «Промокод» предоставляет интерфейс «Управление промокодом», который используют объекты класса «Платеж». В результате, UML-диаграмма классов для нашего примера примет следующий вид.

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

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

А в заключение покажем, как выглядит жизненный цикл объектов класса «Промокод» с помощью UML-диаграммы состояний (StateChart или State Machine). На мой взгляд, из всех UML-диаграмм она самая простая и понятная без дополнительных объяснений. Начиная со стартового события, объект последовательно проходит разные стадии жизненного цикла, меняя свое состояние в зависимости от некоторых условий.

Как описать архитектурные аспекты проектируемой информационной системы с помощью UML, читайте в нашей новой статье.

Проверить свои знания UML вы можете прямо на нашем сайте, выполнив бесплатный интерактивный тест.

Открытый тест по UML: основы бизнес-анализа для начинающих

А научиться самостоятельно разрабатывать эти и другие UML-диаграммы вам поможет специализированный курс «UML для бизнес-аналитиков». Только практика на реальных примерах. После 8-часового интенсива вы сможете дополнять текстовые схемы представления требований User Story и Use Case UML-диаграммами вариантов использования и детализировать их далее в диаграммы деятельности, последовательности и состояний, чтобы наглядно объяснить разработчикам, что именно должна делать программная система.