Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Евгений / идз1 / Пособие_Об_анал.doc
Скачиваний:
19
Добавлен:
31.03.2015
Размер:
1.44 Mб
Скачать

Выбор актеров и участников

Актер— это человек, организация или что-то другое, всегда отличающееся от участника по одному или нескольким параметрам. Участник ведет себя специфически, играет роль, выполняет особую миссию.

#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. Выбор транзакций

Соседние файлы в папке идз1