3.6. Определение отношений

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

Ассоциация (association) – это двунаправленная семантическая связь между классами.

Агрегационное отношение – это специальная форма ассоциации между целым и его частью или частями, то есть отношение типа «часть от» или «содержит».

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

0

0..1

0..n

1

1..n

n

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

Наследованием называется такое отношение между классами, когда один класс использует часть структуры и / или поведения другого или нескольких классов. При наследовании создается иерархия абстракций, в которой подкласс (subclass) наследуется от одного или нескольких суперклассов (superclass). Подкласс наследует все атрибуты, операции и отношения, определенные в каждом его суперклассе.

Пример иерархии классов: транспортное средство, (судно, автомобиль, троллейбус), Титаник.

Пример множеств. Наследования: окно, окно с рамкой, окно с заголовком, окно с рамкой и заголовком.

4.На рис.4.3 подклассы Студент и Преподаватель наследуют свойства и поведение класса Пользователь.

3.2. Построение концептуальной модели

В UML существует несколько разновидностей класса: сущность, интерфейс и др. Для указания вида класса в UML введено понятие стереотипа (stereotype). Существует стандартный набор стереотипов, который, при необходимости, можно расширять.

Основные стереотипы класса – это сущность, граничный элемент, элемент управления, сервисный элемент и исключение.Соответственно, классы-интерфейсы имеют стереотип "boundary", классы-сущности - "entity", элемент управления – “control”, сервисный элемент - ”service”, исключение - ” exception”.

Класс- сущность (entity class) используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы.

Граничные классы (boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Такие классы представляют интерфейс для пользователя или другой системы (то есть для актера).

Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение.

Атрибут - это значение, характеризующее объект в его классе. Примеры атрибутов: категория, баланс, кредит (атрибуты объектов класса счет); имя, возраст, вес (атрибуты объектов класса человек) и т.д. Среди атрибутов различаются постоянные атрибуты (константы) и переменные атрибуты. Постоянные атрибуты характеризуют объект в его классе (например, номер счета, категория, имя человека и т.п.). Текущие значения переменных атрибутов характеризуют текущее состояние объекта (например, баланс счета, возраст человека и т.п.); изменяя значения этих атрибутов, мы изменяем состояние объекта.

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

Следует отметить, что, говоря об объектах и их классах, мы не подразумеваем никакого объектно-ориентированного языка программирования. Это, в частности, выражается в том, что на данном этапе разработки программной системы следует рассматривать только такие атрибуты, которые имеют смысл в реальности (все атрибуты объектов класса счет - рисунок 2.1- обладают этим свойством). Атрибуты связаны с особенностями общей реализации. Например, если известно, что будет использоваться база данных, в которой каждый объект имеет уникальный идентификатор, то включать этот идентификатор в число атрибутов объекта на данном этапе не следует. Дело в том, что, вводя такие атрибуты, мы ограничиваем возможности реализации системы. Так, вводя в качестве атрибута уникальный идентификатор объекта в базе данных, мы уже в самом начале проектирования отказываемся от использования СУБД, которые такой идентификатор не поддерживают.