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

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

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

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

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

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

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

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

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

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

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

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

  • предмет;

  • событие;

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

  • роль;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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