
- •5. Углубленный анализ
- •5. 1. Моделирование классов
- •5.1.1.Выявление классов
- •Подход на основе использования именных групп
- •Подход на основе использования общих шаблонов для классов
- •Подход на основе использования прецедентов
- •Подход crc
- •Комплексный подход
- •5.1.2. Некоторые правила выявления классов
- •5.1.3. Спецификация классов
- •5.2. Моделирование отношений между классами
- •5.2.1.Моделирование ассоциаций
- •5.2.2. Моделирование отношений агрегации и композиции
- •5.2.3. Моделирование отношений обобщения
- •5.3. Спецификация поведения
- •5.4. Моделирование открытых интерфейсов
- •5.5. Углубленное моделирование классов
- •5.6. Иерархия классов
- •5.6.1.Пакеты
- •5.6.2. Подход bce
- •5.6.3. Углубленное моделирование обобщения и наследования
- •Наследование интерфейса
- •Наследование реализации
- •5.6.4. Углубленное моделирование агрегации и делегирования
Комплексный подход
На практике процесс выявления классов использует разные подходы. Немаловажными факторами при этом выступают общая эрудиция эксперта, его опыт и интуиция. Процесс в чистом виде не следует ни методу сверху-вниз, ни методу снизу-вверх - он все время идет “из средины”. Подобный подход к выявлению классов называют комплексным подходом.
5.1.2. Некоторые правила выявления классов
Для каждого класса должно быть ясно сформулировано его назначение в системе.
Каждый класс - это шаблон описания множества объектов. Единичные классы, для которых можно представить существование только одного объекта, весьма маловероятны среди “бизнес-объектов”. Например, если система спроектирована для единственной организации, существование класса Organization (Организация) может быть не оправданно.
Каждый класс-сущность должен содержать набор атрибутов. Хорошим приемом является установление идентифицирующих атрибутов (ключей), чтобы помочь нам судить о мощности класса (т.е. ожидаемом количестве объектов данного класса в базе данных). Следует, однако, помнить о том, что класс не обязательно должен обладать пользовательским ключом.
Объекты классов идентифицируются с помощью идентификаторов объектов (OID)
Каждый класс должен отличаться от атрибута. Является ли понятие классом или атрибутом зависит от области приложения. Цвет автомобиля обычно воспринимается как атрибут класса Car (Автомобиль). Однако на фабрике по производству красок Color (Цвет) - это определенно класс со своими собственными атрибутами (яркостью, насыщенностью, прозрачностью и т.д.).
Каждый класс содержит набор операций. Однако на данном этапе вопрос идентификации операций не рассматривается.
5.1.3. Спецификация классов
После того, как перечень потенциальных классов сформирован, необходима их дальнейшая спецификация: классы требуется включить в диаграмму классов и определить их свойства.
Каждому классу необходимо присвоить имя.
Существует определенное соглашение в отношении имен классов. Это соглашение заключается в том, что имя класса начинается с заглавной буквы. Для составных имен в качестве первой буквы каждого слова также используется заглавная буква (вместо того, чтобы отделять слова знаком подчеркивания или дефисом). Это всего лишь рекомендуемое соглашение, однако, среди разработчиков оно нашло довольно много приверженцев.
Имя класса должно быть именем существительным в единственном числе (например, Computer) либо, при возможности, сочетанием прилагательного и существительного в единственном числе (например, StandartConfiguration). Т.к. класс представляет собой шаблон для множества объектов, использование в качестве имен существительных во множественном числе не несет никакой дополнительной информации. Имя класса должно быть осмысленным. Оно должно отражать истинную природу класса. Оно должно заимствоваться из словаря пользователей (а не жаргона разработчиков).
Графическая пиктограмма, представляющая класс, состоит из трех отделений (имя класса, атрибуты, операции, рис. 5.1.).
Рисунок 5.1. Представление класса на диаграмме классов
Выделение атрибутов осуществляется параллельно с выделением классов. Исходные модели спецификации определяют только атрибуты, являющиеся существенными для понимания состояний, в которых могут находиться объекты класса. Остальные атрибуты можно до поры до времени игнорировать (однако аналитик должен быть уверен в том, что установленная, но проигнорированная на определенном этапе информация не будет по ошибке утеряна и будет зафиксирована впоследствии). Маловероятно, чтобы все атрибуты класса были приведены в документе описания требований, однако важно не включать в спецификацию те атрибуты, которые не вытекают из требований.
Для имен атрибутов можно придерживаться следующего соглашения: в именах атрибутов использовать только строчные буквы, а слова в составных именах отделять подчеркиванием.