FUNDAO DE ENSINO EURPIDES SOARES DA ROCHA CENTRO UNIVERSITRIO EURPIDES DE MARLIA - UNIVEM MESTRADO EM CINCIA DA COMPUTAO

MARCO ANTONIO DE GRANDI

UMA ABORDAGEM DE IDENTIFICAO E MODELAGEM DE REGRAS DE NEGCIO E SEUS RELACIONAMENTOS TRANSVERSAIS

MARLIA 2008

MARCO ANTONIO DE GRANDI

UMA ABORDAGEM DE IDENTIFICAO E MODELAGEM DE REGRAS DE NEGCIO E SEUS RELACIONAMENTOS TRANSVERSAIS

Dissertao apresentada ao Programa de PsGraduao em Cincia da Computao do Centro Universitrio Eurpides de Marlia, como parte dos requisitos necessrios obteno do ttulo de Mestre em Cincia da Computao.

Orientador: Prof. Dr. Edmundo Srgio Spoto. Co-orientador: Prof. Dr. Valter Vieira de Camargo

MARLIA 2008

DE GRANDI, Marco Antonio Uma Abordagem de Identificao e Modelagem de Regras de Negcio e seus Relacionamentos Transversais / Marco Antonio De Grandi; orientador: Edmundo Srgio Spoto / co-orientador: Valter Vieira de Camargo, Marlia, SP:[s.n.], 2008. 118 f. Dissertao (Mestrado em Cincia da Computao) Centro Universitrio Eurpedes de Marlia Fundao de Ensino Eurpedes Soares da Rocha. 1. Regras de Negcio 2. Programao Orientada a Aspectos 3. Reso de Software CDD: 0005.1

s minhas filhas Maria Jlia e Bianca, vocs foram minha motivao.

AGRADECIMENTOS

Agradeo aos meus pais, por sempre acreditarem em mim.

As minhas filhas, pela inspirao.

Aos meus orientadores, Prof. Dr. Edmundo e Prof. Dr. Valter, pela confiana, dedicao e amizade.

Ao meu scio e irmo Mario, pelo apoio e compreenso nas insistentes ausncias.

Ao meu amigo Paulo, pela motivao inicial para essa jornada.

Aos meus amigos de mestrado Silvio, Rodrigo, Bruno, Juliana, Thais, Camila e Giuliana pela amizade e convivncia. E ao meu amigo Alex, pela amizade que excedeu ao companheirismo de mestrado.

Eu posso estar completamente enganado, Eu posso estar correndo pro lado errado. Mas a dvida o preo da pureza, Pois intil ter certeza.
Humberto Gessinger

DE GRANDI, Marco Antonio. Uma Abordagem de identificao e modelagem de Regras de Negcio e seus relacionamentos transversais. 116 f Dissertao (Mestrado em Cincia da Computao) Centro Universitrio Eurpides de Marlia, Fundao de Ensino Eurpides Soares da Rocha, Marlia, 2008.

RESUMO

O uso de regras de negcio dentro do contexto de sistema de informao tem despertado grande interesse no meio acadmico. Vrios pesquisadores argumentam que a volatilidade das regras de negcio faz com que seja necessrio um tratamento mais aprimorado delas durante o desenvolvimento de sistemas de informao. Recentemente o surgimento da programao orientada a aspectos (POA) mudou a viso da integrao das regras de negcio com o ncleo do software, uma vez que forneceu mecanismos para projetar e implementar essas regras de forma desvinculada desse ncleo. Neste trabalho apresentada uma abordagem que permite identificar, classificar e modelar regras de negcio. Essa abordagem baseada em artefatos que apiam o registro das regras de negcio na fase de anlise do software. Essa abordagem tambm composta por critrios que apiam a identificao e classificao das regras de negcio na fase de anlise de requisitos. Tambm so estabelecidos critrios para apoiar a determinao do paradigma de projeto das regras de negcio, sendo que alguns tipos devero ser projetados e implementados por meio de programao orientada a aspectos. Essa abordagem foi estruturada como uma extenso do Processo Unificado (PU) e foi validada com o desenvolvimento de um estudo de caso baseado em um sistema de gesto comercial real.

Palavras chaves: Regras de Negcio, Programao Orientada a Aspectos, Reso de Software.

DE GRANDI, Marco Antonio. Uma Abordagem de identificao e modelagem de Regras de Negcio e seus relacionamentos transversais. 116 f Dissertao (Mestrado em Cincia da Computao) Centro Universitrio Eurpides de Marlia, Fundao de Ensino Eurpides Soares da Rocha, Marlia, 2008.

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

LISTA DE ILUSTRAES

Figura 1.1 Um Framework para arquitetura empresarial (Zachman, 1997) .......................... 22 Figura 1.2 - Classificao das Regras de Negcio ................................................................... 25 Figura 1.3 Diagrama de Caso de Uso (Booch et al., 2000) ................................................... 31 Figura 1.4 - Diagrama de Classes (Booch et al., 2000) ............................................................ 32 Figura 1.5 Diagrama de Seqncia (Booch et al., 2000)....................................................... 33 Figura 1.6 Definindo Esteretipos (Adaptado de Alhir, 2003) ............................................. 35 Figura 1.7 Aplicando Esteretipos no diagrama de classes (Adaptado de Alhir, 2003) ....... 36 Figura 1.8 Esteretipos, valores atribudos e restries (adaptada de Alhir, 2003) .............. 37 Figura 1.9 Exemplo de um aspecto implementado em AspectJ ............................................ 39 Figura 2.1 O cenrio da modelagem de regras de negcio (Bajec e Krisper, 2004) ............. 42 Figura 2.2 - Exemplo da utilizao do Business Object Model (Ilog, 2008). ........................... 45 Figura 2.3 - Ciclos de vida do Software e das Regras de Negcio (Ilog, 2008) ...................... 46 Figura 3.1 - Influncia da abordagem no ciclo de vida de desenvolvimento de software........ 50 Figura 3.2 - Gabarito para registro e documentao dos casos de uso ..................................... 53 Figura 3.3 - Exemplo de Gatilhos............................................................................................. 61 Figura 3.4. Exemplo da modelagem de RNs no diagrama de casos de uso. ............................ 66 Figura 3.5- Exemplo de Projeto de uma RN com o paradigma OO ......................................... 69 Figura 3.6 - Modelagem de uma RN com o uso da abordagem Pawlak et al. ......................... 70 Figura 3.7 - Rastreabilidade de uma Regra de Negcio ........................................................... 71 Figura 4.1 - Casos de uso do ator Vendedor ............................................................................ 75 Figura 4.2 - Casos de uso do ator Administrador ..................................................................... 75 Figura 4.3 - Casos de uso do ator Gerente ................................................................................ 76 Figura 4.4 - Casos de uso do ator Caixa ................................................................................... 76 Figura 4.5 - Documentao do caso de uso Gerar Venda ....................................................... 77 Figura 4.6 - Documentao do caso de uso Movimentar Estoque ........................................... 77

Figura 4.7 - Requisito 8 (oito) referente a movimentao de estoque ...................................... 78 Figura 4.8 - Requisito 10 (dez) referente ao registro de vendas. .............................................. 79 Figura 4.9 - Diagrama de casos de uso com a modelagem das regras de negcio ................... 83 Figura 4.10 - Regra de negcio projetada como aspecto .......................................................... 87 Figura 4.11 - Regra de Negcio candidata a aspecto ............................................................... 88 Figura 4.12 - Diagrama de Classes. .......................................................................................... 89 Figura A.1 Exemplo de conjunto de juno. ....................................................................... 101 Figura A.2 Exemplo de um adendo do tipo around............................................................. 103 Figura A.3 Exemplos de declarao intertipos .................................................................... 104

LISTA DE TABELAS

Tabela 1.1 Classificao das Regras de Negcio .................................................................. 23 Tabela 3.1 - Atividades da extenso do PU proposta ............................................................... 51 Tabela 3.2 - Exemplo da seo fluxos alternativos .................................................................. 57 Tabela 3.3 - Exemplo de Pr-Condies .................................................................................. 58 Tabela 3.4 - Exemplo de Ps-Condies .................................................................................. 59 Tabela 3.5 Critrios para a classificao das Regras de Negcio ......................................... 62 Tabela 3.6 - Exemplo do Artefato Lista de Regras Preenchido ............................................... 63 Tabela 3.7 - Diretrizes de apoio para anlise do ponto de atuao .......................................... 64 Tabela 4.1 Lista de Regras parcialmente preenchida ............................................................ 81 Tabela 4.2 - Lista de Regras totalmente preenchida. ................................................................ 85 Tabela A.1 Pontos de juno dinmicos do AspecJ (adaptado de Kiczales et al., 2001b) ... 99 Tabela A.2 Designadores disponveis em AspectJ (Wink e Goetten Jr, 2006) ................... 101 Tabela A.3 Tipos de adendos disponveis em AspectJ (Wink e Goetten Jr, 2006) ............. 102

SUMRIO

INTRODUO ...................................................................................................................... 15 CONTEXTUALIZAO ................................................................................................................ 15 MOTIVAO .............................................................................................................................. 16 OBJETIVO .................................................................................................................................. 17 ORGANIZAO .......................................................................................................................... 17 CAPTULO 1 REVISO BIBLIOGRFICA .................................................................. 19 1.1. REGRAS DE NEGCIO .......................................................................................................... 19 1.1.1. A UTILIZAO DE REGRAS DE NEGCIO NA ENGENHARIA DE SOFTWARE ....................... 20 1.1.2. CLASSIFICAO DAS REGRAS DE NEGCIO ..................................................................... 23 1.1.3. PRINCPIOS BSICOS DAS REGRAS DE NEGCIO ............................................................... 26 1.1.4. PRINCPIOS PARA A IMPLEMENTAO DE REGRAS DE NEGCIO ...................................... 27 1.2. UML .................................................................................................................................. 28 1.2.1. MODELO CONCEITUAL DA UML ...................................................................................... 28
A. B. C.

DIAGRAMA DE CASOS DE USO ..................................................................................... 30 DIAGRAMA DE CLASSES .............................................................................................. 30 DIAGRAMA DE SEQNCIA .......................................................................................... 31

1.2.2. EXTENSES UML ............................................................................................................ 33 1.3. PROGRAMAO ORIENTADA A ASPECTOS .......................................................................... 37 1.4. CONSIDERAES FINAIS ..................................................................................................... 40 CAPTULO 2 TRABALHOS RELACIONADOS ........................................................... 41 2.1. GERENCIAMENTO DE REGRAS DE NEGCIO ........................................................................ 41 2.2. SISTEMAS GERENCIADORES DE REGRAS DE NEGCIO ........................................................ 44 2.3. REGRAS DE NEGCIO E ASPECTOS ...................................................................................... 47 2.4. CONSIDERAES FINAIS ..................................................................................................... 47 CAPTULO 3 PROJETO DE SOFTWARE COM REGRAS DE NEGCIO ............. 49 3.1. VISO GERAL DA ABORDAGEM .......................................................................................... 49 3.2. EXTENSO DO PROCESSO UNIFICADO ................................................................................. 50

3.2.1 DISCIPLINA ANLISE ......................................................................................................... 51 3.2.1.1. ATIVIDADE: IDENTIFICAR E REGISTRAR CASOS DE USO ESSENCIAIS ............................ 52 3.2.1.2. ATIVIDADE: DOCUMENTAR CASOS DE USO COM GABARITO ........................................ 52
A) B) C) D)

FLUXO ALTERNATIVO ................................................................................................. 53 PR-CONDIES .......................................................................................................... 57 PS-CONDIES .......................................................................................................... 58 GATILHOS.................................................................................................................... 59

3.2.1.3. ATIVIDADE: CLASSIFICAR E REGISTRAR REGRAS DE NEGCIO .................................... 61 3.2.1.4. ATIVIDADE: REFINAR VISO
DO

DIAGRAMA

DE

CASOS

DE

USO

PARA

REGRAS

DE

NEGCIO ................................................................................................................................... 65 3.2.2. DISCIPLINA PROJETO ....................................................................................................... 66 3.2.2.1. ATIVIDADE: DEFINIR PARADIGMA DE PROJETO DAS REGRAS ....................................... 67 3.2.2.2. ATIVIDADE: PROJETAR AS REGRAS DE NEGCIO NO DIAGRAMA DE CLASSES .............. 68 3.3. RASTREAMENTO DAS REGRAS DE NEGCIO........................................................................ 70 3.4. CONSIDERAES FINAIS ..................................................................................................... 70 CAPTULO 4 ESTUDO DE CASO ................................................................................... 73 4.1. DEFINIO .......................................................................................................................... 73 4.2. EXECUO .......................................................................................................................... 74 4.2.1. DOCUMENTAR CASOS DE USO COM GABARITO ............................................................... 75 4.2.2. IDENTIFICAR E CLASSIFICAR REGRAS DE NEGCIO ......................................................... 80 4.2.3. REFINAR DIAGRAMAS DE CASO DE USO .......................................................................... 82 4.2.4. DEFINIR PARADIGMA DE PROJETO DAS REGRAS DE NEGCIO ......................................... 84 4.2.5. PROJETAR REGRAS DE NEGCIO NO DIAGRAMA DE CLASSES .......................................... 86 4.2.6. IMPLEMENTAR AS REGRAS DE NEGCIO .......................................................................... 88 4.3. CONSIDERAES FINAIS ..................................................................................................... 90 CONCLUSES....................................................................................................................... 91 PRINCIPAIS CONTRIBUIES ...................................................................................................... 91 LIMITAES .............................................................................................................................. 92 TRABALHOS FUTUROS ............................................................................................................... 92 REFERNCIAS ..................................................................................................................... 93

ANEXO A ................................................................................................................................ 96 APNDICE A ......................................................................................................................... 98 A1. LINGUAGENS DE SUPORTE PROGRAMAO ORIENTADA A ASPECTOS ............................. 98 A2. NOVAS CONSTRUES POA ............................................................................................... 99 A2.1. PONTOS DE JUNO ......................................................................................................... 99 A2.2. CONJUNTOS DE JUNO ................................................................................................. 100 A2.3. ADENDOS ....................................................................................................................... 102 A2.4. MODIFICAO DE ESTRUTURAS ESTTICAS .................................................................. 103 A2.5. ASPECTOS ...................................................................................................................... 104 APNDICE B........................................................................................................................ 106 B1. VISO GERAL DO SISTEMA ............................................................................................... 106 B2. REQUISITOS FUNCIONAIS .................................................................................................. 106 B2.1. CADASTROS ................................................................................................................... 106 B2.2. LANAMENTOS DIVERSOS ............................................................................................. 107 B2.3. CONSULTAS ON-LINE...................................................................................................... 110 B2.4. IMPRESSO DE DIVERSOS TIPOS DE RELATRIOS E CONSULTAS ...................................... 111 B3. REQUISITOS NO FUNCIONAIS .......................................................................................... 112 B3.1. CONFIABILIDADE ........................................................................................................... 112 B3.2. EFICINCIA ..................................................................................................................... 113 B3.3. PORTABILIDADE ............................................................................................................. 113 APNDICE C ....................................................................................................................... 114 C1. CASO DE USO ABRIR CAIXA .............................................................................................. 114 C2. CASO DE USO FECHAR CAIXA ........................................................................................... 114 C3. CASO DE USO GERAR VENDAS .......................................................................................... 115 C4. CASO DE USO MOVIMENTAR ESTOQUE ............................................................................. 117 C5. CASO DE USO GERAR PAGAMENTO DE DOCUMENTOS ....................................................... 117 C6. CASO DE USO INFORMAR RECEBIMENTO DE DUPLICATAS ................................................. 118 C7. CASO DE USO CADASTRAR RECEBIMENTO DE PRODUTOS ................................................. 119

15

INTRODUO Contextualizao
No decorrer da dcada de 1980 surgiu o conceito que classifica os termos, polticas, restries e aes afetando o comportamento de uma organizao. Esse conceito foi denominado de regras de negcio, e foi considerado um elo perdido, pois passou a fornecer uma ligao entre dois nveis de abstrao distintos: a arquitetura de dados de alto nvel e o projeto de dados de nvel fsico. O objetivo principal de tais regras era estabelecer maneiras restritivas de manipular os dados do negcio, fornecendo meios adicionais de melhorar a consistncia desses dados, e estabelecendo uma ligao entre a estrutura de dados e a estrutura de processamento (Appleton, 1984). O uso de regras de negcio1 dentro do contexto de Sistema de Informao2 tem despertado grande interesse no meio acadmico, e com isso diversas linhas de pesquisas tm surgido, apontando a necessidade de buscar formas de integrao dessas regras, que geralmente so oriundas de processos organizacionais, com os sistemas de informao (Yu et al., 1995; Cibrn et al., 2006; Korthaus, 1998; Von Halle, 2002; Bajec e Krisper, 2004)). As regras de negcio podem estar presentes no software de diversas maneiras; podem estar implcitas em seu cdigo, nas estruturas de dados, ou como gatilhos (triggers) e procedimentos armazenados (stored procedures) do banco de dados, mas, tambm podem estar projetadas de outras maneiras, usando diversos formatos de representao. A utilizao das tcnicas e mtodos da engenharia de software no projeto de regras de negcio faz com que elas sejam mais bem manipuladas e gerenciadas, resultando em softwares mais manutenveis, e que possam responder de forma mais adequadas s freqentes alteraes exigidas pelo ambiente de negcio. Como exemplos dessas alteraes podem-se citar as mudanas de polticas, de leis e procedimentos, bem como os constantes rearranjos em busca de melhores mtodos de gesto (Bajec e Krisper, 2004). Muitos pesquisadores esto

Como explicado no prximo captulo, regras de negcio (RNs) so diretivas cujo objetivo influenciar ou guiar o comportamento de um negcio (Ross, 2003). Dentro do contexto de Sistemas de Informao, regras de negcio a parte do software responsvel pela definio do comportamento do software, ou como ele deve operar (Date, 2000).
2

Sistema de informao um software desenvolvido com o objetivo de apoiar as operaes de negcio realizadas por uma empresa.

16 convencidos que a natureza voltil das regras de negcio frente s mudanas do negcio requer um tratamento explcito durante o desenvolvimento de sistemas de informao (Bajec e Krisper, 2004; Ross, 2003; Von Halle, 2002). Recentemente o surgimento da programao orientada a aspectos (POA) mudou a viso da integrao das regras de negcio com o ncleo do software 3, uma vez que forneceu meios para a implementao das regras de forma desvinculada do ncleo do software, possibilitando sua integrao de forma no invasiva ao cdigo, em um artefato independente, por meio dos novos construtores oferecidos nesse paradigma (Cibrn et al.,2003). O projeto das regras de negcio de forma desvinculada e independente do ncleo do software um dos princpios desejveis ao projeto das regras de negcio (Ross, 2003; Von Halle, 2002). Assim, surgiram alguns trabalhos que mostram a utilizao da orientao a aspectos como apoio a essa implementao (Cibrn et al., 2003; Cibrn et al., 2004; Camargo e Masiero, 2005). O conceito difundido por esses trabalhos foi a implementao do cdigo referente regra de negcio por meio de mdulos especficos (classes), no paradigma orientado a objetos, e a conexo com o ncleo do software por meio do paradigma orientado a aspectos.

Motivao
A motivao principal deste trabalho a carncia de mtodos e tcnicas adequadas para o tratamento de regras de negcio nas atividades de anlise e projeto do software. Notase tambm na literatura especializada, a ausncia de critrios para a identificao e classificao das regras de negcio que auxiliem a modelagem dessas regras de forma independente do ncleo do software. Tambm no foram encontrados trabalhos que apresentem uma notao precisa para representar regras de negcio nas fases de anlise e projeto do software. Outro ponto que merece destaque no projeto de regras de negcio com Orientao a Aspectos (OA), j que, apesar de alguns trabalhos sugerirem o projeto das regras de negcios com POA, em nenhum deles apresentada uma diretriz clara de quais tipos de regras de negcios so adequadas de serem projetadas com esse paradigma.

No contexto desse trabalho, ncleo do software a sua parte base, responsvel pela implementao das caractersticas funcionais do software.

17 Dessa forma, nota-se ausncia de um conjunto de mecanismos que propiciem as tcnicas e artefatos necessrios ao tratamento das regras de negcio durante as atividades de anlise e projeto do software.

Objetivo
O objetivo deste trabalho fornecer mecanismos ao engenheiro de software para realizar atividades de identificao, de classificao e de modelagem de regras de negcio, resultando em artefatos de software independentes e rastreveis, aumentando assim a capacidade de modularizao e de adaptabilidade do software. Deve ser feita dessa forma, tendo em vista que manutenes e adaptaes ocorrem mais freqentemente nas regras de negcio do que no ncleo de software (Von Halle, 2002; Ross, 2003). Para isso, sugerida uma abordagem baseada em uma extenso do Processo Unificado (Unified Process), originalmente proposto por Jacobson et. al (1999), com a finalidade de manipular de forma mais adequada as regras de negcio durante o desenvolvimento de softwares. Essa extenso baseada em um gabarito (template) para o registro dos casos de uso, cuja utilizao apia a identificao das regras de negcio. Alm disso, so estabelecidos critrios para a identificao e classificao das regras de negcio a partir dos requisitos do projeto de software. Numa outra atividade, so estabelecidos critrios para a identificao de regras de negcio que devem ser projetadas com OA. Como apoio ao projeto das regras de negcio/aspectos sugerido o uso de uma notao especfica, proposta por Pawlak et al. (2002), bem como o uso de esteretipos para apoiar a modelagem de casos de uso e mtodos que representam regras de negcio.

Organizao
Esta monografia apresentada em quatro captulos, alm desta introduo e da concluso. Nessa primeira parte apresentada a contextualizao da convergncia do conceito de regras de negcio com a engenharia de software. apresentada tambm a motivao deste trabalho, bem como seu objetivo. Os prximos captulos esto organizados da seguinte forma: no Captulo 1 so apresentados os conceitos relevantes para a proposta deste trabalho. No Captulo 2 so

18 descritos os principais trabalhos relacionados a este, bem como os conceitos utilizados. No Captulo 3 apresentada a abordagem proposta neste trabalho destacando as principais sugestes de melhorias. No Capitulo 4 apresentado um Estudo de Caso visando ilustrar a prtica da abordagem proposta. E por fim so apresentadas as concluses finais e as propostas de trabalhos futuros.

19

CAPTULO 1 REVISO BIBLIOGRFICA

Neste captulo so apresentados os conceitos relevantes para a proposta deste trabalho. Na Seo 1.1 discutida a definio e os principais conceitos de regras de negcio, na Seo 1.2 apresentada a UML (Unified Modeling Language), seus principais diagramas e seu mecanismo de extenso e na Seo 1.3 discutido o conceito de programao orientada a aspectos, com nfase na Linguagem AspectJ

1.1. Regras de Negcio

Segundo Ross (2003), regras de negcio (RNs) so diretivas cujo objetivo influenciar ou guiar o comportamento de um negcio. Para o Business Rules Group (2000), RNs so declaraes que definem ou restringem algum comportamento de um negcio. Ainda para o Business Rules Group (2000), uma RN expressa restries especficas na criao, atualizao ou remoo de dados persistentes em um sistema de informao. Numa definio mais detalhada, Wiegers (2006) afirma que RNs so polticas da companhia, padres de indstria ou leis e regulamentaes governamentais que definem, restringem ou governam alguns comportamentos de um negcio. Todas as definies aqui apresentadas convergem para pontos comuns. Para ilustrar de uma forma mais prtica, Date (2000) cita que um sistema de informao, que implementa alguma funo de negcio, pode ser dividido em trs partes, sendo elas: 1. Funcionalidades de Apresentao 2. Funcionalidades de Banco de Dados 3. Funcionalidades especficas da funo de negcio em si. Com base nessa diviso de um sistema de informao, a terceira parte contm as RNs do software, e, fica claro que as duas primeiras partes foram largamente automatizadas, mas a terceira parte necessita, ainda hoje, de muita codificao para que a implementao das funcionalidades especficas da funo de negcio seja possvel (Date, 2000). Ainda segundo Date (2000), RNs, dentro do contexto de Sistemas de Informao, a parte do software responsvel pela definio do comportamento do software, ou como ele deve operar. Nos ltimos anos a relao entre as RNs e a engenharia de software gerou duas linhas distintas de pesquisa, a primeira, foca a obteno e representao sistemtica das RNs

20 por meio de vrias tcnicas, como: a linguagem natural, Object Constraint Language (OCL), eXtensible Markup Language (XML), Lgica de Primeira Ordem (LPO), entre outras (Martins, 2006; Morgado 2005). O objetivo primrio dessa linha de pesquisa a obteno das RNs pelos especialistas de negcios, sua posterior traduo para uma representao computacional e sua integrao com os sistemas de informao da empresa pelo cdigo gerado. A integrao ocorre por meio de ferramentas que geram cdigos para linguagens especficas, ou por meio de Sistemas Gerenciadores de Regras, que oferecem mecanismos de integrao das regras especificadas, em um ambiente prprio, com o software desenvolvido. Numa outra linha esto 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 modularizao, propiciando uma melhor adaptabilidade e manuteno ao software. Dentro dessa linha, existem ainda as pesquisas que buscam a integrao de RNs, codificadas separadamente do ncleo do software, por meio de programao orientada a aspectos. Para o foco dado a esse trabalho, ser explorada essa segunda linha de pesquisa. Um elemento sempre presente na ilustrao do envolvimento entre RNs e sistemas de informao um framework proposto por Zachman (1997). Na prxima seo ser detalhado como esse framework forneceu fundamentao para a relao entre RNs e sistemas de informao.

1.1.1. A utilizao de Regras de Negcio na Engenharia de Software

Boa parte do enquadramento das RNs no processo de desenvolvimento de software, ou mesmo, o enquadramento das RNs com relao s atividades das corporaes 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 utilizao 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 representao do Framework de Zachman, que um conjunto de representaes, sob diferentes perspectivas, das atividades existentes no processo

21 de desenvolvimento de software (Zachman, 1997). Para viabilizar essa representao, o autor elaborou esse framework focando a ilustrao do processo de desenvolvimento de software, no qual as linhas representam as diferentes perspectivas ou papis e as colunas representam as diferentes caractersticas, ou abstraes, do produto em questo. Zachman (1997) argumenta que o estado da arte de modelagem de RNs, que utilizada na coluna Motivao (Motivation), limitado. Argumenta ainda que fato comum encontrar essas regras expressas em estrutura de dados ou cdigo procedural, que no fornecem o subsdio necessrio para que o planejamento e modelagem dessas regras ocorram de forma adequada. O autor argumenta, por meio desse trabalho, que quando as presses competitivas do mercado forarem melhor integrao das RNs com o software, para que respondam em tempo hbil s presses competitivas, elas comearo a ser tratadas nos modelos arquiteturais de processos, passando a serem mais bem definidas e gerenciadas. Esse trabalho serviu para mostrar a importncia e a necessidade das RNs na organizao 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 negcio, e o modelo de RNs que havia sido abordado por Zachman (1997), tratando assim sua melhor definio, classificao e utilizao. Para isso, ambos os trabalhos focaram as linhas de um a trs (Planner a Designer) do framework proposto por Zachman. Com isso as RNs foram classificadas em duas categorias extradas do framework do Zachman: i) as de negcio, que focam mais a linha dois (owner), e ii) as de sistema de informao, focada na linha trs (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 negcio. Na prxima seo detalhada essa classificao.

22

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

23

1.1.2. Classificao das Regras de Negcio

Na literatura sobre RNs possvel encontrar diversas formas de classific-las. Cada autor utiliza a classificao que julga mais adequada ao propsito em questo. Na Tabela 1.1 so mostrados alguns exemplos de classificao de Regras de Negcio por diferentes autores.
Tabela 1.1 Classificao das Regras de Negcio Origem Business Rules Group (2000) Esquema de Classificao Declaraes Estruturais o Termos o Fatos Declaraes de Ao o Autorizao o Condio o Restrio de Integridade Derivaes o Clculo Matemtico o Inferncia Restrio Restrio de Estado Restrio de Transio Estmulo/Resposta Derivao Computao Inferncia No mesmo trabalho ainda apresentado um segundo esquema de classificao: Restries de Domnio Restries de Coluna Restries de Tabela Restries de Banco de Dados Restries Derivaes Inferncia Temporizao Seqncia Heurstica Restries o Restries (Ao Restritiva) o Diretrizes (Ao Informativa) Habilitadoras de Aes Derivao o Computao o Inferncia

C. J. Date (2000)

Ross (2003)

Von Halle (2002)

Nessa tabela pode-se comprovar que os autores direcionam a forma de classificao de acordo com seu propsito. Sendo assim a classificao proposta por C. J. Date (2000) est mais focada aos interesses de banco de dados, enquanto a classificao do Business Rules

24 Group (2000) mais genrica, preocupando inclusive com a estrutura que compe as RNs. A classificao proposta por Ross (2003) visa estruturar as regras de modo a facilitar a aplicao de sua abordagem. E por fim, a proposta de Von Halle (2002) a mais concisa e considera as caractersticas funcionais das RNs sem, contudo, esquecer das diferenas estruturais entre os tipos propostos. Alm disso, essa classificao pode ser considerada como uma sntese de outros tipos de classificao e possui foco nos tipos de regras que normalmente so utilizados em sistemas de informao. Normalmente, outros tipos de classificao tm seu foco na forma como as regras so implementadas, ou onde elas sero armazenadas. Dessa forma, para este trabalho ser utilizada a classificao proposta por Von Halle (2002), mostrada na Figura 1.2, na qual uma RN pode ser uma restrio, uma diretriz, uma habilitadora de aes, ou uma derivao (por computao ou inferncia). As RNs do tipo Restries expressam um comportamento restritivo, ou seja, expressam uma circunstncia que deve ser verdadeira ou deve ser falsa para que um evento de negcio possa ser completado com a integridade desejada (Von Halle, 2002). Geralmente as regras de restrio ocorrem de forma independente da execuo do software, refletindo uma restrio que s importante no mbito do negcio, e no para a integridade do software em si. As RNs do tipo Diretriz so definies que expressam uma advertncia sobre uma circunstncia de negcio que faz com que alguma ao humana, ou de qualquer outro tipo que esteja fora do escopo do software, seja executada sem, contudo, restringir a execuo do software. As RNs do tipo Habilitadora de Aes so mecanismos que verificam uma determinada condio e caso ela seja verdadeira inicia uma nova ao no software. As RNs do tipo Derivao (por computao ou inferncia) resultam na criao de um novo trecho de informao que, em termos de banco de dados, pode ser uma nova instncia de uma entidade, ou uma nova instncia de um atributo. Para que a derivao ocorra necessrio que seja implementado o mecanismo de derivao com o mapeamento que ser aplicado s informaes bases para a extrao das informaes derivadas. A classificao das RNs auxilia em seu projeto e implementao, uma vez que agrupa as RNs com caractersticas semelhantes e que devem exercer o mesmo papel na execuo de um sistema de informao. As RNs possuem uma estrutura base que independe da forma como so classificadas, elas sempre so compostas de termos e fatos.

25
Regra de Negcio

Informaes restritivas de interesse aos eventos de negcio

Habilita outras aes de interesse aos eventos de negcio

Cria novas informaes de interesse aos eventos de negcio

Restries

Diretrizes

Habilitadoras de aes

Computao

Inferncia

Figura 1.2 - Classificao das Regras de Negcio

Os termos e fatos estruturam o conhecimento bsico do negcio (Ross, 2003). Eles definem o significado dos termos usados no dia-a-dia de uma organizao e estabelecem possveis aes que permeiam as operaes de um negcio. Termo uma palavra ou frase simples, em linguagem natural, que deve ser reconhecida e compartilhada no mbito do negcio. O termo no deve ser ambguo e deve oferecer um significado particular ao negcio. Todos os fatos e regras, que referenciem o termo, dependem de seu significado, assim, mais importante o conceito de negcio que ele representa do que o prprio significado da palavra. Para que um termo possa ser usado ele precisa possuir trs caractersticas (Ross, 2003): Bsico: Termos no podem ser derivados ou associados a outros termos. Atmico: Termos devem representar conceitos indivisveis. 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 organizao ou pessoa individual que colocou um pedido e realizou um pagamento nos ltimos dois anos. Fatos so sentenas declarativas que relacionam termos apropriados. Os fatos devem ser expressos utilizando-se de sentenas completas, que devem meramente estabelecer o fato sem qualquer restrio.

26 Como exemplos de fato, pode-se citar: Consumidores colocam pedidos, Funcionrio tem um gerente ou Gerente uma categoria de funcionrio. Os fatos podem ser classificados como Base ou Derivados. Um fato Base o registro de algo existente no mundo real. Um fato Derivado uma declarao que construda a partir de outras declaraes, e, s pode existir sendo criado a partir da aplicao de uma regra de derivao (que ser definida nas prximas subsees). 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 so tipos fundamentais de requisitos.

1.1.3. Princpios Bsicos das Regras de negcio

Existem alguns princpios que devem ser observados para se lidar com RNs. Ross (2003), durante a explanao sobre sua abordagem de RNs, mostra os princpios bsicos das RNs, que funcionam como um guia para a elaborao correta dessas regras dentro do contexto de negcio, como segue: Regras devem ser escritas de forma explcita; Regras devem ser expressas em linguagem clara; Regras devem existir independentemente de procedimentos e workflows; Regras devem ser construdas sobre fatos, e os fatos devem ser construdos sobre conceitos representados por termos; Regras devem guiar ou influenciar comportamentos da maneira prevista; Regras devem ser movidas por fatores de negcio identificveis 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 princpio, no menos importante, sobre RNs que por sua natureza, as RNs esto em constante mudana devido s influncias sofridas, sejam elas influncias internas ou externas organizao.

27

1.1.4. Princpios para a Implementao de Regras de Negcio

A metodologia de RNs proposta por Von Halle (2002), defende que os softwares que implementam RNs devem sempre manter separados trs elementos do software: regras, dados e processos. Considerando que o foco dessa metodologia so as regras, nela a autora defende que todo software que incorpora conceitos de RNs (e em sua opinio todos os softwares que manipulam informaes coorporativas deveriam incorpor-los) deve respeitar alguns princpios bsicos que tem por objetivo garantir a separao e gerenciamento das RNs, algo que geralmente negligenciado nas metodologias tradicionais de desenvolvimento de software. Esses princpios so: 1. Separao (Separate): As RNs devem ser projetadas de forma separada do ncleo do software. Esse princpio busca incentivar o reso das regras e possibilitar que elas possam ser alteradas independentemente de outras caractersticas do sistema; 2. Rastreamento (Trace): As RNs devem possuir uma rastreabilidade que permita identificar os artefatos de software utilizados para sua implementao, com isso, o impacto sobre a alterao de uma regra pode ser mensurado. Alm disso, esse princpio apia as tarefas de manuteno do sistema; 3. Exteriorizao (Externalize): Toda a regra deve ser expressa num formato compreensvel para que seja possvel a realizao de auditorias de negcio, por pessoas no-tcnicas; 4. Posicionamento (Position): As RNs devem estar preparadas para mudanas, uma vez que por meio das regras pode-se mudar o curso regular do negcio. Em resumo, deve ser possvel alterar-se uma RN de forma fcil e rpida. Na definio da metodologia de RNs, Von Halle (2002) salienta que a abordagem orientada a objetos no est preparada para respeitar esses quatro princpios das RNs. A opinio da autora semelhante a outras opinies encontradas, como a dos autores Bajec e Krisper (2004) que salientam que nos modelos orientados a objetos no existe um consenso sobre onde acomodar as RNs, o que faz com que as RNs fiquem espalhadas pelo cdigo, sendo muitas vezes projetadas como mtodos das classes, tornando-se o ponto fraco dos sistemas desenvolvidos. No trabalho de Korthaus (1998), embora o autor no cite explicitamente os princpios de projeto de RNs, ele cita a importncia das RNs serem modeladas e implementadas de forma independente, o que favoreceria a manuteno e seu gerenciamento, j que impediria que as RNs ficassem espalhadas pelo cdigo do software.

28 Dessa forma entende-se que a opinio expressada por Von Halle (2002) reflete o cenrio 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 princpios 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 mdulo de software separado do ncleo, permitindo uma acesso rpido na manuteno, ou evoluo, dessas regras. Todavia, para o cumprimento dos princpios 2 e 3 necessrio 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.

1.2. UML
A primeira verso completa e padronizada da UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) surgiu em janeiro de 1997, oriunda da fuso dos mtodos Booch, OMT de Rumbaugh e OOSE de Jacobson (Booch et al., 2000). A UML uma linguagem-padro para a elaborao 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 especificao da anlise de requisitos at a fase de testes (Booch et al., 2000). Seu objetivo descrever qualquer tipo de sistema, utilizando-se de diagramas de representao dos mesmos.

1.2.1. Modelo conceitual da UML

O vocabulrio da UML abrange trs tipos de blocos de construo: itens, relacionamentos e diagramas. Os itens so as abstraes em um modelo, os relacionamentos renem esses itens e os diagramas agrupam colees dos itens (Booch et al., 2000).

29 Segundo Booch et al. (2000), os itens podem ser subdivididos em quatro tipos, sendo eles: estruturais, comportamentais, de agrupamento e de anotao, como seguem: Estruturais: so os substantivos utilizados em modelos da UML, so as partes mais estticas dos modelos. Ao todo existem sete tipos de itens estruturais: classes, interfaces, colaboraes, caso de uso, classes ativas, componentes e ns. Comportamentais: so as partes dinmicas dos modelos UML, podem ser considerados os verbos de um modelo, representando comportamentos. Os itens comportamentais so dois: interao e mquina de estado. De Agrupamento: so as partes organizacionais dos modelos UML, so os blocos em que os modelos podem ser compostos. Existe apenas um tipo principal de itens de agrupamentos, os pacotes. De Anotao: so as partes explicativas dos modelos de UML, so os comentrios includos para descrever, esclarecer e fazer alguma observao sobre qualquer elemento do modelo. Existe um nico tipo de item de anotao, as notas. Outro bloco de construo da UML so os relacionamentos. Eles interligam as classes e objetos estabelecendo uma relao lgica entre elas. Eles tambm se subdividem em quatro tipos, sendo: dependncia, associao, generalizao e realizao. Por fim, sero abordados os diagramas da UML, que so os grficos que descrevem a visualizao 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 seqncias e. Diagrama de colaboraes f. Diagrama de grficos de estados g. Diagrama de atividades h. Diagrama de componentes i. Diagrama de implantao Para o escopo desse trabalho, trs diagramas tm especial importncia, e, devero ser utilizados em seu desenvolvimento, so eles: diagrama de casos de uso, diagrama de classes e

30 diagramas de seqncia. Assim, nas prximas subsees cada diagrama ser descrito de forma mais detalhada.

a. Diagrama de Casos de Uso

Os diagramas de casos de uso so diagramas para a modelagem de caractersticas dinmicas 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 acessveis, melhor compreendidos, por apresentarem uma viso externa sobre os elementos utilizados no contexto. Os diagramas de casos de uso so 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 especificao de um conjunto de seqncias de aes, incluindo variantes realizadas pelo sistema para produzir um resultado observvel pelo ator, sem ser necessrio especificar como esse comportamento ser implementado. Esses comportamentos so funes em nvel de sistema, utilizada para visualizar, especificar, construir e documentar o comportamento pretendido do sistema durante a captao e anlise de requisitos (Booch et al., 2000). Um caso de uso representado por uma elipse contendo seu nome, sendo que o nome formado por expresses verbais ativas que reflitam o comportamento do caso de uso. Normalmente, um caso de uso envolve a interao dos atores com o sistema (Booch et al., 2000). Um ator representa um conjunto coerente de papis que os usurios 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 podero estar conectados aos casos de uso por meio dos relacionamentos de dependncia, generalizao e associao. Na Figura 1.3 mostrada a estrutura bsica de um diagrama de caso de uso, por meio de um exemplo simples.

b. Diagrama de Classes
No diagrama de classes so apresentados um conjunto de classes, interfaces e colaboraes e seus relacionamentos (relacionamentos de dependncia, generalizao e associao) (Booch et al., 2000).

31 Uma classe uma descrio de um conjunto de objetos com os mesmos atributos, relacionamentos, operaes e semntica. Toda classe dever ter nome que a distinga das outras classes. Ela tambm caracterizada como um classificador. Classificador um mecanismo que descreve caractersticas estruturais e comportamentais. Os classificadores incluem classes, interfaces, tipos de dados, sinais, componentes, ns, casos de uso e subsistemas (Booch et al., 2000). O classificador tem caractersticas avanadas, possibilitando a modelagem da multiplicidade, da visibilidade, das assinaturas, do polimorfismo e de outras caractersticas (Booch et al., 2000).

Figura 1.3 Diagrama de Caso de Uso (Booch et al., 2000)

Ao se fazer a modelagem das caractersticas comportamentais de uma classe definese suas operaes e sinais. O nome de uma operao juntamente com seus parmetros (incluindo seu tipo de retorno) chamado de assinatura da operao (Booch et al., 2000). Na UML alm da modelagem dos itens que formam o vocabulrio do sistema tambm devem ser modelados os relacionamentos entre esses itens (Booch et al., 2000). Na modelagem orientada a objetos os quatro relacionamentos mais importantes so: dependncias, generalizaes, associaes e realizaes. Podendo ser feita modelagem de heranas mltiplas, navegao, refinamentos e outras caractersticas (Booch et al., 2000). Na Figura 1.4 apresentado o diagrama de classes com as respectivas caractersticas estticas dos blocos de construo e seus relacionamentos.

c. Diagrama de Seqncia

32 O diagrama de seqncia um diagrama de interao que d nfase ordenao 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 1.4 - Diagrama de Classes (Booch et al., 2000)

Conforme exemplificado na Figura 1.5, o diagrama de seqncia formado colocando-se os objetos que participam da interao na parte superior do diagrama, seguindo o eixo X. O objeto que inicia o primeiro esquerda, e os objetos que sero instanciados no decorrer da interao vo aparecendo direita. Em seguida, as mensagens que esses objetos enviam e recebem so distribudas ao longo do eixo Y, em ordem crescente de tempo de cima para baixo (Booch et al., 2000). Uma das caractersticas do diagrama de seqncia a representao do foco de controle. Sempre que um objeto criado no diagrama, inicia-se sua linha de vida, que uma

33 linha tracejada vertical que representa a existncia do objeto (Booch et al., 2000). No decorrer de sua linha de vida, so criados retngulos altos e estreitos que representam os perodos que o objeto est desempenhando alguma ao. Assim, sempre que um objeto recebe uma mensagem, iniciando uma ao, um retngulo iniciado, terminando com a concluso da ao, que pode ser marcada por uma mensagem de retorno (Booch et al., 2000).

Figura 1.5 Diagrama de Seqncia (Booch et al., 2000)

O diagrama de seqncia utilizado para a modelagem das caractersticas dinmicas do sistema, que podem envolver qualquer tipo de instncia de um sistema. Podem-se anexar os diagramas de seqncia aos casos de uso, para assim, realizar a modelagem de um cenrio. Como define Larman (2007), um diagrama de seqncia de sistema deve ser feito para a seqncia tpica de eventos de casos de uso, e, possivelmente, outros diagramas de seqncia para as outras seqncias alternativas mais interessantes.

1.2.2. Extenses UML

Segundo Rumbaugh et al. (1998), a UML foi concebida para ser usada com diversos propsitos, e, embora ela seja uma linguagem universal que pode expressar um grande nmero de propriedades fundamentais de modelagem, algumas vezes pode ser desejvel uma linguagem que se adapte a um domnio especfico. A UML pode ser adaptada usando-se diversos mecanismos, como: convenes, regras de estilo, classes pr-definidas e mapeamento implcito para software. A UML oferece, ainda, extenses, chamadas de perfis (profiles), que podem ser definidas com o uso de:

34 esteretipos (stereotypes), restries (constraints) e valores atribudos (tagged values) (Rumbaugh et al., 1998). Um perfil uma coleo de definies de esteretipos, valores atribudos e restries relevantes para especificar um domnio ou propsito (Alhir, 2003). O perfil formado por elementos de modelos, estendidos a partir dos elementos padro da UML. Um perfil pode ser reusado em outros projetos do mesmo domnio. Os perfis possuem como restrio o fato de que eles devem ser estritamente aditivos para a semntica padro da UML (Pender, 2003), dessa forma esses perfis no devem conflitar ou contradizer a semntica padro da UML. As extenses permitem que a UML se adapte a novas tecnologias, porm essas extenses devem ser usadas de forma criteriosa, uma vez que a prpria linguagem proposta oferece muitas construes expressivas. Assim, essas extenses devem ser evitadas, uma vez que, por definio, uma extenso serve a uma comunidade especfica, e pode conduzir ao engano as demais comunidades. Por outro lado, o poder expressivo de uma extenso pode compensar a perda da uniformidade. Com o tempo, as extenses podem tornar-se teis o suficiente para serem adicionadas UML padro, ou cair no esquecimento (Rumbaugh et al., 1998). Segundo OMG (2005), possvel estender a UML de duas maneiras: extenses lightweight e extenses heavyweight. As extenses lightweight so extenses mais leves e apenas estendem as metaclasses j existentes na UML padro, assim, nesse tipo de extenso apenas so criados esteretipos, restries e valores atribudos. As extenses heavyweight so extenses mais pesadas e que alteram o metamodelo em si, criando novas metaclasses no metamodelo padro da UML. A UML possui uma arquitetura definida com um esquema chamado de Metamodelo de Arquitetura Quatro Camadas que engloba quatro diferentes nveis de abstrao (Alhir, 2003). Cada camada define elementos, conceitos e relaes entre conceitos, como segue: Camada meta-metamodelo ou camada nvel M3: Essa camada define a base para a arquitetura do metamodelo, a responsabilidade primria dessa camada definir a linguagem para a especificao do metamodelo. Assim, essa camada define um modelo com maior nvel de abstrao que a camada de metamodelo. Exemplo de meta-metaobjetos definidos nessa camada so MetaClasse, MetaAtributo e MetaOperao. Camada metamodelo ou camada nvel M2: Essa camada uma instncia da camada M3, nela so definidos os conceitos de Classe, Atributo, Operao, Valor

35 de Atributo, Associaes, Ligaes, etc. A responsabilidade primria dessa camada definir a linguagem para a especificao de modelos. Nessa camada so includos todos os conceitos que compem a UML. Exemplos de metaobjetos definidos nessa camada so: Classe, Atributo, Operao e Componente. Camada modelo ou camada nvel M1: Essa camada uma instncia da camada M2, sua responsabilidade primria definir uma linguagem que descreve um domnio de informaes. Nessa camada so definidas classes especficas, atributos, ope raes e associaes, que compem os projetos dos usurios. Camada modelo de usurio ou camada nvel M0: Nessa camada so definidos os objetos, valor de atributos e ligaes, que compem os projetos de usurios. O primeiro elemento utilizado nas extenses UML o esteretipo, que usado para prover a extenso do vocabulrio padro da modelagem, ou para oferecer indicaes visuais distintivas para determinados tipos de abstraes (Booch et al., 2000). Um esteretipo define um novo tipo de elemento de modelagem na UML (Alhir, 2003). Para que um novo esteretipo seja criado necessrio que ocorra uma extenso de algum dos elementos padro de modelagem existente na UML, essa extenso deve ser realizada por meio de uma dependncia com a marca stereotype que estender uma das metaclasses existentes na UML. Na Figura 1.6 so mostrados dois exemplos de criao de esteretipos, no qual, criado um esteretipo Projeto a partir de uma extenso do metaobjeto Classe, e tambm um esteretipo Feito por a partir de uma extenso do metaobjeto Associao. Os metaobjetos Classe e Associao so parte da UML padro.

<<metaclasse>> Classe

<<metaclasse>> Associao

<<esteretipo>>

<<esteretipo>>

<<esteretipo>> Projeto

<<esteretipo>> Feito por

Figura 1.6 Definindo Esteretipos (Adaptado de Alhir, 2003)

36 Para aplicar um esteretipo criado, devem-se usar os novos elementos com seu novo tipo acima de seu nome. Na Figura 1.7 mostrado um exemplo de aplicao dos esteretipos criados na figura anterior, no qual, se cria os novos objetos Projeto de Desenvolvimento e Projeto de Infraestrutura que so instncias do novo metaobjeto Projeto criado anteriormente. Nesse mesmo exemplo nota-se tambm as associaes Feito por, que so instncias do novo metaobjeto Feito por criado anteriormente. O Valor Atribudo outro elemento das extenses UML, e estende as propriedades dos elementos padro da UML permitindo que novas propriedades sejam adicionadas. Com isso possvel inserir novas informaes s existentes no metamodelo da UML (Booch et al., 2000). Os valores atribudos podem ser adicionados a qualquer elemento do modelo. Valores atribudos so expressos na forma nome=valor. Exemplo: Ocorrncia=2. Em alguns locais do diagrama eles podem aparecer entre chaves, exemplo: {Ocorrncia=2} (Pender, 2003). <<Projeto>> Projeto de Desenvolvimento <<Projeto>> Projeto de Infraestrutura

<<Feito por>>

<<Feito por>>

Ambiente de Desenvolvimento

Ambiente de Distribuio

Figura 1.7 Aplicando Esteretipos no diagrama de classes (Adaptado de Alhir, 2003)

O ltimo elemento das extenses UML a Restrio. As restries so consideradas regras para um elemento do modelo, que so aplicadas a todo elemento em que os esteretipos so aplicados. Na UML as restries so definidas como textos que podem ser expressos em OCL, por meio de pseudo-linguagens, com linguagens de programao (por exemplo, C# ou C++) ou qualquer outro tipo de linguagem. Na Figura 1.8 mostrado um exemplo de extenso do metamodelo com restries. Nessa figura a metaclasse Projeto uma extenso da metaclasse Classe. Nessa extenso so adicionados alguns atributos no existentes na metaclasse original, como o atributo Data

37 Incio. Quando essa metaclasse estendida for instanciada em um modelo, esses atributos devero receber valores, e a restrio estabelecida dever ser respeitada.

<<metaclasse>> Classe

<<metaclasse>> Associao

<<esteretipo>>

<<esteretipo>>

<<esteretipo>> Projeto Data Incio: String, Data Trmino: String, {A Data Trmino deve ser igual ou maior que a Data Incio}

<<esteretipo>> Feito por {Descrio: String}

Figura 1.8 Esteretipos, valores atribudos e restries (adaptada de Alhir, 2003)

1.3. Programao 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 so aqueles relacionados com a funcionalidade principal do sistema e os interesses transversais (crosscutting concerns) so aqueles cuja implementao com tcnicas tradicionais causam problemas de entrelaamento (tangling) e espalhamento (scattering) de cdigo, uma vez que sua implementao no pode ser acomodada numa nica classe do software. O espalhamento ocorre quando o cdigo de um determinado interesse fica espalhado pelos mdulos que compem o interesse-base do software. O entrelaamento ocorre quando o cdigo de um interesse encontra-se misturado com o cdigo de interesses-base dentro de um mesmo mdulo, ou classe, do software. Vale ressaltar que a implementao de uma regra de negcio pode envolver tanto interesses-base quanto transversais. Nesse sentido, a programao orientada a aspectos (POA) tem como objetivo modularizar mais adequadamente os interesses que so transversais, resultando em melhores nveis de reso e manuteno.

38 A implementao dos aspectos fornece subsdio Programao Orientada a Objetos (POO) para tratar os interesses transversais por meio da decomposio funcional da classe (Elrad et al., 2001a). Os aspectos consistem em caractersticas estruturais e/ou comportamentais que so projetadas separadamente e adicionadas em diversas partes do sistema por meio da definio de pontos do programa em que esses aspectos podem afetar. Dessa forma, a combinao dos interesses transversais, implementados nos aspectos, com os interesses-base de cada classe afetada faz com que sejam atingidas as propriedades pretendidas, porm, sem comprometer a coeso de cada mdulo. A POA, portanto, no visa a substituir o paradigma orientado a objetos, mas complement-lo com uma nova viso, tentando assim deixar seu desenvolvimento mais claro e eficiente. Existem diversas linguagens que apiam a POA, entretanto neste trabalho apenas a Linguagem AspectJ ser discutida porque a linguagem que ser usada para a conduo do projeto. A Linguagem AspectJ est baseada numa nova construo chamada Aspecto (aspect). Os Aspectos so os mdulos responsveis por toda a implementao transversal, e podem conter mtodos, atributos, construtores, conjuntos de juno (pointcuts) e adendos (advices) (Kiczales et al., 2001). Assim, as novas construes da Linguagem AspectJ resumem-se em pontos de juno (joinpoints), conjuntos de juno, adendos, construes para afetar estaticamente a estrutura das classes do programa e os aspectos. No Apndice A desta monografia encontram-se os fundamentos tericos da POA, bem como a exemplificao de cada nova construo desse paradigma e no Anexo A encontra-se todo o cdigo do exemplo que utilizado nesta subseo. A seguir, so explicados os novos construtores da POA por meio da implementao de uma regra de negcio. Na Figura 1.9 mostrada a implementao de uma regra de negcio que d uma advertncia sobre o custo de uma transao bancria a cada vez que o saldo da conta ficar negativo. Esse exemplo utilizado para explicar as novas construes fornecidas pela POA. Na Linha 2 do exemplo criado um aspecto por meio da nova construo aspect, esse novo aspecto nomeado como aTaxaJuros e o responsvel pela implementao da regra de negcio supra citada. Nas Linhas 4, 6, 10 e 14 so implementadas construes para afetar estaticamente a estrutura da classe Conta. Essas modificaes permitem alterar estaticamente a estrutura de

39 uma classe por meio de declaraes 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 instituio bancria quando o saldo da conta estiver negativo. Na Linha 6 adicionado um novo mtodo, nomeado getTaxaJuros(), cuja funo retornar o percentual da taxa de juros da conta, que est armazenado no atributo TaxaJuros. Na Linha 10 adicionado tambm um novo mtodo nomeado setTaxaJuros(), cuja funo 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 parmetros a identificao da conta e a taxa de juros cobrada pela instituio, e atribui essa taxa ao atributo TaxaJuros, por meio do mtodo setTaxaJuros().

Figura 1.9 Exemplo de um aspecto implementado em AspectJ

Na Linha 20 definido um novo conjunto de juno nomeado AvisoSaldo(). Nele utilizado o designador call que permite interceptar os pontos de juno correspondentes chamada de mtodos. Esse designador utiliza-se de uma regra genrica para definir quais chamadas de mtodos formaro o conjunto de pontos de juno que sero afetados, nesse exemplo a regra utilizada : * Conta+.mostraSaldo(..). Essa regra

40 ir capturar as chamadas do mtodo mostraSaldo(), da Classe Conta e de todas as suas especializaes, uma vez que utiliza a notao coringa + aps o nome da classe, com qualquer tipo de parmetro, devido ao uso de notao coringa .. na definio dos parmetros, e que retorne qualquer tipo de dado, uma vez que no lugar do tipo do retorno foi utilizado a notao coringa *. Na Linha 22 criado o adendo relativo ao conjunto de juno estabelecido na Linha 20. Esse adendo do tipo after, o que significa que ele ir interceptar a chamada dos mtodos, estabelecidos na regra genrica do conjunto de juno, aps sua computao ser realizada. Nas Linhas 23 a 28 esto os cdigos que sero executados em cada ponto de juno capturado.

1.4. Consideraes Finais

Neste captulo foram abordados os conceitos relacionados s RNs, UML e programao orientada a aspectos. Um fato notado a ausncia de um padro sobre a definio, classificao e representao das RNs, contudo, existem esforos nessa direo como o Business Rules Group e a OMG. Nota-se tambm que, embora exista um esforo no sentido de alinhar o conceito de RNs com o desenvolvimento de software, isso ainda no uma realidade. Dessa forma, abre-se um importante nicho de pesquisa a ser explorado. No prximo captulo sero abordados os trabalhos relacionados a este, detalhando assim, os esforos de pesquisa que focam esse objetivo.

41

CAPTULO 2 TRABALHOS RELACIONADOS

Nesta seo so apresentados trabalhos que de alguma forma buscam uma integrao das RNs com a engenharia de software. Recentemente diversos autores buscaram essa integrao, porm 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 execuo, sem terem feito parte do seu desenvolvimento. Outros ainda apresentam solues para a integrao das RNs com o ncleo do software buscando cumprir os princpios para a implementao de RNs. Diante desse cenrio, neste captulo busca-se delinear as iniciativas que mais se aproximam da proposta presente neste trabalho, mostrando assim como este se enquadra no cenrio 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 modularizao e o rastreamento, o que os diferencia dos demais trabalhos aqui apresentados. Na Seo 2.1 apresentado o conceito de desenvolvimento de software com o gerenciamento das RNs, formando assim uma base para a integrao das RNs com o software em desenvolvimento. Na Seo 2.2 so discutidos os softwares que fornecem um gerenciamento das RNs, permitindo que elas sejam acopladas ao software j desenvolvido. Na Seo 2.3 so mostrados os trabalhos que defendem o uso de POA para a implementao das RNs. E na Seo 2.4 so feitas as consideraes sobre esse captulo.

2.1. Gerenciamento de Regras de Negcio4

Os autores defendem uma estrutura de desenvolvimento de software na qual RNs teriam um papel fundamental. Essa estrutura visa estabelecer uma ligao entre os negcios de uma organizao e seu respectivo sistema de informao, uma vez que esses sistemas so sensveis s mudanas dos processos de negcio. A forma encontrada para que essa ligao 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

A escrita desta seo baseada no trabalho de Bajec e Krisper (2004)

42 RNs podem ser implementadas de diferentes formas (gatilhos de banco de dados, procedimentos armazenados, componentes de camada de negcio, etc), o que torna necessrio um controle cuja abrangncia se estenda desde o requisito que as originou, at sua implementao, possibilitando um controle de todas as implicaes que envolvem o suporte do software s mudanas do negcio. Dessa forma, foi proposto um cenrio definindo as principais atividades e papis necessrios ao gerenciamento das RNs para toda a organizao, como mostrado na Figura 2.1. Nesse cenrio so descritas as atividades dedicadas ao gerenciamento das regras de negcio (Business Rules Management) e ao desenvolvimento do sistema de informao (IS Development). O objetivo desse cenrio ilustrar o conjunto de tarefas necessrias ao gerenciamento das RNs e seu envolvimento com os sistemas de informao.

Figura 2.1 O cenrio da modelagem de regras de negcio (Bajec e Krisper, 2004)

Para o contexto explorado nesta dissertao, as atividades relevantes so as que esto relacionadas com o desenvolvimento do sistema de informao (IS Development), sendo elas: BR Acquisition: considerando que as RNs representam um importante subconjunto dos requisitos e que so adquiridas juntamente com os demais requisitos do software, o objetivo dessa atividade tornar a aquisio das

43 regras um processo mais sistemtico e garantir que todas as regras sejam adquiridas. Essa tarefa considera como uma relevante fonte de RNs as regras previamente capturadas na modelagem do negcio (Enterprise Modeling) ou no desenvolvimento de outros softwares, que esto devidamente armazenas em um repositrio e disponveis para anlises mais detalhadas. BR Analysis and Classification: O propsito dessa atividade garantir que as regras sejam atmicas, classific-las em categorias e document-las com base em um gabarito (template) definido para cada categoria de regras. A descrio 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 no sejam conflitantes entre si. BR Modeling: o objetivo dessa atividade modelar as regras de negcio, com alguma forma de representao grfica para propiciar aos desenvolvedores do software um melhor entendimento sobre elas. BR Implementation: o objetivo dessa atividade propiciar ao repositrio das RNs que a informao sobre onde e como as regras foram implementadas seja capturada. Alm dessas atividades que compem o desenvolvimento de sistemas de informao, existe outra tarefa relevante, que a BR maintenance and monitoring, cujo objetivo gerenciar a manuteno das RNs constantes no software, isso realizado por meio de tarefas de controle de mudanas, controle de verses e controle de impacto. Essas atividades buscam estabelecer e manter a ligao entre o cenrio de negcios e o sistema de informao que lhe oferece suporte. O objetivo dos autores, nesse trabalho, mostrar a importncia da existncia de um amplo modelo de negcio, que resulta em um repositrio documental de regras de negcio. Esse repositrio tem o objetivo de apoiar o gerenciamento dessas regras, bem como os efeitos de suas mudanas. Alm disso, algumas regras desse repositrio so genricas e podem ser reusadas em outros contextos. Entretanto, os autores propem uma implementao dessas regras sem que um estilo de modelagem e implementao seja seguido. Isso faz com que, embora as regras e seus artefatos possam ser gerenciados, as RNs continuem inseridas no

44 cdigo funcional do software, no apoiando completamente os 4 (quatro) princpios de implementao das RNs (separao, rastreamento, exteriorizao e posicionamento), embora nesse ambiente o rastreamento das regras seja possvel. Tambm no sugerido qualquer padro de integrao entre as RNs, a modelagem e a implementao do software. Dessa forma, somente as definies das regras genricas que podem ser reusadas, uma vez que elas no so implementadas genericamente. Assim, percebe-se que o trabalho em questo prope um amplo cenrio de desenvolvimento de software, no qual as RNs so devidamente consideradas. Porm, isso ocorre de uma forma conceitual, sem que as atividades sejam detalhadas, j que o principal objetivo do trabalho estabelecer uma ligao clara entre as RNs na engenharia de software e suas fontes na modelagem de negcio. Devido a isso, os autores no propem uma metodologia ou um processo que apie o projeto dessas regras no desenvolvimento do software. Ou seja, o gerenciamento proposto obtido com base na implementao das RNs de maneira usual, com as regras espalhadas pelos artefatos de software. Os autores ainda citam que no existe atualmente uma metodologia que apie o projeto das RNs, e assim consideram que a implementao dessas regras pode ocorrer de vrias formas. Alm disso, citado no trabalho que no desenvolvimento orientado a objetos no 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 dissertao tem como objetivo complementar o cenrio proposto pelos autores, fornecendo tcnicas e artefatos que apiem a identificao das RNs bem como seu projeto, propondo um modelo de projeto dessas regras, e critrios para sua identificao. Nesse ponto o trabalho de Bajec e Krisper (2004) tambm difere da abordagem proposta, j que os autores consideraram que as RNs comeam a ser obtidas nas atividades de modelagem de negcio (Enterprise Modeling), e so completadas com a anlise dos requisitos do software, sem que seja determinado como exatamente isso ocorre, ao passo que na abordagem aqui proposta as RNs so obtidas diretamente nos requisitos do software, com o apoio de critrios especficos para isso.

2.2. Sistemas Gerenciadores de Regras de Negcio

Os Sistemas Gerenciadores de Regras de Negcio (SGRN) (BRMS Business Rules Management System) so softwares que fornecem um ambiente que possibilita que RNs sejam criadas, gerenciadas e distribudas. De acordo com Ilog (2008), adicionalmente so oferecidos

45 modelos de objetos de negcio (BOM Business Object Model) a partir dos quais os termos das RNs so mapeados com elementos de software (mtodos e objetos), o que permite que os objetos e seus mtodos sejam traduzidos para fragmentos de linguagem natural. Assim, por exemplo, o objeto Cliente pode ser associado ao fragmento cliente e o mtodo obterLimiteCrdito pode ser associado ao fragmento limite de crdito de, o que permitiria a construo da seguinte regra: Se o limite de credito de cliente for maior que 0 Ento...., onde o texto em negrito so elementos do Rule Builder. A execuo das regras criadas ocorre por meio de Enterprise Java Beans permitindo que uma RN manipule objetos contidos na memria (Ilog, 2008). O SGRN mais conhecido atualmente JRules. Na Figura 2.2 mostrado um dos poucos exemplos padres disponibilizados pela empresa iLog, fabricante do jRules, nesse exemplo a RN descrita no primeiro quadro ligada ao BOM, com seu respectivo vocabulrio, mostrado no segundo quadro, gerando assim um novo fato nomeado creditScore

Figura 2.2 - Exemplo da utilizao 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 inconscincia no software desenvolvido, impossibilitando assim que regras mais complexas, como as de derivao, interajam com os mecanismos criados no software, uma vez que tais regras no existem durante o

46 desenvolvimento do software, o que impede, por exemplo, que a classe que implementa determinado objeto tenha conscincia sobre sua origem. Outro problema dessa abordagem diz respeito ao fato das RNs no serem parte dos requisitos iniciais do software, o que no garante que todos os elementos necessrios s regras estejam presentes no software. Isso fere o conceito de que RNs so tipos de requisitos de um software a ser construdo (Ross, 2003). Alm disso, no foram encontrados estudos que analisassem como fica o cenrio de manuteno do software, uma vez que as alteraes na estrutura do software poderiam influenciar as RNs acopladas a ele, lembrando que tais regras no so artefatos de software, e no esto disponveis no desenvolvimento do software.

Figura 2.3 - Ciclos de vida do Software e das Regras de Negcio (Ilog, 2008)

Dessa forma, o trabalho apresentado nessa dissertao 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 no mecanismos que podem atuar de forma independente sobre o software em produo. Evitando assim os problemas apontados no pargrafo anterior.

47

2.3. Regras de Negcio e Aspectos

Para Cibrn et al. (2003) a implementao das regras de negcio com cdigo procedimental, orientado a objetos, ou por meio de abordagens de banco de dados prejudica os princpios de implementao das RNs, como defendido por Von Halle (2002). Cibrn et al. (2003) mencionam tambm que a implementao de alguns tipos de RNs com orientao a objetos faz com que o cdigo responsvel pela conexo do ncleo do software com as regras, fique espalhado por diversas classes. Esses tipos de RNs envolvem interesses transversais e so adequadas de serem implementadas com orientao a aspectos. Dessa forma, Cibrn et al. (2003) apresentam uma proposta de conexo das RNs ao ncleo do software por meio de programao orientada a aspectos. Todavia, o referido trabalho tem enfoque apenas na implementao do software, isto , no descrita qualquer tcnica ou metodologia para que essas regras possam ser modeladas durante todo o ciclo de vida do desenvolvimento, assim como proposto na abordagem proposta nesta dissertao. Outro trabalho que mostra a viabilidade da conexo de RNs com o ncleo do software por meio de programao orientada a aspectos o de Camargo e Masiero (2005). Nesse trabalho os autores mostram a implementao genrica de RNs na forma de Frameworks Transversais (FTs). Frameworks Transversais so um tipo especial de framework orientado a aspecto que encapsula apenas um determinado interesse transversal. Esses FTs devem ser instanciados e acoplados a um cdigo-base por meio de mecanismos abstratos fornecidos pela POA. No trabalho de Camargo e Masiero (2005) mostrado um FT de regra de negcio. Esse FT encapsula de forma genrica uma regra de negcio que pode ser instanciada de vrias formas para diferentes aplicaes. Esse tipo de implementao favorece o reso dessas regras e facilita sua integrao com o software por meio dos mecanismos fornecidos pela POA. Entretanto, da mesma forma que o trabalho citado anteriormente (Cibrn et al., 2003), o acoplamento do framework ao ncleo do software ocorre apenas na implementao, sem qualquer tcnica ou metodologia para a modelagem durante todo o ciclo de vida do desenvolvimento de software.

2.4. Consideraes Finais

Os trabalhos apresentados neste captulo indicam a relevncia das RNs no processo

48 de desenvolvimento de software. O trabalho apresentado na Seo 2.1 mostra a necessidade da integrao das regras de negcio ao processo de desenvolvimento de software. Mas, apesar de indicar a importncia dessa integrao por meio da modelagem das regras no paradigma orientado a objetos, ele tambm mostra que esse conceito encontra-se num estgio embrionrio. Na Seo 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 negcio estabelecer e gerenciar as RNs da companhia, de forma independente do ciclo de vida de desenvolvimento do software. Todavia isso apresenta algumas limitaes, j que o desenvolvimento do software ocorre de forma independente das RNs que iro atuar nele. Sendo assim, no existe uma garantia de que todos os elementos necessrios regra vo existir no software. Na Seo 2.3 foram apresentados os trabalhos que mostram a viabilidade da implementao das RNs por meio da programao orientada a aspectos. Contudo, isso ocorreu apenas na implementao do software, no sendo encontrado nada que mostrasse a viabilidade dessa abordagem na modelagem do software. Assim, os trabalhos apresentados nessa seo confirmam a necessidade de integrao entre RNs e desenvolvimento de software, viabilizando essa abordagem com o uso da programao orientada a aspectos.

49

CAPTULO 3 PROJETO DE SOFTWARE COM REGRAS DE NEGCIO

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 ncleo do software, e assim atender aos princpios de projetos exigidos pelas RNs (Seo 1.1.3), que so: Separao, Rastreamento, Exteriorizao e Posicionamento. Para atender a esse objetivo necessrio 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, porm de forma desacoplada e independente. Dessa forma, a abordagem proposta consiste na adaptao do ciclo de vida de desenvolvimento de software de forma a incluir novas atividades e artefatos para apoiar o tratamento das RNs. A adaptao tambm foi utilizada como base para uma extenso do Processo Unificado (PU) (Jacobson et al., 1999), com o objetivo de apoiar o processo de desenvolvimento de softwares com RNs. Na Seo 3.1 descrita uma viso geral da abordagem proposta neste trabalho; na Seo 3.2 apresentada a extenso do Processo Unificado (PU); na Seo 3.3 abordada a rastreabilidade resultante da abordagem; e na Seo 3.4 so apresentadas as consideraes finais desse captulo.

3.1. Viso Geral da Abordagem

A abordagem proposta envolve quatro etapas: a elaborao de casos de uso com um gabarito proposto, a identificao das RNs nos requisitos do software, a identificao das RNs candidatas a aspectos e o projeto das RNs. Na Figura 3.1 so mostradas adaptaes realizadas no modelo clssico de desenvolvimento de software, para atender a abordagem proposta. Na Figura 3.1 os quadros pontilhados representam os novos artefatos propostos, e os retngulos vazios adicionados s etapas do ciclo de vida clssico representam as novas atividades necessrias proposta deste trabalho. O objetivo de inicialmente ilustrar as mudanas no processo utilizando-se o ciclo de vida clssico de desenvolvimento de software possibilitar uma viso geral das intervenes

50 nas atividades de desenvolvimento de software. Todavia para a aplicao dessas atividades sugerido um processo de desenvolvimento, que proposto como uma extenso do PU com as mudanas devidamente aplicadas s suas atividades. Essa extenso detalhada na prxima seo.

- Atividades Registrar casos de uso com gabarito Gabarito para registro dos casos de uso Lista de Regras Projetar RN - Artefatos - Descrio P de Atividade r o j e t a r R N Implantao

Elicitao/ Coleta de Requisitos

Documentos de Requisitos

Anlise Projeto Implementao

Identificar RNs Identificar RNs candidatas a aspectos

Classificar RNs

Figura 3.1 - Influncia da abordagem no ciclo de vida de desenvolvimento de software

3.2. Extenso do Processo Unificado

O PU composto por diversas disciplinas distribudas em quatro fases: Concepo, Elaborao, Construo e Transio. A realizao dessas disciplinas ocorre em todas as fases do processo, porm com nfase diferente de acordo com a evoluo do processo. A extenso proposta neste trabalho utiliza essa mesma estrutura do PU, porm com o objetivo de apoiar de forma explcita o tratamento de RNs. A base da extenso a criao de novas atividades ao longo das disciplinas do PU. As atividades consideradas nessa extenso iniciam-se na disciplina anlise, j que a abordagem proposta considera que os requisitos j estejam definidos, no envolvendo portanto, a disciplina requisitos. Tambm foram adaptadas algumas das atividades j existentes para que pudessem oferecer um tratamento especfico para as RNs. Na Tabela 3.1 so mostradas as atividades que compem a extenso do PU para RNs. As atividades em negrito so novas, as atividades

51 em itlico no so influenciadas pela abordagem, porm constam na tabela para enfatizar a seqncia de atividades do PU, as demais possuem algum tipo de adaptao proposta nesta extenso. O PU originalmente um processo iterativo e incremental, e a extenso proposta em nada compromete essas caractersticas 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 manipulao das RNs.

Tabela 3.1 - Atividades da extenso do PU proposta

Atividades da Disciplina Anlise Identificar e Registrar Casos de Uso Essenciais Documentar casos de uso com gabarito Classificar e Registrar Regras de Negcio Refinar Diagramas de Casos de uso Refinar Viso do Diagrama de Casos de Uso para Regras de Negcio Criar Diagrama de Seqncia de Sistema Definir Contratos das Operaes do Sistema Desenvolver Modelo Conceitual Atividades da Disciplina Projeto Definir Paradigma de Projeto das Regras Desenvolver Diagramas de Interao Desenvolver Modelo de Classes do Projeto Projetar Regras de Negcio Projetar Modelo de Dados Atividades da Disciplina Implementao Implementar Classes do Domnio Implementar Banco de Dados Implementar Regras de Negcio Implementar Classes Controladoras Implementar Interfaces Testar

3.2.1 Disciplina anlise

O objetivo principal da anlise realizar uma investigao do problema e dos requisitos (Larman, 2007). Dessa forma, o objetivo dessa fase refinar os casos de uso definidos para a iterao atual, descobrir novos requisitos e elaborar o modelo de domnio.

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, alm da identificao, classificao e registro das RNs. Sendo assim, a disciplina anlise o grande foco da abordagem, pois ela fornece toda a base para o restante do desenvolvimento do software com RNs. Nas prximas subsees sero detalhadas as atividades que compem essa disciplina, e que foram influenciadas pela abordagem.

3.2.1.1. Atividade: Identificar e Registrar Casos de Uso Essenciais

A identificao e registro dos casos de uso devem ocorrer da maneira usual, como sugere originalmente o PU. Todavia aps essa atividade ser necessria a documentao dos casos de uso com o gabarito proposto na abordagem. Sendo assim, o engenheiro de software pode optar por um registro bsico do caso de uso, com apoio de algum gabarito usual, e na prxima atividade a documentao completa atendendo as exigncias da abordagem, ou o registro dos casos de uso j no gabarito sugerido, porm apenas com as informaes bsicas sobre cada caso de uso, para que na prxima atividade a documentao seja completada com as informaes necessrias abordagem.

3.2.1.2. Atividade: Documentar Casos de Uso com Gabarito

A identificao de RNs durante a anlise dos requisitos deve ser apoiada por meio do uso de um gabarito (template) para a documentao dos casos de uso. Essa documentao deve ocorrer aps a identificao e registro dos casos de uso, o que ocorre na atividade anterior. O PU j sugere a utilizao de gabaritos para o registro dos casos de uso, sendo assim, a proposta da abordagem a utilizao de um gabarito prprio 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 adaptao do gabarito proposto por Jacobson e Ng (2004). A extenso foi feita para apoiar de forma mais adequada a identificao das RNs. Isso ocorre por meio do registro de informaes relacionadas com RNs e que so oriundas do documento de requisitos. Essas informaes podem, posteriormente, tornarem-se RNs. A adaptao realizada consistiu em adicionar a ltima seo (Gatilhos) no gabarito

53 original, e incluir algumas outras informaes nas sees Fluxo Alternativo, Pr-Condies e Ps-Condies.

Caso de Uso:
Descrio: Fluxo Principal: Seq Descrio Fluxos Alternativos: Seq Origem Tipo Pr-Condies: Origem Ps-Condies: Origem

Condio

Ao

Condio

Condio

Gatilhos: Tipo de Gatilho Caso de Ao Uso Diretriz Habilitador Derivao

Figura 3.2 - Gabarito para registro e documentao dos casos de uso

O documento de requisitos que ser utilizado como base para o preenchimento do gabarito deve descrever de forma satisfatria as funcionalidades que se espera que o software fornea. Alm disso, espera-se tambm que esse documento descreva minuciosamente o comportamento do software. Uma vez que as RNs so responsveis por delinear tal comportamento, com base nas polticas e normas organizacionais. As sees adicionadas ou modificadas, pela abordagem proposta, esto detalhadas nas prximas subsees.

a) Fluxo Alternativo
Os fluxos alternativos de um caso de uso tm por objetivo descrever as possveis variaes do fluxo principal (Jacobson e Ng, 2004). Dessa forma, no contexto da abordagem

54 proposta, espera-se que estejam descritas, nesses fluxos, as variaes de comportamento que devem ser manipuladas pelo caso de uso. Alm disso, espera-se tambm que estejam descritos os comportamentos adicionais que venham a ocorrer em situaes especficas de ambientes de negcio, tais como diretrizes relativas a polticas empresariais, restries que venham a ocorrer em funo de polticas, leis e normas empresariais, ou ainda derivaes que satisfaam regras empresariais pr-definidas. Esses comportamentos no fazem parte do fluxo principal em conseqncia da sua natureza de negcio, que determina como o software deve funcionar, e no 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 seo de fluxo alternativo. Os fluxos alternativos que representam eventos de negcio possuem uma caracterstica prpria que ser acionado a partir de uma condio. Para o preenchimento dessa seo do gabarito, necessrio que o engenheiro de software identifique eventos de negcio que compem o fluxo alternativo do caso de uso, o que deve ser feito com base nos documentos de requisitos. Eventos de negcio, no contexto deste trabalho, so comportamentos que refletem necessidades especficas do negcio 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 anlise na origem do fluxo alternativo deve ser informado na coluna Origem dessa seo do gabarito. A origem pode ser: Sistema: So todos os comportamentos alternativos que tem por objetivo o cumprimento de uma necessidade do software, tais como: garantia de integridade dos dados, validaes de tipos de dados etc. Negcio: So comportamentos alternativos impostos por fatores de negcio, tais como: acionamento de eventos de negcio, diretrizes informativas de polticas da empresa etc. Esses comportamentos representam RNs. A determinao da origem dos fluxos alternativos (cujo resultado ser a base para o preenchimento da coluna origem da seo do gabarito) est relacionada com a identificao de RNs, ou seja, os fluxos alternativos cuja origem seja de negcio se tornaro RNs nas prximas atividades da abordagem. Para o escopo desse trabalho, ser focada a identificao de RNs nos requisitos do software. Para isso so propostos alguns critrios que tem por objetivo apoiar o engenheiro de software na tarefa de identificar as RNs na especificao dos

55 requisitos do software. O objetivo desses critrios fornecer um meio adicional identificao de RNs, com isso o engenheiro de software pode submeter cada fluxo alternativo identificado aos critrios propostos abaixo, e seu resultado ser uma diretriz essencial na identificao de comportamentos de negcio. Os critrios so: Identificao de decises: As RNs geralmente esto acompanhadas de decises (Von Halle, 2002). Isso ocorre pelo fato das RNs definirem como o software funciona. Dessa forma, a identificao de decises que envolvem polticas da companhia, ou demais caractersticas de uma RN, um caminho para sua identificao nos requisitos do software; Fluxo de eventos: Fluxos de eventos so seqncias de aes que o software deve implementar para satisfazer uma poltica da empresa, o que pode ser independente de decises. A identificao dos fluxos de eventos nos requisitos do software possibilita a obteno de alguns tipos de RNs, identificando-se essas aes tm-se as RNs que no so precedidas por condies; Essencialidade: As RNs definem como um evento de negcio (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, porm a questo se ela essencial ao funcionamento genrico do caso de uso. Como exemplo, pode-se citar uma RN que verifica se a durao da estadia de uma reserva de acomodao, num sistema de controle hoteleiro, no excedeu ao limite estabelecido. Essa RN essencial ao sistema hoteleiro em questo, mas no essencial ao controle de reserva de qualquer sistema hoteleiro. Assim, se a RN for essencial sua

separao poderia comprometer o sistema, caso essa RN fosse desativada futuramente. Portanto, sua separao causaria uma falsa impresso de independncia e desacoplamento, o que pode ser prejudicial ao sistema. Nesse caso, provavelmente ela no uma RN. Esse critrio foi adaptado de Camargo (2006). Os critrios propostos no so independentes, ou seja, eles devem sempre ser aplicados em conjunto, uma vez que o terceiro critrio uma validao das RNs identificadas pelos dois primeiros critrios. A aplicao dos critrios propostos deve sempre ser acompanhada da anlise crtica do engenheiro de software, pois existem certas funcionalidades que podem satisfazer aos

56 critrios, todavia podem no ser RNs por no refletirem polticas da empresa e no ter qualquer outra caracterstica de uma RN. Para a correta identificao da origem dos fluxos alternativos deve-se tambm tomar como base, alm dos critrios propostos, o fundamento terico e a vasta disponibilidade de exemplos existentes sobre RNs. Essas informaes podem ser encontradas em Ross (2003) e Von Halle (2002). Com a origem devidamente preenchida, caso seu contedo seja Negcio o campo Tipo deve ser preenchido, caso contrrio dever permanecer vazio, uma vez que esse campo no tem significado para fluxos alternativos convencionais. Essa informao deve refletir o tipo de comportamento de negcio que o fluxo alternativo em questo ir executar. Os comportamentos identificados e aceitos neste trabalho so: Diretriz: expressam uma advertncia sobre uma circunstncia de negcio que faz com que alguma ao humana - ou de qualquer outra natureza que esteja fora do escopo do software - seja executada sem, contudo, restringir a execuo do software. Exemplo: Caso o cliente possua duplicatas vencidas e no pagas o usurio dever ser comunicado; Habilitador: so mecanismos que verificam uma determinada condio e caso ela seja verdadeira inicia uma nova ao no software. Exemplo: Caso o usurio possua status de gerente a alterao dos preos de venda dever ser liberada; Derivao: resulta na criao de um novo trecho de informao que, em termos de banco de dados, pode ser uma nova instncia de uma entidade, ou uma nova instncia de um atributo. Para que a derivao ocorra necessrio que seja implementado o mecanismo de derivao com o mapeamento que ser aplicado s informaes bases para a extrao das informaes derivadas. Exemplo: Caso seja o ms de aniversrio do cliente o valor do desconto dever ser 10% do total da venda. A determinao 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 informao designa um dado comportamento para a RN. A prxima etapa para o preenchimento dessa seo do gabarito a identificao da condio que deve ser cumprida para que o fluxo alternativo em questo seja acionado. A condio de acionamento algo intrnseco s RNs (Von Halle, 2002), sendo inclusive um mecanismo para sua identificao (como mostrado na Seo 3.2.1.2.a). Sendo assim, cabe

57 ao engenheiro de software identific-la no enunciado da regra e transcrev-la ao gabarito. O registro dessa condio pode ocorrer em linguagens mais formais, como OCL, por exemplo, porm em todos os exemplos deste trabalho utilizada linguagem natural para o registro de tais condies. Por fim, o ltimo campo dessa seo do gabarito a ao que dever ser executada caso a condio do fluxo alternativo em questo seja satisfeita. Essa ao dever ser descrita em linguagem natural e dever descrever uma ao condizente com a classificao previamente informada no campo Tipo. Para exemplificar o preenchimento dessa seo do gabarito, mostrada na Tabela 3.2 uma parte do gabarito relativo ao caso de uso Gerar Vendas, que compe o estudo de caso dessa dissertao.
Tabela 3.2 - Exemplo da seo fluxos alternativos

b) Pr-Condies
As pr-condies de um caso de uso indicam as condies que devem ser satisfeitas para que sua execuo possa ser feita adequadamente. Devem constar as restries que levariam a execuo do caso de uso a um estado indefinido. Um caso de uso s pode ser executado se todas as suas pr-condies forem satisfeitas. As pr-condies so formas de se garantir que a execuo de um caso de uso ocorrer de forma consistente, sem ferir princpios ou circunstncias pr-estabelecidas. A identificao das pr-condies do caso de uso deve ser feita com base nos documentos de requisitos. Toda pr-condio identificada deve ser analisada com o objetivo de identificar sua origem, que pode ser:

58 Sistema: So todos os comportamentos alternativos que tem por objetivo o cumprimento de uma necessidade do software, tais como: garantia de integridade dos dados, validaes de tipos de dados etc. Negcio: So comportamentos alternativos impostos por fatores de negcio, tais como: acionamento de eventos de negcio, diretrizes informativas de polticas da empresa etc. Esses comportamentos representam RNs. A determinao da origem das pr-condies est relacionada com a identificao de RNs. Por isso ela deve ser feita com base nos critrios propostos na Seo 3.2.1.2.a. O campo Condio deve ser preenchido com a condio que ser verificada para determinar se esse caso de uso pode ser executado ou no. Para exemplificar o preenchimento dessa seo do gabarito mostrada na Tabela 3.3 uma parte do gabarito relativo ao caso de uso Gerar Vendas, que compe o estudo de caso dessa dissertao.
Tabela 3.3 - Exemplo de Pr-Condies

c) Ps-Condies
Indicam condies que devem ser satisfeitas para que o caso de uso seja concludo com sucesso. Devem constar as condies necessrias para garantir que um caso de uso s poder ser concludo quando todas as condies de integridade, pr-estabelecidas, forem satisfeitas. A identificao das ps-condies do caso de uso deve ser feito com base nos documentos de requisitos. Toda ps-condio identificada deve ser analisada com o objetivo de identificar sua origem, que pode ser: Sistema: So todos os comportamentos alternativos que tem por objetivo o cumprimento de uma necessidade do software, tais como: garantia de integridade dos dados, validaes de tipos de dados etc.

59 Negcio: So comportamentos alternativos impostos por fatores de negcio, tais como: acionamento de eventos de negcio, diretrizes informativas de polticas da empresa etc. Esses comportamentos representam RNs. A determinao da origem das ps-condies est relacionada com a identificao de RNs. Por isso ela deve ser feita bom base nos critrios propostos na Seo 3.2.1.2.a. O campo Condio deve ser preenchido com a descrio da checagem que ser realizada para validar a ps-condio estabelecida. Para exemplificar o preenchimento dessa seo do gabarito mostrada na Tabela 3.4 uma parte do gabarito relativo ao caso de uso Gerar Vendas, que compe o estudo de caso dessa dissertao.
Tabela 3.4 - Exemplo de Ps-Condies

d) Gatilhos
Os Gatilhos so descritos em uma nova seo do gabarito proposto neste trabalho. Gatilhos so procedimentos que devem ser disparados aps a execuo, com sucesso, de um caso de uso. O disparo dos gatilhos geralmente ocorre mediante uma condio de negcio e deve ser independente do fluxo de execuo do caso de uso. Isso diferencia os gatilhos do fluxo alternativo de eventos, uma vez que o fluxo alternativo descreve excees para o funcionamento do caso de uso em si, enquanto os gatilhos descrevem aes que devem ser executadas aps o trmino do caso de uso em questo. Em outros termos, os gatilhos descrevem complementos ao funcionamento do caso de uso, que geralmente so condicionados a execuo de outros casos de uso. Os gatilhos informados nesta seo do gabarito devem representar eventos de negcio. 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 so compostos de um mecanismo de acionamento e uma funcionalidade alvo. Esses dois elementos podem estar encapsulados em uma nica RN, ou podem ser

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. desejvel que os mecanismos de acionamento independentes sejam representados como RNs pelo fato de representar uma ao que visa cumprir um comportamento de negcio, e dessa forma, possui as caractersticas das RNs (volatilidade, independncia, etc) devendo respeitar as caractersticas desejveis para seu projeto. A ao resultante de um gatilho determina o seu tipo. Os tipos de gatilhos identificados e aceitos nesse trabalho so: Diretriz: expressam uma advertncia sobre uma circunstncia de negcio que faz com que alguma ao humana ou de qualquer outra natureza que esteja fora do escopo do software, seja executada sem restringir a execuo do software; Habilitador: so mecanismos que verificam uma determinada condio e caso ela seja verdadeira inicia uma nova ao no software; Derivao: resulta na criao de um novo trecho de informao que, em termos de banco de dados, pode ser uma nova instncia de uma entidade, ou uma nova instncia de um atributo. Para que a derivao ocorra necessria a existncia de um mecanismo de derivao com o mapeamento que ser aplicado s informaes bases para a extrao das informaes derivadas. Geralmente esse mecanismo de derivao est definido no caso de uso invocado nesse gatilho. O tipo de um gatilho est intrinsecamente relacionado ao tipo de RN que ele descreve. A prxima informao constante nessa seo do gabarito o caso de uso que representa a funcionalidade alvo do gatilho em questo, caso essa funcionalidade esteja separada do mecanismo acionador, o que pode ocorrer por questes de modularizao do software, j que o caso de uso alvo do gatilho pode tambm ser uma funcionalidade base do software. Nesse caso o acionamento dessa funcionalidade representa um evento de negcio, e no a funcionalidade em si. Isso ocorre devido ao fato de que o fluxo de aes do software pode ser determinado ou influenciado por fatores de negcio. E nessas situaes podem

61 ocorrer gatilhos que no possuem condies para serem executados, uma vez que o prprio fluxo de eventos do software foi influenciado por fatores de negcios. Por fim, a ltima informao que o engenheiro de software deve fornecer a ao resultante desse gatilho. Essa ao pode ser a simples invocao do caso de uso alvo, ou ainda pode estar contida nessa ao a condio necessria para que o gatilho seja disparado. Porm essa condio no obrigatria, o que torna aceitveis gatilhos que sempre sero disparados, desde que isso ocorra por fatores de negcio, caso contrrio a implementao desses gatilhos dever seguir os mecanismos usuais da engenharia de software. Para exemplificar o preenchimento dessa seo do gabarito mostrada na Figura 3.3 uma parte do gabarito relativo ao caso de uso Gerar Vendas, que compe o estudo de caso dessa dissertao.

Figura 3.3 - Exemplo de Gatilhos

3.2.1.3. Atividade: Classificar e Registrar Regras de Negcio

Essa uma nova atividade da extenso 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 no ocorra de forma explcita, a identificao de fluxos alternativos, pr e ps condies e gatilhos de origem de negcio, nada mais que a identificao de RNs com objetivos especficos. Esse fato facilita a tarefa de identificao das RNs, uma vez que ao focar a identificao em RNs com objetivos especficos reduz-se o domnio dessas regras. Sendo assim, com as regras j descritas nas sees especficas do gabarito a tarefa de classific-las ocorre por meio de um mapeamento entre as sees do gabarito com o tipo de cada regra. As diretrizes para que esse mapeamento ocorra so mostradas na Tabela 3.5. O mapeamento deve ser executado seguindo-se os critrios constantes na coluna Critrio de Identificao (Tabela 3.5). Dessa forma, as RNs sero obtidas de acordo com seu tipo (j que para cada tipo de RN existe um conjunto de critrios de identificao), seguindo-se os critrios estabelecidos obtm-se o conjunto de regras oriundas de sees do gabarito. Isso

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 especfico, chamado Lista de Regras. A classificao das RNs identificadas nos gabaritos ocorre pelo agrupamento das regras de acordo com suas caractersticas, ou seja, as RNs quando identificadas nos requisitos recebem uma classificao prvia, seja por meio da seo do gabarito na qual ela registrada, seja pela identificao de seu tipo (nas sees Fluxos Alternativos e Gatilhos do gabarito). Dessa forma os diversos tipos de RNs que esto distribudas pelas sees do gabarito devem ser identificadas e agrupadas. Isso possvel pelo fato das sees Pr e Ps-Condies receberem apenas um tipo de regras, e as sees Fluxos Alternativos e Gatilhos possurem um campo de identificao (Tipo) que representa o tipo de RN registrada. importante ressaltar que o preenchimento do campo de identificao ocorre com base no conceito de RNs, como apresentado nas Sees 3.2.1.2.a e 3.2.1.2.d. Sendo assim o objetivo dos Critrios de Identificao orientar onde (seo do gabarito) cada tipo de regra deve ser obtido, e como separar as RNs das funcionalidades pertencentes ao caso de uso em questo.
Tabela 3.5 Critrios para a classificao das Regras de Negcio Tipo de RN Restries Critrio de Identificao -Itens informados na seo Pr-Condies ou Ps-Condies, que possuam origem de negcio; Diretrizes -Itens informados na seo Fluxo Alternativo ou na seo Gatilhos. Desde que tenham origem de negcio e sejam do tipo Diretriz. As RNs oriundas da seo Fluxo Alternativo devero sofrer uma juno da condio de acionamento da RN com sua ao, para que dessa forma, a RN seja transcrita na sua totalidade; Habilitadoras de Aes -Itens informados na seo Fluxo Alternativo ou na seo Gatilhos. Desde que tenham origem de negcio e sejam do tipo Habilitador. As RNs oriundas da seo Fluxo Alternativo devero sofrer uma juno da condio de acionamento da RN com sua ao, para que dessa forma, a RN seja transcrita na sua totalidade; Derivao -Itens informados na seo Fluxo Alternativo ou na seo Gatilhos. Desde que tenham origem de negcio e sejam do tipo Derivao. As RNs oriundas da seo Fluxo Alternativo devero sofrer uma juno da condio de acionamento da RN com sua ao, para que dessa forma, a RN seja transcrita na sua totalidade;

Na apresentao do PU feito por Larman (2007) j sugerido um artefato nico para registro das RNs, tendo como principal benefcio possibilidade de reso dessas regras por toda a organizao. Todavia esse artefato foi refeito para que pudesse atender s necessidade

63 da abordagem proposta nesse trabalho. Um exemplo desse artefato mostrado na Tabela 3.6 com algumas RNs que foram extradas do estudo de caso apresentado neste trabalho.
Tabela 3.6 - Exemplo do Artefato Lista de Regras Preenchido
Regra Verificar se o caixa anterior est fechado Caso o cliente possua duplicatas a vencer nos prximos 7 dias dever ser gerado um aviso ao usurio Caso o cliente possua duplicatas a vencer nos prximos 7 dias a pesquisa financeira do cliente dever ser exibida Caso o cliente tenha duplicatas vencidas e no pagas dever ser gerada uma advertncia para que a situao seja regularizada seno a venda no ser aceita Caso o usurio no seja gerente a alterao do preo dos produtos dever ser bloqueada Caso seja o ms de aniversrio do cliente, o desconto dever ser preenchido com o valor de 5% do total da venda necessrio que o caixa esteja aberto para que uma venda seja registrada, alterada ou excluda. Tipo Restrio Diretriz Caso de Uso Abrir Caixa Gerar Vendas Ponto de Id. RN Mlt Parad Mdulo Artefato Atuao Ocor igma ChecarCx Checagem PrInicializao ChecarCaixa OA Anterior Condies Anterior ChecaDup Checagem Fluxo No ato de ChecarDupl OA lVencer Alternativo informar o AVencer cliente Seo MostrarPesq Financeira OA
Mostrar Pesquisa PesqFinan ceira

Habilitadora Gerar Fluxo No ato de Vendas Alternativo informar o cliente

Diretriz

Gerar Fluxo No ato de Vendas Alternativo informar o cliente

AdvertirAtra sos

OA

VerificaAt Checagem raso

Habilitadora Gerar Fluxo Na insero Bloquear Vendas Alternativo de produtos Preos na venda Derivao Gerar Fluxo Na Vendas Alternativo informao do valor do desconto GerarDesco ntoAniversa rio

OO

BloquearP Bloqueio recos

OA

ChecaDes Checagem cNiver

Restrio

Gerar PrInicializao VerificarCai Vendas Condies xaAberto

OA

VerificarC Checagem aixaAberto

As colunas do artefato devem ser preenchidas seguindo-se diretrizes, como segue: Regra: Nessa coluna deve constar a prpria 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 seo; Caso de Uso: Deve ser informado o caso de uso que originou a RN, essa informao essencial para a obteno da rastreabilidade; Seo: Nessa coluna deve constar a qual seo do gabarito a RN pertence; Ponto Atuao: Esse campo representa uma informao importante para a abordagem. Nessa coluna deve ser informado qual o ponto, da funcionalidade a ser implementada, que a RN ir influenciar. Essa informao pode ser considerada como um esforo inicial para direcionar o engenheiro de software

64 no sentido de determinar o ponto de chamada ou o ponto de juno da RN aps ser implementada. Considerando que essa abordagem enquadra-se nas fases iniciais do desenvolvimento do software, no possvel determinar exatamente os nomes dos mtodos/atributos e das classes. Sendo assim, nesse ponto do desenvolvimento suficiente informar em linguagem natural e com um alto nvel de abstrao os pontos de juno nos quais as RNs sero acopladas. Essa informao pode ser obtida por meio da anlise da localizao da RN no gabarito, por exemplo, uma regra oriunda da seo de Pr-Condies deve influenciar a inicializao da classe que implementar a funcionalidade representada no caso de uso. Na Tabela 3.7 so definidas diretrizes com o intuito de apoiar o engenheiro de software nessa anlise, como segue:
Tabela 3.7 - Diretrizes de apoio para anlise do ponto de atuao Seo do Gabarito Pr-Condies Ps-condies Possveis pontos de juno Inicializao e instncia da classe que representa a funcionalidade base do caso de uso Mtodos que executam atividades fins na classe. Exemplo: cadastrar, imprimir, processar, excluir etc. O ponto de juno geralmente ocorre antes da execuo ou chamada do mtodo. Semelhante s Ps-condies, porm o ponto de juno ocorre aps a execuo ou chamada do mtodo. Geralmente os pontos de juno esto vinculados ao passo do fluxo principal que o fluxo alternativo ir modificar. Geralmente est vinculado com aes de modificao e acesso de atributos (get e set) ou com execuo de mtodos.

Gatilhos Fluxos Alternativos

Id.RN: Essa coluna deve ser preenchida com uma identificao nica para a RN, essa informao importante para possibilitar o rastreamento da regra; Mltipla Ocorrncia: Quando uma RN atua em diversos pontos do software, faz-se necessrio que na primeira ocorrncia da regra, todas as informaes sobre os artefatos que a implementam sejam preenchidos, porm, nas demais ocorrncias isso no se faz necessrio, j que elas so 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 atuao da regra; Paradigma: Deve constar a informao sobre qual o paradigma que foi

65 utilizado para sua implementao, no contexto desse trabalho podem ser utilizados os paradigmas Orientados a Objetos (OO) ou Orientados a Aspectos (OA) Mdulo: Deve ser preenchida com o nome do mdulo 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 questo. Caso o paradigma utilizado seja OO, deve constar o nome do mtodo que encapsula a implementao da regra, caso seja OA deve constar o nome do adendo que encapsula a implementao da regra. As colunas Paradigma, Mdulo e Artefato no sero preenchidas nessa atividade do processo. A coluna paradigma dever ser preenchida aps a atividade cujo objetivo identificar o paradigma de projeto das RNs (Seo 3.2.2.1), j as colunas Mdulo e Artefato devero ser preenchidas durante o projeto do diagrama de classes, quando essas informaes estiverem disponveis. 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.

3.2.1.4. Atividade: Refinar Viso do Diagrama de Casos de Uso para Regras

de Negcio

Com as RNs identificadas, classificadas e registradas, sugere-se que elas sejam representadas graficamente como casos de uso. Dessa forma, pode-se ter uma viso mais ampla do sistema e dos relacionamentos que essas RNs mantm 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 padro do PU (Larman, 2007) que no influenciada pela abordagem. Para que os casos de uso referentes s regras de negcio sejam diferenciados dos demais, sugere-se tambm a utilizao do esteretipo <<business rule>> e a criao de vises individuais para as RNs, com o intuito de no poluir demais o diagrama de casos de uso. Os casos de uso que representam RNs geralmente devem ser relacionados aos seus

66 casos de uso base por meio de relacionamentos do tipo Extenso (Extend), uma vez que as RNs representam funcionalidades extras que so 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 situao so as RNs que representam fluxos de eventos, j que podem representar seqncias necessrias execuo 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 Inadimplncia e Controlar Durao da Reserva. Essa modelagem deve representar a influncia de RNs sobre o comportamento de um caso de uso. Essas RNs so obtidas a partir do artefato Relao de Regras de Negcio (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.

3.2.2. Disciplina Projeto

O objetivo da disciplina projeto a definio 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 sero projetadas. Como citado na seo 1.1.4, o paradigma orientado a aspectos adequado para o projeto das RNs, porm podem existir situaes nas quais esse paradigma no seja o ideal, sendo coerente projet-las como componentes de objetos. Nessa disciplina esto as atividades de projeto das RNs que visam definir como elas sero projetadas e posteriormente implementadas. As prximas subsees detalham as atividades dessa disciplina.

67

3.2.2.1. Atividade: Definir Paradigma de Projeto das Regras

As quatro caractersticas necessrias implementao de RNs (Separao, Rastreamento, Exteriorizao e Posicionamento) sugerem que as RNs devem ser projetadas separadamente do ncleo do software. O uso da orientao a aspectos contribui para isso e tm-se mostrado vivel ao projeto das RNs (Cibrn et. al, 2003; Cibrn et. al, 2004; Camargo e Masiero, 2005). Porm, existem outros fatores que devem ser considerados e que podem influenciar a deciso de projetar as RNs com orientao a aspectos, ou de forma convencional, com orientao a objetos, tais como: espalhamento do cdigo, quebra da integridade do cdigo (separao de parte da funcionalidade base implementada no cdigo), volatilidade, entre outros . Para apoiar a deciso sobre o paradigma que deve ser usado no projeto das RNs so propostos critrios com o objetivo de indicar quando uma RN deve, ou no, ser implementada com aspectos. So eles: Quantidade de Relacionamentos, No-Incluso, e Volatilidade. Os dois primeiros critrios foram propostos por Camargo (2006) e utilizados neste trabalho. A seguir so detalhados os critrios: Quantidade de Relacionamentos: Caso uma RN possua dois ou mais relacionamentos com casos de uso base do software, desejvel que ela seja projetada como um aspecto. Dessa forma o uso de OA evitaria o espalhamento do cdigo relativo regra. A anlise da quantidade de relacionamentos de uma RN pode ser feita com o uso do diagrama de casos de uso, na viso na qual as RNs foram modeladas. Esse critrio deve ser reaplicado a cada iterao 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 iterao. No-Incluso: Esse critrio considera os relacionamentos do tipo Incluso (Include) entre dois casos de uso. Como o comportamento dos casos de uso de incluso um complemento ao comportamento do caso de uso base, geralmente eles so necessrios funcionalidade base definida nesse caso de uso. Dessa forma, sua separao poderia causar uma falsa impresso de independncia e desacoplamento, o que pode ser prejudicial ao sistema, no devendo assim ser projetada como candidata a aspectos. Assim, caso uma RN

68 no possua relacionamentos de incluso, ela candidata a ser projetada como aspecto. Volatilidade: Considera a sensibilidade s mudanas de uma RN. Caso uma RN mostre-se estvel, bem definida e pouco sujeita a mudanas, no existe a necessidade de separ-la do ncleo do software, uma vez que o benefcio de sua separao seria pequeno ou nulo. Assim, essa RN no deve ser projetada como candidata a aspectos, caso contrrio ela uma candidata a ser projetada com esse paradigma. Porm, essa uma avaliao muito subjetiva, e deve ser realizada com base nas informaes e experincias obtidas junto empresa durante a elicitao de requisitos. Ainda assim esse critrio deve ser utilizado de forma cuidadosa, uma vez que est passivo a erros de interpretao. O critrio Quantidade de Relacionamentos possui precedncia sobre os demais, ou seja, sempre que ele for satisfeito a RN dever ser projetada com o paradigma OA. Caso ele no seja satisfeito, necessrio que os dois outros critrios sejam satisfeitos para que a RN seja projetada com OA. Isso ocorre pelo fato do critrio Quantidade de Relacionamentos possuir peso suficiente para determinar o paradigma de uma RN, j que quando um caso de uso possui vrios relacionamentos o espalhamento de cdigo eminente. Ao passo que os demais critrios so secundrios, e no possuem peso suficiente para, sozinhos, determinar o paradigma de uma RN, necessitando assim que ambos sejam atendidos caso o critrio principal no seja atendido. Isso se justifica, uma vez que o fato de uma RN no possuir relacionamentos de incluso sendo voltil, ou sendo voltil possuindo relacionamentos de incluso no geram um cenrio determinante para que uma RN seja projetada como aspecto. Uma vez determinadas quais RNs sero 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.

3.2.2.2. Atividade: Projetar as Regras de Negcio no Diagrama de Classes

Neste ponto do projeto do software tm-se as RNs relacionadas no artefato Lista de Regras e representadas graficamente no diagrama de casos de uso (numa viso prpria). A partir disso o projeto do software continua e sero projetadas as classes que iro compor a parte base do software, na atividade do PU anterior a essa. Para projetar as RNs juntamente

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 mtodo da classe a que ela pertence, porm deve-se utilizar um esteretipo para que esse mtodo seja identificado como uma RN e satisfaa (mesmo que parcialmente) a caracterstica de Separao (Von Halle, 2002). O Esteretipo 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

conseqentemente transformou-se num mtodo 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 notao proposta por Pawlak et al. (2002) para projetar a regra no diagrama de classes. Nessa notao os autores utilizam-se de classes com o esteretipo <<aspect>> para identificar os aspectos. importante ressaltar que a partir desse ponto do projeto essas RN sero aspectos. Os mtodos da classe so utilizados para representar os adendos (advices) do aspecto, para isso so utilizados os esteretipos <<before>>, <<after>> e <<around>> que representam o tipo de adendo a ser implementado. As associaes com esteretipos <<pointcut>> so utilizadas para indicar quais as classes base que o aspecto entrecorta. Essas associaes utilizam-se de etiquetas valoradas (tagged value) para identificar os mtodos e atributos da classe base que sero entrecordados pelo aspecto. O formato das etiquetas valoradas so ?metodo(..) ou !metodo(..) no qual o caractere ? indica que o mtodo entrecortado pelo aspecto no contexto de chamada (call) e o caractere ! indica que o mtodo entrecortado pelo aspecto no contexto de execuo (execution). A definio do ponto de juno da RN (aspecto) pode ser apoiada pelo valor da coluna Ponto de Atuao, do artefato Relao de Regras de Negcio, j que foi preenchida com o intuito de indicar em que momento a RN influenciar o software base.

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 mtodo Set_Data().

Figura 3.6 - Modelagem de uma RN com o uso da abordagem Pawlak et al.

3.3. Rastreamento das Regras de Negcio

Com aplicao da abordagem proposta neste trabalho, possvel obter um bom nvel de rastreamento das RNs desde o caso de uso at a sua implementao. Isso possvel pela ligao que estabelecida partindo do caso de uso, documentado no gabarito proposto, passando pela Lista de Regras, diagrama de classes, at chegar implementao do software. Na Figura 3.7 mostrado um exemplo no qual o caso de uso Gerar Vendas, documentado pelo gabarito, possui na seo Ps-Condies uma RN do tipo restrio, que projetada com o paradigma OA e d origem ao aspecto VerificarCredito. Dessa forma possvel, partindo-se de uma RN, chegar at ao caso de uso que a originou, e em direo contrria, chegar at ao artefato que a implementou.

3.4. Consideraes Finais

Neste captulo foi apresentada a descrio da abordagem de desenvolvimento de software com RNs, que a base dessa dissertao. A apresentao ocorreu com a fundamentao terica da proposta, seu enquadramento no ciclo de vida padro de desenvolvimento de software, e com a proposta de uma extenso ao Processo Unificado, originalmente proposto por Jacobson et al.(1999).

71

Figura 3.7 - Rastreabilidade de uma Regra de Negcio

72 O objetivo deste captulo foi fornecer o embasamento terico necessrio aplicao dessa abordagem. No prximo captulo apresentada a aplicao da abordagem em um estudo de caso real, o que fornece um bom nvel de exemplificao e ajuda a compreender melhor a abordagem

73

CAPTULO 4 ESTUDO DE CASO

Neste captulo apresentado um estudo de caso que foi utilizado para a gerao e validao da proposta apresentada nesta dissertao. 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 vesturio. O software originalmente desenvolvido, com base nesses requisitos, faz parte das solues oferecidas pela DataPlus Sistemas, porm no foi utilizado o paradigma OO no projeto original do software, o que impediu uma comparao do projeto da verso original com a verso desenvolvida nesse estudo de caso, pelo fato de estarem em paradigmas diferentes. Na Seo 4.1 mostrada a definio do estudo de caso, na seo 4.2 so mostrados os detalhes da execuo do estudo de caso, e na seo 4.3 so feitas as consideraes finais desse captulo

4.1. Definio
O objeto deste estudo de caso o desenvolvimento de um software para controlar as atividades de uma loja do setor de vesturio. Esse controle abrange as operaes cotidianas de uma empresa desse tipo, sendo elas: manuteno dos dados cadastrais necessrios operao do software (Cliente, Fornecedores, Produtos etc), controle das vendas efetuadas, apurao da comisso 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 Apndice B. O objetivo deste estudo de caso a utilizao da abordagem apresentada nessa dissertao. Dessa forma espera-se que o uso da abordagem propicie a construo de um software no qual as RNs estejam implementadas com base em artefatos independentes do ncleo do software, favorecendo as futuras manutenes do software, bem como o reso das RNs e do prprio software, j que as RNs podem ser mais facilmente desacopladas do software resultante. Alm disso, espera-se tambm que o uso da abordagem favorea o rastreamento das RNs permitindo que se possam identificar facilmente todos os artefatos utilizados na implementao de uma determinada RNs, apoiando as quatro caractersticas

74 necessrias implementao de RNs (Separao, Rastreamento, Exteriorizao e Posicionamento). O estudo de caso foi realizado pelo prprio autor. O material necessrio para esse estudo foi: Fundamentao de RNs (Business Rules Group, 2000; Von Halle, 2002; Ross, 2003), Guia da API Java 1.5.1 e Manuais do SGBD MS-SQLSERVER 8.0. A modelagem foi feita com o apoio da ferramenta Rational XDE, a codificao foi realizada na linguagem Java utilizando a API J2SE 1.5 e a API AspectJ 1.5, o IDE utilizado foi o Eclipse verso 3.2. A execuo do caso de uso est detalhada na prxima seo.

4.2. Execuo
A execuo do estudo de caso ocorreu com a aplicao da extenso do PU proposta nessa abordagem, cumprindo-se assim uma seqncia 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 Interao; 8. Projetar regras de negcio; 9. Implementar classes do domnio; 10. Implementar regras de negcio; 11. Testar;

O estudo de caso foi executado com um pequeno nmero de iteraes (as fases de elaborao e construo foram executadas em apenas uma iterao). Isso ocorreu pelo fato do desenvolvimento ser baseado em um software j existente e estvel, sendo assim a diviso em diversas iteraes no iria gerar uma contribuio significativa para esse estudo de caso. Algumas dessas atividades no foram modificadas ou influenciadas pela abordagem proposta. As demais atividades (em negrito) compem a abordagem proposta, ou sofreram algum tipo de alterao por ela. As atividades modificadas (ou criadas) esto detalhadas nas prximas sees.

75

4.2.1. Documentar Casos de Uso com Gabarito

Os casos de uso foram identificados e registrados na atividade anterior. Isso ocorreu da forma convencional, com base no PU, sem qualquer influncia 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 so mostrados os casos de uso com uma viso independente para cada ator. A documentao dos casos de uso que possuem RNs pode ser vista no Apndice C.

Figura 4.1 - Casos de uso do ator Vendedor

Figura 4.2 - Casos de uso do ator Administrador

76

Figura 4.3 - Casos de uso do ator Gerente

Figura 4.4 - Casos de uso do ator Caixa

Para este estudo de caso so utilizados dois casos de uso (Gerar Venda e Movimentar Estoque). Isso ocorre para evitar uma extenso inadequada ao contexto deste trabalho. As especificaes destes casos de uso so mostradas nas Figuras 4.5 e 4.6. O preenchimento das sees do gabarito proposto deve se feito mediante anlise do documento de requisitos. Para que o foco do trabalho seja mantido s so comentadas as sees includas ou alteradas pela abordagem, uma vez que as demais sees foram preenchidas na atividade anterior.

77

Figura 4.5 - Documentao do caso de uso Gerar Venda

Figura 4.6 - Documentao do caso de uso Movimentar Estoque

Na identificao dos fluxos alternativos dos casos de uso (assim como nas pr e pscondies) a questo chave para o uso adequado da abordagem a identificao da origem da informao. Para ilustrar essa questo ser utilizada uma comparao entre dois comportamentos identificados como fluxos alternativos, como seguem:

78 a) Um movimento de estoque do tipo sada s ser aceito com quantidade menor ou igual ao atributo quantidade em estoque, no cadastro do produto. b) Na gravao da venda, o valor de desconto no 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 movimentao 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 ao especfica caso sua condio no seja satisfeita, porm apenas um deles uma RN. Aplicando-se os critrios para identificao de RNs, mostrados na Seo 3.2.1.2.a., nesse trecho do documento de requisitos pode-se perceber que ambos os comportamentos satisfazem ao critrio das decises, uma vez que ambos possuem uma condio para serem acionados. Com isso nenhum deles ir representar um fluxo de eventos (critrio Fluxo de Eventos). Porm o comportamento a essencial ao funcionamento genrico do seu caso de uso, uma vez que no seria admissvel que um software de gesto de lojas permitisse que fosse registrada uma venda de um produto que no tenha disponibilidade de estoque. J o comportamento b no essencial ao funcionamento genrico do seu caso de uso, j que nem todas as lojas impem restries de descontos no ato da venda, pois podem gerenciar esses descontos posteriormente, por meio de relatrios especficos. Sendo assim o critrio de Essencialidade foi determinante para apurar a origem desses comportamentos.

Figura 4.7 - Requisito 8 (oito) referente a movimentao de estoque

79

Figura 4.8 - Requisito 10 (dez) referente ao registro de vendas.

Alm disso, pode-se apurar que o comportamento a tem por objetivo o cumprimento de uma necessidade de integridade das informaes manipuladas pelo software, o que no o caracteriza como uma RN. J o comportamento b tem por objetivo o cumprimento de uma poltica da empresa, que o caracteriza como uma RN. Em resumo, a identificao das RNs ocorreu com o uso dos critrios para a identificao das RNs associado teoria de RN. A identificao tambm foi apoiada pelo uso do gabarito, uma vez que o engenheiro de software pode identificar RNs que atuam em situaes especficas (fluxo alternativo de eventos, pr e ps-condies e gatilhos), o que reduz o domnio de identificao de acordo com cada seo do gabarito. A identificao do tipo de RN na seo Fluxo Alternativo (assim como na seo Gatilhos) utiliza como critrio de escolha o objetivo do comportamento registrado como fluxo alternativo, aliado teoria de RN. Uma vez que no contexto deste trabalho foram

80 identificados trs tipos de fluxo alternativo (e de gatilhos) a escolha torna-se relativamente simples, bastando para isso observar-se o resultado da ao desempenhada. Como exemplo, sero utilizados alguns fluxos alternativos extrados do documento de requisitos, como segue: c) O valor unitrio dos produtos s poder ser alterado caso o usurio do sistema tenha nvel de acesso de gerente; d) Dever tambm ser realizada uma checagem para apurar se o cliente ter alguma duplicata que ir vencer nos prximos 7 (sete) dias, caso tenha, uma mensagem dever ser exibida para o usurio; No fluxo c percebe-se que o resultado da RN, caso a condio seja satisfeita, a habilitao de uma funcionalidade do caso de uso, que a possibilidade de alterao dos valores unitrios 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 condio, uma advertncia ao ator, dessa forma o tipo do fluxo alternativo Diretriz. As pr e ps-condies 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. Alm disso, a identificao da origem deve atentar-se s observaes supracitadas. Os gatilhos so parecidos com as ps-condies, porm descrevem outros tipos de comportamento. O engenheiro de software deve atentar-se de que os gatilhos cuja origem no seja de negcio, no devem ser includos nessa seo, mas sim modelados da forma clssica, com casos de uso e relacionamentos.

4.2.2. Identificar e Classificar Regras de Negcio

O objetivo dessa atividade a aplicao das diretrizes de identificao e classificao das RNs, o que possibilita a extrao das RNs da documentao dos casos de uso. Foi possvel perceber, nesse ponto do desenvolvimento, que o esforo maior para a identificao das RNs ocorre durante a documentao 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 ateno maior a identificao de RNs com mltiplas ocorrncias. Para essa identificao necessrio atentar-se para RNs que sejam

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 considervel a identificao de RNs candidatas a aspectos (Seo 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 de Uso Verificar se o caixa anterior est Restrio Abrir fechado Caixa Caso o cliente possua duplicatas Diretriz Gerar a vencer nos prximos 7 dias Vendas dever ser gerado um aviso ao usurio Caso o cliente possua duplicatas Habilitad Gerar a vencer nos prximos 7 dias a ora Vendas pesquisa financeira do cliente dever ser exibida Caso o cliente tenha duplicatas Diretriz Gerar vencidas e no pagas dever ser Vendas gerada uma advertncia para que a situao seja regularizada seno a venda no ser aceita Caso o usurio no seja gerente Habilitad Gerar a alterao do preo dos ora Vendas produtos dever ser bloqueada Caso seja o ms de aniversrio Deriva Gerar do cliente, o desconto dever ser o Vendas preenchido com o valor de 5% do total da venda necessrio que o caixa esteja Restrio Gerar aberto para que uma venda seja Vendas registrada, alterada ou excluda. O valor de desconto no dever Restrio Gerar ser superior a 5% da venda Vendas Dever ser realizada uma Restrio Gerar checagem para apurar se o Vendas cliente tem alguma duplicata vencida e no paga, caso tenha a venda no dever ser aceita Na gravao da venda, devero Deriva Gerar ser geradas duplicatas a receber, o Vendas uma para cada vencimento constante na condio de pagamento da venda. Na gravao da venda, caso Deriva Gerar algum dos vencimentos possua o Vendas o nmero de dias do vencimento igual a 0 (o que indica que a vista), dever ser gerado um recebimento relativo duplicata do vencimento em questo, no mesmo valor da duplicata Na gravao da venda, dever Habilitad Gerar ser impresso um border ora Vendas relativo venda O atributo data do movimento Restrio Movimen s poder ser diferente da data tar do dia caso o usurio do sistema Estoque tenha nvel de acesso de gerente necessrio que o caixa esteja Restrio Gerar aberto para que um pagamento Pagament seja registrado, alterado ou o de excludo. Documen tos Regra Tipo Ponto de Id. RN Mltipla Paradig Mdulo Artefato Atuao Ocorrncia ma PrInicializao ChecarCaixa Condies Anterior Fluxo No ato de ChecarDuplA Alternativo informar o Vencer cliente Fluxo No ato de Alternativo informar o cliente Fluxo No ato de Alternativo informar o cliente MostrarPesqF inanceira Seo

AdvertirAtras os

Fluxo Na insero Alternativo de produtos na venda Fluxo Na Alternativo informao do valor do desconto PrInicializao Condies PsCondies PsCondies Gravao da Venda Gravao da Venda

Bloquear Preos GerarDescont oAniversario

VerificarCaix aAberto VerificarDesc ontoMximo VerificarCrdi to

Gatilhos

Gravao da GerarDuplicat Venda as

Gatilhos

Gravao da GerarRecebim Venda entoAVista

Gatilhos

Gravao da ChamarImpre Venda ssaoBordero

PrGravao da VerificarAces Condies Movimenta so o PrInicializao VerificarCaix Condies aAberto X

82
Na gravao do pagamento, a Restrio Gerar Psdata de pagamento dever ser a Pagament Condies data do dia, a menos que o o de usurio do sistema tenha nvel Documen de acesso de gerente. tos Aps a incluso de um novo Habilitad Gerar Gatilhos pagamento a impresso do ora Pagament recibo acionada o de Documen tos necessrio que o caixa esteja Restrio Informar Praberto para que um recebimento Recebime Condies seja registrado, alterado ou nto de excludo. Duplicata s Na gravao do recebimento, a Restrio Informar Psdata de recebimento dever ser a Recebime Condies data do dia, a menos que o nto de usurio do sistema tenha nvel Duplicata de acesso de gerente. s Caso o custo apurado de algum Diretriz Cadastrar Fluxo produto, seja 10% menor que o Recebime Alternativo atual dever ser gerado um nto de aviso de possibilidade de Produtos campanha promocional O preo de custo de cada Habilitad Recebime Gatilhos produto dever ser atualizado ora nto de com o valor constante na Produtos entrada mais o valor rateado dos custos adicionais. A cada atualizao do custo do produto o preo de venda do mesmo dever ser atualizado Devero ser gerados os Deriva Recebime Gatilhos documentos a pagar para o o nto de fornecedor, um para cada Produtos vencimento constante na entrada Gravao do VerificarAces Pagamento so X

Aps ChamarRecPa Gravao do gto Pagamento

Inicializao VerificarCaix aAberto

Gravao do VerificarAces Recebiment so o

Na InformarRedu Gravao da oPreos Entrada

Na Gravao

AtualizarCust oVenda

Aps a Gravao

GerarDocume ntos

4.2.3. 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 esteretipos estabelecidos. Essa modelagem foi realizada em uma viso prpria, o que mostrou-se vlido, uma vez que diversas RNs influenciam um mesmo casos de uso, e tambm, uma RN influencia diversos casos de uso, o que polui de forma considervel o diagrama original. Na Figura 4.9 so mostradas as partes mais relevantes do diagrama de casos de uso com a modelagem das RNs.

83

Figura 4.9 - Diagrama de casos de uso com a modelagem das regras de negcio

84

4.2.4. Definir Paradigma de Projeto das Regras de Negcio

O processo de definio do paradigma de projeto de uma regra consiste na aplicao dos critrios nas RNs constantes na Lista de Regras. Para ilustrar esse processo foram selecionadas algumas regras para que a aplicao dos critrios seja comentada, como segue: a) Caso o usurio no seja gerente a alterao do preo dos produtos dever ser bloqueada; b) Na gravao da venda, dever ser impresso um border relativo venda; c) necessrio que o caixa esteja aberto para que um pagamento seja registrado, alterado ou excludo; d) O valor de desconto no dever ser superior a 5% da venda A RN a foi desconsiderada OA (e sim OO) por no atender ao critrio Quantidade de Relacionamentos, j que possui um nico relacionamento, atender ao critrio NoIncluso, j que no possui relacionamentos de incluso e no atender ao critrio Volatilidade. Dessa forma, como o critrio precedente no foi atendido, e apenas um dos critrios secundrios foi atendido, essa RN ser projetada OO. A questo da volatilidade foi determinada durante a fase de elicitao de requisitos, quando os analistas apuraram que nesse tipo de empresa a alterao de preos dos itens de venda algo incomum, uma vez que eventuais descontos so concedidos no campo designado a isso. Sendo assim, muito embora essa caracterstica seja prpria da empresa, essa uma RN que dificilmente ser modificada. A RN b foi desconsiderada OA (e sim OO) pelo fato de no atender ao critrio precedente Quantidade de Relacionamentos, no atender ao critrio No-Incluso, uma vez que o relacionamento com a funcionalidade representada pelo caso de uso Gerar Vendas do tipo incluso, ou seja, o comportamento de impresso do border est includo no caso de uso Gerar Venda, embora atenda ao critrio Volatilidade. Dessa forma, como o critrio precedente no foi atendido, e apenas um dos critrios secundrios 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 cdigo, e dessa forma atende ao critrio precedente Quantidade de Relacionamentos. Por fim, a RN d no atende ao critrio de quantidade de relacionamentos, porm atende aos critrios de No-Incluso, j que no possui nenhum relacionamento de incluso

85 com os casos de uso, e atende ao critrio de volatilidade, j que no possui as caractersticas de uma regra estvel, o que faz com que ela seja projetada como OA, j que atendeu aos dois critrios secundrios, embora no tenha atendido ao critrio precedente. Aps a definio do paradigma de projeto das RNs, o artefato Lista de Regras deve ser atualizado, preenchendo-se a coluna paradigma com a informao OA ou OO, para que essa informao 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 prxima atividade a modelagem das RNs no diagrama de classes.
Tabela 4.2 - Lista de Regras totalmente preenchida.
Ponto de Id. RN Mltip Paradi Atuao Ocor. gma Verificar se o caixa anterior est Restrio Abrir Caixa PrInicializao ChecarCaixaA OA fechado Condie nterior s Caso o cliente possua duplicatas Diretriz Gerar Vendas Fluxo No ato de ChecarDuplA OA a vencer nos prximos 7 dias Alternativ informar o Vencer dever ser gerado um aviso ao o cliente usurio Caso o cliente possua duplicatas Habilitad Gerar Vendas Fluxo No ato de MostrarPesqFi OA a vencer nos prximos 7 dias a ora Alternativ informar o nanceira pesquisa financeira do cliente o cliente dever ser exibida Caso o cliente tenha duplicatas Diretriz Gerar Vendas Fluxo No ato de AdvertirAtras OA vencidas e no pagas dever ser Alternativ informar o os gerada uma advertncia para o cliente que a situao seja regularizada seno a venda no ser aceita Caso o usurio no seja gerente Habilitad Gerar Vendas Fluxo Na insero Bloquear OO a alterao do preo dos ora Alternativ de produtos Preos produtos dever ser bloqueada o na venda Caso seja o ms de aniversrio Deriva Gerar Vendas Fluxo Na GerarDescont OA do cliente, o desconto dever ser o Alternativ informao oAniversario preenchido com o valor de 5% o do valor do do total da venda desconto necessrio que o caixa esteja Restrio Gerar Vendas PrInicializao VerificarCaixa OA aberto para que uma venda seja Condie Aberto registrada, alterada ou excluda. s O valor de desconto no dever Restrio Gerar Vendas PsGravao da VerificarDesc OA ser superior a 5% da venda Condie Venda ontoMximo s Dever ser realizada uma Restrio Gerar Vendas PsGravao da VerificarCrdi OA checagem para apurar se o Condie Venda to cliente tem alguma duplicata s vencida e no paga, caso tenha a venda no dever ser aceita Na gravao da venda, devero Deriva Gerar Vendas Gatilhos Gravao da GerarDuplicat OO ser geradas duplicatas a receber, o Venda as uma para cada vencimento constante na condio de pagamento da venda. Na gravao da venda, caso Deriva Gerar Vendas Gatilhos Gravao da GerarRecebim OA algum dos vencimentos possua o Venda entoAVista o nmero de dias do vencimento igual a 0 (o que indica que a vista), dever ser gerado um recebimento relativo duplicata do vencimento em questo, no mesmo valor da duplicata Na gravao da venda, dever Habilitad Gerar Vendas Gatilhos Gravao da ChamarImpres OA ser impresso um border ora Venda saoBordero relativo venda O atributo data do movimento Restrio Movimentar PrGravao da VerificarAcess OA Regra Tipo Caso de Uso Seo Mdulo Artefato

ChecarCx Checagem Anterior ChecaDu Checagem plVencer

Mostrar Pesquisa PesqFina nceira VerificaA Checagem traso

Bloquear Bloqueio Precos ChecaDes Checagem cNiver

Verificar Checagem CaixaAbe rto ChecaDes Checagem conto Verificar Checagem Credito

Venda

GeraDocs Receber

GerarRec Gerador Vista

Venda

ImprimirB ordero

Verificar Checagem

86
s poder ser diferente da data do dia caso o usurio do sistema tenha nvel de acesso de gerente necessrio que o caixa esteja aberto para que um pagamento seja registrado, alterado ou excludo. Na gravao do pagamento, a data de pagamento dever ser a data do dia, a menos que o usurio do sistema tenha nvel de acesso de gerente. Aps a incluso de um novo pagamento a impresso do recibo acionada necessrio que o caixa esteja aberto para que um recebimento seja registrado, alterado ou excludo. Na gravao do recebimento, a data de recebimento dever ser a data do dia, a menos que o usurio do sistema tenha nvel 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 preo de custo de cada produto dever ser atualizado com o valor constante na entrada mais o valor rateado dos custos adicionais. A cada atualizao do custo do produto o preo de venda do mesmo dever ser atualizado Devero ser gerados os documentos a pagar para o fornecedor, um para cada vencimento constante na entrada Estoque Condie Movimenta o s o X Acesso

Restrio Gerar PrInicializao VerificarCaixa Pagamento de Condie Aberto Documentos s Restrio Gerar PsGravao do VerificarAcess Pagamento de Condie Pagamento o Documentos s

Habilitad Gerar ora Pagamento de Documentos Restrio Informar Recebimento de Duplicatas

Gatilhos

Aps ChamarRecPa Gravao do gto Pagamento PrInicializao VerificarCaixa Condie Aberto s

OO

Pagament ImprimirR o ecibo

Restrio Informar PsGravao do VerificarAcess Recebimento Condie Recebimento o de Duplicatas s

Diretriz

Cadastrar Fluxo Na Gravao InformarRedu Recebimento Alternativ da Entrada oPreos de Produtos o

OA

Verificar Checagem Reducao

Habilitad Recebimento Gatilhos ora de Produtos

Na Gravao AtualizarCust oVenda

OO

Produto

AtualizarP rVenda

Deriva Recebimento Gatilhos o de Produtos

Aps a Gravao

GerarDocume ntos

OO

Entrada

GerarDocs Pagar

4.2.5. Projetar Regras de Negcio no Diagrama de Classes

Com as RNs identificadas, classificadas e com o paradigma de projeto definido, o prximo 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 definio dos pontos de juno das RNs que foram projetadas como aspectos. A informao Ponto de Atuao, presente no artefato Relao de Regras de Negcio, um auxilio bastante til, pois evita que seja necessrio uma nova anlise dos requisitos em busca da identificao do momento que uma RN deve ser acionada. Para ilustrar essa atividade sero 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

87 paradigma OA, como mostrado na Figura 4.10. Para projetar o ponto de juno dessa RN (que agora um aspecto), seguiu-se a orientao registrada na Lista de Regras que indicava que seu ponto de atuao deveria ser na inicializao da classe. Dessa forma, seu ponto de juno a instncia da classe (mtodo main) com o tipo de adendo before, o que possibilita que uma exceo seja gerada, caso o caixa da loja no esteja aberto.

Figura 4.10 - Regra de negcio projetada como aspecto

b) Checar Desconto: O objetivo dessa RN verificar se o desconto concedido na venda no excedeu o desconto mximo permitido. Essa RN de negcio foi projetada no paradigma OA, como mostrado na Figura 4.11. Para projetar o ponto de juno dessa RN foi considerado o ponto de atuao indicado na relao de regras de negcio, que indicava que a RN deveria ser acionada na gravao da venda. Assim, seu ponto de juno foi projetado como a chamada do mtodo cadastra() com o tipo de adendo before, possibilitando assim que a venda no seja gravada, caso o desconto seja excessivo.

88

Figura 4.11 - Regra de Negcio candidata a aspecto

Na Figura 4.12 so mostradas RNs, mais relevantes, projetadas e modeladas no diagrama de classes. O diagrama de classes resultante proporciona uma viso ampla da parte esttica do software, com as RNs projetadas juntamente com as classes que compem o ncleo do software.

4.2.6. Implementar as Regras de Negcio

O objetivo desta atividade implementar as RNs para que elas componham o software e se integrem ao ncleo funcional deste. A implementao seguiu o que estava projetado, respeitando o paradigma no qual cada regra foi projetada. O nico ponto que deve ser salientado que a abordagem no ofereceu subsdio s RNs/Aspectos que atuam num mesmo ponto de juno, fazendo com que a definio de prioridade dessas regras ocorresse de forma emprica.

89

Figura 4.12 - Diagrama de Classes.

90

4.3. Consideraes Finais

Na conduo do estudo de caso foram encontradas algumas dificuldades, sendo elas: i) identificao dos comportamentos do software oriundos de eventos de negcio: ocorre pela necessidade de conhecimento prvio do conceito de RNs; ii) aplicao do critrio de volatilidade na identificao das RNs candidatas a aspectos: ocorre pela peculiaridade do critrio, que suscetvel a diferentes julgamentos por parte dos engenheiros de software; iii) identificao e registro das RNs que possuem mais de um relacionamento com casos de uso base: a identificao dessas RNs e seu registro de forma adequada, sem que sejam registradas diversas vezes, est totalmente a cargo do engenheiro de software, sem apoio da abordagem proposta. As dificuldades i e ii tiveram uma assimilao razovel, de forma que elas foram extinguindo-se com a prtica da abordagem. J a dificuldade iii mais complexa e necessitaria de uma avaliao minuciosa, talvez podendo ser resolvida com a aplicao de tcnicas de modelagem de RNs mais aprimoradas. Todavia a limitao de tempo impediu uma investigao mais conclusiva desse problema, no escopo desse trabalho. Durante a conduo do estudo de caso ocorreram algumas situaes nas quais as RNs necessitaram de alteraes, mesmo com o desenvolvimento no ocorrendo num ambiente de produo real, j que o software utilizado como base para o estudo de caso um novo desenvolvimento orientado a objetos de um software real, originalmente desenvolvido com o paradigma estruturado. Em todas essas situaes a abordagem apoiou a localizao das RNs e seus artefatos, de forma bastante positiva. Porm no foram executadas medies e comparaes que permitissem uma mensurao dessa contribuio. Por fim, foi possvel concluir que para uma melhor validao da abordagem seria necessria sua aplicao num ambiente de manuteno intensa do software desenvolvido, para que os conceitos de rastreabilidade, separao e posicionamento das RNs pudessem ser colocados prova. Porm isso no foi possvel no escopo desse trabalho.

91

CONCLUSES
Neste trabalho foi apresentada uma abordagem para o desenvolvimento de software com RNs. Essa abordagem composta de um gabarito para a documentao de casos de uso, critrios de identificao de RNs, critrios para a classificao de RNs e critrios para a identificao de RNs candidatas a aspectos. Essa abordagem foi apoiada por um artefato para o registro das RNs identificadas no software. Para o projeto das RNs foram propostos esteretipos no diagrama de casos de uso e no diagrama de classes, e foi utilizada a notao proposta por Pawlak et al. (2004) para o projeto das RNs projetadas como aspectos. A abordagem foi estruturada como uma extenso do PU proposto por Jacobson et al. (1999) e apresentado por Larman (2007). Essa extenso criou novas atividades, e alterou atividades j existentes nas diversas matrias que compe o PU. Como parte da pesquisa foi conduzido um estudo de caso baseado na especificao de um software real. Esse estudo de caso foi til para validar a abordagem e fornecer detalhes para o enriquecimento e aprimoramento da abordagem.

Principais Contribuies
A principal contribuio deste trabalho foi fornecer meios ao engenheiro de software para que as RNs sejam modeladas de forma independente do ncleo do software. Isso ocorreu por meio de uma abordagem de desenvolvimento de software que possibilita que as RNs sejam identificadas e classificadas nas fases iniciais do desenvolvimento de software. A abordagem tambm permitiu que as RNs sejam registradas e projetadas de forma independente do ncleo do software. Essa abordagem foi estruturada como uma extenso do PU. Como contribuies secundrias podem ser citados: i) Critrios para a identificao de RNs: esses critrios apiam a identificao de RNs no documento de requisitos do software; ii) Critrios para a identificao de RNs candidatas a aspectos: esses critrios apiam a identificao de RNs, que pelas suas caractersticas mostram-se adequadas para serem projetadas com o paradigma OA; iii) Rastreamento das RNs: com o uso da abordagem no desenvolvimento do software foi possvel obter um rastreamento dos artefatos de software utilizados no projeto das RNs, isso foi possvel devido ao uso de artefatos que apiam esse quesito.

92

Limitaes
Uma das limitaes do presente trabalho a no utilizao de um formalismo mais forte na especificao das RNs. Ao invs do caminho trilhado poderia ter sido utilizado um formalismo na especificao das regras juntamente com mecanismos que permitissem a decomposio das regras em termos e fatos, e a vinculao desses termos e fatos a elementos de software. Com isso seria possvel solucionar um gap semntico que permaneceu na abordagem proposta, que o gap entre a especificao descritiva dos pontos de atuao das regras e os elementos de software que o viabilizam. Outra limitao presente a ausncia da aplicao da abordagem num ambiente de manuteno intensa do software desenvolvido, para que os conceitos de rastreabilidade, separao e posicionamento das RNs pudessem ser colocados prova.

Trabalhos Futuros
Para a continuidade do presente trabalho pode-se sugerir algumas linhas de pesquisa a serem seguidas que enriqueceria e complementaria a pesquisa atual, sendo elas: i) Prioridades das regras: seria importante dispor de alguns critrios, ou outro tipo de mecanismos, que permitissem estabelecer prioridade s regras/aspectos que atuam num mesmo ponto de juno; ii) Ferramenta de apoio: seria interessante o desenvolvimento de uma ferramenta que possibilitasse a automatizao de algumas tarefas da abordagem, como por exemplo o registro das RNs; iii) Formalismo: o uso de um formalismo mais bem definido na especificao das RNs apoiaria a relao entre regras e objetos, possibilitando uma facilidade maior na identificao de pontos de juno das regras/aspectos e poderia apoiar a automatizao na gerao de cdigos para as regras estabelecidas.

93

REFERNCIAS
ALHIR, Sinan Si. Learning UML. OReilly, 2003. APPLETON, Daniel S. Business Rules: The Missing Link. In Datamation Journal, 1984, pp. 145150. BAJEC, Marko; KRISPER , Marjan. A methodology and tool support for managing business rules in organisations. In: Information Systems v.30 n.6, p.423-443, 2004 BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia do Usurio, Traduo de Fbio Freitas da Silva, Rio de Janeiro, Editora Campus Ltda, 2000. BUSINESS RULES GROUP. Defining Business Rules: What Are They Really?, 2000 Disponvel em: http://www.businessrulesgroup.org Acesso em: 15 Ago 2006. CAMARGO, Valter Vieira de. Frameworks transversais: definies, classificaes, arquitetura e utilizao em um processo de desenvolvimento de software. Tese Doutorado ICMC/USP, So Carlos, SP, 2006. CAMARGO, Valter Vieira de; MASIERO, Paulo Cesar. Frameworks Orientados a Aspectos. In XIX Simpsio Brasileiro de Engenharia de Software, Uberlndia, MG, Brasil, 2005. CIBRN, Mara Agustina; DHONDT, Maja. High-level specification of business rules and their crosscutting connections. In. 8th International Workshop on Aspect-Oriented Modeling at the International Conference on Aspect-Oriented Programming (AOSD'06), Bonn, Germany, 2006. CIBRN, Mara Agustina; DHONDT, Maja; JONCKERS, Viviane. Aspect-Oriented Programming for Connecting Business Rules. In. Proceedings Business Information Systems (BIS), Colorado Springs, USA, 2003 CIBRN, Mara Agustina; SUVE, Davy; DHONDT, Maja; VANDERPERREN, Win; JONCKERS, Viviane. Integrating Rules with Object-Oriented Software Applications using Aspect-Oriented Programming. In Proceedings of the International Conference of the Argentine Society for Computer Science and Operational Research (SADIO), Crdoba, Argentina, 2004. DATE, C. J. What Not How The Business Rules Approach to Application Development. Boston: Addison-Wesley, 2000. ELRAD, Tzilla; FILMAN, Robert. E.; BADER, Atef. Aspect-Oriented Programming. Communications of the ACM. Vol. 44, No 10. Outubro/2001a ELRAD, Tzilla; MEHMET, Aksit, KICZALES, Gregor; LIEBERHERR, Karl; OSSHER, Harold. Discussing Aspects of AOP. Communications of the ACM. Vol.. 44, No 10. Outubro/2001b.

94 ILOG JRULES, Bloor Research - ILOG Jrules 6.0 White Paper. Disponvel em: http://www.ilog.com/products/jrules/whitepapers/ Acesso em: 29 Set 2008. JACOBSON, I; BOOCH, G; RUMBAUGH, J. The Unified Software Development Process. Reading, MA. Addison-Wesley, 1999. JACOBSON, Ivar; Ng, Pan-Wei. Aspect-Oriented Software Development with Use Cases. Massachusetts: Addison-Wesley, 2004. KICZALES, Gregor; HILSDALE, Erik; HUGUNIN, Jim; KERSTEN, Mik; PALM, Jeffrey; GRISWOLD, William G. Getting Started with AspectJ. Communications of the ACM. Vol. 44, No 10. Outubro/2001. KICZALES, Gregor; HILSDALE, Erik; HUGUNIN, Jim; KERSTEN, Mik; PALM, Jeffrey; GRISWOLD, William G. An Overview of AspectJ. In Proceedings of the 15th European Conference on Object-Oriented Programming (ECOOP). Springer, 2001b. KORTHAUS A. Using UML for business object based systems modeling In The Unified Modeling Language - Technical Aspects and Applications, pg: 220-237. Physica-Verlag, Heidelberg, Alemanha, 1998 LARMAN, Craig. Utilizando UML e Padres: uma introduo anlise e ao projeto orientado a objetos e ao desenvolvimento iterativo. 3 ed. Porto Alegre: Bookman, 2007. MARTINS, Alissandra Evangelista. Em direo captura e representao sistemtica das definies dos termos das regras de negcio. Dissertao de Mestrado, Universidade Federal do Rio de Janeiro Ncleo de Computao Eletrnica, Rio de Janeiro, Brasil, 2006. MORGADO, G. P. Regula Uma Ferramenta para o Gerenciamento de Regras de Negcio. Monografia (Projeto Final de Curso), Universidade Federal do Rio de Janeiro Departamento de Cincia da Computao, Rio de Janeiro, Brasil, 2005. OMG Object Management Group -Unified Modeling Language Specification. Jan 2005. Disponvel em: <http://www.uml.org/>. Acesso em Abril/2007. PAWLAK, Renaud; DUCHIEN, Laurence; FLORIN, Gerard; LEGOND-AUBRY, Fabrice; SEINTURIER, Lionel; MARTELLI, Laurent. A UML Notation for Aspect Oriented Software Design. 1st International Conference on Aspect-Oriented Software Development. Enschede, Irlanda. 2002. PENDER, Tom. UML Bible. Indianapolis: Wiley Publishing, Inc, 2003. ROSS, Ronald G.; Principles of the Business Rule Approach. Boston: Addison-Wesley, 2003 RUMBAUGH, James; JACOBSON, Ivar; BOOCH, Grady. The Unified Modeling Language Reference Manual. Reading, Massachusetts: Addison-Wesley, 1998.

95 SOARES, Srgio; BORBA, Paulo. AspectJ Programao orientada a aspectos em Java. IV Simpsio Brasileiro de Linguagens de Programao. Rio de Janeiro, Brasil. 2002. VON HALLE, Barbara: Business rules applied: building better systems using the business rules approach. New York: John Wiley & Sons Inc, 2002. ZACHMAN, John A. Enterprise Architecture: The Issue of the Century. In: Database Programming and Design magazine, 1997. WIEGERS, Karl E. More about Software Requirements. Redmont, Washington: Microsoft Press, 2006 WINK, Diogo Vincius; GOETTEN JR, Vicente. AspectJ: Programao Orientada a Aspectos com Java. So Paulo: Novatec Editora, 2006 YU, Eric; DU BOIS, Philippe; DUBOIS, Eric; MYLOPOULOS, John. From Organization Models to System Requirements A Cooperating Agents Approach. In Proceeding of the Third International Conference on Cooperative Information Systems CoopIS-95, Vienna, Austria, 1995.

96

ANEXO A
Essa seo contm a listagem do cdigo do programa utilizado com exemplo para a compreenso das novas construes da POA. Esse programa composto pelos mdulos: Conta.java: a codificao da classe conta que implementa um controle de contas correntes.
public class Conta { private String Conta; private float Saldo; public Conta(String NrConta) { this.setConta(NrConta); this.setSaldo(0); } public void Debita(float Valor) { this.Saldo -= Valor; } public void Credita(float Valor) { this.Saldo += Valor; } public float getSaldo() { return this.Saldo; } public void setSaldo(float wSaldo) { this.Saldo = wSaldo; } public String getConta() { return this.Conta; } public void setConta(String wConta) { this.Conta = wConta; } public void mostraSaldo() { System.out.println("O Saldo da Conta " + this.getConta() + " " + this.getSaldo()); } }

97 aTaxaJuros.aj: a codificao do aspecto responsvel por implementar uma regra de negcio que exibe advertncias todas as vezes que uma operao resultar em um saldo negativo para a conta.
public aspect aTaxaJuros { private float Conta.TaxaJuros; public float Conta.getTaxaJuros() { return this.TaxaJuros; } public void Conta.setTaxaJuros(float wJuros) { this.TaxaJuros = wJuros; } public Conta.new(String NrConta, float TxJuros) { setConta(NrConta); setTaxaJuros(TxJuros); setSaldo(0); } pointcut AvisoSaldo(Conta wContaAviso) : call( * Conta+.mostraSaldo(..)) && target(wContaAviso); after(Conta wContaAviso) : AvisoSaldo(wContaAviso) { if(wContaAviso.getSaldo() < 0) { System.out.println(""); System.out.println("O Custo deste saldo ser de " + ((wContaAviso.getTaxaJuros() * wContaAviso.getSaldo())/100)*-1 + " ao ms."); System.out.println(""); } } }

Principal.Java: a codificao do mdulo principal do programa que instancia a classe Conta e realiza algumas operaes.
public class Principal { public static void main(String[] args) { Conta wConta = new Conta("1818-5",6); wConta.Credita(800); wConta.Debita(1000); wConta.mostraSaldo(); } }

98

APNDICE A
Nesta seo so apresentados os fundamentos tericos sobre POA. Na Seo A.1 so descritos os fundamentos das linguagens de programao que apiam a POA. Na Seo A.2 so detalhadas as novas construes fornecidas pelo paradigma POA.

A1. Linguagens de Suporte Programao Orientada a Aspectos

Nesta subseo so apresentados, por meio de fundamentos da Linguagem AspecJ, os principais conceitos de uma linguagem POA. Esses conceitos so importantes para o entendimento das caractersticas que permitem a POA atuar de modo no invasiva, e como essas caractersticas fornecem meios para a implementao dos interesses transversais sem que ocorra o espalhamento e entrelaamento do cdigo das classes. Para que uma linguagem de programao oferea os recursos necessrios para a modularizao dos interesses transversais, necessrio que ela possua cinco elementos bsicos (Elrad et al., 2001b), sendo eles: Um modelo de pontos de juno descrevendo os ganchos onde comportamentos adicionais podem ser includos. Uma forma de identificar pontos de juno. Uma forma de especificar comportamentos para os pontos de juno. Unidade que encapsulem tanto a especificao de pontos de juno quanto comportamentos adicionais. Um mtodo (ou processo) para ligar as unidades aos programas.

Alm disso, uma linguagem tambm precisa respeitar as trs propriedades bsicas da POA (Elrad et al., 2001): Dicotomia aspectos-base: a separao entre classes e aspectos, em que as classes devem implementar os interesses bsicos e os aspectos os interesses transversais; Inconscincia: o conceito de que os componentes no precisam ser preparados para serem entrecortados por aspectos; Quantificao: a capacidade de escrever declaraes unitrias e independentes que podem afetar muitos pontos do sistema.

99 Por fim, uma Linguagem POA precisa ter o combinador aspectual (weaver) que o prprio compilador de aspectos, responsvel pela recomposio aspectual, sendo que, dado o cdigo fonte de um sistema e um conjunto de aspectos, ele gera uma verso do sistema com estes aspectos (Soares e Borba, 2002) Na prxima seo abordado como esses elementos foram aplicados Linguagem AspecJ.

A2. Novas Construes POA

Nas prximas subsees sero detalhadas e exemplificadas as novas construes fornecidas pelo paradigma POA. Todos os exemplos e definies so baseados na linguagem de programao AspecJ.

A2.1. Pontos de Juno

Os pontos de juno so locais bem definidos, na estrutura de um programa, que identificam em que momento, ou situao, o aspecto dever ser combinado com a classe (Wink e Goetten Jr, 2006). Na Tabela A.1 so relacionados os tipos de ponto de juno implementados em AspecJ (Kiczales et al., 2001b).

Tabela A.1 Pontos de juno dinmicos do AspecJ (adaptado de Kiczales et al., 2001b) Tipo de ponto de juno Chamada de um mtodo ou construtor Recepo da chamada de um mtodo ou construtor Execuo de um mtodo ou construtor Acesso de leitura (get) a um atributo Acesso de modificao (set) de um atributo Execuo do manipulador de excees (handler exception) Inicializao de uma classe Inicializao de um objeto Ponto na execuo do programa em que... Um mtodo (ou um construtor de uma classe) chamado. Um objeto recebe a chamada de um mtodo ou construtor. A execuo de um mtodo individual ou construtor invocada. Um atributo de um objeto, classe ou interface lido. Um atributo de um objeto ou classe modificado. Uma exceo invocada. Ocorre a execuo de inicializadores estticos so executados Inicializadores dinmicos de uma executados durante a criao do objeto. classe so

100

A2.2. Conjuntos de Juno

Os conjuntos de juno so mecanismos usados para definir pontos de juno e funcionam como uma regra criada pelo desenvolvedor para especificar eventos que sero afetados pelo aspecto (Wink e Goetten Jr, 2006). Uma das caractersticas dos conjuntos de juno permitir que pontos de juno genricos sejam definidos sem que fiquem dependentes da nomenclatura e termos utilizados no cdigo que ser entrecortado. Isso geralmente feito por meio de coringas (wildcards), como por exemplo, (*), (..) e (+) que sero explicados com mais detalhes adiante. Os conjuntos de juno devem ser escritos dentro de um aspecto, e devem ser identificados com nomes, semelhantes s classes da Linguagem Java. Um elemento importante do conjunto de juno o designador, ele o elemento responsvel por selecionar o conjunto de pontos de juno para o conjunto de juno em questo. Na Tabela A.2 so relacionados os designadores disponveis em AspecJ (Wink e Goetten Jr, 2006). Os designadores podem ainda ser reunidos, utilizando-se dos seguintes combinadores lgicos: && (e) Quando ambos os argumentos para os operadores forem verdadeiros || (ou) Quando um ou mais argumentos para os operadores forem verdadeiros ! (no) Identifica todos os pontos de juno que no foram identificados pelo conjunto de juno. A Linguagem AspectJ possui algumas notaes coringas que auxiliam na especificao dos designadores, que representam: * Qualquer nmero de caracteres, com exceo do .. .. Qualquer nmero de caracteres, incluindo o . + Qualquer subclasse ou interface da classe especificada.

101
Tabela A.2 Designadores disponveis em AspectJ (Wink e Goetten Jr, 2006) Designador Execution Call Initialization Handler Get Set This Target Args Cflow Cflowbelow staticinitialization Withincode Within IF adviceexecution preinitialization Descrio Corresponde execuo de um mtodo ou de um construtor. Corresponde chamada para um mtodo ou para um construtor. Corresponde inicializao de um objeto, representada pela execuo do primeiro construtor para a classe. Corresponde manipulao das excees. Corresponde referncia para um atributo de uma classe. Corresponde definio de um atributo de uma classe. Retorna o objeto associado com o ponto de juno em particular ou limita o escopo de um ponto de juno utilizando um tipo de classe. Retorna o objeto alvo de um ponto de juno ou limita o escopo do mesmo. Expe os argumentos para ponto de juno ou limita o escopo de um conjunto de juno. Retorna os pontos de juno na execuo do fluxo de outro ponto de juno Retorna os pontos de juno na execuo do fluxo de outro ponto de juno, exceto o ponto corrente. Corresponde inicializao dos elementos estticos de um objeto. Corresponde aos pontos de juno contidos em um mtodo ou construtor. Corresponde aos pontos de juno contidos em um tipo especfico. Permite que uma condio dinmica faa parte de um conjunto de juno. Corresponde ao adendo (advice) do ponto de juno. Corresponde pr-inicializao de um ponto de juno.

Na Figura A.1 mostrado um exemplo de conjunto de juno para um controle de contas correntes. Nesse exemplo o conjunto de juno VerificaSaldo ir entrecortar a chamada aos mtodos Debita() da classe Conta, quando chamado com quaisquer parmetros e com qualquer tipo de retorno, e ir tambm entrecortar o mtodo Credita(), da classe Conta e de todas as suas especializaes, com qualquer sufixo, ou seja, se existir um mtodo CreditaConta() este tambm ser entrecortado, desde que esses mtodos recebam dois parmetros do tipo inteiro (int) e retorne um valor tambm do tipo inteiro.

Figura A.1 Exemplo de conjunto de juno.

102

A2.3. Adendos
Segundo Kiczales et al. (2001b), adendo uma construo, semelhante a uma classe, usada para declarar que determinado cdigo deve ser executado em cada um dos pontos de juno de um conjunto de juno. Na Tabela A.3 so relacionados os tipos de adendos disponveis em AspectJ.

Tabela A.3 Tipos de adendos disponveis em AspectJ (Wink e Goetten Jr, 2006)

Designador Before

Descrio Executa quando o conjunto de juno alcanado, mas imediatamente antes da sua computao.

after returning after throwing After

Executa aps a computao com sucesso do conjunto de juno. Executa aps a computao sem sucesso do conjunto de juno. Executa aps a computao do conjunto de juno, em qualquer situao.

Around

Executa quando o ponto de juno alcanado e tem total controle sobre a computao.

Os adendos do tipo before e os trs tipos de after so estritamente aditivos, fazendo com que o cdigo escrito no corpo do adendo seja executado antes ou depois da computao do ponto de juno capturado. O adendo around tem a capacidade de cercar o ponto de juno capturado fazendo com que o cdigo do ponto de juno seja executado em qualquer ponto do cdigo do corpo do adendo, ou ainda, podendo fazer com que o cdigo do ponto de juno execute mais de uma vez. Na Erro! Fonte de referncia no encontrada. mostrado um exemplo de adendo do tipo around para um aspecto que adiciona feriados municipais em uma funo de clculo de feriados. Os adendos ainda podem ter acesso a variveis especiais, reflexivas que fornecem informaes referentes ao ponto de juno capturado, essas variveis so: thisJoinPoint Encapsula informaes estticas e dinmicas do ponto de juno.

103 thisJoinPointStaticPart Guarda informaes do contexto esttico do ponto de juno. thisEnclosingJoinPointStaticPart Guarda informaes estticas do ponto de juno mais prximo, sentido acima, do capturado.

Figura Exemplo deadendo um adendo do around tipo around. Figura A.2 1.1 Exemplo de um do tipo

A2.4. Modificao de Estruturas Estticas

Na seo anterior mostrou-se como os aspectos podem afetar dinamicamente o cdigo-base de uma aplicao. Nesta seo, o objetivo mostrar como os aspectos podem afetar estaticamente o cdigo-base por meio de declaraes intertipos. As possveis formas de declaraes intertipos so (Wink e Goetten Jr, 2006): Incluso de membros (mtodos, construtores, atributos) para tipos (classes, interfaces ou outros aspectos). Incluso de implementao concreta para interfaces. Declarao de que tipo estende um novo ou implementa uma nova interface. Declarao da precedncia do aspecto.

104 Declarao de erros de compilao customizveis ou avisos. Converso de excees checadas (checked exceptions) para no checadas (unchecked). Na Figura A.3 so mostrados exemplos de declarao intertipos para incluso de mtodos, construtores e atributos, em um aspecto cuja funo controlar o custo dos juros para contas bancrias cujos saldos sejam negativos, funcionalidade essa que no estava prevista na classe original (Conta).

Figura A.3 Exemplos de declarao intertipos

A2.5. Aspectos
Aspectos so as principais unidades modulares para a implementao de um interesse transversal (Kiczales et al., 2001b). A forma de declarao dos aspectos, em AspectJ, similar forma de declarao de uma classe. O corpo do cdigo de um aspecto pode conter declaraes de conjuntos de juno, adendos, bem como outros tipos de declaraes permitidas em classes, ou seja, modificaes da estrutura esttica. O aspecto possui um especificador de acesso que segue a mesma regra dos especificadores de acesso para classes em Java.

105 A Linguagem AspectJ permite que aspectos abstratos possam ser construdos e reusados por outros aspectos posteriormente. Um aspecto pode tambm herdar caractersticas de outras classes e interfaces, no entanto, no permitido que uma classe estenda ou implemente um aspecto (Wink e Goetten Jr, 2006).

106

APNDICE B
Nesta seo so apresentados os documentos de requisitos do software utilizado no estudo de caso dessa dissertao:

B1. Viso Geral do Sistema

O sistema para a loja de roupas unissex Veste Bem consiste no gerenciamento de suas vendas, compras e seu estoque, controlando desde o recebimento dos produtos comprados at as vendas da loja.

B2. Requisitos Funcionais

Os requisitos funcionais do software esto divididos em: cadastros, lanamentos diversos, consultas on-line e relatrios e impresses.

B2.1. Cadastros
1. O sistema deve permitir a incluso, alterao e remoo de clientes, contendo os seguintes atributos: cdigo do cliente, nome, endereo, bairro, cidade onde mora, CEP, estado, telefone, email, RG, CPF e data de nascimento.

2. O sistema deve permitir a incluso, alterao e remoo de produtos de venda classificados por marca e grupo de produtos, com os seguintes atributos: referncia do item, descrio, unidade, cdigo de barra, preo de custo, margem de lucro, preo de venda e quantidade em estoque, estoque mnimo.

3. O sistema deve permitir a incluso, alterao e remoo de vendedores da loja, com os seguintes atributos: cdigo do vendedor, nome, endereo, cidade, CEP, estado, telefone, CPF, data de nascimento e % de comisso.

107 4. O sistema deve permitir a incluso, alterao e remoo de fornecedores da loja, com os seguintes atributos: razo social, endereo, bairro, cidade, estado, cep, telefone, CNPJ, e e-mail.

5. O sistema deve permitir a incluso, alterao e remoo das marcas dos produtos, com os seguintes atributos: cdigo da marca, nome da marca e margem de lucro.

6. O sistema deve permitir a incluso, alterao e remoo dos grupos de produtos, com os seguintes atributos: cdigo do grupo e descrio.

7. O sistema deve permitir a incluso, alterao e remoo de condio de pagamento, com os atributos: cdigo, descrio, % de desconto e nmero de dias para cada vencimento (num mximo de 6)

B2.2. Lanamentos Diversos

8. O sistema deve permitir a incluso, alterao e remoo de movimentaes de estoque, com os seguintes atributos: nmero de registro do movimento, referncia do produto, tipo de movimento (entrada ou sada), data do movimento e quantidade. Sempre que um movimento de estoque for gerado, a quantidade em estoque constante no cadastro do produto dever ser atualizada. Na alterao, caso o produto, a quantidade ou o tipo de movimentao for alterada, a alterao dever ser refletida no atributo quantidade em estoque do cadastro de produto, o mesmo deve ocorrer na excluso. Um movimento de estoque do tipo sada s ser aceito com quantidade menor ou igual ao atributo quantidade em estoque, no cadastro do produto. No ato da gravao da movimentao de estoque, o atributo data do movimento s poder ser diferente da data do dia caso o usurio do sistema tenha nvel de acesso de gerente.

9. O sistema deve permitir a incluso, alterao e remoo de entrada de produtos, que so os produtos oriundos das compras efetuadas com os fornecedores, com os seguintes atributos: nmero da nota fiscal, cdigo do fornecedor, data de entrada, data de emisso da nota fiscal, custos adicionais, referncia dos produtos recebidos, quantidade de cada produto, valor unitrio de cada produto e condio de pagamento (que ser composta por

108 data de vencimento e valor, podendo se repetir at seis vezes). Na incluso ou alterao de entrada de produtos o preo de custo de cada produto dever ser atualizado com o valor constante na entrada mais o valor rateado dos custos adicionais. Na gravao da incluso, caso o custo apurado na entrada seja menor que o custo atual do produto, o custo do produto no dever ser atualizado e caso o percentual de reduo seja superior a 10% dever ser gerado um aviso ao usurio informando a possibilidade de uma campanha promocional para o produto, caso o custo apurado na entrada seja 20% maior que o custo atual do produto, dever ser gerado uma advertncia ao usurio, informando o percentual de aumento que o produto teve. A cada atualizao do custo do produto o preo de venda do mesmo dever ser atualizado. No ato da gravao de uma entrada de produtos, dever ser geradas movimentaes de estoque do tipo entrada, para cada produto informado, com a quantidade equivalente entrada e com a data igual a data de entrada. Ainda na gravao da entrada devero ser gerados os documentos a pagar para o fornecedor, um para cada vencimento constante na entrada, com os atributos: nmero do documento (que deve ser obtido com a juno do nmero da nota fiscal de entrada + o caractere - + o nmero da parcela + o caractere / + o total de parcelas), cdigo do fornecedor (igual ao da entrada), data de emisso (igual a data de emisso da nota fiscal), data de vencimento (igual a data do vencimento) e valor (igual ao valor do vencimento). Deve ser observado que mais de um fornecedor podem emitir o mesmo nmero de nota fiscal. Na alterao, as mudanas realizadas devem ser refletidas nas movimentaes geradas. Na excluso as movimentaes geradas devem ser excludas.

10. O sistema deve permitir a incluso, alterao e remoo de vendas, com os seguintes atributos: nmero da nota fiscal, data da venda, cdigo do cliente, cdigo do vendedor, cdigo da condio de pagamento, valor de desconto, cdigo dos produtos, quantidade dos produtos e valor unitrio dos produtos. Para que uma venda seja registrada necessrio que exista um caixa aberto. A data da venda dever ser igual a data atual. Caso o cliente no seja cadastrado o sistema deve permitir seu cadastro no ato da venda. O valor unitrio dos produtos dever ser o valor de venda constante no cadastro do produto tirado o desconto informado na condio de pagamento, e s poder ser alterado caso o usurio do sistema tenha nvel de acesso de gerente. Na gravao da venda, o valor de desconto no dever ser superior a 5% da venda. Na gravao da venda, os produtos constantes nela devero ter quantidade igual ou menor ao valor do atributo quantidade em

109 estoque, do cadastro de produto. Quando o cliente for informado dever ser checado se o ms de aniversrio dele o ms atual, caso seja, uma mensagem dever ser exibida, e na gravao da venda, o valor do desconto dever ser equivalente a 5% do total. Dever tambm ser realizada uma checagem para apurar se o cliente ter alguma duplicata que ir vencer nos prximos 7 dias, caso tenha uma mensagem dever ser exibida para o usurio e dever ser mostrada a pesquisa financeira com os dados do cliente;. No ato da gravao de uma venda, alguns procedimentos devero ser executados: i) dever ser geradas movimentaes de estoque do tipo sada, para cada produto informado, com a quantidade equivalente quantidade vendida e com a data igual a data da venda; ii) devero ser geradas duplicatas a receber, uma para cada vencimento constante na condio de pagamento da venda, com os atributos: nmero da duplicata (que deve ser obtido com a juno do nmero da venda + o caractere - + o nmero da parcela + o caractere / + o total de parcelas), cdigo do cliente (igual ao da venda), data de emisso (igual a data da venda), data de vencimento (data da venda + nmero de dias da parcela) e valor (valor total da venda dividido pelo nmero de parcelas); iii) caso algum dos vencimentos possua o nmero de dias do vencimento igual a 0 (o que indica que a vista), dever ser gerado um recebimento relativo duplicata do vencimento em questo, no mesmo valor da duplicata; iv) dever ser realizada uma checagem para apurar se o cliente tem alguma duplicata vencida e no paga, caso tenha a venda no dever ser aceita. Aps a venda ser gravada, dever ser emitido um border com todos os dados relativos venda. Todas as informaes geradas no ato da gravao da venda devero ter as mudanas, referente a alteraes, refletidas em seus dados. Na excluso todas as informaes geradas no ato da gravao de uma venda devem ser excludas.

11. O sistema dever permitir o recebimento de duplicatas previamente geradas no ato da venda. Para que um recebimento seja registrado necessrio que exista um caixa aberto. Devero ser preenchidos os atributos data do recebimento e valor. O valor de um recebimento dever ser menor ou igual ao valor em aberto (diferena entre valor valor pago) de uma duplicata. Quanto o total j pago de uma duplicata for igual ao seu valor o atributo quitada dever ser preenchido com o valor 1. A data de recebimento dever ser a data do dia, a menos que o usurio do sistema tenha nvel de acesso de gerente. Na alterao ou excluso de recebimentos o valor do atributo quitada deve ser reavaliado.

110 12. O sistema dever permitir o pagamento de documentos previamente gerado no ato da entrada de produtos. Para que um pagamento seja registrado necessrio que exista um caixa aberto. Os pagamentos podero ser feitos por usurios que tenham nvel de acesso de caixa ou gerente. Devero ser preenchidos os atributos data do pagamento e valor. O valor de um pagamento dever ser menor ou igual ao valor em aberto (diferena entre valor valor pago) de um documento. Quanto o total j pago de um documento for igual ao seu valor o atributo quitado dever ser preenchido com o valor 1. A data de pagamento dever ser a data do dia, a menos que o usurio do sistema tenha nvel de acesso de gerente. Na alterao ou excluso de pagamentos o valor do atributo quitado deve ser reavaliado.

13. O sistema dever possuir o controle de caixa, que deve ser aberto todas as vezes que o sistema entrar em operao. Sem que o caixa esteja aberto o sistema deve bloquear as aes de venda, recebimento e pagamento. Os demais procedimentos podem ser acessveis. Quando um caixa aberto o sistema deve trazer o troco restante do caixa anterior como valor inicial para o caixa atual. No fechamento de caixa, o sistema deve mostrar todos os recebimentos e pagamentos do caixa atual, e mostrar o saldo, considerando o saldo de abertura (saldo inicial + recebimentos pagamentos) e perguntar ao usurio qual o saldo que ficar no caixa (troco). O registro do caixa dever possuir os seguintes atributos: data abertura, seqncia, saldo inicial, total de recebimentos, total de pagamentos e saldo final. Para que um usurio possa abrir ou fechar o caixa ele dever ter nvel de acesso de gerente, ou de caixa.

B2.3. Consultas on-line

14. O sistema deve permitir uma pesquisa financeira do cliente, que dever constar: duplicatas vencidas e a vencer, ordenadas pelos atributos: quitada + data de vencimento. Para cada duplicata dever ser mostrado seus pagamentos. Dever contar os totais: total de duplicatas geradas, valor total em aberto e valor total vencido. As duplicatas vencidas e no pagas devero ter uma cor diferenciada.

15. O sistema deve permitir uma pesquisa de produtos vendidos por cliente, que dever constar: referncia do produto, descrio, data da venda, quantidade e valor unitrio.

111

B2.4. Impresso de diversos tipos de relatrios e consultas

16. O sistema deve permitir a impresso de um border de venda, contendo todos os dados da venda.

17. O sistema deve permitir a impresso de um recibo no ato de um recebimento de duplicata, contendo: nmero da duplicata, data de emisso, data de vencimento, nome e CPF do cliente, valor do pagamento, valor do pagamento por extenso e data de pagamento

18. O sistema deve permitir, opcionalmente, a impresso de um recibo no ato de um pagamento de documento, contendo: nmero do documento, data de emisso, data de vencimento, nome e CNPJ do fornecedor, valor do pagamento, valor do pagamento por extenso e data de pagamento

19. O sistema deve permitir a impresso de um relatrio de caixa no ato do procedimento de fechamento de caixa, contendo: saldo inicial, recebimentos (nmero da duplicata, nome do cliente, data de vencimento, valor da duplicata e valor do recebimento), pagamentos (nmero do documento, nome do fornecedor, data de vencimento, valor do documento e valor do pagamento), saldo final e troco em caixa.

20. O sistema deve permitir a impresso de uma listagem de estoque contando referncia, descrio, tipo de produto, unidade, quantidade em estoque. Devero ser includos todos os produtos cujo atributo quantidade em estoque seja maior que zero, ordenada pelos atributos: Tipo de produto + descrio do produto.

21. O sistema deve permitir a impresso de uma listagem dos produtos que estejam com estoque abaixo do mnimo estabelecido, ou seja, todos os produtos cujo atributo quantidade em estoque seja menor ou igual ao atributo estoque mnimo. A listagem dever ser ordenada pelos atributos: tipo de produto + descrio do produto, e dever conter: referncia, descrio, unidade, tipo de produto, quantidade em estoque e estoque mnimo.

112 22. O sistema deve permitir a impresso de uma listagem de valores de comisso. Os dados de entrada para essa listagem sero: cdigo do vendedor, data inicial da apurao e data final da apurao. A listagem dever conter: nmero da venda, data da venda, nome do cliente, valor total da venda, % de comisso e valor da comisso. Os campos total d a venda e valor da comisso devero ser totalizados. O percentual da comisso deve ser obtido no cadastro do vendedor. A listagem dever ser ordenada pela data da venda.

23. O sistema deve permitir a impresso de uma listagem de vendas por perodo. Os dados de entrada para essa listagem sero: data inicial e data final. Dever constar: nmero da venda, data da venda, nome do cliente e valor total da venda. O valor total da venda dever ser totalizado. A listagem deve ser ordenada pela data da venda, e devero ser filtradas as vendas relativas ao intervalo de datas informado.

24. O sistema deve permitir a impresso de uma listagem de produtos vendidos por perodo Os dados de entrada para essa listagem sero: data inicial e data final. Dever constar: referncia do produto, quantidade vendida, valor total vendido e valor mdio (deve ser o resultado da diviso do valor total vendido pela quantidade vendida). O valor total vendido dever ser totalizado. A listagem deve ser ordenada pela descrio do produto, e devero ser filtradas as vendas relativas ao intervalo de datas informado.

25. O sistema deve permitir a impresso de uma listagem de contas a receber. Os dados de entrada para essa listagem sero: data inicial e data final. Dever constar: Nmero da duplicata, nome do cliente, data de emisso, data de vencimento, valor da duplicata, valor pago, saldo a receber. Devero ser filtradas as duplicatas que no estejam quitadas (campo quitada <> 1), e cuja data de vencimento esteja no intervalo de datas informado. A listagem dever ser ordenada pela data de vencimento + nome do cliente.

B3. Requisitos No Funcionais B3.1. Confiabilidade

26. O sistema deve ter capacidade para recuperar os dados perdidos da ltima operao que realizou em caso de falha.

113 27. O sistema deve fornecer facilidades para a realizao de backups dos arquivos do sistema.

28. O sistema deve possuir senhas de acesso e identificao para diferentes tipos de usurios: administrador do sistema, gerente e vendedores.

B3.2. Eficincia
29. O sistema deve responder a consultas on-line em menos de 5 segundos.

30. O sistema deve iniciar a impresso de relatrios solicitados dentro de no mximo 20 segundos aps sua requisio.

31. Todas as rotinas que possuem a referncia de um produto como entrada, devero estar preparadas para receber tanto a referncia digitada manualmente, quanto o cdigo de barra do produto, obtido por meio de um leitor de cdigo de barras.

B3.3. Portabilidade
32. O sistema deve ser executado em computadores Pentium 200mHz ou superior, com sistema operacional Windows 98 ou acima.

33. O sistema deve ser capaz de armazenar os dados em base de dados SQL-Server.

114

APNDICE C
Nesta seo so apresentadas as documentaes relativas aos casos de uso que possuem RNs. Esses casos de uso esto descritos nas prximas sees:

C1. Caso de uso Abrir Caixa

Caso de Uso: Abrir Caixa Descrio: Realizar a abertura de caixa para que o fluxo de trabalho seja iniciado Fluxo Principal: Seq Descrio 1 Registrar a data de abertura do caixa 2 Registrar a seqncia do caixa 3 Buscar e exibir o saldo inicial do caixa 4 Solicitar uma confirmao da abertura do caixa 5 Gravar um novo caixa Fluxo Alternativo: Seq Origem Pr-Condies: Origem Negcio Ps-Condies: Origem Tipo Condio Ao

Condio Verificar se o caixa imediatamente anterior est devidamente fechado Condio

Gatilhos: Tipo de Gatilho Caso de Gatilho Uso Diretriz Habilitador Derivao

C2. Caso de uso Fechar Caixa

Caso de Uso: Abrir Caixa Descrio: Realizar a abertura de caixa para que o fluxo de trabalho seja iniciado Fluxo Principal: Seq Descrio 1 Registrar a data de abertura do caixa 2 Registrar a seqncia do caixa 3 Buscar e exibir o saldo inicial do caixa 4 Solicitar uma confirmao da abertura do caixa 5 Gravar um novo caixa Fluxo Alternativo: Seq Origem Pr-Condies: Origem Tipo Condio Ao

Condio

115 Negcio Ps-Condies: Origem Verificar se o caixa imediatamente anterior est devidamente fechado Condio

Gatilhos: Tipo de Gatilho Caso de Gatilho Uso Diretriz Habilitador Derivao

C3. Caso de uso Gerar Vendas

Caso de Uso: Gerar Vendas Descrio: Permite a Incluso, Alterao e Excluso de vendas Fluxo Principal: Seq Descrio 1 O Usurio inicia uma nova venda informando o nmero da nota fiscal 2 A Data da venda preenchida 3 O cliente relacionado com a venda pesquisado e informado na venda 4 O vendedor informado 5 So informados os produtos, quantidades e preos 6 informada a condio de pagamento 7 informado o valor do desconto concedido 8 A Venda gravada 9 A gerao das movimentaes de estoque acionada Fluxo Alternativo: Seq Origem 1.1 Sistema 1.2 Sistema Tipo Condio Ao Uma venda j existente pesquisada e inicia-se sua edio Uma venda j existente pesquisada e o processo de remoo acionado, nesse caso o fluxo desviado para a seqncia 8. Inicia o processo de cadastramento do cliente Dever ser gerado um aviso ao usurio A pesquisa financeira do cliente dever ser exibida Dever ser gerada uma advertncia para que a situao seja regularizada seno a venda no ser aceita A alterao do preo dos produtos dever ser bloqueada O desconto dever ser preenchido com o valor de

3.1 3.2

Negcio Habilitador Negcio Diretriz

3.3

Negcio Habilitador

3.4

Negcio Diretriz

O cliente no foi encontrado pelo usurio O cliente possui duplicatas a vencer nos prximos 7 dias. O cliente possui duplicatas a vencer nos prximos 7 dias. O cliente possui duplicatas vencidas e no pagas. O usurio no possui status de gerente. O ms atual o mesmo da data de

5.1 7.1

Negcio Habilitador Negcio Derivao

116 aniversrio do cliente. 8.1 9.1 Sistema Sistema 5% do total da venda Caso seja uma excluso, a venda removida do sistema Caso seja uma edio, as mudanas ocorridas nos produtos informados na venda so refletidas nas movimentaes de estoque Caso seja uma excluso, todas as movimentaes de estoque geradas devem se excludas

9.2

Sistema

Pr-Condies: Origem Negcio Ps-Condies: Origem Negcio Negcio Condio Na gravao da venda, o valor de desconto no dever ser superior a 5% da venda Na gravao da venda, os produtos constantes nela devero ter quantidade igual ou menor ao valor do atributo quantidade em estoque, do cadastro de produto Na gravao da venda, dever ser realizada uma checagem para apurar se o cliente tem alguma duplicata vencida e no paga, caso tenha a venda no dever ser aceita Ao Condio necessrio que o caixa esteja aberto para que uma venda seja registrada, alterada ou excluda.

Negcio

Gatilhos: Tipo de Gatilho Caso de Uso Diretriz Habilitador Derivao X Gerar Duplicatas a Receber

Na gravao da venda, devero ser geradas duplicatas a receber, uma para cada vencimento constante na condio de pagamento da venda, com os atributos: nmero da duplicata (que deve ser obtido com a juno do nmero da venda + o caractere - + o nmero da parcela + o caractere / + o total de parcelas), cdigo do cliente (igual ao da venda), data de emisso (igual a data da venda), data de vencimento (data da venda + nmero de dias da parcela) e valor (valor total da venda dividido pelo nmero de parcelas) Informar Na gravao da venda, caso algum dos Recebimento vencimentos possua o nmero de dias do de Duplicata vencimento igual a 0 (o que indica que a vista), dever ser gerado um recebimento

117 relativo duplicata do vencimento em questo, no mesmo valor da duplicata Imprimir Aps a gravao da venda, dever ser Border de impresso um border relativo venda. Venda

C4. Caso de uso Movimentar Estoque

Caso de Uso: Movimentar Estoque Descrio: Permite a Incluso, Alterao e Excluso de movimentao de estoque de produtos Fluxo Principal: Seq Descrio 1 Uma nova movimentao de estoque iniciada 2 A referncia do produto informada 3 O tipo de movimento informado (Entrada ou Saida) 4 A data do movimento informada 5 A quantidade do movimento informada 6 A movimentao de estoque gravada 7 O atributo quantidade em estoque do produto atualizado Fluxo Alternativo: Seq Origem Tipo Condio Ao 1.1 Sistema Uma movimentao j existente pesquisada e inicia-se sua edio 1.2 Sistema Uma movimentao j existente pesquisada e o processo de remoo acionado, nesse caso o fluxo desviado para a seqncia 6. 5.1 Sistema Caso seja uma sada, verifica-se se existe quantidade disponvel no atributo quantidade em estoque, caso no exista o fluxo deve retornar para a seqncia 5 Pr-Condies: Origem Condio Ps-Condies: Origem Negcio Condio No ato da gravao da movimentao de estoque, o atributo data do movimento s poder ser diferente da data do dia caso o usurio do sistema tenha nvel de acesso de gerente

Gatilhos: Tipo de Gatilho Caso de Gatilho Uso Diretriz Habilitador Derivao

C5. Caso de uso Gerar Pagamento de Documentos

Caso de Uso: Gerar Pagamento de Documentos Descrio: Permitir o pagamento de documentos previamente gerados no ato do recebimento

118 de produtos Fluxo Principal: Seq Descrio 1 O documento que ser a base do pagamento informada ou identificada 2 A data de pagamento informada 3 O valor do pagamento informado 4 O atributo quitado atualizado 5 O pagamento gravado Fluxo Alternativo: Seq Origem Tipo Condio Ao 1.1 Sistema Um pagamento j existente informado ou localizado, e inicia-se o processo de edio. 1.2 Sistema Um pagamento j existente pesquisado e o processo de remoo acionado, nesse caso o fluxo desviado para a seqncia 5. 3.1 Sistema O valor do pagamento deve ser menor que o valor do documento menos o valor j pago, caso contrrio uma advertncia gerada e fluxo retorna para a seqncia 3 Pr-Condies: Origem Condio Negcio necessrio que o caixa esteja aberto para que um pagamento seja registrado, alterado ou excludo. Ps-Condies: Origem Condio Negcio Na gravao do pagamento, a data de pagamento dever ser a data do dia, a menos que o usurio do sistema tenha nvel de acesso de gerente. Gatilhos: Tipo de Gatilho Caso de Gatilho Uso Diretriz Habilitador Derivao X Imprimir Aps a incluso de um novo pagamento a Recibo de impresso do recibo acionada Pagamento

C6. Caso de uso Informar Recebimento de Duplicatas

Caso de Uso: Informar Recebimento de Duplicatas Descrio: Permitir o recebimento de duplicatas previamente geradas no ato da venda Fluxo Principal: Seq Descrio 1 A duplicata que ser a base do recebimento informada ou identificada 2 A data de recebimento informada 3 O valor do recebimento informado 4 O atributo quitada atualizado 5 O recebimento gravado 6 A Impresso do recibo acionada Fluxo Alternativo: Seq Origem Tipo Condio Ao 1.1 Sistema Um recebimento j existente informado ou localizado, e inicia-se

119 1.2 Sistema o processo de edio. Um recebimento j existente pesquisado e o processo de remoo acionado, nesse caso o fluxo desviado para a seqncia 5. O valor do recebimento deve ser menor que o valor da duplicata menos o valor j pago, caso contrrio uma advertncia gerada e fluxo retorna para a seqncia 3

3.1

Sistema

Pr-Condies: Origem Negcio Ps-Condies: Origem Negcio

Condio necessrio que o caixa esteja aberto para que um recebimento seja registrado, alterado ou excludo. Condio Na gravao do recebimento, a data de pagamento dever ser a data do dia, a menos que o usurio do sistema tenha nvel de acesso de gerente.

Gatilhos: Tipo de Gatilho Caso de Gatilho Uso Diretriz Habilitador Derivao

C7. Caso de uso Cadastrar Recebimento de Produtos

Caso de Uso: Cadastrar Recebimento de Produtos Descrio: Permite a Incluso, Alterao e Excluso de entrada de produtos Fluxo Principal: Seq Descrio 1 Um novo recebimento iniciado informando-se o nmero da nota fiscal de entrada e o cdigo do fornecedor 2 A data de entrada informada 3 A data da nota fiscal informada 4 Os custos adicionais so informados 5 So informados os produtos, quantidades e valores unitrios 6 So informados os pagamentos 7 A entrada gravada 8 So geradas as movimentaes de estoque Fluxo Alternativo: Seq Origem Tipo Condio Ao 1.1 Sistema Um recebimento j existente pesquisado, e inicia-se sua edio 1.2 Sistema Um recebimento j existente pesquisado e o processo de remoo acionado, nesse caso o fluxo desviado para a seqncia 7. 7.1 Sistema Caso seja uma excluso, o recebimento removido do sistema 7.2 Negcio Diretriz Caso o custo Na incluso, dever ser apurado, de algum gerado um aviso de

120 7.3 Negcio Diretriz produto, seja 10% menor que o atual Caso o custo apurado, de algum produto, seja 20% maior que o atual possibilidade de campanha promocional. Na incluso, dever ser gerada uma advertncia ao usurio. Caso seja uma edio, as mudanas ocorridas nos produtos informados no recebimento so refletidas nas movimentaes de estoque Caso seja uma excluso, todas as movimentaes de estoque geradas devem se excludas

8.1

Sistema

8.2

Sistema

Pr-Condies: Origem Ps-Condies: Origem

Condio Condio

Gatilhos: Tipo de Gatilho Diretriz Habilitador Derivao X

Na incluso ou alterao de entrada de produtos o preo de custo de cada produto dever ser atualizado com o valor constante na entrada mais o valor rateado dos custos adicionais. A cada atualizao do custo do produto o preo de venda do mesmo dever ser atualizado. Gerar Na gravao da entrada devero ser Documentos gerados os documentos a pagar para o a Pagar fornecedor, um para cada vencimento constante na entrada, com os atributos: nmero do documento (que deve ser obtido com a juno do nmero da nota fiscal de entrada + o caractere - + o nmero da parcela + o caractere / + o total de parcelas), cdigo do fornecedor (igual ao da entrada), data de emisso (igual a data de emisso da nota fiscal), data de vencimento (igual a data do vencimento) e valor (igual ao valor do vencimento)

Caso de Uso Atualizar Valores de Custo e Venda dos Produtos

Gatilho