- •Стратегии «Руководство по основным действиям и компонентам».
- •Стратегии идентификации назначения и характерных свойств системы
- •Описание примера: Магазин (приложение для торгового терминала)
- •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. Общая схема на данный момент
Что совпадает, а что отличается Оплата и ее виды
Рассмотрим оплату и три ее вида: наличными, по чеку и по кредитной карточке. Что общего между ними и в чем разница?
A. Определение обязанностей: "что я знаю".
Все виды оплаты знают:
— выплаченную сумму. Разница состоит в том, что каждый объект cash (наличные деньги) знает:
— выданные наличные деньги. Каждый объект check (чек) знает:
— банковский номер;
— номер счета;
— выданную сумму;
— код авторизации. Каждый объект credit (кредитная карточка) знает:
— тип карточки;
— номер карточки;
— срок действия:
— код авторизации.
Заметим, что check и credit имеют общий атрибут — код авторизации. Если общие атрибуты имеют одинаковые имена и смысл и при этом можно использовать относящееся к данной области обобщение, в структуру gen-spec нужно внести новое обобщение, имеющее следующую структуру:
оплата
наличные
авторизованная оплата
чек
кредитная карточка
В результате будет явно выражена общность (рис.1. 35).
Б. Определение обязанностей: "кого я знаю".
Каждая оплата знает соответствующую ей:
— продажу.
(И продажа знает соответствующие ей оплаты. Вспомните, что клиенты Х могут расплачиваться, используя наличные деньги, кредитные карточки и чеки, а также комбинировать их.) В этом виды оплаты похожи между собой. Различия между ними здесь не рассматриваются.
В. Определение обязанностей: "что я делаю".
Общие службы остаются прежними. Разница в том, что в некоторых случаях необходима авторизация оплаты. Поэтому следует считать, что объект authorized payment (авторизованная оплата) может авторизовать самого себя. Добавим к модели службу:
— авторизовать.
Добавим к модели также обязанности для payment (и виды оплаты) (рис.1. 35).
Рис.1. 35. Оплата и виды оплаты: «что я знаю, кого я знаю, что я делаю»
Сеанс
А. Определение обязанностей: "что я знаю".
Атрибуты объекта session(сеанс):
— дата начала;
— время начала;
— дата окончания;
— время окончания.
Б. Определение обязанностей: "кого я знаю".
Объект session знает:
— свое регистрирующее устройство;
— своего кассира. (Каждое регистрирующее устройство и каждый кассир знают свои сеансы.)
В. Определение обязанностей: "что я делаю".
Сеанс — это множество продаж за интервал времени. Он может выполнять следующие службы:
— подсчитывать, сколько (денег собрано) за интервал времени;
— подсчитывать число (продаж) за интервал времени. Добавим обязанности объекта session к объектной модели (рис.1. 36).
Рис.1. 36. Сеанс: "что я знаю, кого я знаю, что я делаю"
1.8. Применение образцов: определение обязанностей в проблемной области
Сейчас мы определим обязанности для каждого объекта PD (проблемной области) в аспекте "что я знаю, кого я знаю и что я делаю".
Рассмотрим образцы. Образец включает в себя стереотипные обязанности каждого объекта данного образца. Покажем это на примере "множество-рабочий".
Множество-рабочий
Изучим фундаментальный образец объектного моделирования: множество-рабочий.
#1. Образец "Множество-рабочий" (фундаментальный образец) |
• Множество-рабочий является фундаментальным образцом объектной модели. • Все другие образцы — это его вариации. • Типичные объектные взаимодействия howMany —> calcForMe calcOverWorkers —> calcForMe howMuch —> calcForMe rankWorkers —> rateMe • Другие замечания "aboutMe" помогает понять, какие еще нужны атрибуты "calcForMe" показывает, какие специальные вычисления могут понадобиться "rankMe" уточняет, какие службы упорядочивания и сравнения нужны "rateMe" помогает понять, какие службы самоконтроля необходимы |
Объект collection (множество) знает некоторое число рабочих. Он делает только то, что относится к множеству рабочих: вычисляет, оценивает и выбирает.
Рабочий выполняет доступные ему задания, используя свои знания, а также информацию, которую ему могут сообщить другие.
Для определения мест применения образца рассмотрим потенциальные образцы игроков и выберем объекты, знающие о нескольких других объектах. Такое знание выражено связью между объектами (или особым видом связи типа целое-часть), имеющей верхнее ограничение "много".
Образцов типа множество-рабочий может быть несколько. Далее описано использование некоторых из них.