Спецификации состояний

Состояние объекта определяется значениями его атрибутов и ассоциаций. Напри­мер, объект BankAccount (Банковский счет) может находиться в состоянии "превышение кредитного лимита", если значение атрибута balance (баланс) отрицательно. Поскольку состояния объекта определяются структурам данных, модели структур данных называются спецификациями состояний.

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

В типичной ситуации сначала определяются классы-сущности, т.е. классы, которые определяют проблемную область и характеризуются постоянным присутствием в базе данных системы. Подобные классы иногда называются "бизнес-классами". Классы, ко­торые обслуживают системные события (управляющие классы) и классы, которые пред­ставляют GUI-интерфейс (классы представления или пограничные классы) не устанавли­ваются до тех пор, пока не станут известны поведенческие характеристики системы.

Моделирование классов

Модель классов - это краеугольный камень разработки объектно-ориентирован­ной системы. Классы лежат в основании наблюдаемости свойств и поведения систе­мы. К сожалению, классы всегда трудно поддаются определению, а свойства классов не всегда очевидны. Весьма маловероятно, чтобы два аналитика пришли к одному и тому же множеству классов и их свойств для одной и той же нетривиальной проблем­ной области. Хотя модели классов могут отличаться, конечный результат и степень удовлетворенности пользователя могут быть в равной мере достаточными (или в рав­ной мере недостаточными).

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

1. Знания в области моделирования классов.

2. Понимание проблемной области.

3. Опыт в области аналогичных и успешных проектов.

4. Способность смотреть вперед и предвидеть последствия решений.

5. Готовность к пересмотру модели с целью устранения недостатков и т.д.

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

Выявление классов

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

Барами (Bahrami) подробно изучил главные особенности четырех основных подходов к выявлению классов (class discovery). Ниже перечислены эти подходы.

1. Подход на основе использования именных групп.

2. Подход на основе использования общих шаблонов для классов.

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

4. Подход CRC (class-responsibility-collaborators - класс-обязанности - "сотрудники").

Барами поставил в соответствие каждому из подходов опубликованные работы, однако - по нашему мнению - только последний подход обладает неоспоримым ис­точником.