Как составить диаграмму прецедентов

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

• Важность использования диаграммы прецедентов
• Объекты диаграммы прецедентов
• Рекомендации по диаграммам прецедентов
• Отношения в диаграммах вариантов использования
• Как создавать диаграммы вариантов использования ( с примером )
  • идентификация актеров
  • Определение вариантов использования
  • Когда использовать “Включить”
  • Как использовать обобщение
  • Когда использовать «Расширить»
• Шаблоны диаграмм вариантов использования для распространенных сценариев

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

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

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

Объекты диаграммы прецедентов

Использовать диаграммы корпуса состоят из 4 объектов.

• Актер
• Случай использования
• Система
• Пакет

Объекты более подробно описаны ниже.

Актер

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

Случай использования

Случай использования представляет собой функцию или действие внутри системы. Она нарисована как овал и названа функцией.

Система

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

Пакет

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

Рекомендации по диаграммам прецедентов

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

К ним относятся стандарты именования, направления стрелок, размещение вариантов использования, использование системных блоков, а также правильное использование отношений.

Мы подробно освещали эти рекомендации в отдельном посте блога. Так что продолжайте и ознакомьтесь с рекомендациями по диаграммам прецедентов.

Отношения в диаграммах вариантов использования

Существует пять типов отношений на диаграмме прецедентов. Они

• Ассоциация между актером и случаем использования
• Обобщение актера
• Расширить отношения между двумя случаями использования
• Включить взаимосвязь между двумя случаями использования
• Обобщение случая использования

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

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

До сих пор вы узнали об объектах, отношениях и руководствах, которые критичны при рисовании диаграмм с примерами из практики. Я объясню различные процессы на примере банковской системы.

Выявление актеров

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

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

Определение случаев использования

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

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

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

Ищите общие функциональные возможности для использования Включать

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

Возможно ли обобщение актеров и случаев использования

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

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

Необязательные функции или дополнительные функции

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

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

Шаблоны диаграмм прецедентов использования

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

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

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

Больше руководств по диаграммам

• Учебное пособие по диаграммам последовательностей: полное руководство с примерами
• Учебное пособие по моделированию бизнес-процессов (руководство по BPM с объяснением функций)
• Окончательное руководство по блок-схеме (полное руководство по блок-схеме с примерами)

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

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

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

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

---

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

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

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

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

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

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

Несколько слов о требованиях

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

Если обратиться к классикам, например, к той же «банде трех» (Якобсон, Буч, Рамбо), мы узнаем, что требование — это желаемая функциональность, свойство или поведение системы. Именно со сбора требований начинается процесс разработки ПО. Если изобразить процесс разработки ПО в виде » черного ящика » (уверены, читатель знает, что это такое, если нет — «Википедия» к вашим услугам), на выходе которого мы получаем программный продукт, то на вход этого «черного ящика» будет подаваться именно набор требований к программному продукту (рис. 6.1)!

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

Кстати, вернемся к требованиям. Да, мы сказали, что на вход нашего «черного ящика» подается набор требований. Но в какой форме? Как их документируют, эти требования? Думаю, большинство читателей помнит, что такое техническое задание — основной документ, без составления которого не начинался в советские времена ни один проект. Документ это был большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). И описывал он, по сути, не что иное, как требования к создаваемой системе!

Техническое задание — вещь по-своему хорошая. Но время шло, менялись стандарты, нотации, способы описания требований. И вот постепенно техническое задание уступило место набору артефактов, состоящему из документов двух видов:

• диаграммы прецедентов;
• нефункциональные требования.

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

Нефункциональные требования — это описание таких свойств системы, как особенности среды и реализации, производительность, расширяемость, надежность и т. д. Часто нефункциональные требования не привязаны к конкретному варианту использования и потому выносятся в отдельный список дополнительных требований к системе (рис. 6.2).

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

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

Подобный вид деятельности обычно выполняется в такой последовательности:

1. Определение действующих лиц.
2. Определение прецедентов.
3. Составление описания каждого прецедента.
4. Описание модели прецедентов в целом (этот этап включает в себя создание словаря предметной области).

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

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

Думаем, здесь все понятно. Таблица с описанием требований может быть, например, такой:

Здесь нигде не сказано о том, что система должна быть написана на ASP.NET. Почему — понятно: это ведь нефункциональное требование! И еще, очевидно, что секретарь и офис-менеджер тоже являются сотрудниками. Читатель, внимательно прочитавший предыдущие лекции, заподозрит, что в данном случае, создавая модель прецедентов, говоря о действующих лицах, можно бы применить генерализацию. Действительно, диаграмма прецедентов, построенная на основе этой таблицы, может быть, например, такой (рис. 6.3):

Для чего используется техника креативности

Определить функциональные требования к системе.

Описать типичные взаимодействия между пользователями системы и самой системой и предоставить описание процесса её функционирования.

План действий

В разделе «Описание» изучите основной набор символов диаграммы прецедентов, необходимый для того, чтобы уметь читать диаграммы.

После ознакомления с другими разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм прецедентов.

Замечания (описание)

Здесь представлен основной набор символов диаграммы вариантов использования (прецедентов) , необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы вариантов использования системы (ВИС) самостоятельно!

Термин	Изображение	Описание
Сценарий	Вся диаграмма вариантов использования (ВИС)	Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы.
Актер		Актер (actor) представляет собой некую роль, которую пользователь играет по отношению к системе.
Прецедент		Обозначает выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам.
include (включает)		Сложный шаг в прецеденте можно представить другим прецедентом. В терминах языка UML мы говорим, что первый прецедент включает (includes) второй.
Граница системы		Позволяет обозначить границы систем или подсистем.

Как применять технику креативности

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

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

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

Как научиться

Пример использования

Прецеденты – это технология определения функциональных требований к системе. Работа прецедентов заключается в описании типичных взаимодействий между пользователями системы и самой системой и предоставлении описания процесса ее функционирования. Вместо того чтобы описывать прецеденты в лоб, я предпочитаю подкрасться к ним сзади и начать с описания сценариев. Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы. Поэтому при наличии онлайнового магазина, основанного на веб-сайте, мы можем использовать сценарий «Покупка товара» (Buy a Product), в котором происходит следующее.

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

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

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

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

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

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

Содержимое прецедентов

Не существует стандартного способа описания содержимого прецедента; в разных случаях применяются различные форматы. На рис. 9.1 показан общий стиль использования. Вы начинаете с выбора одного из сценариев в качестве главного успешного сценария (main success scenario). Сначала вы описываете тело прецедента, в котором главный успешный сценарий представлен последовательностью нумерованных шагов. Затем берете другой сценарий и вставляете его в виде расширения (extension), описывая его в терминах изменений главного успешного сценария. Расширения могут быть успешными – пользователь достиг своей цели, как в варианте 3a, или неудачными, как в варианте 6a.

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

Каждый шаг в прецеденте – это элемент взаимодействия актера с системой. Каждый шаг должен быть простым утверждением и должен четко указывать, кто выполняет этот шаг. Шаг должен показывать намерение актера, а не механику его действий. Следовательно, в прецеденте интерфейс актера не описывается. Действительно, составление прецедента обычно предшествует разработке интерфейса пользователя.

Расширение внутри прецедента указывает условие, которое приводит к взаимодействиям, отличным от описанных в главном успешном сценарии (main success scenario, MSS), и устанавливает, в чем состоят эти отличия. Расширение начинается с имени шага, на котором определяется это условие, и предоставляет краткое описание этого условия.
Следуйте этому условию, нумеруя шаги таким же образом, что и в главном успешном сценарии. Заканчивайте эти шаги описанием точки возврата в главный успешный сценарий, если это необходимо.

Структура прецедента – это отличный инструмент для поиска альтернатив главного успешного сценария. На каждом шаге спрашивайте:
«Что может еще произойти?» и в частности «Что может пойти не так?»

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

Сложный шаг в прецеденте можно представить другим прецедентом. В терминах языка UML мы говорим, что первый прецедент включает (includes) второй. Не существует стандартного способа показать в тексте включение прецедента, но я думаю, что подчеркивание, которое предполагает гиперссылку, работает прекрасно, а во многих инструментах действительно будет гиперссылкой. Так, на рис. 9.1 первый шаг включает шаблон «просматривает каталог и выбирает товары для покупки».

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

Наряду с шагами сценария можно вставить в прецедент дополнительную общую информацию.
• Предусловие (pre-condition) описывает действия, обязательно выполняемые системой перед тем, как она разрешит начать работу прецедента. Это полезная информация, позволяющая разработчикам не проверять некоторые условия в их программе.
• Гарантия (guarantee) описывает обязательные действия системы по окончании работы шаблона ответа. Успешные гарантии выполняются после успешного сценария; минимальные гарантии выполняются после любого сценария.
• Триггер (trigger) определяет событие, инициирующее выполнение прецедента.

При рассмотрении дополнительных элементов относитесь к этому скептически. Лучше сделать слишком мало, чем слишком много. Кроме того, приложите максимум усилий, чтобы сделать прецедент кратким и легким для чтения. Я убедился, что излишне подробный прецедент, который трудно читать, скорее приведет к провалу, чем к достижению цели. Не обязательно записывать все детали; устное общение часто бывает очень эффективным, особенно во время итеративного цикла, когда необходимые условия быстро выполняются запущенной программой.
Степень детализации, необходимая в прецеденте, зависит от уровня риска этого прецедента. Часто детали нужны в начале только немногих ключевых прецедентов, другие можно конкретизировать непосредственно перед их реализацией.

Диаграммы прецедентов

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

Лучше всего обдумывать диаграмму прецедентов с помощью графической таблицы, показывающей их содержимое. Она напоминает диаграмму контекста, используемую в структурных методах, поскольку она показывает границы системы и ее взаимодействие с внешним миром. Диаграмма прецедентов показывает актеров, прецеденты и отношения между ними:
• Какие актеры выполняют тот или иной прецедент
• Какие прецеденты включают другие прецеденты
В языке UML помимо отношения «include» (включает) есть и другие типы отношений между прецедентами, например отношение «extend» (расширяет). Настоятельно рекомендуем его избегать. Слишком часто разработчики целыми командами надолго погружались в рассмотрение различных отношений между прецедентами, понапрасну растрачивая силы. Лучше уделяйте больше внимания текстовому описанию прецедента; именно в этом заключается истинная ценность этой технологии.

Прецеденты и возможности (или пожелания)

Во многих подходах возможности системы применяются для описания требований к системе; в экстремальном программировании (Extreme Programming) возможности системы называются пожеланиями пользователя. Общим является вопрос о том, как установить соответствие между возможностями и прецедентами.

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

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

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс «Как зарабатывать на фрилансе».

Перейти на страницу курса