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

Введение

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

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

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

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

Что такое 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обычно делятся на две основные категории:

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

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

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

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

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

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

Классы
Атрибуты
Операции
Интерфейсы
Связи
Видимость
Множественность

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

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

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

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

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

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

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

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

Моделирования предметной области
Объектно-ориентированное проектирование
Планирование баз данных и приложений
Определение обязанностей
Объяснение наследования и интерфейсов

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

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

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

Например:

customerA:Customer
name = "Alex"

order1001:Order
status = "Paid"

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

Состояние объектов во время выполнения
Примеры связей данных
Конкретный сценарий
Как связаны экземпляры классов

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

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

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

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

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

Пример:

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

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

Микросервисных архитектур
Систем, ориентированных на сервисы
Проектирования API
Архитектуры приложений
Показа границ сервисов и зависимостей

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

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

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

Клиентские устройства
Веб-серверы
Серверы приложений
Базы данных серверы
Облачные узлы
Контейнеры
Сетевые соединения
Развёрнутые программные артефакты

Пример:

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

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

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

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

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

пользователь
каталог
заказ
оплата
уведомление

Пример:

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

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

Организации больших моделей
Показа зависимостей модулей
Выявления архитектурных слоев
Предотвращения нежелательной связанности

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

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

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

Внутренние части
Порты
Соединители
Внутренние взаимодействия
Отношения между внутренними элементами

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

OrderService
OrderRepository
Служба оплаты
Служба уведомлений

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

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

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

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

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

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

Веб-приложения
Корпоративная архитектура
Системы реального времени
Встраиваемые системы
Специфические фреймворки программирования
Моделирование для конкретных отраслей

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

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

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

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

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

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

Клиент
Администратор
Платёжный шлюз
Служба доставки

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

Регистрация аккаунта
Войти
Просмотр товаров
Добавить товар в корзину
Оформить заказ
Оплатить
Отслеживание доставки
Управление товарами

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

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

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

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

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

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

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

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

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

Действия
Решения
Слияния
Циклы
Параллельные действия
Начальные и конечные узлы
Полосы ответственности

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

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

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

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

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

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

Участники
Линии жизни
Сообщения
Полосы активации
Возвратные сообщения
Условия
Циклы
Альтернативы
Параллельные взаимодействия

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

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

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

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

Объекты
Связи между объектами
Нумерованные сообщения
Структура взаимодействия

Пример:

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

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

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

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

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

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

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

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

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

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

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

Жизненные циклы заказов
Состояния пользовательских аккаунтов
Статусы рабочих процессов
Поведение устройства
Состояния сетевого соединения
Процессы согласования

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

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

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

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

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

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

Сигналом устройства
Состоянием контроллера
Значением датчика
Реакцией в течение определённого временного интервала

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

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

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

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

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

Аутентификация клиента
Выбор товара
Взаимодействие при оформлении заказа
Авторизация платежа
Исполнение заказа

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

Связи UML

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

Ассоциация

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

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

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

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

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

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

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

Обобщение

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

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

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

Зависимость

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

OrderService - - - -> PaymentGateway

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

Агрегация

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

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

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

Композиция

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

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

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

Реализация

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

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

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

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

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

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

Клиент
Администратор
Платёжный шлюз
Служба доставки

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

Создать аккаунт
Просмотр товаров
Добавить товары в корзину
Оформить заказ
Оплатить заказ
Отслеживание доставки
Управление запасами

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

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

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

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

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

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

Клиент отправляет корзину.
Веб-приложение отправляет запрос в сервис заказов.
Сервис заказов проверяет товары.
Сервис оплаты авторизует платеж.
Заказ сохраняется.
Сервис доставки уведомляется.
Служба уведомлений отправляет подтверждение по электронной почте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка

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

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

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

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

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

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

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

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

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

Создайте новый проект.
Организуйте модель в пакеты, такие как “Требования, Модель предметной области, Сервисы“, и “Развертывание.
Создайте диаграмму вариантов использования для фиксации функциональности системы.
Добавьте диаграмму деятельности или последовательности для важных рабочих процессов.
Создайте диаграмму классов для модели предметной области.
Добавьте диаграммы компонентов и развертывания для архитектуры.
Обсудите диаграммы с заинтересованными сторонами.
Обновляйте модель по мере эволюции системы.
Экспортируйте диаграммы или создавайте документацию при необходимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отношение к 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 繁體中文

Введение

Что такое UML?

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

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

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

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

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

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

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

Класс

Объект

Атрибут

Операция

Актер

Интерфейс

Связь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связи UML

Ассоциация

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

Обобщение

Зависимость

Агрегация

Композиция

Реализация

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

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

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

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

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

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

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

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

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

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

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

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

Разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение