Ранее я уже писал про построение диаграмм.
Тогда мои я смотрел на эту тему через призму практики.
Но спустя время у меня пара более весомых аргументов в пользу того что сила диаграмм недостаточна в разработке ПО.
1️⃣ аргумент:
Мысленный эксперимент:
🔹 Подумайте о фиче над которой вы работали(-ете) последнее время.
🔹 Попытайтесь формально и недвусмысленно представить себе ее описание или представление.
Со всеми связями, зависимостями и внутренними элементами.
🔹 А теперь опишите это так, чтобы человек который не имеет ни малейшего понятия об этом, смог в точности воспроизвести то, что вы описали.
Именно эта проблема емко выражается словом невыразительность:
🔻Невыразительность или Inexpressiveness — термин употребляемый чаще всего математиками, означающий невозможность как формально, так и строго выразить, смоделировать, представить описанную проблему.
И в отличие от физических, механических или геометрических конструкций в физическом мире, проектирование ПО осуществляется в абстрактном мире.
И то, чего достаточно для отображения физического мира не достаточно для абстрактного.
Отсюда 3ий закон инженерной разработки:
Теорема 1.3. Природа ПО проистекает из неосязаемости изучаемых абстрактных объектов, сложных внутренних связей программных систем, адаптивности к внешним объектам и окружения, и когнитивной сложности для их явного описания.
Software Engineering Foundations, Wang, p26
И следствие из него:
Следствие 1.2. Силы выражения диаграмм недостаточно в разработке ПО, поскольку они делают дизайн и спецификации расплывчатыми.
Архитектура ПО представляет собой создание сложных объектов, часто опирающихся на физический мир, с не менее сложными связями между ними.
И вся эта сложность может быть выражена только на уровне профессиональных обозначений или математически.
❗️Для понимания см. картинку к посту:
Т.е. не на уровне L1, L2 - уровне реальных объектов и диаграмм, а на уровнях L4, L5.
Именно эта разница вызывает проблему, упомянутую прошлой статье про диаграммы:
Очень сложно отразить адекватно все связи с реальным классом так, чтобы это было удобно воспринимать
2️⃣ аргумент:
Евгений Куприянов, который ведет канал Системный Сдвиг провел опрос среди подписчиков касательно использования UML на проектах.
Вот несколько выводов оттуда (цитирую, упрощая местами формулировки):
— Большинство аналитиков рисуют диаграммы, но многие не для того, чтобы разобраться или что-то спроектировать, а потому, что в документации есть такой раздел. Некоторые даже не знают, куда эта документация дальше пойдет.
— UML используется совсем не так, как был придуман. От всего UML осталась диаграмма последовательности (и она ого-го как используется!), диаграмма вариантов использования и диаграмма состояний.
— Диаграммы в основном скорее формальные, но не идеально формальные.
UML — как латынь для некоторых наук. Мёртв-не мёртв, а лучше знать хотя бы основы и понимать, как его правильно применять сейчас. Lingua Franca для разработки.
Выводы:
🔸Диаграммы недостаточно выразительны для точного описания сложных программных систем, что приводит к риску неправильного понимания и интерпретации.
🔸Архитектура ПО оперирует абстрактными объектами и связями, которые сложно адекватно передать с помощью диаграмм, особенно на уровнях, связанных с реальными объектами.
🔸UML и другие диаграммы часто используются формально и не всегда помогают в проектировании, что ставит под сомнение их практическую ценность в разработке ПО.
з.ы. жаль ребят кто должен рисовать схемы по долгу специфики работы (аналитики, поставил за вас свечку 🕯)
Более подробно, невыразительность, как одно из ограничений инженерной разработки, мы будем разбирать на моем курсе!
Посмотреть план курса 🫡
Сохраняй себе, чтобы не потерять и делись с коллегами 📞
Ставь 👍 если тебе заходит такого рода контент!
#software_engineering@UniArchitect
