Моделирование ассоциаций

Моделирование отношений между классами

Спецификация классов

Некоторые правила выявления классов

Комплексный подход

Подход CRC

Подход на основе использования прецедентов

Подходу на основе использования прецедентов придается особое значение в языке UML.

Можно даже сказать, что этот подход рекомендуется использовать в рамках UML (если быть точным — то в рамках методологии RUP (Rational Unified Process)). Графическая модель прецедентов сопровождается неформальными описаниями, а также диаграммами последовательностей и кооперации для отдельных прецедентов. Эти дополнительные описания и шаги определения диаграмм (и объектов) требуется выполнить для каждого прецедента. На основе этой информации можно прийти к обобщениям, необходимым для выявления потенциальных классов. После того, как прецеденты становятся известны, а представление о системе с точки зрения взаимодействия, по меньшей мере, частично определено с помощью диаграмм последовательностей, объекты, используемые в этих диаграммах, приводят к выявлению классов.

Подход CRC (C lass- R esponsibility- C ollaborators – класс-ответственность-“сотрудники”) представляет собой нечто большее, чем метод выявления классов, – это способ интерпретации и изучения объектов (а также и обучения объектному подходу). Подход CRC включает в себя сеансы “мозгового штурма”, проведение которых облегчается за счет использования специально подготовленных карточек. Карточки состоят из трех отделений: имя класса записывается в верхнем отделении, “обязанности” класса перечислены в левом отделении, а “сотрудники” перечислены в правом отделении. Обязанности - это услуги (операции), которые класс готов выполнить в интересах других классов. Для выполнения многих обязанностей необходимо участие (обслуживание) со стороны других классов. Такие классы перечисляются как “сотрудники”.

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

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

2 Каждый класс - это шаблон описания множества объектов. Единичные классы, для которых можно представить существование только одного объекта, весьма маловероятны среди “бизнес-объектов”. Например, если система спроектирована для единственной организации, существование класса Organization (Организация) может быть не оправданно.

3 Каждый класс-сущность должен содержать набор атрибутов. Хорошим приемом является установление идентифицирующих атрибутов (ключей), чтобы помочь нам судить о мощности класса (т.е. ожидаемом количестве объектов данного класса в базе данных). Следует, однако, помнить о том, что класс не обязательно должен обладать пользовательским ключом.

4 Объекты классов идентифицируются с помощью идентификаторов объектов (OID)

5 Каждый класс должен отличаться от атрибута. Является ли понятие классом или атрибутом зависит от области приложения. Цвет автомобиля обычно воспринимается как атрибут класса Car (Автомобиль). Однако на фабрике по производству красок Color (Цвет) - это определенно класс со своими собственными атрибутами (яркостью, насыщенностью, прозрачностью и т.д.).

6 Каждый класс содержит набор операций. Однако на данном этапе вопрос идентификации операций не рассматривается.

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

Каждому классу необходимо присвоить имя.

Существует определенное соглашение в отношении имен классов. Это соглашение заключается в том, что имя класса начинается с заглавной буквы. Для составных имен в качестве первой буквы каждого слова также используется заглавная буква (вместо того, чтобы отделять слова знаком подчеркивания или дефисом). Это всего лишь рекомендуемое соглашение, однако, среди разработчиков оно нашло довольно много приверженцев.

Имя класса должно быть именем существительным в единственном числе (например, Computer) либо, при возможности, сочетанием прилагательного и существительного в единственном числе (например, StandartConfiguration). Т.к. класс представляет собой шаблон для множества объектов, использование в качестве имен существительных во множественном числе не несет никакой дополнительной информации. Имя класса должно быть осмысленным. Оно должно отражать истинную природу класса. Оно должно заимствоваться из словаря пользователей (а не жаргона разработчиков).

Графическая пиктограмма, представляющая класс, состоит из трех отделений (имя класса, атрибуты, операции, рис. 5.1.).

Рисунок 5.1. Представление класса на диаграмме классов

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

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

Ассоциации служат объединению объектов в системе. Они способствуют взаимодействию между объектами.

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

Спецификация ассоциаций подразумевает выполнение следующих действий:

1 Присваивание имен ассоциациям.

2 Присваивание имен ассоциативным ролям.

3 Установление кратности ассоциации

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

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

Дата добавления: 2014-01-05