de_DEen_USes_ESfa_IRfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Язык моделирования (UML): Комплексное руководство по диаграммам, концепциям и визуальной парадигме

Введение

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

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

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

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

UML управляется как отраслевой стандарт Группой управления объектами (OMG) и также принят в рамках международных стандартов. Современный UML обычно относится к версии UML 2.x, которая определяет широкий набор структурных и поведенческих диаграмм. Например, UML 2.2 определяла 14 типов диаграмм, поровну разделенных между структурным и поведенческим моделированием.

Что такое UML?

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

  • Компоненты системы

  • Классы и объекты

  • Требования пользователей

  • Рабочие процессы и бизнес-процессы

  • Сообщения, обмениваемые между объектами

  • Состояния системы и переходы

  • Среды развертывания программного обеспечения

  • Зависимости между пакетами и компонентами

Цель UML — не замена исходного кода. Напротив, она помогает командам обдумывать и обсуждать систему до, во время и после её реализации.

Модель UML может создаваться на разных уровнях детализации:

  • Концептуальный уровень:Описывает основные бизнес-концепции без деталей реализации.

  • Уровень анализа:Исследует требования, обязанности и поведение системы.

  • Уровень проектирования:Определяет классы, интерфейсы, компоненты и взаимодействия.

  • Уровень реализации:Представляет детали, которые тесно соответствуют исходному коду и инфраструктуре развертывания.

Почему UML важна?

UMLполезна, потому что программные системы могут стать трудными для понимания, если они описаны только через исходный код или объёмные письменные документы.

Упрощает сложные системы

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

Улучшает коммуникацию

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

Поддерживает планирование

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

Помогает документировать программное обеспечение

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

Стимулирует создание более качественного дизайна

Создание модели заставляет команду задуматься над вопросами, такими как:

  • Какой объект отвечает за выполнение задачи?

  • Как связаны между собой компоненты?

  • Что происходит при сбое операции?

  • Какие классы зависят друг от друга?

  • Как система реагирует на различные события?

Ключевые концепции UML

Справочная карточка нотации UML, иллюстрирующая восемь ключевых понятий: Класс, Объект, Атрибут, Операция, Актер, Интерфейс, Отношения и Множественность с примерами.

Класс

Класс — это шаблон, определяющий атрибуты и операции, общие для группы объектов.

Например, класс «Заказ» может содержать:

  • Атрибуты: orderId, orderDate, и статус

  • Операции: calculateTotal() и cancelOrder()

Объект

Объект — это фактический экземпляр класса. Если Заказ — это класс, order1001 может быть конкретным объектом, созданным из этого класса.

Атрибут

Атрибут представляет данные, хранящиеся в классе или объекте.

Примеры включают:

  • имя

  • цена

  • emailAddress

  • orderStatus

Операция

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

Примеры включают:

  • addItem()

  • submitPayment()

  • sendNotification()

Актер

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

Примеры включают:

  • Клиент

  • Администратор

  • Платежный шлюз

  • Система склада

Интерфейс

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

Связь

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

Множественность

Множественность определяет, сколько объектов может участвовать в связи.

Типичные примеры включают:

  • 1: Ровно один

  • 0..1: Ноль или один

  • *: Много

  • 1..*: Один или более

  • 0..*: Ноль или более

Например, один клиент может сделать ноль или много заказов. Это можно представить следующим образом:

Клиент 1 -------- 0..* Заказ

Категории диаграмм UML

Диаграммы UMLобычно делятся на две основные категории:

  1. Структурные диаграммы

  2. Поведенческие диаграммы

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

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

Структурные диаграммы UML

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

1. Диаграмма классов

Диаграмма классов UML, иллюстрирующая систему книжного магазина с классами, такими как Книга, Клиент и Заказ, показывающая отношения, такие как агрегация и обобщение.

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

  • Классы

  • Атрибуты

  • Операции

  • Интерфейсы

  • Связи

  • Видимость

  • Множественность

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

Клиент
- customerId
- name
+ placeOrder()

Заказ
- orderId
- orderDate
- status
+ calculateTotal()

Товар
- productId
- name
- price
+ updatePrice()

Возможные связи включают:

Клиент 1 -------- 0..* Заказ
Заказ 1 -------- 1..* Товар

В более детальной модели может быть введен OrderItem между Заказ и Товар.

Классовые диаграммы полезны для:

  • Моделирования предметной области

  • Объектно-ориентированное проектирование

  • Планирование баз данных и приложений

  • Определение обязанностей

  • Объяснение наследования и интерфейсов

Диаграмма классов описывает классы в целом, тогда как диаграмма объектов показывает конкретные экземпляры этих классов. Visual Paradigm описывает диаграммы классов как модели классов, атрибутов, операций и отношений внутри объектно-ориентированной системы.

2. Диаграмма объектов

Диаграмма объектов показывает снимок системы в определённый момент времени. Она представляет реальные экземпляры объектов, а не общие классы.

Диаграмма UML, сравнивающая структуру класса с конкретным снимком экземпляра объекта, иллюстрирующая атрибуты, ассоциации и отношения наследования.

Например:

customerA:Customer
name = "Alex"

order1001:Order
status = "Paid"

Диаграмма объектов полезна, когда необходимо продемонстрировать:

  • Состояние объектов во время выполнения

  • Примеры связей данных

  • Конкретный сценарий

  • Как связаны экземпляры классов

Диаграмма классов может показать, что клиент может разместить множество заказов. Диаграмма объектов может показать, что customerA в настоящее время владеет order1001 и order1002.

3. Диаграмма компонентов

Компонентная диаграмма UML, показывающая архитектуру платформы доставки еды с сервисами Ресторан, Заказ, Оплата, Доставка и Уведомления, соединенными через интерфейсы.

Диаграмма компонентов показывает организацию и зависимости заменяемых программных компонентов.

Диаграмма компонентов электронной коммерции может включать:

  • Веб-приложение

  • Сервис заказов

  • Сервис продуктов

  • Сервис платежей

  • Сервис уведомлений

  • База данных

Пример:

Веб-приложение --> Сервис заказов
Сервис заказов --> Сервис платежей
Сервис заказов --> Сервис уведомлений
Сервис заказов --> База данных заказов

Диаграммы компонентов особенно полезны для:

  • Микросервисных архитектур

  • Систем, ориентированных на сервисы

  • Проектирования API

  • Архитектуры приложений

  • Показа границ сервисов и зависимостей

4. Диаграмма развертывания

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

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

Это может отображать:

  • Клиентские устройства

  • Веб-серверы

  • Серверы приложений

  • Базы данных серверы

  • Облачные узлы

  • Контейнеры

  • Сетевые соединения

  • Развёрнутые программные артефакты

Пример:

Устройство клиента
       |
       v
Веб-сервер
       |
       v
Сервер приложений
       |
       v
Сервер базы данных

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

5. Диаграмма пакетов

Пакетная диаграмма UML, показывающая подсистему LearningPlatform с внутренними пакетами, внешними зависимостями и отношениями обобщения.

Диаграмма пакетов группирует связанные элементы модели в пакеты и показывает зависимости между этими пакетами.

Проект может содержать пакеты, такие как:

  • пользователь

  • каталог

  • заказ

  • оплата

  • уведомление

Пример:

order --> user
order --> catalog
order --> payment
payment --> notification

Диаграммы пакетов полезны для:

  • Организации больших моделей

  • Показа зависимостей модулей

  • Выявления архитектурных слоев

  • Предотвращения нежелательной связанности

6. Диаграмма составной структуры

Диаграмма развертывания UML, показывающая веб-сервер, развертывающий app.jar в JVM, и сервер базы данных, размещающий schema.sql.

Диаграмма составной структуры показывает внутреннюю структуру класса, компонента или другого структурированного классификатора.

Она может отображать:

  • Внутренние части

  • Порты

  • Соединители

  • Внутренние взаимодействия

  • Отношения между внутренними элементами

Например, OrderController может содержать или соединяться с:

  • OrderService

  • OrderRepository

  • Служба оплаты

  • Служба уведомлений

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

7. Диаграмма профиля

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

Диаграмма профиля UML, иллюстрирующая расширение VehicleProfile со стереотипами Vehicle, Engine и Wheel, связанными с метаклассом Class.

Например, профиль может вводить стереотипы, такие как:

<<entity>>
<<controller>>
<<service>>
<<microservice>>

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

  • Веб-приложения

  • Корпоративная архитектура

  • Системы реального времени

  • Встраиваемые системы

  • Специфические фреймворки программирования

  • Моделирование для конкретных отраслей

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

Поведенческие диаграммы UML

Поведенческие диаграммы описывают динамическое поведение системы. Они показывают рабочие процессы, события, взаимодействия, изменения состояний и реакции.

1. Диаграмма вариантов использования

Диаграмма вариантов использования UML, показывающая актеров Клиент и Администратор, взаимодействующих с функциями системы, такими как Поиск товаров, Оформление заказа и Управление заказами.

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

Типичная система онлайн-покупок может включать следующих акторов:

  • Клиент

  • Администратор

  • Платёжный шлюз

  • Служба доставки

Возможные варианты использования включают:

  • Регистрация аккаунта

  • Войти

  • Просмотр товаров

  • Добавить товар в корзину

  • Оформить заказ

  • Оплатить

  • Отслеживание доставки

  • Управление товарами

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

Важные отношения включают:

  • Связь:Соединяет актора с вариантом использования.

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

  • Расширение: Показывает опциональное или условное поведение.

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

Например, Оформить заказ может включать Оплатить, в то время как Применить скидку может расширять Оформить заказ.

2. Диаграмма деятельности

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

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

Пример: оформление заказа

Начало
  |
Просмотр товаров
  |
Добавить товар в корзину
  |
Перейти к оформлению заказа
  |
Ввести платежные реквизиты
  |
Оплата успешна?
 /              
Нет              Да
|                |
Показать ошибку  Создать заказ
                  |
              Отправить подтверждение
                  |
                 Конец

Диаграммы деятельности могут представлять:

  • Действия

  • Решения

  • Слияния

  • Циклы

  • Параллельные действия

  • Начальные и конечные узлы

  • Полосы ответственности

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

3. Диаграмма последовательности

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

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

Пример: оформление заказа

Клиент -> Веб-приложение: Отправить заказ
Веб-приложение -> Служба заказов: createOrder()
Служба заказов -> Служба платежей: authorizePayment()
Служба платежей --> Служба заказов: paymentApproved
Служба заказов -> Служба уведомлений: sendConfirmation()
Служба заказов --> Веб-приложение: orderCreated
Веб-приложение --> Клиент: Отобразить подтверждение

Диаграммы последовательности содержат:

  • Участники

  • Линии жизни

  • Сообщения

  • Полосы активации

  • Возвратные сообщения

  • Условия

  • Циклы

  • Альтернативы

  • Параллельные взаимодействия

Они особенно полезны для объяснения вызовов API, взаимодействий между сервисами, потоков аутентификации и обработки ошибок.

4. Диаграмма коммуникации

Диаграмма коммуникации UML, показывающая объекты, такие как «Клиент» и «Веб-приложение», соединённые пронумерованными и подписанными сообщениями, демонстрирующими взаимодействие объектов.

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

Вместо того чтобы фокусироваться преимущественно на вертикальной временной шкале, как диаграмма последовательности, она фокусируется на:

  • Объекты

  • Связи между объектами

  • Нумерованные сообщения

  • Структура взаимодействия

Пример:

1: submitOrder()
Клиент ----------------> Веб-приложение

2: createOrder()
Веб-приложение ------------------> Сервис заказов

3: authorizePayment()
Сервис заказов -------------> Сервис платежей

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

5. Диаграмма машины состояний

Диаграмма машины состояний UML, иллюстрирующая переходы между состояниями «Ожидание», «Охлаждение» и «Нагрев» с вложенным состоянием «Активно».

Диаграмма машины состояний показывает, как объект или система изменяет своё состояние в ответ на события.

Заказ может проходить через следующие состояния:

Новый -> Ожидание оплаты -> Оплачен -> Отгружен -> Доставлен
                  |
                  v
              Отменён

Переход может быть помечен событием или условием:

Ожидание оплаты -- paymentApproved --> Оплачен
Ожидание оплаты -- paymentFailed --> Оплата не прошла

Диаграммы машины состояний полезны для:

  • Жизненные циклы заказов

  • Состояния пользовательских аккаунтов

  • Статусы рабочих процессов

  • Поведение устройства

  • Состояния сетевого соединения

  • Процессы согласования

Они особенно ценны, когда поведение объекта сильно зависит от его текущего состояния.

6. Диаграмма временных зависимостей

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

Диаграмма временных зависимостей показывает, как состояние или значение одного или нескольких элементов изменяется во времени.

Она часто используется для:

  • Системы реального времени

  • Встраиваемые системы

  • Протоколы связи

  • Координация аппаратного и программного обеспечения

  • Взаимодействия, чувствительные к производительности

Например, диаграмма временных зависимостей может показать взаимосвязь между:

  • Сигналом устройства

  • Состоянием контроллера

  • Значением датчика

  • Реакцией в течение определённого временного интервала

7. Диаграмма обзора взаимодействия

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

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

Она может показывать:

  • Порядок основных взаимодействий

  • Решения между фрагментами взаимодействия

  • Параллельные пути взаимодействия

  • Ссылки на диаграммы последовательности или коммуникации

Например, обзор взаимодействия для онлайн-заказа может соединять:

  1. Аутентификация клиента

  2. Выбор товара

  3. Взаимодействие при оформлении заказа

  4. Авторизация платежа

  5. Исполнение заказа

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

Связи UML

Понимание связей UML необходимо для создания содержательных диаграмм.

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

Ассоциация

Ассоциация представляет структурную связь между двумя элементами.

Клиент -------- Заказ

Это указывает на то, что клиенты и заказы связаны.

Направленная ассоциация

Направленная ассоциация показывает возможность навигации в одном направлении.

Заказ ------> Оплата

Это предполагает, что заказ знает о платёжном объекте или использует его, тогда как обратное может быть неверным.

Обобщение

Обобщение представляет наследование или специализацию.

       Пользователь
      /    
Клиент  Администратор

Здесь, Клиент и Администратор являются специализированными типами Пользователь.

Зависимость

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

OrderService - - - -> PaymentGateway

Изменение в шлюзе оплаты может повлиять на сервис заказов.

Агрегация

Агрегация представляет собой отношение «целое-часть», при котором части могут существовать независимо.

Команда ◇------ Игрок

Игрок может продолжать существовать даже в случае расформирования команды.

Композиция

Композиция представляет собой сильную связь «целое-часть». Части, как правило, зависят от целого в течение своего жизненного цикла.

Заказ ◆------ Позиция заказа

Позиция заказаПозиция заказа может рассматриваться как часть заказа и может не иметь смысла вне этого заказа.

Реализация

Реализация указывает на то, что класс или компонент реализует интерфейс.

Сервис оплаты - - -|> Обработчик платежей

Сервис оплатыСервис оплаты предоставляет поведение, определённое интерфейсомОбработчик платежей.

Пример UML: Система онлайн-покупок

Рассмотрим приложение для онлайн-покупок.

Основные акторы

  • Клиент

  • Администратор

  • Платёжный шлюз

  • Служба доставки

Основные сценарии использования

  • Создать аккаунт

  • Просмотр товаров

  • Добавить товары в корзину

  • Оформить заказ

  • Оплатить заказ

  • Отслеживание доставки

  • Управление запасами

Возможные классы

Клиент
Товар
Корзина
Элемент корзины
Заказ
Элемент заказа
Оплата
Доставка

Возможные сервисные компоненты

Сервис пользователей
Сервис каталога
Сервис корзины
Сервис заказов
Сервис оплаты
Сервис доставки
Сервис уведомлений

Пример взаимодействия

Когда клиент оформляет заказ:

  1. Клиент отправляет корзину.

  2. Веб-приложение отправляет запрос в сервис заказов.

  3. Сервис заказов проверяет товары.

  4. Сервис оплаты авторизует платеж.

  5. Заказ сохраняется.

  6. Сервис доставки уведомляется.

  7. Служба уведомлений отправляет подтверждение по электронной почте.

Этот единственный бизнес-процесс может быть представлен с помощью нескольких диаграмм UML:

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

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

  • Диаграмма последовательности: показывает сообщения между службами.

  • Классовая диаграмма: показывает Клиент, Заказ, Товар, а также связанные классы.

  • Компонентная диаграмма: показывает задействованные службы.

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

Как выбрать правильную диаграмму UML

Цель моделирования Рекомендуемая диаграмма UML
Показать классы и их взаимосвязи Классовая диаграмма
Показать реальные экземпляры объектов Диаграмма объектов
Описание функциональности системы Диаграмма вариантов использования
Моделирование бизнес-процесса или рабочего процесса системы Диаграмма деятельности
Показ обмениваемых сообщений во времени Диаграмма последовательности
Показ взаимодействия объектов Диаграмма коммуникации
Показ жизненного цикла и изменений состояния Диаграмма автомата состояний
Показ программных модулей или сервисов Диаграмма компонентов
Показ физической развертки Диаграмма развертки
Организация элементов модели Диаграмма пакетов
Показ внутренних частей классификатора Диаграмма составной структуры
Показ изменений во времени Диаграмма временных зависимостей
Обобщение нескольких взаимодействий Диаграмма обзора взаимодействий
Расширение UML для специализированной предметной области Диаграмма профиля

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

UML и жизненный цикл разработки программного обеспечения

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

Анализ требований

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

Анализ системы

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

Архитектурное проектирование

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

Детальное проектирование

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

Разработка

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

Тестирование

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

Техническое обслуживание

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

Создание диаграмм UML с помощью Visual Paradigm

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

Начало работы над проектом UML

Практический рабочий процесс в Visual Paradigm выглядит следующим образом:

  1. Создайте новый проект.

  2. Организуйте модель в пакеты, такие как “Требования, Модель предметной области, Сервисы“, и “Развертывание.

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

  4. Добавьте диаграмму деятельности или последовательности для важных рабочих процессов.

  5. Создайте диаграмму классов для модели предметной области.

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

  7. Обсудите диаграммы с заинтересованными сторонами.

  8. Обновляйте модель по мере эволюции системы.

  9. Экспортируйте диаграммы или создавайте документацию при необходимости.

Создание диаграммы классов

Чтобы создать диаграмму классов:

  1. Создайте новую диаграмму классов.

  2. Добавьте основные классы предметной области.

  3. Добавьте атрибуты и операции.

  4. Свяжите классы с помощью соответствующих отношений.

  5. Укажите кратности.

  6. Укажите наследование и интерфейсы там, где это необходимо.

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

  8. Проверьте модель на соответствие требованиям.

Например, диаграмма классов для интернет-магазина может содержать Клиент, Заказ, Товар, Оплата, и Отгрузка.

Создание диаграммы вариантов использования

Диаграмма вариантов использования может быть создана следующим образом:

  1. Определение внешних акторов.

  2. Перечисление основных функций системы.

  3. Добавление границы системы.

  4. Размещение вариантов использования внутри границы.

  5. Соединение акторов с вариантами использования, в которых они участвуют.

  6. Добавление отношений «включать» или «расширять» только тогда, когда они уточняют повторное использование или опциональное поведение.

Создание диаграммы последовательности

При создании диаграммы последовательности:

  1. Определите моделируемый сценарий.

  2. Добавьте актора или инициирующий компонент.

  3. Добавьте участвующие объекты или сервисы.

  4. Расположите их слева направо.

  5. Добавьте сообщения в хронологическом порядке.

  6. Моделируйте альтернативы, циклы и условия ошибок.

  7. Проверьте, чтобы каждое сообщение соответствовало реалистичной ответственности.

Сотрудничество и документирование

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

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

Рекомендации по эффективному моделированию на UML

Моделируйте с целью

Каждая диаграмма должна отвечать на чёткий вопрос. Например:

  • Как клиент размещает заказ?

  • Какие сервисы зависят от сервис оплаты?

  • В какие состояния может перейти заказ?

  • Какие классы относятся к домену заказов?

Держите диаграммы сфокусированными

Избегайте размещения всей системы на одной диаграмме. Разделите большие модели на более мелкие представления для требований, структуры домена, поведения, архитектуры и развёртывания.

Используйте последовательные имена

Используйте одинаковые имена на всех диаграммах. Если одна диаграмма называет компонент «OrderService»,то другая не должна называть его «OrderManager»,если только это действительно разные элементы.

Выбирайте правильный уровень детализации

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

Избегайте ненужных связей

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

Показывайте кратность там, где это важно

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

Проверяйте диаграммы на соответствие требованиям

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

Используйте диаграммы как живую документацию

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

Комбинируйте взаимодополняющие диаграммы

Ни одна отдельная диаграмма UML не объясняет все аспекты системы. Диаграмма классов может показывать структуру, тогда как диаграмма последовательностей объясняет, как эта структура ведет себя в конкретном сценарии.

Распространенные ошибки, которых следует избегать

  • Отношение к UML как к исходному коду

  • Создание диаграмм без конкретной цели

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

  • Использование наследования там, где уместнее было бы композицию

  • Пропуск кратности в важных связях

  • Добавление слишком большого количества элементов на одну диаграмму

  • Использование некорректных связей include и extend

  • Немоделирование ошибок и альтернативных потоков

  • Разрешение разным диаграммам использовать несогласованные названия

  • Предположение о том, что диаграмма верна только потому, что она визуально организована

UML 2.x и количество диаграмм

Ранние версии UML обычно описывали меньшее количество типов диаграмм.UML 2.xрасширила язык и ввела или формализовала дополнительные диаграммы, включая:

  • Диаграмма составной структуры

  • Диаграмма коммуникации

  • Диаграмма обзора взаимодействия

  • Диаграмма временных характеристик

Она также переименовала диаграммы состояний (statechart diagrams) в диаграммы машин состояний. Распространенная классификация UML 2.x содержит 14 диаграмм: семь диаграмм структуры и семь диаграмм поведения. Группа диаграмм поведения включает диаграммы вариантов использования, деятельности, машин состояний, последовательностей, коммуникации, обзора взаимодействия и временных характеристик. Группа диаграмм структуры включает диаграммы классов, объектов, компонентов, составной структуры, развертывания, пакетов и профилей.

Следовательно, списки, описывающие UML 2.x как имеющую только 13 диаграмм, являются неполными в рамках общепринятой классификации из 14 диаграмм.

Заключение

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

Наиболее часто используемыми диаграммами обычно являются:

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

  • Диаграммы классов для статической структуры

  • Диаграммы деятельности для рабочих процессов

  • Диаграммы последовательностей для взаимодействий

  • Диаграммы компонентов для архитектуры

  • Диаграммы развертывания для инфраструктуры

  • Диаграммы автоматов состояний для поведения жизненного цикла

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

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

Эта статья также доступна на Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文