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

Лабораторная работа №3.

Цели лабораторной работы:

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

2. Создание статического ракурса модели информационной системы в виде иерархии взаимосвязанных классов. Предполагается спецификация иерархии классов в виде UML-диаграмм.

3. Отображение модели ключевых классов системы в виде программных конструкций на языке С++ и проверка работоспособности реализации при помощи тестовой программы.

Ход лабораторной работы:

1. Выявление кандидатов в классы, описывающие предметную область:

- Выписать часто встречающиеся существительные в описании требований.

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

- Выделить в отдельный список те из выписанных существительных, которые можно отнести к одной из следующих смысловых групп – такие существительные являются явными кандидатами в классы:

- понятие, концепция;

- предмет;

- событие;

- организация;

- роль;

- местоположение;

- взаимодействие.

- По остальным существительным решение может быть принято позже.

2. Метод CRC-карточек:

Для оценки корректности выявления каждого конкретного класса следует дать ответы на следующие вопросы:

- Каковы обязанности класса?

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

Если обязанности сформулировать не получается, возможно существительное не является классом.

Если обязанностей несколько, возможно класс слишком большой и его следует разбить на несколько более мелких с 1 четкой обязанностью.

- С какими другими классами сотрудничает класс?

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

Если класс не взаимодействует ни с кем, маловероятно, что класс представляет собой объект-сущность. Отсутствие связей вполне допустимо для классов-значений.

3. Спецификация структуры классов:

- Используя программу StarUML, создать новую модель, содержащую диаграмму классов

- Добавить пустые классы-заготовки для всех выявленных классов.

- Выявить и специфицировать на диаграмме описательные атрибуты классов:

- Атрибут должен иметь имя и тип данных.

- Рекомендуется всем атрибутам назначить закрытую видимость.

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

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

- Выявить и обозначить на диаграмме отношения агрегации между классами:

- агрегация – это отношение целое-часть: если нельзя сказать, что объект класса является частью объекта другого класса, то отношение не является агрегацией;

- символ агрегации – ромбик – отображается на стороне объекта-контейнера;

- подвиды агрегации ExclusiveOwns (безраздельное владение) и Owns (владение) обозначаются закрашенным ромбиком, а Has и Member – незакрашенным;

- конкретный вид агрегации можно подчеркнуть при помощи стереотипов (дополнительный текст на соединительных стрелках);

- обязательно указать кратность агрегации (1..1, 1..*, *..*, …);

- допускается отношение циклической агрегации, если один из объектов класса может содержать объекты того же самого класса;

- если между классами существует более чем одно отношение агрегации, следует уточнить отношение при помощи явного имени либо комментария;

- Выявить и обозначить на диаграмме отношения ассоциации между классами:

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

- ассоциация может быть:

- двунаправленной, если оба объекта инициируют взаимодействие друг с другом;

- однонаправленной, если только один из объектов инициирует взаимодействие;

- без направления, если смысл ассоциации акцентируется не на взаимодействии, а на некоторой логической связи;

- обязательно указать кратность ассоциации (1..1, 1..*, *..*, …);

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

- если между двумя классами существует ассоциация с кратностью *..*, следует задуматься о возможных ассоциативных классах – т.е., вспомогательных классах, моделирующих конкретную пару объектов (типичный признак: конкретная пара объектов имеет характерные атрибуты)

- Выявить и обозначить на диаграмме отношения обобщения между классами:

- правильный случай: можно сказать, что подкласс является подвидом суперкласса;

- правильный случай: объект суперкласса можно заменить объектом подкласса;

- правильный случай: подкласс расширяет обязанности суперкласса;

- неправильный случай: наследование похожих атрибутов без наличия связи между обязанностями классов;

- неправильный случай: классы отличаются лишь малым набором свойств, не существенным для рассматриваемой задачи.