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

Канал о системном и бизнес-анализе, продуктовом мышлении и архитектуре. Как выявлять реальные проблемы, строить работающие решения и не терять здравый смысл в IT. Все вопросы - @innokentyB

umlархитектурадиаграммы

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

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

  • Ты набросал диаграмму классов со свойствами, методами и связями, а тебе хоба - и все это в Java код преобразовалось.
  • Добавил сиквенс и у тебя в методы прямо логика взаимодействия с другими классами добавилась.
  • Нарисовал конечный автомат и вот у тебя в коде проверяется логика переходов по статусам сущности.

Как легко догадаться - не полетело. И из огромного сонма диаграмм (14 штук как минимум) используются обычно 3-4. Но, естественно находятся гики, которые пользуют все, им удобно, все нравится. И остальным должно нравиться 😈

По факту - сколько быть я ни пробовал применить конечный автомат - если он простой, то смысла не было, а если сложный - то матрица была надежнее.

Компонентную диаграмму вместе с пакетной легко заменяет С4, которая и проще и нагляднее.

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

Вот диаграмма Use Case и Sequence - пожалуй две реально часто используемых диаграммы. Но упарываться и все рисовать диаграммами? Можно, особенно если у вас Enterprise Architect, где все сущности провязаны и реально можно какие-то вещи собирать, как из конструктора, но он стоит оооочень дорого и порог входа достаточно высокий, разработчики его категорически не любят.

А какие у вас взаимоотношения с UML?

Дискуссия

Дмитрий Котов | 1С Заметки
Нулевое взаимодействие с uml)
PRO анализ в ИТ
Дмитрий Котов | 1С Заметки
Нулевое взаимодействие с uml)
Тоже неплохо)
Igor Diatchenko
В state-диаграммах есть определенная харизма (как и в idef0, кстати), особенно если есть композитные состояния, определяемые несколькими другими состояниями разных агрегатов. А вот сиквенс, несмотря на популярность, нормально можно описать только happy path, который и без этого обычно очевиден, в полных вариантах превращается в месиво. На state-диаграммах corner cases нормально и прозрачно описываются. Можно у вас попросить хороший пример или ссылку на матрицы для сложных стейт-диаграмм? Имеется в виду просто шахматка, где состояния по вертикали и по горизонтали, а на пересечениях возможность и способы перехода?
Igor Diatchenko
Диаграммы "классов" это вообще какой-то лютый порожняк, создающий путаницу. Особо сложные ER сейчас тоже не особо рисуют, т.к. конские схемы сложно связанных таблиц это антипаттерн по большому счёту. Сейчас популярны микросервисы, поэтому ропулярны сиквенс для их оркестрации и стейт для стейтфул сервисов, концептуальных схем и разных систем со сложными состояниями
PRO анализ в ИТ
Igor Diatchenko
В state-диаграммах есть определенная харизма (как и в idef0, кстати), особенно если есть композитные состояния, определяемые несколькими другими состояниями разных агрегатов. А вот сиквенс, несмотря на популярность, нормально можно описать только happy path…
Да, именно шахматка с условиями переходов. Боевая матрица под НДА, попробую найти что то доступное
PRO анализ в ИТ
Igor Diatchenko
Диаграммы "классов" это вообще какой-то лютый порожняк, создающий путаницу. Особо сложные ER сейчас тоже не особо рисуют, т.к. конские схемы сложно связанных таблиц это антипаттерн по большому счёту. Сейчас популярны микросервисы, поэтому ропулярны сиквенс…
Вот как то на стейт я обычно смотрел свысока, попробую свою матрицу переложить на диаграмму
Igor Diatchenko
PRO анализ в ИТ
Вот как то на стейт я обычно смотрел свысока, попробую свою матрицу переложить на диаграмму
У меня совсем недавно был случай с довольно сложной синхронно/асинхронной многошаговой интеграцией (с высокой вероятностью ошибок, с откатами и коммитами и т.д.), выгоднее было state-карту сделать, чем сиквенсы, на которых бы вообще ад получился из-за веток возможных исходов. А так - получилось довольно чётко, понятно в каком состоянии общая система и отдельные её части находятся и по каким состояниям к какому из итоговых исходов проход
Присоединиться к обсуждению →

Читайте так же