Введение

Работая с учениками на курсе по UML, я столкнулся с непринятием инструмента:

Зачем рисовать ваши схемы, если можно сразу писать код? Бюрократия какая-то!

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

Как сделать щеколду для сарая?

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

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

Нет, конечно! Нужно сделать чертеж и всем раздать!

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

Но вдруг новый вызов! Вас заметила соседняя мебельная фабрика и хочет заказать щеколды для архивных шкафов. Вы им сразу выпаливаете: “Что за шкафы, какой размер, какая нужна щеколда, может лучше задвижку? … Не знаете, что такое задвижка? Нууу, это такое… вот, ммм, короче… штуковина…”

Понимаете, к чему я? Кончено же снова нужен чертеж!

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

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

UML-диаграмма - это “чертеж” в разработке ПО

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

UML-диаграммы — это и есть те самые «чертежи», но для разработки программного обеспечения.

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

Зачем это нужно? Есть три процесса, когда мы можем использовать UML:

1. Проектирование.
2. Документирование.
3. Изучение.

Рассмотрим каждый процесс подробнее.

1. Проектирование

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

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

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

Гораздо проще стереть линию на схеме, чем переписывать тысячи строк кода.

Умение создавать такие диаграммы — это один из важных навыков архитектора или тимлида. Вы учитесь не просто кодировать, а мыслить на уровне системы, видеть ее целиком.

2. Документирование

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

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

Чтобы этого не случилось, надо понимать следующее: диаграмма для документации должна отражать общее, абстрактное видение системы — ее концепт.

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

3. Изучение

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

Диаграммы классов, например, можно сгенерировать с помощью doxygen.

Вывод

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

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

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

Этого набора уже хватит, чтобы значительно повысить свой уровень.

---

Обсудить в Телеграм

---

Свежие записи