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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Атрибуты

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

У нас есть объект. Мы выделяем, что характеризует этот объект. Естественно, это зависит от той задачи, которая нам требуется. Мы подходим не "что нам делать", а "чем характеризуется". Мы выделяем атрибуты объектов, характеристики. Любая характеристика, которая нас заинтересовала, абстрагируется как атрибут.

Атрибуты делятся на:

• Идентифицирующие или указывающие. Идентификатор - набор из одного или нескольких атрибутов, которые четко идентифицируют объект. Атрибуты, которые мы объединили в понятии идентификатор, являются идентифицирующими. Еще их называют указывающими атрибутами.

Привилегированный идентификатор (начинается с *)

• Описательные. Любая характеристика объекта, которая его описывает. Например, студент. Средний балл. Это может быть описательной характеристикой? Нет. А вес, рост? Да.
• Вспомогательные. Мы их вводим для формализации связей и состояния (статус).

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

Все атрибуты могут менять и объект от это ни как не меняется, то есть поменялось имя, то объект остался прежним, или же вес, то тоже самое.

Все сводится в таблицу:

• строка - объект,
• столбец - атрибут.

Описание атрибутов

Каждый атрибут мы должны описать. Нужно четко понять, почему мы его выделили, и это описать.

Что из себя представляет описание атрибута? Это текст, из которого становится понятно, зачем нам нужен данный атрибут, почему мы его выделили, почему мы выделили данную характеристика.

Описание идентифицирующего атрибута

Мы должна описать форму указания (если она уместна), кто назначает указание и указать степень, в которой этот идентифицирующий атрибут используется, как идентификатор.

Среди всех идентифицирующих атрибутов мы выделяем привилегированный атрибут. Например, для студента, если имя и фамилия - идентифицирующие атрибуты, из них фамилия - привилегированный.

Описание описательного атрибута

Четко показываем, какую конкретную характеристику объекта сберегает этот атрибут. Так же показываем, как определяется этот атрибут, кто задает значение этого атрибута.

Описание вспомогательного атрибута

Надо делать описание только того атрибута, который формализует связь. В данном случае надо просто указать, какую связь формализует данный атрибут и почему мы так формализуем эту связь, а не по другому.

Изменение атрибутов

Мы четко должны понимать: изменение атрибута не приводит к изменению объекта. Объект остается таким же, тем же самым.

Если изменился указательный атрибут, то просто другое имя стало у того ж самого объекта. Была Иванова, а стала Петрова, но объект остался тот же самым.

Если изменился описательный атрибут, то это говорит о том, что какая-то характеристика изменилась. Например, изменился вес, но объект остался прежним.

Если изменяется вспомогательный атрибут, который формализует связь, то это говорит о том, что просто другие объекты участвуют в этой связи. Поменялись объекты участвующие в связи.

Правила атрибутов:

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

Мы выделяем правила атрибутов:

• Для данного объекта каждый атрибут в любой момент времени должен иметь значение. Не может быть такого, чтобы какой-то атрибут не был определен. Это значение должно быть единственным. Если, когда мы выделили какую-то сущность, в ней появился объект, который мы отнесли к этой сущности, но у него, возможно, какой-то атрибут не определен - значит, объект относится к другой сущности.
• Атрибут не должен содержать внутренней структуры. Он не должен быть для нас сложным. Это что-то простое, например: вес, рост и так далее.
• Когда атрибут имеет составной идентификатор, каждый атрибут, который является частью идентификатора, представляет характеристику всего объекта, а не его части, ну и тем более не характеристику чего-либо другого. Например, для студента, ФИО - это всё характеристики самого объекта, самого студента, а не его части.
• Если атрибут не является частью идентификатора, то он должен представлять характеристику данного объекта, указанного идентификатором, а не характеристику какого-либо другого атрибута. Это типичная ошибка - добавить атрибуты, которые характеризуют другие атрибуты или части объекта.