ООП 04. Цикл разработки ПО с использованием ООП: анализ, проектирование, эволюция, модификация. Рабочие продукты объектно ориентированного анализа.

ООП направлено на то, чтобы в дальнейшем легко модифицировать программу.

Этапы объектно-ориентированного проектирования:

1. Этап анализа - построение модели задачи и начальной объектно-ориентированной модели (выделение ключевых абстракций). Этап анализа проходит вместе с заказчиком. Анализ строится на основе физического мира.

   Требования к модели:

   • Полная
   • Понятная всем заинтересованным лицам

2. Этап проектирования. На современном уровне как правильно автоматизирован. Создаем проектные документы на основе документов, которые мы получили на этапе анализа.

3. Этап эволюции. Эволюция = кодирование + тестирование + рекурсивный дизайн (от простого состояния системы развиваем до сложного).

   Эволюция - развитие проекта в рамках разработки продукта. До сдачи продукта.

4. Этап модификации - изменения, вносимые уже после сдачи продукта заказчику. Этапы эволюции и модификации выполняют разные люди.

Преимущества выделения этапа эволюции:

• Предоставляется обширная обратная связь
• Получаются разные версии системы - дает механизм отката и можно выпускать альтернативные версии продукта.
• Можно рассматривать каждую версию для демонстрации и обсуждения с заказчиком. Уже на начальных этапах есть результаты.
• Интерфейс разрабатывается отдельно от модели.

Какие изменения могут быть реализованы при эволюции:

• Добавление новых классов (безболезненная операция).
• Изменение реализации класса (безболезненная подмена).
• Изменение представления класса (более сложная операция).
• Реорганизация структуры класса (ещё более тяжёлая процедура).

Некоторые изменения можно реализовать за счёт применения паттернов проектирования.

Мы ни в коем случае не должны изменять интерфейс базового класса.

Рабочие продукты объектно-ориентированного анализа.

Продукт анализа - рабочие документы. Они лягут в основу проектных документов (на этапе проектирования).

Какие документы создаются при анализе:

1. Для всей программы:

   1.1. Схема доменов

   1.2. Проектная матрица (контролируем, какие этапы анализа нами пройдены)

2. Для каждого домена:

   Если в домене больше 30-50 классов, разбиваем домен на подсистемы. Разбиваем граф связности по принципу минимума связей - внутри подсистемы связей много, между подсистемами связей мало.

   2.1. Модель связей подсистем

   2.2. Модель доступа к подсистемам

   2.3. Модель взаимодействия подсистем

3. Для каждой подсистемы:

   3.1. Информационная модель (диаграмма сущность-связь)

   3.2. Описание классов и их атрибутов (членов данных)

   3.3. Описание связей

   3.4. Модель взаимодействия объектов (МВО)

   3.5. Список событий, происходящих в подсистеме

   3.6. Модель доступа к объектам (МДО)

4. Для каждого класса:

   4.1. Модель состояний (диаграмма переходов состояний - ДПС)

   4.2. Таблица процессов состояний (ТПС)

   4.3. Алгоритм действий состояний

5. Для каждого действия:

   5.1 Диаграмма потоков данных действий (ДПДД)

   5.2. Описание процессов

С чего начинать разработку проекта: разбили задачу на домены, рассматриваем прикладной домен (наш). Разработка прикладного домена начинается с информационного моделирования.

Информационное моделирование всегда начинаем с физических (реальных) объектов. Смотрим, какие объекты существуют. Пытаемся эти объекты сгруппировать по принципу одних и тех же характеристик (выделяем общее). Выделяем, чем характеризуется объект. Выделяем атрибуты объектов.