Após a apresentação do modelo geral da estrutura do nosso sistema, pretende-se agora re nar o modelo previamente apresentado através da decomposição do sistema em componentes (elementos estruturais).
Para cada um dos componentes pretende-se apurar as suas responsabilidades, e identi car as inter-ligações existentes entre os diferentes componentes que compõem o sistema.
Apresentam-se de seguida a listagem desses componentes:
• Knowledge Repository (ou Repositório de Regras) componente respon- sável por armazenar de forma centralizada todas as regras RV que se pretendem validar sobre a nossa aplicação altamente con gurável.
• Facts Repository (ou Repositório de Factos) componente responsável por armazenar os dados provenientes da aplicação alvo de validação e que são necessários para executar a validação das regras existentes no Repositório de Regras.
• Integrator (ou Integrador) este componente, depois de correctamente con- gurado, é responsável por:
aceder à aplicação alvo de modo a obter dados de con guração da mesma; converter os dados provenientes da aplicação para o modelo utilizado para
a representação dos factos no Repositório de Factos; gerar o Modelo de Factos.
Na Figura 7.5 podemos observar as interacções deste componente.
• Rules Manager (ou Gestor de Regras) componente responsável por toda a gestão das regras RV, mais especi camente no que diz respeito:
à introdução/edição das regras para o Repositório de Regras a partir de um cheiro ou editor grá co especí co para o efeito;
ao controlo de acessos ao Repositório de Regras, necessário para pos- terior validação;
Figura 7.5: Componente: Integrator
Figura 7.6: Componente: Gestor de Regras.
Na Figura 7.6 podemos observar as interacções deste componente.
• Rules Engine (ou Motor de Regras) componente responsável por de- cidir o que fazer para validar uma determinada regra RV do Repositório de Regras. Da lista de responsabilidades deste componente fazem parte:
obter as regras RV a validar do Repositório de Regras, por intermédio do Gestor de Regras;
obter os factos necessários, para validar determinada regra, do Repositório de Factos;
receber ordem de execução do processo de validação dos factos contra as regras existentes;
inferir o resultado da validação de cada uma das regras RV do Repositório de Regras.
Na Figura 7.7 podemos observar as interacções deste componente.
• Rules Processor (ou Processador de Regras) componente responsável por desencadear o processo de validação da aplicação altamente con gurável, bem como de expor os resultados dessa validação para o utilizador. Para além disso é responsável por determinar como deve a validação ocorrer (e.g.: se devem ser validadas todas as regras do repositório, ou não.).
7.3. Visão de Arquitectura
Figura 7.7: Componente: Motor de Regras.
Figura 7.8: Componente: Processador de Regras.
Feito isto apresentamos em seguida na Figura 7.9 um diagrama de arquitectura conceptual com todas as interacções entre os componentes previamente introduzidos.
Capítulo 8
Desenvolvimento do Sistema de
Validação
A scientist builds in order to learn; an engineer learns in order to build. Fred Brooks
Após o desenho da arquitectura do sistema validador, interessa-nos demonstrar a viabilidade da estratégia de validação de nida, bem como da arquitectura já ap- resentada, através da especi cação e implementação de uma Prova de Conceito (POC)[Dic11] utilizando Java [Ora11] como linguagem principal.
Para a realização da prova de conceito tem-se uma abordagem partida pelos diferentes componentes a desenvolver, identi cados no modelo arquitectural. É im- portante, para cada componente: especi car o funcionamento do negócio; identi car ferramentas e linguagens a utilizar; anotar decisões técnicas na utilização das ferra- mentas; e mostrar detalhes sobre a concretização da sua implementação.
Como ponto chave para o desenvolvimento do sistema validador, optou-se pela utilização de uma ferramenta já referenciada no capítulo 5.1 como sendo um sistema de gestão de regras de negócio (BRMS) o Drools.
Figura 8.1: O Drools no Sistema de Validação.
Como se pode ver na Figura 8.1 o Drools surge como uma peça core da solução proposta, não só fornecendo um conjunto de ferramentas muito úteis ao desenvolvi- mento do sistema pretendido, mas também por servir como agregador dos diversos
componentes.
Ao longo do capítulo, serão fornecidos os detalhes necessários para adaptar e in- corporar o Drools na solução, porém, para uma visão mais ampla das potencialidades desta ferramenta poderá consultar-se o Apêndice D.
Nas secções seguintes apresenta-se o modo pela qual o desenvolvimento de cada um dos componentes da arquitectura será endereçado. Desde o Repositório de Factos (secção 8.1) e de Regras (secção 8.2), passando pelo Integrador (secção 8.3) e pelo Gestor de Regras (secção 8.4) e nalizando com o Motor e Processor de Regras (secção 8.5).
8.1 Repositório de Factos
Na concepção do Repositório de Factos (Facts Repository), as questões que ime- diatamente se colocam são:
• que estrutura deverá ser usada para persistir os factos? • como será populada a estrutura de dados do repositório? • que tipo de informações irão os factos conter?
A ideia passa por encontrar o modelo/estrutura para suportar a representação, de forma inequívoca, das informações provenientes das aplicações altamente con g- uráveis Modelo de Factos. Sendo que o modo como estas informações serão explicitadas deverá ser genérico o su ciente para que sejam independentes do negócio da aplicação alvo de validação.
Para além disso, as RV (cuja concepção será abordada mais tarde na secção 8.2) deverão ser de nidas tendo em consideração este modelo, para facilitar posterior acesso a esta mesma informação.
Ora, acontece que o Drools1 (em especí co o Drools Runtime) possui uma inter-
face org.drools.runtime.StatefulKnowledgeSession na sua Application Programming Interface (API), que permite estabelecer o diálogo com o seu motor de regras, mantendo o estado dessa sessão. Sendo essa mesma sessão que irá manter os nossos factos em memória.
Os mesmos factos que serão posteriormentes validados, são escritos usando Java, em que cada facto é uma instância da classe java.lang.Object, a qual representa o topo da hierarquia de classes desta linguagem (todas as classes são do tipo Object).
8.2. Repositório de Regras