UML: Use Case Diagram

Познав, что такое UML и каким он бывает, двинемся к конкретным диаграммам, и с позиции аналитика первое, что приходит на ум — это диаграмма вариантов использования (Use Case Diagram).

Основные обозначения в заметке:
Голубой цвет — то, что не продиктовано UML, а взято как полезный совет/правило из иных теорий и практик (например, по ”классике” теории юз кейсов).
Курсив — примеры.

Use Case Diagram, если применять по прямому назначению, описывает, что можно сделать с решением, в терминах актеров и выполняемых ими вариантов использования.

Когда применять:

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

Согласовать скоуп с заказчиком/пользователями
Донести скоуп команде
Систематизировать скоуп для себя и коллег-аналитиков

Даже если скоуп в юз кейсах (вариантах использования (ВИ), если прямо уж красиво) и сами юз кейсы не особо отзываются, взгляд на систему со стороны пользователя — полезная штука (читаем тут и тут, какие кайфы это может привнести в вашу жизнь). User stories лишь ограниченно подходят для подобной задачи, так как не все истории — это ответ на вопрос “что ценного я могу сделать с системой” (они зачастую “мельче”, чем юз кейсы, и могут описывать, например, один редкий и необычный сценарий отдельного юз кейса).

Элементы:

Aктер (Actor) — это актеры для ваших юз кейсов. Показываются фигуркой человечка. Актер — это тот человек, организация, роль или нежить (софт или устройство, например), которые взаимодействуют с решением и получают ценность от выполнения ВИ (что в большинстве случаев можно трактовать как “выполняют ВИ” — UML все же допускает, что юз кейс может быть инициирован и не актером, но последний от этого тем, кто получает от юз кейса счастье, быть не перестает).

Актеры должны быть внешними по отношению к системе, варианты использования которой мы рассматриваем. Осознайте следующую конструкцию: есть целевая система, которую мы моделируем; есть варианты ее использования (что с ней можно сделать), а есть актеры, которые ее используют — логично, что они находятся вне этой системы. Но: если сильно хочется, можно показать и юз кейсы, которые выполняет сама система (очевидно, что это не внешний актер, а потому формально этим самым мы нарушаем заповеди UML): например, система просыпается раз в день и отправляет запрос на импорт данных в сторонний сервис. Просто имейте в виду, что в глазах пуристов вы таким подходом совершаете грех.
Актеров можно делить на первичных и вторичных. В этой парадигме актёры, которых мы описывали до этого, — это как раз первичные. Вторичные актеры — это те, кто участвует каким-то образом в выполнении ВИ (в отличие от тех, кто его выполняет/получает ключевую ценность). Советую этим пользоваться. Различить их визуально можно только связями к ним / от них, а потому расскажу об этом ниже.

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

Полезная: пришёл -> сделал -> ушёл с чувством выполненного долга. В этих рамках “Войти в систему”, например, нельзя трактовать как юз кейс. Будут исключения из этого правила, и о них поговорим ниже.
Сформулированная как единичная/разовая: “Создать пользователя”, а не “Управление пользователями” как непонятная абстракция.
Сформулированная в виде глагола (с возможными пояснениями — например, указанием на объект действия) — см. пример в предыдущем пункте.

Связи:

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

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

Ряд людей на этом заканчивают освоение Use Case Diagram, но я не вижу в этом смысла: если мы построим так называемую “ромашку” (актеры, их юз кейсы и ассоциации между первыми и вторыми), то на кой вообще это нужно? Что добавила эта мегавизуализация в сравнении с вариантом, если бы мы просто списком перечислили ВИ рядом с актерами? Поэтому я предлагаю на этом не останавливаться и рассмотреть, какие еще полезные смыслы можно заложить в диаграмму.

Включение (Include) — отношение между вариантами использования, показывающее, что один юз кейс полностью и обязательно включает в себя другой юз кейс. Штриховая линия с открытой стрелкой на конце и стереотипом include. Направление идет по чтению (А включает Б).

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

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

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

Расширение (Extend) — отношение между вариантами использования, показывающее, один юз кейс может расширять собой другой (= быть опциональным дополнением к нему). Штриховая линия с открытой стрелкой на конце и стереотипом extend. Т. к. многие путаются в направлении стрелок, обратите внимание: в этом случае направление может нарушать вашу дефолтную логику — стрелка идет от “вторичного” юз кейса к “основному”.

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

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

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

Полезно знать:

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

Давайте несложный айтишный пример наколбасим.

Допустим, у нас есть система видеохостинга — сильно покоцанный и местами неудобный аналог YouTube. Что в нем есть:

Регистрация и вход/выход
Просмотр (через ленту на домашней странице) и заливка видосиков
Комментирование и модерирование комментов
Добавление видосиков в плейлист Watch Later

Вот так это можно отразить на диаграмме:

Чем руководствовались в ряде моментов:

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

Описанного выше вполне хватит, чтобы рисовать классные диаграммы и не париться. Для тех же, кто хочет больше знать/уметь — чуть более продвинутые практики:

Subject (иногда называют Boundary) — элемент, группирующий юз кейсы по какому-либо признаку (в UML применимость этого элемента несколько более узка, но смысла в этих ограничениях для аналитика не вижу, поэтому обобщим до “любого признака”). Показывается прямоугольником.

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

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

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

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

Примеры цепочек обобщения/наследования от родителей к потомкам:

Транспортное средство -> Автомобиль -> Легковой автомобиль -> Седан

Аппаратное устройство -> Вычислительное устройство -> Ноутбук -> Игровой ноутбук

Для проверки того, верно ли вы используете в смысловом плане связь, можно формулировать это так: наследник Б — это родитель А с дополнительной спецификой (прояснением) X.

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

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

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

Расширим наш айтишный пример, добавив туда а) разные типы пользователей, как описано в п. 1 выше, и б) вариации создания видео, чтобы показать описанное в п. 2.

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

Что дал пункт б): мы добавили два подвида создания видео — заливку вручную и импорт из YouTube (c участием YouTube, вестимо).

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

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

Абстрактные юз кейсы — как и в предыдущем случае, полезная эта штука, скорее, для умения правильно читать подобные ситуации на диаграммах. Все примеры юз кейсов, рассмотренные выше, — не-абстрактные (или “конкретные”, если устраивает такой термин). У абстрактных юз кейсов (и не только юз кейсов — это применимо для большинства UML-элементов на разных диаграммах) название элемента пишется курсивом. Что это означает: абстрактный элемент не является “реальным”, и нужен он лишь для каких-то побочных целей. В случае с юз кейсами это означает, что абстрактный юз кейс не будет выполним ни одним актером. Возникает тогда вопрос, а нафига он нужен? Типовым вариантов применения абстрактных юз кейсов является использование их в комбинации с обобщением между юз кейсами. Т. е. правильнее кусок из примера выше должен выглядеть так:

Читается это так: создание видео может протекать только в виде заливки вручную или импорта из YouTube. Несмотря на то, что на диаграмме 3 овала, реальных, выполнимых юзером ВИ тут только 2. Создать видосик — это не третья опция создания видео, а абстракция для двух других “реальных” юз кейсов.

Еще один кейс использования абстрактных ВИ и обобщения (технически напоминающий предыдущий, но немного иной по смыслу) — группировка юз кейсов в более высокоуровневые контейнеры. Например, так:

Note (Заметка) — не то, чтобы это прямо advanced уровень, но полезно знать, что любые ваши пояснения лучше обозначать способом, диктуемым правилами UML:

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

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

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

Отображение в направленных ассоциациях семантики "кто к кому обращается" или "куда летят данные", а не первичности/вторичности актеров.

Как использовать направления ассоциаций при наличии актеров разных видов: от первичного актера — к юз кейсу; от юз кейса — ко вторичному актеру.

Использование extend не в контексте "могу сделать в процессе", а дабы показать временнУю последовательность юз кейсов.

На диаграмме выше Выход не может расширять Вход. Делая так, вы формулируете следующее: я как аналитик предлагаю заложить в систему, что в процессе каждого входа, который пользователь может совершать, у него будет логичная предлагаемая системой возможность выхода. Это не так. От шага "Открыть страницу входа" до постусловия "Актер аутентифицирован и находится на домашней странице" актеру не будет предлагаться возможность выхода — это совершенно иная операция. То, что показано — Вход является предусловием для того, чтобы можно было начать Выход. Предусловия на диаграмме не показываются — они отражаются в детализации ВИ (но если сильно хочется и жжется, добавьте новую связь со стереотипом, например <<precede>>).

Неверное направление обобщения: от родителя к потомку.

Обобщение рисуется от потомка к родителю и читается (подсказка: всегда удобнее понимать или называть связи так, как вы будете читать их в ногу с направлением) как "обобщается в", "абстрагируется в".

Неверное понимание сути обобщения.

В чем ошибка в примере? Логика, казалось бы, верная: юзер с ролью CommonUser может делать чуть больше, чем неаутентифицированный юзер, а с ролью Admin — больше, чем CommonUser. Но давайте вспомним фразу, которую стоит применять при осмыслении использования этой связи: наследник Б — это родитель А с дополнительной спецификой X.
То есть: юзер с ролью CommonUser — это неаутентифицированный юзер с доп. деталями, а Admin — это юзер с ролью CommonUser и доп. деталями? Если вчитаться, то не очень похоже не правду. Юзер с любой ролью — это юзер, уже прошедший аутентификацию. А Admin (если, конечно, предположить, что роли взаимоисключающи, т. е. любой юзер может иметь только одну из этих двух ролей) не может быть юзером с ролью CommonUser.
Правильным вариантом было бы добавить сюда дополнительных актеров, чтобы выстроить правильную цепочку обобщения: Пользователя в целом (как абстракцию аутентифицированного и нет) и Аутентифицированного Пользователя (как абстракцию юзеров с ролями CommonUser и Admin).