Создание механизмов бизнес-правил с помощью Drools — мощность для SMEople

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

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

МСП встречается с ИТ, начинается передача знаний

Именно здесь в дело вступает предметный эксперт (SME). SME, как правило, активно участвует в стадии разработки проекта.

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

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

При условии применения гибкого подхода и наличия одного или нескольких МСП на этапе разработки проекта передача знаний будет продолжаться на всех этапах проекта.

Что делать, если полная передача знаний невозможна?

В зависимости от отрасли и проекта МСП может оказаться не в состоянии обеспечить полную передачу знаний.

Например, представьте, что МСП — это врач с 25-летним стажем, а у вас есть 6 месяцев на выполнение проекта. Или представьте себе МСП как биолога с 40-летним стажем — такой уровень знаний просто невозможно передать в реалистичные сроки для проектов по разработке программного обеспечения.

Но что, если область знаний динамична?

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

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

Когда и где механизмы правил имеют смысл?

Для многих программных проектов возможен полный перенос знаний и кодирование бизнес-логики на компьютерном языке, таком как C# или Java.

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

Что такое механизм бизнес-правил?

Механизм правил — это инструмент для выполнения бизнес-правил. Бизнес-правила состоят из фактов и условных утверждений. Любое утверждение «если-то», которое появляется в традиционной бизнес-логике, квалифицируется как бизнес-правило.

Например: если работник более 5 дней подряд болеет и у него нет справки от врача, то его нужно выписать. Если с деловым партнером не связывались более 6 месяцев и за это время он не сделал ни одной покупки, возможно, пришло время отправить ему сердечное электронное письмо. Если у пациента высокая температура тела, проблемы со зрением и есть семейный анамнез глаукомы , возможно, пришло время запросить дополнительное МРТ или другие исследования.

Как МСП пишут бизнес-правила?

Вместо того, чтобы ожидать от малого и среднего бизнеса изучения Java, C# или другого языка программирования, ИТ-отдел создаст для него или нее мини-язык для выражения своих бизнес-правил. Строительные блоки этих правил будут состоять из фактов, которые можно запросить. Некоторые примеры фактов по отраслям/областям практики:

• Человеческие ресурсы: зарплата, должность, менеджер, годы работы в компании
• Медицинские: температура, кровяное давление, текущие лекарства
• Финансовые показатели: текущая цена акций, максимальная/минимальная цена за 52 недели, коэффициент P/E, дата следующего отчета о прибылях и убытках.

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

Как выглядят эти правила?

В оставшейся части этого руководства по механизму правил я буду использовать Drools, механизм правил с открытым исходным кодом на основе Java, который можно найти на сайте www.drools.org и который является проектом JBoss. В Drools правила написаны в виде кода Java и имеют следующую структуру:

Операторы импорта идут сюда:

 rule “Name of rule” when “The if” part of the business logic goes here. then The “then” part of the business logic goes here. end

Слюни и рабочая память

В Drools используется концепция рабочей памяти.

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

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

Оценка правил

После того, как рабочая память Drools загружена правилами и фактами, правила оцениваются в соответствии с частью «тогда» их правила. Если часть «тогда» оценивается как истина, тогда будет выполнена часть «когда» правила.

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

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

Сторона «если» в правиле пускания слюней

В Drools факты представлены объектами. Можно запросить существование или отсутствие типа объекта. Кроме того, атрибуты объекта также могут быть запрошены.

Вот несколько примеров:

Определите, зарабатывает ли сотрудник больше 100 000.

 Employee(salary > 100000)

Определите, имеет ли пациент уровень холестерина выше 200 и принимает Липитор.

 Patient(cholesterol > 200, medications.contains(“lipitor”))

Определите, находится ли цена акции в пределах 1% от ее годового максимума.

 Stock(price >= (yearHigh * .99))

Объединение запросов

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

Например:

Определите, есть ли менеджер, зарабатывающий менее 75 000 долларов, или директор, зарабатывающий менее 100 000 долларов.

 Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)

Использование нескольких типов объектов

Все приведенные до сих пор примеры были основаны на одном типе объекта, таком как Сотрудник или Пациент. Однако Drools позволяет создавать запросы на основе нескольких типов объектов.

Например:

Определите, имеет ли клиент зарплату выше 50 000 долларов и не подал ли он заявление о банкротстве.

 Customer(salary>50000) AND not exists Bankruptcy()

«Тогда» сторона правила

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

В Drools все, что может быть написано на Java, может быть записано в «затем» части правила. Однако, чтобы сделать правила более пригодными для повторного использования, обычно рекомендуется не помещать в правило какой-либо ввод-вывод, код управления потоком или общий код выполнения.

В качестве альтернативы часть правила «тогда» может использоваться для изменения рабочей памяти. Обычной практикой является вставка факта в рабочую память, когда правило оценивается как истинное.

Например:

 rule “LoanApproved” when Customer(credit>700) && not exist LoanOutstanding() then insert(new LoanApproval()) end

Как мы узнаем, когда правило оценивается как истинное?

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

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

 query "GetLoanApproval " $result: LoanApproval() end

Как механизм бизнес-правил взаимодействует с приложением?

Типичные приложения содержат бизнес-логику, графический интерфейс, ввод-вывод и поток управляющего кода.

Например, приложение может обрабатывать запрос пользователя следующим образом:

 GUI ? Flow Control ? I/O ? Business Logic ? I/O ? Flow Control ? GUI

Встраивание механизма правил добавляет к этому процессу несколько шагов:

 GUI ? Flow Control ? I/O ? Create Rules Engine Session ? Add Facts to Working Memory ? Fire Rules ? Determine which rules have evaluated true ? I/O ? Flow Control ? GUI

Как МСП работают с Правилами?

Создание, редактирование и удаление правил

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

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

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

Элементы пользовательского графического интерфейса SME

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

• Syntax Checker — кнопка «проверить синтаксис» может вызвать код Drools для проверки возможных ошибок и их номеров строк.
• Перетаскивание — вместо того, чтобы требовать от SME запоминать доступные им объекты и атрибуты, рассмотрите возможность предоставления им списка выбора, из которого они могут перетаскивать.
• Веб-интерфейс — интерфейс тонкого клиента будет доступен для малого и среднего бизнеса без проблем с распространением. Это пригодится, поскольку графический интерфейс нуждается в дополнительных функциях и общем обслуживании.
• Тестер правил — возможность тестировать отдельные правила без взаимодействия со всем приложением значительно повысит производительность малого и среднего бизнеса. Разрешить графическому интерфейсу SME определять факты, а затем запускать отдельные правила.

Где должны храниться правила?

В Drools обычно есть два способа хранения правил. Drools работает по умолчанию с правилами на основе файлов, которые обычно имеют расширение .drl.

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

В этом руководстве по движку правил затронута лишь очень небольшая часть языка правил Drools. Полное описание можно найти в официальной справочной документации.

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

Теперь мы можем перейти к тому, чтобы показать вам кое-что более интересное — простой реальный пример Drools в действии, в сценарии использования, который должен быть знаком большинству читателей блога Toptal.

Использование слюней в реальном сценарии

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

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

Программное обеспечение для отслеживания кандидатов будет изменено для запуска правил, предоставленных отделом кадров, на каждом этапе принятия решения в процессе найма. HR будет иметь объект «Кандидат», который будет представлять кандидата на работу, чей статус только что был изменен в результате начальной записи, прохождения онлайн-экзамена или ряда различных факторов. Объект «Кандидат» будет иметь поля для представления опыта, результатов тестов, результатов собеседований и т. д.

В следующем примере представлен упрощенный набор правил для вашего рассмотрения. Он не развернут, это простой пример, состоящий из четырех взаимосвязанных правил:

• Отправлено -> Тестирование
• Тестирование -> Интервью
• Интервью -> Проект
• Проект -> Наем

Отправлено -> Тестирование

Основываясь на текущих потребностях клиентов, отдел кадров хотел бы написать правило, которое будет определять, следует ли кандидату проходить онлайн-тестирование.

 Rule “Schedule For Testing” when $candidate: Candidate(status=='Submitted',yrsExperience >= 10, skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5)) then $candidate.setStatus('Testing'); end

Тестирование -> Интервью

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

 Rule “Schedule For Interview” when $candidate: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8); then $candidate.setStatus('Interview'); end

Интервью -> Проект

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

 Rule “Schedule For Project” when $candidate: Candidate(status=='Interview', interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 ); then $candidate.setStatus('Project'); end

Проект -> Наем

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

 Rule “Schedule For Hiring” when $candidate: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 ); then $candidate.setStatus('Hiring'); end

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

Поскольку правила могут быть изменены на лету, у отдела кадров также будет гораздо больше гибкости. Например, отдел кадров может расширить или ограничить процесс отбора, установив различные параметры.

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