Добрый дня всем!
В этой статье я не буду касаться технических вопросов и не приведу примеров кода. Эта статья призвана дать понятие, что такое Rule Engine, для чего эта штука и что она умеет. Если вас заинтересует такой подход к построению систем, то вы без проблем найдете Rule Engine на ваш вкус и цвет.
Итак, зачем же эта штука нужна. Возьмем какое нибудь предприятие, которое живет в весьма быстром ритме. Например один из крупнейших аэропортов, где каждые несколько минут происходит посадка или взлет.
Вопросы и ответы
Задайте себе вопросы:
- Кто, как и на основании чего решает, в каком порядке самолеты садятся и взлетают?
- Какова может быть цена неверного решения?
Второй вопрос проще, поэтому ответим сначала на него. Минимальная цена это несколько десятков тысяч евро, а вот максимальная несколько сотен человеческих жизней. А теперь к первому вопросу.
Итак, кто? Ответ: в большинстве случаев люди. Не без помощи компьютеров конечно, но все таки люди. Теперь вопрос: как? Есть список возможных вариантов, человек из них выбирает. Вариантов дается немного, поэтому в принципе особых мук выбора нет. И последний вопрос: на основании чего? Есть правила, их нужно придерживаться и по возможности выполнять. Например, задержка вылета более чем на полчаса весьма нежелательна. Ну и главный вопрос: а причем тут Rule Engine?
Что бы ответить на этот вопрос, нужно ответить на другой вопрос, а именно: а почему человеку предлагается всего несколько вариантов, если:
- Нужно планировать хотя бы часа на 3-4 вперед, а лучше на 8
- Если очередь состоит из порядка 200 самолетов(взлет/посадка)
- Если правил, которые надо учитывать, несколько десятков
- Если эти правила меняются почти каждый день, а иногда и каждый час
- Если всегда есть нештатные ситуации
- И много чего еще...
Ответ: а потому что, все что вы только что прочитали, является некоторым подобием идеальной ситуации, которую все бы хотели видеть, но которая сильно упрощается, потому что в таком случае человек просто не справился бы с потоком информации. Поэтому количество правил, на которые действительно обращают внимание уменьшают в лучшем случае до десятка, а иногда и меньше. И планируют на часок-другой вперед. Вот и появляются всякие неприятные ситуации, а некоторые из них становятся просто хроническими, как например запаздывание вылета на полчаса. В результате теряются весьма большие деньги, т.к. самолеты не летают, как должны, а стоят на полосах и ждут не известно чего. Пассажиры нервничают, репутация компании страдает, она ругается с аэропортом, т.к. платит тому весьма не маленькую сумму денег за услуги и вправе рассчитывать на соответствующее качество оных. Конечно, все уже давно привыкли и прекрасно понимают, что работа аэропорта не из легких, но ведь хочется как всегда лучшего. Как раз в этот момент на помощь приходит Rule Engine.
Что за зверь такой?
Предположим у вас есть объект А, у него есть численное value и булево priority. Есть правило: если value>5, то ставим объекту приоритет, т.е. записываем ему в priority значение true. Таким образом, если у нас есть куча объектов, то прогоняя их через это правило, мы определяем, какие из них согласно этому правилу важны. Это будет первый этап сортировки. Если на этом этапе мы не смогли однозначно определить, что объект А важнее чем объект Б, то нам требуется еще одно правило, или мы решаем, что объекты равнозначны. Именно выполнение правил Rule Engine и делает. Вы даете ей правила, объекты и спрашиваете, какие из объектов к правилам подходят, какие нет. Правило часто и густо выглядит примерно так:
when A.value>5
then A.priority=true
Вот так вот просто. Как вы сами понимаете, правило может быть таким сложным, как вы хотите/как надо.
В чем смысл?
А смысл в том, что эти правила хранятся в отдельном файлике, или в базе данных или еще где нибудь/как нибудь. Если вам надо правило изменить, вам не надо трогать вашу программу, достаточно это самое правило изменить и сказать Rule Engine, что теперь правила изменились. Если какая то определенная Rule Engine вам вдруг разонравилась(тормозит например), вы можете ее без особых проблем заменить на другую.
В чем подвох?
Есть множество моментов, которые иногда совсем не тривиальны. Например: у нас есть два правила:
when A.value>5
then A.value=A.value+5
и
when A.value<7
then A.value=A.value-3
И есть объект, у которого value равно 6. Даем мы Rule Engine этот объект и эти правила, что получим? Неправильно! Почему? Потому что надо еще сказать, в каком порядке правила применяются, т.к. от порядка выполнения зависит результат. Для того что бы сказать Rule Engine в каком порядке она должна применять правила, надо поставить им приоритеты. Если у двух правил приоритеты одинаковые, значит их очередность не влияет на результат.
Или вот еще вопрос. Как обрабатывать правила? Все, пока есть хоть одно, которое выполняется? Тогда можно легко подвесить систему, т.к. одно правило будет что нибудь уменьшить а другое это же самое увеличивать. А может применять правило ровно один раз? Или проверять правило ровно один раз? Чувствуете разницу?
Хочу блэкджек и развратных женщин!
Есть такая штука. Даже много штук, вам понравится.
Правила можно тестить. Да-да, вы же не хотите обрушить вашу систему из-за того, что вы в правиле циферку не ту написали?
Правила можно дебагить. Классно, правда? Вот вам Rule Engine выдает интересный результат. Весьма интересный. Но не тот, который вы ожидаете. Что делать? Дебагить, что ж еще! Ставим точку останова в правиле и вперед.
У правил есть версии. А то как же без системы версий? А вдруг окажется, что наше новое чудное правило, которое мы успешно протестили, приносит нам одни убытки, т.к. раньше мы слали подарки бездетным женщинам, а теперь шлем их лицам интересной сексуальной ориентации? Как исправить? Идем в систему версий, достаем оттуда старое правило, смотрим, кто его изменил, увольняем его нафиг/ лишаем премии/ смотрим внимательно(а вроде мужик ведь? а?)
Проверяем правила на корректность/ не противоречивость. Например:
when A.value>5 and A.value<3
then A.priority=true
Угадайте, что делает это правило? Правильно, ничего! Убираем это правило, ибо не лишнее.
Правила можно накликать. В смысле не как беду накликать, а мышкой накликать. Есть визуальный редактор правил. Теперь ваша секретарша Маша может сама творить интересные вещи с вашей системой. Степень вашего удивления зависит только от креативности Маши.
А вот манагеру Феде кликать правила не нравится, он ведь манагер, он хочет рулить правила писать. Можно и так. Для этого есть такая штука как DSL (Domain Specific Language). Теперь Федя может написать:
«Если клиент студент, то кредит ему не давать».
Да, Федя злой.
Ну хоть одну фамилию то назови!
Что, хотите узнать, как же такое чудо называется, где искать? Ну количество Rule Engine довольно большое. Все что я описал есть например у JBoss Drools. Написана на Java, бесплатная, известная. Рекомендую.
Сам то юзал?
А то. Я писал прототип системы (описана в начале статьи) для одного весьма известного аэропорта в рамках написания своей бакалаврской работы. Было интересно, узнал много нового. На защите работы бакалавра, дабы не говорить абстрактно, что я там творил( потому как низзя!), написал простую программку, которая несколько раз в секунду генерировала целое число, записывала его в список и этот список сортировала. Результат сортировки я выводил тупо в консоль. Дома я написал несколько правил, например:
- Число важно, если оно четно
- Число важно, если оно не четно
- Число важно, если оно делится на 5
- Число важно, если оно простое
И т.д. На защите я преподам эти правила показал, потом мы быстро накликали в редакторе еще одно, потом я стартовал систему и мы игрались несколько минут сортируя список с числами на всякие лады, просто изменяя приоритеты правил(естественно правила менялись на лету, без остановки системы). Было весело.
А теперь, по традиции, я озвучу вам истинную цель этой статьи. После этой статьи было небольшое движение, результаты которого я вам преподнесу в виде отдельной статьи, если эта вам понравится.
Надеюсь, мы еще увидимся(еще сегодня).
Автор: schroeder
