Диаграмма вариантов использования пример производства смартфонов uml
Унифицированный язык моделирования (UML) играет важную роль в разработке программного обеспечения, а также в системах, не связанных с ИТ, во многих отраслях, поскольку он дает возможность визуально показать поведение и структуру системы или процесса. UML помогает продемонстрировать возможные ошибки в структурах приложений, поведении системы и других бизнес-процессах.
Почему UML?
Впервые UML появился еще в 1990-х годах благодаря трем инженерам-программистам — Грэди Бучу, Ивару Джекобсону и Джеймсу — поскольку они хотели разработать менее хаотичный способ представления разработки все более сложного программного обеспечения, в то же время отделяя методологию от самого процесса. Сегодня UML по-прежнему является стандартной практической нотацией для разработчиков, а также для руководителей проектов, владельцев бизнеса, технических предпринимателей и специалистов из разных отраслей.
Каковы преимущества UML?
- Упрощает сложности
- Сохраняет возможности открытого общения
- Автоматизирует производство программного обеспечения и процессов
- Помогает решить постоянные проблемы с архитектурой
- Улучшает качество работы
- Сокращает затраты и время выхода на рынок
Типы диаграмм UML
Существует два основных типа диаграмм UML: структурные диаграммы и поведенческие диаграммы (а внутри этих категорий имеется много других). Эти варианты существуют для представления многочисленных типов сценариев и диаграмм, которые используют разные типы людей.
От заказчиков и руководителей проектов до технических писателей, конструкторов, аналитиков, программистов и тестеров — представители каждой роли будут использовать конкретную диаграмму в соответствии со своими потребностями. Это означает, что каждый шаблон требует различного фокуса и уровня детализации. Цель UML — визуально представить диаграммы, которые легко понять каждому.
Пример базовой диаграммы последовательности UML. Шаблон доступен длязагрузки
Давайте посмотрим внимательнее:
Структурные диаграммы
Структурные диаграммы представляют статическую структуру программного обеспечения или системы, они также показывают различные уровни абстракции и реализации. Они используются, чтобы помочь визуализировать различные структуры, составляющие систему, например, базу данных или приложение. Они показывают иерархию компонентов или модулей и то, как они связаны и взаимодействуют между собой. Эти инструменты обеспечивают руководство работы и гарантируют, что все части системы функционируют так, как задумано по отношению ко всем остальным частям.
Поведенческие диаграммы
Основное внимание здесь уделяется динамическим аспектам системы программного обеспечения или процесса. Эти диаграммы показывают функциональные возможности системы и демонстрируют, что должно происходить в моделируемой системе.
Давайте подробнее рассмотрим различные типы диаграмм UML, которые относятся к каждой категории:
1. Структурные диаграммы UML
2. Поведенческие диаграммы UML
Модели базы данных
UML также завоевывает популярность как нотация для моделирования баз данных. Эти модели являются отличным визуальным инструментом для проведения мозгового штурма, создания диаграмм в свободной форме и совместной работы над идеями.
Хотя UML не имеет спецификаций для моделирования данных, он может быть полезным инструментом для построения диаграмм, тем более что данные из баз данных могут использоваться в объектно-ориентированном программировании.
Давайте рассмотрим различные типы моделей баз данных, которые вы можете создать:
- Иерархическая модель базы данных. Старые добрые модели данных организованы в древовидную структуру. Дерево состоит из нескольких групп, называемых сегментами. Она использует отношения «один ко многим». Доступ к данным также предсказуем.
- Сетевая модель. Эта модель имеет форму графа, где типы отношений — это дуги, а типы объектов — узлы. В отличие от других моделей баз данных, схема сетевых моделей не ограничивается решеткой или иерархией.
- Объектно-ориентированная модель базы данных. Эта модель использует коллекцию объектов или повторно используемых программных элементов со связанными функциями и методами. Например, мультимедийная база данных может иметь изображения, которые не сохраняются в реляционной базе данных, или гипертекстовая база данных, позволяющая ссылаться на другие объекты.
- Реляционная модель. Здесь данные структурированы с использованием отношений или решетчатых математических структур, которые имеют столбцы и строки. Они могут рассматриваться как таблица.
- Объектно-реляционная модель. Как следует из названия, эта модель представляет собой комбинацию двух упомянутых выше. Она поддерживает объекты, классы, наследование и другие объектно-ориентированные элементы, но при этом поддерживает и типы данных, табличные структуры и многое другое как реляционная модель данных.
- Модель «сущность-связи». Она состоит из типов объектов (люди, места или предметы). Модель показывает связи, которые могут существовать между ними. Определяя сущности, их атрибуты и показывая связи между ними, диаграмма ER иллюстрирует логическую структуру баз данных.
- Модель документа. Она предназначена для хранения и управления документами или полуструктурированными данными, а не атомарными данными. Имеет древовидную структуру, в которой каждый узел является объектом, представляющим часть документа.
- Модель «сущность-атрибут-значение». Модели EAV или открытой схемы, данные записываются в виде трех столбцов:
- Сущность (что описывается)
- Атрибут или параметр (например, имя, описание, тип данных)
- Значение атрибута.
- Схема «звезда». Это простейшая версия многомерной модели, в которой данные располагаются в измерениях и фактах. Она используется в бизнес-аналитике и хранилищах данных, поскольку подходит для запросов больших массивов данных.
Упрощение с помощью программного обеспечения
Создаете ли вы модели баз данных или диаграммы UML, использование программных инструментов упрощает и улучшает этот процесс. Обязательно выберите инструменты, которые позволят вам:
- Создавать профессиональные диаграммы с готовыми шаблонами и тысячами форм в экосистеме контента, которая соответствует отраслевым стандартам, таким как UML 2.5, а также BPMN 2.0 и IEEE.
- Внедрить диаграммы с помощью наложения данных, символов, цветов и графики, чтобы упростить их интерпретацию, включая одноступенчатую визуализацию данных в Excel.
- Сотрудничайте с коллегами, используя совместное редактирование, комментирование и аннотации.
- Установите одну версию модели и получите доступ к диаграммам практически из любого места, используя браузер или приложение на устройстве.
При разработке программного обеспечения и непрограммируемых систем во многих отраслях использование визуальных UML-диаграмм может играть важную роль в построении поведенческих процессов и структур. Узнайте больше о создании диаграмм UML с помощью программного обеспечения при помощи пошаговой инструкции: руководства.
Сведения об авторе
Задача команды Центра роста — помочь вам начать собственный бизнес, успешно управлять им и развивать его.
Начать работу с Visio
Visio поможет превратить ваши идеи, данные и процессы в наглядные схемы, которыми вы сможете делиться с любого устройства, где бы вы ни находились.
Диаграмму вариантов использования есть смысл строить во время изучения технического задания, она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных последовательностей действий (потока событий), которые выполняет пользователь при работе с системой. Спецификация затем станет основой для тестирования и документации, а на следующих этапах проектирования она дополняется и оформляется в виде диаграммы (в рамках ICONIX используется диаграмма последовательности, но в UML для этого имеются также диаграммы деятельности). Кроме того, use-case диаграмма достаточно проста, чтобы ее мог понять заказчик, следовательно вы можете использовать ее для согласования ТЗ (ведь диаграмма описывает функциональные требования к системе).
На диаграмме использования изображаются:
На мой взгляд, наиболее правильный порядок построения диаграммы следующий:
Сценарии являются очень важной частью диаграмм использования, хотя их формат и не регламентирован. Ряд авторов предлагает использовать псевдокод для представления сценария и даже сразу строить диаграммы деятельности или взаимодействия, но на мой взгляд, наиболее предпочтительным вариантом на этапе построения use-case диаграмм является текстовый, описывающий систему с точки зрения пользователя (т.к. именно этот формат будет наиболее понятен заказчику, с которым вам предстоит согласовывать техническое задание).
- для учеников:
- выбор подготовленного учителем блока заданий;
- выполнение заданий;
- подготовка для учеников блоков заданий;
- добавление в систему ученика;
- просмотр отчетов.
Очевидно, несмотря на то, что заказчик очень подробно описал некоторые детали, мы не можем не только приступить к реализации задачи, но даже приблизительно оценить стоимость и сроки выполнения. Из такого задания не понятно, например, что должны содержать отчеты. Однако, мы сразу можем выделить две группы пользователей и несколько видов их деятельности.
![use-case-example]()
Пример диаграммы использования
Сплошные линии на диаграмме представляют собой отношения ассоциации, отражающие возможность использования актором прецедента. После того, как определен набор вариантов использования, можно приступать к составлению сценариев. Сценарии должны описываться с точки зрения пользователя, при этом важно описывать взаимодействие пользователя с элементами интерфейса. Так например сценарий прецедента регистрации ученика мог бы выглядеть следующим образом:
Аналогичным образом должны быть прописаны все прецеденты, изображенные на диаграмме. Составлять сценарии нужно достаточно упорно чтобы описать все возможные варианты действий пользователя в системе. Заказчик может делать это с большим удовольствием, а программист за счет этого раньше узнает возможные пожелания заказчика (так из приведенного сценария он мог бы выяснить, что программа должна отображать всплывающие уведомления).
![use-case-include-example]()
Отношение включения на диаграмме использования
Отношение расширения отражает возможное присоединение одного варианта использования к другому в некоторой точке (точке расширения). При этом подчеркивается то, что расширяющий вариант использования выполняется лишь при определенных условиях и не является обязательным для выполнения основного прецедента. На диаграмме такой вид отношения изображается стрелкой, направленной к расширяемому прецеденту, в отдельном разделе которого может быть описана точка расширения, а условия расширения могут быть приведены в комментарии с ключевым словом Condition. Таким образом, расширение позволяет моделировать необязательное поведение системы, которое является условным и не изменяет поведение основного прецедента. Например отношение расширения нужно применить, если по техническому заданию требуется возможность удаления набора задач в прецеденте просмотра отчетов при условии, что все ученики решили этот набор.
![use-case-extend-example]()
Отношение расширения на диаграмме использования
Таким образом можно показать, что у учителя появляется возможность (но не обязанность) удалить набор задач при просмотре отчетов если все ученики выполнили этот набор.
На последней диаграмме используется символ комментария для задания условий расширения, при этом комментарий связывается пунктирной линией с отношением расширения, т.к. относится к нему. В ряде публикаций по UML и ICONIX предлагается описывать с помощью комментариев на диаграмме прецедентов:
- нефункциональные требования к системе (при этом используется стереотип <<requirement>>);
- сценарии вариантов использования (связывая комментарий с соответствующим прецедентом);
- детали реализации и другие выводы, к которым разработчики пришли в процессе обсуждения задачи (не все с этим согласны, т.к. use-case диаграмма показывается заказчику, которому не нужны детали).
Наиболее типичными ошибками при построении этого вида диаграмм являются:
- неправильное использование отношений расширения и включения, в том числе попытки использовать диаграммы для функциональной декомпозиции системы. Возникает из-за непонимания различий между этими двумя видами отношений и того, что use-case диаграмма должна выражать лишь требования к системе, а не детали ее реализации;
- разработка диаграммы с точки зрения программиста, а не пользователя. В сценариях должны использоваться названия элементов управления (видимые пользователю), но нежелательно изображать детали реализации (такие как менеджер событий), не понятные заказчику;
- не достаточная проработка сценариев:
- отсутствие или недостаточное количество альтернативных последовательностей, в которых должен быть учтен, в том числе, ввод некорректных данных в систему;
- описание действий пользователя без указания конкретных элементов интерфейса системы и отсутствие описаний реакции системы в сценариях.
Если следовать всем приведенным правилам составления диаграмм вариантов использования, с их помощью можно достаточно подробно проработать техническое задание чтобы оценить сроки и стоимость его выполнения, описать конкретные сценарии взаимодействия с системой, которые лягут в основу тестов и документации, и согласовать всё это с заказчиком.
В статье приведены основные возможности use-case диаграмм, по моему мнению их должно быть достаточно для разработки подавляющего большинства систем, при необходимости большее количество информации и примеров можно почерпнуть в следующей литературе:
Краткие сведения о диаграмме вариантов использования
Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом сценарием варианта использования или потоком событий ( flow of events ). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.
Достоинства модели вариантов использования заключаются в том, что она:
- определяет пользователей и границы системы;
- определяет системный интерфейс;
- удобна для общения пользователей с разработчиками;
- используется для написания тестов;
- является основой для написания пользовательской документации;
- хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).
Основные элементы диаграмм вариантов использования
![]()
Активный субъект ( actor ) отождествляется с чем-то или с кем-то, взаимодействующим с системой, т.е. играет определённую роль по отношению к системе, это может быть не обязательно пользователь будущей системы, также это может быть внешняя система.
![]()
Варианты использования (use cases) позволяют моделировать диалог между активным субъектом и системой и отображают функции системы. С каждым вариантом использования связан определенный поток событий, происходящих по мере выполнения соответствующих функций системы. При описании потока событий определяется, что необходимо осуществить, и игнорируются аспекты того, как это делается.
Между активным субъектом и вариантом использования устанавливаются связь ассоциация ( association relationship ), которая выполняет коммуникативную функцию, сообщая о взаимодействии субъекта с системой в рамках определенного варианта использования. Направление связи указывает, кто (субъект или система) является инициатором взаимодействия.
Помимо связей между субъектом и вариантом использования, связи могут устанавливаться и между вариантами использования. Связи бывают двух типов - включающими ( inclusive ) и расширяющими ( extensive ).Диаграмма вариантов использования отражает функциональные возможности и требования системы с использованием действующих лиц и вариантов использования. Варианты использования моделируют службы, задачи, функции, которые должна выполнять система. Варианты использования представляют функциональные возможности высокого уровня и то, как пользователь будет обращаться с системой. Варианты использования являются основными концепциями моделирования языка Unified Modeling.
В этом уроке UML Diagram вы узнаете больше о:
Зачем нужна схема использования?
Вариант использования состоит из вариантов использования, лиц или различных вещей, которые вызывают функции, называемые актерами, и элементов, отвечающих за реализацию вариантов использования. Диаграммы прецедентов отражают динамическое поведение работающей системы. Он моделирует, как внешняя сущность взаимодействует с системой, чтобы заставить ее работать. Диаграммы прецедентов отвечают за визуализацию внешних вещей, которые взаимодействуют с частью системы.
Обозначения диаграмм вариантов использования
Ниже приведены общие обозначения, используемые в диаграмме прецедентов:
Использование регистра:
Варианты использования используются для представления функций высокого уровня и того, как пользователь будет обращаться с системой. Вариант использования представляет отдельную функциональность системы, компонента, пакета или класса. Он обозначен овальной формой с названием варианта использования, написанным внутри овальной формы. Обозначение варианта использования в UML приведено ниже:
![]()
Актер:
![]()
Как нарисовать диаграмму вариантов использования?
Чтобы нарисовать диаграмму вариантов использования в UML, сначала необходимо тщательно проанализировать всю систему. Вы должны выяснить каждую функцию, предоставляемую системой. После того, как все функциональные возможности системы обнаружены, эти функциональные возможности преобразуются в различные варианты использования, которые будут использоваться в диаграмме вариантов использования.
После того, как актеры и варианты использования зачислены, вам необходимо изучить связь конкретного актера с вариантом использования или системой. Нужно определить общее количество способов взаимодействия актера с системой. Один субъект может взаимодействовать с несколькими вариантами использования одновременно или одновременно с несколькими вариантами использования.
Следующие правила должны соблюдаться при рисовании сценария использования для любой системы:
- Имя актера или сценарий использования должны быть значимыми и относиться к системе.
- Взаимодействие актера с вариантом использования должно быть определено четко и понятно.
- Аннотации должны использоваться везде, где они необходимы.
- Если сценарий использования или субъект имеют несколько связей, то должны отображаться только существенные взаимодействия.
Советы по составлению схемы использования
- Диаграмма вариантов использования должна быть максимально простой.
- Диаграмма вариантов использования должна быть полной.
- Диаграмма прецедентов должна представлять все взаимодействия с прецедентом.
- Если существует слишком много вариантов использования или участников, то должны быть представлены только основные варианты использования.
- Диаграмма прецедентов должна описывать хотя бы один модуль системы.
- Если диаграмма варианта использования велика, ее следует обобщить.
Пример диаграммы варианта использования
Следующая схема использования представляет работу системы управления студентами:
![]()
На приведенной выше диаграмме сценариев использования есть два актера: ученик и учитель. Всего существует пять вариантов использования, которые представляют специфическую функциональность системы управления студентами. Каждый актер взаимодействует с конкретным вариантом использования. Студент-актер может проверить посещаемость, расписание, а также тестовые отметки в приложении или системе. Этот субъект может выполнять только эти взаимодействия с системой, даже если в системе остаются другие варианты использования.
Не обязательно, чтобы каждый актер взаимодействовал со всеми вариантами использования, но это может произойти.
Второй актер по имени учитель может взаимодействовать со всеми функциями или вариантами использования системы. Этот актер также может обновлять посещаемость ученика и оценки ученика. Эти взаимодействия как студента, так и актера-учителя вместе подводят итог всего приложения управления студентами.
Когда использовать диаграмму прецедентов?
Диаграммы прецедентов представляют основные части системы и рабочий процесс между ними. В случае использования детали реализации скрыты от внешнего использования, только поток событий представлен.
С помощью диаграмм вариантов использования мы можем выяснить предварительные и последующие условия после взаимодействия с актером. Эти условия могут быть определены с использованием различных тестовых случаев.
В общем случае сценарии использования используются для:
- Анализ требований системы
- Визуальное программное обеспечение высокого уровня
- Захват функциональных возможностей системы
- Моделирование основной идеи системы
- Прямое и обратное проектирование системы с использованием различных тестовых случаев.
Варианты использования предназначены для передачи желаемой функциональности, поэтому точная область применения может варьироваться в зависимости от системы и цели создания модели UML.
Диаграмма вариантов использования отражает функциональные возможности и требования системы с использованием действующих лиц и вариантов использования. Варианты использования моделируют службы, задачи, функции, которые должна выполнять система. Варианты использования представляют функциональные возможности высокого уровня и то, как пользователь будет обращаться с системой. Варианты использования являются основными концепциями моделирования языка Unified Modeling.
В этом уроке UML Diagram вы узнаете больше о:
Зачем нужна схема использования?
Вариант использования состоит из вариантов использования, лиц или различных вещей, которые вызывают функции, называемые актерами, и элементов, отвечающих за реализацию вариантов использования. Диаграммы прецедентов отражают динамическое поведение работающей системы. Он моделирует, как внешняя сущность взаимодействует с системой, чтобы заставить ее работать. Диаграммы прецедентов отвечают за визуализацию внешних вещей, которые взаимодействуют с частью системы.
Обозначения диаграмм вариантов использования
Ниже приведены общие обозначения, используемые в диаграмме прецедентов:
Использование регистра:
Варианты использования используются для представления функций высокого уровня и того, как пользователь будет обращаться с системой. Вариант использования представляет отдельную функциональность системы, компонента, пакета или класса. Он обозначен овальной формой с названием варианта использования, написанным внутри овальной формы. Обозначение варианта использования в UML приведено ниже:
![]()
Актер:
![]()
Как нарисовать диаграмму вариантов использования?
Чтобы нарисовать диаграмму вариантов использования в UML, сначала необходимо тщательно проанализировать всю систему. Вы должны выяснить каждую функцию, предоставляемую системой. После того, как все функциональные возможности системы обнаружены, эти функциональные возможности преобразуются в различные варианты использования, которые будут использоваться в диаграмме вариантов использования.
После того, как актеры и варианты использования зачислены, вам необходимо изучить связь конкретного актера с вариантом использования или системой. Нужно определить общее количество способов взаимодействия актера с системой. Один субъект может взаимодействовать с несколькими вариантами использования одновременно или одновременно с несколькими вариантами использования.
Следующие правила должны соблюдаться при рисовании сценария использования для любой системы:
- Имя актера или сценарий использования должны быть значимыми и относиться к системе.
- Взаимодействие актера с вариантом использования должно быть определено четко и понятно.
- Аннотации должны использоваться везде, где они необходимы.
- Если сценарий использования или субъект имеют несколько связей, то должны отображаться только существенные взаимодействия.
Советы по составлению схемы использования
- Диаграмма вариантов использования должна быть максимально простой.
- Диаграмма вариантов использования должна быть полной.
- Диаграмма прецедентов должна представлять все взаимодействия с прецедентом.
- Если существует слишком много вариантов использования или участников, то должны быть представлены только основные варианты использования.
- Диаграмма прецедентов должна описывать хотя бы один модуль системы.
- Если диаграмма варианта использования велика, ее следует обобщить.
Пример диаграммы варианта использования
Следующая схема использования представляет работу системы управления студентами:
![]()
На приведенной выше диаграмме сценариев использования есть два актера: ученик и учитель. Всего существует пять вариантов использования, которые представляют специфическую функциональность системы управления студентами. Каждый актер взаимодействует с конкретным вариантом использования. Студент-актер может проверить посещаемость, расписание, а также тестовые отметки в приложении или системе. Этот субъект может выполнять только эти взаимодействия с системой, даже если в системе остаются другие варианты использования.
Не обязательно, чтобы каждый актер взаимодействовал со всеми вариантами использования, но это может произойти.
Второй актер по имени учитель может взаимодействовать со всеми функциями или вариантами использования системы. Этот актер также может обновлять посещаемость ученика и оценки ученика. Эти взаимодействия как студента, так и актера-учителя вместе подводят итог всего приложения управления студентами.
Когда использовать диаграмму прецедентов?
Диаграммы прецедентов представляют основные части системы и рабочий процесс между ними. В случае использования детали реализации скрыты от внешнего использования, только поток событий представлен.
С помощью диаграмм вариантов использования мы можем выяснить предварительные и последующие условия после взаимодействия с актером. Эти условия могут быть определены с использованием различных тестовых случаев.
В общем случае сценарии использования используются для:
- Анализ требований системы
- Визуальное программное обеспечение высокого уровня
- Захват функциональных возможностей системы
- Моделирование основной идеи системы
- Прямое и обратное проектирование системы с использованием различных тестовых случаев.
Варианты использования предназначены для передачи желаемой функциональности, поэтому точная область применения может варьироваться в зависимости от системы и цели создания модели UML.
Читайте также:
