Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento Marco Antonio De Grandi, Valter Vieira de Camargo, Edmundo Sérgio Spoto Centro Universitário Eurípides de Marília (Univem) Caixa Postal 2041 17.525-901 Marília SP Brazil marcodgrandi@gmail.com, {valter, dino}@univem.edu.br Resumo. Neste artigo é mostrada uma abordagem para apoiar a identificação e classificação de regras de negócio. As diretrizes mostradas fornecem apoio para que os próximos passos do desenvolvimento possam tratar as regras de negócio de forma separada do núcleo do software. Palavras-Chave: Regras de Negócio. 1 Introdução Regras de negócio (RNs) são declarações cujo objetivo é influenciar, ou guiar, o comportamento de um negócio [8]. Elas têm por objetivo definir as características do negócio que norteiam a execução dos requisitos funcionais de um software. Pesquisadores argumentam que a sensibilidade das RNs às mudanças de requisitos faz com que elas devam ser tratadas de forma mais adequada e sistemática durante o desenvolvimento de um sistema [1,8,9]. Uma maneira de prover esse tratamento é fornecer mecanismos para que as RNs sejam identificadas, classificadas, registradas e implementadas separadamente do núcleo do software, facilitando a manutenção, a modularização e conseqüentemente fornecendo melhores níveis de reúso. O objetivo principal desse artigo é fornecer diretrizes para a identificação e classificação das RNs, fornecendo apoio para que as próximas etapas do desenvolvimento possam tratá-las de forma separada do núcleo do software, facilitando sua manipulação e resultando em sistemas mais manuteníveis e reusáveis. Para isso são definidos critérios para a identificação e classificação das RNs, fornecendo assim a base inicial para que os próximos passos do desenvolvimento possam tratar as regras de negócio de forma separada do núcleo do software. O artigo está organizado da seguinte forma: Na Seção 2 são apresentados os conceitos relevantes às RNs. Na Seção 3 é apresentada a abordagem. Na seção 4 encontram-se os trabalhos relacionados a esse, e na Seção 5 as considerações finais. 2 Regras de Negócio As RNs podem ser classificadas em diversas formas [2,6,8,9]. Nesse trabalho é utilizada a classificação proposta por [9], por ser uma síntese de outros tipos de
classificação e possuir foco nos tipos de RNs que normalmente são utilizados em sistemas de informação. Nesse esquema, as RNs são separadas em três grupos (Informações Restritivas, Habilitadoras e Derivações) que originam os cinco tipos de RNs: Restrições, Diretrizes, Habilitadoras de Ações, Derivação por Computação e por Inferência. A implementação das RNs em um sistema de informação deve respeitar alguns princípios básicos [8,9] que visam viabilizar a manutenção das RNs, devido à sua natureza volátil. Esses princípios são: 1. Separação (Separate): As RNs devem ser implementadas de forma separada dos requisitos e do próprio sistema. Esse princípio busca incentivar o reúso das regras e possibilitar que elas possam ser alteradas independentemente de outras características do sistema; 2. Rastreamento (Trace): As RNs devem possuir uma rastreabilidade que permita identificar os artefatos de software utilizados para sua implementação, com isso, o impacto sobre a alteração de uma regra pode ser mensurado; 3. Externalização (Externalize): Toda a regra deve ser expressa num formato compreensível para que seja possível a realização de auditorias de negócio, por pessoas não-técnicas; 4. Posicionamento (Position): As RNs devem estar preparadas para mudanças, uma vez que por meio das regras pode-se mudar o curso regular do negócio. Para o cumprimento desses princípios, é necessário que o desenvolvimento das RNs possa ser acompanhado durante as fases iniciais do ciclo de vida de um sistema. Esse acompanhamento pode ser feito mediante mecanismos que permitam identificar, classificar, modelar e mapear as regras de uma fase para a outra do desenvolvimento. 3 A Abordagem Proposta A abordagem proposta neste artigo envolve duas etapas: a elaboração de casos de uso com gabarito e a identificação/classificação das RNs. Na Figura 1 são mostradas algumas etapas genéricas do desenvolvimento clássico de um sistema e também os pontos que sofrem influência da abordagem proposta neste artigo, sendo que, os quadros pontilhados representam os novos artefatos utilizados, e o quadro adicionado na fase de Análise representa uma nova atividade, necessária à proposta desse trabalho e que é discutida nas próximas subseções. Gabarito para registro dos casos de uso Relação de RNs Documentos de Requisitos Elicitação/ Coleta de Requisitos Identificação e Classificação das RN Análise Projeto Implementação Implantação Figura 1. Adaptação do ciclo de vida de desenvolvimento de software à proposta.
3.1 Elaboração de Casos de Uso com Gabarito A identificação de RNs durante o levantamento de requisitos deve ser auxiliada por meio do uso de um gabarito (template) para a documentação e registro dos casos de uso. O gabarito utilizado nesse trabalho (Figura 2) é uma adaptação do gabarito proposto por [4]. A extensão foi feita para apoiar de forma mais adequada a identificação das RNs. Isso ocorre por meio do registro de informações específicas, oriundas do documento de requisitos que posteriormente irão se tornar RNs. Caso de Uso: Descrição: Premissas: Passos: 1: 2: Variações: Não Funcional: Questões: Pré-Condições: Condição Pós-Condições: Condição Gatilhos: Tipo de Gatilho Diretriz Habilitador Derivação Gatilho Relacionamentos: Caso de Uso Tipo de Relação Função da Relação Condição Habilitador Derivação Informações aos Atores: Condição Informação Figura 2. Gabarito para Documentação de Caso de Uso Para o preenchimento das novas seções do gabarito proposto, deve-se utilizar informações obtidas no documento de requisitos do sistema com o apoio de diretrizes que devem ser aplicadas aos documentos de requisitos. São elas: 1. Pré-Condições: Indicam as condições, tais como restrições de negócio, que devem ser satisfeitas na ocorrência do caso de uso; 2. Pós-Condições: Indicam condições de negócio que devem ser satisfeitas para que o caso de uso seja concluído; 3. Gatilhos: São procedimentos que devem ser disparados, independente do cluxo de execução do caso de uso, após a execução, com sucesso, de um caso de uso, sempre que a condição estabelecida for satisfeita; 4. Relacionamentos: São todos os relacionamentos que o caso de uso possua com os demais, desde que exerçam uma função de negócio. O tipo de relação pode ser: Associação, Extensão ou Inclusão. A função da relação pode ser derivação ou habilitadora de ações; 5. Informações aos Atores: São informações fornecidas aos atores relacionados ao caso de uso, podendo ocorrer em qualquer ponto de um caso de uso. Essas diretrizes devem ser aplicadas com o objetivo de identificar os comportamentos de negócio presentes nos requisitos. Portanto deve-se atentar para que essas informações sejam políticas da companhia, padrões de indústria, leis e regulamentações governamentais, ou ter outro tipo de origem que esteja vinculado ao comportamento que o software deve ter para refletir um comportamento específico da
companhia. As demais pré e pós-condições, gatilhos, relacionamentos e informações aos atores, devem ser implementadas no software da forma convencional, sem necessariamente serem tratadas como RNs, e sem, portanto, estarem informadas nas novas seções do gabarito proposto. Portanto, antes da inserção das informações em cada uma das novas seções do gabarito é necessário fazer uma crítica no intuito de certificar que realmente trata-se de uma informação que reflete um comportamento de negócio. 3.2 Identificação e Classificação de Regras de Negócio Uma vez que os casos de uso estejam documentados com o gabarito proposto, é possível a identificação das RNs mediante aplicação de alguns critérios. Na Tabela 1 são apresentados os critérios de identificação e subseqüente classificação das RNs. Esses critérios que foram elaborados com o objetivo de extrair as RNs dos casos de uso e classificá-las, tomando como base sua localização nas seções do gabarito mostrado na Figura 2. Tabela 1. Critérios para Identificação e Classificação das Regras de Negócio Tipo de RN Restrições Diretrizes Habilitadoras de Ações Derivação Critério de Identificação -Itens informados na seção Pré-Condições ou Pós-Condições. -Itens informados na seção Informações aos Atores. -Itens informados na seção Gatilhos, que sejam do tipo Diretrizes. -Itens informados na seção Gatilhos e que tenha a função Habilitador. -Itens informados na seção Associações e que a função Habilitador. -Itens informados na seção Gatilhos e que tenham a função Derivação. -Itens informados na seção Associações e que tenham a função Derivação. Com a aplicação desses critérios em todos os casos de uso, obtêm-se o conjunto total de RNs existentes no sistema. Em seguida sugere-se a elaboração de um artefato para registrar as regras que foram identificadas no passo anterior. Esse artefato é mostrado na Tabela 2. Na primeira coluna desse artefato deve ser informado a RN em si, em seguida seu tipo, e o caso de uso que deu origem a ela. Na quarta coluna deve ser informada a seção do caso de uso que gerou a regra e na quinta a identificação da RN. Note-se que esse registro propicia um mapeamento entre as RNs e cada caso de uso que deram origem a elas, auxiliando na rastreabilidade dessas RNs nessas fases iniciais do desenvolvimento. Tabela 2. Relação de Regras de Negócio (por caso de uso) Regra Tipo Caso de Uso Seção Id. RN Restrição Realizar Pré-Condição 1 Duração Reserva Reserva No preenchimento da data de chegada e da data de saída, o número de dias da reserva não deve exceder a 7 Caso o hóspede possua faturas vencidas e não pagas o sistema deverá gerar uma advertência por débitos, na efetivação da reserva. Diretriz Realizar Reserva Gatilho 1 Inadimplência Sugere-se também que as RNs identificadas sejam representadas graficamente como casos de uso. Dessa forma, pode-se ter uma visão mais ampla do sistema e dos
relacionamentos que essas RNs mantêm com os demais casos de uso funcionais. Para que os casos de uso referentes às RNs sejam diferenciados dos demais, sugere-se também a utilização do estereótipo <<business rule>> e a criação de visões individuais para as RNs, com o intuito de não poluir o diagrama de casos de uso. Os casos de uso que representam RNs devem ser relacionados aos seus casos de uso base por meio de relacionamentos do tipo Extensão (Extend), uma vez que geralmente as RNs dependem de uma condição para serem acionadas, ou seja, elas representam um comportamento adicional ao caso de uso base. Um exemplo da modelagem de RNs no diagrama de casos de uso é mostrado na Figura 3, no qual o caso de uso base RealizarReserva possui duas RNs nomeadas Inadimplência e DuraçãoReserva. Essa modelagem deve representar a influência de RNs sobre o comportamento de um caso de uso. Pode-se observar que essas RNs foram obtidas a partir do artefato Relação de Regras de Negócio mostrado na Tabela2 e modeladas de acordo com as diretrizes apresentadas anteriormente. Figura 3. Exemplo da modelagem de RNs no diagrama de casos de uso. 4 Trabalhos Relacionados Nos últimos anos a utilização das RNs na engenharia de software gerou diversas linhas distintas de pesquisa, entre elas estão as pesquisas que focam a captura e representação sistemática das RNs bem como sua posterior tradução para códigos de linguagens de programação [7], as que visam a implementação das RNs com a tecnologia Adaptive Object Models [10], as que focam a implementação das RNs por meio de tecnologias específicas, como por exemplo, as linguagens baseadas em regras [8,9]. Existem ainda as pesquisas que sugerem a implementação das RNs com POA [3,5], contudo, focando apenas a implementação do software sem abordar as fases de projeto. E por fim as pesquisas que focam o rastreamento das RNs nos artefatos do software no ambiente OO, como em [1,11]. 5 Considerações Finais e Trabalhos Futuros Nesse trabalho foi apresentada uma abordagem para apoiar a identificação e a classificação das RNs no início do desenvolvimento. Essa abordagem é composta um modelo de gabarito para a documentação dos casos de uso, e pelas diretrizes para a
identificação e classificação das RNs, fornecendo apoio para que as próximas etapas do desenvolvimento possam tratá-las de forma separada do núcleo do software. Com a aplicação da abordagem foi observado que as RNs podem ser tratadas de forma separada e independente do núcleo do software. Esse resultado é o inicio de um processo cujo objetivo é apoiar o desenvolvimento das RNs ao longo das fases de projeto do sistema, obtendo-se assim a implementação das RNs de forma separada do núcleo do software, o que resulta em sistemas mais legíveis e manuteníveis Acredita-se que a contribuição principal desse artigo seja a proposta de identificação e classificação das RNs. Fornecendo assim, uma diretriz para o tratamento de RNs nas atividades de análise e projeto, permitindo sua modelagem de forma desvinculada e independente. Como contribuição secundária está a obtenção de uma rastreabilidade entre as RNs identificadas e o caso de uso no qual elas foram identificadas. Referências 1. Bajec, M.; Krisper, M.: A methodology and tool support for managing business rules in organizations, In: Information Systems (2004) 2. Business Rules Group: Defining Business Rules: What Are They Really? Disponível em: http://www.businessrulesgroup.org 3. Camargo, V. V.; Masiero, P. C.: Frameworks Orientados a Aspectos, In XIX Simpósio Brasileiro de Engenharia de Software, Uberlândia, Brasil (2005) 4. Coleman, D.: A Use Case Template: draft for discussion, Disponível em: http:// citeseer.ist.psu.edu/476167.html 5. Cibrán, M. A.; Suvée, D.; D Hondt, M.; Vanderperren, W.; Jonckers, V.: Integrating Rules with Object-Oriented Software Applications using Aspect- Oriented Programming. In: Proceedings of the International Conference of the Argentine Society for Computer Science and Operational Research, Córdoba, Argentina (2004) 6. Date, C. J.: What Not How The Business Rules Approach to Application Development. Boston: Addison-Wesley (2000), 7. Morgado, G. P.: Regula Uma Ferramenta para o Gerenciamento de Regras de Negócio. Monografia (Projeto Final de Curso), Universidade Federal do Rio de Janeiro Departamento de Ciência da Computação, Rio de Janeiro, Brasil (2005) 8. Ross, R. G.: Principles of the Business Rule Approach. Boston: Addison-Wesley (2003) 9. Von Halle, B.: Business rules applied: building better systems using the business rules approach. New York: John Wiley & Sons, Inc (2002) 10. Yoder, J.; Balaguer, Federico; Johnson, Ralph: Adaptive Object-Models for Implementing Business Rules. In: Third Workshop on Best-Practices for Business Rules: Design and Implementation OOPSLA 2001, Tampa Bay (2001) 11. Wan-Kadir, W.M.N.; Loucopolos, P.: Relating evolving business rules to software design. In: Journal of Systems Architecture (2004)