grule rule engine

«Суслик держит правила»

Grule-Rule-Engine

 import "github.com/hyperjumptech/grule-rule-engine" 

Механизм правил для Go

Grule — это библиотека правил для языка программирования Go (Golang). Вдохновлен знаменитым JBOSS Drools и выполнен гораздо проще.

Как и Drools , Grule имеет свой собственный DSL или предметно-ориентированный язык.

Ниже приведен пример DRL Drools или языка правил Drools:

 rule "SpeedUp"
    salience 10
    when
        $TestCar : TestCarClass( speedUp == true && speed < maxSpeed )
        $DistanceRecord : DistanceRecordClass()
    then
        $TestCar.setSpeed($TestCar.Speed + $TestCar.SpeedIncrement);
        update($TestCar);
        $DistanceRecord.setTotalDistance($DistanceRecord.getTotalDistance() + $TestCar.Speed);
        update($DistanceRecord);
end

GRL Grule выглядит следующим образом:

 rule SpeedUp "When testcar is speeding up we keep increase the speed." salience 10  {
    when
        TestCar . SpeedUp == true && TestCar . Speed < TestCar . MaxSpeed
    then
        TestCar . Speed = TestCar . Speed + TestCar . SpeedIncrement ;
        DistanceRecord . TotalDistance = DistanceRecord . TotalDistance + TestCar . Speed ;
}

Что такое механизм правил

Нет лучшего объяснения, чем статья Мартина Фаулера. Вы можете прочитать статью здесь (RulesEngine Мартина Фаулера).

Взято с сайта TutorialsPoint (с небольшими изменениями).

Механизм правил Grule — это система производственных правил, которая использует основанный на правилах подход для реализации экспертной системы. Экспертные системы — это системы, основанные на знаниях, которые используют представления знаний для обработки полученных знаний в базу знаний, которую можно использовать для рассуждений.

Система производственных правил — это система Тьюринга, в которой основное внимание уделяется представлению знаний для выражения пропозициональной логики и логики первого порядка в краткой, недвусмысленной и декларативной форме.

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

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

Механизм правил позволяет вам определить «Что делать» , а не «Как это сделать».

Что такое правило

(также взято из TutorialsPoint)

Правила — это знания, которые часто выражаются следующим образом: «Когда возникают какие-то условия, выполняйте некоторые задачи».

 When
   < Condition is true >
Then
   < Take desired Action >

Наиболее важной частью правила является его часть «когда». Если часть «когда» удовлетворена, срабатывает часть «то» .

 rule  < rule_name > < rule_description >
   < attribute > < value > {
   when
      < conditions >

   then
      < actions >
}

Преимущества механизма правил

Декларативное программирование

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

Разделение логики и данных

Данные находятся в объектах домена, а бизнес-логика — в правилах. В зависимости от типа проекта такое разделение может быть очень выгодным.

Централизация знаний

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

Гибкость к изменениям

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

Варианты использования

Следующие случаи лучше решать с помощью механизма правил:

1. Экспертная система, которая должна оценивать факты, чтобы сделать какие-то выводы из реальной жизни. Если бы не использовать механизм правил в стиле RETE, можно было бы закодировать каскадный набор операторов if / else , и перестановки комбинаций того, как они могут быть оценены, быстро стали бы невозможными. Механизма правил на основе таблиц может быть достаточно, но он по-прежнему более уязвим к изменениям, и его не очень легко кодировать. Такая система, как Grule, позволяет вам описывать правила и факты вашей системы, освобождая вас от необходимости описывать, как правила оцениваются на основе этих фактов, и скрывая от вас большую часть этой сложности.

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

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

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

5. Система советов/предложений. «Правило» — это просто другой вид данных, что делает его основным кандидатом на определение в другой программе. Этой программой может быть другая экспертная система или искусственный интеллект. Другие системы могут манипулировать правилами, чтобы иметь дело с новыми типами фактов или вновь обнаруженной информацией о предметной области, которую набор правил намеревается моделировать.

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

Однако важно помнить, что машина правил, конечно, не панацея. Существует множество альтернатив для решения проблем «знаний» в программном обеспечении, и их следует использовать там, где они наиболее уместны. Нельзя использовать механизм правил там, где, например, достаточно простой ветки if / else .

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

Документы

Страница документации здесь

Чтобы погрузиться в руководство, посетите Wiki Docs здесь, на Github.

Контрольный показатель

Loading rules into KnowledgeBase :

• Для загрузки 100 правил в базу знаний потребовалось 99342047 ns/op (бралось максимальное значение), что равно ~99.342047ms и ( 49295906 B/op ) ~49.295906MB памяти на операцию.

• Для загрузки 1000 правил в базу знаний потребовалось 933617752 ns/op (бралось максимальное значение), что равно ~933.617752ms и ( 488126636 B/op ) ~488.126636 памяти на операцию.

Executing rules against a fact :

• Чтобы выполнить факт против 100 правил, Grule Engine потребовалось ~9697 ns/op (приняло за основу максимальное значение), что едва ли составляет ~0.009697ms и 3957 B/op , что довольно быстро.

• Чтобы выполнить факт против 1000 правил, Grule Engine потребовалось ~568959 ns/op (приняло максимальное значение за базовое), что едва ли составляет ~0.568959ms и 293710 B/op , что тоже довольно быстро.

Подробный отчет вы можете прочитать здесь

Задачи и нужна помощь

Да. Нам нужны участники, которые сделают Grule еще лучше и полезным для сообщества разработчиков программного обеспечения с открытым исходным кодом.

• Нужно делать все больше и больше тестов.
• Улучшенный тест покрытия кода.
• Лучше комментировать лучшие практики go doc.
• Улучшите обработку аргументов функции, чтобы она стала более гибкой и интуитивно понятной.

Если вы действительно хотите нам помочь, просто Fork проекта и подайте заявку на запрос на включение. Пожалуйста, прочтите наше Руководство по взносам и Кодекс поведения.