USE CASE-диаграмма. Примеры использования

В программной и системной инженерии USE CASE-диаграмма представляет собой список действий или шагов мероприятия, которые обычно определяют взаимодействие между ролью (известной на языке унифицированного моделирования как «актер») и системой для достижения цели. "Актер" может быть человеческой или другой внешней системой.

Определение

USE CASE-диаграммы языка UML — это важный и ценный метод анализа требований, который широко используется в современной разработке программного обеспечения со времени его официального введения Иваром Джекобсоном в 1992 году. Разработка с использованием приложений зависит от многих моделей процессов и структур, таких как ICONIX, Unified Process (UP), IBM Rational Unified Process (RUP) и Oracle Unified Method (OUM).

История

В 1986 году Ивар Джекобсон сначала сформулировал текстовые, структурные и визуальные методы моделирования для определения вариантов использования. В 1992 году его соавтор книги «Объектно-ориентированная разработка программного обеспечения — подход, основанный на USE CASE», помог популяризовать технику сбора функциональных требований, особенно в разработке ПО.

Другие эксперты также внесли большой вклад, в частности Алистер Кокберн, Ларри Константин, Дин Леффингвелл, Курт Биттнер и Гуннар Овергаард.

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

Характер взаимодействия элементов

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

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

USE CASE-диаграммы: состав, виды связей

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

Существует три основных элемента процесса:

  • "Актеры" — это тип пользователей, которые взаимодействуют с системой.

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

  • Цели — USE CASE обычно инициируются пользователем для выполнения целей, описывающих действия и варианты, участвующие в их достижении.

Характеристики методики:

  • Организация функциональных требований.

  • Моделирование целей взаимодействия пользователей системы.

  • Запись сценариев из триггерных событий в конечные цели.

  • Описание основного хода действий и исключительного потока событий.

  • Разрешение доступа к функциям другого события.

Шаги при разработке диаграмм:

  • Определите пользователей системы.

  • Для каждой категории создайте профиль пользователя. Это включает в себя все роли, имеющие отношение к системе.

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

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

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

Терминология

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

Для чего применяются USE CASE-диаграммы?

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

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

Что такое диаграмма UML?

USE CASE-диаграмма UML — это способ визуализации программного обеспечения с использованием набора диаграмм. Основоположники технологии — Грэди Буч, Джеймс Румбо, Ивар Джекобсон и компания Rational Software Corporation. Их работы легли в основу объектно-ориентированного дизайна, затем спецификации были расширены, чтобы охватить более широкий спектр проектов разработки программного обеспечения. Сегодня UML принимается группой управления объектами (OMG) в качестве стандарта для разработки программного обеспечения для моделирования.

Чтобы ответить на вопрос о том, что такое диаграмма использования в UML, необходимо сначала понять ее строительные блоки. Общие компоненты включают:

  • пользователей, которые взаимодействуют с системой;

  • определенную последовательность действий и взаимодействия между участниками и сценарием системы;

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

В профессиональном сообществе программистов для объяснения структуры часто применяют диаграммы USE CASE «по курочке Рябе» — визуальное изображение сюжета популярной сказки в виде схемы.

Что такое UML?

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

  • улучшена интеграция между структурными моделями, такими как диаграммы классов и модели поведения (диаграммы активности);

  • добавлена ​​возможность определять иерархию и разлагать программную систему на компоненты и подкомпоненты;

  • в исходном UML указаны девять диаграмм — UML 2.0 увеличивает это число до 13;

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

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

Типы диаграмм

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

Эти диаграммы организованы в две различные группы: структурные и диаграммы поведения (или взаимодействия).

Структурные, в свою очередь, делятся на следующие виды диаграмм:

  • Классов — являются основой почти каждого объектно-ориентированного метода, включая UML. Они описывают статическую структуру системы.

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

  • Объекта — описывают статическую структуру системы в определенное время. Они могут использоваться для проверки диаграмм классов для точности.
    Композитные структурные диаграммы показывают внутреннюю часть класса. Моделируют функциональность системы с использованием участников и прецедентов.

  • Компонентов — описывают организацию физических программных компонентов, включая исходный код, исполняемый файл (двоичный код).

  • Диаграммы развертывания отображают физические ресурсы в системе, включая узлы, компоненты и соединения.

Поведенческие имеют в своем составе диаграммы:

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

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

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

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

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

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

Символы и обозначения

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

Зависимости отмечены пунктирной линией со стрелкой. Использование << >> позволяет указать свойства этой зависимости. Множественность обычно отображается с номером на одном конце стрелки и * с другой.

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

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

Почему мы используем UML?

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

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

Пример USE CASE-диаграммы — графическое изображение взаимодействий между элементами системы. Это методология, используемая в системном анализе для выявления, уточнения и организации системных требований. В этом контексте термин «система» относится к тому, что разрабатывается или эксплуатируется, например к веб-сайту по продаже и обслуживанию товаров по почте. USE CASE-диаграмма в UML (Unified Modeling Language) — стандартная нотация для моделирования объектов и систем реального мира.

Расшифровка понятий

Цели системы могут включать в себя планирование общих требований, проверку аппаратного проектирования, тестирование и отладку разрабатываемого программного продукта, создание справки по оперативной помощи или выполнение задачи, ориентированной на потребителя. Например, использование диаграммы вариантов USE CASE diagram в среде продаж включает в себя упорядочивание товаров, обновление каталога, обработку платежей и отношения с клиентами. Диаграмма использования выглядит как блок-схема. Интуитивные символы представляют собой элементы системы. Сценарии прецедентов диаграмм USE CASE-банкомата содержат четыре компонента:

  • Граница, которая определяет систему интереса к окружающему миру.

  • "Актеры", обычно люди, связанные с системой, определяемые в соответствии с их ролями.

  • Варианты использования, которые являются конкретными ролями, которые играют "актеры" внутри и вокруг системы.

  • Взаимоотношения между субъектами.

На унифицированном языке моделирования диаграмма может суммировать сведения о пользователях вашей системы (также известных как субъекты) и их взаимодействии с системой. Чтобы построить один объект, вы будете использовать набор специализированных символов и коннекторов. Например, USE CASE-диаграмма интернет-магазина может помочь вашей команде обсудить и представить:

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

  • цели и методы их достижения;

  • объем системы.

Практическое применение

USE CASE-диаграмма не имеет большого значения при отсутствии четкого понимания процесса — она не будет моделировать порядок выполнения шагов, если не заложен четкий алгоритм. Эксперты рекомендуют использовать данные диаграммы для дополнения текстового варианта. В диаграмме на высоком уровне демонстрируется взаимосвязь между вариантами использования, субъектами и системами. По этой причине часто используются USE CASE uml-диаграммы для политической партии при моделировании структуры.

Диаграмма идеальна в таких ситуациях:

  • представление целей системно-пользовательских взаимодействий;

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

  • выявление контекста и требований системы;

  • моделирование основного потока событий в прецеденте.

Благодаря оптимальной визуализации при моделировании программного обеспечения стиральных машин USE CASE-диаграммы применяются очень широко.

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

Назначение

Цель диаграммы — захватить динамический аспект системы. Однако это определение является слишком общим для описания цели. Так как другие четыре диаграммы (активность, последовательность, совместное использование и Statechart) также имеют одинаковую цель. USE CASE-диаграммы используются для сбора требований к системе, включая внутренние и внешние воздействия (как правило, это требования к дизайну). Следовательно, когда система анализируется для сбора ее функциональных возможностей, разрабатываются примеры использования и идентифицируются участники.

Когда начальная задача завершена, диаграммы случайных ситуаций моделируются для представления внешнего вида. Целями при создании USE CASE-диаграмм можно назвать следующее:

  • сбор требований;

  • получение внешнего вида системы;

  • влияние внешних и внутренних факторов;

  • визуализация взаимодействия между требованиями и субъектами.

Процесс создания

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

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

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

  • Имя прецедента очень важно — выберите его таким образом, чтобы оно могло идентифицировать выполняемые функции.

  • Дайте подходящее имя для актеров.

  • Покажите на диаграмме отношения и зависимости.

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

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

Сферы применения

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

Чтобы понять динамику, нужно использовать разные типы диаграмм. USE CASE-диаграммы, состав, виды связей — наилучший пример. Ее конкретная цель - собирать системные требования участников.

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

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

USE CASE-диаграммы могут использоваться для анализа требований и высокоуровневого дизайна, сопоставления контекста системы и обратного инжиниринга.

Комментарии