Unified Modeling Language, унифицированный язык моделирования помогает визуально представить технически сложные системы. Это решает множество практических проблем, о чем мы рассуждали в предыдущем материале. В этой статье мы приведем конкретные примеры UML и расскажем, с чего начать его изучение.

С чего начинать изучение

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

С нуля до лида: как выглядит карьера бизнес-аналитика

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

• Актор: Пользователь или внешняя система.
• Прецеденты (Use cases): Регистрация, Поиск товаров.

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

Как минимум, надо “прикрутить платежные сервисы”, системы, которые будут отличать зарегистрированных пользователей и “гостей” и учесть еще ряд деталей, без которых невозможен запуск системы оплаты за товары. Возможно, уже во время просмотра заказчик примет решение. Во всяком случае, при взгляде на схему он задумается и сможет легче представить планируемые расходы.

Кроличья нора: насколько глубоко надо изучать API бизнес-аналитикам

Также обратите внимание на то, что каждая стрелка в UML имеет свое значение. Так стрелка с белым треугольником обозначает отношение “Обобщение”. Линия без стрелок — “Ассоциация”. Пунктирная линия со стрелкой означает зависимости, ведь наш процесс “Сделать покупку” связан и с поиском, и с просмотром и с оплатой за товар. Это, как раз, не усложнение, а упрощение — единые правила позволяют аналитикам со всего мира одинаково понимать созданные на UML cxемы.

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

Шаг 1. Создаем классы

Так в системе интернет-магазина могут быть классы: «Пользователь», «Товар», «Заказ». У каждого класса есть свои свойства:

• Пользователь: имя, email.
• Товар: название, цена.
• Заказ: номер заказа, статус.

Пока это просто три квадратика с текстом, но программистам уже понятно, что для номера заказа надо использовать тип данных “целые числа”, для статуса, имени, email и названия тип данных String (текст), а вот для цен — Double (для цифр с плавающей запятой, ведь цены бывают в долларах и центах).

Шаг 2. Добавление методов

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

• Пользователь: зарегистрироваться().
• Товар: показать_информацию().
• Заказ: изменить_статус().

Шаг 3. Добавление взаимосвязей

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

Сплошная линия с 1 на одном конце и N на другом указывает, что Пользователь может делать несколько Заказов, при этом Заказ может включать в себя несколько Товаров.

Также на первое время можно изучить диаграмму деятельности, которая показывает последовательность действий и диаграмму последовательности (Sequence Diagram). Она немного сложнее, но зато показывает как взаимодействуют между собой элементы системы во времени.

На этом графике вы можете увидеть описание функции “Дублирование проекта” в системе управления бизнесом Darlean.

Подробно мы описывали происходящее на графике в материале “Как создают софт в DAR: бизнес- и системный анализ”.

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

Магия пиктограмм: что такое BPMN?

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