Требования к механизмам исполнения правил

Фиксирование и передача сложных бизнес-правил

Системы управления бизнесом обычно имеют дело со сложными повторяющимися задачами, такими как обработка страховых заявлений или маршрутизация пакетов для доставки. Для выполнения подобных задач эти системы содержат запрограммированную специализированную бизнес-логику, но при этом они должны гибко отзываться на изменения. Чтобы упростить разработку и обеспечить быстрое внедрение изменений, были созданы независимые от процедурного кода серверы исполнения бизнес-правил, позволяющие вносить изменения в правила без модификации лежащей в основе программы. Узнайте о средствах и методах записи требований, моделирования и тестирования бизнес-правил.

Бенджамин Либерман, главный архитектор, BioLogic Software Consulting, LLC

Ben LiebermanБенджамин Либерман (Benjamin A. Lieberman) служит главным архитектором в фирме BioLogic Software Consulting, предоставляющей экспертно-консультационные услуги и услуги обучения по широкому кругу тем, связанных с разработкой программного обеспечения, включая анализ требований, анализ и проектирование программного обеспечения, а также совершенствование процесса разработки. Доктор Либерман специализируется в области объектно-ориентированных архитектур и распределенных вычислений. Связаться с ним можно по адресу blieberman@BioLogicSoftwareConsulting.com.



03.09.2012

Вопреки распространенному мнению, наиболее трудная часть разработки программного обеспечения состоит не в самом написании программы для системы, а в фиксировании и переводе неопределенных, неполных и зачастую противоречивых требований бизнеса. Дороже всего стоит исправление ошибок, внесенных на ранней стадии представления требований, поскольку оно требует разработки исправлений и увеличения расходов на обслуживание. Нигде это не проявляется так ясно, как в попытке сформулировать и запрограммировать сложные бизнес-правила.

Существует много определений понятия «бизнес-правило», но в общем случае его лучше всего рассматривать как точку принятия решений в бизнес-процессе. Бизнес-правила описываются логикой вида "если-то-иначе": если удовлетворяется определенный набор бизнес-условий, то выполняется конкретное действие; иначе (в противном случае) может быть выполнено какое-то другое действие. Рассмотрим, например, компанию, предлагающую стимулирующий тариф за свои услуги. Стимулирующий тариф действует ограниченный период времени на определенный набор продуктов или услуг. Внутренние системы обработки должны уметь не только правильно применять стимулирующую ставку для новых клиентов, но также и прекращать рекламную акцию в соответствующее время. Такие действия производятся с помощью бизнес-правил.

Сложности возникают, когда эти правила вносятся в программное обеспечение. Большинство языков программирования напрямую не поддерживают идею независимых правил, которые вступают в действие и срабатывают в результате набора условий — несмотря на существование большого числа бизнес-процессов, определяемых правилами (см. ниже).

Таблица 1. Примеры бизнес-процессов, определяемых правилами
Сфера деятельностиПример
Финансовые решенияИнициирование кредита
СтрахованиеСтрахование от несчастного случая
Планирование или составление маршрутаДоставка пакетов
Поставка продуктовУслуги сотовой связи
Управление материально-техническим снабжениемПоставки точно по графику
Расчет тарифаВоздушный, судовой, железнодорожный, автобусный транспорт

В этой статье изучаются аналитические методы сбора и моделирования сложных бизнес-правил. В качестве примера я буду использовать некие гипотетические правила для тестирования загрязнения воды. В этой предметной области имеются четко заданные правила для определения концентрации загрязнений питьевой воды, установленные Агентством по защите окружающей среды США. Для целей этой статьи предполагается, что тестирование выполняется государственным органом, контролирующим качество местного водоснабжения. Цель состоит в том, чтобы показать, как можно объединить простые правила в более сложные структуры, отражающие надежный бизнес-процесс.

Установление требований бизнес-правил

Правила отличаются от перебора вариантов тем, что описывают бизнес-логику, а не поведение системы. В типичном выборе вариантов продвижение действий происходит в результате взаимодействия конкретного действующего субъекта с системой для достижения определенной цели (например, "получение пробы качества воды"). В отличие от этого правила выполняются только тогда, когда условия для правила в точности удовлетворяются в результате другой системной операции (например, применения платежа к непогашенному остатку). Следовательно, подход к установлению и проверке бизнес-правил полностью отличается от подхода с использованием вариантов.

Определение правил

Правила обычно составляются как четко определенные пары из предложений условия и действия. В целом правила лучше всего записывать в виде набора, в котором все условия должны быть выполнены, чтобы правило сработало. Хотя некоторые механизмы правил позволяют использовать в условиях конструкцию or (ИЛИ), на практике такие конструкции приводят к правилам, трудным для понимания и проверки. В этих случаях лучше создать несколько правил для каждой ситуации or , чем одно сложное правило со многими возможными вариантами совпадения условий. Поэтому в следующих примерах стандартное сочетание условий — это всегда and (И) (см. таблицу 2). Более того, правила следует создавать как можно более независимыми, чтобы для выполнения заданного действия требовалось только одно правило. Такой подход дает возможность независимого тестирования и проверки каждого правила в отдельности; затем эти правила можно объединять в более сложные действия.

Таблица 2. Категории правил
КатегорияПравило
Правила проверкиПроверка данных, проверка целостности
Правила расчетаРасчет значений на основе входных данных
Правила принятия решенийВыбор пути бизнес-процесса
Создание правилСоздание новых объектов данных

Индивидуальные правила

Индивидуальные правила определяются на атомарном уровне — то есть как уникальное сочетание условий, в результате которых будет выполняться одно и только одно правило для этого набора запускающих событий. Простое определение правила приведено в таблице 3, где проба воды оценивается на соответствие установленному стандарту качества воды. В этом случае действие состоит в создании некоторого уведомления, но можно задать в качестве действия правила и более сложное действие (например, выдачу цитаты). Обратите внимание, что такое определение правила можно проверить и понять в отрыве от других правил; нет необходимости разбирать правила, которые могут быть выполнены перед этим правилом, или правила, которые следуют за ним.

Таблица 3. Определение единичного правила
Название правила: оценка пробы воды — бензол
Группа правил: оценка-пробы-воды
УсловиеДействиеПримечание
Действительная проба водыВыдача уведомления: «превышен предел по бензолу»Максимально допустимая концентрация бензола в пробе 0,005 мг/л.
Концентрация бензола > 0.005 мг/л

Иногда присутствие одного условия изменяет другое. Например, новое исследование показало, что при наличии карбофурана (допустимый предел 0,04 мг/л) допустимую концентрацию бензола (номинальное значение 0,005 мг/л) следует снизить на 50 процентов (новый предел = 0,0025 мг/л). Такое правило может быть записано, как показано ниже.

Таблица 4. Измененное определение единичного правила
Название правила: оценка пробы воды — бензол (сниженный порог допуска)
Группа правил: оценка-пробы-воды
УсловиеДействиеПримечание
Действительная проба водыВыдача уведомления: «превышен предел по бензолу»Новое исследование показывает, что допустимый уровень бензола должен быть снижен на 50 процентов при наличии карбофурана.
Концентрация бензола > 0,0025 мг/лВыдача уведомления: «превышен предел по бензолу»
Концентрация карбофурана > 0 мг/л

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

Некоторые правила лучше всего представлять с помощью таблицы принятия решений, которая является просто способом обобщения многих правил, использующих общий набор условий; при этом действия основываются на изменяющихся значениях этих условий. Это распространенная ситуация в финансовых организациях, где решения об удовлетворении запроса на предоставление кредита вырабатываются на основе кредитной истории запрашивающего, статуса занятости, имеющихся активах и т.д.

Таблица 5. Табличное определение правил
Группа правил: определение возможности получения займа
Описание: Кредитный эксперт будет использовать эту таблицу для определения возможности предоставления кредита клиенту.
ЗапросДоходДолгДействие
<10,000>45,000<10,000Утвердить кредит с 5-процентной ставкой
<20,000, >10,001>65,000<10,000Утвердить кредит с 4,5-процентной ставкой
<30,000, >20,001>75,000<10,000Утвердить кредит с 3-процентной ставкой
...

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

Последний тип правил называется деревом правил. Как и в предыдущем примере, методика записи правил является просто сокращенным способом представления нескольких связанных правил, но здесь это позволяет осуществлять визуализацию всего дерева принятия решений, используемого для того, чтобы прийти к конкретному заключению. Как показано на рисунке 1, клиентам может быть предоставлена скидка в зависимости от уровня вознаграждения клиента, географического региона и семейства продуктов, которые они получают.

Рисунок 1. Дерево принятия решений
Дерево принятия решений

Группы правил

Правила могут быть тесно связаны в том смысле, что они используют одинаковые входные данные или выполняют схожие наборы действий (правила проверки, например). Зачастую бывает полезно сгруппировать эти правила, чтобы ограничить количество проверяемых условий. Это делается главным образом для человеческого восприятия, поскольку алгоритмы оптимизации в механизмах правил достаточно эффективны, чтобы оптимизировать оценку условий в правилах. Есть, однако, значительное преимущество в том, что если определенный набор данных не удастся обработать на раннем этапе, то эти данные объявляются непригодными и не подвергаются дальнейшей обработке в последующих правилах. Такое исключение упрощает условия для последующих правил и снижает вероятность ошибок.

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

Рисунок 2. Модель с группами правил
Модель с группами правил

По мере увеличения сложности наборов правил экспертам будет все труднее полностью понимать (и проверять) все взаимодействия между правилами и группами правил. Визуальное моделирование этих взаимодействий и зависимостей предоставляет эффективный механизм взаимодействия между командой разработки, командой тестирования и бизнесом. Три вида моделей, наиболее полезные в этом плане — это структурная модель групп правил, карта зависимости между группами и потоки выполнения, которые осуществляет сам механизм правил.

Как показано на рисунке 2, я применил «стереотипный» механизм расширения унифицированного языка моделирования (Unified Modeling Language, UML) для улучшения UML-диаграммы действий, чтобы получить визуальную модель, описывающую эту информацию. Стереотип «группа-правил» обозначает группу правил, а «правило»— именованное правило. На рисунке 3 показаны два способа обозначения пар «условие» и «действие» для определения правила.

Рисунок 3. UML-модель правил
UML-модель правил

Этот подход полезен при работе непосредственно с бизнес-пользователями, так как он представляет правила визуально, а не в текстовом виде. В сочетании с диаграммой моделирования групп правил эти два представления модели могут дать полную картину правил, встроенных в набор бизнес-правил.


Перевод требований в механизм правил

Определения требований не обязательно делать описанным выше способом, но такой подход легко приводит к простой реализации, которую можно проследить обратно до конкретных требований. В таблице 6 показано, как три примера правил: Проверка пробы воды, Оценка пробы воды — Превышение ПДК и Оценка пробы воды— Фекальные колиморфные бактерии — кодируются с помощью механизма правил с открытым исходным кодом JBoss Rules (Drools).

Таблица 6. Пример определения правила
Наименование правила: Проверка пробы воды
Группа правил: ПробаВоды
Приоритет (значимость): 100
УсловиеДействиеПримечание
Аннулированная проба водыИзвещение об аннулировании пробыПроба помечается как аннулированная.
Наименование правила: Оценка пробы воды — Фекальные колиморфные бактерии
Группа правил: ПробаВоды
Приоритет (значимость): 50
УсловиеДействиеПримечание
Действительная проба водыИзвещение о фекальных колиморфных бактерияхЕсли в пробе найдены фекальные колиморфные бактерии, создается извещение о загрязнении.
Фекальные колиморфные бактерии > 0
Наименование правила: Оценка пробы воды — Превышена предельно допустимая концентрация
Группа правил: ПробаВоды
Приоритет (значимость): 50
УсловиеДействиеПримечание
Действительная проба водыИзвещение: Превышена предельно допустимая концентрацияПредельно допустимая концентрация пробы включается в собранные данные по образцу.
Конц. загрязнений > предельно допустимая концентрация

На рисунке 4 приводится реализация этих трех правил с помощью Drool.

Рисунок 4. Реализация трех правил оценки проб воды с помощью Drools
Реализация трех правил оценки проб воды с помощью Drools

В зависимости от реализации механизма правил и взаимодействия между правилами зачастую существует необходимость установить приоритетность выполнения правил. Это можно сделать двумя способами, первый из которых — ранее упоминавшиеся группы правил и потоки выполнения правил. Второй способ — на уровне индивидуального правила, когда конкретному правилу в наборе можно установить приоритет выше остальных. (В механизме Drools это называется уровнем значимости (salience level).)

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

В приведенном выше примере, несмотря на то, что два правила находятся в одной группе правил (ПробаВоды), в соответствии с установленными уровнями значимости правило оценки будет выполняться после правила проверки. Если проба не прошла проверку, данные пробы можно удалить из рабочей памяти, чтобы они больше не были доступны для обработки в следующих правилах.

Тестирование и проверка

Когда бизнес-правила реализованы в механизме правил, последний шаг состоит в том, чтобы убедиться, что запрограммированные правила соответствуют требованиям. Многие механизмы правил предоставляют средства для тестирования и проверки, но иногда необходимо создать специализированные инструменты. Как показано на рисунке 5, инструмент, написанный в дополнение к средствам тестирования, предоставленным с механизмом Drools, дает возможность команде тестирования выбирать данные проверки «на лету» и немедленно просматривать и результаты, и выполняемые правила.

Рисунок 5. Оценка и тестирование правил
Оценка и тестирование правил

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


Заключение

Программирование бизнес-правил в программных системах — это важная и весьма трудная задача. Представление неоднозначных, неполных или вводящих в заблуждение требований значительно усложняет задачу для точной разработки и ведет к дорогостоящим ошибкам. Сочетание визуальных и текстовых описаний бизнес-правил дает возможность более точной и эффективной записи бизнес-правил, в особенности для реализации с использованием механизма правил. Использование описанных здесь методов помогает предоставить бизнес-аналитикам мощную аналитическую основу для формулирования сложных бизнес-правил.

Ресурсы

Научиться

Получить продукты и технологии

  • Механизм правил JBoss Drools— стабильная и эффективная альтернатива коммерческим машинам правил.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source
ArticleID=833018
ArticleTitle=Требования к механизмам исполнения правил
publish-date=09032012