10 советов по созданию профессиональной диаграммы вариантов использования

Существует два распространенных заблуждения относительно моделирования вариантов использования:

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

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

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

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

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

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

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

Диаграмма вариантов использования обычно проста. Она не показывает детали вариантов использования:

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

Use Case Diagram Template | Use Case Diagram Template

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

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

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

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

10 практических советов по моделированию вариантов использования

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

1. Думайте с точки зрения конечного пользователя

Ясно, что необходимо знать ожидания пользователей, чтобы создать работающую программную систему, и этот принцип особенно важен при моделировании вариантов использования. Многие люди ошибочно считают, что моделирование вариантов использования — это процесс моделирования функций системы, что может быть неверно. Точнее сказать, моделирование вариантов использования — это способ моделирования того, чего хотят пользователи. Каждый вариант использования на диаграмме должен приводить к наблюдаемой цели через взаимодействие пользователя с конечным программным продуктом или системой. Иногда цель пользователя совпадает с функцией системы, но это не всегда так. Например, «Вход в систему» — это функция системы, но это, безусловно, не цель пользователя — никто не запускает программу, заходит и уходит! Поэтому, чем больше функций системы вы включаете в диаграмму вариантов использования, тем менее эффективным становится модель вариантов использования для выражения реальных ожиданий пользователей на протяжении всего процесса разработки программного обеспечения. Следовательно, при разработке модели вариантов использования попробуйте выразить всё, сначала думая с точки зрения конечного пользователя.

2. Избегайте длинных названий вариантов использования

Если вы читаете диаграмму вариантов использования, подготовленную для системы банкомата, какой из следующих вариантов использования вы хотите увидеть на диаграмме? «Снять наличные» и «Снять наличные и обновить баланс на счете». Второй вариант использования кажется более описательным, верно? А что, если у вас будет более 50 различных вариантов использования с таким длинным названием? Вы, вероятно, больше не захотите читать диаграмму, и, возможно, у вас начнёт болеть глаза.

Use cases with short names

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

Одной из причин, по которой нам нужно моделирование, является желание понять сложную программную систему простым и понятным способом. Именно поэтому UML предоставил нам множество различных нотаций, каждая из которых представляет определенную перспективу при описании полной программной системы. Этот «дух» применим и к именованию вариантов использования. Если мы пытаемся давать вариантам использования подробные названия, зачем тогда не использовать текстовый файл? Чтобы диаграмма вариантов использования была понятной, важно, чтобы названия вариантов использования были короткими, но при этом информативными. Держите названия короткими, а подробное описание оставьте в разделе описания вариантов использования.

3. Актер — это роль, а не реальный человек

Actor is a role

Актер — это роль

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

4. Моделирование общего варианта использования с помощью связи

The Include relationship

Связь включения

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

5. Моделирование исключительного поведения

The Extend relationship

Связь расширения

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

6. Моделирование сценария с потоком событий

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

Use case flow of events

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

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

7. Правильно используйте стереотипы для категоризации

Use cases with stereotype applied

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

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

8. Моделирование детального потока системы с помощью диаграммы последовательности

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

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

9. Применяйте одинаковую ширину к вариантам использования при необходимости

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

10. Располагайте актеров и варианты использования осмысленно

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

Ссылки:

Leave a Reply