Use case ошибки

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

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

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

Вот такая задача. Теперь рассмотрим, для чего мы здесь будем использовать Use Case диаграмму. Когда мы разрабатываем программную систему важно понимать, для кого мы ее делаем. Да, программная система призвана решать проблемы заинтересованных лиц, однако все же с программой будет работать конкретный пользователь, и именно для пользователя мы разрабатываем ее, именно с точки зрения пользователя мы будем формировать список функций нашей системы. Отсюда следует, что Use Case диаграмма как раз и создается с точки зрения пользователей системы. При этом нужно иметь в виду, что пользователь не является частью системы, а лишь с ней взаимодействует – он активно «давит» на кнопки панели инструментов, всячески инициирует работу тех или иных функций программы. Он является первичным (активным) актором, который на диаграмме принято изображать слева. С другой стороны, наша система взаимодействует по принципу «клиент-сервер» с другими системами – серверами баз данных, различными веб-сервисами и т.д. Такие системы являются вторичными (пассивными) акторами и взаимодействуют с нашей системой, только если от нее придет запрос. Давайте посмотрим, что показано на вот этой диаграмме.

Здесь мы видим, что часть пользователей нашей системы обозначены как вторичные акторы (те, что справа) . Об этом говорит сайт https://intellect.icu . Фактически данная диаграмма читается как то, что пользователей подключили проводами к компьютеру и переодически бъют током, чтобы вызвать у него ответную реакцию на это событие . Это первая ошибка.

Вторая ошибка состоит в том, что здесь мы видим Use Case «Носить браслет». Это функция пользователя, которая вообще не имеет отношение к нашей системе, а как мы уже договорились, пользователь не является частью создаваемой нами системы. Поэтому данный Use Case из этой диаграммы следует удалить.

Третья ошибка на данной диаграмме состоит в наличии так называемых «подвисших Use Case». Ранее мы обсуждали, что функции системы инициируются пользователем. На этой диаграмме мы видим Use Case «Фиксировать прохождение КС» и «Отображение карты местности». Кто иницирует эти функции? Вторичный актор не может этого делать, исходя из того что он сам работает по запросу из нашей системы.
Теперь я хочу обратить ваше внимание на другую интересную ошибку. Посмотрим диаграмму Use Case другого автора этой же задачи:

Здесь мы видим довольно странного актора «System». Очень сложно понять, что он будет делать. Судя по всему, разработчик этой диаграммы имел в виду ту самую систему, которую мы же и разрабатываем. Но рекурсия здесь не работает – система не может являться актором самому себе, исходя из определения актора, а все Use Case, которые мы указываем на диаграмме, имеют отношение именно к нашей системе. Таким образом, когда мы указываем актора, мы должны четко понимать, для чего он здесь, зачем он взаимодействует с нашей системой или зачем мы взаимодействуем с ним. Кстати, здесь же мы опять видим ранее рассмотренную ошибку о «подвисшем Use Case».

Диаграмма Use Case призвана показать, какие функции она предоставляет пользователю, но она не призвана показать, как эти функции выполняет система. В связи с этим весьма распространенной ошибкой является попытка показать на диаграмме Use Case, как будут выполняться те или иные функции. Для показа «как система будет выполнять функции» существуют другие UML диаграммы. Посмотрим пример такой диаграммы:

Use Case «Input data about spertsman» (сохранено оригинальное название, данное автором этой диаграммы) говорит о том, что здесь мы будем вводить данные о спортсмене. Здесь этой информации, что мы просто вводим данные, достаточно. А какие это данные, мы узнаем из модели предметной области, где уже на диаграмме классов отражаются атрибуты спортсмена. Но здесь это просто не нужно делать. Кроме того, заказчик изменит требования, внесет еще какие-то характеристики спортсмена, которые ему важны, и из-за этого нам перестраивать диаграмму? Поэтому на диаграмме Use Case мы показываем лишь «что система будет делать для пользователя», а не «как она это будет делать».

И в конце самая «вкусная» ошибка этой задачи. Является ли браслет актором? Проанализируем вот эту диаграмму:

Обратите внимание на Use Case «Pass the chekpoint». Мы видим, что его инициируют два первичных актора «Runner» (т.е. спортсмен) и «Bracelet». Если с первым все понятно и логично, то почему браслет, который надет на спортсмене, выступает в качестве самостоятельного актора? Чтобы понять, кем здесь является браслет, достаточно сказать, что на диаграммах Use Case связь между актором и Use Case (в миру UML называемая ассоциацией) по сути означает интерфейс пользователя, когда мы говорим о первичном акторе, и интерфейс к внешней системе, когда мы говорим о вторичном акторе. Мы все привыкли, что интерфейс пользователя – это исключительно UI. А в этой задаче для спортсмена UI нет – для него есть контрольная станция, интерфейсом для которой и является его браслет. Таким образом, если мы убираем с этой диаграммы актора «Bracelet», то все встает на свои места.

Мы рассмотрели часто встречающиеся ошибки. Готов обсудить ваше решение этой задачи в комментариях.

Еще тогда предложу к обсуждению такой экземпляр

Если роли Ученик и Родитель ничем не различаются, то зачем делать из одной роли три?
(На самом деле они, наверное, различаются, и диаграмма нужна как раз для того, чтобы показать это различие).

И снова «посмотреть профиль ученика» imho совершенно ненужный юзкейс. Да ещё сбивающий с толку (обычно под профилем понимаются настройки).

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

Гриша, ты считаешь, что этого достаточно для аргументирования проблемы?

Нет, это же было только вступление.

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

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

О чем речь? Use Сase – это сценарий, который описывает взаимоотношения участников внутри какой-либо системы. Например, это может быть взаимодействие двух людей (при продаже или покупке) или человека с программой.

На что обратить внимание? Use Case используются в различных сферах: от разработки ПО до формирования бизнес-процессов. Главные требования – ясность и лаконичность, ведь от этого зависит, поймут ли его в принципе.

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

Если говорить обобщенно, то Use Case – это сценарий, описывающий взаимодействие нескольких участников, происходящее с определенной целью, например:

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

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

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

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

Когда необходим Use Case

Кому нужны сценарии Use Case:

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

Скачать
файл

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

Случаи, в которых могут быть использованы сценарии Use Case:

• Для создания качественной спецификации требований системы. При их разработке и применяется также описание интерфейса программы, и возможность ее интеграции с другими.
• При осуществлении технической поддержки. В таком случае UseCase помогает выявить ошибку и определить, на каком этапе она произошла.
• Если требуется дать описание лишь части функциональности системы, взаимодействия пользователя и программой. Здесь на выручку приходит шаблон UseCase, на основе которого и создается сценарий. Допустим, что в основе мобильного приложения лежит описание пользовательского интерфейса. Но не учтен ряд функций, выполнение которых требует создания дополнительных сценариев с использованием таблички: «Действие пользователя – отклик системы» или их совмещения.

Правила написания Use Case

Количество элементов Use Case может меняться в зависимости от степени сложности сценария. Но, как правило, их набор всегда стандартен:

• Актор (actor), то есть пользователь. Например, в магазине онлайн в качестве акторов выступают и продавцы, и покупатели, а также компании, осуществляющие доставку товара или обеспечивающие поступление платежей.
• Стейкхолдер (stakeholder) – это лицо, заинтересованное в получении выгоды от работы сценария. Если продолжить рассматривать пример онлайн-магазина, то в данном случае Стейкхолдером может являться платежная система.
• Primary actor, или первичное действующее лицо. Это может быть как физическое, так и юридическое лицо, которое посредством работы системы достигает своих целей. В нашем примере, в качестве primary actor мы можем рассматривать фирму-дистрибьютора, продажа товаров которой осуществляется на платформе онлайн-магазина.
• Предусловия и постусловия. Другими словами, это факторы, при наличии которых производится запуск сценария, и те, которые возникают после.

• Триггеры – элементы, приводящие в действие UseCase.
• Успешный сценарий, то есть происходящий без ошибок и непредусмотренных обстоятельств.
• Альтернативные варианты. Их можно охарактеризовать как запасной план, созданный на базе основного сценария, необходимый при сбоях в функционировании системы.

Последовательность действия при создании сценариев Use Case описана максимально просто и доступно. Как правило, выделяются такие шаги как:

1. Определение пользователей сайта.
2. Выбор одного из них.
3. Формулировка действий пользователя на сайте, которые и будут являться UseCase.
4. Определение потока события для каждого из сценариев.
5. Описание действий пользователя и результата, к которому они ведут. Другими словами, каким должен быть отклик системы.
6. Создание и добавление других вариантов развития событий в сценарий.
7. Выбор других пользователей и описание UseCase для каждого из них (шаги 2 – 6).

Нижеприведенный пример Use Case – это сценарий входа пользователя в школьное приложение:

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

Рекомендации по созданию Use Case

Применяйте диаграммы

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

Люди – первостепенно важный элемент сценария

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

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

Идите за потоком

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

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

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

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

Ошибки при создании Use Case

В завершение статьи кратко расскажем, какие ошибки чаще всего допускаются разработчиками при создании различных видов Use Case:

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

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

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

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

Значение Use Case в разработке продукта

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

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

Еще одним важным преимуществом использования Use Case является то, что это позволяет разработчикам лучше понимать, каким образом пользователи будут использовать продукт в реальной жизни. Это позволяет создать более удобный и интуитивно понятный интерфейс, который будет соответствовать потребностям и ожиданиям пользователей.

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

В целом, использование Use Case является необходимым для разработки продукта, который будет соответствовать потребностям и ожиданиям пользователей, а также будет функциональным и удобным в использовании.

Что должен включать в себя хороший Use Case?

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

Хороший Use Case должен включать в себя следующие элементы:

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

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

Краткое описание. Краткое описание того, что происходит в данном сценарии.

Предусловия. Описание условий, необходимых для начала работы системы в рамках данного Use Case. Это могут быть какие-то исходные данные, которые должны быть подготовлены до начала работы системы.

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

Альтернативные потоки событий. Опишите возможные варианты развития событий, которые могут произойти в рамках Use Case, если определенные условия не будут выполнены или произойдут какие-то непредвиденные события..

Постусловия. Опишите возможные варианты развития событий, которые могут произойти в рамках Use Case, если определенные условия не будут выполнены или произойдут какие-то непредвиденные события.

Расширенные атрибуты. Опишите дополнительные сведения о сценарии использования, такие как исключения, дополнительные условия, требования к безопасности и т. д.

UML Use Case диаграмма. Графическое представление сценария использования, которое показывает акторов, основной поток событий и альтернативные потоки.

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

Как построить идеальную Use Case диаграмму в целом, я уже писал, если вы всё делали по инструкциям, написанным в этом блоге, то у вас не должно возникнуть с этим трудностей.

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

Use Case пример

Пример плохого Use Case

Ниже представлен пример плохого варианта использования и указаны допущенные ошибки

Заголовок	Оформление заказа на доставку еды.
Акторы	Заказчик.
Описание	Заказчик использует мобильное приложение для оформления заказа на доставку еды.
Предусловия	Заказчик установил приложение и зарегистрировался в нем.
Основной поток событий	Заказчик открывает мобильное приложение. Заказчик выбирает блюда из меню и добавляет их в корзину. Заказчик выбирает адрес доставки и указывает способ оплаты. Приложение отправляет заказ на сервер.
Альтернативные потоки событий	Нет альтернативных потоков событий.
Постусловия	Заказ оформлен.
Расширенные атрибуты	Отсутствуют.
UML Use Case диаграмма

В данном use case допущены следующие ошибки:

1. Отсутствуют акторы, которые участвуют в процессе оформления заказа на доставку еды, такие как ресторан.
2. Отсутствуют альтернативные потоки событий, которые могут возникнуть при оформлении заказа, например, если блюда из меню недоступны или закончились, если заказ не может быть выполнен в указанное время и т.д.
3. Описание Use Case слишком краткое и не содержит достаточной информации для полного понимания процесса оформления заказа.
4. Отсутствуют расширенные атрибуты, такие как возможность отслеживания статуса заказа и возможность оставить отзыв о доставке.
5. Не корректно составлена UML Use Case диаграмма.

Пример хорошего Use Case

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

Заголовок	Оформление заказа на доставку еды через мобильное приложение.
Акторы	Заказчик, Ресторан.
Описание	В данном сценарии заказчик использует мобильное приложение для оформления заказа на доставку еды из ресторана.
Предусловия	Заказчик установил приложение и зарегистрировался в нем. Ресторан подключен к приложению.
Основной поток событий	Заказчик открывает мобильное приложение и выбирает ресторан. Заказчик выбирает блюда из меню и добавляет их в корзину. Заказчик выбирает адрес доставки. Приложение отправляет заказ в ресторан. Ресторан получает заказ и подтверждает его. Приложение уведомляет заказчика о подтверждении заказа Приложение списывает стоимость заказа со счета клиента.
Альтернативные потоки событий	Если ресторан не подтверждает заказ в течение 10 минут, приложение уведомляет заказчика о задержке. Ресторан может отменить заказ, если блюда не доступны или закончились.
Постусловия	Ресторан получил оплату за заказ.
Расширенные атрибуты	Заказчик может отслеживать статус заказа в приложении. Заказчик может оставить комментарий к заказу и поставить рейтинг ресторану.
UML Use Case диаграмма
Рекомендации по реализации	Разработать удобный интерфейс для выбора блюд и оформления заказа. Организовать быстрое подтверждение заказов ресторанами.