ООП Лекция 15. Документы объектно ориентированного анализа.

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

Когда мы проводим анализ, мы формируем рабочие документы. Эти рабочие документы помогают нам проводить анализ, и эти рабочие документы мы в дальнейшем используем для разработки уже проектных документов, на основе которых мы выполняем этап эволюции.

Виды документов:

1. Для всей программы.
2. Для каждого домена.
3. Для каждой подсистемы.
4. Для каждого класса.
5. Для каждого состояния.
6. Для каждого действия.

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

• Cхема доменов. Мы разбиваем задачу на домены.
• Проектная матрица (используется не только при проектировании, но и эволюции.) Она нам нужна, для того, чтобы четко оценивать, на какой стадии разработки нашего ПО мы находимся.

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

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

• Модель связей подсистем;
• Модель взаимодействия подсистем;
• Модель доступ к подсистемам;

Каждой подсистемы

• Информационная модель (выделяем сущности, классы) С этой модели мы начинаем, собственно, проектировать. Разрабатывая информационную модель, мы выделяем:
  • Описание классов и их атрибутов;
  • Описание связей;
• Модель взаимодействия объектов (диаграмма взаимодействий). Выделяя модель взаимодействия объектов, мы формируем список событий, которые происходят в нашей подсистеме:
  • Список событий (в результате модели взаимодействий объектов);
• Модель доступа к объектам;

Для каждого класса (сущности)

• Модель состояний (ДПС - диаграмма переходов состояний); (Для каждого состояния.)
• Таблица процессов состояний (ТПС); (Для каждого состояния.)
• Диаграмма потоков данных действий (ДПДД); (для каждого действия)
• Описание процессов; (для каждого действия)

С чего начинать разработку?

Объектно-ориентированный подход - подход белого ящика. Мы идем от сущности, которая у нас реально существует, и из чего состоят эти сущности. Начинается всё с информационного моделирования. Понятно, что в начале мы разбили задачу на домены. Рассматриваем данном случае прикладной домен, грубо говоря, нашу задачу. Когда мы переходим к понятию подсистемы? Когда кол-во классов в прикладном домене становится критическим, и когда четко выделяются группы объектов, которые мы четко можем разбить на подсистемы. В любом случае, мы начинаем разработку прикладного домена с информационного моделирования.