Uma das coisas mais incríveis sobre trabalhando em desenvolvimento de software é a capacidade de trabalhar em muitos setores diferentes - especialmente se você for um consultor. A maioria das habilidades de desenvolvimento de software que você aprende enquanto trabalha em um setor pode ser transferida diretamente para qualquer outro setor, empresa, projeto e nichos.

Estou falando sobre 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 (PME). Normalmente, uma PME estará muito envolvida na fase de concepção do projeto.

O SME tem trabalhado no setor por um longo período de 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 projeto ter sucesso.

Para muitos projetos, a menos que o desenvolvedor de software tenha um grande entendimento 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 irá variar amplamente com base na complexidade do projeto.

como extrair dados do twitter

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

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

Dependendo da indústria e do projeto, pode não ser possível para uma PME entregar a transferência completa de conhecimento.

Por exemplo, imagine se o SME fosse um médico com 25 anos de experiência e você tivesse 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 uma programação definida com base no tempo ou 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 o software com a freqüê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 de resistir às mudanças contribuirá muito para garantir seu sucesso final a longo prazo.

Quando e onde os motores de regras fazem sentido?

Para muitos projetos de software, é possí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: E se um funcionário está doente por mais de 5 dias consecutivos e não tem um atestado médico, então eles precisam ser escritos. E se um parceiro de negócios não foi contatado por mais de 6 meses e eles não fizeram compras durante esse tempo, então pode ser hora de enviar um e-mail cordial. E se um paciente tem temperatura corporal elevada, problemas de visão e há uma história familiar de glaucoma, então pode ser hora de solicitar uma ressonância magnética adicional ou outros exames.

Como as PMEs escrevem regras de negócios?

Em vez de esperar que um SME aprender Java , C # ou outra linguagem de programação, a TI criará uma minilinguagem para que ele expresse 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 setor / áreas de prática são:

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

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

Como são essas regras?

Para o restante deste tutorial do mecanismo de regras, estarei usando o Drools, um mecanismo de regras baseado em Java de código aberto, que pode ser encontrado em www.drools.org e é um projeto JBoss. No Drools, as regras são escritas como código Java e têm 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

Drools e Memória de Trabalho

O Drools emprega um conceito chamado Memória de Trabalho.

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

Por exemplo, se um aplicativo está determinando se deve aprovar um cliente para um empréstimo, os fatos relevantes incluiriam 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

Depois que a memória de trabalho do Drools foi carregada 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 vez, embora as regras possam ser agrupadas e avaliadas por grupo. A parte “então” 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 delas é avaliada como verdadeira. Nesse caso, 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 de Drools

No Drools, os fatos são representados por objetos. A existência ou não existê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 superior a 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 máxima anual.

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

Combinando consultas

Ao escrever lógicas de negócios complexas, 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 ganhando menos de $ 75.000 ou um diretor ganhando 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 Funcionário ou Paciente. 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 “then” 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 dentro de 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 foram disparadas, 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, depois que todas as regras foram disparadas, 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 do usuário assim:

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 regras?

Criação, edição e exclusão de regras

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

Por exemplo, o Drools vem com duas GUIs que considero fáceis de usar. O primeiro se assemelha a uma planilha e permite que os 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 ambas as GUIs possam ser úteis para inserir condições simples, elas não funcionarão conforme a lógica de negócios se torna mais complexa. Nesse caso, você terá que criar sua própria GUI personalizada.

Elementos do SME Custom GUI

Para que as PMEs trabalhem com eficácia, considere a criação de uma GUI personalizada com os seguintes recursos:

• Verificador de sintaxe - um botão de “verificação de 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 lembre-se dos Objetos e Atributos disponíveis, considere oferecer a eles uma lista de seleção da qual podem arrastar e soltar.
• Interface da Web - uma interface de cliente fino estará disponível para PMEs sem problemas 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 o aplicativo inteiro aumentará muito a produtividade do SME. Permita que o SME GUI determine os fatos e, em seguida, dispare regras individuais.

Onde as regras devem ser armazenadas?

No Drools, normalmente existem duas maneiras de armazenar regras. O Drools funciona imediatamente com regras baseadas em arquivos que geralmente têm uma extensão .drl.

Isso funciona bem quando o número de regras é pequeno. Conforme 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.

o que são diretivas em angularjs

Este tutorial do mecanismo de regras abordou apenas uma pequena parte da linguagem de regras do Drools. Para uma descrição completa, consulte no documentação de referência oficial .

A decisão de usar um mecanismo de regras não deve ser tomada levianamente. Embora um mecanismo de regras torne seu aplicativo mais extensível por PMEs, ele também se tornará mais complicado de desenvolver, testar e implantar. Para obter considerações adicionais sobre este tópico, você pode querer reveja as seguintes diretrizes .

Agora podemos prosseguir para mostrar a você 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 de blog do ApeeScape deve achar familiar.

Usando Drools em um cenário da vida real

A ApeeScape, fornecedora líder de talentos de alto nível em desenvolvimento de software, atualmente usa o software de rastreamento de candidatos para conduzir os candidatos a empregos por 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. Sempre que os Recursos Humanos precisam mudar a lógica de negócios, eles devem ter a TI envolvida. Eles gostariam de poder alterar diretamente a forma como o 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 online ou uma série de fatores diferentes. O objeto Candidato terá campos para representar experiência, pontuação de teste, pontuação de entrevista, etc.

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

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

Enviado -> Teste

Com base nas necessidades atuais do cliente, o RH gostaria de escrever uma regra que determinará se um candidato deve ser agendado para teste 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 gostaria de ter controle sobre essa regra também. O exame online testa a capacidade do candidato de compreender a teoria do desenvolvimento de software, a resolução de problemas e a sintaxe. O RH gostaria de decidir que 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 de um candidato de falar sobre sua experiência, responder a perguntas de resolução de problemas e testará sua capacidade de comunicação em geral. O RH escreverá a regra que determina a 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, ele receberá um projeto de programação off-line. Eles enviarão o projeto e ele será avaliado quanto à integridade, 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 uma série de 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 seleção.

Como as regras podem ser alteradas imediatamente, 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 marcando todas as caixas corretas, a barreira pode ser aumentada em minutos, reduzindo assim o número de candidatos. Alternativamente, se o processo produzir 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.