Почему не рекомендуется подробная детализация диаграмм прецедентов
Перейти к содержимому

Почему не рекомендуется подробная детализация диаграмм прецедентов

  • автор:

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

Диаграмма прецедентов (она же диаграмма вариантов использования, англ. Use-Case Diagram) — первая диаграмма, которая моделируется средствами языка UML. Диаграмма прецедентов рассматривает корпоративные бизнес-процессы верхнего уровня с внешней точки зрения и позволяет понять, как выглядит деятельность компании «со стороны».

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

Подробное описание элементов графической нотации и типов взаимосвязи см. в подпараграфе 5.5.1 «Представление прецедентов».

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

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

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

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

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

Рис. 5.17. Пример диаграммы прецедентов

На рис. 5.17 приведен упрощенный пример диаграммы прецедентов. Пунктирная линия со словом «extend» означает, что прецедент «Заказ товаров» может быть включен в прецедент «Учет запасов» (например, если новая ИС будет автоматически формировать заказ поставщикам на основании данных о запасах). Однако на текущий момент заказ товаров не является составной частью учета запасов.

Пунктирные линии со словом «include», идущие от прецедента «Продажа товаров», означают, что прецеденты «Продажа по карте» и «Продажа наличными» являются составными. При этом настолько подробная детализация может не производиться.

Квадратной рамкой выделена область автоматизации.

Диаграмма прецедентов (вариантов использования) UML

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма прецедентов (вариантов использования системы) UML

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

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

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

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

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

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

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

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

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

Диаграмма прецедентов (вариантов использования) UML

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

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

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

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

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

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

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

Основы UML.
Кому и зачем он нужен

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

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

Время на чтение статьи: 17 минут
Не любите читать? Посмотрите видео.
Оглавление

  • Определение
  • История возникновения UML
  • Классификация UML диаграмм
  • UML для Заказчика
  • UML для Аналитика
  • UML для Архитектора
  • UML для Разработчика
  • UML c позиции Тестировщика
  • UML для Технического писателя
  • Какие задачи на UML встречаются на собеседованиях?
  • Правда ли, что UML используют только в больших компаниях?
  • Обязательно ли знать программирование для работы с UML?
  • На каких практических кейсах можно потренироваться в UML?
  • Можно ли моделировать сложную логику UML в MS Visio?
  • Как быстро освоить Enterprise Architect?
  • Зачем нужна диаграмма классов, если есть ER-диаграмма?
  • Как связаны UML и BPMN?

Что такое UML

UML (Unified Modeling Language, Унифицированный Язык Моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, который также можно применять для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

Давайте подробнее разберём аббревиатуру UML:

  • U — Unified (Унифицированный). Большой набор элементов, входящих в нотацию, позволяет покрывать много задач на этапе анализа и проектирования. Ещё одна версия происхождения этого слова кроется в том, что нотация объединила в себе несколько разнородных нотаций, существовавших ранее.
  • M — Modeling (Моделирование). Создание диаграмм заключается в разработке моделей, содержащих наполненные информацией и связанные между собой графические объекты.
  • L — Language (Язык). UML является искусственным языком и обладает свойствами языка: имеет словарь (графические символы), семантику (смысловые значения элементов) и синтаксис (правила построения конструкций). В нотацию также заложена возможность генерации кода из графической модели и генерация моделей из кода.

История возникновения UML

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

В основу нотации легли наработки многих специалистов в области программной инженерии, но наиболее весомый вклад внесли Грейди Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) и Джеймс Рамбо (James Rumbaugh).

UML вобрала в себя особенности их нотаций моделирования — Booch, OOSE (Object Oriented Software Engineering) и OMT (Object Modeling Technique) соответственно.

История возникновения нотации UML

Рис. 1 — История возникновения нотации UML

Язык постоянно развивается, появляются новые элементы для моделирования более сложных систем. Актуальная сейчас версия нотации — UML 2.5.1; новости и рекомендации можно найти на официальном сайте UML.org.

Классификация UML диаграмм

Нотация известна тем, что в неё входит много различных видов диаграмм:

виды UML диаграмм

Рис. 2 — Классификация диаграмм нотации UML
Структурные диаграммы UML. Описывают систему статически
Диаграмма;Описание

Диаграмма классов (Class Diagram);Описывает систему в виде набора классов со свойствами, доступными методами и взаимосвязями между классами. Диаграмма объектов (Object Diagram);Является экземпляром диаграммы классов и показывает конкретные значения свойств классов. Диаграмма пакетов (Package Diagram);Описывает взаимосвязи пакетов. Пакет — группа классов, объединенных для упрощения сложной диаграммы классов. Диаграмма компонент (Component Diagram);Описывает архитектуру компонентов (сервисы, интерфейсы, приложения и т.д.) и зависимости между ними. Диаграмма развертывания (Deployment Diagram);Описывает архитектуру системы с точки зрения ее развертывания на физическом уровне. Диаграмма профилей (Profile Diagram);Описывает пользовательские стереотипы и ограничения, применяемые к моделям. Диаграмма композитной структуры (Composite Structure Diagram);Описывает внутреннюю структуру классов и взаимодействие элементов класса между собой.

Диаграммы поведения UML. Описывают систему динамически

Диаграмма;Описание

Диаграмма прецедентов (Use Case Diagram). Употребляется также термин «Диаграмма вариантов использования»;Описывает набор функциональности (прецедент), доступной акторам (внешним для системы сущностям, например, пользователям). Диаграмма деятельности (Activity Diagram);Описывает рабочий процесс внутри каждого прецедента. Диаграмма состояний (State Machine Diagram);Описывает состояния, в которых может находиться каждый объект, и правила перехода из одного состояния в другое. Диаграммы взаимодействия; Диаграмма последовательности (Sequence Diagram);Описывает логику взаимодействия и обмена данными между объектами в рамках прецедента в хронологическом порядке. Диаграмма коммуникации (Communication Diagram);Описывает логику взаимодействия и обмена данными между объектами в рамках прецедента. Схожа с sequence diagram, но без раскрытия хронологического порядка. Диаграмма синхронизации (Timing Diagram);Описывает как объекты ведут себя на временной шкале без отображения взаимосвязей между объектами. Диаграмма обзора взаимодействия (Interaction Overview Diagram);Описывает процесс взаимодействия объектов. Похожа на activity diagram, но более высокоуровневую, где каждый узел — другая диаграмма взаимодействия.

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

Применение UML к разным задачам

Почти любые задачи описания и проектирования при разработке можно решить с помощью UML. Примеры таких задач перечислены в таблице.

Задача;Диаграммы

На графике ниже приведена статистика упоминания различных видов диаграмм (информация взята из мета-анализа встречаемости UML в статьях и исследованиях по ИТ-дисциплинам за 2021 год, числа указывают абсолютное количество публикаций). В рабочей практике статистика применимости похожая.

Статистика частоты разных UML-диаграмм в публикациях

  • Class Diagram
  • Activity Diagram
  • Sequence Diagram
  • Use Case Diagram

Применение UML разными ролями

Если в поиске на сайте HeadHunter ввести ключевое слово «UML», то получится, что в подавляющем большинстве случаев знание этой нотации нужно системным аналитикам (реже — бизнес-аналитикам). По описаниям вакансий можно также заметить, что знание UML требуется в основном специалистам уровня middle и senior.

  • Кто такой системный аналитик? Профессия, требования, зарплата
  • Как выполнить тестовое задание на должность системного аналитика

Давайте разберемся, кому и какие UML-модели могут пригодиться в работе.

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

Аннотация: Диаграмма вариантов использования как концептуальное представление бизнес-системы в процессе ее разработки. Особенности графического изображения вариантов использования и актеров. Основные отношения между графическими элементами, их стереотипы. Понятия бизнес-актера, сотрудника и бизнес варианта использования. Особенности концептуального моделирования бизнес-систем в форме диаграмм вариантов использования.

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

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

Диаграмма вариантов использования (use case diagram ) — диаграмма , на которой изображаются отношения между актерами и вариантами использования .

Диаграмма вариантов использования — это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели:

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

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

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

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

Базовыми элементами диаграммы вариантов использования являются вариант использования и актер .

Вариант использования (use case) — внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с актерами .

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

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

Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое имя в форме существительного (рис. 3.1, а) или глагола (рис. 3.1, б) с пояснительными словами. Сам текст имени варианта использования должен начинаться с заглавной буквы.

Имя (name) — строка текста, которая используется для идентификации любого элемента модели.

Рис. 3.1. Графическое обозначение варианта использования

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

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

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

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

Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Каждый актер может рассматриваться как некая отдельная роль относительно конкретного варианта использования . Стандартным графическим обозначением актера на диаграммах является фигурка «человечка», под которой записывается имя актера (рис. 3.2).

Рис. 3.2. Графическое обозначение актера

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *