Механизм бизнес-правил

Механизм бизнес-правил — это программная система , которая выполняет одно или несколько бизнес-правил в производственной среде выполнения . Правила могут исходить из правового регулирования («Сотрудник может быть уволен по любой причине или без причины, но не по незаконной причине»), политики компании («Все клиенты, которые потратят более 100 долларов США за один раз, получат скидку 10%» ) или другие источники. Система бизнес-правил позволяет определять, тестировать, выполнять и поддерживать политику компании и другие оперативные решения отдельно от кода приложения .

Механизмы правил обычно поддерживают правила, факты, приоритет (оценку), взаимное исключение, предварительные условия и другие функции.

Программное обеспечение механизма правил обычно предоставляется как компонент системы управления бизнес-правилами , которая, помимо других функций, обеспечивает возможность: регистрировать, определять, классифицировать и управлять всеми правилами, проверять согласованность определений правил («Клиенты золотого уровня право на бесплатную доставку при объеме заказа > 10» и «максимальный объем заказа для клиентов уровня Silver = 15»), определить взаимосвязи между различными правилами и связать некоторые из этих правил с ИТ- приложениями, которые затронуты или должны обеспечить соблюдение одного или еще правила.

Вариант использования ИТ [ править ]

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

История [ править ]

В статье в Computerworld движки правил восходят к началу 1990-х годов и к продуктам таких компаний, как Pegasystems , Fair Isaac Corp, ILOG. ^[1] и eMerge ^[2] от Сапиенса .

Стратегии дизайна [ править ]

Усилия многих организаций по созданию правил сочетают в себе аспекты того, что обычно считается проектированием рабочего процесса , с традиционным дизайном правил. Неспособность разделить два подхода может привести к проблемам с возможностью повторного использования и контроля как бизнес-правил, так и рабочих процессов. Подходы к проектированию, позволяющие избежать этого затруднения, разделяют роли бизнес-правил и рабочих процессов следующим образом: ^[3]

Бизнес-правила производят знания;
Рабочие процессы выполняют бизнес-работу.

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

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

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

Большинство механизмов правил на основе Java предоставляют технический интерфейс уровня вызова, основанный на (API) JSR-94 стандарте интерфейса прикладного программирования , чтобы обеспечить интеграцию с различными приложениями, а многие механизмы правил допускают сервис-ориентированную интеграцию через Интернет. основанные на стандартах, такие как WSDL и SOAP .

Большинство механизмов правил предоставляют возможность разрабатывать абстракцию данных , представляющую бизнес-объекты и отношения, для которых должны быть написаны правила. Эта модель бизнес-объекта обычно может заполняться из различных источников, включая XML , POJO , неструктурированные файлы и т. д. Стандартного языка для написания самих правил не существует. Многие движки используют синтаксис, подобный Java , в то время как некоторые позволяют определять собственные языки, удобные для бизнеса.

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

Типы механизмов правил [ править ]

Существует несколько различных типов механизмов правил. Эти типы (как правило) различаются тем, как правила планируются для выполнения.

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

Первый класс обрабатывает так называемые правила производства/ вывода . Эти типы правил используются для представления поведения типа ЕСЛИ условие ТОГДА. Например, такое правило могло бы ответить на вопрос: «Должна ли этому клиенту быть разрешена ипотека?» путем выполнения правил вида «ЕСЛИ какое-то условие, ТО разрешить клиенту ипотеку».
Другой тип механизма правил обрабатывает так называемые правила действий при условиях реакции/события . Реактивные механизмы правил обнаруживают входящие события и реагируют на них, а также обрабатывают шаблоны событий. Например, механизм реактивных правил можно использовать для оповещения менеджера об отсутствии определенных товаров на складе.

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

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

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

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

Существуют некоторые обстоятельства, когда вывод на основе нечеткой логики может быть более подходящим, когда при обработке правил используются эвристики, а не логические правила. Примеры могут включать классификацию клиентов, вывод недостающих данных, расчет ценности клиента и т. д. Язык DARL ^[4] и связанная с ним машина вывода и редакторы являются примером этого подхода.

Механизмы правил для контроля доступа/авторизации [ править ]

Одним из распространенных вариантов использования механизмов правил является стандартизированное управление доступом к приложениям. OASIS определяет архитектуру механизма правил и стандарт, предназначенный для контроля доступа, который называется XACML (расширяемый язык разметки контроля доступа).Одним из ключевых различий между механизмом правил XACML и механизмом бизнес-правил является тот факт, что механизм правил XACML не имеет состояния и не может изменять состояние каких-либо данных.Механизм правил XACML, называемый точкой принятия политического решения (PDP), ожидает двоичного вопроса типа «да/нет», например «Может ли Алиса просмотреть документ D?» и возвращает решение, например, Разрешить/запретить.

См. также [ править ]

Ссылки [ править ]

^ «Знаете ли вы, где находятся все бизнес-правила вашей компании?» . Компьютерный мир . 39 (21). IDG Enterprise (опубликовано 23 мая 2005 г.): 25. 23 мая 2005 г. ISSN 0010-4841 . Проверено 2 февраля 2014 г. Механизмы правил существуют с начала 1990-х годов, когда их продали такие компании, как Pegasystems Inc. в Кембридже, Массачусетс, Fair Isaac Corp. в Миннеаполисе и ILOG в Маунтин-Вью, Калифорния. Обычно они использовались в отраслях с тяжелыми правилами, таких как финансы и страхование. Однако за последние несколько лет на рынок вышло множество поставщиков, и все больше компаний рассматривают механизмы правил как способ добиться большей гибкости в бизнес-операциях.
^ «Платформа разработки программного обеспечения на основе правил eMerge» .
^ Управляема ли ваша система правил событиями? Получено с http://www.sapiens-tech.com/iDuneDownload.dll?GetFile?AppId=225&FileID=216581&Anchor=&ext=.pdf . Архивировано 30 сентября 2018 г. на Wayback Machine .
^ «Язык ДАРЛ» . Архивировано из оригинала 01 сентября 2018 г. Проверено 1 сентября 2018 г.

Библиография [ править ]

Тейлор, Джеймс; Раден, Нил (2007). Умные (достаточно) системы. Прентис Холл. ISBN 0-13-234796-2 .
Дэвид Линтикум (14 февраля 2007 г.). «Машины правил и SOA». Инфоморлд, 14 февраля 2007 г. Получено 23 сентября 2009 г. с http://www.infoworld.com/d/architecture/rules-engines-and-soa-158 .

Внешние ссылки [ править ]

Рекомендации по принятию решения об использовании механизма правил?

[1] «Знаете ли вы, где находятся все бизнес-правила вашей компании?» . Компьютерный мир . 39 (21). IDG Enterprise (опубликовано 23 мая 2005 г.): 25. 23 мая 2005 г. ISSN 0010-4841 . Проверено 2 февраля 2014 г. Механизмы правил существуют с начала 1990-х годов, когда их продали такие компании, как Pegasystems Inc. в Кембридже, Массачусетс, Fair Isaac Corp. в Миннеаполисе и ILOG в Маунтин-Вью, Калифорния. Обычно они использовались в отраслях с тяжелыми правилами, таких как финансы и страхование. Однако за последние несколько лет на рынок вышло множество поставщиков, и все больше компаний рассматривают механизмы правил как способ добиться большей гибкости в бизнес-операциях.

[2] «Платформа разработки программного обеспечения на основе правил eMerge» .

[3] Управляема ли ваша система правил событиями? Получено с http://www.sapiens-tech.com/iDuneDownload.dll?GetFile?AppId=225&FileID=216581&Anchor=&ext=.pdf . Архивировано 30 сентября 2018 г. на Wayback Machine .

[4] «Язык ДАРЛ» . Архивировано из оригинала 01 сентября 2018 г. Проверено 1 сентября 2018 г.

[1]

[2]

[3]

[4]