Uma Abordagem para Acompanhamento de Regras de Negócio Transversais ao Longo do Desenvolvimento

Transcrição

1 Uma Abordagem para Acompanhamento de Regras de Negócio Transversais ao Longo 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 Marília SP Brazil {valter, Abstract. This paper presents an approach to support the development of business rules using aspects during the initial phases of software development. The approach supplies guidelines to identify, classify and model the business rules by maintaining a record of the mapping between each phase and providing a good level of traceability. A hotel reservation system is used to exemplify its application. Resumo. Este artigo apresenta uma abordagem para apoiar o desenvolvimento de regras de negócio com aspectos durante as fases iniciais do desenvolvimento. A abordagem fornece diretrizes para identificar, classificar e modelar as regras de negócio mantendo um registro dos mapeamentos entre essas fases e propiciando um bom nível de rastreamento. A abordagem é demonstrada com um sistema de reserva de uma rede de hotéis. 1. Introdução Regras de negócio (RNs) são diretivas cujo objetivo é influenciar, ou guiar, o comportamento de um negócio [Ross, 2003]. Elas têm por objetivo definir as características do negócio que norteiam a execução dos requisitos funcionais que compõem um software, e elas podem estar presentes nesse software de diversas maneiras; podem estar implícitas em seu código, nas estruturas de dados, ou como gatilhos (triggers) e procedimentos (stored procedures) do banco de dados. Pesquisadores argumentam que a sensibilidade das RNs às mudanças de requisitos faz com que elas devam ser tratadas de forma sistemática durante todo o desenvolvimento de um sistema [Korthaus, 1998; Ross, 2003; Von Halle, 2002]. Uma maneira de prover esse tratamento é fornecer mecanismos para que as RNs sejam identificadas, classificadas e implementadas separadamente do núcleo do software, facilitando a manutenção, a modularização e fornecendo melhores níveis de reúso. Na terminologia da Programação Orientada a Aspectos (POA) os interesses base são aqueles relacionados com a funcionalidade principal do sistema e os interesses transversais (crosscutting concerns) são aqueles cuja implementação com técnicas tradicionais causam problemas de entrelaçamento (tangling) e espalhamento (scattering) de código. A POA tem sido apontada por alguns autores como uma alternativa interessante para a implementação das RNs de forma desvinculada do núcleo do software, possibilitando sua integração de forma não invasiva ao código por meio dos novos mecanismos de composição fornecidos por esse paradigma [Cibrán et al., 2004]. Entretanto, não foram encontrados trabalhos que mostrem como as RNs são manipuladas durante o ciclo de vida quando a POA é usada em sua implementação. O objetivo principal neste artigo é fornecer uma abordagem que permite manipular mais adequadamente o desenvolvimento das RNs nas primeiras fases do ciclo

2 de vida, o que resulta em um bom nível de rastreamento dessas RNs. Para isso são definidos critérios para a identificação e classificação de alguns tipos de RNs e diretrizes para realizar seu mapeamento para a etapa de modelagem. O artigo está organizado da seguinte forma: Na Seção 2 são apresentados os conceitos relevantes às RNs. Na Seção 3 são apresentadas propostas de identificação, classificação e modelagem de alguns tipos de RNs. Na Seção 4 é mostrado um estudo de caso com a abordagem proposta. Na Seção 5 encontra-se uma análise sobre os trabalhos relacionados a esse, e na Seção 6 encontram-se as considerações finais. 2. Regras de Negócio e POA RNs são compostas de termos e fatos que estruturam o conhecimento básico do negócio [Ross, 2003]. Termo é uma palavra ou frase simples, em linguagem natural, que deve ser reconhecida e compartilhada no âmbito do negócio. Fatos são sentenças declarativas que relacionam termos. As RNs podem ser classificadas de diversas formas [Business Rules Group, 2000; Ross, 2003; Von Halle, 2002]. Para esse trabalho será utilizada a classificação proposta por Von Halle (2002), por ser uma síntese de outros tipos de classificação e possuir foco no controle da execução de eventos de negócio. Nesse esquema as RNs são separadas em cinco tipos: Restrições, Diretrizes, Habilitadoras de Ações, Derivação por Computação e Derivação por Inferência. O uso de POA na implementação das RNs tem se mostrado adequado porque duas das quatro características de implementação exigidas pelas RNs [Ross, 2003; Von Halle, 2002] são atendidas com seu uso. Essas características são: i) Separação (separate): As RNs devem ser implementadas separadamente dos requisitos e do próprio sistema; ii) 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; iii) 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; iv) Posicionamento (position): As RNs devem sempre estar preparadas para mudanças, uma vez que por meio das regras pode-se mudar o curso regular do negócio. O uso de POA para a implementação das RNs auxilia o cumprimento direto das características i e iv. Todavia, para o cumprimento das características ii e iii é 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. Abordagem para Acompanhamento de Regras de Negócio 3.1. Identificação e Classificação das Regras de Negócio 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 dos casos de uso. Existem diversos tipos de gabaritos para a documentação de casos de uso, entretanto para esse trabalho será considerado o mostrado na Figura 1. Esse gabarito é uma extensão do proposto por Coleman (1998). A extensão foi feita para apoiar de forma mais adequada a identificação das RNs e consistiu em adicionar as quatro últimas seções ao gabarito original. Para a nomenclatura dessas seções procurou-se seguir padrões existentes, uma

3 vez que gabaritos com seções para pré e pós-condições e gatilhos são relativamente comuns. As informações para o preenchimento dessas seções podem ser obtidas nos requisitos do sistema. Em todas as novas seções existe a informação Negócio/Sistema cujo objetivo é separar regras que tratam de exigências do sistema, das que refletem exigências do negócio e que são caracterizadas como RNs. Caso d e Uso: Desc riçã o: Pre missas: Pass os: 1: 2: Variaç õe s: Não Fu nc ional: Q ue st ões: Pré -Con diçõe s: Neg ócio/s istem a C ondiçã o Pós- Con diç ões: Neg ócio/s istem a C on dição Ga tilh os: Negócio/ Sistem a T ipo de Ga tilho Guidelines Ha bilita dor De riva ção Ga tilho In for maçõe s aos Ator es: Negó cio/s istem a Deta lh am ento Na Tabela 1 são mostradas as diretrizes que devem ser aplicadas a documentos de requisitos com o objetivo de preencher as novas seções do gabarito (Figura 1). Seção Pré-Condições Pós-Condições Gatilhos Informações aos Atores Com os casos de uso documentados no gabarito, é possível a extração das RNs mediante aplicação de alguns critérios. Na Tabela 2 são mostrados esses critérios, que utiliza como base sua localização nas seções do gabarito proposto (Figura 1). Tabela 2. Critérios para Identificação e Classificação das Regras de Negócio Tipo de RN Critério de Identificação Restrições -Itens informados na seção Pré-Condições ou Pós-Condições, que sejam identificados como sendo de Negócio. Diretrizes -Itens informados na seção Informações aos Atores ou na seção Gatilhos como diretrizes, que sejam identificados como sendo de Negócio. Até o momento foram analisadas as regras do tipo Restrição e Diretrizes, que são abordados no contexto desse trabalho, sendo esses dois tipos adequados para serem projetados e implementados com POA devido à sua natureza que os caracteriza como um comportamento adicional do software, e por refletir uma política ou ação do negócio. Depois que o processo de identificação e classificação das RNs foi concluído sugere-se a elaboração de um artefato para registrar as RNs que foram identificadas. Esse artefato é mostrado na Tabela 3, nesse ponto não deve ser considerado o preenchimento das duas últimas colunas (Aspecto e Conjunto de Junção). Tabela 3. Relação de Regras de Negócio obtidas por meio dos casos de uso Regra Tipo Caso de Uso Seção Id. RN Aspecto Conj. de Junção No preenchimento da data de chegada e da Restrição Realizar Pré- RN1 Reserva_RN1 RN1 data de saída, o número de dias da reserva não Reserva Condição 1 deve exceder a 7 Na efetivação da reserva, o número de Restrição Realizar Pré- RN2 Reserva_RN2 RN4 acomodações disponíveis para o tipo de Reserva Condição 2 acomodação reservado no período da reserva deve ser maior que 0 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. Figura 1. G a barito pa ra Doc um en taç ã o d e Ca so de Uso Tabela 1. Diretrizes para o Preenchimento das Novas Seções do Gabarito Diretrizes Indicam condições que devem ser satisfeitas antes da ocorrência do caso de uso. Devem constar restrições, de negócio ou sistema, que levaria a execução do caso de uso a um estado indefinido. Indicam condições que devem se satisfeitas para que o caso de uso seja concluído. São procedimentos que devem ser disparados, após a execução do caso de uso, sempre que a condição estabelecida for satisfeita. Toda informação que deve ser fornecida aos atores relacionados ao caso de uso. Diretrizes Realizar Reserva Gatilho Modelagem das Regras de Negócio no Diagrama de Classes RN3 Reserva_RN3 RN3 Com as RNs identificadas e classificadas, a próxima etapa é projetar essas RNs no

4 diagrama de classes e também seu acoplamento com as classes que compõem o núcleo do software, que deve estar sendo projetado paralelamente as RNs. Para isso, deve-se projetar as RNs do artefato Relação de Regras de Negócio (Tabela 3) como aspectos. Depois disso, deve-se realizar a decomposição das RNs em termos, e identificar os termos que fazem parte do núcleo do software e os que fazem parte da RN. Os termos que são específicos da RN geralmente devem ser projetados como métodos ou atributos, ou serem implementados no próprio adendo (advice) do aspecto que implementa a RN, enquanto que os termos que fazem parte do núcleo do software correspondem aos pontos de acoplamento (pontos de junção join points) entre o aspecto (RN) e o núcleo do software, bem como aos métodos ou atributos que são utilizados pela RN. Para isso sugere-se a elaboração de um novo artefato para registrar cada termo com seu respectivo elemento estático (Tabela 4). Os termos não pertencem, necessariamente, a uma única RN, um termo pode estar presente em diversas RNs. Tabela 4. Relação de Termos com seus respectivos elementos estáticos Termo Data de Chegada Data de Saída Número de dias da reserva Efetivação da Reserva Número de acomodações disponíveis Tipo de acomodação reservado Período da Reserva Hóspede Faturas Vencidas e não pagas Advertência por Débitos Elemento Estático Atributo Reserva.DataChegada Atributo Reserva.DataSaída Diferença de dias entre os atributos Reserva.DataChegada e Reserva.DataSaida Método Reserva.Cadastra() Método TipoAcomodacao.AcomodacoesDisponiveis() Método Reserva.TipoAcomodacao Intervalo entre os atributos Reserva.DataChegada e Reserva.DataSaida Classe Hospede Método Hospede.ChecaCredito() A ser implementado na Regra de Negócio Após a realização desse mapeamento é possível identificar quais classes, métodos e atributos são afetados por uma RN sendo necessário modelar essa influência das RNs no diagrama de classes. Note-se que esse mapeamento pode ser feito nesse momento porque está sendo considerado nesse trabalho que a parte base do sistema já está parcialmente pronta. A influência que as RNs geram nos métodos e atributos das classes é a mesma que os conjuntos de junção (pointcuts) da POA realizam nos pontos de junção identificados nas classes base. Para modelar as RNs, que devem ser implementadas como aspectos, e para obter uma visualização dos pontos do código base que são afetados por essas RNs, é utilizada a notação proposta por Pawlak et al. (2002). Nessa notação os autores utilizam-se de classes com estereótipos para representar aspectos. Os métodos da classe, com a adição de estereótipos são utilizados para representar os adendos (advices) do aspecto. As associações com estereótipos <<pointcut>> são utilizadas para indicar as classes base que o aspecto entrecorta. Essas associações utilizam-se de etiquetas valoradas (tagged value) para identificar os pontos da classe base que serão entrecortados pelo aspecto. Na figura 2 é mostrado um exemplo dessa modelagem, nele a RN Reserva_RN2 foi projetada como um aspecto, e entrecorta o método Cadastra() da classe Reserva. Figura 2. Diagrama de classes modelado com as Regras de Negócio

5 Para que seja possível rastrear as RNs dos casos de uso até sua implementação é necessário que o mapeamento seja completo e estenda-se até a implementação das RN identificando os artefatos que implementam cada RN. Assim a Relação de Regras de Negócio (Tabela 3) deve ser completada com as informações referentes à implementação das RNs, que são: o aspecto e o conjunto de junção. 4. Estudo de Caso O estudo de caso consiste em um sistema de controle de hotel que gerencia estadias de hóspedes. Em conseqüência da limitação de espaço, é mostrado somente um caso de uso do sistema: o controle de reserva de acomodações. Com o início do desenvolvimento, o caso de uso é documentado pelo gabarito proposto na Seção 3.1, como é mostrado na Figura 3. A obtenção das pré-condições e gatilhos foi possível com a observação das restrições informadas no documento de requisitos. Porém, apurar se cada condição ou gatilho atua no âmbito de sistema ou de negócio é uma tarefa menos trivial, uma vez que deve-se avaliar se essas restrições e gatilhos cumprem necessidades do negócio ou do software. Com base no gabarito preenchido foram aplicados os critérios de identificação e classificação de RNs (Tabela 3), propostos na Seção 3.1. Como resultados foram obtidas as RNs relacionadas a cada caso de uso. Essas RNs são mostradas na Tabela 3. Com a decomposição das RNs em termos e a relação de cada termo com o elemento estático vinculado a ele obtêm-se um mapeamento entre o diagrama de casos de uso e o diagrama de classes. Na Tabela 4 é mostrada a decomposição dos termos das RNs e seu respectivo elemento estático. As RNs devem ser modeladas no diagrama de classe, como foi fundamentado na Seção 3.2. Nesse ponto deve-se interpretar cada RN para determinar qual método ou atributo será o ponto de junção da classe base com a RN. O diagrama de classe com as RNs modeladas é mostrado na Figura 2. A nomenclatura dos artefatos relativos às RNs deve seguir a indicada na Tabela 3, criando-se os aspectos e conjuntos de junção de acordo com a nomenclatura estabelecida nessa tabela. 5. Trabalhos Relacionados Figura 3. Gabarito do caso de uso RealizarReserva O uso de POA foi objeto de estudos de alguns pesquisadores, mostrando que esse tipo de implementação diminui o entrelaçamento, o espalhamento e facilita modificações quando as RNs precisam ser alteradas [Cibrán et al., 2004]. 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 [Martins, 2006], as que visam a implementação das RNs

6 com a tecnologia Adaptive Object Models [Yoder et al., 2001], as que focam a implementação das RNs por meio de tecnologias específicas, como por exemplo as linguagens baseadas em regras [Ross, 2003; Von Halle, 2002]. Existem também as pesquisas que apresentam uma abordagem para tratamento de RNs durante todo o ciclo de vida, mas no contexto da orientação a objetos, como em Korthaus (1998). 6. Considerações Finais e Trabalhos Futuros Esse trabalho apresentou uma abordagem de rastreamento de RNs, essa abordagem é composta pela identificação e classificação de RNs por meio da aplicação de critérios a uma extensão do gabarito para especificação de casos de uso. Mostrou-se também o uso de uma notação para a modelagem de dois tipos de RNs com o uso da UML. Foram focados dois tipos de RNs: Restrição e Diretrizes. Acredita-se que a contribuição principal desse artigo seja a possibilidade de rastreamento das RNs desde os casos de uso até sua implementação. Como contribuição secundária está a proposta de identificação e classificação das RNs. Nesse trabalho não estão sendo abordadas situações onde uma RN afeta mais de um ponto de junção, ou, várias RNs afetam um mesmo ponto de junção. Outro fator que necessita de uma melhor avaliação é a possibilidade de utilizar-se de declarações formais para especificar as RNs, como as abordadas em Martins (2006), possibilitando talvez uma facilidade maior na identificação dos elementos das RNs. Em continuação a esse trabalho está sendo definida a proposta de identificação e classificação para os demais tipos de RNs. Estão também sendo pesquisadas diretrizes de implementação das RNs, visando entre outros benefícios, a solução para o problema de múltiplas RNs num único ponto de junção, como citado no parágrafo anterior. 7. Referências Bibliográficas Business Rules Group (2001) Defining Business Rules: What Are They Really? Disponível em: Coleman, D. (1998) A Use Case Template: draft for discussion, Disponível em: citeseer.ist.psu.edu/ html Cibrán, M. A.; Suvée, D.; D Hondt, M.; Vanderperren, W.; Jonckers, V. (2004) Integrating Rules with Object-Oriented Software Applications using Aspect- Oriented Programming, In: Proceedings of the Argentine Society for Computer Science and Operational Research (SADIO), Córdoba, Argentina. Martins, A. E. (2006) Em direção à captura e representação sistemática das definições dos termos das regras de negócio, Dissertação de Mestrado, UFRJ, Rio de Janeiro. Korthaus A. (1998) Using UML for business object based systems modeling, In: The Unified Modeling Language - Technical Aspects and Applications, pág: Physica-Verlag, Heidelberg, Alemanha. Pawlak, R.; Duchien, L.; Florin, G.; Legond-Aubry, F.; Seinturier, L.; Martelli, L. (2002) A UML Notation for Aspect Oriented Software Design, In: 1 st International Conference on Aspect-Oriented Software Development. Enschede, Irlanda. Ross, R.G. (2003), Principles of the Business Rule Approach. Boston: Addison-Wesley. Von Halle, B. (2002), Business rules applied: building better systems using the business rules approach. New York: John Wiley & Sons, Inc. Yoder, J.; Balaguer, F.; Johnson, R. (2001) Adaptive Object-Models for Implementing Business Rules, In: Third Workshop on Best-Practices for Business Rules: Design and Implementation OOPSLA 2001, Tampa Bay, 2001.