Практическое руководство по UML с использованием Visual Paradigm и VPasCode

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

В этом руководстве в качестве постоянного примера используется система онлайн-покупок. Оно охватывает основные типы диаграмм UML и рабочий процесс с использованием Visual Paradigm для визуального моделирования и VPasCode для диаграмм на основе текста.

1. Начните с вопроса, на который должна отвечать ваша диаграмма

Перед рисованием решите, что читатель должен понять:

• Что могут делать пользователи? Используйте диаграмму вариантов использования.

• Что происходит в ходе сценария? Используйте диаграмму последовательности или диаграмму деятельности.

• Какие концепции и отношения составляют предметную область? Используйте диаграмму классов.

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

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

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

2. Семейства диаграмм UML

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

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

3. Наиболее полезные диаграммы с примером электронной коммерции

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

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

Используйте<<include>> когда вариант использования всегда вызывает другое требуемое поведение. Используйте<<extend>> для опционального или условного поведения, которое дополняет базовый вариант использования. Сохраняйте границы системы четкими, чтобы читатели могли различать систему и внешних акторов.

Диаграмма деятельности: рабочий процесс и решения

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

1. Проверить корзину и адрес.

2. Рассчитать доставку и налог.

3. Создать заказ в статусе ожидания.

4. Запросить авторизацию платежа.

5. Если платеж успешен, подтвердить заказ и уведомить службу исполнения.

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

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

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

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

@startuml
actor Customer
participant "Storefront" as UI
participant "Order Service" as Orders
participant "Inventory Service" as Inventory
participant "Payment Provider" as Payment

Customer -> UI: submit checkout
UI -> Orders: placeOrder(cart, address)
Orders -> Inventory: reserve(items)

alt items available
    Inventory --> Orders: reservation confirmed
    Orders -> Payment: authorize(total)
    alt payment approved
        Payment --> Orders: approved
        Orders --> UI: order confirmed
        UI --> Customer: show confirmation
    else payment declined
        Payment --> Orders: declined
        Orders -> Inventory: release reservation
        Orders --> UI: payment failed
        UI --> Customer: show payment error
    end
else items unavailable
    Inventory --> Orders: reservation failed
    Orders --> UI: item unavailable
    UI --> Customer: show availability error
end
@enduml

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

Диаграмма классов: структура предметной области

Диаграммы классов описывают типы и их взаимосвязи. Небольшая модель заказа может содержать:

• Клиент

• Заказ

• позиция заказа

• Товар

• Платеж

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

Общие типы связей:

• Ассоциация: общая структурная связь.

• Наследование/специализация: один класс является специализированным вариантом другого.

• Агрегация: связь «целое–часть», при которой части могут существовать независимо; использовать экономно.

• Композиция: сильная связь «целое–часть», при которой жизненный цикл части привязан к жизненному циклу целого.

• Зависимость: один элемент использует или зависит от другого.

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

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

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

Ожидание → Ожидание оплаты → Подтверждено → Выполнено

Оно также может перейти в Отменено или Ошибка оплаты. Подписывайте переходы триггерными событиями или условиями, например, оплатаПодтверждена или [stockAvailable]. Эта диаграмма может выявить недопустимые переходы — например, можно ли отменить уже выполненное заказ.

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

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

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

4. Хорошо моделируйте: практические соглашения

• Присваивайте каждой диаграмме чёткое название и одну конкретную цель.

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

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

• Включайте только те детали, которые отвечают на вопрос диаграммы.

• Подписывайте важные связи и потоки сообщений.

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

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

• Поддерживайте согласованность имён и ответственности между диаграммами.

• Различайте подтверждённое, предлагаемое и ещё неизвестное.

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

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

5. Использование Visual Paradigm

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

Практический рабочий процесс:

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

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

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

4. Добавить диаграммы поведения для сценариев, несущих наибольшие риски или неопределённость.

5. Создать модель классов на основе предметных концепций и их правил.

6. Добавить представления компонентов и развёртывания если архитектура или размещение во времени выполнения требуют обсуждения.

7. Согласовать с заинтересованными сторонами. Проверить имена, области, альтернативные потоки и кардинальности.

8. Экспортировать или поделиться диаграммами в форматах, подходящих для обзоров и документации.

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

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

6. Использование VPasCode

VPasCode — это редактор диаграмм на основе кода, работающий в браузере, от Visual Paradigm. В описании продукта указывается поддержка текстовых форматов диаграмм, включая PlantUML и Mermaid, с живым рендерингом; также описываются возможности экспорта, такие как SVG и PNG.

Простой рабочий процесс:

1. Откройте VPasCode и выберите язык диаграмм, например PlantUML.

2. Напишите или вставьте скрипт диаграммы.

3. Проверяйте предпросмотр рендеринга по мере редактирования.

4. Уточните имена, связи, компоновку и пути обработки ошибок.

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

6. Сохраните исходный скрипт вместе с проектом, если вам нужен текстовый журнал, который можно просматривать и версионировать.

VPasCode хорошо подходит для быстрых черновиков, диаграмм документации и команд, предпочитающих текстовое редактирование. Графическая модель Visual Paradigm полезна, когда вы хотите визуально манипулировать элементами модели и организовывать диаграммы в рамках более крупного проекта моделирования. Эти два подхода могут дополнять друг друга, но не следует предполагать, что каждая диаграмма или модель передаётся между ними с идеальной двусторонней точностью; проверяйте любой конвертированный результат в вашем рабочем процессе.

7. Полезный сквозной рабочий процесс

Для функции оформления заказа лёгкая последовательность моделирования может выглядеть так:

1. Вариант использования: определите, кто может оформить заказ и какие внешние системы участвуют.

2. Деятельность: отобразите поток оформления заказа и его решения.

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

4. Класс: определите понятия заказа, позиции заказа, товара и оплаты, а также их правила.

5. Машина состояний: укажите допустимый жизненный цикл заказа.

6. Компонент: покажите, какие сервисы несут эти обязанности.

7. Развёртывание: задокументируйте размещение во время выполнения, если решения об инфраструктуре имеют значение.

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

8. Распространённые ошибки

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

• Смешение активностей и последовательностей: активности подчёркивают рабочий процесс; последовательности подчёркивают сообщения во времени.

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

• Использование include и extend в качестве украшения: они выражают конкретные отношения между случаями использования.

• Игнорирование альтернативных путей: сбои и отмены часто выявляют важные требования.

• Отнесение к диаграмме как к спецификации: явно документируйте важные бизнес-правила, допущения и ограничения.

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

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

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