Из аналитической модели

Создание модели проектирования

В кооперациях

Обязанности класса — это просто сумма всех ролей, которые он исполняет во всех

реализациях вариантов использования. Сложив все роли и удалив перекрывающиеся

части ролей, мы получим список всех обязанностей и атрибутов класса.

За определение ролей класса отвечают разработчики, выполняющие анализ и реализацию

вариантов использования. Разработчик, отвечающий за класс, собирает

все роли класса в полный набор обязанностей класса, а затем преобразует его

в согласованный набор обязанностей.

Разработчики, отвечающие за анализ вариантов использования, должны гарантировать,

что классы реализуют варианты использования с соответствующим качеством.

Если класс изменен, разработчик класса должен убедиться, что класс по-

прежнему способен выполнять свои роли в реализациях вариантов использования.

Если изменилась роль в реализации варианта использования, разработчик

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

Роли, таким образом, помогают разработчикам классов и разработчикам вариантов

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

Модель проектирования создается с использованием модели анализа в качестве

исходных данных. Она адаптируется к выбранной среде выполнения, например

к брокеру объектных запросов, библиотекам для построения пользовательского

интерфейса или СУБД. Она может также быть адаптирована для повторного использования

унаследованных систем (приложение В) или других заготовок, разработанных

для проекта. Таким образом, принимая во внимание, что модель анализа

является первым шагом модели проектирования, модель проектирования

будет чертежом для реализации.

Подобно модели анализа, модель проектирования также определяет классификаторы

(классы, подсистемы и интерфейсы), отношения между ними и кооперации,

которые реализуют варианты использования. Однако элементы, определенные

в модели проектирования, являются «проектными аналогами» более концептуальных

элементов, определенных в модели анализа, в том смысле, что новые эле-__

анализа)

— нет. Другими словами, модель проекта более «физическая» по природе,

а модель анализа более «концептуальная».

Реализация вариантов использования модели анализа связана трассировкой

с реализацией вариантов использования модели проектирования.

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

На рис. 3.7 показано, как вариант использования Снять деньги со счета реализуется

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

Рис. 3.7. Реализации варианта использования в разных моделях

Реализация варианта использования в различных моделях преследует различные

цели. Вернемся к подразделу «Создание по вариантам использования аналитической

модели» данной главы (см. рис. 3.4), где классы анализа Интерфейс кас-

сирау Получение, Банковский счет и Устройство выдачи участвуют в реализации

варианта использования Снять деньги со счета в модели анализа. После того как

эти классы анализа разработаны, с их помощью определяются уточненные классы

проектирования, которые адаптированы к среде выполнения. Это иллюстрируется

рис. 3.8.

Рис. 3.8. Классы проектирования из модели проектирования трассируются

от классов анализа из модели анализа

Так, например, класс з.ндiлизsi Интерфейс кассира преобразуется в четыре класса

проектирования — Дисплей, Клавиатура, Считыватель карт и Менеджер клиентов

(который является активным классом и поэтому изображен с толстой рамкой,

см. приложение А).

Обратите внимание, что на рис. 3.8 множество классов проектирования трассируются

от единственного класса анализа. Это нормально для классов проектирования,

которые специфичны для конкретного приложения или разработаны для

поддержки приложения или группы приложений. Поэтому структура системы,

определяемая моделью анализа, естественным образом распространится и на проектирование,

хотя, возможно, будут необходимы некоторые компромиссы (например,

когда Менеджер клиентов участвует в классах проектирования Интерфейс

кассира и Устройство выдачи). Кроме того, активные классы (Менеджер клиентов,

Менеджер транзакций и Менеджер счетов) представляют собой специальные

процессы, которые организуют работу других (неактивных) классов в случае распределенной

системы (мы вернемся к этой проблеме в подразделе «Архитектурное

представление модели развертывания» главы 4).

Как следствие, реализация варианта использования Снять деньги со счета

в модели проектирования должна описывать, как вариант использования реализован

в понятиях соответствующих классов проекта. Рисунок 3.9 изображает

диаграмму классов, которая является частью реализации варианта использования.

Рис. 3.9. Диаграмма классов, являющаяся частью реализации варианта

использования Снять деньги со счета модели проектирования.

Каждый класс проектирования участвует

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

Очевидно, что на этой диаграмме классов представлено большее количество

деталей, чем на диаграмме классов модели анализа (рис. 3.5). Такая детализация

необходима из-за адаптации модели проектирования к среде выполнения.

Анализ, проектирование и разработка при реализации варианта использования 81

%

Рис. 3.10. Диаграмма последовательности, представляющая собой часть

реализации варианта использования Снять деньги со счета

в модели проектирования

Как и при анализе (см. рис. 3.6), мы должны идентифицировать взаимодействия

между объектами проектирования, которые появились после того, как в модели

проектирования были реализованы варианты использования. Прежде всего, воспользуемся

диаграммой последовательности, чтобы промоделировать взаимодействия

между объектами проектирования, как показано на рис. 3.10.

Диаграмма последовательности показывает, как фокус — исходно находящийся

в верхнем левом углу — перемещается от объекта к объекту по мере выполнения

варианта использования и как объекты обмениваются сообщениями. Сообщение,

посланное одним объектом, побуждает объект-приемник этого сообщения

получить фокус и выполнить одну из операций его класса.

Интересно будет сравшгть эту диаграмму последовательности с ее «аналогом

из анализа» — то есть диаграммой коопераций, см. рис. 3.6. Фактически первые

два сообщения из диаграммы сотрудничества («1:идентифицировать» и «2:запро-

сить снятие») превратились в весь набор сообщений диаграммы последовательности

на рис. 3.10. Это дает нам понятие о сложности и уровне детализации модели

проектирования по сравнению с моделью анализа.

Как и в диаграммах кооперации, разработчики могут дополнять диаграммы

последовательностей текстом комментариев, поясняющим взаимодействие объектов

проектирования при выполнении последовательности событий варианта использования.

Как можно заметить по этому примеру, модель проектирования, вероятно, будет

содержать множество классов. Значит, нам потребуется способ организации

классов. Это можно сделать при помощи подсистем, которые мы рассмотрим в следующем

подразделе.__