Цикл заметок по UML и артефактам

Начал перечитывать книгу Фаулера 2004 года "UML Основы" — на этот раз внимательно. И внезапно оказалось, что там много интересного, мимо чего я раньше проходил. Решил делиться находками в виде коротких заметок. Потом, может, соберу всё в один материал.

🔸 UML — это не просто «диаграммы рисовать». Это целое семейство графических нотаций, объединённых в унифицированный язык моделирования. В основе — метамодель (вы спросите "что?", не забивайте голову) . Возник этот язык как компромисс между кучей методологий и подходов, которые плодились в 80–90-х. В какой-то момент несколько команд договорились, набрали критическую массу и такие — бац, держите UML. Подробнее об истории в интернете.

🔸 Что такое «графический язык моделирования» по сути? Это когда рисуешь блоки и стрелки, и в идеале это можно превратить в исполняемый код. Ну или хотя бы в понятную модель.

Фаулер выделяет три режима использования UML:

- Режим эскиза
- Режим проектирования
- Режим языка программирования

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

📝 Режим эскиза — наш с вами хлеб.
Когда рисуем схему, чтобы объяснить разработчику, «что вот тут будет вот так». Или чтобы всей командой обсудить логику куска системы. Цель простая: визуализировать идею, а не построить идеальный чертёж.

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

И да, все любят картинки. Визуалам так проще.

🏗️ Режим проектирования — это уже ближе к архитектуре. Типа чертёж, по которому надо строить. Обычно это не про «на ходу объяснить», а про «задокументировать, чтобы потом не переспрашивать».

💾 Режим языка программирования — почти вымер? (моя гипотеза, но вроде так и есть). Я видел один раз в Enterprise Architect. И то не уверен, что это было легально.

Собственно история показала, что режим эскиза - то, как на самом деле используют UML

Фаулер пишет:
«Эскизы сознательно выполняются неполными»
«Эскизы — это проба, а проект — финальный результат»

И дальше — здравый вывод:
- слишком подробные модели сложно поддерживать,
- и они тормозят разработку.
(ну это надо "правильно нарисовать", обсудить, переделать)

Так что если у вас UML — это набор простых элементов, соединённых стрелками чтобы обсудить «а если так» — вы делаете всё правильно.

🔸 А ещё у Фаулера есть мысль про допустимость
Он говорит: нет никакого «правильного UML».

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

Если вам кажется, что надо стрелочку покрасить, нарисовать человечка и подписать «Клиент» — рисуйте.

По факту мы используем лишь 10-20% от всех возможностей нотации и нам хватает 👍

🔸Лучше понятная схема в “неправильном” UML, чем не понятная в “правильном”
(это относится ко всем артефактам аналитика в целом)

Ну и финалочка. Чтобы делать полезные диаграммы, не обязательно лезть в код. Часто хватает базового понимания — как работает программа, кто с кем разговаривает, что куда идёт. Не знаете? Делите на логические куски, рисуйте, обсуждайте, уточняйте.

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

📌 Поэтому:

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

Следующая заметка — скоро. Если не забуду.
Лайк = требование следущей части

#uml@analyst_exe
analyst.exe | чат