MARCO ANTONIO DE GRANDI UMA ABORDAGEM DE IDENTIFICAÇÃO E MODELAGEM DE REGRAS DE NEGÓCIO E SEUS RELACIONAMENTOS TRANSVERSAIS

Transcrição

1 FUNDAÇÃO DE ENSINO EURÍPIDES SOARES DA ROCHA CENTRO UNIVERSITÁRIO EURÍPIDES DE MARÍLIA - UNIVEM MESTRADO EM CIÊNCIA DA COMPUTAÇÃO MARCO ANTONIO DE GRANDI UMA ABORDAGEM DE IDENTIFICAÇÃO E MODELAGEM DE REGRAS DE NEGÓCIO E SEUS RELACIONAMENTOS TRANSVERSAIS MARÍLIA 2008

2 MARCO ANTONIO DE GRANDI UMA ABORDAGEM DE IDENTIFICAÇÃO E MODELAGEM DE REGRAS DE NEGÓCIO E SEUS RELACIONAMENTOS TRANSVERSAIS Dissertação apresentada ao Programa de Pós- Graduação em Ciência da Computação do Centro Universitário Eurípides de Marília, como parte dos requisitos necessários à obtenção do título de Mestre em Ciência da Computação. Orientador: Prof. Dr. Edmundo Sérgio Spoto. Co-orientador: Prof. Dr. Valter Vieira de Camargo MARÍLIA 2008

3 DE GRANDI, Marco Antonio Uma Abordagem de Identificação e Modelagem de Regras de Negócio e seus Relacionamentos Transversais / Marco Antonio De Grandi; orientador: Edmundo Sérgio Spoto / co-orientador: Valter Vieira de Camargo, Marília, SP:[s.n.], f. Dissertação (Mestrado em Ciência da Computação) Centro Universitário Eurípedes de Marília Fundação de Ensino Eurípedes Soares da Rocha. 1. Regras de Negócio 2. Programação Orientada a Aspectos 3. Reúso de Software CDD:

4

5 Às minhas filhas Maria Júlia e Bianca, vocês foram minha motivação.

6 AGRADECIMENTOS Agradeço aos meus pais, por sempre acreditarem em mim. As minhas filhas, pela inspiração. Aos meus orientadores, Prof. Dr. Edmundo e Prof. Dr. Valter, pela confiança, dedicação e amizade. Ao meu sócio e irmão Mario, pelo apoio e compreensão nas insistentes ausências. Ao meu amigo Paulo, pela motivação inicial para essa jornada. Aos meus amigos de mestrado Silvio, Rodrigo, Bruno, Juliana, Thais, Camila e Giuliana pela amizade e convivência. E ao meu amigo Alex, pela amizade que excedeu ao companheirismo de mestrado.

7 Eu posso estar completamente enganado, Eu posso estar correndo pro lado errado. Mas a dúvida é o preço da pureza, Pois é inútil ter certeza. Humberto Gessinger

8 DE GRANDI, Marco Antonio. Uma Abordagem de identificação e modelagem de Regras de Negócio e seus relacionamentos transversais. 116 f Dissertação (Mestrado em Ciência da Computação) Centro Universitário Eurípides de Marília, Fundação de Ensino Eurípides Soares da Rocha, Marília, RESUMO O uso de regras de negócio dentro do contexto de sistema de informação tem despertado grande interesse no meio acadêmico. Vários pesquisadores argumentam que a volatilidade das regras de negócio faz com que seja necessário um tratamento mais aprimorado delas durante o desenvolvimento de sistemas de informação. Recentemente o surgimento da programação orientada a aspectos (POA) mudou a visão da integração das regras de negócio com o núcleo do software, uma vez que forneceu mecanismos para projetar e implementar essas regras de forma desvinculada desse núcleo. Neste trabalho é apresentada uma abordagem que permite identificar, classificar e modelar regras de negócio. Essa abordagem é baseada em artefatos que apóiam o registro das regras de negócio na fase de análise do software. Essa abordagem também é composta por critérios que apóiam a identificação e classificação das regras de negócio na fase de análise de requisitos. Também são estabelecidos critérios para apoiar a determinação do paradigma de projeto das regras de negócio, sendo que alguns tipos deverão ser projetados e implementados por meio de programação orientada a aspectos. Essa abordagem foi estruturada como uma extensão do Processo Unificado (PU) e foi validada com o desenvolvimento de um estudo de caso baseado em um sistema de gestão comercial real. Palavras chaves: Regras de Negócio, Programação Orientada a Aspectos, Reúso de Software.

9 DE GRANDI, Marco Antonio. Uma Abordagem de identificação e modelagem de Regras de Negócio e seus relacionamentos transversais. 116 f Dissertação (Mestrado em Ciência da Computação) Centro Universitário Eurípides de Marília, Fundação de Ensino Eurípides Soares da Rocha, Marília, ABSTRACT The use of business rules in the information systems context has attracted a great interest in the academic community. Many researchers argue that the business rules volatility requires a better treatment of them when developing a information system. Recently the appearance of the Aspect Oriented Programming changed the integration vision between business rules and the software core. In this work, an approach that allows to identify, classify and model business rules is presented. This approach is based on artifacts that permits the business rules registry in the analysis phase. This approach is also composed by criterias that support the business rules identification and classification in the requirement analysis phase. Some criterias are also defined to assist the project paradigms choice of business rules, in which some of them need to be projected and codified by aspect oriented programming. This approach is structured as a Unified Process extension and was validated with a case study development. This case study was based on a real commercial administration software. Key-words: Business Rules, Oriented Aspect Programming, Software Reuse

10 LISTA DE ILUSTRAÇÕES Figura 1.1 Um Framework para arquitetura empresarial (Zachman, 1997) Figura Classificação das Regras de Negócio Figura 1.3 Diagrama de Caso de Uso (Booch et al., 2000) Figura Diagrama de Classes (Booch et al., 2000) Figura 1.5 Diagrama de Seqüência (Booch et al., 2000) Figura 1.6 Definindo Estereótipos (Adaptado de Alhir, 2003) Figura 1.7 Aplicando Estereótipos no diagrama de classes (Adaptado de Alhir, 2003) Figura 1.8 Estereótipos, valores atribuídos e restrições (adaptada de Alhir, 2003) Figura 1.9 Exemplo de um aspecto implementado em AspectJ Figura 2.1 O cenário da modelagem de regras de negócio (Bajec e Krisper, 2004) Figura Exemplo da utilização do Business Object Model (Ilog, 2008) Figura Ciclos de vida do Software e das Regras de Negócio (Ilog, 2008) Figura Influência da abordagem no ciclo de vida de desenvolvimento de software Figura Gabarito para registro e documentação dos casos de uso Figura Exemplo de Gatilhos Figura 3.4. Exemplo da modelagem de RNs no diagrama de casos de uso Figura 3.5- Exemplo de Projeto de uma RN com o paradigma OO Figura Modelagem de uma RN com o uso da abordagem Pawlak et al Figura Rastreabilidade de uma Regra de Negócio Figura Casos de uso do ator Vendedor Figura Casos de uso do ator Administrador Figura Casos de uso do ator Gerente Figura Casos de uso do ator Caixa Figura Documentação do caso de uso Gerar Venda Figura Documentação do caso de uso Movimentar Estoque... 77

11 Figura Requisito 8 (oito) referente a movimentação de estoque Figura Requisito 10 (dez) referente ao registro de vendas Figura Diagrama de casos de uso com a modelagem das regras de negócio Figura Regra de negócio projetada como aspecto Figura Regra de Negócio candidata a aspecto Figura Diagrama de Classes Figura A.1 Exemplo de conjunto de junção Figura A.2 Exemplo de um adendo do tipo around Figura A.3 Exemplos de declaração intertipos

12 LISTA DE TABELAS Tabela 1.1 Classificação das Regras de Negócio Tabela Atividades da extensão do PU proposta Tabela Exemplo da seção fluxos alternativos Tabela Exemplo de Pré-Condições Tabela Exemplo de Pós-Condições Tabela 3.5 Critérios para a classificação das Regras de Negócio Tabela Exemplo do Artefato Lista de Regras Preenchido Tabela Diretrizes de apoio para análise do ponto de atuação Tabela 4.1 Lista de Regras parcialmente preenchida Tabela Lista de Regras totalmente preenchida Tabela A.1 Pontos de junção dinâmicos do AspecJ (adaptado de Kiczales et al., 2001b) Tabela A.2 Designadores disponíveis em AspectJ (Wink e Goetten Jr, 2006) Tabela A.3 Tipos de adendos disponíveis em AspectJ (Wink e Goetten Jr, 2006)

13 SUMÁRIO INTRODUÇÃO CONTEXTUALIZAÇÃO MOTIVAÇÃO OBJETIVO ORGANIZAÇÃO CAPÍTULO 1 REVISÃO BIBLIOGRÁFICA REGRAS DE NEGÓCIO A UTILIZAÇÃO DE REGRAS DE NEGÓCIO NA ENGENHARIA DE SOFTWARE CLASSIFICAÇÃO DAS REGRAS DE NEGÓCIO PRINCÍPIOS BÁSICOS DAS REGRAS DE NEGÓCIO PRINCÍPIOS PARA A IMPLEMENTAÇÃO DE REGRAS DE NEGÓCIO UML MODELO CONCEITUAL DA UML A. DIAGRAMA DE CASOS DE USO B. DIAGRAMA DE CLASSES C. DIAGRAMA DE SEQÜÊNCIA EXTENSÕES UML PROGRAMAÇÃO ORIENTADA A ASPECTOS CONSIDERAÇÕES FINAIS CAPÍTULO 2 TRABALHOS RELACIONADOS GERENCIAMENTO DE REGRAS DE NEGÓCIO SISTEMAS GERENCIADORES DE REGRAS DE NEGÓCIO REGRAS DE NEGÓCIO E ASPECTOS CONSIDERAÇÕES FINAIS CAPÍTULO 3 PROJETO DE SOFTWARE COM REGRAS DE NEGÓCIO VISÃO GERAL DA ABORDAGEM EXTENSÃO DO PROCESSO UNIFICADO... 50

14 3.2.1 DISCIPLINA ANÁLISE ATIVIDADE: IDENTIFICAR E REGISTRAR CASOS DE USO ESSENCIAIS ATIVIDADE: DOCUMENTAR CASOS DE USO COM GABARITO A) FLUXO ALTERNATIVO B) PRÉ-CONDIÇÕES C) PÓS-CONDIÇÕES D) GATILHOS ATIVIDADE: CLASSIFICAR E REGISTRAR REGRAS DE NEGÓCIO ATIVIDADE: REFINAR VISÃO DO DIAGRAMA DE CASOS DE USO PARA REGRAS DE NEGÓCIO DISCIPLINA PROJETO ATIVIDADE: DEFINIR PARADIGMA DE PROJETO DAS REGRAS ATIVIDADE: PROJETAR AS REGRAS DE NEGÓCIO NO DIAGRAMA DE CLASSES RASTREAMENTO DAS REGRAS DE NEGÓCIO CONSIDERAÇÕES FINAIS CAPÍTULO 4 ESTUDO DE CASO DEFINIÇÃO EXECUÇÃO DOCUMENTAR CASOS DE USO COM GABARITO IDENTIFICAR E CLASSIFICAR REGRAS DE NEGÓCIO REFINAR DIAGRAMAS DE CASO DE USO DEFINIR PARADIGMA DE PROJETO DAS REGRAS DE NEGÓCIO PROJETAR REGRAS DE NEGÓCIO NO DIAGRAMA DE CLASSES IMPLEMENTAR AS REGRAS DE NEGÓCIO CONSIDERAÇÕES FINAIS CONCLUSÕES PRINCIPAIS CONTRIBUIÇÕES LIMITAÇÕES TRABALHOS FUTUROS REFERÊNCIAS... 93

15 ANEXO A APÊNDICE A A1. LINGUAGENS DE SUPORTE À PROGRAMAÇÃO ORIENTADA A ASPECTOS A2. NOVAS CONSTRUÇÕES POA A2.1. PONTOS DE JUNÇÃO A2.2. CONJUNTOS DE JUNÇÃO A2.3. ADENDOS A2.4. MODIFICAÇÃO DE ESTRUTURAS ESTÁTICAS A2.5. ASPECTOS APÊNDICE B B1. VISÃO GERAL DO SISTEMA B2. REQUISITOS FUNCIONAIS B2.1. CADASTROS B2.2. LANÇAMENTOS DIVERSOS B2.3. CONSULTAS ON-LINE B2.4. IMPRESSÃO DE DIVERSOS TIPOS DE RELATÓRIOS E CONSULTAS B3. REQUISITOS NÃO FUNCIONAIS B3.1. CONFIABILIDADE B3.2. EFICIÊNCIA B3.3. PORTABILIDADE APÊNDICE C C1. CASO DE USO ABRIR CAIXA C2. CASO DE USO FECHAR CAIXA C3. CASO DE USO GERAR VENDAS C4. CASO DE USO MOVIMENTAR ESTOQUE C5. CASO DE USO GERAR PAGAMENTO DE DOCUMENTOS C6. CASO DE USO INFORMAR RECEBIMENTO DE DUPLICATAS C7. CASO DE USO CADASTRAR RECEBIMENTO DE PRODUTOS

16 15 INTRODUÇÃO Contextualização No decorrer da década de 1980 surgiu o conceito que classifica os termos, políticas, restrições e ações afetando o comportamento de uma organização. Esse conceito foi denominado de regras de negócio, e foi considerado um elo perdido, pois passou a fornecer uma ligação entre dois níveis de abstração distintos: a arquitetura de dados de alto nível e o projeto de dados de nível físico. O objetivo principal de tais regras era estabelecer maneiras restritivas de manipular os dados do negócio, fornecendo meios adicionais de melhorar a consistência desses dados, e estabelecendo uma ligação entre a estrutura de dados e a estrutura de processamento (Appleton, 1984). O uso de regras de negócio 1 dentro do contexto de Sistema de Informação 2 tem despertado grande interesse no meio acadêmico, e com isso diversas linhas de pesquisas têm surgido, apontando a necessidade de buscar formas de integração dessas regras, que geralmente são oriundas de processos organizacionais, com os sistemas de informação (Yu et al., 1995; Cibrán et al., 2006; Korthaus, 1998; Von Halle, 2002; Bajec e Krisper, 2004)). As regras de negócio podem estar presentes no software de diversas maneiras; podem estar implícitas em seu código, nas estruturas de dados, ou como gatilhos (triggers) e procedimentos armazenados (stored procedures) do banco de dados, mas, também podem estar projetadas de outras maneiras, usando diversos formatos de representação. A utilização das técnicas e métodos da engenharia de software no projeto de regras de negócio faz com que elas sejam mais bem manipuladas e gerenciadas, resultando em softwares mais manuteníveis, e que possam responder de forma mais adequadas às freqüentes alterações exigidas pelo ambiente de negócio. Como exemplos dessas alterações podem-se citar as mudanças de políticas, de leis e procedimentos, bem como os constantes rearranjos em busca de melhores métodos de gestão (Bajec e Krisper, 2004). Muitos pesquisadores estão 1 Como é explicado no próximo capítulo, regras de negócio (RNs) são diretivas cujo objetivo é influenciar ou guiar o comportamento de um negócio (Ross, 2003). Dentro do contexto de Sistemas de Informação, regras de negócio é a parte do software responsável pela definição do comportamento do software, ou como ele deve operar (Date, 2000). 2 Sistema de informação é um software desenvolvido com o objetivo de apoiar as operações de negócio realizadas por uma empresa.

17 16 convencidos que a natureza volátil das regras de negócio frente às mudanças do negócio requer um tratamento explícito durante o desenvolvimento de sistemas de informação (Bajec e Krisper, 2004; Ross, 2003; Von Halle, 2002). Recentemente o surgimento da programação orientada a aspectos (POA) mudou a visão da integração das regras de negócio com o núcleo do software 3, uma vez que forneceu meios para a implementação das regras de forma desvinculada do núcleo do software, possibilitando sua integração de forma não invasiva ao código, em um artefato independente, por meio dos novos construtores oferecidos nesse paradigma (Cibrán et al.,2003). O projeto das regras de negócio de forma desvinculada e independente do núcleo do software é um dos princípios desejáveis ao projeto das regras de negócio (Ross, 2003; Von Halle, 2002). Assim, surgiram alguns trabalhos que mostram a utilização da orientação a aspectos como apoio a essa implementação (Cibrán et al., 2003; Cibrán et al., 2004; Camargo e Masiero, 2005). O conceito difundido por esses trabalhos foi a implementação do código referente à regra de negócio por meio de módulos específicos (classes), no paradigma orientado a objetos, e a conexão com o núcleo do software por meio do paradigma orientado a aspectos. Motivação A motivação principal deste trabalho é a carência de métodos e técnicas adequadas para o tratamento de regras de negócio nas atividades de análise e projeto do software. Notase também na literatura especializada, a ausência de critérios para a identificação e classificação das regras de negócio que auxiliem a modelagem dessas regras de forma independente do núcleo do software. Também não foram encontrados trabalhos que apresentem uma notação precisa para representar regras de negócio nas fases de análise e projeto do software. Outro ponto que merece destaque é no projeto de regras de negócio com Orientação a Aspectos (OA), já que, apesar de alguns trabalhos sugerirem o projeto das regras de negócios com POA, em nenhum deles é apresentada uma diretriz clara de quais tipos de regras de negócios são adequadas de serem projetadas com esse paradigma. 3 No contexto desse trabalho, núcleo do software é a sua parte base, responsável pela implementação das características funcionais do software.

18 17 Dessa forma, nota-se ausência de um conjunto de mecanismos que propiciem as técnicas e artefatos necessários ao tratamento das regras de negócio durante as atividades de análise e projeto do software. Objetivo O objetivo deste trabalho é fornecer mecanismos ao engenheiro de software para realizar atividades de identificação, de classificação e de modelagem de regras de negócio, resultando em artefatos de software independentes e rastreáveis, aumentando assim a capacidade de modularização e de adaptabilidade do software. Deve ser feita dessa forma, tendo em vista que manutenções e adaptações ocorrem mais freqüentemente nas regras de negócio do que no núcleo de software (Von Halle, 2002; Ross, 2003). Para isso, é sugerida uma abordagem baseada em uma extensão do Processo Unificado (Unified Process), originalmente proposto por Jacobson et. al (1999), com a finalidade de manipular de forma mais adequada as regras de negócio durante o desenvolvimento de softwares. Essa extensão é baseada em um gabarito (template) para o registro dos casos de uso, cuja utilização apóia a identificação das regras de negócio. Além disso, são estabelecidos critérios para a identificação e classificação das regras de negócio a partir dos requisitos do projeto de software. Numa outra atividade, são estabelecidos critérios para a identificação de regras de negócio que devem ser projetadas com OA. Como apoio ao projeto das regras de negócio/aspectos é sugerido o uso de uma notação específica, proposta por Pawlak et al. (2002), bem como o uso de estereótipos para apoiar a modelagem de casos de uso e métodos que representam regras de negócio. Organização Esta monografia é apresentada em quatro capítulos, além desta introdução e da conclusão. Nessa primeira parte é apresentada a contextualização da convergência do conceito de regras de negócio com a engenharia de software. É apresentada também a motivação deste trabalho, bem como seu objetivo. Os próximos capítulos estão organizados da seguinte forma: no Capítulo 1 são apresentados os conceitos relevantes para a proposta deste trabalho. No Capítulo 2 são

19 18 descritos os principais trabalhos relacionados a este, bem como os conceitos utilizados. No Capítulo 3 é apresentada a abordagem proposta neste trabalho destacando as principais sugestões de melhorias. No Capitulo 4 é apresentado um Estudo de Caso visando ilustrar a prática da abordagem proposta. E por fim são apresentadas as conclusões finais e as propostas de trabalhos futuros.

20 CAPÍTULO 1 REVISÃO BIBLIOGRÁFICA 19 Neste capítulo são apresentados os conceitos relevantes para a proposta deste trabalho. Na Seção 1.1 é discutida a definição e os principais conceitos de regras de negócio, na Seção 1.2 é apresentada a UML (Unified Modeling Language), seus principais diagramas e seu mecanismo de extensão e na Seção 1.3 é discutido o conceito de programação orientada a aspectos, com ênfase na Linguagem AspectJ 1.1. Regras de Negócio Segundo Ross (2003), regras de negócio (RNs) são diretivas cujo objetivo é influenciar ou guiar o comportamento de um negócio. Para o Business Rules Group (2000), RNs são declarações que definem ou restringem algum comportamento de um negócio. Ainda para o Business Rules Group (2000), uma RN expressa restrições específicas na criação, atualização ou remoção de dados persistentes em um sistema de informação. Numa definição mais detalhada, Wiegers (2006) afirma que RNs são políticas da companhia, padrões de indústria ou leis e regulamentações governamentais que definem, restringem ou governam alguns comportamentos de um negócio. Todas as definições aqui apresentadas convergem para pontos comuns. Para ilustrar de uma forma mais prática, Date (2000) cita que um sistema de informação, que implementa alguma função de negócio, pode ser dividido em três partes, sendo elas: 1. Funcionalidades de Apresentação 2. Funcionalidades de Banco de Dados 3. Funcionalidades específicas da função de negócio em si. Com base nessa divisão de um sistema de informação, a terceira parte contém as RNs do software, e, fica claro que as duas primeiras partes foram largamente automatizadas, mas a terceira parte necessita, ainda hoje, de muita codificação para que a implementação das funcionalidades específicas da função de negócio seja possível (Date, 2000). Ainda segundo Date (2000), RNs, dentro do contexto de Sistemas de Informação, é a parte do software responsável pela definição do comportamento do software, ou como ele deve operar. Nos últimos anos a relação entre as RNs e a engenharia de software gerou duas linhas distintas de pesquisa, a primeira, foca a obtenção e representação sistemática das RNs

21 20 por meio de várias técnicas, como: a linguagem natural, Object Constraint Language (OCL), extensible Markup Language (XML), Lógica de Primeira Ordem (LPO), entre outras (Martins, 2006; Morgado 2005). O objetivo primário dessa linha de pesquisa é a obtenção das RNs pelos especialistas de negócios, sua posterior tradução para uma representação computacional e sua integração com os sistemas de informação da empresa pelo código gerado. A integração ocorre por meio de ferramentas que geram códigos para linguagens específicas, ou por meio de Sistemas Gerenciadores de Regras, que oferecem mecanismos de integração das regras especificadas, em um ambiente próprio, com o software desenvolvido. Numa outra linha estão os trabalhos que buscam representar as RNs como um componente do software, devidamente empregado nas etapas do ciclo de vida da engenharia de software (Korthaus, 1998; Ross, 2003; Von Halle, 2002). Essa linha tem como objetivo melhorar a sua modularização, propiciando uma melhor adaptabilidade e manutenção ao software. Dentro dessa linha, existem ainda as pesquisas que buscam a integração de RNs, codificadas separadamente do núcleo do software, por meio de programação orientada a aspectos. Para o foco dado a esse trabalho, será explorada essa segunda linha de pesquisa. Um elemento sempre presente na ilustração do envolvimento entre RNs e sistemas de informação é um framework proposto por Zachman (1997). Na próxima seção será detalhado como esse framework forneceu fundamentação para a relação entre RNs e sistemas de informação A utilização de Regras de Negócio na Engenharia de Software Boa parte do enquadramento das RNs no processo de desenvolvimento de software, ou mesmo, o enquadramento das RNs com relação às atividades das corporações está fundamentado no framework para arquitetura empresarial desenvolvido por Zachman (1997) (Business Rules Group, 2000; Ross, 2003; Von Halle, 2002), que será referenciado neste trabalho como Framework de Zachman. Esse trabalho foi um dos primeiros a sugerir a utilização das RNs pela engenharia de software, incluindo em seu framework as fases de modelagem e projeto das RNs, integradas ao desenvolvimento de software. Todavia isso foi feito apenas de maneira conceitual, sem o detalhamento sobre o funcionamento de cada atividade. Na Figura 1.1 é mostrada a representação do Framework de Zachman, que é um conjunto de representações, sob diferentes perspectivas, das atividades existentes no processo

22 21 de desenvolvimento de software (Zachman, 1997). Para viabilizar essa representação, o autor elaborou esse framework focando a ilustração do processo de desenvolvimento de software, no qual as linhas representam as diferentes perspectivas ou papéis e as colunas representam as diferentes características, ou abstrações, do produto em questão. Zachman (1997) argumenta que o estado da arte de modelagem de RNs, que é utilizada na coluna Motivação (Motivation), é limitado. Argumenta ainda que é fato comum encontrar essas regras expressas em estrutura de dados ou código procedural, que não fornecem o subsídio necessário para que o planejamento e modelagem dessas regras ocorram de forma adequada. O autor argumenta, por meio desse trabalho, que quando as pressões competitivas do mercado forçarem melhor integração das RNs com o software, para que respondam em tempo hábil às pressões competitivas, elas começarão a ser tratadas nos modelos arquiteturais de processos, passando a serem mais bem definidas e gerenciadas. Esse trabalho serviu para mostrar a importância e a necessidade das RNs na organização e no processo de desenvolvimento de software, assim, trabalhos posteriores como o Business Rules Group (2000) e Ross (2003) procuraram focar o modelo de processo de negócio, e o modelo de RNs que havia sido abordado por Zachman (1997), tratando assim sua melhor definição, classificação e utilização. Para isso, ambos os trabalhos focaram as linhas de um a três (Planner a Designer) do framework proposto por Zachman. Com isso as RNs foram classificadas em duas categorias extraídas do framework do Zachman: i) as de negócio, que focam mais a linha dois (owner), e ii) as de sistema de informação, focada na linha três (designer) (Business Rules Group, 2000). As RNs podem ser classificadas ainda, de acordo com o modo como elas influenciam ou guiam o comportamento de um negócio. Na próxima seção é detalhada essa classificação.

23 Figura 1.1 Um Framework para arquitetura empresarial (Zachman, 1997) 22

24 Classificação das Regras de Negócio Na literatura sobre RNs é possível encontrar diversas formas de classificá-las. Cada autor utiliza a classificação que julga mais adequada ao propósito em questão. Na Tabela 1.1 são mostrados alguns exemplos de classificação de Regras de Negócio por diferentes autores. Tabela 1.1 Classificação das Regras de Negócio Origem Esquema de Classificação Business Rules Group (2000) Declarações Estruturais o Termos o Fatos Declarações de Ação o Autorização o Condição o Restrição de Integridade Derivações o Cálculo Matemático o Inferência C. J. Date (2000) Restrição Restrição de Estado Restrição de Transição Estímulo/Resposta Derivação Computação Inferência No mesmo trabalho ainda é apresentado um segundo esquema de classificação: Restrições de Domínio Restrições de Coluna Restrições de Tabela Restrições de Banco de Dados Ross (2003) Restrições Derivações Inferência Temporização Seqüência Heurística Von Halle (2002) Restrições o Restrições (Ação Restritiva) o Diretrizes (Ação Informativa) Habilitadoras de Ações Derivação o Computação o Inferência Nessa tabela pode-se comprovar que os autores direcionam a forma de classificação de acordo com seu propósito. Sendo assim a classificação proposta por C. J. Date (2000) está mais focada aos interesses de banco de dados, enquanto a classificação do Business Rules

25 24 Group (2000) é mais genérica, preocupando inclusive com a estrutura que compõe as RNs. A classificação proposta por Ross (2003) visa estruturar as regras de modo a facilitar a aplicação de sua abordagem. E por fim, a proposta de Von Halle (2002) é a mais concisa e considera as características funcionais das RNs sem, contudo, esquecer das diferenças estruturais entre os tipos propostos. Além disso, essa classificação pode ser considerada como uma síntese de outros tipos de classificação e possui foco nos tipos de regras que normalmente são utilizados em sistemas de informação. Normalmente, outros tipos de classificação têm seu foco na forma como as regras são implementadas, ou onde elas serão armazenadas. Dessa forma, para este trabalho será utilizada a classificação proposta por Von Halle (2002), mostrada na Figura 1.2, na qual uma RN pode ser uma restrição, uma diretriz, uma habilitadora de ações, ou uma derivação (por computação ou inferência). As RNs do tipo Restrições expressam um comportamento restritivo, ou seja, expressam uma circunstância que deve ser verdadeira ou deve ser falsa para que um evento de negócio possa ser completado com a integridade desejada (Von Halle, 2002). Geralmente as regras de restrição ocorrem de forma independente da execução do software, refletindo uma restrição que só é importante no âmbito do negócio, e não para a integridade do software em si. As RNs do tipo Diretriz são definições que expressam uma advertência sobre uma circunstância de negócio que faz com que alguma ação humana, ou de qualquer outro tipo que esteja fora do escopo do software, seja executada sem, contudo, restringir a execução do software. As RNs do tipo Habilitadora de Ações são mecanismos que verificam uma determinada condição e caso ela seja verdadeira inicia uma nova ação no software. As RNs do tipo Derivação (por computação ou inferência) resultam na criação de um novo trecho de informação que, em termos de banco de dados, pode ser uma nova instância de uma entidade, ou uma nova instância de um atributo. Para que a derivação ocorra é necessário que seja implementado o mecanismo de derivação com o mapeamento que será aplicado às informações bases para a extração das informações derivadas. A classificação das RNs auxilia em seu projeto e implementação, uma vez que agrupa as RNs com características semelhantes e que devem exercer o mesmo papel na execução de um sistema de informação. As RNs possuem uma estrutura base que independe da forma como são classificadas, elas sempre são compostas de termos e fatos.

26 Regra de Negócio 25 Informações restritivas de interesse aos eventos de negócio Habilita outras ações de interesse aos eventos de negócio Cria novas informações de interesse aos eventos de negócio Restrições Diretrizes Habilitadoras de ações Computação Inferência Figura Classificação das Regras de Negócio Os termos e fatos estruturam o conhecimento básico do negócio (Ross, 2003). Eles definem o significado dos termos usados no dia-a-dia de uma organização e estabelecem possíveis ações que permeiam as operações de um negócio. Termo é uma palavra ou frase simples, em linguagem natural, que deve ser reconhecida e compartilhada no âmbito do negócio. O termo não deve ser ambíguo e deve oferecer um significado particular ao negócio. Todos os fatos e regras, que referenciem o termo, dependem de seu significado, assim, é mais importante o conceito de negócio que ele representa do que o próprio significado da palavra. Para que um termo possa ser usado ele precisa possuir três características (Ross, 2003): Básico: Termos não podem ser derivados ou associados a outros termos. Atômico: Termos devem representar conceitos indivisíveis. Gerar conhecimento: Termos devem sempre representar conceitos que produzem algum tipo de conhecimento. Para ilustrar um exemplo de termo, pode-se considerar a palavra Consumidor, cujo significado é: uma organização ou pessoa individual que colocou um pedido e realizou um pagamento nos últimos dois anos. Fatos são sentenças declarativas que relacionam termos apropriados. Os fatos devem ser expressos utilizando-se de sentenças completas, que devem meramente estabelecer o fato sem qualquer restrição.

27 26 Como exemplos de fato, pode-se citar: Consumidores colocam pedidos, Funcionário tem um gerente ou Gerente é uma categoria de funcionário. Os fatos podem ser classificados como Base ou Derivados. Um fato Base é o registro de algo existente no mundo real. Um fato Derivado é uma declaração que é construída a partir de outras declarações, e, só pode existir sendo criado a partir da aplicação de uma regra de derivação (que será definida nas próximas subseções). Como pode ser notado, termos e fatos se aproximam muito do conceito de requisitos para o desenvolvimento de um software, ou, como citado em Ross (2003), termos e fatos são tipos fundamentais de requisitos Princípios Básicos das Regras de negócio Existem alguns princípios que devem ser observados para se lidar com RNs. Ross (2003), durante a explanação sobre sua abordagem de RNs, mostra os princípios básicos das RNs, que funcionam como um guia para a elaboração correta dessas regras dentro do contexto de negócio, como segue: Regras devem ser escritas de forma explícita; Regras devem ser expressas em linguagem clara; Regras devem existir independentemente de procedimentos e workflows; Regras devem ser construídas sobre fatos, e os fatos devem ser construídos sobre conceitos representados por termos; Regras devem guiar ou influenciar comportamentos da maneira prevista; Regras devem ser movidas por fatores de negócio identificáveis e importantes; Regras devem ser únicas; Regras devem ser especificadas diretamente pelas pessoas que tem um conhecimento relevante sobre elas; Regras devem ser gerenciadas. Segundo Bajec e Krisper (2004), outro princípio, não menos importante, sobre RNs é que por sua natureza, as RNs estão em constante mudança devido às influências sofridas, sejam elas influências internas ou externas à organização.

28 Princípios para a Implementação de Regras de Negócio 27 A metodologia de RNs proposta por Von Halle (2002), defende que os softwares que implementam RNs devem sempre manter separados três elementos do software: regras, dados e processos. Considerando que o foco dessa metodologia são as regras, nela a autora defende que todo software que incorpora conceitos de RNs (e em sua opinião todos os softwares que manipulam informações coorporativas deveriam incorporá-los) deve respeitar alguns princípios básicos que tem por objetivo garantir a separação e gerenciamento das RNs, algo que geralmente é negligenciado nas metodologias tradicionais de desenvolvimento de software. Esses princípios são: 1. Separação (Separate): As RNs devem ser projetadas de forma separada do núcleo do software. 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. Além disso, esse princípio apóia as tarefas de manutenção do sistema; 3. Exteriorizaçã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. Em resumo, deve ser possível alterar-se uma RN de forma fácil e rápida. Na definição da metodologia de RNs, Von Halle (2002) salienta que a abordagem orientada a objetos não está preparada para respeitar esses quatro princípios das RNs. A opinião da autora é semelhante a outras opiniões encontradas, como a dos autores Bajec e Krisper (2004) que salientam que nos modelos orientados a objetos não existe um consenso sobre onde acomodar as RNs, o que faz com que as RNs fiquem espalhadas pelo código, sendo muitas vezes projetadas como métodos das classes, tornando-se o ponto fraco dos sistemas desenvolvidos. No trabalho de Korthaus (1998), embora o autor não cite explicitamente os princípios de projeto de RNs, ele cita a importância das RNs serem modeladas e implementadas de forma independente, o que favoreceria a manutenção e seu gerenciamento, já que impediria que as RNs ficassem espalhadas pelo código do software.

29 28 Dessa forma entende-se que a opinião expressada por Von Halle (2002) reflete o cenário encontrado à época de seu trabalho, para descrever o desenvolvimento de RNs com o uso do paradigma OO. Contudo, recentemente com o uso de OA no projeto das RNs, o cumprimento dos princípios 1 e 4 foi facilitado, uma vez que com os novos construtores oferecidos por esse paradigma as RNs podem ser projetadas como um Aspecto, e implementadas num módulo de software separado do núcleo, permitindo uma acesso rápido na manutenção, ou evolução, dessas regras. Todavia, para o cumprimento dos princípios 2 e 3 é 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 UML A primeira versão completa e padronizada da UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) surgiu em janeiro de 1997, oriunda da fusão dos métodos Booch, OMT de Rumbaugh e OOSE de Jacobson (Booch et al., 2000). A UML é uma linguagem-padrão para a elaboração da estrutura de projetos de software, independente do processo, apesar de ser perfeitamente utilizada em processo orientado a casos de usos, centrada na arquitetura, iterativo e incremental (Booch et al., 2000). A UML é uma linguagem destinada a: visualizar, especificar, construir e documentar. Atualmente, a UML é usada no desenvolvimento dos mais diversos tipos de sistemas. Ela é aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificação da análise de requisitos até a fase de testes (Booch et al., 2000). Seu objetivo é descrever qualquer tipo de sistema, utilizando-se de diagramas de representação dos mesmos Modelo conceitual da UML O vocabulário da UML abrange três tipos de blocos de construção: itens, relacionamentos e diagramas. Os itens são as abstrações em um modelo, os relacionamentos reúnem esses itens e os diagramas agrupam coleções dos itens (Booch et al., 2000).

30 29 Segundo Booch et al. (2000), os itens podem ser subdivididos em quatro tipos, sendo eles: estruturais, comportamentais, de agrupamento e de anotação, como seguem: Estruturais: são os substantivos utilizados em modelos da UML, são as partes mais estáticas dos modelos. Ao todo existem sete tipos de itens estruturais: classes, interfaces, colaborações, caso de uso, classes ativas, componentes e nós. Comportamentais: são as partes dinâmicas dos modelos UML, podem ser considerados os verbos de um modelo, representando comportamentos. Os itens comportamentais são dois: interação e máquina de estado. De Agrupamento: são as partes organizacionais dos modelos UML, são os blocos em que os modelos podem ser compostos. Existe apenas um tipo principal de itens de agrupamentos, os pacotes. De Anotação: são as partes explicativas dos modelos de UML, são os comentários incluídos para descrever, esclarecer e fazer alguma observação sobre qualquer elemento do modelo. Existe um único tipo de item de anotação, as notas. Outro bloco de construção da UML são os relacionamentos. Eles interligam as classes e objetos estabelecendo uma relação lógica entre elas. Eles também se subdividem em quatro tipos, sendo: dependência, associação, generalização e realização. Por fim, serão abordados os diagramas da UML, que são os gráficos que descrevem a visualização de um sistema sob diferentes perspectivas (Booch et al., 2000). O mesmo elemento pode aparecer em todos os diagramas, em alguns ou em nenhum diagrama. A UML possui nove tipos de diagramas descritos a seguir: a. Diagrama de classes b. Diagrama de objetos c. Diagrama de casos de uso d. Diagrama de seqüências e. Diagrama de colaborações f. Diagrama de gráficos de estados g. Diagrama de atividades h. Diagrama de componentes i. Diagrama de implantação Para o escopo desse trabalho, três diagramas têm especial importância, e, deverão ser utilizados em seu desenvolvimento, são eles: diagrama de casos de uso, diagrama de classes e

31 30 diagramas de seqüência. Assim, nas próximas subseções cada diagrama será descrito de forma mais detalhada. a. Diagrama de Casos de Uso Os diagramas de casos de uso são diagramas para a modelagem de características dinâmicas do sistema (Booch et al., 2000). Eles modelam o comportamento de um sistema, de um subsistema ou de uma classe. Esses diagramas tornam os sistemas mais acessíveis, melhor compreendidos, por apresentarem uma visão externa sobre os elementos utilizados no contexto. Os diagramas de casos de uso são compostos por um conjunto de casos de uso, atores e seus relacionamentos (Booch et al., 2000). Assim, um caso de uso especifica o comportamento do sistema ou parte dele e é uma especificação de um conjunto de seqüências de ações, incluindo variantes realizadas pelo sistema para produzir um resultado observável pelo ator, sem ser necessário especificar como esse comportamento será implementado. Esses comportamentos são funções em nível de sistema, utilizada para visualizar, especificar, construir e documentar o comportamento pretendido do sistema durante a captação e análise de requisitos (Booch et al., 2000). Um caso de uso é representado por uma elipse contendo seu nome, sendo que o nome é formado por expressões verbais ativas que reflitam o comportamento do caso de uso. Normalmente, um caso de uso envolve a interação dos atores com o sistema (Booch et al., 2000). Um ator representa um conjunto coerente de papéis que os usuários dos casos de uso desempenham quando interagem com esses casos. Um ator representa o papel de um ser humano, de um dispositivo de hardware ou até de outro sistema (Booch et al., 2000). Esses atores poderão estar conectados aos casos de uso por meio dos relacionamentos de dependência, generalização e associação. Na Figura 1.3 é mostrada a estrutura básica de um diagrama de caso de uso, por meio de um exemplo simples. b. Diagrama de Classes No diagrama de classes são apresentados um conjunto de classes, interfaces e colaborações e seus relacionamentos (relacionamentos de dependência, generalização e associação) (Booch et al., 2000).

32 31 Uma classe é uma descrição de um conjunto de objetos com os mesmos atributos, relacionamentos, operações e semântica. Toda classe dever ter nome que a distinga das outras classes. Ela também é caracterizada como um classificador. Classificador é um mecanismo que descreve características estruturais e comportamentais. Os classificadores incluem classes, interfaces, tipos de dados, sinais, componentes, nós, casos de uso e subsistemas (Booch et al., 2000). O classificador tem características avançadas, possibilitando a modelagem da multiplicidade, da visibilidade, das assinaturas, do polimorfismo e de outras características (Booch et al., 2000). Figura 1.3 Diagrama de Caso de Uso (Booch et al., 2000) Ao se fazer a modelagem das características comportamentais de uma classe definese suas operações e sinais. O nome de uma operação juntamente com seus parâmetros (incluindo seu tipo de retorno) é chamado de assinatura da operação (Booch et al., 2000). Na UML além da modelagem dos itens que formam o vocabulário do sistema também devem ser modelados os relacionamentos entre esses itens (Booch et al., 2000). Na modelagem orientada a objetos os quatro relacionamentos mais importantes são: dependências, generalizações, associações e realizações. Podendo ser feita modelagem de heranças múltiplas, navegação, refinamentos e outras características (Booch et al., 2000). Na Figura 1.4 é apresentado o diagrama de classes com as respectivas características estáticas dos blocos de construção e seus relacionamentos. c. Diagrama de Seqüência

33 32 O diagrama de seqüência é um diagrama de interação que dá ênfase à ordenação temporal de mensagens (Booch et al., 2000). Esse diagrama distribui, de forma cartesiana, os objetos no eixo X e as mensagens, em ordem temporal, no eixo Y. Figura Diagrama de Classes (Booch et al., 2000) Conforme exemplificado na Figura 1.5, o diagrama de seqüência é formado colocando-se os objetos que participam da interação na parte superior do diagrama, seguindo o eixo X. O objeto que inicia é o primeiro à esquerda, e os objetos que serão instanciados no decorrer da interação vão aparecendo à direita. Em seguida, as mensagens que esses objetos enviam e recebem são distribuídas ao longo do eixo Y, em ordem crescente de tempo de cima para baixo (Booch et al., 2000). Uma das características do diagrama de seqüência é a representação do foco de controle. Sempre que um objeto é criado no diagrama, inicia-se sua linha de vida, que é uma

34 33 linha tracejada vertical que representa a existência do objeto (Booch et al., 2000). No decorrer de sua linha de vida, são criados retângulos altos e estreitos que representam os períodos que o objeto está desempenhando alguma ação. Assim, sempre que um objeto recebe uma mensagem, iniciando uma ação, um retângulo é iniciado, terminando com a conclusão da ação, que pode ser marcada por uma mensagem de retorno (Booch et al., 2000). Figura 1.5 Diagrama de Seqüência (Booch et al., 2000) O diagrama de seqüência é utilizado para a modelagem das características dinâmicas do sistema, que podem envolver qualquer tipo de instância de um sistema. Podem-se anexar os diagramas de seqüência aos casos de uso, para assim, realizar a modelagem de um cenário. Como define Larman (2007), um diagrama de seqüência de sistema deve ser feito para a seqüência típica de eventos de casos de uso, e, possivelmente, outros diagramas de seqüência para as outras seqüências alternativas mais interessantes Extensões UML Segundo Rumbaugh et al. (1998), a UML foi concebida para ser usada com diversos propósitos, e, embora ela seja uma linguagem universal que pode expressar um grande número de propriedades fundamentais de modelagem, algumas vezes pode ser desejável uma linguagem que se adapte a um domínio específico. A UML pode ser adaptada usando-se diversos mecanismos, como: convenções, regras de estilo, classes pré-definidas e mapeamento implícito para software. A UML oferece, ainda, extensões, chamadas de perfis (profiles), que podem ser definidas com o uso de:

35 34 estereótipos (stereotypes), restrições (constraints) e valores atribuídos (tagged values) (Rumbaugh et al., 1998). Um perfil é uma coleção de definições de estereótipos, valores atribuídos e restrições relevantes para especificar um domínio ou propósito (Alhir, 2003). O perfil é formado por elementos de modelos, estendidos a partir dos elementos padrão da UML. Um perfil pode ser reusado em outros projetos do mesmo domínio. Os perfis possuem como restrição o fato de que eles devem ser estritamente aditivos para a semântica padrão da UML (Pender, 2003), dessa forma esses perfis não devem conflitar ou contradizer a semântica padrão da UML. As extensões permitem que a UML se adapte a novas tecnologias, porém essas extensões devem ser usadas de forma criteriosa, uma vez que a própria linguagem proposta oferece muitas construções expressivas. Assim, essas extensões devem ser evitadas, uma vez que, por definição, uma extensão serve a uma comunidade específica, e pode conduzir ao engano as demais comunidades. Por outro lado, o poder expressivo de uma extensão pode compensar a perda da uniformidade. Com o tempo, as extensões podem tornar-se úteis o suficiente para serem adicionadas à UML padrão, ou cair no esquecimento (Rumbaugh et al., 1998). Segundo OMG (2005), é possível estender a UML de duas maneiras: extensões lightweight e extensões heavyweight. As extensões lightweight são extensões mais leves e apenas estendem as metaclasses já existentes na UML padrão, assim, nesse tipo de extensão apenas são criados estereótipos, restrições e valores atribuídos. As extensões heavyweight são extensões mais pesadas e que alteram o metamodelo em si, criando novas metaclasses no metamodelo padrão da UML. A UML possui uma arquitetura definida com um esquema chamado de Metamodelo de Arquitetura Quatro Camadas que engloba quatro diferentes níveis de abstração (Alhir, 2003). Cada camada define elementos, conceitos e relações entre conceitos, como segue: Camada meta-metamodelo ou camada nível M3: Essa camada define a base para a arquitetura do metamodelo, a responsabilidade primária dessa camada é definir a linguagem para a especificação do metamodelo. Assim, essa camada define um modelo com maior nível de abstração que a camada de metamodelo. Exemplo de meta-metaobjetos definidos nessa camada são MetaClasse, MetaAtributo e MetaOperação. Camada metamodelo ou camada nível M2: Essa camada é uma instância da camada M3, nela são definidos os conceitos de Classe, Atributo, Operação, Valor

36 35 de Atributo, Associações, Ligações, etc. A responsabilidade primária dessa camada é definir a linguagem para a especificação de modelos. Nessa camada são incluídos todos os conceitos que compõem a UML. Exemplos de metaobjetos definidos nessa camada são: Classe, Atributo, Operação e Componente. Camada modelo ou camada nível M1: Essa camada é uma instância da camada M2, sua responsabilidade primária é definir uma linguagem que descreve um domínio de informações. Nessa camada são definidas classes específicas, atributos, ope rações e associações, que compõem os projetos dos usuários. Camada modelo de usuário ou camada nível M0: Nessa camada são definidos os objetos, valor de atributos e ligações, que compõem os projetos de usuários. O primeiro elemento utilizado nas extensões UML é o estereótipo, que é usado para prover a extensão do vocabulário padrão da modelagem, ou para oferecer indicações visuais distintivas para determinados tipos de abstrações (Booch et al., 2000). 2003). Um estereótipo define um novo tipo de elemento de modelagem na UML (Alhir, Para que um novo estereótipo seja criado é necessário que ocorra uma extensão de algum dos elementos padrão de modelagem existente na UML, essa extensão deve ser realizada por meio de uma dependência com a marca stereotype que estenderá uma das metaclasses existentes na UML. Na Figura 1.6 são mostrados dois exemplos de criação de estereótipos, no qual, é criado um estereótipo Projeto a partir de uma extensão do metaobjeto Classe, e também um estereótipo Feito por a partir de uma extensão do metaobjeto Associação. Os metaobjetos Classe e Associação são parte da UML padrão. <<metaclasse>> Classe <<metaclasse>> Associação <<estereótipo>> <<estereótipo>> <<estereótipo>> Projeto <<estereótipo>> Feito por Figura 1.6 Definindo Estereótipos (Adaptado de Alhir, 2003)

37 36 Para aplicar um estereótipo criado, devem-se usar os novos elementos com seu novo tipo acima de seu nome. Na Figura 1.7 é mostrado um exemplo de aplicação dos estereótipos criados na figura anterior, no qual, se cria os novos objetos Projeto de Desenvolvimento e Projeto de Infraestrutura que são instâncias do novo metaobjeto Projeto criado anteriormente. Nesse mesmo exemplo nota-se também as associações Feito por, que são instâncias do novo metaobjeto Feito por criado anteriormente. O Valor Atribuído é outro elemento das extensões UML, e estende as propriedades dos elementos padrão da UML permitindo que novas propriedades sejam adicionadas. Com isso é possível inserir novas informações às existentes no metamodelo da UML (Booch et al., 2000). Os valores atribuídos podem ser adicionados a qualquer elemento do modelo. Valores atribuídos são expressos na forma nome=valor. Exemplo: Ocorrência=2. Em alguns locais do diagrama eles podem aparecer entre chaves, exemplo: {Ocorrência=2} (Pender, 2003). <<Projeto>> Projeto de Desenvolvimento <<Projeto>> Projeto de Infraestrutura <<Feito por>> <<Feito por>> Ambiente de Desenvolvimento Ambiente de Distribuição Figura 1.7 Aplicando Estereótipos no diagrama de classes (Adaptado de Alhir, 2003) O último elemento das extensões UML é a Restrição. As restrições são consideradas regras para um elemento do modelo, que são aplicadas a todo elemento em que os estereótipos são aplicados. Na UML as restrições são definidas como textos que podem ser expressos em OCL, por meio de pseudo-linguagens, com linguagens de programação (por exemplo, C# ou C++) ou qualquer outro tipo de linguagem. Na Figura 1.8 é mostrado um exemplo de extensão do metamodelo com restrições. Nessa figura a metaclasse Projeto é uma extensão da metaclasse Classe. Nessa extensão são adicionados alguns atributos não existentes na metaclasse original, como o atributo Data

38 37 Início. Quando essa metaclasse estendida for instanciada em um modelo, esses atributos deverão receber valores, e a restrição estabelecida deverá ser respeitada. <<metaclasse>> Classe <<metaclasse>> Associação <<estereótipo>> <<estereótipo>> <<estereótipo>> Projeto Data Início: String, Data Término: String, {A Data Término deve ser igual ou maior que a Data Início} <<estereótipo>> Feito por {Descrição: String} Figura 1.8 Estereótipos, valores atribuídos e restrições (adaptada de Alhir, 2003) 1.3. Programação Orientada a Aspectos Em sistemas de software em geral, pode-se encontrar dois tipos de interesses ou funcionalidades denominados de base e transversais. 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, uma vez que sua implementação não pode ser acomodada numa única classe do software. O espalhamento ocorre quando o código de um determinado interesse fica espalhado pelos módulos que compõem o interesse-base do software. O entrelaçamento ocorre quando o código de um interesse encontra-se misturado com o código de interesses-base dentro de um mesmo módulo, ou classe, do software. Vale ressaltar que a implementação de uma regra de negócio pode envolver tanto interesses-base quanto transversais. Nesse sentido, a programação orientada a aspectos (POA) tem como objetivo modularizar mais adequadamente os interesses que são transversais, resultando em melhores níveis de reúso e manutenção.

39 38 A implementação dos aspectos fornece subsídio à Programação Orientada a Objetos (POO) para tratar os interesses transversais por meio da decomposição funcional da classe (Elrad et al., 2001a). Os aspectos consistem em características estruturais e/ou comportamentais que são projetadas separadamente e adicionadas em diversas partes do sistema por meio da definição de pontos do programa em que esses aspectos podem afetar. Dessa forma, a combinação dos interesses transversais, implementados nos aspectos, com os interesses-base de cada classe afetada faz com que sejam atingidas as propriedades pretendidas, porém, sem comprometer a coesão de cada módulo. A POA, portanto, não visa a substituir o paradigma orientado a objetos, mas complementá-lo com uma nova visão, tentando assim deixar seu desenvolvimento mais claro e eficiente. Existem diversas linguagens que apóiam a POA, entretanto neste trabalho apenas a Linguagem AspectJ será discutida porque é a linguagem que será usada para a condução do projeto. A Linguagem AspectJ está baseada numa nova construção chamada Aspecto (aspect). Os Aspectos são os módulos responsáveis por toda a implementação transversal, e podem conter métodos, atributos, construtores, conjuntos de junção (pointcuts) e adendos (advices) (Kiczales et al., 2001). Assim, as novas construções da Linguagem AspectJ resumem-se em pontos de junção (joinpoints), conjuntos de junção, adendos, construções para afetar estaticamente a estrutura das classes do programa e os aspectos. No Apêndice A desta monografia encontram-se os fundamentos teóricos da POA, bem como a exemplificação de cada nova construção desse paradigma e no Anexo A encontra-se todo o código do exemplo que é utilizado nesta subseção. A seguir, são explicados os novos construtores da POA por meio da implementação de uma regra de negócio. Na Figura 1.9 é mostrada a implementação de uma regra de negócio que dá uma advertência sobre o custo de uma transação bancária a cada vez que o saldo da conta ficar negativo. Esse exemplo é utilizado para explicar as novas construções fornecidas pela POA. Na Linha 2 do exemplo é criado um aspecto por meio da nova construção aspect, esse novo aspecto é nomeado como ataxajuros e é o responsável pela implementação da regra de negócio supra citada. Nas Linhas 4, 6, 10 e 14 são implementadas construções para afetar estaticamente a estrutura da classe Conta. Essas modificações permitem alterar estaticamente a estrutura de

40 39 uma classe por meio de declarações intertipos (intertypes). Na Linha 4 é adicionado um novo atributo do tipo float nomeado TaxaJuros. O objetivo desse atributo é armazenar o percentual de taxa de juros cobrado pela instituição bancária quando o saldo da conta estiver negativo. Na Linha 6 é adicionado um novo método, nomeado gettaxajuros(), cuja função é retornar o percentual da taxa de juros da conta, que está armazenado no atributo TaxaJuros. Na Linha 10 é adicionado também um novo método nomeado settaxajuros(), cuja função é atribuir um novo percentual de taxa de juros ao atributo TaxaJuros. Por fim, na Linha 14, é adicionado um novo construtor à classe Conta, esse construtor, diferentemente do construtor original da classe, recebe como parâmetros a identificação da conta e a taxa de juros cobrada pela instituição, e atribui essa taxa ao atributo TaxaJuros, por meio do método settaxajuros(). Figura 1.9 Exemplo de um aspecto implementado em AspectJ Na Linha 20 é definido um novo conjunto de junção nomeado AvisoSaldo(). Nele é utilizado o designador call que permite interceptar os pontos de junção correspondentes à chamada de métodos. Esse designador utiliza-se de uma regra genérica para definir quais chamadas de métodos formarão o conjunto de pontos de junção que serão afetados, nesse exemplo a regra utilizada é: * Conta+.mostraSaldo(..). Essa regra

41 40 irá capturar as chamadas do método mostrasaldo(), da Classe Conta e de todas as suas especializações, uma vez que utiliza a notação coringa + após o nome da classe, com qualquer tipo de parâmetro, devido ao uso de notação coringa.. na definição dos parâmetros, e que retorne qualquer tipo de dado, uma vez que no lugar do tipo do retorno foi utilizado a notação coringa *. Na Linha 22 é criado o adendo relativo ao conjunto de junção estabelecido na Linha 20. Esse adendo é do tipo after, o que significa que ele irá interceptar a chamada dos métodos, estabelecidos na regra genérica do conjunto de junção, após sua computação ser realizada. Nas Linhas 23 a 28 estão os códigos que serão executados em cada ponto de junção capturado Considerações Finais Neste capítulo foram abordados os conceitos relacionados às RNs, UML e à programação orientada a aspectos. Um fato notado é a ausência de um padrão sobre a definição, classificação e representação das RNs, contudo, existem esforços nessa direção como o Business Rules Group e a OMG. Nota-se também que, embora exista um esforço no sentido de alinhar o conceito de RNs com o desenvolvimento de software, isso ainda não é uma realidade. Dessa forma, abre-se um importante nicho de pesquisa a ser explorado. No próximo capítulo serão abordados os trabalhos relacionados a este, detalhando assim, os esforços de pesquisa que focam esse objetivo.

42 CAPÍTULO 2 TRABALHOS RELACIONADOS 41 Nesta seção são apresentados trabalhos que de alguma forma buscam uma integração das RNs com a engenharia de software. Recentemente diversos autores buscaram essa integração, porém de formas diferentes, alguns descreveram a estrutura do desenvolvimento de software com as RNs, outros forneceram mecanismos que permitem que as RNs atuem no software em tempo de execução, sem terem feito parte do seu desenvolvimento. Outros ainda apresentam soluções para a integração das RNs com o núcleo do software buscando cumprir os princípios para a implementação de RNs. Diante desse cenário, neste capítulo busca-se delinear as iniciativas que mais se aproximam da proposta presente neste trabalho, mostrando assim como este se enquadra no cenário atual, que é moldado pelas diversas linhas de pesquisa existentes. Todavia vale ressaltar que o objetivo principal da abordagem proposta neste trabalho é fornecer mecanismos para que o engenheiro de software consiga identificar, classificar e projetar as RNs, favorecendo a modularização e o rastreamento, o que os diferencia dos demais trabalhos aqui apresentados. Na Seção 2.1 é apresentado o conceito de desenvolvimento de software com o gerenciamento das RNs, formando assim uma base para a integração das RNs com o software em desenvolvimento. Na Seção 2.2 são discutidos os softwares que fornecem um gerenciamento das RNs, permitindo que elas sejam acopladas ao software já desenvolvido. Na Seção 2.3 são mostrados os trabalhos que defendem o uso de POA para a implementação das RNs. E na Seção 2.4 são feitas as considerações sobre esse capítulo Gerenciamento de Regras de Negócio 4 Os autores defendem uma estrutura de desenvolvimento de software na qual RNs teriam um papel fundamental. Essa estrutura visa estabelecer uma ligação entre os negócios de uma organização e seu respectivo sistema de informação, uma vez que esses sistemas são sensíveis às mudanças dos processos de negócio. A forma encontrada para que essa ligação seja estabelecida foi uma proposta de gerenciamento das RNs. Esse gerenciamento consiste no controle dos artefatos que implementam as RNs, uma vez que os autores entendem que as 4 A escrita desta seção é baseada no trabalho de Bajec e Krisper (2004)

43 42 RNs podem ser implementadas de diferentes formas (gatilhos de banco de dados, procedimentos armazenados, componentes de camada de negócio, etc), o que torna necessário um controle cuja abrangência se estenda desde o requisito que as originou, até sua implementação, possibilitando um controle de todas as implicações que envolvem o suporte do software às mudanças do negócio. Dessa forma, foi proposto um cenário definindo as principais atividades e papéis necessários ao gerenciamento das RNs para toda a organização, como é mostrado na Figura 2.1. Nesse cenário são descritas as atividades dedicadas ao gerenciamento das regras de negócio (Business Rules Management) e ao desenvolvimento do sistema de informação (IS Development). O objetivo desse cenário é ilustrar o conjunto de tarefas necessárias ao gerenciamento das RNs e seu envolvimento com os sistemas de informação. Figura 2.1 O cenário da modelagem de regras de negócio (Bajec e Krisper, 2004) Para o contexto explorado nesta dissertação, as atividades relevantes são as que estão relacionadas com o desenvolvimento do sistema de informação (IS Development), sendo elas: BR Acquisition: considerando que as RNs representam um importante subconjunto dos requisitos e que são adquiridas juntamente com os demais requisitos do software, o objetivo dessa atividade é tornar a aquisição das

44 43 regras um processo mais sistemático e garantir que todas as regras sejam adquiridas. Essa tarefa considera como uma relevante fonte de RNs as regras previamente capturadas na modelagem do negócio (Enterprise Modeling) ou no desenvolvimento de outros softwares, que estão devidamente armazenas em um repositório e disponíveis para análises mais detalhadas. BR Analysis and Classification: O propósito dessa atividade é garantir que as regras sejam atômicas, classificá-las em categorias e documentá-las com base em um gabarito (template) definido para cada categoria de regras. A descrição das regras deve ocorrer de maneira formal, ou semi-formal, com o uso de linguagens de regras (rule language) pré-definidas, tal como OCL, por exemplo. BR Consistency Validation: Essa tarefa tem por objetivo garantir que o conjunto completo das RNs inclua somente regras que sejam consistentes, que não sejam conflitantes entre si. BR Modeling: o objetivo dessa atividade é modelar as regras de negócio, com alguma forma de representação gráfica para propiciar aos desenvolvedores do software um melhor entendimento sobre elas. BR Implementation: o objetivo dessa atividade é propiciar ao repositório das RNs que a informação sobre onde e como as regras foram implementadas seja capturada. Além dessas atividades que compõem o desenvolvimento de sistemas de informação, existe outra tarefa relevante, que é a BR maintenance and monitoring, cujo objetivo é gerenciar a manutenção das RNs constantes no software, isso é realizado por meio de tarefas de controle de mudanças, controle de versões e controle de impacto. Essas atividades buscam estabelecer e manter a ligação entre o cenário de negócios e o sistema de informação que lhe oferece suporte. O objetivo dos autores, nesse trabalho, é mostrar a importância da existência de um amplo modelo de negócio, que resulta em um repositório documental de regras de negócio. Esse repositório tem o objetivo de apoiar o gerenciamento dessas regras, bem como os efeitos de suas mudanças. Além disso, algumas regras desse repositório são genéricas e podem ser reusadas em outros contextos. Entretanto, os autores propõem uma implementação dessas regras sem que um estilo de modelagem e implementação seja seguido. Isso faz com que, embora as regras e seus artefatos possam ser gerenciados, as RNs continuem inseridas no

45 44 código funcional do software, não apoiando completamente os 4 (quatro) princípios de implementação das RNs (separação, rastreamento, exteriorização e posicionamento), embora nesse ambiente o rastreamento das regras seja possível. Também não é sugerido qualquer padrão de integração entre as RNs, a modelagem e a implementação do software. Dessa forma, somente as definições das regras genéricas é que podem ser reusadas, uma vez que elas não são implementadas genericamente. Assim, percebe-se que o trabalho em questão propõe um amplo cenário de desenvolvimento de software, no qual as RNs são devidamente consideradas. Porém, isso ocorre de uma forma conceitual, sem que as atividades sejam detalhadas, já que o principal objetivo do trabalho é estabelecer uma ligação clara entre as RNs na engenharia de software e suas fontes na modelagem de negócio. Devido a isso, os autores não propõem uma metodologia ou um processo que apóie o projeto dessas regras no desenvolvimento do software. Ou seja, o gerenciamento proposto é obtido com base na implementação das RNs de maneira usual, com as regras espalhadas pelos artefatos de software. Os autores ainda citam que não existe atualmente uma metodologia que apóie o projeto das RNs, e assim consideram que a implementação dessas regras pode ocorrer de várias formas. Além disso, é citado no trabalho que no desenvolvimento orientado a objetos não existe um consenso sobre onde acomodar as RNs nos modelos existentes, e nenhuma proposta que mude isso foi encontrada. Sendo assim, a abordagem proposta nesta dissertação tem como objetivo complementar o cenário proposto pelos autores, fornecendo técnicas e artefatos que apóiem a identificação das RNs bem como seu projeto, propondo um modelo de projeto dessas regras, e critérios para sua identificação. Nesse ponto o trabalho de Bajec e Krisper (2004) também difere da abordagem proposta, já que os autores consideraram que as RNs começam a ser obtidas nas atividades de modelagem de negócio (Enterprise Modeling), e são completadas com a análise dos requisitos do software, sem que seja determinado como exatamente isso ocorre, ao passo que na abordagem aqui proposta as RNs são obtidas diretamente nos requisitos do software, com o apoio de critérios específicos para isso Sistemas Gerenciadores de Regras de Negócio Os Sistemas Gerenciadores de Regras de Negócio (SGRN) (BRMS Business Rules Management System) são softwares que fornecem um ambiente que possibilita que RNs sejam criadas, gerenciadas e distribuídas. De acordo com Ilog (2008), adicionalmente são oferecidos

46 45 modelos de objetos de negócio (BOM Business Object Model) a partir dos quais os termos das RNs são mapeados com elementos de software (métodos e objetos), o que permite que os objetos e seus métodos sejam traduzidos para fragmentos de linguagem natural. Assim, por exemplo, o objeto Cliente pode ser associado ao fragmento cliente e o método obterlimitecrédito pode ser associado ao fragmento limite de crédito de, o que permitiria a construção da seguinte regra: Se o limite de credito de cliente for maior que 0 Então..., onde o texto em negrito são elementos do Rule Builder. A execução das regras criadas ocorre por meio de Enterprise Java Beans permitindo que uma RN manipule objetos contidos na memória (Ilog, 2008). O SGRN mais conhecido atualmente é JRules. Na Figura 2.2 é mostrado um dos poucos exemplos padrões disponibilizados pela empresa ilog, fabricante do jrules, nesse exemplo a RN descrita no primeiro quadro é ligada ao BOM, com seu respectivo vocabulário, mostrado no segundo quadro, gerando assim um novo fato nomeado creditscore Figura Exemplo da utilização do Business Object Model (Ilog, 2008). O conceito desse tipo de software é que as RNs possuem um ciclo de vida distinto do software, ou seja, as RNs podem ser criadas e associadas ao software desenvolvido, e já em uso pela empresa, como mostrado na Figura 2.3. Embora essa estrutura possibilite uma grande flexibilidade às RNs, isso ocorre com inconsciência no software desenvolvido, impossibilitando assim que regras mais complexas, como as de derivação, interajam com os mecanismos criados no software, uma vez que tais regras não existem durante o

47 46 desenvolvimento do software, o que impede, por exemplo, que a classe que implementa determinado objeto tenha consciência sobre sua origem. Outro problema dessa abordagem diz respeito ao fato das RNs não serem parte dos requisitos iniciais do software, o que não garante que todos os elementos necessários às regras estejam presentes no software. Isso fere o conceito de que RNs são tipos de requisitos de um software a ser construído (Ross, 2003). Além disso, não foram encontrados estudos que analisassem como fica o cenário de manutenção do software, uma vez que as alterações na estrutura do software poderiam influenciar as RNs acopladas a ele, lembrando que tais regras não são artefatos de software, e não estão disponíveis no desenvolvimento do software. Figura Ciclos de vida do Software e das Regras de Negócio (Ilog, 2008) Dessa forma, o trabalho apresentado nessa dissertação diferencia-se dos softwares SGRN (Ilog, 2008) pelo fato de considerar as RNs primeiramente como requisitos do software, e posteriormente como parte do software desenvolvido, e não mecanismos que podem atuar de forma independente sobre o software em produção. Evitando assim os problemas apontados no parágrafo anterior.

48 2.3. Regras de Negócio e Aspectos 47 Para Cibrán et al. (2003) a implementação das regras de negócio com código procedimental, orientado a objetos, ou por meio de abordagens de banco de dados prejudica os princípios de implementação das RNs, como defendido por Von Halle (2002). Cibrán et al. (2003) mencionam também que a implementação de alguns tipos de RNs com orientação a objetos faz com que o código responsável pela conexão do núcleo do software com as regras, fique espalhado por diversas classes. Esses tipos de RNs envolvem interesses transversais e são adequadas de serem implementadas com orientação a aspectos. Dessa forma, Cibrán et al. (2003) apresentam uma proposta de conexão das RNs ao núcleo do software por meio de programação orientada a aspectos. Todavia, o referido trabalho tem enfoque apenas na implementação do software, isto é, não é descrita qualquer técnica ou metodologia para que essas regras possam ser modeladas durante todo o ciclo de vida do desenvolvimento, assim como é proposto na abordagem proposta nesta dissertação. Outro trabalho que mostra a viabilidade da conexão de RNs com o núcleo do software por meio de programação orientada a aspectos é o de Camargo e Masiero (2005). Nesse trabalho os autores mostram a implementação genérica de RNs na forma de Frameworks Transversais (FTs). Frameworks Transversais são um tipo especial de framework orientado a aspecto que encapsula apenas um determinado interesse transversal. Esses FTs devem ser instanciados e acoplados a um código-base por meio de mecanismos abstratos fornecidos pela POA. No trabalho de Camargo e Masiero (2005) é mostrado um FT de regra de negócio. Esse FT encapsula de forma genérica uma regra de negócio que pode ser instanciada de várias formas para diferentes aplicações. Esse tipo de implementação favorece o reúso dessas regras e facilita sua integração com o software por meio dos mecanismos fornecidos pela POA. Entretanto, da mesma forma que o trabalho citado anteriormente (Cibrán et al., 2003), o acoplamento do framework ao núcleo do software ocorre apenas na implementação, sem qualquer técnica ou metodologia para a modelagem durante todo o ciclo de vida do desenvolvimento de software Considerações Finais Os trabalhos apresentados neste capítulo indicam a relevância das RNs no processo

49 48 de desenvolvimento de software. O trabalho apresentado na Seção 2.1 mostra a necessidade da integração das regras de negócio ao processo de desenvolvimento de software. Mas, apesar de indicar a importância dessa integração por meio da modelagem das regras no paradigma orientado a objetos, ele também mostra que esse conceito encontra-se num estágio embrionário. Na Seção 2.2 foram discutidos softwares que possuem um mecanismo que permite o acoplamento das RNs a um software pré-desenvolvido, permitindo ainda o gerenciamento dessas regras. Isso, por um lado, é bastante vantajoso já que possibilita aos especialistas de negócio estabelecer e gerenciar as RNs da companhia, de forma independente do ciclo de vida de desenvolvimento do software. Todavia isso apresenta algumas limitações, já que o desenvolvimento do software ocorre de forma independente das RNs que irão atuar nele. Sendo assim, não existe uma garantia de que todos os elementos necessários à regra vão existir no software. Na Seção 2.3 foram apresentados os trabalhos que mostram a viabilidade da implementação das RNs por meio da programação orientada a aspectos. Contudo, isso ocorreu apenas na implementação do software, não sendo encontrado nada que mostrasse a viabilidade dessa abordagem na modelagem do software. Assim, os trabalhos apresentados nessa seção confirmam a necessidade de integração entre RNs e desenvolvimento de software, viabilizando essa abordagem com o uso da programação orientada a aspectos.

50 CAPÍTULO 3 PROJETO DE SOFTWARE COM REGRAS DE NEGÓCIO 49 Neste capitulo é apresentada a abordagem proposta neste trabalho, cujo objetivo é fornecer meios para que as RNs possam ser implementadas de forma separada e independente do núcleo do software, e assim atender aos princípios de projetos exigidos pelas RNs (Seção 1.1.3), que são: Separação, Rastreamento, Exteriorização e Posicionamento. Para atender a esse objetivo é necessário fornecer meios para que o engenheiro de software possa: Identificar as RNs nos requisitos do software, classificá-las, modelá-las juntamente com a parte base do software, definir o paradigma de projeto das RNs e projetá-las juntamente com a parte base do software, porém de forma desacoplada e independente. Dessa forma, a abordagem proposta consiste na adaptação do ciclo de vida de desenvolvimento de software de forma a incluir novas atividades e artefatos para apoiar o tratamento das RNs. A adaptação também foi utilizada como base para uma extensão do Processo Unificado (PU) (Jacobson et al., 1999), com o objetivo de apoiar o processo de desenvolvimento de softwares com RNs. Na Seção 3.1 é descrita uma visão geral da abordagem proposta neste trabalho; na Seção 3.2 é apresentada a extensão do Processo Unificado (PU); na Seção 3.3 é abordada a rastreabilidade resultante da abordagem; e na Seção 3.4 são apresentadas as considerações finais desse capítulo Visão Geral da Abordagem A abordagem proposta envolve quatro etapas: a elaboração de casos de uso com um gabarito proposto, a identificação das RNs nos requisitos do software, a identificação das RNs candidatas a aspectos e o projeto das RNs. Na Figura 3.1 são mostradas adaptações realizadas no modelo clássico de desenvolvimento de software, para atender a abordagem proposta. Na Figura 3.1 os quadros pontilhados representam os novos artefatos propostos, e os retângulos vazios adicionados às etapas do ciclo de vida clássico representam as novas atividades necessárias à proposta deste trabalho. O objetivo de inicialmente ilustrar as mudanças no processo utilizando-se o ciclo de vida clássico de desenvolvimento de software é possibilitar uma visão geral das intervenções

51 50 nas atividades de desenvolvimento de software. Todavia para a aplicação dessas atividades é sugerido um processo de desenvolvimento, que é proposto como uma extensão do PU com as mudanças devidamente aplicadas às suas atividades. Essa extensão é detalhada na próxima seção. Registrar casos de uso com gabarito Documentos de Requisitos Identificar RNs Elicitação/ Coleta de Requisitos Gabarito para registro dos casos de uso Análise Lista de Regras Projeto Projetar RN Implementação - Atividades - Artefatos - Descrição P de Atividade r o j e t a r R Implantação N Classificar RNs Identificar RNs candidatas a aspectos Figura Influência da abordagem no ciclo de vida de desenvolvimento de software 3.2. Extensão do Processo Unificado O PU é composto por diversas disciplinas distribuídas em quatro fases: Concepção, Elaboração, Construção e Transição. A realização dessas disciplinas ocorre em todas as fases do processo, porém com ênfase diferente de acordo com a evolução do processo. A extensão proposta neste trabalho utiliza essa mesma estrutura do PU, porém com o objetivo de apoiar de forma explícita o tratamento de RNs. A base da extensão é a criação de novas atividades ao longo das disciplinas do PU. As atividades consideradas nessa extensão iniciam-se na disciplina análise, já que a abordagem proposta considera que os requisitos já estejam definidos, não envolvendo portanto, a disciplina requisitos. Também foram adaptadas algumas das atividades já existentes para que pudessem oferecer um tratamento específico para as RNs. Na Tabela 3.1 são mostradas as atividades que compõem a extensão do PU para RNs. As atividades em negrito são novas, as atividades

52 51 em itálico não são influenciadas pela abordagem, porém constam na tabela para enfatizar a seqüência de atividades do PU, as demais possuem algum tipo de adaptação proposta nesta extensão. O PU originalmente é um processo iterativo e incremental, e a extensão proposta em nada compromete essas características originais do PU, já que as novas atividades propostas, bem como as atividades já existentes e que foram modificadas, atuam como um complemento às demais, atuando de forma que garanta a correta manipulação das RNs. Tabela Atividades da extensão do PU proposta Atividades da Disciplina Análise Identificar e Registrar Casos de Uso Essenciais Documentar casos de uso com gabarito Classificar e Registrar Regras de Negócio Refinar Diagramas de Casos de uso Refinar Visão do Diagrama de Casos de Uso para Regras de Negócio Criar Diagrama de Seqüência de Sistema Definir Contratos das Operações do Sistema Desenvolver Modelo Conceitual Atividades da Disciplina Projeto Definir Paradigma de Projeto das Regras Desenvolver Diagramas de Interação Desenvolver Modelo de Classes do Projeto Projetar Regras de Negócio Projetar Modelo de Dados Atividades da Disciplina Implementação Implementar Classes do Domínio Implementar Banco de Dados Implementar Regras de Negócio Implementar Classes Controladoras Implementar Interfaces Testar Disciplina análise O objetivo principal da análise é realizar uma investigação do problema e dos requisitos (Larman, 2007). Dessa forma, o objetivo dessa fase é refinar os casos de uso definidos para a iteração atual, descobrir novos requisitos e elaborar o modelo de domínio.

53 52 Nessa disciplina concentra-se o maior volume de trabalho da abordagem, uma vez que em suas atividades inclui a tarefa de documentar os casos de uso com o gabarito proposto, além da identificação, classificação e registro das RNs. Sendo assim, a disciplina análise é o grande foco da abordagem, pois ela fornece toda a base para o restante do desenvolvimento do software com RNs. Nas próximas subseções serão detalhadas as atividades que compõem essa disciplina, e que foram influenciadas pela abordagem Atividade: Identificar e Registrar Casos de Uso Essenciais A identificação e registro dos casos de uso devem ocorrer da maneira usual, como sugere originalmente o PU. Todavia após essa atividade será necessária a documentação dos casos de uso com o gabarito proposto na abordagem. Sendo assim, o engenheiro de software pode optar por um registro básico do caso de uso, com apoio de algum gabarito usual, e na próxima atividade a documentação completa atendendo as exigências da abordagem, ou o registro dos casos de uso já no gabarito sugerido, porém apenas com as informações básicas sobre cada caso de uso, para que na próxima atividade a documentação seja completada com as informações necessárias à abordagem Atividade: Documentar Casos de Uso com Gabarito A identificação de RNs durante a análise dos requisitos deve ser apoiada por meio do uso de um gabarito (template) para a documentação dos casos de uso. Essa documentação deve ocorrer após a identificação e registro dos casos de uso, o que ocorre na atividade anterior. O PU já sugere a utilização de gabaritos para o registro dos casos de uso, sendo assim, a proposta da abordagem é a utilização de um gabarito próprio aos seus objetivos. Existem diversos tipos de gabaritos propostos na literatura, entretanto para este trabalho será considerado o gabarito mostrado na Figura 3.2, que é uma adaptação do gabarito proposto por Jacobson e Ng (2004). 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 relacionadas com RNs e que são oriundas do documento de requisitos. Essas informações podem, posteriormente, tornarem-se RNs. A adaptação realizada consistiu em adicionar a última seção (Gatilhos) no gabarito

54 53 original, e incluir algumas outras informações nas seções Fluxo Alternativo, Pré-Condições e Pós-Condições. Caso de Uso: Descrição: Fluxo Principal: Seq Descrição Fluxos Alternativos: Seq Origem Tipo Condição Ação Pré-Condições: Origem Condição Pós-Condições: Origem Condição Gatilhos: Tipo de Gatilho Diretriz Habilitador Derivação Caso de Uso Ação Figura Gabarito para registro e documentação dos casos de uso O documento de requisitos que será utilizado como base para o preenchimento do gabarito deve descrever de forma satisfatória as funcionalidades que se espera que o software forneça. Além disso, espera-se também que esse documento descreva minuciosamente o comportamento do software. Uma vez que as RNs são responsáveis por delinear tal comportamento, com base nas políticas e normas organizacionais. As seções adicionadas ou modificadas, pela abordagem proposta, estão detalhadas nas próximas subseções. a) Fluxo Alternativo Os fluxos alternativos de um caso de uso têm por objetivo descrever as possíveis variações do fluxo principal (Jacobson e Ng, 2004). Dessa forma, no contexto da abordagem

55 54 proposta, espera-se que estejam descritas, nesses fluxos, as variações de comportamento que devem ser manipuladas pelo caso de uso. Além disso, espera-se também que estejam descritos os comportamentos adicionais que venham a ocorrer em situações específicas de ambientes de negócio, tais como diretrizes relativas a políticas empresariais, restrições que venham a ocorrer em função de políticas, leis e normas empresariais, ou ainda derivações que satisfaçam regras empresariais pré-definidas. Esses comportamentos não fazem parte do fluxo principal em conseqüência da sua natureza de negócio, que determina como o software deve funcionar, e não o que ele deve fazer (Date, 2000). Sendo assim esses comportamentos visam determinar alternativas e regras às funcionalidades bases descritas no fluxo principal de eventos, devendo estar registrados na seção de fluxo alternativo. Os fluxos alternativos que representam eventos de negócio possuem uma característica própria que é ser acionado a partir de uma condição. Para o preenchimento dessa seção do gabarito, é necessário que o engenheiro de software identifique eventos de negócio que compõem o fluxo alternativo do caso de uso, o que deve ser feito com base nos documentos de requisitos. Eventos de negócio, no contexto deste trabalho, são comportamentos que refletem necessidades específicas do negócio em si. Dessa forma, para que os fluxos alternativos possam ser registrados de forma adequada, todo comportamento adicional do caso de uso, que dá origem aos fluxos alternativos, que for identificado deve ser analisado com o objetivo de determinar sua origem. O resultado dessa análise na origem do fluxo alternativo deve ser informado na coluna Origem dessa seção do gabarito. A origem pode ser: Sistema: São todos os comportamentos alternativos que tem por objetivo o cumprimento de uma necessidade do software, tais como: garantia de integridade dos dados, validações de tipos de dados etc. Negócio: São comportamentos alternativos impostos por fatores de negócio, tais como: acionamento de eventos de negócio, diretrizes informativas de políticas da empresa etc. Esses comportamentos representam RNs. A determinação da origem dos fluxos alternativos (cujo resultado será a base para o preenchimento da coluna origem da seção do gabarito) está relacionada com a identificação de RNs, ou seja, os fluxos alternativos cuja origem seja de negócio se tornarão RNs nas próximas atividades da abordagem. Para o escopo desse trabalho, será focada a identificação de RNs nos requisitos do software. Para isso são propostos alguns critérios que tem por objetivo apoiar o engenheiro de software na tarefa de identificar as RNs na especificação dos

56 55 requisitos do software. O objetivo desses critérios é fornecer um meio adicional à identificação de RNs, com isso o engenheiro de software pode submeter cada fluxo alternativo identificado aos critérios propostos abaixo, e seu resultado será uma diretriz essencial na identificação de comportamentos de negócio. Os critérios são: Identificação de decisões: As RNs geralmente estão acompanhadas de decisões (Von Halle, 2002). Isso ocorre pelo fato das RNs definirem como o software funciona. Dessa forma, a identificação de decisões que envolvem políticas da companhia, ou demais características de uma RN, é um caminho para sua identificação nos requisitos do software; Fluxo de eventos: Fluxos de eventos são seqüências de ações que o software deve implementar para satisfazer uma política da empresa, o que pode ser independente de decisões. A identificação dos fluxos de eventos nos requisitos do software possibilita a obtenção de alguns tipos de RNs, identificando-se essas ações têm-se as RNs que não são precedidas por condições; Essencialidade: As RNs definem como um evento de negócio (no caso, uma funcionalidade do software) ocorre e suas particularidades. Em geral, uma RN sempre é essencial ao funcionamento do sistema, uma vez que ela esteja definida no documento de requisitos, porém a questão é se ela é essencial ao funcionamento genérico do caso de uso. Como exemplo, pode-se citar uma RN que verifica se a duração da estadia de uma reserva de acomodação, num sistema de controle hoteleiro, não excedeu ao limite estabelecido. Essa RN é essencial ao sistema hoteleiro em questão, mas não é essencial ao controle de reserva de qualquer sistema hoteleiro. Assim, se a RN for essencial sua separação poderia comprometer o sistema, caso essa RN fosse desativada futuramente. Portanto, sua separação causaria uma falsa impressão de independência e desacoplamento, o que pode ser prejudicial ao sistema. Nesse caso, provavelmente ela não é uma RN. Esse critério foi adaptado de Camargo (2006). Os critérios propostos não são independentes, ou seja, eles devem sempre ser aplicados em conjunto, uma vez que o terceiro critério é uma validação das RNs identificadas pelos dois primeiros critérios. A aplicação dos critérios propostos deve sempre ser acompanhada da análise crítica do engenheiro de software, pois existem certas funcionalidades que podem satisfazer aos

57 56 critérios, todavia podem não ser RNs por não refletirem políticas da empresa e não ter qualquer outra característica de uma RN. Para a correta identificação da origem dos fluxos alternativos deve-se também tomar como base, além dos critérios propostos, o fundamento teórico e a vasta disponibilidade de exemplos existentes sobre RNs. Essas informações podem ser encontradas em Ross (2003) e Von Halle (2002). Com a origem devidamente preenchida, caso seu conteúdo seja Negócio o campo Tipo deve ser preenchido, caso contrário deverá permanecer vazio, uma vez que esse campo não tem significado para fluxos alternativos convencionais. Essa informação deve refletir o tipo de comportamento de negócio que o fluxo alternativo em questão irá executar. Os comportamentos identificados e aceitos neste trabalho são: Diretriz: expressam uma advertência sobre uma circunstância de negócio que faz com que alguma ação humana - ou de qualquer outra natureza que esteja fora do escopo do software - seja executada sem, contudo, restringir a execução do software. Exemplo: Caso o cliente possua duplicatas vencidas e não pagas o usuário deverá ser comunicado; Habilitador: são mecanismos que verificam uma determinada condição e caso ela seja verdadeira inicia uma nova ação no software. Exemplo: Caso o usuário possua status de gerente a alteração dos preços de venda deverá ser liberada; Derivação: resulta na criação de um novo trecho de informação que, em termos de banco de dados, pode ser uma nova instância de uma entidade, ou uma nova instância de um atributo. Para que a derivação ocorra é necessário que seja implementado o mecanismo de derivação com o mapeamento que será aplicado às informações bases para a extração das informações derivadas. Exemplo: Caso seja o mês de aniversário do cliente o valor do desconto deverá ser 10% do total da venda. A determinação do tipo do fluxo alternativo, que posteriormente será o tipo da RN, é relevante, pois pode apoiar na escolha da forma que essa RN será projetada, uma vez que essa informação designa um dado comportamento para a RN. A próxima etapa para o preenchimento dessa seção do gabarito é a identificação da condição que deve ser cumprida para que o fluxo alternativo em questão seja acionado. A condição de acionamento é algo intrínseco às RNs (Von Halle, 2002), sendo inclusive um mecanismo para sua identificação (como é mostrado na Seção a). Sendo assim, cabe

58 57 ao engenheiro de software identificá-la no enunciado da regra e transcrevê-la ao gabarito. O registro dessa condição pode ocorrer em linguagens mais formais, como OCL, por exemplo, porém em todos os exemplos deste trabalho é utilizada linguagem natural para o registro de tais condições. Por fim, o último campo dessa seção do gabarito é a ação que deverá ser executada caso a condição do fluxo alternativo em questão seja satisfeita. Essa ação deverá ser descrita em linguagem natural e deverá descrever uma ação condizente com a classificação previamente informada no campo Tipo. Para exemplificar o preenchimento dessa seção do gabarito, é mostrada na Tabela 3.2 uma parte do gabarito relativo ao caso de uso Gerar Vendas, que compõe o estudo de caso dessa dissertação. Tabela Exemplo da seção fluxos alternativos b) Pré-Condições As pré-condições de um caso de uso indicam as condições que devem ser satisfeitas para que sua execução possa ser feita adequadamente. Devem constar as restrições que levariam a execução do caso de uso a um estado indefinido. Um caso de uso só pode ser executado se todas as suas pré-condições forem satisfeitas. As pré-condições são formas de se garantir que a execução de um caso de uso ocorrerá de forma consistente, sem ferir princípios ou circunstâncias pré-estabelecidas. A identificação das pré-condições do caso de uso deve ser feita com base nos documentos de requisitos. Toda pré-condição identificada deve ser analisada com o objetivo de identificar sua origem, que pode ser:

59 58 Sistema: São todos os comportamentos alternativos que tem por objetivo o cumprimento de uma necessidade do software, tais como: garantia de integridade dos dados, validações de tipos de dados etc. Negócio: São comportamentos alternativos impostos por fatores de negócio, tais como: acionamento de eventos de negócio, diretrizes informativas de políticas da empresa etc. Esses comportamentos representam RNs. A determinação da origem das pré-condições está relacionada com a identificação de RNs. Por isso ela deve ser feita com base nos critérios propostos na Seção a. O campo Condição deve ser preenchido com a condição que será verificada para determinar se esse caso de uso pode ser executado ou não. Para exemplificar o preenchimento dessa seção do gabarito é mostrada na Tabela 3.3 uma parte do gabarito relativo ao caso de uso Gerar Vendas, que compõe o estudo de caso dessa dissertação. Tabela Exemplo de Pré-Condições c) Pós-Condições Indicam condições que devem ser satisfeitas para que o caso de uso seja concluído com sucesso. Devem constar as condições necessárias para garantir que um caso de uso só poderá ser concluído quando todas as condições de integridade, pré-estabelecidas, forem satisfeitas. A identificação das pós-condições do caso de uso deve ser feito com base nos documentos de requisitos. Toda pós-condição identificada deve ser analisada com o objetivo de identificar sua origem, que pode ser: Sistema: São todos os comportamentos alternativos que tem por objetivo o cumprimento de uma necessidade do software, tais como: garantia de integridade dos dados, validações de tipos de dados etc.

60 59 Negócio: São comportamentos alternativos impostos por fatores de negócio, tais como: acionamento de eventos de negócio, diretrizes informativas de políticas da empresa etc. Esses comportamentos representam RNs. A determinação da origem das pós-condições está relacionada com a identificação de RNs. Por isso ela deve ser feita bom base nos critérios propostos na Seção a. O campo Condição deve ser preenchido com a descrição da checagem que será realizada para validar a pós-condição estabelecida. Para exemplificar o preenchimento dessa seção do gabarito é mostrada na Tabela 3.4 uma parte do gabarito relativo ao caso de uso Gerar Vendas, que compõe o estudo de caso dessa dissertação. Tabela Exemplo de Pós-Condições d) Gatilhos Os Gatilhos são descritos em uma nova seção do gabarito proposto neste trabalho. Gatilhos são procedimentos que devem ser disparados após a execução, com sucesso, de um caso de uso. O disparo dos gatilhos geralmente ocorre mediante uma condição de negócio e deve ser independente do fluxo de execução do caso de uso. Isso diferencia os gatilhos do fluxo alternativo de eventos, uma vez que o fluxo alternativo descreve exceções para o funcionamento do caso de uso em si, enquanto os gatilhos descrevem ações que devem ser executadas após o término do caso de uso em questão. Em outros termos, os gatilhos descrevem complementos ao funcionamento do caso de uso, que geralmente são condicionados a execução de outros casos de uso. Os gatilhos informados nesta seção do gabarito devem representar eventos de negócio. Os demais gatilhos que representem eventos relacionados ao software em si, devem ser modelados da forma convencional, por meio de casos de uso e relacionamentos UML. Os gatilhos são compostos de um mecanismo de acionamento e uma funcionalidade alvo. Esses dois elementos podem estar encapsulados em uma única RN, ou podem ser

61 60 elementos distintos, nesse caso a funcionalidade alvo pode ser uma funcionalidade da parte base do software. O mecanismo de acionamento, quando separado da funcionalidade alvo, deve ser um elemento independente, que inclui a funcionalidade alvo em seu comportamento, e que será modelado como uma RN. É desejável que os mecanismos de acionamento independentes sejam representados como RNs pelo fato de representar uma ação que visa cumprir um comportamento de negócio, e dessa forma, possui as características das RNs (volatilidade, independência, etc) devendo respeitar as características desejáveis para seu projeto. A ação resultante de um gatilho determina o seu tipo. Os tipos de gatilhos identificados e aceitos nesse trabalho são: descreve. Diretriz: expressam uma advertência sobre uma circunstância de negócio que faz com que alguma ação humana ou de qualquer outra natureza que esteja fora do escopo do software, seja executada sem restringir a execução do software; Habilitador: são mecanismos que verificam uma determinada condição e caso ela seja verdadeira inicia uma nova ação no software; Derivação: resulta na criação de um novo trecho de informação que, em termos de banco de dados, pode ser uma nova instância de uma entidade, ou uma nova instância de um atributo. Para que a derivação ocorra é necessária a existência de um mecanismo de derivação com o mapeamento que será aplicado às informações bases para a extração das informações derivadas. Geralmente esse mecanismo de derivação está definido no caso de uso invocado nesse gatilho. O tipo de um gatilho está intrinsecamente relacionado ao tipo de RN que ele A próxima informação constante nessa seção do gabarito é o caso de uso que representa a funcionalidade alvo do gatilho em questão, caso essa funcionalidade esteja separada do mecanismo acionador, o que pode ocorrer por questões de modularização do software, já que o caso de uso alvo do gatilho pode também ser uma funcionalidade base do software. Nesse caso o acionamento dessa funcionalidade representa um evento de negócio, e não a funcionalidade em si. Isso ocorre devido ao fato de que o fluxo de ações do software pode ser determinado ou influenciado por fatores de negócio. E nessas situações podem

62 61 ocorrer gatilhos que não possuem condições para serem executados, uma vez que o próprio fluxo de eventos do software foi influenciado por fatores de negócios. Por fim, a última informação que o engenheiro de software deve fornecer é a ação resultante desse gatilho. Essa ação pode ser a simples invocação do caso de uso alvo, ou ainda pode estar contida nessa ação a condição necessária para que o gatilho seja disparado. Porém essa condição não é obrigatória, o que torna aceitáveis gatilhos que sempre serão disparados, desde que isso ocorra por fatores de negócio, caso contrário a implementação desses gatilhos deverá seguir os mecanismos usuais da engenharia de software. Para exemplificar o preenchimento dessa seção do gabarito é mostrada na Figura 3.3 uma parte do gabarito relativo ao caso de uso Gerar Vendas, que compõe o estudo de caso dessa dissertação. Figura Exemplo de Gatilhos Atividade: Classificar e Registrar Regras de Negócio Essa é uma nova atividade da extensão proposta ao PU. O objetivo dessa atividade é classificar e registrar as RNs. A tarefa de identificar RNs é em grande parte realizada no registro dos casos de uso com o gabarito proposto, na atividade anteriormente descrita. Embora isso não ocorra de forma explícita, a identificação de fluxos alternativos, pré e pós condições e gatilhos de origem de negócio, nada mais é que a identificação de RNs com objetivos específicos. Esse fato facilita a tarefa de identificação das RNs, uma vez que ao focar a identificação em RNs com objetivos específicos reduz-se o domínio dessas regras. Sendo assim, com as regras já descritas nas seções específicas do gabarito a tarefa de classificá-las ocorre por meio de um mapeamento entre as seções do gabarito com o tipo de cada regra. As diretrizes para que esse mapeamento ocorra são mostradas na Tabela 3.5. O mapeamento deve ser executado seguindo-se os critérios constantes na coluna Critério de Identificação (Tabela 3.5). Dessa forma, as RNs serão obtidas de acordo com seu tipo (já que para cada tipo de RN existe um conjunto de critérios de identificação), seguindo-se os critérios estabelecidos obtêm-se o conjunto de regras oriundas de seções do gabarito. Isso

63 62 deve ser feito para todos os casos de uso registrados com o gabarito, tendo como resultado o conjunto de RNs identificadas nos gabaritos e classificadas por essas diretrizes. Essas RNs devem ser documentadas em um artefato específico, chamado Lista de Regras. A classificação das RNs identificadas nos gabaritos ocorre pelo agrupamento das regras de acordo com suas características, ou seja, as RNs quando identificadas nos requisitos recebem uma classificação prévia, seja por meio da seção do gabarito na qual ela é registrada, seja pela identificação de seu tipo (nas seções Fluxos Alternativos e Gatilhos do gabarito). Dessa forma os diversos tipos de RNs que estão distribuídas pelas seções do gabarito devem ser identificadas e agrupadas. Isso é possível pelo fato das seções Pré e Pós-Condições receberem apenas um tipo de regras, e as seções Fluxos Alternativos e Gatilhos possuírem um campo de identificação (Tipo) que representa o tipo de RN registrada. É importante ressaltar que o preenchimento do campo de identificação ocorre com base no conceito de RNs, como apresentado nas Seções a e d. Sendo assim o objetivo dos Critérios de Identificação é orientar onde (seção do gabarito) cada tipo de regra deve ser obtido, e como separar as RNs das funcionalidades pertencentes ao caso de uso em questão. Tipo de RN Restrições Diretrizes Habilitadoras de Ações Derivação Tabela 3.5 Critérios para a classificação das Regras de Negócio Critério de Identificação -Itens informados na seção Pré-Condições ou Pós-Condições, que possuam origem de negócio; -Itens informados na seção Fluxo Alternativo ou na seção Gatilhos. Desde que tenham origem de negócio e sejam do tipo Diretriz. As RNs oriundas da seção Fluxo Alternativo deverão sofrer uma junção da condição de acionamento da RN com sua ação, para que dessa forma, a RN seja transcrita na sua totalidade; -Itens informados na seção Fluxo Alternativo ou na seção Gatilhos. Desde que tenham origem de negócio e sejam do tipo Habilitador. As RNs oriundas da seção Fluxo Alternativo deverão sofrer uma junção da condição de acionamento da RN com sua ação, para que dessa forma, a RN seja transcrita na sua totalidade; -Itens informados na seção Fluxo Alternativo ou na seção Gatilhos. Desde que tenham origem de negócio e sejam do tipo Derivação. As RNs oriundas da seção Fluxo Alternativo deverão sofrer uma junção da condição de acionamento da RN com sua ação, para que dessa forma, a RN seja transcrita na sua totalidade; Na apresentação do PU feito por Larman (2007) já é sugerido um artefato único para registro das RNs, tendo como principal benefício à possibilidade de reúso dessas regras por toda a organização. Todavia esse artefato foi refeito para que pudesse atender às necessidade

64 63 da abordagem proposta nesse trabalho. Um exemplo desse artefato é mostrado na Tabela 3.6 com algumas RNs que foram extraídas do estudo de caso apresentado neste trabalho. Tabela Exemplo do Artefato Lista de Regras Preenchido Regra Tipo Caso de Uso Seção Verificar se o caixa anterior Restrição Abrir Préestá fechado Caixa Condições Caso o cliente possua Diretriz Gerar Fluxo duplicatas a vencer nos Vendas Alternativo próximos 7 dias deverá ser gerado um aviso ao usuário Caso o cliente possua duplicatas a vencer nos próximos 7 dias a pesquisa financeira do cliente deverá ser exibida Caso o cliente tenha duplicatas vencidas e não pagas deverá ser gerada uma advertência para que a situação seja regularizada senão a venda não será aceita Caso o usuário não seja gerente a alteração do preço dos produtos deverá ser bloqueada Caso seja o mês de aniversário do cliente, o desconto deverá ser preenchido com o valor de 5% do total da venda É necessário que o caixa esteja aberto para que uma venda seja registrada, alterada ou excluída. Habilitadora Gerar Fluxo No ato de Vendas Alternativo informar o cliente Diretriz Gerar Fluxo No ato de Vendas Alternativo informar o cliente Habilitadora Gerar Fluxo Na inserção Vendas Alternativo de produtos na venda Derivação Restrição Gerar Fluxo Na Vendas Alternativo informação do valor do desconto Gerar Pré- Vendas Condições Ponto de Id. RN Atuação Inicialização ChecarCaixa Anterior No ato de ChecarDupl informar o AVencer cliente MostrarPesq Financeira AdvertirAtra sos Bloquear Preços GerarDesco ntoaniversa rio Inicialização VerificarCai xaaberto Múlt Parad Ocor igma OA OA OA OA OO OA OA Módulo ChecarCx Anterior ChecaDup lvencer Mostrar PesqFinan ceira VerificaAt raso BloquearP recos ChecaDes cniver Artefato Checagem Checagem Pesquisa Checagem Bloqueio Checagem VerificarC Checagem aixaaberto As colunas do artefato devem ser preenchidas seguindo-se diretrizes, como segue: Regra: Nessa coluna deve constar a própria RN, da forma que foi transcrita do documento de requisitos; Tipo: Deve ser preenchida com o tipo da RN que pode ser obtido seguindo-se as diretrizes apresentadas anteriormente nessa seção; Caso de Uso: Deve ser informado o caso de uso que originou a RN, essa informação é essencial para a obtenção da rastreabilidade; Seção: Nessa coluna deve constar a qual seção do gabarito a RN pertence; Ponto Atuação: Esse campo representa uma informação importante para a abordagem. Nessa coluna deve ser informado qual o ponto, da funcionalidade a ser implementada, que a RN irá influenciar. Essa informação pode ser considerada como um esforço inicial para direcionar o engenheiro de software

65 64 no sentido de determinar o ponto de chamada ou o ponto de junção da RN após ser implementada. Considerando que essa abordagem enquadra-se nas fases iniciais do desenvolvimento do software, não é possível determinar exatamente os nomes dos métodos/atributos e das classes. Sendo assim, nesse ponto do desenvolvimento é suficiente informar em linguagem natural e com um alto nível de abstração os pontos de junção nos quais as RNs serão acopladas. Essa informação pode ser obtida por meio da análise da localização da RN no gabarito, por exemplo, uma regra oriunda da seção de Pré-Condições deve influenciar a inicialização da classe que implementará a funcionalidade representada no caso de uso. Na Tabela 3.7 são definidas diretrizes com o intuito de apoiar o engenheiro de software nessa análise, como segue: Tabela Diretrizes de apoio para análise do ponto de atuação Seção do Gabarito Pré-Condições Pós-condições Gatilhos Fluxos Alternativos Possíveis pontos de junção Inicialização e instância da classe que representa a funcionalidade base do caso de uso Métodos que executam atividades fins na classe. Exemplo: cadastrar, imprimir, processar, excluir etc. O ponto de junção geralmente ocorre antes da execução ou chamada do método. Semelhante às Pós-condições, porém o ponto de junção ocorre após a execução ou chamada do método. Geralmente os pontos de junção estão vinculados ao passo do fluxo principal que o fluxo alternativo irá modificar. Geralmente está vinculado com ações de modificação e acesso de atributos (get e set) ou com execução de métodos. Id.RN: Essa coluna deve ser preenchida com uma identificação única para a RN, essa informação é importante para possibilitar o rastreamento da regra; Múltipla Ocorrência: Quando uma RN atua em diversos pontos do software, faz-se necessário que na primeira ocorrência da regra, todas as informações sobre os artefatos que a implementam sejam preenchidos, porém, nas demais ocorrências isso não se faz necessário, já que elas são registradas para identificar os pontos do software que a RN deve atuar. Sendo assim o objetivo dessa coluna é orientar o engenheiro de software sobre o fato de que a RN aqui listada já foi detalhada em algum outro ponto do projeto, e nesse ponto representa apenas um novo ponto de atuação da regra; Paradigma: Deve constar a informação sobre qual o paradigma que foi

66 65 utilizado para sua implementação, no contexto desse trabalho podem ser utilizados os paradigmas Orientados a Objetos (OO) ou Orientados a Aspectos (OA) Módulo: Deve ser preenchida com o nome do módulo no qual essa RN está implementada. Caso o paradigma utilizado seja OO, deve constar o nome da classe, caso seja OA, o nome do aspecto; Artefato: Deve ser preenchida com o nome do artefato de software que implementa a RN em questão. Caso o paradigma utilizado seja OO, deve constar o nome do método que encapsula a implementação da regra, caso seja OA deve constar o nome do adendo que encapsula a implementação da regra. As colunas Paradigma, Módulo e Artefato não serão preenchidas nessa atividade do processo. A coluna paradigma deverá ser preenchida após a atividade cujo objetivo é identificar o paradigma de projeto das RNs (Seção ), já as colunas Módulo e Artefato deverão ser preenchidas durante o projeto do diagrama de classes, quando essas informações estiverem disponíveis. Note-se que esse registro propicia um mapeamento entre as RNs e cada caso de uso que as originou, auxiliando no rastreamento dessas RNs nas fases iniciais do desenvolvimento Atividade: Refinar Visão do Diagrama de Casos de Uso para Regras de Negócio Com as RNs identificadas, classificadas e registradas, sugere-se que elas 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. Nesse ponto espera-se que o diagrama de casos de uso funcionais do software já tenha sido definido e refinado, o que dever ter ocorrido na Atividade Refinar Diagramas de Casos de Uso, que é uma atividade padrão do PU (Larman, 2007) que não é influenciada pela abordagem. Para que os casos de uso referentes às regras de negócio 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 demais o diagrama de casos de uso. Os casos de uso que representam RNs geralmente devem ser relacionados aos seus

67 66 casos de uso base por meio de relacionamentos do tipo Extensão (Extend), uma vez que as RNs representam funcionalidades extras que são adicionadas ao comportamento de um caso de uso base. Todavia pode acontecer o fato de uma RN ser essencial ao comportamento de um caso de uso base. Um dos fatores que pode gerar tal situação são as RNs que representam fluxos de eventos, já que podem representar seqüências necessárias à execução do software num determinado contexto. Um exemplo da modelagem de RNs no diagrama de casos de uso é mostrado na Figura 3.4, no qual o caso de uso base RealizarReserva possui duas RNs nomeadas Controlar Inadimplência e Controlar Duração da Reserva. Essa modelagem deve representar a influência de RNs sobre o comportamento de um caso de uso. Essas RNs são obtidas a partir do artefato Relação de Regras de Negócio (Tabela 3.6) e modeladas de acordo com as diretrizes apresentadas. Figura 3.4. Exemplo da modelagem de RNs no diagrama de casos de uso Disciplina Projeto O objetivo da disciplina projeto é a definição dos objetos do software e como eles colaboram para que requisitos previamente definidos sejam atingidos (Larman, 2007). O objetivo dessa fase, para a abordagem proposta, é definir como as RNs serão projetadas. Como citado na seção 1.1.4, o paradigma orientado a aspectos é adequado para o projeto das RNs, porém podem existir situações nas quais esse paradigma não seja o ideal, sendo coerente projetá-las como componentes de objetos. Nessa disciplina estão as atividades de projeto das RNs que visam definir como elas serão projetadas e posteriormente implementadas. As próximas subseções detalham as atividades dessa disciplina.

68 Atividade: Definir Paradigma de Projeto das Regras As quatro características necessárias à implementação de RNs (Separação, Rastreamento, Exteriorização e Posicionamento) sugerem que as RNs devem ser projetadas separadamente do núcleo do software. O uso da orientação a aspectos contribui para isso e têm-se mostrado viável ao projeto das RNs (Cibrán et. al, 2003; Cibrán et. al, 2004; Camargo e Masiero, 2005). Porém, existem outros fatores que devem ser considerados e que podem influenciar a decisão de projetar as RNs com orientação a aspectos, ou de forma convencional, com orientação a objetos, tais como: espalhamento do código, quebra da integridade do código (separação de parte da funcionalidade base implementada no código), volatilidade, entre outros. Para apoiar a decisão sobre o paradigma que deve ser usado no projeto das RNs são propostos critérios com o objetivo de indicar quando uma RN deve, ou não, ser implementada com aspectos. São eles: Quantidade de Relacionamentos, Não-Inclusão, e Volatilidade. Os dois primeiros critérios foram propostos por Camargo (2006) e utilizados neste trabalho. A seguir são detalhados os critérios: Quantidade de Relacionamentos: Caso uma RN possua dois ou mais relacionamentos com casos de uso base do software, é desejável que ela seja projetada como um aspecto. Dessa forma o uso de OA evitaria o espalhamento do código relativo à regra. A análise da quantidade de relacionamentos de uma RN pode ser feita com o uso do diagrama de casos de uso, na visão na qual as RNs foram modeladas. Esse critério deve ser reaplicado a cada iteração do PU, uma vez que com o progresso do desenvolvimento os relacionamentos de uma RN podem mudar, de acordo com os requisitos projetados em cada iteração. Não-Inclusão: Esse critério considera os relacionamentos do tipo Inclusão (Include) entre dois casos de uso. Como o comportamento dos casos de uso de inclusão é um complemento ao comportamento do caso de uso base, geralmente eles são necessários à funcionalidade base definida nesse caso de uso. Dessa forma, sua separação poderia causar uma falsa impressão de independência e desacoplamento, o que pode ser prejudicial ao sistema, não devendo assim ser projetada como candidata a aspectos. Assim, caso uma RN

69 68 não possua relacionamentos de inclusão, ela é candidata a ser projetada como aspecto. Volatilidade: Considera a sensibilidade às mudanças de uma RN. Caso uma RN mostre-se estável, bem definida e pouco sujeita a mudanças, não existe a necessidade de separá-la do núcleo do software, uma vez que o benefício de sua separação seria pequeno ou nulo. Assim, essa RN não deve ser projetada como candidata a aspectos, caso contrário ela é uma candidata a ser projetada com esse paradigma. Porém, essa é uma avaliação muito subjetiva, e deve ser realizada com base nas informações e experiências obtidas junto à empresa durante a elicitação de requisitos. Ainda assim esse critério deve ser utilizado de forma cuidadosa, uma vez que está passivo a erros de interpretação. O critério Quantidade de Relacionamentos possui precedência sobre os demais, ou seja, sempre que ele for satisfeito a RN deverá ser projetada com o paradigma OA. Caso ele não seja satisfeito, é necessário que os dois outros critérios sejam satisfeitos para que a RN seja projetada com OA. Isso ocorre pelo fato do critério Quantidade de Relacionamentos possuir peso suficiente para determinar o paradigma de uma RN, já que quando um caso de uso possui vários relacionamentos o espalhamento de código é eminente. Ao passo que os demais critérios são secundários, e não possuem peso suficiente para, sozinhos, determinar o paradigma de uma RN, necessitando assim que ambos sejam atendidos caso o critério principal não seja atendido. Isso se justifica, uma vez que o fato de uma RN não possuir relacionamentos de inclusão sendo volátil, ou sendo volátil possuindo relacionamentos de inclusão não geram um cenário determinante para que uma RN seja projetada como aspecto. Uma vez determinadas quais RNs serão projetadas com o paradigma POA deve-se atualizar o artefato Lista de Regras (Tabela 3.6), identificando o paradigma (OO ou OA) com que cada uma das RNs deve ser projetada Atividade: Projetar as Regras de Negócio no Diagrama de Classes Neste ponto do projeto do software têm-se as RNs relacionadas no artefato Lista de Regras e representadas graficamente no diagrama de casos de uso (numa visão própria). A partir disso o projeto do software continua e serão projetadas as classes que irão compor a parte base do software, na atividade do PU anterior a essa. Para projetar as RNs juntamente

70 69 com as classes base do software deve-se seguir diferentes procedimentos, de acordo com o paradigma que será utilizado no projeto da RN. Caso a RN seja projetada com OO, o engenheiro de software deve representá-la como um método da classe a que ela pertence, porém deve-se utilizar um estereótipo para que esse método seja identificado como uma RN e satisfaça (mesmo que parcialmente) a característica de Separação (Von Halle, 2002). O Estereótipo utilizado é o <<BR>>. Na Figura 3.5 é mostrado um exemplo de uma RN projetada com OO, no qual ChecarCxAnterior() da classe ControleCaixa é uma RN que foi projetada com OO, e conseqüentemente transformou-se num método da classe. Figura 3.5- Exemplo de Projeto de uma RN com o paradigma OO Caso a RN seja projetada com OA, o engenheiro de software deve utilizar a notação proposta por Pawlak et al. (2002) para projetar a regra no diagrama de classes. Nessa notação os autores utilizam-se de classes com o estereótipo <<aspect>> para identificar os aspectos. É importante ressaltar que a partir desse ponto do projeto essas RN serão aspectos. Os métodos da classe são utilizados para representar os adendos (advices) do aspecto, para isso são utilizados os estereótipos <<before>>, <<after>> e <<around>> que representam o tipo de adendo a ser implementado. As associações com estereótipos <<pointcut>> são utilizadas para indicar quais as classes base que o aspecto entrecorta. Essas associações utilizam-se de etiquetas valoradas (tagged value) para identificar os métodos e atributos da classe base que serão entrecordados pelo aspecto. O formato das etiquetas valoradas são?metodo(..) ou!metodo(..) no qual o caractere? indica que o método é entrecortado pelo aspecto no contexto de chamada (call) e o caractere! indica que o método é entrecortado pelo aspecto no contexto de execução (execution). A definição do ponto de junção da RN (aspecto) pode ser apoiada pelo valor da coluna Ponto de Atuação, do artefato Relação de Regras de Negócio, já que foi preenchida com o intuito de indicar em que momento a RN influenciará o software base.

71 70 Na Figura 3.6 é mostrado um exemplo de RN projetada com OA, no qual a RN VerificarAcesso é um aspecto que entrecorta a classe MovEstoque antes da chamada do método Set_Data(). Figura Modelagem de uma RN com o uso da abordagem Pawlak et al Rastreamento das Regras de Negócio Com aplicação da abordagem proposta neste trabalho, é possível obter um bom nível de rastreamento das RNs desde o caso de uso até a sua implementação. Isso é possível pela ligação que é estabelecida partindo do caso de uso, documentado no gabarito proposto, passando pela Lista de Regras, diagrama de classes, até chegar à implementação do software. Na Figura 3.7 é mostrado um exemplo no qual o caso de uso Gerar Vendas, documentado pelo gabarito, possui na seção Pós-Condições uma RN do tipo restrição, que é projetada com o paradigma OA e dá origem ao aspecto VerificarCredito. Dessa forma é possível, partindo-se de uma RN, chegar até ao caso de uso que a originou, e em direção contrária, chegar até ao artefato que a implementou Considerações Finais Neste capítulo foi apresentada a descrição da abordagem de desenvolvimento de software com RNs, que é a base dessa dissertação. A apresentação ocorreu com a fundamentação teórica da proposta, seu enquadramento no ciclo de vida padrão de desenvolvimento de software, e com a proposta de uma extensão ao Processo Unificado, originalmente proposto por Jacobson et al.(1999).

72 Figura Rastreabilidade de uma Regra de Negócio 71

73 72 O objetivo deste capítulo foi fornecer o embasamento teórico necessário à aplicação dessa abordagem. No próximo capítulo é apresentada a aplicação da abordagem em um estudo de caso real, o que fornece um bom nível de exemplificação e ajuda a compreender melhor a abordagem

74 CAPÍTULO 4 ESTUDO DE CASO 73 Neste capítulo é apresentado um estudo de caso que foi utilizado para a geração e validação da proposta apresentada nesta dissertação. Esse estudo de caso foi elaborado com base nos requisitos de um software real. Esses requisitos foram gentilmente cedidos pela empresa DataPlus Sistemas, de Catanduva-SP. Os requisitos especificam o funcionamento de um software para controle de lojas do setor de vestuário. O software originalmente desenvolvido, com base nesses requisitos, faz parte das soluções oferecidas pela DataPlus Sistemas, porém não foi utilizado o paradigma OO no projeto original do software, o que impediu uma comparação do projeto da versão original com a versão desenvolvida nesse estudo de caso, pelo fato de estarem em paradigmas diferentes. Na Seção 4.1 é mostrada a definição do estudo de caso, na seção 4.2 são mostrados os detalhes da execução do estudo de caso, e na seção 4.3 são feitas as considerações finais desse capítulo 4.1. Definição O objeto deste estudo de caso é o desenvolvimento de um software para controlar as atividades de uma loja do setor de vestuário. Esse controle abrange as operações cotidianas de uma empresa desse tipo, sendo elas: manutenção dos dados cadastrais necessários à operação do software (Cliente, Fornecedores, Produtos etc), controle das vendas efetuadas, apuração da comissão dos vendedores, controle das contas a receber, controle do estoque dos produtos, controle do recebimento dos produtos e controle das contas a pagar, entre outros, conforme descrito no documento de requisitos presente no Apêndice B. O objetivo deste estudo de caso é a utilização da abordagem apresentada nessa dissertação. Dessa forma espera-se que o uso da abordagem propicie a construção de um software no qual as RNs estejam implementadas com base em artefatos independentes do núcleo do software, favorecendo as futuras manutenções do software, bem como o reúso das RNs e do próprio software, já que as RNs podem ser mais facilmente desacopladas do software resultante. Além disso, espera-se também que o uso da abordagem favoreça o rastreamento das RNs permitindo que se possam identificar facilmente todos os artefatos utilizados na implementação de uma determinada RNs, apoiando as quatro características

75 74 necessárias à implementação de RNs (Separação, Rastreamento, Exteriorização e Posicionamento). O estudo de caso foi realizado pelo próprio autor. O material necessário para esse estudo foi: Fundamentação de RNs (Business Rules Group, 2000; Von Halle, 2002; Ross, 2003), Guia da API Java e Manuais do SGBD MS-SQLSERVER 8.0. A modelagem foi feita com o apoio da ferramenta Rational XDE, a codificação foi realizada na linguagem Java utilizando a API J2SE 1.5 e a API AspectJ 1.5, o IDE utilizado foi o Eclipse versão 3.2. A execução do caso de uso está detalhada na próxima seção Execução A execução do estudo de caso ocorreu com a aplicação da extensão do PU proposta nessa abordagem, cumprindo-se assim uma seqüência de atividades definidas, como segue: 1. Identificar e registrar casos de uso essenciais; 2. Documentar casos de uso com gabarito; 3. Classificar e registrar RNs; 4. Refinar diagramas de casos de uso; 5. Desenvolver modelo de classes do projeto 6. Definir paradigma de projeto das regras; 7. Desenvolver diagramas de Interação; 8. Projetar regras de negócio; 9. Implementar classes do domínio; 10. Implementar regras de negócio; 11. Testar; O estudo de caso foi executado com um pequeno número de iterações (as fases de elaboração e construção foram executadas em apenas uma iteração). Isso ocorreu pelo fato do desenvolvimento ser baseado em um software já existente e estável, sendo assim a divisão em diversas iterações não iria gerar uma contribuição significativa para esse estudo de caso. Algumas dessas atividades não foram modificadas ou influenciadas pela abordagem proposta. As demais atividades (em negrito) compõem a abordagem proposta, ou sofreram algum tipo de alteração por ela. As atividades modificadas (ou criadas) estão detalhadas nas próximas seções.

76 Documentar Casos de Uso com Gabarito 75 Os casos de uso foram identificados e registrados na atividade anterior. Isso ocorreu da forma convencional, com base no PU, sem qualquer influência da abordagem proposta. Foram identificados, neste estudo de caso, 24 casos de uso e 4 (quatro) atores. Nas Figuras 4.1, 4.2, 4.3 e 4.4 são mostrados os casos de uso com uma visão independente para cada ator. A documentação dos casos de uso que possuem RNs pode ser vista no Apêndice C. Figura Casos de uso do ator Vendedor Figura Casos de uso do ator Administrador

77 76 Figura Casos de uso do ator Gerente Figura Casos de uso do ator Caixa Para este estudo de caso são utilizados dois casos de uso (Gerar Venda e Movimentar Estoque). Isso ocorre para evitar uma extensão inadequada ao contexto deste trabalho. As especificações destes casos de uso são mostradas nas Figuras 4.5 e 4.6. O preenchimento das seções do gabarito proposto deve se feito mediante análise do documento de requisitos. Para que o foco do trabalho seja mantido só são comentadas as seções incluídas ou alteradas pela abordagem, uma vez que as demais seções foram preenchidas na atividade anterior.

78 77 Figura Documentação do caso de uso Gerar Venda Figura Documentação do caso de uso Movimentar Estoque Na identificação dos fluxos alternativos dos casos de uso (assim como nas pré e póscondições) a questão chave para o uso adequado da abordagem é a identificação da origem da informação. Para ilustrar essa questão será utilizada uma comparação entre dois comportamentos identificados como fluxos alternativos, como seguem:

79 78 a) Um movimento de estoque do tipo saída só será aceito com quantidade menor ou igual ao atributo quantidade em estoque, no cadastro do produto. b) Na gravação da venda, o valor de desconto não deverá ser superior a 5% do valor total da venda. O comportamento a é parte do requisito 8 (oito), que é mostrado na Figura 4.7, que descreve o funcionamento da movimentação de estoque, e o comportamento b é parte do requisito 10 (dez), que é mostrado na Figura 4.8, que descreve o funcionamento da venda. Ambos os comportamentos pertencem ao fluxo alternativo, dos casos de uso Movimentar Estoque e Gerar Vendas respectivamente (vide Figuras 4.6 e 4.5), e necessitam de uma ação específica caso sua condição não seja satisfeita, porém apenas um deles é uma RN. Aplicando-se os critérios para identificação de RNs, mostrados na Seção a., nesse trecho do documento de requisitos pode-se perceber que ambos os comportamentos satisfazem ao critério das decisões, uma vez que ambos possuem uma condição para serem acionados. Com isso nenhum deles irá representar um fluxo de eventos (critério Fluxo de Eventos). Porém o comportamento a é essencial ao funcionamento genérico do seu caso de uso, uma vez que não seria admissível que um software de gestão de lojas permitisse que fosse registrada uma venda de um produto que não tenha disponibilidade de estoque. Já o comportamento b não é essencial ao funcionamento genérico do seu caso de uso, já que nem todas as lojas impõem restrições de descontos no ato da venda, pois podem gerenciar esses descontos posteriormente, por meio de relatórios específicos. Sendo assim o critério de Essencialidade foi determinante para apurar a origem desses comportamentos. Figura Requisito 8 (oito) referente a movimentação de estoque

80 79 Figura Requisito 10 (dez) referente ao registro de vendas. Além disso, pode-se apurar que o comportamento a tem por objetivo o cumprimento de uma necessidade de integridade das informações manipuladas pelo software, o que não o caracteriza como uma RN. Já o comportamento b tem por objetivo o cumprimento de uma política da empresa, que o caracteriza como uma RN. Em resumo, a identificação das RNs ocorreu com o uso dos critérios para a identificação das RNs associado à teoria de RN. A identificação também foi apoiada pelo uso do gabarito, uma vez que o engenheiro de software pode identificar RNs que atuam em situações específicas (fluxo alternativo de eventos, pré e pós-condições e gatilhos), o que reduz o domínio de identificação de acordo com cada seção do gabarito. A identificação do tipo de RN na seção Fluxo Alternativo (assim como na seção Gatilhos) utiliza como critério de escolha o objetivo do comportamento registrado como fluxo alternativo, aliado à teoria de RN. Uma vez que no contexto deste trabalho foram

81 80 identificados três tipos de fluxo alternativo (e de gatilhos) a escolha torna-se relativamente simples, bastando para isso observar-se o resultado da ação desempenhada. Como exemplo, serão utilizados alguns fluxos alternativos extraídos do documento de requisitos, como segue: c) O valor unitário dos produtos só poderá ser alterado caso o usuário do sistema tenha nível de acesso de gerente; d) Deverá também ser realizada uma checagem para apurar se o cliente terá alguma duplicata que irá vencer nos próximos 7 (sete) dias, caso tenha, uma mensagem deverá ser exibida para o usuário; No fluxo c percebe-se que o resultado da RN, caso a condição seja satisfeita, é a habilitação de uma funcionalidade do caso de uso, que é a possibilidade de alteração dos valores unitários dos itens da venda, nesse caso o tipo do fluxo alternativo é Habilitador. No fluxo d percebe-se que o resultado da RN, caso ela seja acionada por ter satisfeito a condição, é uma advertência ao ator, dessa forma o tipo do fluxo alternativo é Diretriz. As pré e pós-condições puderam ser identificadas sem maiores problemas, atentandose apenas em limitá-las aos comportamentos restritivos que ocorrem antes ou depois da funcionalidade base do caso de uso, separando-as assim dos fluxos alternativos. Além disso, a identificação da origem deve atentar-se às observações supracitadas. Os gatilhos são parecidos com as pós-condições, porém descrevem outros tipos de comportamento. O engenheiro de software deve atentar-se de que os gatilhos cuja origem não seja de negócio, não devem ser incluídos nessa seção, mas sim modelados da forma clássica, com casos de uso e relacionamentos Identificar e Classificar Regras de Negócio O objetivo dessa atividade é a aplicação das diretrizes de identificação e classificação das RNs, o que possibilita a extração das RNs da documentação dos casos de uso. Foi possível perceber, nesse ponto do desenvolvimento, que o esforço maior para a identificação das RNs ocorre durante a documentação dos casos de uso. Dessa forma, as atividades dessa etapa resumem-se em extrair, de forma organizada, as RNs constantes nos gabaritos preenchidos e agrupá-las no artefato Lista de Regras. O único ponto que necessita de uma atenção maior é a identificação de RNs com múltiplas ocorrências. Para essa identificação é necessário atentar-se para RNs que sejam

82 81 semelhantes, mesmo estando em diferentes pontos dos casos de uso, ou mesmo em diferentes casos de uso. Essa é uma tarefa nada trivial e que pode afetar de forma considerável a identificação de RNs candidatas a aspectos (Seção 4.2.4). O resultado desta atividade é o artefato Lista de Regras parcialmente preenchida, que é mostrado na Tabela 4.1. Tabela 4.1 Lista de Regras parcialmente preenchida Caso o cliente possua duplicatas a vencer nos próximos 7 dias a pesquisa financeira do cliente deverá ser exibida Caso o cliente tenha duplicatas vencidas e não pagas deverá ser gerada uma advertência para que a situação seja regularizada senão a venda não será aceita Caso o usuário não seja gerente a alteração do preço dos produtos deverá ser bloqueada Caso seja o mês de aniversário do cliente, o desconto deverá ser preenchido com o valor de 5% do total da venda É necessário que o caixa esteja aberto para que uma venda seja registrada, alterada ou excluída. Habilitad ora Diretriz Habilitad ora Derivaçã o Gerar Vendas Gerar Vendas Gerar Vendas Gerar Vendas Restrição Gerar Vendas O valor de desconto não deverá Restrição Gerar ser superior a 5% da venda Vendas Deverá ser realizada uma Restrição Gerar checagem para apurar se o Vendas cliente tem alguma duplicata vencida e não paga, caso tenha a venda não deverá ser aceita Na gravação da venda, deverão ser geradas duplicatas a receber, uma para cada vencimento constante na condição de pagamento da venda. Na gravação da venda, caso algum dos vencimentos possua o número de dias do vencimento igual a 0 (o que indica que é a vista), deverá ser gerado um recebimento relativo à duplicata do vencimento em questão, no mesmo valor da duplicata Na gravação da venda, deverá ser impresso um borderô relativo à venda O atributo data do movimento só poderá ser diferente da data do dia caso o usuário do sistema tenha nível de acesso de gerente É necessário que o caixa esteja aberto para que um pagamento seja registrado, alterado ou excluído. Derivaçã o Derivaçã o Habilitad ora Gerar Vendas Gerar Vendas Gerar Vendas Restrição Movimen tar Estoque Restrição Gerar Pagament o de Documen tos Ponto de Id. RN Atuação Inicialização ChecarCaixa Anterior No ato de ChecarDuplA informar o Vencer cliente Fluxo No ato de Alternativo informar o cliente Fluxo No ato de Alternativo informar o cliente Fluxo Na inserção Alternativo de produtos na venda Fluxo Alternativo Regra Tipo Caso de Uso Seção Verificar se o caixa anterior está Restrição Abrir Préfechado Caixa Condições Caso o cliente possua duplicatas Diretriz Gerar Fluxo a vencer nos próximos 7 dias Vendas Alternativo deverá ser gerado um aviso ao usuário Pré- Condições Na informação do valor do desconto MostrarPesqF inanceira AdvertirAtras os Bloquear Preços GerarDescont oaniversario Inicialização VerificarCaix aaberto Pós- Gravação da VerificarDesc Condições Venda ontomáximo Pós- Gravação da VerificarCrédi Condições Venda to Gatilhos Gatilhos Gatilhos Pré- Condições Pré- Condições Gravação da Venda Gravação da Venda Gravação da Venda GerarDuplicat as GerarRecebim entoavista ChamarImpre ssaobordero Gravação da VerificarAces Movimentaç so ão Inicialização VerificarCaix aaberto Múltipla Ocorrência X Paradig ma Módulo Artefato

83 Na gravação do pagamento, a data de pagamento deverá ser a data do dia, a menos que o usuário do sistema tenha nível de acesso de gerente. Após a inclusão de um novo pagamento a impressão do recibo é acionada É necessário que o caixa esteja aberto para que um recebimento seja registrado, alterado ou excluído. Na gravação do recebimento, a data de recebimento deverá ser a data do dia, a menos que o usuário do sistema tenha nível de acesso de gerente. Caso o custo apurado de algum produto, seja 10% menor que o atual deverá ser gerado um aviso de possibilidade de campanha promocional O preço de custo de cada produto deverá ser atualizado com o valor constante na entrada mais o valor rateado dos custos adicionais. A cada atualização do custo do produto o preço de venda do mesmo deverá ser atualizado Deverão ser gerados os documentos a pagar para o fornecedor, um para cada vencimento constante na entrada Restrição Gerar Pós- Pagament Condições o de Documen tos Habilitad Gerar Gatilhos ora Pagament o de Documen tos Restrição Informar Pré- Recebime Condições nto de Duplicata s Restrição Informar Pós- Recebime Condições nto de Duplicata s Diretriz Cadastrar Recebime nto de Produtos Habilitad ora Derivaçã o Recebime Gatilhos nto de Produtos Recebime Gatilhos nto de Produtos Gravação do Pagamento VerificarAces so Após ChamarRecPa Gravação do gto Pagamento Inicialização VerificarCaix aaberto Gravação do Recebiment o VerificarAces so Fluxo Na InformarRedu Alternativo Gravação da çãopreços Entrada Na Gravação Após a Gravação AtualizarCust ovenda GerarDocume ntos X X X Refinar Diagramas de Caso de Uso Nessa atividade deve ser realizada a modelagem das RNs identificadas no diagrama de casos de uso, com o uso dos estereótipos estabelecidos. Essa modelagem foi realizada em uma visão própria, o que mostrou-se válido, uma vez que diversas RNs influenciam um mesmo casos de uso, e também, uma RN influencia diversos casos de uso, o que polui de forma considerável o diagrama original. Na Figura 4.9 são mostradas as partes mais relevantes do diagrama de casos de uso com a modelagem das RNs.

84 Figura Diagrama de casos de uso com a modelagem das regras de negócio 83

85 Definir Paradigma de Projeto das Regras de Negócio O processo de definição do paradigma de projeto de uma regra consiste na aplicação dos critérios nas RNs constantes na Lista de Regras. Para ilustrar esse processo foram selecionadas algumas regras para que a aplicação dos critérios seja comentada, como segue: a) Caso o usuário não seja gerente a alteração do preço dos produtos deverá ser bloqueada; b) Na gravação da venda, deverá ser impresso um borderô relativo à venda; c) É necessário que o caixa esteja aberto para que um pagamento seja registrado, alterado ou excluído; d) O valor de desconto não deverá ser superior a 5% da venda A RN a foi desconsiderada OA (e sim OO) por não atender ao critério Quantidade de Relacionamentos, já que possui um único relacionamento, atender ao critério Não- Inclusão, já que não possui relacionamentos de inclusão e não atender ao critério Volatilidade. Dessa forma, como o critério precedente não foi atendido, e apenas um dos critérios secundários foi atendido, essa RN será projetada OO. A questão da volatilidade foi determinada durante a fase de elicitação de requisitos, quando os analistas apuraram que nesse tipo de empresa a alteração de preços dos itens de venda é algo incomum, uma vez que eventuais descontos são concedidos no campo designado a isso. Sendo assim, muito embora essa característica seja própria da empresa, essa é uma RN que dificilmente será modificada. A RN b foi desconsiderada OA (e sim OO) pelo fato de não atender ao critério precedente Quantidade de Relacionamentos, não atender ao critério Não-Inclusão, uma vez que o relacionamento com a funcionalidade representada pelo caso de uso Gerar Vendas é do tipo inclusão, ou seja, o comportamento de impressão do borderô está incluído no caso de uso Gerar Venda, embora atenda ao critério Volatilidade. Dessa forma, como o critério precedente não foi atendido, e apenas um dos critérios secundários foi atendido, essa RN será projetada OO. Já a RN c possui diversos relacionamentos com casos de uso base, o que justifica seu projeto como OA, já que seu projeto com o paradigma OO poderia gerar espalhamento de seu código, e dessa forma atende ao critério precedente Quantidade de Relacionamentos. Por fim, a RN d não atende ao critério de quantidade de relacionamentos, porém atende aos critérios de Não-Inclusão, já que não possui nenhum relacionamento de inclusão

86 85 com os casos de uso, e atende ao critério de volatilidade, já que não possui as características de uma regra estável, o que faz com que ela seja projetada como OA, já que atendeu aos dois critérios secundários, embora não tenha atendido ao critério precedente. Após a definição do paradigma de projeto das RNs, o artefato Lista de Regras deve ser atualizado, preenchendo-se a coluna paradigma com a informação OA ou OO, para que essa informação auxilie no projeto das RNs no diagrama de classes. O resultado desta atividade é o artefato Lista de Regras totalmente preenchido, como é mostrado na Tabela 4.2 A próxima atividade é a modelagem das RNs no diagrama de classes. Verificar se o caixa anterior está fechado Tabela Lista de Regras totalmente preenchida. Regra Tipo Caso de Uso Seção Ponto de Atuação Restrição Abrir Caixa Pré- Condiçõe s Caso o cliente possua duplicatas a vencer nos próximos 7 dias deverá ser gerado um aviso ao usuário Caso o cliente possua duplicatas a vencer nos próximos 7 dias a pesquisa financeira do cliente deverá ser exibida Caso o cliente tenha duplicatas vencidas e não pagas deverá ser gerada uma advertência para que a situação seja regularizada senão a venda não será aceita Caso o usuário não seja gerente a alteração do preço dos produtos deverá ser bloqueada Caso seja o mês de aniversário do cliente, o desconto deverá ser preenchido com o valor de 5% do total da venda É necessário que o caixa esteja aberto para que uma venda seja registrada, alterada ou excluída. O valor de desconto não deverá ser superior a 5% da venda Deverá ser realizada uma checagem para apurar se o cliente tem alguma duplicata vencida e não paga, caso tenha a venda não deverá ser aceita Na gravação da venda, deverão ser geradas duplicatas a receber, uma para cada vencimento constante na condição de pagamento da venda. Na gravação da venda, caso algum dos vencimentos possua o número de dias do vencimento igual a 0 (o que indica que é a vista), deverá ser gerado um recebimento relativo à duplicata do vencimento em questão, no mesmo valor da duplicata Na gravação da venda, deverá ser impresso um borderô relativo à venda Diretriz Habilitad ora Diretriz Habilitad ora Derivaçã o Gerar Vendas Fluxo Alternativ o Id. RN Inicialização ChecarCaixaA nterior No ato de informar o cliente Gerar Vendas Fluxo No ato de Alternativ informar o o cliente Gerar Vendas Fluxo No ato de Alternativ informar o o cliente Gerar Vendas Fluxo Alternativ o Gerar Vendas Fluxo Alternativ o Restrição Gerar Vendas Pré- Condiçõe s Restrição Gerar Vendas Pós- Condiçõe s Restrição Gerar Vendas Pós- Condiçõe s Derivaçã o Derivaçã o Habilitad ora Gerar Vendas Gatilhos Gerar Vendas Gatilhos Gerar Vendas Gatilhos Na inserção de produtos na venda Na informação do valor do desconto ChecarDuplA Vencer MostrarPesqFi nanceira AdvertirAtras os Bloquear Preços GerarDescont oaniversario Inicialização VerificarCaixa Aberto Gravação da Venda Gravação da Venda Gravação da Venda Gravação da Venda Gravação da Venda VerificarDesc ontomáximo VerificarCrédi to GerarDuplicat as GerarRecebim entoavista ChamarImpres saobordero Múltip Ocor. Paradi gma OA OA OA OA OO OA OA OA OA Módulo ChecarCx Anterior ChecaDu plvencer Mostrar PesqFina nceira VerificaA traso Bloquear Precos ChecaDes cniver Artefato Checagem Checagem Pesquisa Checagem Bloqueio Checagem Verificar Checagem CaixaAbe rto ChecaDes Checagem conto Verificar Credito Checagem OO Venda GeraDocs Receber OA GerarRec Vista Gerador OA Venda ImprimirB ordero O atributo data do movimento Restrição Movimentar Pré- Gravação da VerificarAcess OA Verificar Checagem

87 só poderá ser diferente da data do dia caso o usuário do sistema tenha nível de acesso de gerente É necessário que o caixa esteja aberto para que um pagamento seja registrado, alterado ou excluído. Na gravação do pagamento, a data de pagamento deverá ser a data do dia, a menos que o usuário do sistema tenha nível de acesso de gerente. Após a inclusão de um novo pagamento a impressão do recibo é acionada É necessário que o caixa esteja aberto para que um recebimento seja registrado, alterado ou excluído. Na gravação do recebimento, a data de recebimento deverá ser a data do dia, a menos que o usuário do sistema tenha nível de acesso de gerente. Caso o custo apurado de algum produto, seja 10% menor que o atual deverá ser gerado um aviso de possibilidade de campanha promocional O preço de custo de cada produto deverá ser atualizado com o valor constante na entrada mais o valor rateado dos custos adicionais. A cada atualização do custo do produto o preço de venda do mesmo deverá ser atualizado Deverão ser gerados os documentos a pagar para o fornecedor, um para cada vencimento constante na entrada Estoque Restrição Gerar Pagamento de Documentos Restrição Gerar Pagamento de Documentos Habilitad ora Gerar Pagamento de Documentos Restrição Informar Recebimento de Duplicatas Restrição Informar Recebimento de Duplicatas Diretriz Habilitad ora Derivaçã o Cadastrar Recebimento de Produtos Recebimento de Produtos Recebimento de Produtos Condiçõe s Pré- Condiçõe s Pós- Condiçõe s Gatilhos Pré- Condiçõe s Pós- Condiçõe s Movimentaçã o Inicialização VerificarCaixa Aberto Gravação do Pagamento Após Gravação do Pagamento o VerificarAcess o ChamarRecPa gto Inicialização VerificarCaixa Aberto Gravação do Recebimento Fluxo Na Gravação Alternativ da Entrada o Gatilhos Gatilhos VerificarAcess o InformarRedu çãopreços Na Gravação AtualizarCust ovenda Após a Gravação GerarDocume ntos X X X X OO OA Acesso Pagament o Verificar Reducao 86 ImprimirR ecibo Checagem OO Produto AtualizarP rvenda OO Entrada GerarDocs Pagar Projetar Regras de Negócio no Diagrama de Classes Com as RNs identificadas, classificadas e com o paradigma de projeto definido, o próximo passo é projetá-las e modelá-las no diagrama de classes. Para as RNs projetadas como aspectos foi utilizada a abordagem de modelagem proposta por Pawlak et. al (2003). Um dos pontos importante dessa fase é a definição dos pontos de junção das RNs que foram projetadas como aspectos. A informação Ponto de Atuação, presente no artefato Relação de Regras de Negócio, é um auxilio bastante útil, pois evita que seja necessário uma nova análise dos requisitos em busca da identificação do momento que uma RN deve ser acionada. Para ilustrar essa atividade serão apresentados os detalhes da modelagem de algumas RNs, como segue: a) Verificar Caixa Aberto: O objetivo dessa RN é certificar de que o caixa da loja esteja aberto para que uma venda seja registrada. Essa RN foi projetada no

88 87 paradigma OA, como é mostrado na Figura Para projetar o ponto de junção dessa RN (que agora é um aspecto), seguiu-se a orientação registrada na Lista de Regras que indicava que seu ponto de atuação deveria ser na inicialização da classe. Dessa forma, seu ponto de junção é a instância da classe (método main) com o tipo de adendo before, o que possibilita que uma exceção seja gerada, caso o caixa da loja não esteja aberto. Figura Regra de negócio projetada como aspecto b) Checar Desconto: O objetivo dessa RN é verificar se o desconto concedido na venda não excedeu o desconto máximo permitido. Essa RN de negócio foi projetada no paradigma OA, como é mostrado na Figura Para projetar o ponto de junção dessa RN foi considerado o ponto de atuação indicado na relação de regras de negócio, que indicava que a RN deveria ser acionada na gravação da venda. Assim, seu ponto de junção foi projetado como a chamada do método cadastra() com o tipo de adendo before, possibilitando assim que a venda não seja gravada, caso o desconto seja excessivo.

89 88 Figura Regra de Negócio candidata a aspecto Na Figura 4.12 são mostradas RNs, mais relevantes, projetadas e modeladas no diagrama de classes. O diagrama de classes resultante proporciona uma visão ampla da parte estática do software, com as RNs projetadas juntamente com as classes que compõem o núcleo do software Implementar as Regras de Negócio O objetivo desta atividade é implementar as RNs para que elas componham o software e se integrem ao núcleo funcional deste. A implementação seguiu o que estava projetado, respeitando o paradigma no qual cada regra foi projetada. O único ponto que deve ser salientado é que a abordagem não ofereceu subsídio às RNs/Aspectos que atuam num mesmo ponto de junção, fazendo com que a definição de prioridade dessas regras ocorresse de forma empírica.

90 Figura Diagrama de Classes. 89