- •Стратегии «Руководство по основным действиям и компонентам».
- •Стратегии идентификации назначения и характерных свойств системы
- •Описание примера: Магазин (приложение для торгового терминала)
- •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. Общая схема на данный момент
Выбор актеров и участников
Актер— это человек, организация или что-то другое, всегда отличающееся от участника по одному или нескольким параметрам. Участник ведет себя специфически, играет роль, выполняет особую миссию.
#13. Стратегия "Выбор актеров" |
• Найдите актеров - людей и организации, которые действуют как участники рассматриваемой системы. • Примеры: человек, организация (агентство, компания, корпорация, фонд). |
Сейчас актером будет человек. Позже, возможно, мы заинтересуемся и организацией.
#14. Стратегия "Выбор участников" |
• Проанализируйте участие каждого актера с точки зрения интересов рассматриваемой системы. • Каждый актер в течение времени может вести себя одинаково и по-разному. Актер один и тот же — способы его участия в системе различны. Образно говоря, это то же самое, что носить разные шляпы в течение одного и того же дня. • Примеры: агент, претендент на должность, покупатель, кассир, клерк, клиент, штатский, потребитель, дилер, делегат, дистрибьютор, донор, работодатель, инвестор, производитель, офицер, чиновник, клерк по заказам, владелец, участник, политик, профессионал, потенциальный клиент, получатель, розничный торговец, клерк по продаже, продавец, поставщик, студент, подписчик, руководитель, снабженец, подозреваемый, учитель, оптовый торговец, рабочий. |
В применении системы торгового терминала человек может участвовать как:
— кассир;
— главный кассир;
— покупатель.
Назначение системы и ее характерные свойства задают стандарт, точку поиска нужных объектов. Объект выбирается, если он соответствует контексту обязанностей системы.Если такого соответствия нет, системе добавляется новое характерное свойство или объект помещается в компонент "не сейчас".
Кассир и главный кассир
Объект "кассир" очень важен, и система будет оценивать производительность каждого кассира. А как быть с главным кассиром?
Его можно моделировать как другой вид участника, фактически, как конкретный вид или специализацию кассира. Когда следует так поступать? Проверим потенциальные атрибуты.
#68. Стратегия "Частично применимые атрибуты"
|
• Атрибут относится только к конкретным объектам класса? • Есть ли у вас атрибут, относящийся только к конкретным типам объектов? • Есть ли у вас атрибут, который может иметь значение "неприменим"? • Если да, то выделите ограниченный атрибут в конкретный класс. |
Теперь проверим потенциальные службы.
#121. Стратегия "Частично применимые службы" |
• Есть ли у вас служба, применимая только к конкретным объектам класса? • Есть ли у вас служба, применимая только к конкретным типам объектов? • Есть ли у вас служба, которая проверяет собственный тип, а затем действует соответствующим образом? • Если да, выделите ограниченную службу в конкретный класс. |
Добавлять другой класс участников можно только тогда, когда объект "главный кассир" знает или делает то, чего не знает и не делает объект "кассир".
Можно также моделировать главного кассира вместе с другим участником, выражая простое различие между ними с помощью значений атрибутов. В этом случае главного кассира можно считать кассиром с более высоким уровнем авторизации. Единственная разница между ними — значение уровня авторизации. Такой способ вполне приемлем — в данном случае различия по значению достаточно.
Покупатель
Добавлять объект "покупатель" имеет смысл, только если есть способ определить покупателей Х или, по крайней мере, некоторых из них.
#47. Стратегия "Способ узнать" |
• Необходим способ узнавания каждого объекта и значений его атрибутов. • Если способа узнавания объектов нет, нужно его найти или поместить объект в компонент модели "не сейчас". • Пример: покупатель. Необходим способ узнавания объекта "покупатель"; при его отсутствии следует поместить покупателя в компонент модели "не сейчас". |
Если каждый покупатель входит в магазин, а затем покидает его, оставаясь анонимным, объект "покупатель" в объектной модели не нужен, так как система не должна ничего знать о нем.
Но как быть, если новая система обязана идентифицировать, по крайней мере, некоторых или конкретных покупателей Х? Как кассирам Х их определить? Х может предложить гарантийную расчетную карточку или специальную программу для постоянного покупателя.
А. Что вы думаете по поводу программы для постоянных покупателей?
Х. Прекрасная мысль, но в настоящий момента не актуальная! У меня сейчас и без того достаточно перемен.
Добавьте person (человека) и cashier (кассира) к компоненту проблемной области, a organization (организацию), customer (покупателя) и head cashier (главного кассира) — к компоненту "не сейчас" (рис.1.3).
Рис.1.3. Выбор актеров и участников
Об именах классов:
#38. Стратегия "Применение словаря области" |
• Используйте словарь области. • Попросите экспертов в данной области удалить те имена предметов, которые не созданы экспертами. • Не говорите за экспертов своими словами. • Не изменяйте словарь, если эксперт не скажет, что это необходимо. • Не изменяйте словарь области, пока эксперты не решат изменить свой собственный словарь. |
О символике класса с объектами: внутренний прямоугольник, ограниченный жирной линией, представляет один или несколько объектов класса. Имя класса находится в верхнем отделе, атрибуты в среднем, а службы в нижнем.
Выбор мест
#15. Стратегия "Выбор мест" |
• Найдите места для расположения вещей и для хранения или расположения других объектов. • Примеры: аэропорт, сборочный конвейер, банк, клиника, железнодорожная станция, географическая точка, ангар, больница, промышленный узел, плантация, регион, торговый центр, сервисный центр, полка, станция, магазин, склад, зона. |
Места для расположения вещей и хранения или содержания других объектов крайне важны. В предприятии Х это:
— магазин;
полка.
Оба эти класса относятся к проблемной области.
#42. Стратегия "Обязанности системы" |
• Обязана ли система что-то знать о данном объекте или что-то делать с ним? • Если нет, поместите этот объект в компонент модели "не сейчас". |
Обязана ли система знать что-то о магазине или о полке, что-то делать с ними или соответствовать их характерным свойствам?
Магазин — это контейнер, вместилище вещей.
#22. Стратегия "Выбор контейнера объектов" |
• Используйте относящийся к данной области контейнер, содержащий другие объекты. • Примеры: аэропорт, самолет, секция, банк, бункер, здание, кабинет, папка, гараж, ангар, больница, шкаф, комната, сейф, товарный склад. |
Магазин — это контейнер со множеством предметов, включающим кассиров, регистрирующие устройства и экземпляры продаваемых вещей. Поэтому данный объект — удобное место для расчетов, относящихся ко всем содержащимся в нем объектам. Он соответствует характерными свойствами системы, поэтому его следует включить в модель и добавить к компоненту проблемной области.
Полка тоже может быть важной, особенно если система должна следить за "производительностью" каждой полки. Она может знать, что на ней находится и в каком порядке расположено.
Однако такая обязанность находится вне пределов назначения рассматриваемой системы, поэтому полку лучше поместить в компонент модели "не сейчас" (рис.1.4).
Рис.1.4. Выбор мест
Теперь мы рассмотрим виды магазинов.
#34. Стратегия "Выбор видов объектов" |
• Применяйте метод обобщения-ограничения (gen-spec) для поиска дополнительных классов. Рассмотрите каждый класс обобщения. Присвойте имена результатам его ограничений, которые соответствуют целям системы. Рассмотрите каждое ограничение. Присвойте имена результатам его обобщений, которые соответствуют целям системы. • Примеры: оборудование, виды оборудования, участники, виды участников, транзакции, виды транзакций. |
Магазин — это один из способов торговли. Возможно, со временем наша Х перейдет и к другим способам торговли (например, по каталогу).
Магазины можно далее разделить по видам (например: супермаркет, бакалейный магазин, промтоварный магазин). Но пока мы будем рассматривать магазин в общем.
Выбор вещей
Реальные вещи
#16. Стратегия "Выбор реальных вещей" |
• Найдите реальные вещи, используемые в данной проблемной области. • Рассмотрите бизнес-процессы и из множества объектов выберите реальные. • Примеры: счет, кассовый аппарат, выдвижной ящик для денег кассового аппарата, экземпляр товара, план, процедура, продукт, расписание, запланированное событие. |
В магазине реальными вещами являются:
— экземпляр товара;
— регистрирующее устройство;
— выдвижной ящик для денег кассового аппарата.
(Заметим, что регистрирующее устройство состоит из нескольких других, которые в нашей объектной модели не нужны: устройства считывания с магнитной полоски, сканера ярлыков, клавиатуры, принтера для чеков.)
Виды вещей
Интерес могут представлять следующие категории:
— подверженность порче: портящийся, непортящийся;
— обложение налогом: облагаемый налогом, не облагаемый налогом;
— тип: молочный продукт, консервы, замороженные продукты. Нужно ли добавлять классы, представляющие эти различные виды вещей? Для каждой категории учтите следующее:
— Если различия не имеют значения, забудьте о них.
— Если важно значение категории, добавьте атрибут.
— Если категория содержит дополнительные атрибуты, добавьте специальный класс и внесите в него эти атрибуты.
— Если категория содержит различные службы, добавьте специальный класс и внесите в него эти службы.
В данном же случае, в силу особенностей системы, такие различия не имеют значения.
Дескриптивные вещи
#19. Стратегия "Выбор экземпляров и конкретных экземпляров" |
• Найдите экземпляры — дескриптивные объекты со значениями, относящимися к некоторым конкретным экземплярам, и действия, применимые к ним. • Примеры: самолет-конкретный самолет, описание займа-конкретный заем, описание работы-конкретная работа, описание видеокассеты-видеокассета, экземпляр категории цены-конкретный экземпляр, экземпляр категории налога-конкретный экземпляр. |
Из всех видов дескриптивных каталогов или таблиц для рассматриваемой системы потребуются таблицы налогообложения.
Для работы с каждой из них необходимо следить за категориями налогов и налоговыми ставками. Нужно добавить объект "категория налога", чтобы контролировать каждую категорию, ее ставку и реальный срок. "Реальные вещи" и "дескриптивные вещи" добавляются к объектной модели (рис.1.5).
Рис. 1.5. Выбор реальных и дескриптивных вещей
Транзакции как вещи
В контексте построения объектной модели "транзакция" — это запись или регистрация любого важного события, поэтому ее можно назвать "запомненным важным событием". Объект "транзакция" знает о нем, об участвующих в нем игроках и определяет относящиеся к нему вещи.
#17. Стратегия "Выбор транзакций" |
• Найдите транзакции — запомненные события, события, о которых система все время должна помнить. Транзакция — это момент времени (например продажа) или временной интервал (например прокат). • Найдите вхождение записи, с которым необходимо работать, чтобы отвечать на вопросы или осуществлять контроль. • Примеры; договор, оценка, авторизация, контракт, поставка, депозит, происшествие, запрос, заказ, оплата, тематический отчет, покупка, возврат, регистрация, прокат, резервирование, продажа, перестановка, поставка, подписка, временная скидка, заглавие, отзыв. • Замечание. Почти все транзакции состоят из ряда экземпляров строк транзакции. • Замечание. Возможные источники транзакций: Окно (зарегистрированное событие основано на взаимодействии с человеком в некоторый момент времени); Другой объект, отслеживающий важные события и регистрирующий их; Другая система, с которой ваша система взаимодействует для регистрации событий. |
Итак, вопрос в том, какие транзакции, или значительные события, должна записывать система, предназначенная для магазина Х. Предположим, что такими событиями являются: продажа, оплата, сопровождающая каждую продажу, сеанс (между входом и выходом из системы).
Продажа
Одной из транзакций является продажа.
А. Х, что главное в вашем взаимодействии с покупателем? Х. Мы продаем ему что-нибудь. А. У этой операции есть специальное название? Х. Специальное название — "продажа". (Сейчас оно не такое уж и специальное.) А. Она включает в себя только то, что вы продаете покупателю? Х. Продажа может включать в себя и не только собственно продажу, но и возврат. Запомните это! В словаре данной области есть "продажа". Кто-то может сказать, что нужно использовать более точный термин "транзакция продажи". Не делайте этого! Важно никогда не изменять словарь. Изменяйте его только в том случае, если клиент сам этого пожелает, — иначе вы всегда будете отображать его слова в свои собственные, что непродуктивно и неприятно.
Большинство транзакций состоит из частей, называемых экземплярами строк. Продажа — не исключение; это множество, состоящее из конкретного числа экземпляров строки продажи. Добавьте к модели классы sale (продажа) и sale line item (экземпляр строки продажи) (рис.1.7).
Виды продажи
Рассмотрим виды продажи: продажи, возвраты.
Нужно ли проводить различие между продажей и возвратом? А. Чем продажа отличается от возврата? Х. Единственная разница в положительной или отрицательной сумме платежа.
Добавлять к системе оба класса: "sale" (продажа) и "return" (возврат) не нужно. В данном случае обязанности системы по отношению к ним идентичны. Единственная разница заключается в специфике суммы платежа.
Оплата
Оплата тоже имеет важное значение.
А. Какие виды оплаты вы принимаете? Х. Наличными, по чеку, по кредитной карточке или в комбинации. А. Комбинация этих видов действительно приемлема? Х. Да, особенно утром. Не стоит удивляться этому. А. Хорошо, я учту ваши слова.
Наличные, чек и снятие со счета по кредитной карточке — виды оплаты. Нужно ли знать и выполнять различные операции, основанные на виде (видах) оплаты? Возможно. Тогда добавьте эти специальные классы к объектной модели. Позже их можно перенести их в набор "не сейчас", и в этом нет ничего плохого. Со временем вы узнаете многое из того, что необходимо для рассматриваемой системы.
Моделирование gen-spec изображено на рис.1.6.
Рис. 1.6. Gen-spec
Значком gen-spec является полукруг. Обобщения связаны с его округлой границей, ограничения — с прямой.
По соглашению, класс обобщения может иметь объекты или не иметь их; классы ограничения самого нижнего уровня должны иметь объекты, находящиеся в прямом соответствии друг другу. В данном примере класс обобщения не имеет таких объектов.
Сеанс
Сеансы важны, так как - в силу особенностей системы - нужно следить за производительностью кассира. Для подсчета может понадобиться информация о всех сеансах конкретного кассира.
Добавление транзакций к объектной модели
Добавьте к объектной модели классы:
— sale (продажа), sale line item (экземпляр строки продажи);
— payment (оплата), check (чек), cash (наличные деньги), charge (кредитная карточка);
— session (сеанс). Смотри рис.1.7.
Рис. 1.7. Выбор транзакций