UML для аналитиков: экспертиза и практика применения
Ключевые тезисы
- UML (Unified Modeling Language) — это унифицированный графический язык для моделирования программного обеспечения, полезный на всех этапах: от бизнес-анализа до архитектурного проектирования.
- Основная ценность UML — возможность описать систему с разных точек зрения (viewpoints), что помогает выявить противоречия и нестыковки в требованиях.
- Аналитики чаще всего используют ограниченный, но эффективный набор диаграмм: вариантов использования (Use Case), последовательности (Sequence), деятельности (Activity) и классов (Class).
- Ключ к успеху — консистентность моделей и их адаптация под конкретных заинтересованных лиц (стейкхолдеров).
Основные концепции UML
UML как инструмент множественных точек зрения
- Точка зрения (viewpoint) — это представление системы под определённым углом (текстовое, статическое, динамическое).
- Сочетание разных представлений (текст, диаграммы) позволяет полнее описать требования и найти в них ошибки.
Две большие группы диаграмм
- Структурные (статические): показывают внутреннюю структуру системы и связи между элементами (диаграмма классов, компонентов, развёртывания).
- Диаграммы поведения (динамические): показывают, как система работает (диаграмма деятельности, последовательности, состояний).
- Диаграмма вариантов использования относится к поведенческим, так как описывает функционал системы, а не её внутреннюю структуру.
Ключевые диаграммы и практика их применения
Диаграмма последовательности (Sequence Diagram)
Назначение: Раскрывает «чёрный ящик» системы, показывая хронологию взаимодействия объектов (или систем) в рамках одного сценария.
Как создаётся:
- Готовится текстовый сценарий варианта использования.
- Выделяются ключевые объекты (часто из диаграммы классов).
- На диаграмме отображается последовательность вызовов и обмена сообщениями между этими объектами.
Основные кейсы использования:
- Моделирование интеграций между системами.
- Описание сложной внутренней логики сценария.
Типичные ошибки (антипаттерны):
- Избыточность: Попытка уместить все детали на одной диаграмме, что делает её нечитаемой.
- Несоответствие: Расхождение между шагами в текстовом сценарии и на диаграмме последовательности.
- Неполнота: Отсутствие деталей в передаваемых сообщениях (какой метод вызывается, какие данные передаются).
- Лишние объекты: Наличие на диаграмме объектов, не участвующих в автоматизированном сценарии (например, люди, звонящие друг другу).
- Нарушение логики чтения: Стрелки и поток должны идти слева направо и сверху вниз.
Рекомендации:
- Один сценарий — одна диаграмма последовательности. Не смешивайте основной и альтернативные потоки.
- Для сложных взаимодействий используйте диаграмму обзора взаимодействия, чтобы связать несколько простых диаграмм последовательности.
- Группируйте элементы во фрагменты для лучшей читаемости.
Диаграмма деятельности (Activity Diagram)
Назначение: Описание алгоритмов, логики работы системы или бизнес-процессов (хотя для последних лучше подходит BPMN).
Особенности:
- Визуально похожа на блок-схему, но поддерживает отображение параллельных действий.
- Часто используется для описания сценария внутри варианта использования.
Рекомендации:
- Используйте дорожки (swimlanes) для визуального разделения зон ответственности (например, пользователь, система, внешний сервис).
Диаграмма классов (Class Diagram)
Назначение: Моделирование структуры системы. Аналитики используют её преимущественно на логическом уровне для отображения бизнес-сущностей и их взаимосвязей.
Уровни детализации:
- Концептуальный уровень: Выделение ключевых бизнес-сущностей и связей между ними. Атрибуты и операции не детализируются. Понятна бизнесу.
- Логический уровень: Добавляются ключевые атрибуты, операции и указываются кратности связей. Это основа для проектирования базы данных и кода.
Польза для аналитика:
- Мощный инструмент для наведения порядка в предметной области и собственного понимания.
- Позволяет визуально оценить impact изменений: модификация одной сущности покажет, какие другие сущности и процессы будут затронуты.
Рекомендации по созданию:
- Сначала выделите сущности и связи, назовите связи.
- Затем добавляйте атрибуты и операции.
- Не пытайтесь уместить всю модель на одной диаграмме. Разбивайте её на логические домены (например, «Пользователи», «Платежи», «Заявки»).
- Используйте различные типы связей: ассоциации, агрегации, композиции, наследование (генерализацию).
- Класс-ассоциация — мощный элемент для моделирования связи, которая сама обладает атрибутами и операциями.
Другие полезные диаграммы
- Диаграмма состояний (State Machine Diagram): Идеальна для отображения жизненного цикла сущности, переходов между статусами (например, статусы заявки).
- Диаграмма потока информации (Information Flow Diagram): Может использоваться для построения контекстной диаграммы, которая показывает систему в центре и все взаимодействующие с ней внешние сущности и системы.
- Диаграмма развёртывания (Deployment Diagram): Показывает физическое расположение компонентов системы (серверы, узлы). Более актуальна для архитекторов.
Методология и выводы
Последовательность разработки моделей (рекомендация):
- Варианты использования (Use Case) -> 2. Диаграмма деятельности (Activity) для сценариев -> 3. Диаграмма последовательности (Sequence) для детализации -> 4. Диаграмма классов (Class) для структуры.
Модель 4+1
Рекомендуется изучить эту модель представлений архитектуры ПО. Она помогает систематизировать различные диаграммы UML, привязав их к потребностям конкретных стейкхолдеров (пользователей, разработчиков и т.д.).
Главные выводы:
- Консистентность — ключ: Все артефакты (текст, диаграммы разных типов) должны быть синхронизированы и непротиворечивы.
- Рисуйте для аудитории: У каждой диаграммы должен быть потребитель (стейкхолдер). Детализация и нотация для бизнеса и для разработчиков будут разными.
- UML — инструмент аналитика: Даже если разработчики переделают диаграмму классов, процесс её создания крайне важен для глубокого понимания аналитиком предметной области и формирования целостного видения системы.