Как сделать диаграмму прецедентов
Учебное пособие по диаграмма прецедентов (Руководство с примерами)
Updated on: 22 January 2021
Диаграмма вариантов прецедентов – это тип поведенческой диаграммы UML, который часто используется для анализа различных систем. Они позволяют визуализировать различные типы ролей в системе и то, как эти роли взаимодействуют с системой. Это руководство по диаграмме вариантов использования охватывает следующие темы и поможет вам лучше создавать сценарии использования.
Важность использования диаграммы прецедентов
Как уже упоминалось ранее, диаграммы прецедентов используются для сбора требований к использованию системы. В зависимости от ваших требований вы можете использовать эти данные различными способами. Ниже приведены несколько способов их использования.
Объекты диаграммы прецедентов
Использовать диаграммы корпуса состоят из 4 объектов.
Объекты более подробно описаны ниже.
Актер
Актер в использует диаграмму прецедентов – это любая сущность, которая выполняет роль в одной данной системе. Это может быть человек, организация или внешняя система и обычно рисуется как скелет, показанный ниже.
Случай использования
Случай использования представляет собой функцию или действие внутри системы. Она нарисована как овал и названа функцией.
Система
Система используется для определения сферы применения и нарисована в виде прямоугольника. Это необязательный элемент, но полезный при визуализации больших систем. Например, вы можете создать все случаи использования, а затем использовать системный объект для определения области применения вашего проекта. Или вы даже можете использовать его, чтобы показать различные области, охваченные в разных релизах.
Пакет
Пакет является еще одним дополнительным элементом, который чрезвычайно полезен в сложных диаграммах. Подобно диаграммам классов, пакеты используются для группировки случаев использования. Они нарисованы, как показано на рисунке ниже.
Рекомендации по диаграммам прецедентов
Несмотря на то, что диаграммы использования могут быть использованы для различных целей, существуют некоторые общие рекомендации, которым необходимо следовать при рисовании примеров использования.
К ним относятся стандарты именования, направления стрелок, размещение вариантов использования, использование системных блоков, а также правильное использование отношений.
Мы подробно освещали эти рекомендации в отдельном посте блога. Так что продолжайте и ознакомьтесь с рекомендациями по диаграммам прецедентов.
Отношения в диаграммах вариантов использования
Существует пять типов отношений на диаграмме прецедентов. Они
Мы рассмотрели все эти отношения в отдельном посте блога, который содержит примеры с изображениями. Мы не будем вдаваться в подробности в этом посте, но вы можете проверить отношения на диаграммах прецедентов использования.
Как создавать диаграммы прецедентов использования
До сих пор вы узнали об объектах, отношениях и руководствах, которые критичны при рисовании диаграмм с примерами из практики. Я объясню различные процессы на примере банковской системы.
Выявление актеров
Актеры – это внешние объекты, взаимодействующие с вашей системой. Это может быть человек, другая система или организация. В банковской системе наиболее очевидным действующим лицом является клиент. Другие актеры могут быть банковскими служащими или кассирами в зависимости от роли, которую вы пытаетесь показать в случае использования.
Примером внешней организации может служить налоговый орган или центральный банк. Кредитный процессор является хорошим примером внешней системы, связанной в качестве агента.
Определение случаев использования
Теперь пришло время идентифицировать случаи использования. Хороший способ сделать это – определить, что нужно участникам системы. В банковской системе клиенту необходимо будет открывать счета, вводить и выводить средства, запрашивать чековые книги и выполнять аналогичные функции. Так что все это можно рассматривать как случаи использования.
Случаи использования верхнего уровня всегда должны обеспечивать полную функцию, требуемую для агента. В зависимости от сложности системы вы можете расширить или включить случаи использования.
После того, как вы определили актёров и верхний уровень использования, у вас есть базовое представление о системе. Теперь вы можете точно настроить его и добавить к нему дополнительные слои деталей.
Ищите общие функциональные возможности для использования Включать
Ищите общие функциональные возможности, которые могут быть повторно использованы в системе. Если вы найдете два или более случаев использования, которые имеют общую функциональность, вы можете извлечь общие функции и добавить его в отдельный случай использования. Затем вы можете подключить его через include relationship, чтобы показать, что он всегда вызывается, когда выполняется исходный сценарий использования. ( см. диаграмму для примера ).
Возможно ли обобщение актеров и случаев использования
Могут быть случаи, когда агенты ассоциируются с аналогичными случаями использования, в то время как запускается несколько случаев использования, уникальных только для них. В таких случаях можно обобщить агент, чтобы показать наследование функций. Аналогичную вещь можно сделать и в случае использования.
Одним из лучших примеров этого является случай использования “Оплатить” в платежной системе. Вы можете далее обобщить его до “Оплатить кредитной картой”, “Оплатить наличными”, “Оплатить чеком” и т.д. Все они имеют атрибуты и функциональность оплаты со специальными уникальными для них сценариями.
Необязательные функции или дополнительные функции
Есть некоторые функции, которые срабатывают опционально. В таких случаях можно использовать отношения расширения и прикрепить к ним правило расширения. В приведенном ниже примере банковской системы “Рассчитать бонус” является необязательным и срабатывает только при выполнении определенного условия.
Продление не всегда означает, что оно необязательно. Иногда вариант использования, связанный с удлинением, может дополнять вариант использования базы. Следует помнить, что базовый сценарий использования должен быть способен выполнять функцию самостоятельно, даже если сценарий использования расширения не вызывается.
Случай использования с большинством сценариев, найденных в диаграмма прецедентов
Шаблоны диаграмм прецедентов использования
Шаблон варианта прецедентов для системы банкомата
Мы пошли дальше и создали шаблоны диаграмм прецедентов использования для некоторых распространенных сценариев. Хотя ваша проблема или сценарий не будут в точности такими, вы можете использовать их в качестве отправной точки. Ознакомьтесь с нашими шаблонами диаграмм прецедентов использования.
Вопросы по руководству по диаграмме прецедентов использования
Мы постарались всесторонне охватить все, что вам нужно знать о создании диаграмм прецедентов использования. Если у вас есть сомнения по поводу какого-либо раздела или вы можете придумать, как улучшить это руководство, пожалуйста, сообщите нам об этом в комментариях.
UML — диаграмма вариантов использования (use case diagram)
Диаграммы вариантов использования описывают взаимоотношения и зависимости между группами вариантов использования и действующих лиц, участвующими в процессе.
Важно понимать, что диаграммы вариантов использования не предназначены для отображения проекта и не могут описывать внутреннее устройство системы. Диаграммы вариантов использования предназначены для упрощения взаимодействия с будущими пользователями системы, с клиентами, и особенно пригодятся для определения необходимых характеристик системы. Другими словами, диаграммы вариантов использования говорят о том, что система должна делать, не указывая сами применяемые методы.
Вариант использования (use case)
В данном примере вариант использования Part включается в вариант использования Base.
В данном примере вариант использования Base расширяется вариантом использования Another.
В данном примере вариант использования Child обобщает вариант использования Base.
Действующее лицо (actor)
Действующее лицо является внешним источником (не элементом системы), который взаимодействует с системой через вариант использования. Действующие лица могут быть как реальными людьми (например, пользователями системы), так и другими компьютерными системами или внешними событиями.
Действующие лица представляют не физических людей или системы, а их роли. Эти означает, что когда человек взаимодействует с системой различными способами (предполагая различные роли), он отображается несколькими действующими лицами. Например, человек, работающий в службе поддержки и принимающий от клиентов заказы, будет отображаться в системе как «участник отдела поддержки» и «участник отдела продаж».
Описание варианта использования
Описания вариантов использования являются текстовыми пояснениями. Они обычно принимают форму заметки или документа, который каким-то образом прикрепляется к варианту использования и описывает процесс или активность.
Диаграммы прецедентов
Диаграммы прецедентов используются для моделирования динамических аспектов ИС. Диаграммы этого типа позволяют достаточно четко описать и визуализировать поведение системы или ее части с точки зрения способа их использования. В результате, с одной стороны, пользователи системы понимают, как использовать некоторые элементы, а разработчики — как их реализовать. Диаграммы данного типа облегчают понимание системы и ее частей, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. При этом достигается высокий уровень понимания функционирования всей системы в целом. Кроме того, такие диаграммы важны для организации эффективного тестирования систем в процессе прямого проектирования и для понимания их внутреннего устройства при обратном проектировании, когда создается модель уже работающей системы. Поэтому диаграммы прецедентов являются наиболее важным инструментом описания поведения.
На диаграмме прецедентов показывается совокупность прецедентов (use cases), актеров (actors) и отношений между этими элементами. Отношения могут следующих типов: зависимость, обобщение, ассоциация. Диаграмма прецедентов может быть также использована для описания функциональности любого классификатора (classifier).
Актер (actor) — согласованная совокупность ролей, которые играет пользователь системы при взаимодействии с ней. Актером может быть как одушевленный предмет (человек-оператор), так и не одушевленный (другие ИС). Актер обычно представляется как стилизованным человечком:
Актеры позволяют четко определить:
— кто пользуется системой;
— кто отвечает за сопровождение системы;
— внешнее аппаратное обеспечение, которое используется системой;
— другие системы, которые должны взаимодействовать с данной системой.
Можно указать два основных варианта использования диаграмм прецедентов:
1. моделирование контекста системы, в ходе которого формируется воображаемая граница системы и выявляются актеры, взаимодействующие с системой; диаграмма прецедентов позволяет в данном случае определить актеров и суть их ролей;
2. моделирование требований к системе, позволяющее точно определить функции системы и ее реакции на внешние события независимо от того, как эти функции реализуются, т.е. по принципу «черного ящика»; это описание системы с точки зрения внешнего наблюдателя.
Пример описания процесса выполнения заказа клиента с помощью диаграммы прецедентов:
Здесь два актера — «Менеджер по продажам» и «Менеджер по закупкам» — вовлечены в два прецедента — «Выполнить заказ клиента» и «Заключить договор с клиентом». Отношения между актерами и прецедентами носят характер однонаправленной ассоциации и показаны поименованной стрелкой.
Один актер может участвовать в нескольких прецедентах, а с одним прецедентом может быть связано несколько актеров.
Несколько прецедентов могут иметь общую часть, выделяемую в самостоятельный прецедент, с которым устанавливается отношение включения с помощью стереотипа «include». Например, если прецеденты «Выполнить заказ клиента» и «Заключить договор с клиентом» содержат общую часть, выражающуюся в проверке данных о клиенте, то это можно выразить так:
Содержание прецедента с точки зрения действий, из которых он состоит, может быть раскрыто с помощью диаграмм активности или состояний, присоединенных к прецеденту.
Диаграммы классов
Диаграмма классов — это граф, узлами которого являются элементы статической структуры проекта системы (классы, интерфейсы и т.п.), а дугами — отношения между узлами (ассоциации, наследование, зависимости).
Диаграмма классов основана на распространенной модели «сущность-связь» (Entity Relationship Diagram, ERD), но обычно обладает большими возможностями по спецификации свойств сущностей и их отношений. Диаграммы классов являются основным средством моделирования статического вида системы.
Обычно диаграммы классов используют в следующих целях:
1. моделирование словаря предметной области, в ходе которого определяется состав и назначение абстракций, являющихся частью системы;
2. моделирование коопераций, позволяющее визуализировать и специфицировать отношения между элементами, входящими в кооперацию;
3. моделирование логической схемы базы данных (реляционной или объектно-ориентированной).
На диаграмме классов обычно изображаются следующие элементы:
— объект (object) — экземпляр класса;
— параметризованный класс (parameterized class), или шаблон, — семейство классов, отличающихся значением некоторых формальных параметров (пример из языков программирования — шаблоны (templates) в C++);
Среди перечисленных элементов ранее не давалось развернутое описание отношения типа «ассоциация»
Ассоциация(association) — структурное отношение, показывающее, что объекты одного типа некоторым образом связаны с объектами другого типа. Ассоциация может связывать любые классификаторы, но главным образом используется для описания отношений между классами.
Ассоциация, связывающая два класса, называется бинарной. Такая ассоциация используется чаще всего, и именно она рассматривается далее. Можно создавать ассоциации, связывающие более двух классов, они называются n-арными. Реально использование такого отношения редко бывает необходимым. Можно также указывать ассоциацию класса самим с собой, что означает структурную связь между объектами одного класса.
Бинарная ассоциация изображается сплошной линией и может иметь дополнительные визуальные атрибуты, конкретизирующие свойства ассоциации.
Четыре основные характеристики ассоциации:
— наименование — символьная строка, описывающая смысл отношения; имя обычно не указывается, но является полезным, например, в случае существования нескольких ассоциаций между одними и теми же классами;
— роль — описание того значения, которое имеет некоторый класс в контексте данной ассоциации; роль описывает значение одного класса относительно другого класса, связанного ассоциацией;
— кратность — описание числа объектов (экземпляров класса), которые могут быть связаны одним экземпляром ассоциации; указание кратности на одном конце ассоциации специфицирует, сколько именно объектов должно соответствовать каждому объекту на противоположном конце; кратность может указываться конкретным числом или диапазоном, например: единица — «1», несколько — «0..*», положительное количество — «1..*» и т.п.;
— агрегирование — знак того, что ассоциация имеет характер отношения «часть-целое», когда один класс в той или иной форме является частью другого; факт агрегирования показывается с помощью незакрашенного ромба со стороны класса более высокого ранга («целого»); базовая форма агрегирования является чисто концептуальной и показывает, что объект одного класса может агрегироваться объектом другого класса или даже несколькими объектами, что, например, не задает каких-либо зависимостей по времени жизни между объектами.
Пример изображения того, что класс «Студент», играющий роль ученика, ассоциирован с классом «Преподаватель», играющим роль учителя:
При этом считается, что одному объекту «Преподаватель» может соответствовать произвольное количество объектов «Студент». Имя ассоциации составлено со стороны класса «Студент».
Пример использования агрегирования:
Теперь, возвращаясь к примеру о выполнении заказа клиента, можно представить возможную диаграмму классов, использующихся для реализации данного прецедента, следующим образом:
Из диаграммы видно, что для некоторых классов определены операции, перечисляемые в нижней части прямоугольника класса. Для атрибутов определен тип.
Для атрибутов и классов может быть указана видимость:
Закрытые (protected) атрибуты и операции помечаются знаком «-» (минус), защищенные (protected) — знаком «#» (диез), открытые — знаком «+» (плюс).
Дата добавления: 2018-11-25 ; просмотров: 2133 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ
Что находится между идеей и кодом? Обзор 14 диаграмм UML
Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?
Этот цикл статей будет посвящен полезному, но порой ускользающему от молодой поросли знанию — диаграммам UML. И начну я его с обзора существующих диаграмм, поговорим немного об истории и зачем диаграмм должно быть так много.
UML — это сокращение от Unified Modeling Language, и, как мы знаем, он является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.
UML представляет собой набор лучших инженерных практик, которые доказали свою эффективность в моделировании больших и сложных систем и является очень важной частью разработки объектно-ориентированного программного обеспечения.
UML использует в основном графические обозначения, чтобы выразить дизайн программных проектов. Использование UML помогает проектным группам общаться, изучать потенциальные проекты и проверять архитектурный дизайн программного обеспечения.
Происхождение UML
Цель UML — предоставить стандартную нотацию, которая может использоваться всеми объектно-ориентированными методами, а также выбрать и интегрировать лучшие элементы нотаций-предшественников. UML был разработан для широкого спектра приложений. Следовательно, он предоставляет конструкции для широкого спектра систем и видов деятельности (например, распределенных систем, анализа, проектирования и развертывания систем).
UML не возник на пустом месте, ему предшествовали несколько значимых событий, личностей и методологий. Например:
К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция «прецедентов») были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.
В противовес всем известной “Банде Четырех”, Команда Румбо, Буча и Якобсона известна как «Три Амигоса».
На UML также повлияли другие объектно-ориентированные нотации:
Почему UML?
По мере того как стратегическая ценность программного обеспечения возрастала для многих компаний, отрасль искала методы для автоматизации производства программного обеспечения, а также для повышения качества и сокращения затрат и времени выхода на рынок.
Эти методы включают технологию компонентов, визуальное программирование, шаблоны и структуры.
Компании также ищут методы для управления сложностью систем по мере увеличения их масштаба.
В частности, они признают необходимость решения повторяющихся архитектурных проблем, таких как физическое распределение, параллелизм, репликация, безопасность, балансировка нагрузки и отказоустойчивость.
Кроме того, разработка под Web хоть и упрощает некоторые вещи, в целом, она усугубляет эти архитектурные проблемы.
Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.
Основные цели дизайна UML:
Структурные диаграммы показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь. Элементы в структурной диаграмме представляют значимые понятия системы и могут включать в себя абстрактные, реальные концепции и концепции реализации. Существует семь типов структурных диаграмм:
Диаграмма классов
Диаграмма классов — это центральная методика моделирования, которая используется практически во всех объектно-ориентированных методах. Эта диаграмма описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними.
Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:
Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.
Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.
Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.
Диаграмма компонентов
На языке унифицированного моделирования диаграмма компонентов показывает, как компоненты соединяются вместе для формирования более крупных компонентов или программных систем.
Она иллюстрирует архитектуры компонентов программного обеспечения и зависимости между ними.
Эти программные компоненты включают в себя компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.
Диаграмма развертывания
Диаграмма развертывания помогает моделировать физический аспект объектно-ориентированной программной системы. Это структурная схема, которая показывает архитектуру системы, как развертывание (дистрибуции) программных артефактов.
Артефакты представляют собой конкретные элементы в физическом мире, которые являются результатом процесса разработки.
Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.
В большинстве случаев это включает в себя моделирование конфигураций оборудования вместе с компонентами программного обеспечения, на которых они размещены.
Диаграмма объектов
Статическая диаграмма объектов является экземпляром диаграммы класса; она показывает снимок подробного состояния системы в определенный момент времени. Разница в том, что диаграмма классов представляет собой абстрактную модель, состоящую из классов и их отношений.
Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно — чтобы показать примеры структуры данных.
Диаграмма пакетов
Диаграмма пакетов — это структурная схема UML, которая показывает пакеты и зависимости между ними.
Она позволяет отображать различные виды системы, например, легко смоделировать многоуровневое приложение.
Диаграмма составной структуры
Диаграмма составной структуры аналогична диаграмме классов и является своего рода диаграммой компонентов, используемой в основном при моделировании системы на микроуровне, но она изображает отдельные части вместо целых классов. Это тип статической структурной диаграммы, которая показывает внутреннюю структуру класса и взаимодействия, которые эта структура делает возможными.
Эта диаграмма может включать внутренние части, порты, через которые части взаимодействуют друг с другом или через которые экземпляры класса взаимодействуют с частями и с внешним миром, и соединители между частями или портами. Составная структура — это набор взаимосвязанных элементов, которые взаимодействуют во время выполнения для достижения какой-либо цели. Каждый элемент имеет определенную роль в сотрудничестве.
Диаграмма профилей
Диаграмма профилей позволяет нам создавать специфичные для домена и платформы стереотипы и определять отношения между ними. Мы можем создавать стереотипы, рисуя формы стереотипов и связывая их с композицией или обобщением через интерфейс, ориентированный на ресурсы. Мы также можем определять и визуализировать значения стереотипов.
Диаграмма прецедентов
Диаграмма прецедентов описывает функциональные требования системы с точки зрения прецедентов. По сути дела, это модель предполагаемой функциональности системы (прецедентов) и ее среды (актеров).
Прецеденты позволяют связать то, что нам нужно от системы с тем, как система удовлетворяет эти потребности.
Диаграмма деятельности
Диаграммы деятельности представляют собой графическое представление рабочих процессов поэтапных действий и действий с поддержкой выбора, итерации и параллелизма.
Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов.
В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.
Диаграмма состояний
Диаграмма состояний — это тип диаграммы, используемый в UML для описания поведения систем, который основан на концепции диаграмм состояний Дэвида Харела. Диаграммы состояний отображают разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Она помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.
Диаграмма последовательности
Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.
Диаграмма Коммуникации
Как и диаграмма последовательности, диаграмма коммуникации также используется для моделирования динамического поведения прецедента. Если сравнивать с Диаграммой последовательности, Диаграмма коммуникации больше сфокусирована на показе взаимодействия объектов, а не временной последовательности. На самом деле, диаграмма коммуникации и диаграмма последовательности семантически эквивалентны и могут перетекать одна в другую.
Диаграмма обзора взаимодействия
Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.
Временная диаграмма
Временная диаграмма показывает поведение объекта (ов) в данный период времени. По сути — это особая форма диаграммы последовательности и различия между ними состоят в том, что оси меняются местами так, что время увеличивается слева направо, а линии жизни отображаются в отдельных отсеках, расположенных вертикально.
Зачем в UML столько диаграмм?
Причина этого заключается в том, что можно взглянуть на систему с разных точек зрения ведь в разработке программного обеспечения будут участвовать многие заинтересованные стороны, такие как: аналитики, конструкторы, кодеры, тестеры, контроль качества, клиенты, технические авторы.
Все эти люди заинтересованы в различных аспектах системы, и каждый из них требует разного уровня детализации.
Например, кодер должен понимать проект системы и уметь преобразовывать проект в код низкого уровня.
Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.
UML пытается предоставить язык настолько выразительным образом, что все заинтересованные стороны могут извлечь выгоду, как минимум из одной диаграммы UML.
Для тех, кому лень читать: