Onde eu armazeno regras de negócios definidas pelo usuário?

5

Digamos que eu tenha um aplicativo que funcione em departamentos e funcionários. Cada departamento tem um conjunto de regras que define qual funcionário é atribuído a cada departamento. Por exemplo, o sistema atribuirá automaticamente o empregado a um departamento específico com base em algumas propriedades, como o número de anos de experiência ou idiomas falados. A parte complicada é que essas regras não são predefinidas, o que significa que eu quero que o usuário do aplicativo seja capaz de criar, excluir e modificar essas regras, o que significa que não posso colocá-las no código-fonte.

Como posso fazer isso?

    
por Manuel Sopena Ballesteros 18.06.2018 / 11:15
fonte

5 respostas

4

Tenho certeza que você já viu e talvez usou essa funcionalidade: cada cliente de e-mail decente permite que um usuário defina regras de filtragem personalizadas escolhendo alguns modelos de regras, adicionando algumas condições e parâmetros e fazendo as regras serem executadas automaticamente sempre que novo email chega. Portanto, esta é realmente uma forma possível (de muitos ) como implementar tal sistema.

Então, sim, não há nada de especial em ter um sistema com regras e lógica personalizadas. No entanto, há uma grande variedade de opções e graus de liberdade, a partir de algumas regras simples e parametrizadas, a partir das quais um usuário pode escolher até um intérprete embutido, com uma linguagem de programação padrão ou de domínio específica para implementar regras. talvez com base em algum mecanismo genérico de regras.

Os graus de liberdade normalmente se correlacionam com o esforço de desenvolvimento, bem como com a inclinação da curva de aprendizado para os usuários. Portanto, não há uma solução única para isso, você precisa analisar a quantidade de flexibilidade que seus usuários precisam, e "mais flexível" não é necessariamente melhor, porque muitas vezes significa "mais difícil de aprender". Se seus usuários querem alguma flexibilidade para a lógica de negócios, descubra quanta flexibilidade eles realmente precisam e quanto esforço eles estão dispostos a investir em aprender como definir regras e lógica complexas por si mesmos.

    
por 18.06.2018 / 13:19
fonte
3

Haverá inevitavelmente um compromisso com isso. Se você deseja oferecer ao usuário flexibilidade ilimitada para definir regras complexas em tempo real, então o que você efetivamente terá que fazer é criar uma linguagem de programação específica de domínio dentro de seu aplicativo, o que exigirá que você escreva algo que possa então analise isso. Este não é um trabalho pequeno.

No entanto, pode ser que esse grau de controle seja excessivo. Seus usuários podem se contentar com a capacidade de:

  1. Definir atributos (por exemplo, HAS_5_YEARS_EXPERIENCE ou SPEAKS_SPANISH ou IS_CONVICTED_FELON)
  2. Atribuir qualquer número desses atributos a cada funcionário
  3. Especifique regras personalizadas para cada departamento (por exemplo, REQUIRES: SPEAKS_SPANISH ou FORBIDDEN: IS_CONVICTED_FELON)

Esta é uma tarefa muito mais simples.

    
por 18.06.2018 / 11:26
fonte
1

Eu usaria um mecanismo de regras como o Drools (Java). Mecanismos de regras basicamente servem a dois propósitos. Um: eles executam as regras que eles armazenaram (isto é, determinando a quais departamentos um funcionário pertence). Tqo: eles fornecem uma maneira de modificar as regras em tempo de execução. Os mecanismos de regras são dinâmicos por definição. Isso parece se encaixar perfeitamente no seu cenário!

    
por 18.06.2018 / 15:59
fonte
0

Você pode armazenar suas regras em OWL + RDF , um padrão semântico de linguagem da Web do W3C. OWL pode representar a lógica de descrição (veja esta apresentação de Ian Horrocks , e "Uma semântica web primer "por Grigoris Antoniou, Paul Groth, Frank van Harmelen e Rinke Hoekstra . Ele permite que você defina uma ontologia sobre funcionários, departamentos e qualificações de trabalho. E raciocinar dentro dessa ontologia. Por exemplo, permite para definir propriedades e o significado dessas propriedades, para definir os requisitos de vários departamentos, armazene as qualificações dos funcionários.

Com algum conhecimento de representação de conhecimento, você pode alterar e adicionar propriedades, alterar regras para departamentos, etc.

Em seguida, você pode usar os raciocinadores OWL existentes (como Apache Jena , OpenLink Virtuoso , Loja AllegroGraph RDF e Pelotas )

Usando o reasoner, a ontologia definida e o banco de dados de funcionários e departamentos, é possível encontrar a classe de funcionários que satisfazem todas as propriedades necessárias para trabalhar no departamento x.

Dentro da família de ferramentas da web semântica, existem os raciocinadores OWL, armazenamentos de tripé RDF (OWL é frequentemente armazenado como RDF) e editores da base de conhecimento.

    
por 18.06.2018 / 15:55
fonte
0

Usar um mecanismo de regras como o Drools já foi mencionado.

Deixar uma grande parte da configuração para os usuários finais tem uma desvantagem típica em comparação com a manutenção de programação:

  • As alterações têm um efeito imediato no sistema de produção em execução;
  • O controle de versão está ausente;
  • O design é ad-hoc;
  • A documentação está ausente;
  • Um usuário final não está acostumado com a "lógica" de um sistema de software.

Portanto, é necessário um desenvolvimento suficiente e extra cuidadoso.

Faça um design detalhado, com histórias detalhadas: interfaces de usuário finais.

Somente depois de ter requisitos técnicos, uma concepção técnica, procure a (s) ferramenta (s) correta (s). Assim, os tempos de desenvolvimento são distribuídos proporcionalmente às partes da carga de trabalho.

Um aviso: não armazene dados complexos (centenas de nós de gráfico) em várias tabelas de banco de dados, quando esses dados são como um documento; melhor armazenar dados como XML em uma única tabela (JAXB). É melhor se alguém pode passar de gráfico para gráfico, em vez de ter todos distribuídos - mesmo com JPA.

Outra observação: esse tipo de software deve normalmente auxiliar no planejamento, não necessariamente ser prescritivo. O cliente muitas vezes só quer otimizar, fazer as coisas com rapidez e imparcialidade. Isso significa que as exceções manuais provavelmente devem ser tratadas e documentadas.

    
por 19.06.2018 / 16:57
fonte

Tags