Post #368

Как правильно отмечают в комментариях к посту про Robustness Diagram, в UML её нет отдельно, потому что её можно сделать, например, из Communication Diagram. Ранее она называлась Collaboration — как, собравшись вместе, части системы решают задачу. В конце концов, это просто объекты и стрелочки. Такую диаграмму можно и сейчас собрать в каком-нибудь PlantUML, хотя её нет в списке диаграмм, которые он поддерживает. Но стереотипы для Entity, Control и Boundary есть, и стрелки тоже. Забавно, что Ивар Якобсон в расширении UML, описывающем Entity-Control-Boundary подход — у него он назывался Objectory — имел в виду скорее диаграмму классов. Собственно, он ведь какую задачу решал? Как правильно выявить структуру классов в приложении при использовании объектно-ориентированных языков. Это был 1992 год, ОО-языки уже появились, а методологии их применения — ещё нет. И дискуссия про пользу ОО-подхода против структурированного программирования стояла очень остро. Ивар Якобсон и придумал Use Case'ы, как способ проектирования структуры классов. Методически это выражалось как последовательность: 1) реестр юскейсов (взгляд на систему с точки зрения задач пользователя) — диаграмма юскейсов; 2) шаги юскейса, и необходимые для них интефейсы, сущности и логика — диаграмма устойчивости; 3) классы, реализующие выявленные интерфейсы, сущности и логику — диаграмма классов. Для своего времени это была прорывная идея, так как адепты ООП всё время твердили, что классы — это отражение объектов реального мира, и строить их нужно исходя из модели предметной области, не задавая вопроса, что с ними будет делать пользователь. Не знаю, как вас, а меня так ещё учили в институте, хотя в любой практической задаче было очевидно, что такой подход плохо работает. Якобсон одним из первых показал, что идти нужно от задач пользователя, а классы нужно делать такие, какие удобно, а не только как отражение сущностей реального мира. Разговоры по объектно-ориентированное программирование или проектирование сейчас, наверное, не так уж актуальны, но те же идеи на более верхнем уровне присутствуют в DDD и микросервисах. Вот, например, идея с разбиением архитектуры на элементы с разной скоростью изменения. Что-то может меняться, что-то остаётся. Это и обеспечивает устойчивость, робастность. Я долго задавался вопросом — почему диаграмма робастности? Ведь в статистике, электротехнике, инженерии и ML робастность — свойство сохранения работоспособности при резких и странных изменениях внешних параметров (выбросы, помехи). Так вот потому и робастности, говорит Якобсон: свойство системы сохранять работоспособность и целостность при поступлении неожиданных и странных требований! Пришло от заказчика дикое, но неизбежное требование — а мы уже готовы! У нас архитектура так построена, что для дикого требования поменять-то нужно в одном месте небольшой сервис, ну может в двух. И работаем дальше! Система устойчива к выбросам и взбрыкам заказчика.