Была ли когда-нибудь система, включающая механизм разработки правил, ПО-НАСТОЯЩЕМУ успешной?[закрыто]

Question

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

Я немного скептически отношусь к движкам правил.Агилист во мне задается вопросом, не являются ли они просто техническим решением технологической проблемы...т.е.нашим разработчикам требуется слишком много времени, чтобы отреагировать на потребность бизнеса в переменах.Решением этой проблемы должен быть более совместный подход к разработке, лучший охват тестированием, более гибкие методы во всем.

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

Answer 1

Я видел два приложения, в которых использовался движок Blaze Rete от Fair Issac.

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

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

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

Answer 2

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

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

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

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

Как и во всем остальном, обычно речь идет о реализации, а не о самой технике.

Answer 3

Да, у Microsoft есть движок бизнес-правил (BRE) в BizTalk, который успешно используется в течение многих лет.Я слышал, что у них были клиенты, которые покупали BizTalk (очень дорогой) только для BRE.

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

Answer 4

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

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

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

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

Механизм создания правил - это еще один инструмент в вашем арсенале инструментов, который при правильном использовании может оказаться ценным.

Answer 5

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

Answer 6

У меня, конечно, были, но я не могу публично говорить о них, но, вероятно, вы общались с кем-то из них несколько раз в этом году ;)

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

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

Answer 7

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

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

Действительно.

Answer 8

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

Answer 9

Механизмы разработки правил обычно используются в страховом бизнесе.Я работал над системами с сотнями (600ish) правил, которые были реализованы в движке правил.Это сработало очень хорошо.

Answer 10

У вас есть кредитный рейтинг?A ФИКО может быть, счет?Это Fвоздух Яsaac СОкорпорация, разработчики движка правил Blaze.

Answer 11

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

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

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