Диаграмма использования
Диаграмма использования
Заголовок раздела «Диаграмма использования»Диаграмма использования работает прежде всего с функциональными требованиями. Нефункциональные требования важны для системы, но обычно отражаются в других артефактах и диаграммах.
Все способы выявления требований на выходе оставляют их список в каком-то виде. Обычно это текстовые заметки, в идеале структурированные. Зачем нам нужно эти заметки оформлять в виде чего-то в нотации UML:
- Для диаграмм не годятся длинные предложения, и мы их сокращаем и разбиваем на более короткие предложения определённой структуры, это позволяет в случае необходимости разбить большое требование на более мелкие и чёткие;
- Мы абстрагируемся от всего, кроме самих требований: наша задача — описать только то, что должна предоставлять система с точки зрения функциональности, но не способ реализации;
- Декларативное описание: мы перечисляем требования, но не задаём их иерархию, порядок реализации и пр.;
- Выявление границ системы: всё ли учтено, нет ли лишнего или пропущенного, как система взаимодействует с внешним миром.
Всё это реализовано в диаграмме использования. Формально на диаграмме использования применяются следующие элементы:
4 типа сущностей:
- Действующее лицо (actor);
- Вариант использования (use case);
- Примечание (note);
- Пакет (package).
3 типа отношений:
- Ассоциация (association);
- Обобщение (generalization);
- Зависимость (dependency).
В самом простом случае можно обойтись без примечаний и пакетов (но лучше с пакетами).
Рассмотрим подробнее сущности и отношения с точки зрения как UML, так и здравого смысла.
Действующее лицо
Заголовок раздела «Действующее лицо»Роль здесь — это взаимосвязь действующего лица с вариантами использования, которые с ним связаны.
Как правило, действующие лица выделяются в процессе формирования требований и не появляются из воздуха. Если требования уже были сформированы кем-то другим, то в них обычно указывается, какие есть действующие лица. Если же ни того, ни другого не было, то быстрый способ попробовать выделить действующих лиц — пробежаться по списку требований и посмотреть, какие роли там могут “скрываться”.
Действующее лицо
Отдельно стоит упомянуть, как именно нужно именовать сущности (это называется дисциплиной имён). Обычно имена действующих лиц — это существительное с определением, а имена вариантов использования — глагол (обычно с дополнением). На используемый язык ограничений нет, но часто это английский язык.
Вариант использования
Заголовок раздела «Вариант использования»Если требования выделяются в идеальном мире, то все варианты использования очевидны из этих требований. С другой стороны обычно техзадание — это смесь пожеланий заказчика, смутных формулировок и конкретных пунктов, в таком случае можно попробовать выделить глаголы с дополнениями или отглагольные существительные, они вполне могут быть кандидатами для выделения в вариант использования.
Вариант использования
Естественно, можно уточнять детали у заказчика (или другого автора техзадания) и добавлять новые варианты использования.
Отношения
Заголовок раздела «Отношения»Как было упомянуто ранее, на диаграмме использования выделяются три типа отношений: ассоциация, обобщение и зависимость.
Ассоциация всегда показывает отношение между действующим лицом и вариантом использования. По сути, это основное отношение на этой диаграмме, которая показывает, кто где участвует. Если какое-то действующее лицо или вариант использования остались без ассоциации, то стоит задуматься об их целесообразности.
Пример ассоциации
Обобщение между действующими лицами показывает, что одно действующее лицо наследует все свойства (в частности, участие в ассоциациях) другого действующего лица. Такое обобщение показывает иерархию категорий пользователей, в том числе прав доступа. Например, разумно предположить, что администратор службы поддержки может выступать и оператором.
Пример обобщения
Ещё одна польза обобщения — обобщение с использованием абстрактных действующих лиц. В контексте диаграммы использования абстрактное действующее лицо в итоге не будет использовать систему, а абстрактный вариант использования не будет реализован сам по себе.
Отсюда же видно, что обобщение может быть не только между лицами, но и между вариантами использования, это показывает, что один вариант является частным случаем другого.
Между вариантами использования есть два специальных направленных отношения, которые визуально похожи на зависимость:
«include»— показывает, что поведение включённого варианта использования вставляется в базовый вариант использования. Стрелка направлена от базового варианта использования к включённому.
Пример зависимости типа «include»
«extend»— показывает, что расширяющий вариант использования может добавить поведение к расширяемому варианту использования при выполнении условия и в определённой точке расширения. Стрелка направлена от расширяющего варианта к расширяемому.
Пример зависимости типа «extend»
Если говорить совсем формально, то include и extend — это отдельные типы отношений use case model, а не просто произвольные стереотипы зависимости. Визуально они похожи на зависимость, поэтому в учебных материалах их часто объясняют рядом с зависимостями.
Граница системы
Заголовок раздела «Граница системы»Для более чёткого разделения системы (или нескольких подсистем) от действующих лиц используется граница системы. С логической точки зрения это что-то, что подлежит анализу и рассмотрению и к чему можно отнести варианты использования.
Формально граница системы представляет собой ещё один классификатор, который, однако, не выделяется отдельно в иерархии сущностей. Границей системы может выступать и класс, и компонент, но чаще всего используется отдельный стереотип «system», «subsystem» или «service».
Пример применения границы системы