Определение атрибутов и ассоциаций классов

Атрибуты классов анализа определяются, исходя из знаний о предметной области, требований к системе, глоссария и бизнес-модели. В процессе анализа атрибуты определяются только для классов-сущностей, и они имеют тот же смысл, что и в модели ERM. Атрибуты должны быть простыми, т.е. выразимыми с по­мощью простых типов данных (одной из распространенных оши­бок является моделирование сложного понятия предметной об­ласти в виде атрибута). Так, после определения атрибутов для классов-сущностей, показанных на рис. 4.12, они примут следу­ющий вид (рис. 4.14).

Связи между классами (ассоциации) определяются в два этапа:

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

2. Анализируются и уточняются ассоциации между классами-сущностями. Задаются мощности ассоциаций, могут использо­ваться множественные ассоциации, агрегации, обобщения и ас­социации-классы.

Следует избегать использования избыточных ассоциаций и сосредоточиться на тех ассоциациях, для которых данные о связи должны сохраняться в течение некоторого времени. Это достаточ­но важный момент. Если модель содержит N различных классов анализа, то между ними можно установить N*(N-1) ассоциацию, большинство из которых будет просто создавать «визуальный шум» и ухудшать наглядность диаграмм. Поэтому при добавлении ассоциаций нужно придерживаться принципа минимализма.

Рис. 4.14. Классы с операциями «анализа» и атрибутами

Результаты определения связей между классами, принимаю­щими участие в реализации варианта использования «Зарегист­рироваться на курсы», показаны на рис. 4.15 — 4.17.

На рис. 4.15 показаны только классы-сущности. Агрегация между классами Student и Schedule отражает тот факт, что каждый график является собственностью конкретного студента, принад­лежит только ему. Предполагается также, что в системе будет хра­ниться не только график текущего семестра, а все графики сту­дента за разные семестры. Между классами Schedule и CourseOffering введено две ассоциации, поскольку конкретный курс может входить в график студента в качестве основного (не более четырех курсов) и альтернативного (не более двух курсов). К классу Student; добавлены два новых подкласса — FulltimeStudent: (студент очного отделения) и ParttimeStudent (студент вечернего отделения).

Рис. 4.15. Диаграмма классов-сущностей

На рис. 4.16 показаны ассоциации-классы, представляющие свойства связей между классами Schedule и CourseOffering. Ассо­циация, связывающая график и альтернативный курс, имеет только один атрибут — статус курса в конкретном графике (status), который может принимать значения «включен в график», «отменен», «внесен в список курса» и «зафиксирован в графике». Если курс в процессе закрытия регистрации переходит из аль­тернативного в основные, то к соответствующей ассоциации до­бавляется атрибут «оценка» (grade). Таким образом, ассоциация-класс PrimaryScheduleOfferingInfo наследует свойства ассоциа­ции-класса ScheduleOfferingInfo (атрибуты и операции, содержа­щиеся в этом классе, относятся как к основным, так и к альтер­нативным курсам) и добавляет свои собственные (оценка и окончательное включение курса в график могут иметь место только для основных курсов), что и показано с помощью связи обобщения.

ScheduleOfferingInfo

Рис. 4.16. Пример ассоциаций-классов

На рис. 4.17 показана полная диаграмма классов варианта ис­пользования «Зарегистрироваться на курсы» (без атрибутов и операций). Ассоциации между граничными и управляющими классами, а также между управляющими классами и классами-сущностями введены на основе анализа кооперативных диаг­рамм и в отличие от устойчивых структурных (семантических) связей между сущностями отражают связи, динамически возни­кающие между соответствующими объектами в потоке управле­ния (в процессе работы приложения). Поскольку для ассоциаций это не свойственно, в дальнейшем (в процессе проектирования) они могут быть преобразованы в зависимости.

Рис. 4.17. Полная диаграмма классов (без атрибутов и операций)