Объектно-ориентированный анализ и проектирование с примерами приложений на С++

Сейчас, когда мы представили себе систему в целом, продолжим наш анализ и изучим несколько сценариев ее работы. Сначала перечислим ряд основных режимов использования:

• Клиент звонит по телефону в удаленную телемаркетинговую организацию, чтобы сделать заказ.

• Клиент посылает заказ по почте.

• Клиент звонит, чтобы узнать состояние дел по его заказу.

• Клиент звонит, чтобы добавить или убрать некоторые позиции из заказа.

• Кладовщик получает указание отгрузить клиенту необходимое количество товара.

• Служба доставки получает со склада заказанные клиентом товары и готовит их к отправке.

• Бухгалтерия готовит счет для клиента.

• Отдел закупок готовит заказ на новый товар.

• Отдел закупок добавляет или удаляет имя поставщика из списка.

• Отдел закупок запрашивает поставщика о состоянии заказа.

• Отдел приема товара принимает груз от поставщика и проверяет его соответствие заказу.

• Кладовщик заносит новый товар в список.

• Бухгалтерия отмечает прибытие нового товара.

• Плановый отдел генерирует отчет о показателях продаж по различным типам продуктов.

• Плановый отдел генерирует отчет для налоговых органов с указанием количества товаров на складах.

Каждый из основных сценариев может включать в себя ряд вторичных:

• Заказанного клиентом товара нет на складе.

• Заказ клиента неверно оформлен, или в нем присутствуют несуществующие или устаревшие идентификаторы товаров.

• Клиент звонит, чтобы проверить состояние заказа, но не помнит точно что, кем и когда было заказано.

• Кладовщик получил расходную накладную, но некоторые перечисленные в ней товары не нашлись.

• Служба доставки получает заказанные клиентом товары, но они не соответствуют заказу.

• Клиент не заплатил по счету.

• Отдел закупок делает новый заказ, но поставщик либо ушел из бизнеса, либо больше не поставляет заказанный тип товара.

• Отдел приема товара принимает груз, не полностью соответствующий заказу.

• Кладовщик хочет разместить на складе новый товар, но обнаруживается, что для него нет места.

• Изменяются налоговые коды, что вынуждает плановый отдел составить новый инвентаризационный список находящихся на складе товаров.

Для системы такой сложности, наверно, будут выявлены десятки основных сценариев и еще большее количество вторичных. Этот этап анализа может занять несколько недель, пока не удастся добиться более или менее подробного уровня детализации [Но помните о параличе анализа: если фаза анализа не укладывается в сроки, диктуемые бизнесом, то "оставь надежду всяк сюда входящий", - этот бизнес не для вас]. Поэтому мы настоятельно советуем применять правило восьмидесяти процентов: не ждите, пока сформируется полный список всех сценариев (никакого времени на это не хватит), изучите около 80% наиболее интересных из них и, если возможно, попытайтесь хотя бы оценочно проверить правильность общей концепции. В этой главе мы подробно остановимся на двух основных сценариях.

На рис. 10-2 представлен сценарий, в котором покупатель размещает свой заказ в телемаркетинговой фирме. В выполнении этой системной функции задействовано несколько различных объектов. И хотя управление осуществляется взаимодействием клиента (aCustomer) с агентом (anAgent), есть и другие ключевые объекты, а именно: сведения о клиенте (aCustomerRecord), база данных о товарах (inventoryDatabase) и заявка на комплектование (aPackingOrder), являющиеся абстракциями системы складского учета. Этот список абстракций формируется как раз на этапе рассмотрения сценариев работы.  

 Рис. 10-2. Сценарий заказа.

 

Рис. 10-3. Сценарий выполнения заказа.

Рис. 10-3 отражает продолжение данного сценария. На нем представлена схема взаимодействия кладовщика и расходной накладной. Мы видим, что здесь кладовщик является главной фигурой. Он взаимодействует с другими объектами, например с отгрузкой (shipping), которой не было в предыдущем сценарии. Однако большинство объектов, фигурирующих на рис. 10-3, присутствуют также и на рис. 10-2, хотя они играют в этих сценариях различные роли. Например, в сценарии взаимодействия с клиентом мы создаем заказ (anOrder) как документ, в котором отражены требования клиента. В складском сценарии тот же самый заказ исполняется.

При составлении каждого из таких сценариев мы должны постоянно задавать себе ряд вопросов. Какой объект будет нести ответственность за выполнение того или иного действия? Как объект будет проводить ту или иную операцию: самостоятельно или используя свойства другого объекта? Не слишком ли много операций вменяется в круг обязанностей данного объекта? Что произойдет при ошибке в ходе выполнения сценария (какие постусловия могут нарушиться)? Что случится, если будут нарушены некоторые предусловия?

Занимаясь подобным антропоморфизмом для каждого функционального свойства системы, мы откроем в системе целый ряд интересных объектов высокого уровня. Сначала перечислим лиц, взаимодействующих с системой:

• Customer - клиент

• Supplier - поставщик

• OrderAgent - сотрудник отдела продаж

• Accountant - бухгалтер