Вопрос 3. Реализация прецедентов

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

Более точно можно сказать что, разработчик может описать проектное решение для одного или нескольких сценариев(scenario) прецедента, каждый из которых называется реализацией прецедента. Реализация прецедента – это термин процессаRUPили концепция, позволяющая сохранить связь между требованиями, выраженными в виде прецедентов, и процессом про­ектирования объектов, которые этим требованиям удовлетворяют.

Диаграммы взаимодействия UMLявляются стандартным средством, ис­пользуемым для иллюстрации реализации прецедента. Как упоминалось выше, в процессе проектирования объектов можно использовать прин­ципы и шаблоны, такие какInformationExpertиLowCoupling.

Взаимосвязь между не­которыми артефактами RUPвыглядит следующим образом:

• Системные события определяются на основе прецедентов и подробно ото­бражаются на диаграммах последовательностей.

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

• Системные события представляют собой сообщения, с которых начинаются диаграммы взаимодействия, иллюстрирующие взаимодействие объектов для выполнения требуемых задач – реализацию прецедентов.

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

Пример: Реализация прецедентов для данной итерации разработки pos системы тт

Рассмотрим процесс проектирования реализации прецедентов на основе шабло­нов GRASP. Это будет сделано достаточно подробно, чтобы проиллюстрировать, что при построении диаграмм кооперации нет ничего сверхъестественного. Они базируются на вполне обоснованных принципах.

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

Проектное решение: makeNewSale

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

ОП 1: makeNewSale

Операция	makeNewSale()
Ссылки	Прецеденты: Оформление продажи
Предусловия	Отсутствуют
Постусловия	Создан экземпляр sобъектаSale (созданиеэкземпляра); Экземпляр Sale связан с объектомRegister(формирование ассоциации); Инициализированы атрибуты экземпляра s.

Выбор класса-контроллера

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

• Класс представляет всю систему в целом, устройство Register,POSSystemили подсистему.

• Класс является получателем или обработчиком ProcessSaleHandler,всехсистемных событий для некоторого сценарияProcessSaleSessionпрецедента.

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

Важно понимать, что в данном случае Register – это программный объект из модели проектирования, а не физический реестр системы розничной тор­говли. Он представляет собой программную абстракцию, имя которой способ­ствует сокращению разрыва между именами программных объектов и поня­тиями предметной области.

Таким образом, представленная на рис. 3.1 диаграмма взаимодействия начи­нается с отправляемого сообщения makeNewSaleпрограммному объектуRegister.

Рисунок 3.1 – Применение шаблона Controller

Создание нового экземпляра объекта Sale

Для создания программного объекта Saleвоспользуемся шаблономCreator, согласно которому обязанность по созданию новых экземпляров делегируется классу, содержащему, агрегирующему или записывающему информацию о соз­даваемых классах.

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

Поэтому объекту Registerцелесообразно поручить создание экземпляров объ­ектовSale. Если экземплярыSaleбудут создаваться объектомRegister, то впо­следствии объектRegisterбудет содержать ссылку на текущий экземплярSale.

Кроме того, после создания объекта Saleнеобходимо создать пустую кол­лекцию (контейнер наподобиеListвJava) для записи всех добавляемых впо­следствии экземпляровSalesLineItem. Эта коллекция будет поддерживаться экземпляромSale, который, согласно шаблонуCreator, является наилучшим кандидатом для ее создания.

Таким образом, объект Registerсоздает экземплярыSale,aSale, в свою очередь, создает пустой контейнер, представленный на диаграмме взаимодейст­вия как сложный объект.

Таким образом, получена диаграмма взаимодействия, представленная на рис. 3.2.

Рисунок 3.2 – Создание экземпляров Saleи сложного объекта