- Что такое use case диаграмма
- Из чего она состоит
- Кто такой Актор в UML
- Use case, Ассоциация и Boundary
- Связи между ними
- Пример простой диаграммы прецедентов
«Данная статья посвящена диаграмме прецедентов, чаще называемой диаграммой use-кейсов, или диаграммой вариантов использования. Это одно из важных понятий, которые необходимо освоить при изучении объектно-ориентированного программирования (ООП). В схемах (собственно, диаграммах) в данном случае использовался Astah UML, инструмент проектирования, поддерживающий UML. Чтобы освоить данный туториал, желательно скачать Astah здесь и ознакомиться (платный, но есть 20-дневный триал, чего должно быть достаточно), а также научиться им пользоваться, посмотрев документацию.
Что такое use case диаграмма
В объектно-ориентированной парадигме, когда речь идет о проектировании системы, удобно описывать дизайн с помощью Унифицированного Языка Моделирования (Unified Modeling Language, UML). UML-диаграмма use-кейсов применяется для краткого изложения сведений о пользователях проектируемой системы и их взаимодействии с ней.
В чем заключается взаимодействие пользователя с системой, каким оно может быть? Предположим, что создается приложение книжного интернет-магазина. В этом случае взаимодействия — это те действия, которые пользователи могут выполнять с помощью вашего приложения, например:
- Просмотр книг
- Покупка книг
- Добавление книг в корзину
Можно еще добавить много возможных взаимодействий, но основные будут эти.
Итак, демонстрировать взаимодействие системы с пользователем удобно в наглядном, графическом виде, с помощью диаграмм.
Из чего составляется диаграмма use-кейсов?
Из следующих компонентов:
- Актер (Actor)
- Собственно use-кейсы
- Ассоциации между ними
- Границы системы (Boundaries), и
- Отношения (Relationships или связи)
Актор в UML
Актор в терминологии UML-диаграмм — это пользователь, взаимодействующий с системой (действующее лицо). Это может быть человек, организация или даже сервер/система.
Чтобы идентифицировать актора, необходимо ответить на простой вопрос: «Кто будет взаимодействовать с приложением?»
Допустим, нужно создать сайт магазина. Кто будет актором?
- Пользователь, и
- Администратор
В диаграммах use-кейсов актор обычно изображается в виде человечка, но может быть изображен и как на рисунке:
И называться в принципе как угодно, лишь бы было понятно стейкхолдерам и команде.
О use-кейсах, ассоциациях и границах системы
Эти понятия довольно просты, поэтому можно просто привести эти понятия и их обозначения на диаграмме:
- Use кейсы: широкие овалы, изображающие различные варианты использования, по которым может «проходить» пользователь.
- Ассоциация: линия, соединяющая («ассоциирующая») акторов и их use-кейсы. В сложных диаграммах важно четко знать, какие акторы связаны с какими use-кейсами.
- Границы системы: граница, задающая пределы системы для use кейсов. Все use кейсы, выходящие за пределы этой границы, будут считаться выходящими за пределы данной системы.
Например: клиент банка может видеть только свои транзакции, а не все проведенные транзакции в системе, поскольку такой use кейс выходит за границы системы.
В целом, несмотря на кажущуюся сложность для новичков, на практике работать с UML-диаграммами довольно просто. Единственная сложная вещь в UML-диаграммах — это отношения между элементами (Relationships). О них и поговорим.
Отношения в UML-диаграммах
Итак, Relationships, называемые еще связями. Существует 3 типа отношений:
- Включение (Include)
- Расширение (Extend)
- Обобщение (Generalization)
Отношение включения
Отношение включения — обязательная, неотъемлемая связь (отношение) между use кейсами.
Представим это так: например вы голодны и хотите зайти куда-то перекусить. Вы заходите во Вкусно и Точка и говорите: «Я хочу заказать еду». Но что нужно сделать перед этим? Конечно, сначала нужно выбрать еду. Пример диаграммы:
Это и есть отношение включения. Только когда вы сделаете выбор, можно переходить к оплате. Поэтому в диаграмму выше уже был добавлен еще один use кейс с включением — «Оплатить еду».
Отношение расширения
Как уже сказано, include — обязательная связь между use-кейсами. А расширение (extend) является необязательным. Это означает, что если use кейс не является обязательным, то актор может выбирать; если у актора есть выбор, то это уже отношение extend.
Итак, вернемся к примеру с заведением быстрого питания. Когда оплачиваете еду, у вас появляются варианты действий: можете дать официанту чаевые, а можете и не дать. В нашей диаграмме прецедентов это отобразится следующим образом:
Просто запомним: Отношение “Include” — обязательное, а “Extend” — опциональное.
Отношение обобщения
Обобщение (генерализация, generalization) — это, по сути, демонстрация отношений типа «порождающая сущность / порожденная сущность» (parent/child), между use кейсами или акторами.
Например, обобщение use кейсов:
- Логин (parent) -> Вход с помощью телефона/электропочты (child)
- Оплата (parent) -> Оплатить с помощью Сбербанка / Наличкой (child)
Отношения обобщения акторов:
- Менеджер -> Персонал
- Оптовики -> Ритейлеры
Отношение обобщения в ИТ-системе заведения быстрого питания:
Обобщение помогает более четко изобразить диаграмму use кейсов.
При изучении объектно-ориентированного программирования (ООП), легко понять, что обобщение наследуется (наследование в объектно-ориентированной парадигме), то есть дочерняя структура «наследует» свойства и отношения родительской структуры других use кейсов.
Пример диаграммы прецедентов
Разумеется, выше показаны самые простые диаграммы прецедентов. Если вы учили программирование в школе, то наверное уже приходилось рисовать подобные диаграммы и вы должны их помнить. Например мне в свое время пришлось рисовать такую:
