Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Uml Book (Rus).doc
Скачиваний:
15
Добавлен:
11.08.2019
Размер:
58.74 Mб
Скачать

Типичные приемы моделирования Словарь системы

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

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

Моделирование словаря системы включает в себя следующие этапы:

1. Определите, какие элементы пользователи и разработчики применяют для описания задачи или ее решения. Для отыскания правильных абстракций используйте CRC-карточки и анализ прецедентов.

2. Выявите для каждой абстракции соответствующее ей множество обязанно­стей. Проследите, чтобы каждый класс был четко определен, а распределе­ние обязанностей между ними хорошо сбалансировано.

3. Разработайте атрибуты и операции, необходимые для выполнения класса­ми своих обязанностей.

На рис. 4.9 показан набор классов для системы розничной торговли: Customer (Клиент), Order (Заказ) и Product (Товар). Представлено несколько соотнесен­ных с ними абстракций, взятых из словаря проблемной области: Shipment (От грузка), Invoice (Накладная) и Warehouse (Склад). Одна абстракция, а имение Transaction (Транзакция), применяемая к заказам и отгрузкам, связана с технологией решения задачи.

По мере того как вы будете строить все более сложные модели, обнаружится. что многие классы естественным образом объединяются в концептуально и семан­тически родственные группы. В языке UML для моделирования таких групп клас­сов используются пакеты (см. главу 12).

Как правило, модели не бывают статичными. Напротив, большинство абстрак­ций из словаря системы динамически взаимодействует друг с другом. В UML су­ществует несколько способов моделирования такого динамического поведения (см. части 4 и 5).

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

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

Моделирование распределения обязанностей в системе включает в себя следую­щие этапы:

1. Идентифицируйте совокупность классов, совместно отвечающих за некото­рое поведение.

2. Определите обязанности каждого класса.

3. Взгляните на полученные классы как на единое целое и разбейте те из них, у которых слишком много обязанностей, на меньшие - и наоборот, крошеч­ные классы с элементарными обязанностями объедините в более крупные.

4. Перераспределите обязанности так, чтобы каждая абстракция стала в разум­ной степени автономной.

5. Рассмотрите, как классы кооперируются друг с другом (см. главу 27), и пере­распределите обязанности с таким расчетом, чтобы ни один класс в рамках кооперации не делал слишком много или слишком мало.

В качестве примера на рис. 4.10 показано распределение обязанностей между классами Model (Модель), View (Вид) и Controller (Контроллер) из совокуп­ности классов языка Smalltalk. Как видите, их совместная работа организована так, что ни одному из классов не приходится делать слишком мало или слишком много. (Это множество классов формирует образец проектирования - см. главу 28.)

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]