«Привет, Тим, это Джекки. У меня проблема с запросом химиката при помощи системы контроля химикатов. Мой менеджер посоветовал обратиться к тебе. Он сказал, что ты был сторонником продукта и занимался требованиями к этой системе». «Да, это так, — ответил Тим.— А в чем проблема?»
«Мне нужно еще немного фосгена для красок, которыми я сейчас занимаюсь, — сказала Джекки, — но система не принимает мой запрос и сообщает, что я уже больше года не посещала занятий по работе с опасными химикатами. О чем это она? Я годами работала с фосгеном и еще более страшными химикатами — и никаких проблем. Почему же мне нельзя получить еще немного фосгена?»
«Ты, возможно, знаешь, что Contoso Pharmaceuticals требует от сотрудников ежегодно прослушивать курс по безопасной работе с химикатами, — заметил Тим. — Такова корпоративная политика; система контроля химикатов лишь проводит ее в жизнь. Я знаю, что раньше кладовщики давали тебе все, что требовалось, но теперь из-за страховки это невозможно. Извини за неудобства, но мы должны подчиняться правилам. Тебе придется пройти обучение, чтобы система выполнила твой запрос».
В любой организации действует широкий набор корпоративных политик, законов и промышленных стандартов. Такие отрасли, как банковское дело, авиация и производство медицинской техники, подчиняются постановлениям правительства. Все эти контролирующие принципы в целом называются бизнес-правилами (business rules). Зачастую их выполнение и соблюдение осуществляется средствами программных систем. В других случаях за соблюдением правил и процедур следят люди.
Большинство бизнес-правил берут начало вне контекста какой-либо конкретной программной системы. Такие правила, как корпоративная политика, обязывающая ежегодно прослушивать курс по работе с опасными химикатами, действуют, даже если приобретение и распространение химикатов осуществляется исключительно вручную. Стандартные правила отчетности существовали даже в дни зеленых наглазных повязок для сна и чернильных авторучек. Тем не менее бизнес-правила — один из основных источников функциональных требований к ПО, поскольку они определяют возможности, которыми должна обладать система для выполнения правил. Даже бизнес-требования высокого уровня могут определяться бизнес-правилами; так, например, система контроля химикатов должна генерировать отчеты о выполнении федеральных и государственных постановлений о хранении и использовании химикатов.
Не все фирмы рассматривают собственные важнейшие бизнес-правила как ценность, которой они и являются на самом деле. Если эта информация не задокументирована и не хранится должным образом, она существует только в головах сотрудников. Но последние могут по-разному понимать правила, в результате чего отдельные программные системы могут пo-разному выполнять одно и то же бизнес-правило. Если вам известно, где и как каждое приложение реализует относящиеся к нему бизнес-правила, модифицировать приложения в случае изменения правил станет гораздо легче.
| Ловушка Недокументированные бизнес-правила известны только отдельным специалистам, а посему они теряются, когда последние увольняются или переходят на другую работу. |
На большом предприятии лишь подмножество всех имеющихся бизнес-правил относится к любому конкретному приложению. Создание набора общих правил помогает аналитикам требований определить потенциальные требования, которые не были выявлены при обсуждении с пользователями. Наличие главного хранилища бизнес-правил упрощает согласованную реализацию приложений, на которые эти правила влияют.
Правила бизнеса
Согласно определению Business Rules Group (1993), «бизнес-правило — это положение, определяющее или ограничивающее какие-либо стороны бизнеса; его назначение — защитить структуру бизнеса, контролировать или влиять на его операции». Целые методологии разработаны специально для создания и документирования бизнес-правил и их применения в автоматизированных системах (Ross, 1997; von Наlle, 2002). Если вы не создаете систему, которая в значительной степени управляется бизнес-правилами, тщательно разработанная методология вам не нужна. Достаточно выявить и задокументировать относящиеся к вашей системе правила и связать их с конкретными функциональными требованиями,
Для организации бизнес-правил предлагается множество разных таксономии (схем классификации) (Ross, 2001; Morgan, 2002; von Halle, 2002). Простейшая из них (рис. 9-1), из пяти типов бизнес-правил, годится в большинстве случаев. Шестая категория — термины: важные для бизнеса слова, фразы и аббревиатуры. Их удобно хранить в словаре. Вести согласованный свод бизнес-правил гораздо важнее при разработке продукта, чем горячо дискутировать о том, как их классифицировать. Давайте рассмотрим различные типы бизнес-правил, с которыми вам придется столкнуться.
Рис. 9-1. Простая таксономия бизнес-правил
Факты
Факты (facts) — это всего лишь верные утверждения о бизнесе. Зачастую они описывают связи и отношения между важными бизнес-терминами. Факты также называют инвариантами — неизменными истинами о сущности данных и их атрибутах. Бизнес-правила во многих случаях могут ссылаться на определенные факты, однако последние обычно не преобразуются напрямую в функциональные требования к ПО. Сведения о сущности данных, важных для системы, иногда применяют в моделях данных, создаваемых аналитиком или архитектором БД (подробнее о моделировании данных — в главе 11). Вот примеры фактов:
· на каждый химический контейнер нанесен уникальный штрих-код;
· оплачивается доставка каждого заказа;
· каждый элемент заказа содержит данные о химикате, его качестве, размере контейнера и числе контейнеров;
· стоимость билетов не возвращается, если покупатель изменяет маршрут;
· со стоимости доставки налог с продаж не берется.
Ограничения
Ограничения (constraints) — определяют, какие операции может выполнять система и ее пользователи. Вот некоторые слова и фразы, которые часто применяются при описании ограничивающего бизнес-правила: должен, не должен, не может и только. Например, в таких комбинациях:
· договор о займе человека младше 18 лет должен подписывать один из его родителей или законный опекун;
· постоянный посетитель библиотеки может отложить для себя до 10 книг;
· сотрудник может запросить вещество из списка химикатов первого уровня опасности, только если за последние 12 месяцев он прошел обучающий курс работы с опасными соединениями;
· все программы должны соответствовать правительственным постановлениям, касающимся использования их людьми с ослабленным зрением;
· в корреспонденции не может отображаться больше 4 цифр номера социального страхования гражданина;
· экипажи коммерческих авиарейсов должны каждые 24 часа отдыхать не менее 8 часов.
| Так много ограничений У проектов по разработке ПО множество разных ограничений. Менеджеры проекта должны соблюдать расписание, а также лимиты по персоналу и бюджету. Эти ограничения уровня проекта фиксируются в плане управления проектом по разработке ПО. Ограничения уровня продукта на проектирование и реализацию, уменьшающие доступные разработчику возможности, записаны в спецификации требований к ПО или спецификации архитектуры. Многие бизнес-правила налагают ограничения на деловые операции. Когда бы эти ограничения ни были отражены в функциональных требованиях к ПО, следует указать соответствующие правила в качестве обоснования всех производных требований. |
Скорее всего в вашей организации есть политики безопасности, определяющие порядок доступа к информационным системам. Обычно они констатируют, какие пароли следует применять, как часто их надо менять, можно ли применять старые пароли и т.д. Все эти ограничения, касающиеся доступа к приложению, можно считать бизнес-правилами. Ввод каждого такого правила в конкретный код упрощает обновление систем, необходимое для соответствия их новым правилам, например изменение необходимой частоты обновления паролей с 90 до 30 дней.
| Как мне отказали Недавно я хотел заказать, используя часть моих «миль постоянного клиента» авиакомпании Fly-By-Night Airlines, билет для моей жены Крис. Когда я попытался сделать это, сервер FlyByNight.com сообщил мне, что из-за возникшей ошибки выдача билета невозможна, и предложил немедленно позвонить по номеру 800-FLY-NITE. Менеджер по бронированию, который поднял трубку, сообщил, что авиакомпания не может оформить премиальный билет за налетанные мной мили по обычной или электронной почте, поскольку у меня и Крис разные фамилии. Для получения билета мне пришлось ехать в кассу аэропорта и предъявлять удостоверение личности. Данный инцидент вызван следующим ограничивающим бизнес-правилом: «Если фамилия пассажира отличается от фамилии лица, оформляющего премиальный билет за налетанные мили, лицо, оформляющее билет, должно получить его лично». По-видимому, основание для этого бизнес-правила — предотвращение мошенничества. ПО Web-узла Fly-By-Night исправно реализует данное правило, но создает неудобства клиентам. Вместо того, чтобы сообщить мне о правиле, касающемся разных фамилий и действиях, которые мне следует выполнить, система просто вывела предупреждение об ошибке. В результате мы с менеджером компании Fly-By-Night по бронированию потратили время на ненужный телефонный разговор. Плохо продуманные реализации бизнес-правил могут вызвать неприятие клиентов и, следовательно, отрицательно скажутся на вашем бизнесе. |
Активаторы операций
Правило, при определенных условиях приводящее к выполнению каких-либо действий, называется активатором операции (action enabler). Человек может выполнять эти действия вручную. Как вариант, правило может управлять некоторыми программными функциями, благодаря которым приложение при выполнении определенных условий реализует нужную модель поведения. Условия, определяющие выполнение операции, иногда представляют собой сложную комбинацию значений «истина» и «ложь», выполняющихся для нескольких отдельных условий. Таблица решений, такая, как в главе 11, — это выразительный способ документирования активирующих операции бизнес-правил расширенной логики. Выражение вида «Если < некоторое условие верно или наступило определенное событие>, то <что-то произойдет», — это ключ, который описывает активатор операции. Вот несколько примеров таких бизнес-правил:
· если на складе имеются контейнеры с запрошенным химикатом, их следует предложить запросившему химикат лицу;
· если срок хранения контейнера с химикатом истек, об этом необходимо уведомить лицо, у которого в данный момент находится контейнер;
· в последний день квартала должны генерироваться отчеты для Управления по безопасности труда и Агентства по защите окружающей среды о хранении и использовании химикатов в этом квартале;
· если клиент заказал книгу автора, написавшего несколько книг, клиенту следует предложить другие книги этого автора, прежде чем принять заказ.
Выводы
Выводы (inference), иногда эту категорию еще называют предположительным знанием, — это правило, устанавливающее новые реалии на основе достоверности определенных условий. Вывод создает новый факт на основе других фактов или вычислений. Выводы зачастую записывают в формате «если — то», применяемом также при записи бизнес-правил, активирующих операции; тем не менее, раздел «то» вывода заключает в себе факт или предположение, а не действие. Вот несколько примеров выводов:
· если платеж не поступил в течение 30 календарных дней с момента отправки счета, счет считается просроченным; если поставщик не может поставить заказанный товар в течение пяти дней с момента получения заказа, заказ считается невыполненным;
· считается, что срок хранения контейнеров с химикатами, разлагающимися на взрывоопасные составляющие, истекает через один год с даты изготовления;
· химикаты с токсичностью агента LD50 ниже 5 мг на килограмм массы мыши считаются опасными.
Вычисления
Компьютеры осуществляют вычисления, и поэтому один из классов бизнес-правил определяет вычисления (computations), выполняемый с использованием математических формул и алгоритмов. Многие вычисления выполняются по внешним для предприятия правилам, например по формулам удержания подоходного налога. В отличие от активирующих операции бизнес-правил, для реализации которых иногда приходится создавать специфические функциональные требования к ПО, правила вычислений в той форме, в которой они выражены, можно рассматривать в качестве требований к ПО. Ниже в текстовой форме дано несколько примеров бизнес-правил для вычислений; как вариант, их можно представить в символьной форме, например в виде математического выражения. Представление таких правил в виде таблицы (табл. 9-1) гораздо понятнее, чем длинный список сложных текстовых выражений:
· цена единицы товара снижается на 10% при заказе от 6 до 10 единиц, на 20% — при заказе от 11 до 20 единиц и на 30% — при заказе свыше 20 единиц;
· плата за доставку по суше в пределах страны для заказов весом свыше 2 фунтов составляет $4,75 плюс 12 центов на унцию или ее часть; 1 комиссия за операции с ценными бумагами, осуществлявшиеся в интерактивном режиме, составляет $12 при числе акций от 1 до 5000.
· комиссия за операции, осуществлявшиеся через специалиста по торговле ценными бумагами, составляет $45 при числе акций от 1 до 5000. При числе акций свыше 5000 комиссия составляет половину указанной суммы;
· общая стоимость заказа вычисляется как сумма стоимостей всех заказанных товаров, за вычетом скидок на количество, плюс государственные и местные налоги, действующие в округе, куда будет доставлен товар, плюс стоимость доставки и плюс необязательный страховой сбор.
·
Таблица 9-1. Использование таблицы для вычислений, необходимых для представления бизнес-правил
| Идентификатор | Количество приобретаемых единиц товара | Скидка, % |
| DISC-1 | 1-5 | |
| DISC-2 | 6-10 | |
| DISC-3 | 11-20 | |
| DISC-4 | свыше 20 |
Отдельное вычисление может включать множество элементов. В последних примерах общая стоимость учитывает скидку на количество, налог с продаж, стоимость доставки и страховой сбор. Это правило запутанно и сложно для понимания. Чтобы избавиться от данного недостатка, пишите свои бизнес-правила на элементарном уровне, а не объединяйте множество деталей в одно правило. Сложное правило может ссылаться на используемые в нем отдельные правила. Это сделает их краткими и простыми. Кроме того, так вы сможете повторно использовать их и комбинировать различными способами. Чтобы писать вычисления и активирующие операции бизнес-правила на элементарном уровне, не используйте в левой части конструкции «если - то» логику «или», а в правой части этой же конструкции — логику «и» (von Halle, 2002). К элементарным бизнес-правилам, влияющим на вычисление общей стоимости из примера выше, относятся правила вычисления скидки из табл. 9-1, а также следующие правила:
· если адрес доставки находится в штате, где действует налог на продажи, то он вычисляется исходя из общей стоимости заказанных товаров с учетом скидки;
· если адрес доставки относится к округу, где действует налог на продажи, то он вычисляется исходя из общей стоимости заказанных товаров с учетом скидки;
· страховой сбор составляет 1 % от общей стоимости заказанных товаров с учетом скидки;
· налог на продажи не взимается со стоимости доставки;
· налог на продажи не взимается со страхового сбора.
Эти бизнес-правила называются элементарными потому, что дальнейшая их детализация невозможна. В конечном итоге вы, скорее всего, создадите множество элементарных бизнес-правил, от комбинаций которых будут зависеть все вычисления и функциональные требования.