Атрибуты классов анализа определяются, исходя из знаний о предметной области, требований к системе, глоссария и бизнес-модели. В процессе анализа атрибуты определяются только для классов-сущностей, и они имеют тот же смысл, что и в модели 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. Полная диаграмма классов (без атрибутов и операций)
