Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик, разработчик и автор телеграм-канала IT Talks. Наверное многие хотя бы раз сталкивались с диаграммой, которая сделала процесс более понятным. И с диаграммой, после которой пришлось перечитывать описание процесса еще не раз. Грамотная модель делает требования более качественными, а некорректно построенная модель может привести к непониманию хорошо проработанной документации.

В этой статье я разберу пять распространённых ошибок в построении диаграмм системным аналитиком на практических примерах. Статья написана на основе моего прошедшего вебинара.

В моем канале ты можешь скачать бесплатную методичку с шаблонами диаграмм на PlantUML.

Моделирование требований

Чем отличается модель в общем определении данного термина от модели требований:

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

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

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

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

Уточнение требований

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

Проработка процессов системы

Моделирование требований необходимо не только для того, чтобы уточнить сами требования. Модели помогают в проработке процессов системы. По своему опыту могу сказать, что если мне необходимо погрузиться в сложный технический процесс, то я строю, например, диаграмму последовательности на PlantUML и тем самым «укладываю» в голове сложные для понимания алгоритмы. Но здесь также нужно помнить про два момента. Внимательно соотносить диаграммы смежных процессов и следить за возможными конфликтами. Так как процессы пересекаются, это будет отражено на диаграмме. И отражено это должно быть в точности одинаково, чтобы избежать недопонимания читателем. Еще одна ошибка – визуализация множества процессов на одной диаграмме. В попытке сделать все и сразу можно нарисовать нечитаемую диаграмму, в которой не будет никакого смысла.

Повышение эффективности коммуникации

Если необходимо обсудить процесс, то здесь не обойтись без его диаграммы. Это упрощает понимание процесса всеми участниками команды и помогает вести диалог «на одном языке». Также можно использовать модели, как инструмент договорённостей во время обсуждений. Это позволит сразу зафиксировать уточнения и корректировки, понятные для всех участников диалога.

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

Топ-5 ошибок в диаграммах UML

Рассмотрим пять распространенных ошибок, которые я могу выделить на основании своего опыта в работе с диаграммами. Каждая ошибка будет в отдельном типе диаграммы. Пять ошибок – пять видов диаграмм:

Use-case Diagram

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

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

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

На диаграмме справа корректные прецеденты, отражающие возможности пользователь в системе, а также уточнены зависимости прецедентов, что улучшает её понимание.

Sequence Diagram

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

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

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

Activity Diagram

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

На диаграмме слева можно увидеть ошибку, которую мы рассматривали в диаграмме прецедентов. Шаги пользователя заменены на технические вызовы. Пользователь, как действующее лицо, не отправляет запросы. Это не является прямым шагом пользователя, как и отображение данных. Также нужно отметить, что данный вид диаграммы часто избыточно детализируется, что сказывается на её читаемости. Лучше разделить диаграмму на несколько отдельных, чем потерять в качестве.

State Machine Diagram

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

Важно, чтобы статусы на диаграмме соответствовали статусам в системе. На диаграмме слева статус заменяется действием, это не является ошибкой, если этот статус действительно есть в системе. Важно, чтобы статусы на диаграмме были реальными состояниями объекта, а не его действиями или шагами. Переходы должны отражать события, которые являются триггерами смены статусов. Также отмечу еще один недостаток в примере. Статус «Подтверждён», в зависимости от системы, можно понять по-разному. Подтверждение может быть от пользователя, другой системы и так далее. Корректнее, если статус четко отражает состояние объекта и по нему можно понять, что происходит в момент времени.

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

Component Diagram

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

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

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

Подведем итоги

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

В завершение делюсь чек-листом, который, по моему опыту, поможет избежать ошибок и строить качественные диаграммы. Удачи в работе!