У UML репутация тяжеловесного инструмента, но большинство инженеров всё равно обращаются к нему, когда нужна точность: диаграмма классов, чтобы зафиксировать модель, диаграмма последовательности, чтобы выверить взаимодействие, конечный автомат, чтобы сделать переходы явными. Проблема никогда не была в UML. Она была в рисовании. Раскладывать вручную дюжину классов с полями и связями это именно та кропотливая механическая работа, которую никто не хочет делать дважды, и поэтому UML-диаграммы с помощью ИИ так естественны.
Это почти идеальная задача для ИИ. Структура чётко определена, нотация стандартна, а раскладка подчиняется правилам. Вы задаёте намерение; инструмент занимается расстановкой.
Два пути: описать или указать на код
Есть два честных отправных пункта для UML-диаграммы, созданной ИИ, и они подходят для разных моментов.
- Из описания, когда дизайн ещё у вас в голове. "У User много Order; у каждого Order есть Line Item; Line Item ссылается на Product." Вы набрасываете модель вслух и хотите её увидеть.
- Из существующего кода или схемы, когда дизайн уже есть и нужна картинка. Ваши классы, SQL-таблицы и типы уже кодируют связи. Генерация из них означает, что диаграмма соответствует реальности, а не вашим воспоминаниям о ней.
Второй путь это тихая суперсила. Диаграмма классов, выведенная из настоящих типов, не может соврать о полях, а модель в стиле ER, сгенерированная из реального DDL, не может выдумать несуществующую связь.
Диаграмма классов из одного предложения
Допустим, вы описываете небольшую модель заказов. Сгенерированная диаграмма даёт настоящие блоки: каждый класс со своими атрибутами и ассоциации, нарисованные с правильной кратностью, а не просто линиями.
Диаграммы последовательности: взаимодействие, а не объекты
Диаграммы классов показывают структуру; диаграммы последовательности показывают поведение во времени. Рисовать их вручную ещё утомительнее, потому что каждое сообщение это точно размещённая стрелка между линиями жизни. Вместо этого опишите поток: "Клиент вызывает API, тот проверяет кэш, промахивается, запрашивает базу данных, записывает кэш и возвращает ответ." Вы получите линии жизни и упорядоченные сообщения, которые затем можно сократить и подписать.
Нотация стандартна, а раскладка подчиняется правилам. Именно поэтому машина может набросать черновик, а вы можете быть уверены, что исправите его.
UML из кода: генерируйте из настоящего
Самый долговечный UML рисуют не по воображению; его выводят из того, что уже существует. Если ваши модели меняются, нарисованная вручную диаграмма отстаёт. Генерация диаграммы классов из реальных типов или модели данных из реальной схемы означает, что картинка обновляется вместе с кодом. Перегенерируйте, а не перерисовывайте, и диаграмма перестанет быть музейным экспонатом.
Затем сделайте её читаемой, потому что UML бывает плотным
Полный UML быстро превращается в стену блоков. Преимущество редактируемого результата в том, что его можно сократить до той мысли, которую вы действительно доносите. Скройте атрибуты, неважные для этой диаграммы. Сгруппируйте классы одного агрегата. Выделите связь, которую читатель должен заметить. Диаграмма, которая ясно говорит одно, лучше полной, которую никто не читает.
Сгенерируйте структуру, исправьте детали, сократите до сути и экспортируйте версию, которая останется надолго. UML перестаёт быть рутиной и снова становится тем, для чего создавался: точной общей картиной того, как устроена система.