Основываясь на одном из ваших вопросов, я должен сначала кое-что прояснить. По сути:
- Эксперт - это среда выполнения правил.
- Guvnor — инструмент для написания и хранения правил, которые впоследствии будут выполняться в Expert.
Guvnor не предоставляет среду выполнения для ваших правил, кроме того, что требуется для тестовых наборов. Вам всегда будет нужен эксперт для вашей среды выполнения. Guvnor позволяет вам управлять правилами и хранить их. Он также предоставляет некоторые удобные инструменты с графическим интерфейсом, такие как управляемый редактор и таблицы веб-решений. Однако вы также можете редактировать правила в среде IDE, такой как Eclipse, и отправлять их в Guvnor с помощью подключаемых модулей Guvnor WebDav Eclipse.
Как правило, у вас будет веб-приложение Guvnor на одном сервере, а ваши приложения — на другом. Вы можете загрузить скомпилированные правила из Guvnor в сборку вашего приложения и развернуть их вместе с вашим приложением. Кроме того, вы можете определить ресурс URL в своем коде, чтобы создать свою базу знаний, указывающую на URL-адрес пакета Guvnor. В этом случае ваше приложение может загрузить базу знаний при запуске и перезагрузить ее во время выполнения.
Например, следующий код загрузит снимок пакета с именем «Утверждено» в качестве ресурса для создания базы знаний.
UrlResource urlResource =
(UrlResource) ResourceFactory.newUrlResource(
"http://my.guvnor.local/.../package/mypackage/Approved");
urlResource.setBasicAuthentication("enabled");
urlResource.setUsername("myusername");
urlResource.setPassword("mypassword");
KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
builder.add(urlResource, resource.getType());
Изменить. Взгляните на KnowledgeAgent, если вы хотите, чтобы правила перезагружались во время выполнения, когда они изменяются в Guvnor.
Моя основная причина использования Guvnor заключается в том, чтобы позволить нетехническим пользователям создавать правила, используя таблицы решений и управляемые редакторы на основе DSL.
Мне нравится редактировать технические правила в Eclipse, где я могу легко написать вокруг них модульные тесты и оценить, что они ведут себя так, как я ожидаю. Я нахожу это намного проще, чем возможности тестирования в Guvnor. И хотя Guvnor предоставляет некоторый контроль версий, я предпочитаю Subversion/Git в качестве контроля версий для своих технических правил.
Я также пишу DSL в Eclipse, который затем развертываю в Guvnor. Это значительно упрощает работу с управляемыми правилами для нетехнических пользователей.
Правила тестирования
Что касается тестирования, то есть несколько вариантов. В Guvnor есть функция тестирования, которая позволяет вам записывать ожидания на основе различных входных данных. Тем не менее, я лично нахожу этот способ слишком неуклюжим и ограничивающим в использовании. Я предпочитаю писать тесты на Java/JUnit.
Прежде всего, вы можете написать простые модульные тесты, которые загружают одно или два технических правила, написанных на DRL, и оценивают, что они активируются, когда вы думаете, что должны, и генерируют предполагаемые факты, где это уместно.
Для более сложного тестирования я пишу тесты, которые создают базу знаний, используя пакет в Guvnor, вставляют факты и правила огня, чтобы оценить, правильно ли работает пакет в целом, включая те правила, которые были встроены в управляемых редакторах или таблицы решений.
Другое использование Guvnor
Стоит отметить, что функциональность редактора Guvnor становится намного богаче, и он становится редактором и хранилищем не только правил. Например, имеется богатый инструментарий для процессов BPM, который вскоре должен стать лучше, чем то, что вы можете получить в IDE, такой как Eclipse.
Сводка
Если все ваши правила написаны вами и другими разработчиками на DRL, то от использования Guvnor мало пользы. На самом деле я бы нашел это помехой. Однако, если вы хотите воспользоваться управляемыми редакторами или таблицами решений или хотите, чтобы «бизнес» пользователи управляли некоторыми правилами, вам следует более внимательно изучить Guvnor.
person
Steve
schedule
14.12.2012
