1.14.1. Поиск

Если объект должен вести поиск во всем множестве объектов класса, а отыскать относящееся к дан­ной области множество, в котором эти объекты хранятся, невозможно, то пусть объект пошлет сооб­щение объекту DM с запросом на поиск.

1.14.2. Сохранение

В рассматриваемой системе торгового терминала нужны постоянные объекты, сохраняющиеся от од­ного сеанса работы системы до другого.

Применим следующий подход. Если управление базовой памятью объектно не ориентировано, добавим объект DM для каждого класса, содержащего объекты, которые должны сохраняться.

В нашей системе добавляются объекты:

— DM человека:

— DM кассира;

• DM экземпляра товара;

• DM регистрирующего устройства;

— DM ящика кассового аппарата;

— DM продажи;

— DM экземпляра строки продажи;

— DM сеанса;

— DM магазина;

— DM категории налога;

— DM универсального кода товара;

— DM цены:

— DM оплаты.

Каждый объект DM знает соответствующие ему объекты PD.

#80. Стратегия"Определение связей между объектами управления данными"

• Для объекта управления данными определите их связи (выраженные в виде атрибутов) с объектами проблемной области (всеми объектами некоторого класса проблемной области), за которые он отвечает.

Каждый объект DM выполняет базовые функции DM: поиск, сохранение, загрузку.

#100. Стратегия "Определение служб управления данными"

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

Добавим объекты DM и их обязанности к объектной модели (рис.1. 61).

Рис.1.61. Объекты управления данными и их обязанности

Подробности использования архитектуры DM с расширяющимися файлами, реляционными база­ми данных и SOM/DSOM изложены в приложении "Управление данными".

1.14.3. Разработка динамики управления данными с помощью сценариев

Разработку динамики взаимодействия с объектами DM можно начать со службы и компоненте HI (для "сохранить" и "загрузить) или же с поиска из компонента PD.

Здесь мы рассмотрим необходимость поиска из объекта PD:

store.getCashierForID

store.getItemForUPC.

Разработаем динамику взаимодействия с объектами DM.

Сценарий: определение кассира по номеру

Для этого сценария нужен объект "кассир DM", который знает, как применять локальную файловую систему для эффективного поиска объекта cashier по номеру. Представление сценария показано на рис.1.62.

Рис.1. 62. Представление сценария "определение кассира по номеру

Заметим, что основная служба поиска, выполняемая всеми объектами DM, в этом представлении применяется специфически: "поиск по <имя атрибута>".

Сценарий: определение экземпляра товара по UPC

В данном случае нужен объект "экземпляр товара DM".

Этот объект знает, как применять локальную файловую систему для эффективного поиска экзем­пляра товара по UPC;.

Представление сценария показано на рис.1.63.

Рис.1. 63. Представление сценария "определение экземпляра товара по UPC"

1.15. Общая схема на данный момент

Объектная модель представлена на рис.1.64 и рис.1.65. Вместе со сценариями данном разделе эти схемы завершают нашу работу по созданию системы для магазина Х.

Рис.1. 64. Общая схема на данный момент в нотации Unified

Рис.1. 65. Общая схема на донный момент (нотация Unified, продолжение)