Сперва идёт анализ требований, чаще всего через определение use cases, иногда называемых user stories — т.е. всё это ещё ни разу не функциональные требования. Этот анализ даёт модель предметной области (domain model), нечто иллюстрируемое набором определённых диаграмм. Более известное как conceptual object model. Описывает не программные объекты, а через термины реального мира представляет понятия.
На второй фазе идёт уже проектирование через определение программных объектов. Которым назначаются обязанности и описываются способы\варианты взаимодействия между ними.
Для чего используется dynamic view, это делается через UML sequence diagram (частный случай interaction diagram).
В дополнение к чему создаётся static view проектируемого решения через design class diagram.
Основное отличие второй фазы от первой в том, что диаграммы описывают уже классы используемые в исходном коде. И не обязаны соответствовать целиком и полностью модели предметной области.
Каков удел UML в этих раскладах?
Используется и для conceptual perspective описывая сущности реального мира, предметной области.
И как средство для specification perspective как способ выразить программные абстракции (описать компоненты с интерфейсами).
А так же и для implementation perspective — описания конкретной программной реализации, применимой к коду на определённом языке программирования.
Т.е. один и те же фигуры (диаграммы) #UML служат для самых разных уровней отражения и представления систем. В том числе и для разных фаз создания\проектирования создаваемых решений.
И всё это реально нужно перед тем, как получится применить познания подчерпнутые из #DDD или какого-то иного подхода.
#OOP #OOA #OOD #softwaredevelopment #softdev
RE: https://shitpost.poridge.club/notes/afh0dzhunr


