- •Стратегии «Руководство по основным действиям и компонентам».
- •Стратегии идентификации назначения и характерных свойств системы
- •Описание примера: Магазин (приложение для торгового терминала)
- •1.4.1. Идентификация назначения системы
- •1.4.2. Идентификация характерных свойств системы
- •Определение средств регистрации важной информации
- •Определение средств ведения бизнеса
- •Определение средств анализа результатов бизнеса
- •Определение средств взаимодействия с другими системами
- •Замечания по поводу назначения и характерных свойств системы
- •1.5. Выбор объектов
- •1.5.1. Использование компонентов модели для организации работы
- •1.5.2. Выбор объектов проблемной области
- •Выбор актеров и участников
- •1.6. Применение образцов: выбор и упорядочивание объектов проблемной области
- •1.6.1. Участник-транзакция
- •1.6.2. Место-транзакция
- •1.6.3. Транзакция - следующая транзакция
- •1.6.4. Контейнер-содержимое
- •1.6.5. Транзакция-экземпляр строки транзакции
- •1.6.6. Актер-участник
- •1.6.7. Общая схема на данный момент
- •1.7. Применение стратегий для определения обязанностей объектов проблемной области
- •1.7.1. Обязанности актеров и участников Актер: человек
- •Участник: кассир
- •Участник: покупатель.
- •1.7.2. Обязанности мест Магазин
- •1.7.3. Обязанности реальных вещей
- •Экземпляр товара
- •Универсальный код товара upc
- •Описание каждого атрибута
- •Регистрирующее устройство
- •Ящик кассового аппарата
- •Важное замечание по поводу состояния операции
- •Категория налога
- •1.7.4. Обязанности транзакций проблемной области
- •Продажа
- •Экземпляр строки продажи
- •Описание каждой службы
- •Новый вариант экземпляра строки продажи
- •Что совпадает, а что отличается Оплата и ее виды
- •1.8. Применение образцов: определение обязанностей в проблемной области
- •Множество-рабочий
- •Участник-транзакция
- •Транзакция-экземпляр строки транзакции
- •Экземпляр товара-экземпляр строки
- •Общая схема на данный момент
- •1.9. Разработка динамики проблемной области с помощью сценариев
- •1.9.1. Выбор ключевых сценариев
- •1.9.2. Сценарий: вычисление общей суммы при продаже
- •1.10. Выбор объектов взаимодействия с человеком
- •1.10.1. Выбор окон
- •1.10.2. Выбор отчетов
- •1.11. Определение обязанностей для взаимодействия с человеком
- •1.11.1. Обязанности для окон
- •Окно регистрации
- •Окно продажи
- •1.11.2. Обязанности отчетов Получение денег
- •1.12. Разработка динамики взаимодействия с человеком с помощью сценариев
- •1.12.1. Поиск имеющих смысл сценариев взаимодействия с человеком
- •Сценарий: регистрация в системе
- •Сценарий: провести продажу
- •1.13.2. Взаимодействие в данной системе
- •1.13.3. Определение обязанностей для взаимодействия систем
- •1.13.4. Множество систем авторизации
- •1.13.5. Разработка динамики взаимодействия систем с помощью сценариев
- •1.14. Выбор объектов управления данными и их обязанностей
- •1.14.1. Поиск
- •1.14.2. Сохранение
- •1.14.3. Разработка динамики управления данными с помощью сценариев
- •1.15. Общая схема на данный момент
Общая схема на данный момент
Мы выбрали объекты и определили обязанности для объектов проблемной области. На рис.1. 38 показана общая схема на данный момент.
Рис.1. 38. Общая схема на данный момент
1.9. Разработка динамики проблемной области с помощью сценариев
Сценарии— это упорядоченная во времени последовательность взаимодействий между объектами, предназначенная для удовлетворения конкретной потребности. Она описывает то, что могут сделать несколько объектов при совместной работе. Сценарии применяются для:
— обнаружения дополнительных объектов;
— лучшего распределения и обновления обязанностей;
— лучшего понимания динамики системы;
— достижения полноты модели;
— тестирования объектной модели (и, в конечном счете, самой системы).
Составьте сценарии и опишите каждый из них с помощью представления объектной модели, предназначенного для изображения данного сценария.
Невозможно, да и не нужно, рассматривать все сценарии в каждой крупной системе.
Необходимо сконцентрироваться на следующих ключевых сценариях, служащих:
— для понимания сути последовательностей взаимодействий самых важных объектов.
Может понадобиться изучение многих (возможно, нескольких десятков) сценариев:
— для понимания устройства объектной модели.
После просмотра ряда исходных сценариев следует постараться уменьшить число вводимых дополнительных объектов и обязанностей.
1.9.1. Выбор ключевых сценариев
#127. Стратегия "Выбор ключевых сценариев" (разработка динамики с помощью сценариев) |
• Разработайте и спланируйте поведение системы в будущем. Создайте сценарии, позволяющие обрабатывать взаимосвязи объектов, необходимые для функционирования рассматриваемой системы в будущем. Используйте подсценарии для облегчения понимания сценария и работы с ним. • Растяните модель, чтобы выяснить степень ее сложности. Примените сценарии, действительно "растягивающие" объектную модель, чтобы полностью выявить степень ее сложности. • Исследуйте ключевые взаимодействия объектов в модели. Примените сценарии, позволяющие изучить динамику важных служб модели. |
Наиболее интересны сценарии, которые начинают со взаимодействия с человеком или системой, а затем переходят к объектам системы.
На данный момент у нас есть только объекты PD, но даже с ними можно создать интересные сценарии. Возьмем службу, которой для выполнения своей задачи нужна помощь других объектов. Например, для продажи может оказаться важной служба вычисления общей суммы. Затем можно рассмотреть сценарии, которые начинают со взаимодействия с человеком.
1.9.2. Сценарий: вычисление общей суммы при продаже
А. Как вы подсчитываете общую сумму при продаже?
Х. Это не очень трудно. Необходимо вычислить промежуточную сумму для всех экземпляров строк и прибавить к ней общую сумму налогов по счету данной продажи. Представление сценария показывает:
— объекты, участвующие в сценарии (в самой верхней части представления);
а затем во временной последовательности (сверху вниз по странице):
— передающую службу, строку сообщения, принимающую службу и аргументы;
Это общая идея. Учтите, что детали здесь скрыты. Представления сценария полностью показывают взаимодействия объектов.
Описания конкретной службы показывают ее детали.
Теперь приступим к построению сценария. Начнем со служб в "распознающем объекте", а затем расширим сценарий, включив в него взаимодействующие объекты. Рассмотрим объект sale с его сообщениями и построим представление сценария (рис.1. 39).
Рис.1. 39. Представление сценария "вычисление общей суммы при продаже" (цикл I)
Сценарий читается следующим образом:
Служба "calcTotal" вызывает службу "calcSubtotal".
Служба "calcSubtoial" возвращает "subtotal".
Служба "calcTotal" вызывает службу "calcTax".
Служба "calcTax" возвращает "totalTax".
Служба "calcTotal" возвращает "total".
Соглашения и замечания о представлении сценария:
— "Распознающий объект" — объект в крайнем левом столбце;
— Первая служба сценария указывается непосредственно под символом "класса с объектами" в первом столбце.
— Передающая служба — имя службы в конце строки сообщения. Для точного указания служба, посылающая сообщение, в символе объекта выделяется квадратными скобками.
— Список аргументов состоит из входов, за которыми стоит точка с запятой, а затем выходов.
Расширим этот сценарий. Как подсчитать промежуточную сумму продажи? Вспомним подходящий образец. Продажа-экземпляр строки продажи — это конкретный пример образца «транзакция-экземпляр строки транзакции».
Продажа поручает каждому своему экземпляру товара подсчитать относящуюся к нему общую сумму. Может ли это сделать экземпляр строки продажи? Нет, так как для этого нужно знать цену данного экземпляра. Она известна экземпляру товара (неявно, путем взаимодействия с объектами своей цены).
Что должен сделать экземпляр товара? Вместо предоставления какого-то значения он должен указать количество товара и дату.
Создадим представление сценария, указав время продажи, экземпляр строки продажи и экземпляр товара (рис.1. 40).
Рис.1. 40. Представление сценарии "вычисление общей суммы при продаже" (цикл II)
Сценарий читается следующим образом:
Объекту saleпоручается подсчитать общую сумму.
Служба "calcTotal" вызывает службу "caIcSubtotal".
Служба "caIcSubtotal" посылает сообщение "calcSubtotal" объектуsale line item (повторяя это сообщение для каждого экземпляра строки продажи).
Экземпляру строки продажи поручается подсчитать промежуточную сумму.
Служба " caIcSubtotal" посылает сообщение "howMuchForQty" объектуitem, сообщая ему количество и дату.
Объекту itemпоручается подсчитать количество экземпляров товара. Служба "howMucliForQty" вызывает службу "getPriceForDate", сообщая ей конкретную дату.
Служба " getPriceForDate" возвращает цену.
Служба " howMuchForQty" возвращает итог.
Служба "calcSubtotal" возвращает промежуточную сумму.
Служба " calcSubtotal" возвращает "subtotal".
Служба "calcTotal" вызывает службу "calcTax".
Служба "calcTax" возвращает "totalTax".
Служба "calcTotal" возвращает "total".
Соглашение относительно другого представления сценария:
— "n" на стрелке сообщения указывает, что данное сообщение может быть послано нескольким объектам (рис.1. 40).
Заметим, что " howMuchForQty" требует, чтобы требуемое количество посылалось в виде аргумента. Можно сказать: "запросите сразу значение, ослабив связывание аргумента". В общем случае способность экземпляра товара вычислять «howMuchForQty»полезна. А при усложнении бизнес - правил объект, вычисляющий скидки для конкретного экземпляра товара, должен знать объектitem(строкам никогда не нужно знать о подобных деталях). Поэтому, увидев изображение, показанное на рис.1. 41, учтите, что имеется в виду следующее (рис.1. 42):
Рис.1. 41. Отравление сообщения нескольким объектам
Рис.1. 42. Изображение сообщений нескольким объектам класса
Теперь настало время подсчитать налог.
А. Как вы подсчитываете величину налога при продаже?
Х. В разных странах взимаются различные налоги. В США сначала подсчитывают промежуточную сумму для каждой категории налогов, затем к каждой категории применяют налоговую ставку и, наконец, суммируют результаты, определяя налог с конкретной продажи.
Вопросы, связанные с налогами, всегда усложняют дело:
Продажа запрашивает умагазинасвоикатегории налога.
Продажапоручаетэкземпляру строки продаживычислить величину налога по конкретной категории.
Экземпляр строкипродажи поручаетэкземпляру товаравычислить величину своего налога по данной категории.
Экземпляр товараполучает свою цену для конкретной даты.Продажазапрашивает категорию налога для расчета.
В дело вступают новые игроки: tax category(категория налога) иstore(магазин) (store действует как множество категорий налогов).
Расширим представление сценария (рис.1. 43).
В данном представлении сценария за двумя строками предыдущих циклов — Служба "calcTotal" вызывает службу "calcTax". Служба "cakTax" возвращает "totalTax" следует:
В объекте sale служба "calcTotal" вызывает службу "calcTax" Служба "calcTax" посылает объекту store сообщение "getTaxCat". Объекту store поручено получить категории налогов. Служба "getTaxCat" возвращает множество категорий налогов.
Рис.1. 43. Представление сценария вычисления налога
В данном представлении сценария за двумя строками предыдущих циклов — Служба "calcTotal" вызывает службу "calcTax". Служба "calcTax" возвращает "totalTax" следует:
В объекте sale служба "calcTotal" вызывает службу "calcTax"
Служба "calcTax" посылает объекту store сообщение "getTaxCat".
Объекту storeпоручено получить категории налогов.
Служба "getTaxCat" возвращает множество категорий налогов.
Служба "calcTax" посылает объекту salelineitem(возможно несколько раз) сообщение "howMuchInTaxCat", сообщая ему категорию налога.
Экземпляру строки продажи поручается вычислить свой налог по данной категории. Служба "howMuchInTaxCat" посылает объекту itemсообщение "howMiuchInTaxCat", сообщая ему категорию налога.
Объекту itemпоручается вычислить свой налог но данной категории.
Служба "howMuchInTaxCat" вызывает службу "getPriceForDate", сообщая ей дату.
Служба " getPriceForDate " возвращает цену.
Служба "howMuchInTaxCat" возвращает итог.
Служба "howMuchInTaxCat" возвращает величину налога.
Служба "getTaxRate" возвращает налоговую ставку для данной категории.
Служба "calcTax" возвращает "totalTax".
Без сценариев невозможно построение эффективных объектных моделей, так как в сценариях разрабатывается динамика системы и обнаруживаются дополнительные объекты и обязанности.