- •Проектирование информационных систем
- •Вопрос 1. Обязанности, методы, взаимодействия
- •Вопрос 2. Шаблоны
- •Information Expert
- •Шаблон Information Expert
- •Шаблон Creator
- •Шаблон Low Coupling
- •Шаблон High Cohesion
- •Шаблон Controller
- •Вопрос 3. Реализация прецедентов
- •Пример: Реализация прецедентов для данной итерации разработки pos системы тт
- •Проектное решение: makeNewSale
- •Выбор класса-контроллера
- •Проектное решение: enterItem
- •Проектное решение: endSale
- •Проектное решение: makePayment
- •Проектное решение: startup
- •Проектное решение: store-create
- •Подключение уровня интерфейса пользователя к уровню предметной области
Вопрос 3. Реализация прецедентов
Реализация прецедента показывает, как определенный прецедент реализуется в рамках модели проектирования в терминах взаимодействующих объектов".
Более точно можно сказать что, разработчик может описать проектное решение для одного или нескольких сценариев(scenario) прецедента, каждый из которых называется реализацией прецедента. Реализация прецедента – это термин процессаRUPили концепция, позволяющая сохранить связь между требованиями, выраженными в виде прецедентов, и процессом проектирования объектов, которые этим требованиям удовлетворяют.
Диаграммы взаимодействия UMLявляются стандартным средством, используемым для иллюстрации реализации прецедента. Как упоминалось выше, в процессе проектирования объектов можно использовать принципы и шаблоны, такие какInformationExpertиLowCoupling.
Взаимосвязь между некоторыми артефактами RUPвыглядит следующим образом:
Системные события определяются на основе прецедентов и подробно отображаются на диаграммах последовательностей.
Результаты системных событий в терминах изменения объектов предметной области могут дополнительно определяться в описаниях системных операций.
Системные события представляют собой сообщения, с которых начинаются диаграммы взаимодействия, иллюстрирующие взаимодействие объектов для выполнения требуемых задач – реализацию прецедентов.
Диаграммы взаимодействия включают процессы передачи сообщений между программными объектами, имена которых зачастую определяются именами концептуальных классов модели предметной области, а также другими классами объектов.
Пример: Реализация прецедентов для данной итерации разработки pos системы тт
Рассмотрим процесс проектирования реализации прецедентов на основе шаблонов GRASP. Это будет сделано достаточно подробно, чтобы проиллюстрировать, что при построении диаграмм кооперации нет ничего сверхъестественного. Они базируются на вполне обоснованных принципах.
Объекты, принимающие участие в обработке каждого системного события, будут показаны на отдельной диаграмме, чтобы сфокусировать внимание на каждом проектном решении. Однако их можно сгруппировать и поместить на общей диаграмме последовательностей.
Проектное решение: makeNewSale
Системная операция makeNewSale инициируется в тот момент, когда кассир передает запрос о начале новой продажи после того, как покупатель подходит к кассе с выбранными покупками. Необходимую для реализации этой операции информацию можно почерпнуть непосредственно из описания прецедента, однако при рассмотрении POS-системы мы условились составлять описания для всех системных операций.
ОП 1: makeNewSale
Операция
|
makeNewSale()
|
Ссылки
|
Прецеденты: Оформление продажи
|
Предусловия
|
Отсутствуют
|
Постусловия
|
|
Выбор класса-контроллера
Сначала необходимо выбрать контроллер для обработки сообщений системной операции 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и сложного объекта