💠 Циклы разработки ПО с использованием ОО проектирования:
Основной этап: ОО анализ, больше всего времени. Задача ООА – построение модели системы. На основе построенной модели выполняется проектирование.


Проектирование – перевод модели в проектные документы с помощью CASE-средств.


Эволюция. Написание кода, тестирование, итерирование - ОО подход за счет рекурсивного дизайна, система разворачивается и усложняется. 
Модификация – эволюционирование на готовом продукте, сданном заказчику.

💠 Преимущества рекурсивного дизайна при эволюционировании:

• система постоянно развивается, но всегда готова – обеспечивается обратная связь с заказчиком

• предоставляются разные версии системы – можно откатываться на шаг назад; можно пускать разные версионные ветки
• заказчик постоянно видит результат

• серьёзных ошибок не возникает за счет постоянного взаимодействия с заказчиком

• хорошо распределяется время при проектировании

• размеры системы (кода) в принципе не ограничиваются; при структурном же подходе чрезвычайно большая программа при большом количестве разработчиков вызывает проблемы с взаимодействием оных

💠Изменения в системе в порядке ухудшения сценария:

• проектировать надо так, чтобы добавление классов было безболезненно
• 
изменение реализации класса

• изменение представления класса

• реорганизация структуры классов

• изменение интерфейса класса – самое страшное, тянет за собой кучу изменений в основном коде

Задача анализа – довести модель до такого состояния, чтобы дальше не понадобилось изменять интерфейс.

💠ОО анализ
В структурном программировании используется принцип черного ящика – мы не думаем о конкретных действиях и данных, а о том что нужно сделать. В ООП – белый ящик, первее всего – данные. Мы выделяем характеристики объектов, и потом уже приходим к тому, как их обрабатывать.

Система разбивается на домены – интерфейс, реализация, сама задача, сервисные функции (например коммуникация) и так далее. Рисуется схема доменов для доменного уровня всей задачи. Для выполнения же этапов анализа рисуется проектная матрица – мы контролируем, какие этапы анализа нами пройдены. 
С доменом, в котором более 150 классов работать тяжело, а на деле – уже даже с более 50. В домене четко выделяются группы классов, между которыми много связей, в то время как между группами связей мало – домен делится на подсистемы, и проектируем вначале подсистемы, а потом реализуем связи.

Для домена строится модель связи подсистем. Выделяются синхронная и асинхронная схемы взаимодействия, соответственно модель доступа к подсистемам (синхронная) и модель взаимодействия подсистем (асинхронная).