Construindo Mecanismos de Regras de Negócios com Drools - Poder para o SMEople

Uma das coisas mais incríveis de trabalhar no desenvolvimento de software é a capacidade de trabalhar em diversos setores - especialmente se você for um consultor. A maioria das habilidades de desenvolvimento de software que você aprende enquanto trabalha em um setor é transferível diretamente para vários outros setores, empresas, projetos e nichos.

Estou falando de tópicos como design de banco de dados, padrões de design, layouts de GUI, gerenciamento de eventos, etc. Então, é claro, há tópicos específicos para um determinado setor, empresa ou projeto.

PME encontra TI, começa a transferência de conhecimento

É aqui que entra o especialista no assunto (SME). Um SME normalmente estará muito envolvido na fase de concepção do projeto.

O SME trabalha no setor há muito tempo, conhece a linguagem e entende a lógica de negócios por trás da codificação. O SME pode ter algum conhecimento de desenvolvimento de software, mas isso não é necessário para o sucesso do projeto.

Para muitos projetos, a menos que o desenvolvedor de software tenha uma grande compreensão da lógica de negócios, concluir um aplicativo de software bem-sucedido será relativamente difícil. A quantidade de tempo que precisa ser gasta na transferência de conhecimento varia muito com base na complexidade do projeto.

Supondo que uma abordagem ágil seja adotada e uma ou mais PMEs estejam disponíveis durante toda a fase de desenvolvimento do projeto, a transferência de conhecimento continuará durante todas as etapas do projeto.

E se a transferência completa de conhecimento não for viável?

Dependendo do setor e do projeto, pode não ser possível para uma PME fornecer transferência de conhecimento completa.

Por exemplo, imagine se o SME for um médico com 25 anos de experiência e você tiver 6 meses para concluir um projeto. Ou imagine o SME como um biólogo com 40 anos de experiência – tal nível de conhecimento simplesmente não pode ser transferido em um prazo realista para projetos de desenvolvimento de software.

Mas e se a área de conhecimento for dinâmica?

Normalmente, o software é lançado em um cronograma definido com base no tempo ou nos recursos. No entanto, as regras de negócios em alguns setores mudam com muito mais frequência.

Em muitos casos, pode não ser viável lançar software com a frequência necessária para acompanhar as mudanças do setor. Ter a capacidade de externalizar regras de negócios em um mecanismo de regras de negócios pode fazer sentido em tais cenários. A capacidade de um projeto de software ser capaz de suportar mudanças ajudará muito a garantir seu sucesso final a longo prazo.

Quando e onde os mecanismos de regras fazem sentido?

Para muitos projetos de software, é viável que ocorra a transferência total de conhecimento e que a lógica de negócios seja codificada em uma linguagem de computador como C# ou Java.

No entanto, há um subconjunto de projetos em que a quantidade de compreensão de um assunto específico é tão grande, ou as regras de negócios estão sujeitas a tantas mudanças que faz mais sentido para um não programador ter acesso direto à lógica de negócios. Este é o assunto deste tutorial; com isso em mente, vamos discutir os mecanismos de regras em profundidade.

O que é um mecanismo de regras de negócios?

Um mecanismo de regras é uma ferramenta para executar regras de negócios. As regras de negócios são compostas de fatos e declarações condicionais. Qualquer declaração “se-então” que apareça na lógica de negócios tradicional se qualifica como uma regra de negócios.

Por exemplo: se um funcionário estiver doente por mais de 5 dias seguidos e não tiver um atestado médico, ele precisa ser anotado. Se um parceiro de negócios não foi contatado por mais de 6 meses e não fez nenhuma compra durante esse período , talvez seja hora de enviar um e-mail cordial. Se um paciente tiver temperatura corporal alta, problemas de visão e histórico familiar de glaucoma , talvez seja hora de solicitar uma ressonância magnética adicional ou outros testes.

Como as PMEs escrevem regras de negócios?

Em vez de esperar que um SME aprenda Java, C# ou outra linguagem de programação, a TI criará uma minilinguagem para ele expressar suas regras de negócios. Os blocos de construção dessas regras consistirão em fatos que podem ser consultados. Alguns exemplos de fatos por indústria/áreas de atuação são:

• Recursos Humanos: salário, cargo, gerente, anos na empresa
• Médico: temperatura, pressão arterial, medicação atual
• Financeiro: preço atual das ações, preço mais alto/mais baixo de 52 semanas, relação P/L, data da próxima divulgação de resultados

Essencialmente, as informações necessárias para tomar decisões de negócios devem estar disponíveis para a PME de forma simplificada.

Como essas regras se parecem?

Para o restante deste tutorial do mecanismo de regras, usarei o Drools, um mecanismo de regras baseado em Java de código aberto, que pode ser encontrado em www.drolls.org e é um projeto JBoss. No Drools, as regras são escritas como código Java e possuem a seguinte estrutura:

As declarações de importação vão aqui:

 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

Baba e memória de trabalho

Drools emprega um conceito chamado Memória de Trabalho.

O código do aplicativo será responsável por carregar os fatos apropriados na Memória de Trabalho para que as PMEs possam escrever regras que consultem esses fatos. Somente os fatos relevantes para a lógica de negócios do aplicativo devem ser carregados na memória de trabalho, para manter o mecanismo de regras funcionando na velocidade máxima.

Por exemplo, se um aplicativo está determinando se um cliente deve aprovar um empréstimo, os fatos relevantes incluem salário, pontuação de crédito e empréstimos pendentes. Fatos não relevantes incluem dia da semana ou sexo.

Avaliação de regras

Após o Drools Working Memory ser carregado com regras e fatos, as regras são avaliadas de acordo com a parte “então” de sua regra. Se a parte “then” for avaliada como verdadeira, a parte “when” da regra será executada.

Normalmente, todas as regras são avaliadas de uma só vez, embora as regras possam ser agrupadas e avaliadas por grupo. A parte “then” da regra pode alterar o conteúdo da memória de trabalho. Quando isso ocorrer, o Drools reavaliará todas as regras para ver se alguma regra agora é avaliada como verdadeira. Se sim, suas partes “quando” serão executadas.

Essa natureza recursiva das avaliações de regras pode ser uma bênção ou uma maldição – portanto, as regras precisam ser criadas com essa arquitetura em mente.

O lado “se” de uma regra baba

No Drools, os fatos são representados por objetos. A existência ou inexistência de um tipo de objeto pode ser consultada. Além disso, os atributos do objeto também podem ser consultados.

Aqui estão alguns exemplos:

Determine se um funcionário ganha mais de 100.000.

 Employee(salary > 100000)

Determine se um paciente tem nível de colesterol maior que 200 e está tomando Lipitor.

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

Determine se o preço de uma ação está dentro de 1% de sua alta anual.

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

Combinando consultas

Ao escrever lógica de negócios complexa, as regras de negócios podem combinar consultas usando operadores booleanos AND, OR e NOT e aninhando usando parênteses.

Por exemplo:

Determine se há um gerente que ganha menos de $ 75.000 ou um diretor que ganha menos de $ 100.000.

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

Usando vários tipos de objeto

Todos os exemplos até agora foram baseados em um único tipo de objeto, como Employee ou Patient. No entanto, o Drools permite que as consultas sejam baseadas em vários tipos de objetos.

Por exemplo:

Determine se o cliente tem um salário superior a $ 50.000 e não entrou com pedido de falência.

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

O lado “então” de uma regra

O lado “então” de uma regra determina o que acontecerá quando houver pelo menos um resultado na parte “quando” da regra.

No Drools, qualquer coisa que possa ser escrita em Java pode ser escrita na parte “então” da regra. No entanto, para tornar as regras mais reutilizáveis, geralmente é uma boa ideia não colocar nenhuma E/S, código de controle de fluxo ou código de execução geral em uma regra.

Como alternativa, a parte “então” de uma regra pode ser usada para modificar a memória de trabalho. Uma prática comum é inserir um fato na Memória de Trabalho quando uma regra é avaliada como verdadeira.

Por exemplo:

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

Como sabemos quando uma regra foi avaliada como verdadeira?

Depois que todas as regras forem acionadas, o aplicativo precisa saber quais regras foram avaliadas como verdadeiras. Se as regras inserirem objetos na memória de trabalho quando forem avaliadas como verdadeiras, o código poderá ser escrito para consultar a memória de trabalho para esses objetos.

No exemplo acima, após todas as regras terem sido acionadas, uma consulta pode ser feita para ver se um objeto LoanApproval() está na memória de trabalho.

 query "GetLoanApproval " $result: LoanApproval() end

Como um mecanismo de regras de negócios interage com um aplicativo?

Os aplicativos típicos contêm lógica de negócios, GUI, E/S e fluxo de código de controle.

Por exemplo, um aplicativo pode processar uma solicitação de usuário como esta:

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

A incorporação de um mecanismo de regras adiciona algumas etapas a esse processo:

 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

Como as PMEs trabalham com as Regras?

Criando, editando e excluindo regras

Para que as PMEs trabalhem com regras, elas precisarão de uma GUI amigável. Alguns mecanismos de regras de negócios são fornecidos com essa interface.

Por exemplo, Drools vem com duas GUIs que considero amigáveis. O primeiro se assemelha a uma planilha e permite que as PMEs criem regras sem nunca escrever nenhum código real. A segunda GUI permite que uma lógica de negócios mais complexa seja criada.

Embora essas duas GUIs possam ser úteis para inserir condições simples, elas não funcionarão à medida que a lógica de negócios se tornar mais complexa. Nesse caso, você terá que criar sua própria GUI personalizada.

Elementos da GUI personalizada para PME

Para que as PMEs funcionem de forma eficaz, considere a criação de uma GUI personalizada com os seguintes recursos:

• Verificador de sintaxe – um botão de “verificar sintaxe” pode chamar o código Drools para verificar possíveis erros e seus números de linha.
• Arrastar/Soltar – em vez de exigir que um SME se lembre dos Objetos e Atributos disponíveis para eles, considere oferecer a eles uma lista de seleção da qual eles podem arrastar e soltar.
• Interface da Web – uma interface de cliente fino estará disponível para PMEs sem preocupações de distribuição. Isso será útil, pois a GUI precisa de recursos adicionais e manutenção geral.
• Testador de regras – ter a capacidade de testar regras individuais sem fazer interface com todo o aplicativo aumentará muito a produtividade das PMEs. Permita que a SME GUI determine fatos e, em seguida, dispare regras individuais.

Onde as regras devem ser armazenadas?

No Drools normalmente existem duas maneiras de armazenar regras. Drools funciona fora da caixa com regras baseadas em arquivos que normalmente terão uma extensão .drl.

Isso funciona bem quando o número de regras é pequeno. À medida que o número de regras aumenta, você desejará usar um banco de dados. Armazenar e recuperar regras de um banco de dados requer mais trabalho, mas deve fornecer uma arquitetura muito mais gerenciável.

Este tutorial do mecanismo de regras abordou apenas uma parte muito pequena da Linguagem de Regras do Drools. Para obter uma descrição completa, consulte a documentação oficial de referência.

A decisão de usar um mecanismo de regras não deve ser tomada de ânimo leve. Embora um mecanismo de regras torne seu aplicativo mais extensível pelas PMEs, também se tornará mais complicado desenvolver, testar e implantar. Para considerações adicionais sobre este tópico, convém revisar as diretrizes a seguir.

Agora podemos continuar mostrando algo um pouco mais interessante – um exemplo simples da vida real do Drools em ação, em um caso de uso que a maioria dos leitores do blog Toptal deve achar familiar.

Usando Drools em um cenário da vida real

A Toptal, uma fornecedora líder de talentos de desenvolvimento de software de alto nível, atualmente usa o software de rastreamento de candidatos para levar os candidatos a empregos em vários estágios do processo de contratação. Aqui está um fluxograma visual simplificado deste processo:

Atualmente, a lógica de negócios para decidir se um candidato continuará no processo de contratação foi codificada no software. Toda vez que os Recursos Humanos precisam mudar a lógica do negócio, eles devem ter a TI envolvida. Eles gostariam de ter a capacidade de alterar diretamente a maneira como seu software é executado.

O software de Rastreamento de Candidatos será modificado para executar as regras fornecidas pelo RH em cada ponto de decisão no processo de contratação. O RH terá um objeto 'Candidato' que representará um candidato a emprego cujo status acabou de ser modificado por uma entrada inicial, conclusão de exame on-line ou vários fatores diferentes. O objeto Candidato terá campos para representar experiência, notas de testes, notas de entrevistas, etc.

O exemplo a seguir apresenta um conjunto simplificado de regras para sua consideração. Ele não foi implantado, é apenas um exemplo simples que consiste em quatro regras interconectadas:

• Enviado -> Testando
• Teste -> Entrevista
• Entrevista -> Projeto
• Projeto -> Contratação

Enviado -> Testando

Com base nas necessidades atuais do cliente, o RH gostaria de escrever uma regra que determine se um candidato deve ser agendado para testes online.

 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

Teste -> Entrevista

Após o candidato ter feito o exame online, sua pontuação precisa ser avaliada. O RH também gostaria de ter controle sobre essa regra. O exame on-line testa a capacidade do candidato de entender a teoria do desenvolvimento de software, a resolução de problemas e a sintaxe. O RH gostaria de decidir qual combinação de pontuações permitirá que um candidato seja considerado para uma entrevista técnica.

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

Entrevista -> Projeto

Uma entrevista técnica testará a capacidade do candidato de falar sobre sua experiência, responder a perguntas sobre solução de problemas e testará sua capacidade de se comunicar em geral. O RH escreverá a regra que determina uma pontuação de aprovação para a entrevista técnica.

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

Projeto -> Contratação

Se um candidato for aprovado na entrevista técnica, receberá um projeto de programação off-line. Eles enviarão o projeto e serão julgados quanto à completude, arquitetura e GUI.

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

Como você pode ver, mesmo este exemplo básico oferece várias possibilidades para o RH e pode agilizar as operações. O fato de o RH poder alterar as regras sem ter que envolver a TI no processo inevitavelmente economizaria tempo e aceleraria o processo de triagem.

Como as regras podem ser alteradas em tempo real, o departamento de RH também teria muito mais flexibilidade. Por exemplo, o RH pode expandir ou restringir o processo de seleção definindo parâmetros diferentes.

Se houver muitos candidatos que marcam todas as caixas certas, a barra pode ser aumentada em minutos, reduzindo assim o número de candidatos. Alternativamente, se o processo gerar poucos ou nenhum candidato que atenda a todos os requisitos, o RH pode optar por reduzir ou descartar alguns dos padrões, mudando seu foco para habilidades mais relevantes até que um número adequado de candidatos atenda ao requisito.