argus oliveira guedes williams falcão damasceno ... - UCSAL
argus oliveira guedes williams falcão damasceno ... - UCSAL
argus oliveira guedes williams falcão damasceno ... - UCSAL
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
ARGUS OLIVEIRA GUEDES<br />
WILLIAMS FALCÃO DAMASCENO MACHADO<br />
ABREP - UMA FERRAMENTA PARA ANOTAÇÃO DAS REGRAS DE<br />
NEGÓCIO EM PROTÓTIPOS EVOLUTIVOS.<br />
SALVADOR<br />
2010
ARGUS OLIVEIRA GUEDES<br />
WILLIAMS FALCÃO DAMASCENO MACHADO<br />
ABREP - UMA FERRAMENTA PARA ANOTAÇÃO DAS REGRAS DE<br />
NEGÓCIO EM PROTÓTIPOS EVOLUTIVOS.<br />
Monografia apresentada ao Curso de<br />
Bacharelado em Informática da<br />
Universidade Católica do Salvador como<br />
requisito parcial à obtenção do diploma de<br />
Bacharel em Informática.<br />
Orientador: Prof. Antonio Claudio Pedreira<br />
Neiva.<br />
SALVADOR<br />
2010
UNIVERSIDADE CATÓLICA DO SALVADOR<br />
CURSO DE BACHARELADO EM INFORMÁTICA<br />
DEPARTAMENTO DE INFORMÁTICA<br />
ABREP - UMA FERRAMENTA PARA ANOTAÇÃO DAS REGRAS DE<br />
NEGÓCIO EM PROTÓTIPOS EVOLUTIVOS.<br />
BANCA EXAMINADORA<br />
__________________________________<br />
Prof. Antonio Claudio Pedreira Neiva<br />
__________________________________<br />
Prof. Likiso Hattori<br />
__________________________________<br />
Prof. Jorge Luiz Falcão Perrone<br />
SALVADOR<br />
2010
CERTIFICADO<br />
Certifico que a presente memória, ABREP - Uma ferramenta para anotação das<br />
regras de negócio em protótipos evolutivos, foi realizada sob minha orientação<br />
por ARGUS OLIVEIRA GUEDES e WILLIAMS FALCÃO DAMASCENO MACHADO,<br />
constituindo o Projeto Final do Curso de Bacharelado em Informática da Universidade<br />
Católica do Salvador – <strong>UCSAL</strong>.<br />
Salvador, 07 de junho de 2010<br />
Antonio Claudio Pedreira Neiva<br />
Curso de Bacharelado em Informática<br />
Universidade Católica do Salvador<br />
SALVADOR<br />
2010
AGRADECIMENTOS<br />
Em primeiro lugar agradecemos a Deus, pela força e resignação para conseguirmos<br />
chegar até aqui.<br />
Aos nossos pais e namoradas, por toda paciência, compreensão e carinho; por<br />
acreditarem em nosso potencial, por nos incentivarem, por estarem sempre ao nosso<br />
lado em todos os momentos difíceis ao longo dessa jornada. Agradecemos também<br />
aos membros de nossa família que sempre estiveram de nosso lado.<br />
Aos nossos amigos que participaram conosco dessa caminhada, onde vivenciamos<br />
muito momentos marcantes, felizes e alguns poucos tristes. Agradecemos a velha e<br />
boa feijoada da Escaldaria onde nos reuníamos em todos os primeiros dias aula do<br />
semestre para matar a saudade, colocar a conversa em dia e beber umas<br />
cervejinhas para enfrentar o semestre que ali começava.<br />
Agradecemos ao grande mestre Claudio Neiva, nosso orientador, pela paciência,<br />
ajuda e disponibilidade; ao mestre Likiso Hattori, que nos apoiou, nos aconselhou em<br />
momentos de dúvidas. Agradecemos a todos os outros professores pelo<br />
conhecimento passado ao longo desses cinco anos.<br />
Por último agrademos aos nossos chefes, coordenadores e colegas de trabalho pela<br />
ajuda, compreensão e liberação em todos os momentos que houve necessidade.<br />
Argus Guedes e Willians Falcão
“A vida é para quem topa qualquer parada. Não para quem pára em qualquer<br />
topada.”<br />
(Bob Marley)
RESUMO<br />
Este projeto apresenta o desenvolvimento de uma ferramenta para Eclipse que<br />
permite a anotação das regras de negócio no código fonte de uma aplicação Java<br />
(Swing) na construção de protótipos evolutivos. O objetivo dessa ferramenta é de<br />
poder recuperar as informações sobre as regras de negócio anotadas nos diversos<br />
componentes da aplicação, durante a execução da mesma, de forma intuitiva,<br />
facilitando o entendimento das mesmas (as regras) para o cliente o que contribui<br />
para verificação e validação dos requisitos do sistema a ser desenvolvido.<br />
Palavras chave: protótipo, prototipação evolutiva, requisitos, regras de negócio,<br />
anotação.
ABSTRACT<br />
This project presents the development of a tool for Eclipse that allows annotation of<br />
business rules in the source code of a Java (Swing) in evolutionary prototyping. The<br />
purpose of this tool is able to retrieve information about the business rules recorded<br />
in the various application components during the execution of it, intuitively, facilitating<br />
the understanding of these (rules) to the client which helps to check and validation of<br />
system requirements to be developed.<br />
Key words: prototype, evolutionary prototyping, requirements, business rules,<br />
annotations
SUMÁRIO<br />
INTRODUÇÃO ........................................................................................................... 1<br />
1 - REQUISITOS. ....................................................................................................... 3<br />
1.1 – CLASSIFICAÇÃO DOS REQUISITOS. ............................................................ 4<br />
1.2 – TIPOS DE REQUISITOS. .................................................................................. 5<br />
1.2.1 - Requisitos Funcionais .................................................................................. 6<br />
1.2.2 - Requisitos Não-Funcionais. ......................................................................... 6<br />
1.2.3 - Requisitos de Domínio. ................................................................................. 7<br />
2 – ENGENHARIA DE REQUISITOS. ........................................................................ 8<br />
3 – REGRAS DE NEGÓCIO. ................................................................................... 10<br />
3.1 – CLASSIFICAÇÃO DAS REGRAS DE NEGÓCIO. .......................................... 11<br />
4 - PROTÓTIPO. ...................................................................................................... 15<br />
4.1 – PROTOTIPAÇÃO DE SOFTWARE. ............................................................... 15<br />
4.2 – FASES DO PROCESSO DE DESENVOLVIMENTO DE UM PROTÓTIPO. ... 16<br />
4.3 – PROTOTIPAÇÃO DESCARTÁVEL. ............................................................... 17<br />
4.4 – PROTOTIPAÇÃO EVOLUCIONÁRIA OU EVOLUTIVA. ................................ 19<br />
4.5 – PROTÓTIPO EM PAPEL. ............................................................................... 21<br />
4.6 – PROTÓTIPO “WIZARD OF OZ”. .................................................................... 21<br />
4.7 – PROTÓTIPO AUTOMÁTICO. ......................................................................... 21<br />
4.8 – MODELOS DE DESENVOLVIMENTO. ........................................................... 22<br />
4.9 – DESENVOLVIMENTO RÁPIDO DE SOFTWARE. ......................................... 22<br />
5 - PROJETO. .......................................................................................................... 24<br />
5.1- REQUISITOS DA FERRAMENTA. ................................................................... 26
5.2 – DIAGRAMA DE CASO DE USO. .................................................................... 27<br />
5.2.1 - Casos de uso. .............................................................................................. 27<br />
5.2.2 - Especificação do caso de uso. ................................................................... 28<br />
5.3 – ARQUITETURA DO PLUG-IN......................................................................... 31<br />
5.4 – PROJETO DE DESENVOLVIMENTO. ............................................................ 33<br />
5.4.1 - Diagrama de Classe .................................................................................... 33<br />
5.4.2 - Arquivo plugin.xml ...................................................................................... 35<br />
5.4.3 - Estrutura do arquivo de regras. ................................................................. 36<br />
5.5 - FERRAMENTA. ............................................................................................... 37<br />
5.5.1 - Uso da ferramenta. ...................................................................................... 38<br />
5.5.2 - Avaliação da ferramenta. ............................................................................ 42<br />
CONCLUSÃO. ......................................................................................................... 44<br />
REFERÊNCIAS ........................................................................................................ 46<br />
APÊNDICE A ........................................................................................................... 48<br />
APÊNDICE B ........................................................................................................... 55
LISTA DE FIGURAS<br />
Figura 01: Leitores de diferentes tipos de especificações............................... 05<br />
Figura 02: Tipos de Requisitos Não-Funcionais............................................... 07<br />
Figura 03: Processo de engenharia de requisito.............................................. 09<br />
Figura 04: Processo de desenvolvimento de protótipo.................................... 17<br />
Figura 05: Um processo de software com prototipação descartável.............. 19<br />
Figura 06: Prototipação evolucionária............................................................... 20<br />
Figura 07: Caso de uso do projeto de criação da ferramenta.......................... 27<br />
Figura 08: Estrutura de dependência de plug-in e bibliotecas........................ 32<br />
Figura 09: Diagrama de classes.......................................................................... 33<br />
Figura 10: Adicionando a biblioteca (BusinessRuleAnnotations.jar) ao<br />
projeto...................................................................................................................<br />
Figura 11: Tela de importação da regra de negócio......................................... 39<br />
Figura 12: Tela que lista as regras de negócio associados ao projeto........... 39<br />
Figura 13: Anotação da classe para poder anotar as regras de negócio nos<br />
componentes........................................................................................................<br />
Figura 14: Anotação da regra de negócios no componente jButton.............. 41<br />
Figura 15: Recuperação da regra de negócio.................................................... 42<br />
38<br />
40
LISTA DE TABELAS<br />
Tabela 01: Classificação das Regras de Negócio............................................. 12<br />
Tabela 02: Modelo de sentenças utilizado pelo sistema RÉGULA.................. 14<br />
Tabela 03: Requisitos não funcionais................................................................ 26<br />
Tabela 04: Requisitos funcionais........................................................................ 26<br />
Tabela 05: Casos de uso relacionado aos requisitos....................................... 28<br />
Tabela 06: Casos de uso UC001......................................................................... 28<br />
Tabela 07: Casos de uso UC002......................................................................... 29<br />
Tabela 08: Casos de uso UC003......................................................................... 30<br />
Tabela 09: Casos de uso UC004......................................................................... 30<br />
Tabela 10: Casos de uso UC005......................................................................... 31<br />
Tabela 11: Casos de uso UC006......................................................................... 31<br />
Tabela 12: Descrição das tags do arquivo de importação............................... 37
INTRODUÇÃO<br />
A engenharia de requisitos tem fundamental importância no processo de<br />
desenvolvimento de um software, pois normalmente a engenharia de requisitos é<br />
constituída das atividades de obtenção, especificação e validação dos requisitos,<br />
que quando bem executadas, proporcionam um software que atende as reais<br />
necessidades propostas ao sistema, evitando com isso a insatisfação do cliente.<br />
Nesse processo estão inclusas também as regras de negócios, que no decorrer da<br />
construção do software, vão sendo expostas como necessidades pelo cliente,<br />
tornando-se posteriormente os requisitos do software.<br />
Uma das técnicas utilizadas pela engenharia de software para o levantamento,<br />
verificação e, validação dos requisitos é conhecida como prototipação de software.<br />
Essas técnicas, prototipação, trazem ainda como benefícios o amadurecimento dos<br />
requisitos e familiarização do novo sistema em desenvolvimento com os usuários.<br />
(SOMMERVILLE, 2004)<br />
Normalmente os protótipos são uma versão simplificada dos sistemas a serem<br />
desenvolvidos. Freqüentemente os protótipos são a representação da interface<br />
gráfica com o objetivo de representar as regras de negócio. Nessa representação<br />
normalmente existe uma dificuldade dos stakeholders 1 visualizar as regras de<br />
negócio, cálculos e procedimentos completos por causa das dificuldades da<br />
representação.<br />
Com essa dificuldade de representação da visualização geralmente se recorre para<br />
uma leitura da documentação, tornando-se assim um trabalho árduo e impreciso.<br />
Neste projeto é proposto a ferramenta ABREP, que permite através da técnica de<br />
Annotations, efetuar anotações das regras de negócio no código fonte de uma<br />
aplicação JAVA(Swing), no desenvolvimento de protótipos evolutivos. Outra<br />
1 “Os Stakeholders são as pessoas ou organizações que são de alguma forma, afetadas pelo sistema<br />
e/ou que tem diretamente ou indiretamente influência nos requisitos do sistema” (SOMMERVILLE,<br />
2004).<br />
1
funcionalidade dessa ferramenta é a de proporcionar aos stakeholders a<br />
recuperação dessas regras anotadas durante a execução dos protótipos de forma<br />
mais intuitiva.<br />
Este trabalho esta desmembrado em 5 capítulos, começando pelo primeiro capítulo,<br />
que apresenta os conceitos dos requisitos de um software. O capitulo 2 que mostra<br />
os conceitos da engenharia de requisitos e suas atividades, o capitulo 3 que<br />
apresenta os conceito das regras de negócio, o capitulo 4 apresenta os conceitos,<br />
os tipos dos protótipos e o processo de prototipação, os modelos de<br />
desenvolvimento de software e alguns conceitos do desenvolvimento rápido de<br />
software, o capitulo 5 que mostra toda a documentação e especificação, e um<br />
exemplo de uso com avaliação dos pontos positivos e negativos da ferramenta<br />
ABREP e por fim a conclusão do trabalho.<br />
2
1 - REQUISITOS.<br />
Durante a construção de um software, nem sempre é uma tarefa simples entender a<br />
natureza dos problemas especificados pelos clientes e obter uma solução para<br />
esses problemas. Por isso, analisar e compreender esses problemas são os<br />
primeiros passos para construção de um software. Os problemas acima<br />
mencionados são as descrições das funções e das restrições para o sistema a ser<br />
criado (SOMMERVILLE, 2007).<br />
Existem diversos conceitos para os requisitos e todos oferecem uma perspectiva<br />
diferente para o mesmo assunto. Peters (2001) apresenta um conceito mais<br />
completo, especialmente por tratar mais detalhadamente as características de um<br />
requisito.<br />
Um requisito de software é uma descrição dos principais recursos de<br />
um produto de software, seu fluxo de informações, comportamento e<br />
atributos. Em suma, um requisito fornece uma estrutura básica para o<br />
desenvolvimento de um produto de software. O grau de<br />
compreensibilidade, precisão e rigor da descrição fornecida por um<br />
documento de requisitos de software tende ser diretamente<br />
proporcional ao grau de qualidade do produto resultante. (PETERS,<br />
2001)<br />
Percebe-se, então, que os requisitos podem ser definidos como um conjunto de<br />
necessidades especificadas pelo cliente com o intuito de solucionar um problema do<br />
negócio de interece do cliente. Essas especificações se não forem bem<br />
compreendidas pelos desenvolvedores acarretam no desenvolvimento de um<br />
software com qualidade discutível. Para se obter um produto de qualidade, Filho<br />
(2003) nos diz que, a especificação dos requisitos deve satisfazer a uma série de<br />
características:<br />
• Correção – Verificar se todo requisito presente na especificação de requisitos<br />
é realmente um requisito do produto a ser construído. Essa verificação e feita<br />
checando a coerência da especificação dos requisitos com outros<br />
3
documentos da aplicação.<br />
• Precisão – Garantir que todo requisito presente na especificação tenha<br />
somente uma interpretação pelos envolvidos na criação do software.<br />
• Completeza – Refletir todas as decisões da especificação que forram<br />
tomadas como: requisitos significativos relativos à funcionalidade,<br />
desempenho, restrições, atributos e interfaces. Definir as respostas do<br />
software para as entradas possíveis, válidas e inválidas. Conter um glossário<br />
de todos os termos técnicos, unidades de medida e referências a todos os<br />
diagramas e figuras.<br />
• Consistência – Não deve haver nenhum conflito entre os subconjuntos de<br />
requisitos.<br />
• Priorização – Classificar os requisitos de acordo com a sua importância e<br />
estabilidade, pois é grande a probabilidade de que o requisito venha a ser<br />
alterado no desenvolver do projeto.<br />
• Verificabilidade – Garantir que todo requisito possa ser verificado através de<br />
um processo finito de baixo custo e que possa ser executado por uma<br />
máquina ou pessoa.<br />
• Modificabilidade – Permitir que o requisito possa ser modificado de forma<br />
fácil, clara e consistente.<br />
• Rastreabilidade – Garantir a fácil determinação dos antecedentes e<br />
conseqüências do requisito.<br />
1.1 – CLASSIFICAÇÃO DOS REQUISITOS.<br />
A descrição dos requisitos pode ser de alto nível, como uma linguagem natural, ou<br />
específica, como a descrição de uma função matematicamente formal. Para fazer<br />
essas distinções e facilitar a compreensão dos envolvidos no levantamento de<br />
requisitos, Sommerville (2007) utilizou a seguinte classificação:<br />
4
• Requisitos de usuário para tratar dos requisitos abstratos, aqueles definidos<br />
pelo usuário através do uso da linguagem natural, com baixo grau de<br />
detalhamento.<br />
• Requisitos de sistema para descrever as funções e o que realmente o<br />
sistema deve fazer, podendo até mesmo ser utilizado como contrato entre o<br />
comprador e desenvolvedor de sistema, com alto grau de detalhamento.<br />
• Especificação do projeto de software que pode ser utilizado para integrar<br />
os requisitos de sistema e as especificações do projeto.<br />
Existem diversas formas de classificar os requisitos. Pode-se, por exemplo, separá-<br />
los por níveis de detalhamento, com o objetivo de buscar o entendimento dos<br />
mesmos para diferentes leitores. A Figura 01 indica um quadro dos leitores e seus<br />
diferentes tipos de especificações.<br />
Figura 01 - Leitores de diferentes tipos de especificações (SOMMERVILLE, 2004)<br />
1.2 – TIPOS DE REQUISITOS.<br />
Os requisitos de sistema, geralmente, são divididos em três tipos: funcionais, não<br />
funcionais e de domínio.<br />
5
1.2.1 - Requisitos Funcionais<br />
Entende-se por requisitos funcionais, “as declarações de serviços que o sistema<br />
deve fornecer, como o sistema deve reagir a entradas especificas e como deve se<br />
comportar em determinadas situações” (SOMMERVILLE, 2007). Os requisitos<br />
funcionais dependem diretamente do tipo de software que está sendo desenvolvido<br />
e dos stakeholders que os avaliarão. Normalmente os requisitos funcionais de<br />
usuário são escritos de forma geral, enquanto que os requisitos funcionais de<br />
sistema detalham, de forma precisa, as entradas, saídas, exceções do sistema,<br />
entre outros. A descrição dos requisitos funcionais do sistema deve conter todas as<br />
funções solicitadas pelo usuário de forma bem definida, não é permitido<br />
contradições entres os requisitos. (SOMMERVILLE, 2007)<br />
1.2.2 - Requisitos Não-Funcionais.<br />
Os requisitos não-funcionais “são restrições sobre os serviços ou as funções<br />
oferecidas pelo sistema. Eles incluem restrições de timing 2 , restrições sobre o<br />
processo de desenvolvimento e padrões” (SOMMERVILLE, 2007). Geralmente, os<br />
requisitos não-funcionais atingem a totalidade das funcionalidades do sistema. Com<br />
isso, quando não atendidos, podem tornar o sistema inútil, diferente dos requisitos<br />
funcionais que, quando não atendidos, podem degradar somente uma parte do<br />
sistema. Existem diversas categorias de requisitos não-funcionais, a Figura 02<br />
mostra as suas classificações:<br />
2 Cronometragem, afinação.<br />
6
Figura 02 – Tipos de Requisitos Não-Funcionais (SOMMERVILLER, 2007).<br />
1.2.3 - Requisitos de Domínio.<br />
Requisitos de domínio “são requisitos provenientes do domínio da aplicação do<br />
sistema e que refletem as características e as restrições desse domínio”<br />
(SOMMERVILLE, 2007). Com base nessa definição, esses requisitos são obtidos do<br />
domínio da aplicação, diferentemente dos requisitos vistos anteriormente que são<br />
obtidos através das necessidades especificas dos usuários. Esses requisitos podem<br />
ser extremamente importantes para o perfeito funcionamento do sistema, já que os<br />
mesmos refletem os fundamentos do universo da aplicação. Os requisitos de<br />
domínio podem ser funcionais ou não funcionais.<br />
7
2 – ENGENHARIA DE REQUISITOS.<br />
No âmbito dos projetos de desenvolvimento de software, compreender as reais<br />
necessidades do cliente é uma tarefa muito complexa. Por isso, exige-se um esforço<br />
contínuo para analisar e consolidar os problemas para conciliá-los entre o cliente e o<br />
projetista. O conjunto desses processos é conhecido como engenharia de requisitos,<br />
que foi explicada por Pressman (2006) da seguinte forma:<br />
A engenharia de requisitos ajuda os engenheiros de software a<br />
compreender melhor o problema que eles vão trabalhar para resolver.<br />
Ela inclui o conjunto de tarefas que levam a um entendimento de qual<br />
será o impacto do software sobre o negócio, do que o cliente quer e de<br />
como os usuários finais vão interagir com o software. (PRESSMAN,<br />
2006)<br />
Analisar e compreender os problemas propostos pelo cliente é muito importante para<br />
evitar desenvolver as soluções de problemas maus compreendidos, o que<br />
acarretaria em um sistema que não supriria as necessidades do cliente.<br />
Os processos que compõem a engenharia de requisitos são formados por quatro<br />
atividades genéricas consideradas de alto nível, segundo Sommerville (2004). Essas<br />
quatro atividades são: o estudo da viabilidade do sistema; a obtenção e a análise de<br />
requisito; a especificação de requisitos e sua documentação; e a validação desses<br />
requisitos.<br />
A Figura 03 mostra o fluxo das interações entre essas atividades e seus resultados.<br />
Durante o projeto de construção do software, os requisitos naturalmente sofrem<br />
modificações, e essas modificações, normalmente, partem das pessoas envolvidas<br />
no processo, principalmente considerando que as opiniões sobre o que desejam que<br />
o software faça podem ser modificadas com o passar do tempo. Outros motivos que<br />
levam às alterações dos requisitos são: a evolução da organização contratante, o<br />
mercado tecnológico e as modificações de hardware.<br />
8
Figura 03 – Processo de engenharia de requisito (Adaptado de SOMMERVILE, 2004)<br />
Essas mudanças dos requisitos são controladas pela atividade de gerenciamento de<br />
requisitos. Atividade que tem extrema importância para negociar as modificações<br />
necessárias com intuito de satisfazer a todos participantes do projeto da construção<br />
do software.<br />
9
3 – REGRAS DE NEGÓCIO.<br />
Segundo o BRG (2000),<br />
10<br />
regras de negócio são expressões que definem ou restringem alguns<br />
aspectos do negócio, com a intenção de declarar a estrutura do<br />
negócio, controlar ou influenciar o comportamento do mesmo. As<br />
regras de negócio as quais o projeto se preocupa, são atômicas, isto é,<br />
não podem ser decompostas. (BRG, 2000)<br />
Entende-se com isso que as regras de negócio são um conjunto de condições que<br />
regem uma empresa para que um evento ocorra de forma aceitável para o negócio.<br />
As regras de negócio têm duas importantes funções que são: “reduzir o tempo de<br />
desenvolvimento de software e fornecer um sistema que seja projetado para ser<br />
mutável” (VON HALLE, 2002). Para elaboração de uma regra de negócio é<br />
necessário a utilização de uma metodologia diferente das demais metodologias de<br />
desenvolvimento de sistemas, pois, segundo o BRG (2000), “as regras de negócio<br />
são superficiais, não se desligam dos artefatos de outros sistemas, não se<br />
aperfeiçoam e não se mantêm ao longo do tempo”. Essa metodologia “coloca mais<br />
ênfase na importância, disciplina e formalização das regras de negócio e<br />
conseqüentemente, a entrega dessas regras dentro da lógica do sistema<br />
correspondente mutável” (VON HALLE, 2002).<br />
Sob a perspectiva dos sistemas de informação as regra de negócio são definidas<br />
como declarações que definem ou restringem aspectos do negócio (BRG, 2000). A<br />
partir desse principio, percebe-se que através das operações de negócio as regras<br />
de negócios são definidas como restrições ou metadados (informações sobre os<br />
dados). As regras de negócio também são conhecidas como regras do domínio da<br />
aplicação, ou regras de minimundo (problema específico de uma organização)<br />
(ZSIFKOV, 2004).
Segundo as definições acima fica fácil identificar que o funcionamento correto do<br />
negócio depende direta e essencialmente das regras de negócios, pois nelas estão<br />
definidos os aspectos do negócio.<br />
Conforme o que foi abordado entende-se que as regras de negócio são de<br />
fundamental importância para as organizações, pois, elas refletem o domínio da<br />
organização. A não utilização das regras de negócio no processo de<br />
desenvolvimento de software pode acarretar na elaboração de um sistema que não<br />
seja suscetível a acomodar mudanças o que não convêm a uma organização, pois<br />
suas regras podem mudar com a necessidade e o passar do tempo, sendo então<br />
necessário o desenvolvimento de um novo sistema para atender a essas mudanças.<br />
Segundo Von Halle (2002), algumas características das regras de negócio podem<br />
ser definidas como:<br />
• Regras de Negócio são expressões declarativas: são declarações<br />
objetivas, com o intuito de comunicar a essência da regra de maneira mais<br />
clara possível.<br />
• Regras de Negócio não são processos: as regras descrevem o que deve<br />
ser feito e não como deve ser feito.<br />
• Regras de Negócio não dependem de tecnologia: elas devem ser definidas<br />
sem o comprometimento com tecnologias.<br />
• Regras de Negócio são atômicas: as regras não podem ser decompostas<br />
em mais de uma regra.<br />
3.1 – CLASSIFICAÇÃO DAS REGRAS DE NEGÓCIO.<br />
Como abordado nas definições anteriores, as regras de negócio estão contidas no<br />
domínio da aplicação, fazendo com que não exista uma única classificação formal. A<br />
Tabela 01 mostra diversos esquemas de classificação propostos por vários autores<br />
e organizações:<br />
11
Tabela 01 – Classificação das Regras de Negócio (VON HALLE, 2002)<br />
Tabela de Classificação das Regras de Negócio<br />
Fonte Sistema de Classificação de Regras de Negócio<br />
Business Rules Group<br />
(2000)<br />
Ross(2001) • Fatos<br />
• Termos<br />
• Regras<br />
• Restrições<br />
• Derivações<br />
• Inferências<br />
• Cronometragem<br />
• Seqüencia<br />
General Data Analysis<br />
Tipos de Regras<br />
Derivação: uma derivação de conhecimento que é derivado<br />
de outros conhecimentos no negócio.<br />
• Cálculo Matemático<br />
• Inferência<br />
Afirmação de caráter estrutural: um conceito definido da<br />
declaração de um fato que expressa algum aspecto da<br />
estrutura da empresa. Isso envolve tanto os termos e os<br />
fatos montados a partir destes termos.<br />
• Termos<br />
• Fatos<br />
Afirmação de ação: uma declaração de uma restrição ou<br />
condição que limita ou controla as ações da empresa.<br />
• Autorização<br />
• Condição<br />
• Restrições de integridade<br />
• Heurística<br />
Atributos das Regras<br />
• Singularidade<br />
• Opcionalidade<br />
• Verificador de Valor<br />
Computações<br />
Inferências<br />
Restrições de entidade multi-atributos<br />
Regras de Relacionamento<br />
• Cardinalidade<br />
• Opcionalidade<br />
• Integridade Referencial<br />
• Contagens de Cardinalidade<br />
C. J. Date (2000) • Restrições<br />
• Restrição Estado<br />
• Restrição de Transição<br />
• Resposta a Estímulos<br />
• Derivações<br />
• Computação<br />
• Inferência<br />
C. J. Date (2000) Cris Date Further propõe ainda outro esquema de restrições<br />
que é baseado na estrutura dos dados em si.<br />
• Restrições de Domínio<br />
• Restrições de Coluna<br />
• Restrições de Tabela (restrições dentro de uma tabela)<br />
• Restrições do Banco de Dados (restrições entre duas ou<br />
12
mais tabelas)<br />
Versate Inc. • Regras de Integridade Referencial<br />
• Derivações (Atributos computacionais)<br />
• Validação (atributo obrigatório/valores opcionais. Min,<br />
max)<br />
• Restrição (atributo para atributo. Restrições dentro da<br />
entidade)<br />
• Evento/Ação<br />
• Regras de Apresentação<br />
USoft Inc. (Mallens(1997)) • Regras de restrição: restrições comerciais sobre a<br />
informação a ser armazenada, o que não é permitido.<br />
• Regras de Comportamento: como o sistema se<br />
comportar em determinadas situações, o que o sistema<br />
deve fazer automaticamente.<br />
• Regras Dedutivas: como as informações devem ser<br />
calculadas ou derivadas.<br />
• Regras de Apresentação: como o sistema se apresenta<br />
para o usuário, como o trabalho e tarefa devem ser<br />
organizados.<br />
• Regras de instrução: como o usuário irá operar o<br />
sistema em determinadas situações.<br />
Esse sistema de classificação depende dos serviços fornecidos pelos diversos<br />
autores e organizações, conforme visto na tabela acima, para atingir o público-alvo.<br />
Essa forma sistemática de classificação serve para identificar e analisar os negócios<br />
das empresas.<br />
Esses sistemas de classificação podem ser utilizados por diversos públicos alvos<br />
como: desenvolvedores, administradores de banco de dados, analistas /<br />
modeladores de dados, dentre outros.<br />
Para Morgado (2007) as regras de negócio também podem ser agrupadas através<br />
de algumas características comuns como:<br />
• Termos – são os elementos básicos da linguagem utilizada para expressar as<br />
Regras de Negócio, onde a própria definição de um termo é considerada<br />
como uma regra.<br />
• Fatos – descrevem a natureza ou estrutura operacional de um negócio,<br />
relacionando os termos uns aos outros.<br />
13
• Cálculos e Derivações – determinam como um conhecimento ou informação<br />
pode ser transformado em outro, através de fórmulas ou mudanças de<br />
estado.<br />
• Restrições – restringem algum comportamento do negócio, estando<br />
relacionadas às decisões sobre quais dados podem ou não ser atualizados.<br />
• Habilitações de Ação – regras dedutivas, de raciocínio encadeado à frente,<br />
representadas através de um par contendo uma condição e respectiva ação.<br />
A Tabela 02 exemplifica a utilização das características definidas por Morgado<br />
(2007) em um sistema.<br />
Tabela 02 – Modelo de sentenças utilizado pelo sistema RÉGULA (MORGADO, 2007).<br />
Conclui-se então que não existe uma forma única para se classificar as regras de<br />
negócio, pois como já foi abordado antes, cada autor/organização pode elaborar seu<br />
próprio conjunto de regras de negócio de acordo com o domínio de sua aplicação.<br />
14
4 - PROTÓTIPO.<br />
A palavra protótipo vem do grego protos (primeiro) + typos (impressão), ou seja,<br />
‘primeira impressão’. O Dicionário Priberam da Língua Portuguesa nos da os<br />
seguintes significados para a palavra protótipo: primeiro tipo, modelo, exemplar e<br />
padrão. Entende-se com isso que um protótipo é um modelo inicial para servir de<br />
teste antes da construção do produto final.<br />
4.1 – PROTOTIPAÇÃO DE SOFTWARE.<br />
“Um protótipo é uma versão inicial de um sistema de software usado para<br />
demonstrar conceitos, experimentar opções de projetos e, geralmente, conhecer<br />
mais sobre o problema e suas possíveis soluções”. (SOMMERVILLE, 2007)<br />
15<br />
[...] os protótipos são as representações reais do software, que<br />
permitem a equipe do software ter uma experiência do projeto sem<br />
precisar programar o software. Um protótipo é toda a tentativa de<br />
realizar qualquer aspecto do conteúdo do software. Por exemplo, o<br />
protótipo pode ser uma realização da interação e da navegação de um<br />
ponto em um produto a outro. Um protótipo pode igualmente ser um<br />
esquema hierárquico de um projeto da informação, separado do olhar<br />
e da sensação do software final. (ARNOWITZ, 2006)<br />
Os conceitos acima mostram que as principais funções da prototipação é facilitar o<br />
entendimento dos requisitos de sistemas para usuários e os stakeholders, e<br />
contribuir para que haja redução de riscos, já que com a prototipação pode-se<br />
identificar os erros e/ou omissões de requisitos que prejudicariam o funcionamento<br />
correto do software. Para Pressman (2006), o paradigma da prototipação auxilia o<br />
engenheiro de software e o comprador a entenderem melhor o que deve ser<br />
construído quando os requisitos de sistema estão confusos.<br />
Sommerville (2004) define os benefícios da prototipação como:
• A prototipação permite demonstrar aos stakeholders o significado dos<br />
requisitos;<br />
• A Prototipação permite verificar se existem equívocos na interpretação dos<br />
requisitos entre os programadores e os stakeholders;<br />
• Redução dos riscos numa fase avançada do desenvolvimento já que erros ou<br />
omissões dos requisitos são identificados na prototipação.<br />
• Serviços esquecidos podem ser detectados e serviços confusos podem ser<br />
identificados.<br />
• Um sistema funcionando está disponível nos primeiros estágios no processo<br />
de desenvolvimento. (somente na prototipação evolutiva)<br />
• O protótipo pode servir como uma base para derivar uma especificação do<br />
sistema com qualidade de produção.<br />
• O protótipo pode ser usado para treinamento do usuário e teste de sistema.<br />
Não são relatados problemas de prototipação e sim conseqüências negativas que as<br />
técnicas de prototipagem podem gerar se mal administradas como:<br />
• A demora na entrega do protótipo acarreta no atraso do desenvolvimento do<br />
sistema o que acaba gerando um aumento do custo do sistema final<br />
• A reutilização de um código de protótipo ineficiente acaba por diversas vezes<br />
degradando o desempenho geral do sistema.<br />
4.2 – FASES DO PROCESSO DE DESENVOLVIMENTO DE UM PROTÓTIPO.<br />
A Figura 04 mostra as fases do processo de desenvolvimento de um protótipo.<br />
16
Figura 04 – Processo de desenvolvimento de protótipo (SOMMERVILLE, 2004).<br />
A primeira tarefa é a de estabelecer de forma explicita os objetivos do protótipo para<br />
que não ocorra um mau entendimento por parte dos gerentes ou dos usuários finais<br />
do sistema, o que acarretaria na perda dos benefícios da construção do protótipo. A<br />
tarefa seguinte é a definição das funcionalidades do protótipo, é nessa fase que se<br />
estabelece as funções que devem ser incluídas ou excluídas dos protótipos para<br />
alcançar os objetivos propostos, com menor prazo e menor custo. Após a fase de<br />
desenvolvimento, os protótipos são apresentados aos usuários que os utilizarão<br />
para que os mesmo possam se adaptar ao novo padrão de uso. Com essa<br />
adaptação os usuários descobrirão os erros e omissões dos requisitos.<br />
(SOMMERVILLE, 2004)<br />
4.3 – PROTOTIPAÇÃO DESCARTÁVEL.<br />
Segundo Filho (2003),<br />
17<br />
protótipo descartável (throw-away) é aquele tipicamente construído<br />
durante a engenharia de requisitos cuja única finalidade é demonstrar<br />
para os usuários o que o analista captou dos requisitos do sistema ou<br />
parte deles. O fundamental na construção de um protótipo descartável<br />
é a rapidez de construção, devendo esse ser produzido em poucas<br />
horas ou no máximo em poucos dias. (FILHO, 2003)<br />
A decisão de utilizar esse tipo de prototipação é que o custo de construí-los e depois<br />
descartá-los é compensado pela redução dos riscos.
A redução dos riscos se dá através de um amplo processo de analise de requisitos<br />
no qual fornece informações sobre os requisitos para os gerentes avaliarem os<br />
riscos dos processos. Após essa avaliação, os protótipos são descartados e não são<br />
mais utilizados para posterior desenvolvimento. O descarte do protótipo só ocorre<br />
após a criação do documento de requisitos e satisfação parcial ou total do cliente.<br />
Para se obter esse documento e a satisfação do cliente, algumas etapas são<br />
necessárias, como a: elaboração de um documento de requisitos provisório,<br />
obtenção de opiniões do usuário e se necessário uma reformulação do documento<br />
de requisitos. Essas etapas são repetidas por diversas vezes, já que o objetivo é a<br />
criação de um documento de requisitos final, item fundamental para sistemas de<br />
grande porte, pois, facilitam e diminuem futuramente o custo com manutenções e<br />
novas implementações que venham a ocorrer, além de aumentar a satisfação do<br />
cliente. A partir daí o sistema poderá ser desenvolvido em processo cascata,<br />
incremental, ou outro.<br />
Filho (2003) destaca os seguintes benefícios, com o uso da prototipação<br />
descartável:<br />
• Redução dos riscos na construção;<br />
• Aumento da manutenibilidade - uma característica da engenharia de software<br />
atribuída a facilidade de um software ser modificado para a correção de<br />
defeitos, alteração/ inclusão de novos requisitos, adequação a um novo<br />
ambiente dentre outras atividades de manutenção de software;<br />
• Aumento da estabilidade dos requisitos;<br />
• Oportunidade para treinamento dos programadores menos experientes,<br />
trabalhando como codificadores.<br />
As desvantagens da utilização da prototipação descartável é um aumento no custo<br />
de implementação, já que o protótipo construído será descartado. Mas como já foi<br />
abordando, esse aumento no custo da implementação nos traz o beneficio da<br />
redução dos riscos na construção do sistema final. A Figura 05 mostra um processo<br />
de desenvolvimento de software através da prototipação descartável.<br />
18
Figura 05 – Um processo de software com prototipação descartável (SOMMERVILLE, 2006).<br />
Nesse processo de desenvolvimento, um protótipo é desenvolvido a partir de um<br />
modelo inicial definido a partir da especificação do sistema, sendo disponibilizado ao<br />
cliente para experimentação. Esse protótipo pode sofrer mudanças até que o cliente<br />
esteja satisfeito com suas funcionalidades. Com a aprovação do cliente uma nova<br />
especificação do sistema é elabora a partir do protótipo aprovado e o sistema pode<br />
ser reimplementado em uma versão final de produção. (SOMMERVILLE, 2004).<br />
4.4 – PROTOTIPAÇÃO EVOLUCIONÁRIA OU EVOLUTIVA.<br />
Estudos mostraram que um software, como todos os sistemas complexos, evoluem<br />
com o passar do tempo. “Os requisitos do negócio e do produto mudam<br />
freqüentemente à medida que o desenvolvimento prossegue, dificultando um<br />
caminho direto para o produto final”. (PRESSMAN, 2006)<br />
A prototipação evolutiva parte do principio, como o próprio nome já diz, de evolução.<br />
Desta forma, cria-se um protótipo inicial contendo os requisitos que são mais bem<br />
compreendidos e de maior prioridade para o sistema a ser desenvolvido. Esse<br />
protótipo inicial passa por diversas fases de melhorias e incrementos até se tornar o<br />
sistema final.<br />
19
Segundo Filho (2003), alguns benefícios da prototipação evolutiva são:<br />
• Rápida entrega do sistema;<br />
• O sistema é desenvolvido de forma incremental;<br />
• Utilização de técnicas de rápido desenvolvimento de software;<br />
• Possui funcionalidades semelhantes ao do sistema final;<br />
• Alto grau de interatividade com o usuário;<br />
• Exploração e teste diversos com elevado grau de realismo.<br />
Filho (2003) também define alguns pontos negativos como:<br />
• Elevado custo e tempo de desenvolvimento na fase inicial do processo de<br />
prototipação;<br />
• Ineficiente para testes de opções de design de implementação;<br />
• Requisitos não funcionais não são testados de forma adequada;<br />
Esse alto custo inicial com o desenvolvimento é compensado futuramente com a<br />
evolução do protótipo para o sistema final. A Figura 06 nos mostra um processo de<br />
prototipação evolutiva.<br />
Figura 06 – Prototipação evolucionária (SOMMERVILLER, 2004).<br />
Na prototipação evolutiva o “desenvolvimento rápido e iterativo do protótipo é<br />
essencial, de modo que os custos são controlados e os stakeholders do sistema<br />
podem experimentar o protótipo mais cedo no processo de software”<br />
(SOMMERVILLE, 2007). Para se obter esse rápido desenvolvimento e iteratividade<br />
20
no desenvolvimento de um protótipo, a engenharia de software dispõe de modelos<br />
de desenvolvimento incremental e ferramentas de desenvolvimento rápido para<br />
auxiliarem essa tarefa.<br />
4.5 – PROTÓTIPO EM PAPEL.<br />
“É desenvolvido um conjunto de interfaces associadas a cenários de utilização que<br />
são apresentados aos usuários. Esse tipo de prototipagem é barata e eficiente”<br />
(Kotonya, 1998). O desenvolvimento de um software executável não é necessário no<br />
protótipo em papel. Esse tipo de protótipo é muito eficiente para sistemas interativos,<br />
pois permite que os analistas e usuários percorram esses cenários.<br />
4.6 – PROTÓTIPO “WIZARD OF OZ”.<br />
“Uma pessoa simula as respostas do sistema em resposta as ações dos usuários.<br />
Esse tipo de prototipagem é relativamente barata visto que apenas a interface do<br />
sistema tem quer ser desenvolvida” (Kotonya, 1998). Quando se tem uma interface<br />
existente esse é o tipo de protótipo mais adequado a ser desenvolvido, pois os<br />
usuários interagem com o que parece ser o sistema. Essas interações são<br />
analisadas por uma pessoa que simula as respostas do sistema.<br />
4.7 – PROTÓTIPO AUTOMÁTICO.<br />
“É utilizado em linguagens de 4ª geração ou outras linguagens que permitem um<br />
rápido desenvolvimento de protótipos executáveis. Esse tipo de prototipagem é a<br />
mais cara” (Kotonya, 1998). Esse tipo de protótipo envolve o desenvolvimento de<br />
software, recorrendo a linguagens de programação de alto nível, que simulem as<br />
funcionalidades do sistema final a ser construído.<br />
21
4.8 – MODELOS DE DESENVOLVIMENTO.<br />
Conforme abordado, os sistemas evoluem com o passar do tempo e com essas<br />
mudanças os requisitos do sistema também mudam. Com isso nota-se que no<br />
processo de desenvolvimento de software, as atividades do processo são repetidas<br />
regularmente a medida que o sistema é refeito para atender a essas mudanças.<br />
Para facilitar esse processo de mudança existem alguns modelos de processos que<br />
auxiliam essa atividade. Dois modelos de processo são os: modelo incremental onde<br />
“a especificação, o projeto e a implementação do software são divididos em uma<br />
série de incrementos desenvolvidos um de cada vez” (SOMMERVILLE, 2007) e o<br />
modelo espiral onde “o desenvolvimento do sistema evolui em espiral para fora a<br />
partir de um esboço inicial até o sistema final” (SOMMERVILLE, 2007).<br />
4.9 – DESENVOLVIMENTO RÁPIDO DE SOFTWARE.<br />
Existem atualmente no mercado diversas ferramentas e metodologias para o<br />
desenvolvimento rápido de software que auxiliam no processo de elaboração dos<br />
protótipos evolutivos. Essas metodologias utilizam os conceitos dos Métodos Ágeis<br />
(em inglês Agile Modeling, ou AG) “que visam a redução do ciclo de vida do software<br />
(e, por conseguinte acelerar o seu desenvolvimento) desenvolvendo uma versão<br />
mínima, seguidamente integrando as funcionalidades por um processo iterativo<br />
baseado na escuta do cliente e testes ao longo de todo o ciclo de desenvolvimento”<br />
(KIOSKES, 2009).<br />
A metodologia XP (Extreme Programming) e as técnicas de RAD (Rapid Aplication<br />
Development) são exemplos de metodologias de rápido desenvolvimento de<br />
software. A programação XP é uma metodologia ágil criada no final da década de<br />
90, voltada a equipes pequenas e médias que produzem software baseados em<br />
requisitos vagos e que mudam com rapidez e as técnicas de RAD são um modelo de<br />
processo de desenvolvimento de software iterativo e incremental que enfatiza um<br />
22
ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias). (PRESSMAN,<br />
2006)<br />
23
5 - PROJETO.<br />
Os requisitos e sua engenharia compõem um conjunto de atividades muito<br />
importantes para aquisição dos objetos fundamentais de um software, tais como<br />
obtenção, especificação e validação dos requisitos. Freqüentemente, estão contidas<br />
no software as regras de negócios que, normalmente, são manifestadas como<br />
necessidades pelos clientes, o que, ao longo das atividades da engenharia de<br />
requisitos, vão compondo os requisitos do software.<br />
Durante a construção de um software, dentro da atividade de levantamento de<br />
requisitos é muito comum a utilização dos protótipos para que os stakeholders<br />
tenham noção do significado dos requisitos. No momento da avaliação dos<br />
protótipos se faz necessária a recuperação dos requisitos para que os stakeholders<br />
visualizem as necessidades solicitadas e vejam como foi proposta a solução para as<br />
mesmas.<br />
No processo de avaliação dos protótipos pelos stakeholders, nota-se geralmente<br />
uma dificuldade na compreensão da proposta apresentada pelos desenvolvedores<br />
do protótipo em relação às necessidades expostas pelo cliente. Normalmente existe<br />
a dificuldade de se recuperar as informações, principalmente as regras de negócios<br />
contidas nas necessidades do cliente, o que pode acarretar na dificuldade do<br />
amadurecimento dos requisitos e até mesmo impossibilitar a extração de novos<br />
requisitos por conta da falta de informações. Então, como tornar a recuperação das<br />
informações das regras de negócios mais eficiente e eficaz para ajudar na avaliação<br />
dos protótipos?<br />
Utiliza-se como exemplo a construção de um sistema para uma escola, onde se faz<br />
necessário a associação dos alunos para as suas respectivas turmas. Foram<br />
levantadas as seguintes regras de negócio: o aluno não pode ser associado a mais<br />
de uma turma e uma turma não pode ultrapassar o limite máximo estabelecido. O<br />
desenvolvedor cria então o protótipo do sistema. Os stakeholders precisam fazer a<br />
análise deste protótipo para aprovar ou não a criação do sistema nos moldes<br />
24
propostos pelo desenvolvedor. Como, então, tornar este momento mais proveitoso<br />
tanto para o desenvolvedor quanto para o cliente?<br />
Pensando nisto, foi desenvolvida, neste projeto, uma ferramenta que possibilita,<br />
durante a criação dos protótipos evolutivos, anotações das regras de negócio nos<br />
componentes das interfaces desenvolvidas em Swing na linguagem de programação<br />
JAVA. O que, posteriormente, permite também a recuperação das regras nas telas<br />
propostas, de forma intuitiva, ajudando no processo de amadurecimento e<br />
esclarecimento dos requisitos, levantamento de novos requisitos e, até mesmo, a<br />
familiarização dos usuários finais com o novo sistema que será construído. Dessa<br />
forma, durante o processo de criação do protótipo do sistema da escola do exemplo<br />
acima citado, o desenvolvedor poderá anotar, nos elementos do protótipo, as regras<br />
levantadas, como: um aluno só deve estar vinculado a uma turma, que há um limite<br />
máximo de alunos em cada turma, e os stakeholders poderão recuperá-las em<br />
momentos como apresentação, validação e simulação dos protótipos do sistema,<br />
analisando com maior clareza se o sistema se adequará ou não às suas<br />
necessidades.<br />
A construção dessa ferramenta tomou como base o estudo sobre a criação dos plug-<br />
ins para a ferramenta Eclipse. Notou-se que seria necessária uma estrutura em<br />
XML, onde essa estrutura indicaria a integração das funcionalidades criadas pela<br />
ferramenta proposta neste projeto com a ferramenta Eclipse. Após a compreensão<br />
dessa estrutura foi necessário o estudo sobre os padrões de desenvolvimento, para<br />
facilitar a junção entre as funcionalidades da ferramenta e a estrutura padrão do<br />
plug-in para o Eclipse. Com base nos padrões de desenvolvimento, facade e<br />
singleton, foi construído um conjunto de classes com as funcionalidades da<br />
ferramenta proposta neste projeto. Foram também utilizados os conceitos de<br />
Annotations e Reflection para tornar possível à recuperação das regras de negócio.<br />
Os conceitos Annotations foram utilizados para associar os componentes do Swing<br />
com as regras de negócio do protótipo desenvolvido, e os conceitos de Reflection<br />
foram utilizados para chamar um template (um modelo padrão de interface) para<br />
tornar possível à visualização das regras de negócio.<br />
25
5.1- REQUISITOS DA FERRAMENTA.<br />
As tabelas 03 e 04 listam os requisitos que foram levantados para a ferramenta.<br />
Identificação<br />
Tabela 03 – Requisitos não funcionais<br />
Descrição Prioridade<br />
RNF01<br />
A ferramenta deverá ser implementada seguindo os padrões<br />
do Eclipse, no que diz respeito à interface gráfica.<br />
Importante<br />
RNF02<br />
RNF03<br />
RNF04<br />
RNF05<br />
A ferramenta deve ser construída no formato de plug-in para<br />
o Eclipse<br />
A ferramenta deverá disponibilizar, nos protótipos<br />
desenvolvidos, um acesso intuitivo às regras de negócios<br />
vinculadas pelo usuário<br />
A ferramenta deverá sinalizar os componentes que possuem<br />
associação com as regras de negócios<br />
A ferramenta deverá permitir as anotações em protótipos<br />
desenvolvidos em Swing do JAVA<br />
Essencial<br />
Essencial<br />
Essencial<br />
Essencial<br />
Identificação<br />
Tabela 04 – Requisitos funcionais<br />
Descrição<br />
A ferramenta deverá permitir que a associação das regras<br />
Prioridade<br />
RF01<br />
de negócios seja realizada através de anotações nos<br />
componentes do código fonte do protótipo em Swing do<br />
JAVA<br />
Essencial<br />
RF02<br />
A ferramenta deverá listar as regras de negócios por<br />
projeto existente no Eclipse para auxiliar na anotação Importante<br />
RF03<br />
RF04<br />
RF05<br />
A ferramenta deverá permitir que o usuário desenvolvedor<br />
do protótipo importe, para a ferramenta, as regras de<br />
negócios por meio de arquivo (.xml)<br />
A ferramenta deverá verificar se o arquivo importado<br />
possui inconsistência na estrutura do XML , verificar se<br />
possui campos não preenchidos e verificar se os tipos<br />
estão corretos<br />
A ferramenta deverá permitir que o desenvolvedor tenha a<br />
opção de ativar ou desativar a inclusão das regras de<br />
negócios nos protótipos anotados.<br />
Essencial<br />
Essencial<br />
Essencial<br />
26
5.2 – DIAGRAMA DE CASO DE USO.<br />
A Figura 07 mostra os casos de uso identificados.<br />
5.2.1 - Casos de uso.<br />
Figura 07 – Caso de uso do projeto de criação da ferramenta<br />
A Tabela 05 mostra os casos de uso.<br />
27
Tabela 05 – Casos de uso relacionado aos requisitos<br />
Identificação Descrição Requisito<br />
UC001 Importar as regras de negócio RF03<br />
UC002 Validar o padrão do arquivo RF04<br />
UC003<br />
Anotar as regras de negócios nos componentes do<br />
protótipo<br />
RF01<br />
UC004 Configurar as propriedades do plug-in RF05<br />
UC005 Listar regras de negócios RF02<br />
UC006 Recuperar as regras de negócios RNF03/RNF04<br />
Segue a especificação do caso de uso, detalhando as ações da ferramenta<br />
construída neste projeto.<br />
5.2.2 - Especificação do caso de uso.<br />
Tabela 06 – Casos de uso UC001<br />
Número do Caso de UC001<br />
Uso<br />
Nome do Caso de Importar as regras de negócio<br />
Uso<br />
Ator(es) Desenvolvedor<br />
Descrição Este caso de uso tem como objetivo importar as<br />
regras de negócios para um determinado projeto do<br />
Eclipse, por meio de arquivo .xml<br />
Pré-condições Ter a ferramenta Eclipse inicializada com o plug-in<br />
Pós-condições Não se aplica<br />
Fluxo principal 1 - O usuário deve selecionar um projeto para<br />
associar o arquivo (EXC001).<br />
2 - O usuário deve selecionar um arquivo no formato<br />
XML (EXC001).<br />
3 - A ferramenta verifica o arquivo: Ver caso de uso<br />
UC002<br />
Fluxo alternativo Não se aplica<br />
Exceções EXC001 - Campos não preenchidos<br />
Essa exceção indica que o campo não foi preenchido<br />
corretamente.<br />
28
Inclusão (includes) UC002<br />
Extensões (extend) Não se aplica<br />
Tabela 07 – Casos de uso UC002<br />
Número do Caso de UC002<br />
Uso<br />
Nome do Caso de Validar o padrão do arquivo<br />
Uso<br />
Ator(es) Sistema<br />
Descrição Este caso de uso tem como objetivo analisar a<br />
estrutura do arquivo e verificar se existe alguma falha<br />
de padrão.<br />
Pré-condições Ter recebido o caminho do arquivo a importar e um<br />
projeto de desenvolvimento do Eclipse<br />
Pós-condições Não se aplica<br />
Fluxo principal 1 - A classe de importação da ferramenta verifica se a<br />
estrutura do XML no arquivo está de acordo com o<br />
padrão especificado pela ferramenta. (EXC001)<br />
2 - A classe de importação da ferramenta verifica se<br />
os campos da estrutura do XML no arquivo não estão<br />
preenchidos. (EXC002)<br />
3 - A classe de importação da ferramenta verifica se o<br />
tipo de dados está de acordo com o padrão<br />
especificado na ferramenta. (EXC003)<br />
Fluxo alternativo Não se aplica<br />
Exceções EXC001 - Erro de estrutura<br />
É exibido uma mensagem de erro, indicando a linha e<br />
o que é esperado na estrutura do arquivo XML.<br />
EXC002 - Erro de campos não preenchidos<br />
É exibido uma mensagem de erro, indicando que o<br />
campo do XML está vazio.<br />
EXC003 - Erro de tipo de dados<br />
É exibido uma mensagem de erro informando qual<br />
campo está com problemas no tipo de dados<br />
especificado.<br />
Inclusão (includes) Não se aplica<br />
Extensões (extend) Não se aplica<br />
Número do Caso de<br />
Uso<br />
Nome do Caso de<br />
Uso<br />
Tabela 08 – Casos de uso UC003<br />
UC003<br />
Anotar as regras de negócios nos componentes do<br />
protótipo<br />
29
Ator(es) Desenvolvedor<br />
Descrição Este caso de uso tem como objetivo anotar as regras<br />
de negócios no componente do protótipo direto no<br />
código fonte por meio de Annotation.<br />
Pré-condições O protótipo tem que ser em Java com a utilização da<br />
classe Swing<br />
Pós-condições Não se aplica<br />
Fluxo principal 1 - O desenvolvedor arrasta o objeto listado na visão<br />
das regras de negócio e solta acima do componente<br />
que deseja associar a regra.<br />
2 – O sistema inclui o código do Annotation com o<br />
identificador da regra de negócio.<br />
Fluxo alternativo Não se aplica<br />
Exceções Não se aplica<br />
Inclusão (includes) Não se aplica<br />
Extensões (extend) Não se aplica<br />
Tabela 09 – Casos de uso UC004<br />
Número do Caso de UC004<br />
Uso<br />
Nome do Caso de Configurar as propriedades do plug-in<br />
Uso<br />
Ator(es) Desenvolvedor<br />
Descrição Este caso de uso tem como objetivo possibilitar o<br />
usuário optar por compilar o protótipo com as regras<br />
de negócios ou não.<br />
Pré-condições Não se aplica<br />
Pós-condições Não se aplica<br />
Fluxo principal 1 - Selecionar um projeto do Eclipse<br />
2 - Selecionar true para compilar as regras de<br />
negócios ou false para não compilar as regras de<br />
negócios no protótipo.<br />
Fluxo alternativo Não se aplica<br />
Exceções Não se aplica<br />
Inclusão (includes) Não se aplica<br />
Extensões (extend) Não se aplica<br />
Tabela 10 – Casos de uso UC005<br />
Número do Caso de UC005<br />
Uso<br />
Nome do Caso de Listar regras de negócios<br />
Uso<br />
Ator(es) Desenvolvedor<br />
30
Descrição Este caso de uso tem como objetivo listar as regras<br />
de negócios que estão vinculadas a um projeto do<br />
Eclipse.<br />
Pré-condições Ter a ferramenta Eclipse inicializada com o plug-in<br />
Pós-condições Não se aplica<br />
Fluxo principal 1 - O desenvolvedor seleciona a opção de mostrar a<br />
visão de listagem das regras de negócio associadas<br />
aos projetos.<br />
Fluxo alternativo Não se aplica<br />
Exceções Não se aplica<br />
Inclusão (includes) Não se aplica<br />
Extensões (extend) Não se aplica<br />
Tabela 11 – Casos de uso UC006<br />
Número do Caso de UC006<br />
Uso<br />
Nome do Caso de Recuperar as regras de negócios<br />
Uso<br />
Ator(es) Stakeholders<br />
Descrição Este caso de uso tem como objetivo recuperar as<br />
regras de negócio para serem visualizadas pelos<br />
usuários.<br />
Pré-condições Ter executado um protótipo com regras de negócios<br />
anotadas em algum componente<br />
Pós-condições Não se aplica<br />
Fluxo principal 1 - O stakeholder seleciona com o click direito do<br />
mouse um componente sinalizado em vermelho<br />
2 - O protótipo recupera a regra de negócio associado<br />
ao componente e disponibiliza em um formulário para<br />
a visualização.<br />
Fluxo alternativo Não se aplica<br />
Exceções Não se aplica<br />
Inclusão (includes) Não se aplica<br />
Extensões (extend) Não se aplica<br />
5.3 – ARQUITETURA DO PLUG-IN.<br />
O plug-in desenvolvido neste projeto foi destinado para a ferramenta Eclipse que é<br />
uma plataforma livre que possibilita o usuário construir ferramentas integráveis de<br />
31
forma transparente para o ambiente de desenvolvimento. O Eclipse é uma<br />
ferramenta construída sobre um núcleo, o Kernel de tempo de execução, e suas<br />
funcionalidades todas elas desenvolvidas como plug-in. (GALLARDO, 2002)<br />
O plug-in construído neste projeto depende de mais dois plug-ins que são os<br />
Workbench e o Workspace. Esses dois componentes são indispensáveis para<br />
plataforma do Eclipse, pois eles fornecem os pontos de extensões usados pela<br />
maioria dos plug-ins. O Workbench possui as extensões ligadas à interface do<br />
Eclipse como, por exemplo, a criação do menu e a tela que lista as regras de<br />
negócios do plug-in desenvolvido no projeto. Já o Workspace possui as extensões<br />
de recursos dos projetos existentes no Eclipse como, por exemplo, a listagem de<br />
projetos que foi utilizado no plug-in desenvolvido no projeto. (GALLARDO, 2002)<br />
A Figura 08 – mostra a dependência dos plug-ins no Eclipse.<br />
Figura 08 – Estrutura de dependência de plug-in e bibliotecas<br />
Neste caso o plug-in desenvolvido no projeto depende dos componentes Workbench<br />
e o Workspace para utilizar dos recursos de interface e informações dos projetos<br />
existentes no Eclipse.<br />
32
5.4 – PROJETO DE DESENVOLVIMENTO.<br />
No item a seguir mostra o diagrama de classe e a explicação das classes mais<br />
relevantes deste projeto.<br />
5.4.1 - Diagrama de Classe<br />
A Figura 09 mostra o diagrama de classe da ferramenta proposta neste projeto.<br />
Figura 09 – Diagrama de classes.<br />
33
As classes e suas funcionalidades são:<br />
BusinessRules – Classe responsável por armazenar um conjunto de regras de<br />
negócio na ferramenta.<br />
BusinessRulesXML – Classe responsável pela importação do arquivo XML para a<br />
ferramenta.<br />
Processor – Classe responsável por processar as anotações do código fonte dos<br />
protótipos.<br />
Facade - Classe responsável por estabelecer a interface da ferramenta com as<br />
classes do plug-in.<br />
BusinessRulesView – Classe responsável por criar a estrutura que lista as regras de<br />
negócio na ferramenta Eclipse.<br />
BusinessRulesProperties – Classe responsável pela interface que disponibiliza a<br />
configuração do plug-in.<br />
BusinessRulesImport – Classe responsável pela interface de entrada de dados para<br />
realizar a importação do arquivo.<br />
Handlers – Classe responsável por inicializar as interfaces do plug-in, quando o<br />
evento no Eclipse é disparado.<br />
As classes mais importantes do projeto são Processor, BusinessRulesXml. A classe<br />
Processor é responsável por inserir um método template, que cria um formulário com<br />
as informações da regra de negócio associado, no evento do componente em Swing<br />
anotado. Essa anotação é feita pelo recurso disponibilizado na linguagem JAVA, o<br />
Annotations. Já a classe BusinessRulesXml é responsável pela importação do<br />
arquivo em XML, que utiliza os recursos da biblioteca JDom(Conjunto de funções<br />
que ler e cria arquivos no formato XML). Nesta classe, BusinessRulesXml, também é<br />
feita a verificação se os campos estão preenchidos corretamente. Os códigos fontes<br />
dessas classes podem ser visualizados no APÊNDICE A.<br />
34
5.4.2 - Arquivo plugin.xml<br />
O arquivo plugin.xml é responsável por indicar para o Eclipse quais as<br />
funcionalidades proposta pelo plug-in a ser criado. No caso deste projeto proposto, o<br />
arquivo de plug-in.xml, por exemplo, foi criado uma Tag para inserir um novo Menu<br />
contendo uma opção para iniciar a interface de importação do arquivo de regras de<br />
negócio.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Como já explicado anteriormente no item 3 do capitulo 5 deste projeto, o Eclipse é<br />
constituído de vários plug-ins, no trecho do código fonte acima a Tag Extension<br />
indica a inclusão de um novo Menu na UI( user interface, interface usuário) do<br />
Eclipse. No APÊNDICE B pode-se visualizar todo o código fonte do arquivo<br />
plugin.xml utilizado neste projeto.<br />
35
5.4.3 - Estrutura do arquivo de regras.<br />
A estrutura de arquivo para importação que está sendo utilizado neste projeto foi<br />
criado para atender as necessidades da ferramenta ABREP. O padrão criado foi<br />
tomando como base o padrão de Gisele P Morgado. O padrão criado para a<br />
ferramenta proposto neste projeto é uma estrutura simples que possui dois níveis de<br />
hierarquia. (MORGADO, 2007)<br />
No código fonte a seguir, é mostrado um exemplo contendo as regras de negócios e<br />
sua estrutura.<br />
<br />
- <br />
- <br />
Cadastro de Aluno<br />
03/04/2010<br />
1<br />
Para cadastrar o aluno é necessario que ele esteja presente com os pais na hora<br />
da matricula, portando Rg.<br />
Antonio Carlos<br />
- <br />
+ <br />
+ <br />
+ <br />
+ <br />
- <br />
Filhiação<br />
03/04/2010<br />
1<br />
É necessário informar o nome, Rg e CPF do pai e da mãe, para que ele se torne o<br />
responsável pelo aluno.<br />
Antonio Carlos<br />
36
<br />
<br />
+ <br />
<br />
Essa estrutura das tags é explicada na Tabela 12 a seguir:<br />
Tabela 12 – Descrição das tags do arquivo de importação<br />
Tag Descrição<br />
Corpo principal, onde contem o conjunto de regras de negócio<br />
A regra de negócio possui um identificar (Id) como atributo da<br />
<br />
tag<br />
Objetivo da regra de negócio<br />
Data da criação da regra de negócio<br />
Versão da regra de negócio<br />
Descrição dos detalhes da regra de negócio<br />
O autor da regra de negócio<br />
Sub conjuntos de regras de negócio dependentes<br />
5.5 - FERRAMENTA.<br />
A ferramenta foi desenvolvida para o Eclipse Galileo na versão 3.5.2. Para a<br />
utilização da ferramenta proposta neste projeto é necessário que se copie o arquivo<br />
org.businessRules_1.0.0.201006061526.jar para pasta plugins dentro do Eclipse,<br />
geralmente o endereço da pasta fica localizado no endereço “C:\Arquivos de<br />
programas\eclipse\plugins\”. Para poder processar as anotações é necessário<br />
também incluir um biblioteca (BusinessRuleAnnotations.jar) no projeto que contem o<br />
protótipo a ser desenvolvido. A Figura 10 mostra a adição da biblioteca no projeto.<br />
37
Figura 10 – Adicionando a biblioteca (BusinessRuleAnnotations.jar) ao projeto.<br />
5.5.1 - Uso da ferramenta.<br />
Seguindo como exemplo o sistema de escola, para a utilização da ferramenta<br />
proposta neste projeto, dentro da ferramenta do Eclipse, após a criação de um<br />
projeto em Java, no exemplo utilizado “SistemaEscolar”, o desenvolvedor tem a<br />
opção de importar as regras de negócio para o Eclipse. Conforme a Figura 11:<br />
38
Figura 11 – Tela de importação da regra de negócio.<br />
Para importar as regras como a Figura 12, é necessário escolher um arquivo no<br />
formato XML e escolher um projeto para associar as regras. No campo Status serão<br />
exibidas as mensagens do processo de importação. Essas mensagens são de<br />
confirmação da importação ou de erro de tipagem de dados, formatação do arquivo<br />
XML ou quando o campo no arquivo não está preenchido.<br />
Durante a criação do protótipo o desenvolvedor tem a opção de listar as regras de<br />
negócios para ajudar no processo de anotação aos componentes do protótipo. Para<br />
mandar exibir a visão que lista as regras, o desenvolvedor tem que escolher na<br />
opção de visões na janela e escolher a opção de visões do Business Rules.<br />
Figura 12 – Tela que lista as regras de negócio associados ao projeto.<br />
39
Para a utilização da técnica proposta neste projeto, o desenvolvedor terá que<br />
realizar três procedimentos para realizar toda a anotação das regras de negócios<br />
nos componentes dos protótipos desenvolvidos em Swing. O primeiro procedimento,<br />
o desenvolvedor deverá anotar a classe que utilizará as regras de negócio passando<br />
como parâmetro o nome do projeto. A Figura 13 mostra um exemplo de anotação da<br />
classe com o projeto de “SistemaEscolar”.<br />
Figura 13 – Anotação da classe para poder anotar as regras de negócio nos componentes.<br />
Existem duas possibilidades de realizar a anotação da classe, a primeira, o<br />
desenvolvedor digita o comando “@BusinessRulesProject<br />
(Project=”SistemaEscolar")” , a segunda forma, é arrastar da listagem da regra de<br />
negócio o projeto para o código fonte do protótipo.<br />
O segundo procedimento é a realização das anotações dos componentes com o<br />
identificador da regra de negócio. A Figura 14 mostra a anotação de uma regra em<br />
um componente do protótipo.<br />
40
Figura 14 – Anotação da regra de negócios no componente jButton.<br />
Conforme visto no procedimento anterior, também pode-se arrastar da listagem das<br />
regras de negócio para o código fonte do protótipo desenvolvido.<br />
O terceiro procedimento é a inclusão de um método estático para processar as<br />
anotações incluídas no código fonte do protótipo passando como parâmetro a classe<br />
que contém os componentes. Utilizando os conceitos de reflexão (Reflection) e de<br />
invocar (Invoke) é realizado a inclusão das regras de negócio nos protótipos para<br />
posteriormente ser recuperados.<br />
Para a recuperação das regras de negócio no protótipo, durante a execução do<br />
mesmo, basta clicar com o botão direito do mouse os componentes sinalizados. O<br />
desenvolvedor tem a possibilidade e optar por incluir as regras no protótipo ou não,<br />
indo em Properties (Propriedades) do BusinessRules do Eclipse.<br />
A Figura 15 mostra a tela que recupera as regras de negócio após o evento do botão<br />
do mouse.<br />
41
5.5.2 - Avaliação da ferramenta.<br />
Figura 15 – Recuperação da regra de negócio.<br />
Para a avaliação da ferramenta foi dedicado aproximadamente 20 horas de teste<br />
para avaliar a sua estabilidade e usabilidade. A ferramenta durante todo o teste<br />
apresentou-se estável e não foi constatado falhas durante sua execução. Durante a<br />
recuperação das regras de negócios, todos os protótipos testados no exemplo do<br />
sistema para escola, utilizado neste projeto, não demonstraram erros na<br />
recuperação e continuaram estáveis. A utilização dos conceitos de Drag-And-Drop<br />
(Arrastar e soltar), utilizados para ajudar na anotação, contribuiu para o<br />
desenvolvedor e diminuiu os riscos de associações indevidas melhorando a<br />
usabilidade da ferramenta.<br />
Durante a inclusão do método estático para processar as anotações, foi encontrado<br />
uma dificuldade, por que é necessário passar como parâmetro toda a classe que<br />
contem os componentes instanciados e já configurados para a sua visualização o<br />
que dificulta a usabilidade da ferramenta.<br />
Os procedimentos de anotações e recuperações das regras de negócio foram bem<br />
sucedidos em todos os componentes da classe Swing.<br />
42
Existem alguns pontos da ferramenta passiveis de melhoria, principalmente a parte<br />
da utilização do Annotaions, transformando o processamento das anotações em<br />
plug-in, o que diminuiria a dificuldade de incluir o método estático no protótipo e<br />
diminuiria a dependência dos protótipos a ferramenta. Outro ponto que necessita de<br />
melhorias é do evento do mouse que recupera as informações das regras de<br />
negócio, que atualmente só é realizado com o click do botão direito do mouse, o que<br />
impossibilita o sistema de utilizar o evento no protótipo enquanto as regras estão<br />
sendo recuperadas.<br />
43
CONCLUSÃO.<br />
Normalmente os requisitos são derivados das regras de negócio que compõem o<br />
software. Durante a construção de um software, é de fundamental importância o<br />
levantamento dos requisitos do sistema para a construção de um software bem<br />
sucedido. A utilização da ferramenta protótipo auxilia de forma bastante positiva,<br />
quando bem utilizado, a atividade de levantamento de requisitos.<br />
O objetivo deste projeto foi apresentar uma forma prática de associação entre as<br />
regras de negócios e os protótipos evolutivos. Para isso foi desenvolvido uma<br />
ferramenta em formato de plug-in para o Eclipse que permite ao desenvolvedor<br />
anotar as regras de negócio nos componentes dos protótipos construídos em Swing<br />
da linguagem JAVA. Posteriormente durante a utilização desses protótipos, é<br />
possível de forma bastante intuitiva, a recuperação das informações das regras de<br />
negócio. Essas recuperações auxiliam bastante os stakeholders, onde a<br />
visualização das regras de negócios facilita o entendimento da solução proposta no<br />
protótipo e as necessidades que os stakeholders levantaram.<br />
A pesquisa mostrou que existem outras formas de se recuperar as informações<br />
durante o uso dos protótipos, porém essas formas de recuperação não foram<br />
consideradas eficazes na utilização dos protótipos evolutivos e foram consideradas<br />
também dispendiosas. Para isso a pesquisa foi realizada, tomado como base os<br />
aspectos dos processos da engenharia de requisito e a prototipação de software.<br />
Ainda em relação à pesquisa percebeu-se que a inclusão das regras de negócio no<br />
código fonte dos protótipos seria uma forma eficaz de recuperar as informações das<br />
regras de negócio.<br />
As dificuldades encontradas neste projeto foram, a busca pela documentação dos<br />
recursos do Eclipse para a construção do plug-in, e a dificuldade da construção do<br />
referencial teórico sobre as Regras de Negócios.<br />
44
Os estudos realizados neste projeto levam a conclusão de que essa forma de<br />
associação e recuperação das regras de negócio pode ser utilizada no processo de<br />
levantamento de requisitos e prototipação, da Engenharia Software, porém com<br />
base nos próprios estudos, essa forma pode ser mais indicada na construção de um<br />
software baseado nas metodologias ágeis.<br />
O projeto de construção da ferramenta ABREP para ser encontrado no SourceForge<br />
(Site que permite ao usuário disponibilizar o código fonte de um determinado projeto<br />
com o intuito de contribuir com a comunidade para conhecimento, aprendizado e<br />
aperfeiçoamento da tecnicas e metodologias utilizadas nos ambientes da Tecnologia<br />
da Informação.), uma vez que a ferramenta é Open Sorce (ferramenta de código<br />
livre) e não possui custos de licença nem na utilização e nem na criação.<br />
Para trabalhos futuros são sugeridos a continuação da pesquisa das anotações em<br />
componentes web (jsf), a integração da ferramenta para o NetBeans no formato de<br />
plug-in, realização de teste mais aprofundados e o estudo da viabilidade da<br />
utilização da ferramenta.<br />
45
REFERÊNCIAS<br />
ARNOWITZ, Jonathan; ARENT, Michael; BERGER, Nevin. Effective Prototyping<br />
for Software Makers. São Paulo: Morgan Kaufmann, 2006.<br />
BRG. Defining Business Rules ~ What Are They Really? 4th ed.<br />
(July 2000). Disponível na internet.<br />
http://www.businessrulesgroup.org. 08 mai. 2010.<br />
GALLARDO, David. Desenvolvendo Plug-ins do Eclipse. 2002. Disponível na<br />
internet. http://www.ibm.com/developerworks/br/library/os-ecplug/. 20 mai. 2010<br />
KOTONYA, Gerald ; SOMMERVILLE, Ian. “Requirements Engineering”. Wiley,<br />
1998.<br />
MORGADO, Gisele P; et al. Práticas do CMMI® como regras de negócio. In:<br />
PRODUÇÃO, v. 17, n. 2, p. 383-394, Rio de Janeiro, RJ, Maio/Ago, 2007.<br />
FILHO, Wilson de Pádua Paula. Engenharia de Software; fundamentos, métodos<br />
e padrões 2ª Edição. Rio de Janeiro: LTC, 2003.<br />
PETERS, James. F; ET al. Engenharia de Software. Tradução Ana Patrícia Garcia.<br />
Rio de Janeiro: Campus, 2001.<br />
PRESSMAN, Roger S. Engenharia de Software 6ª Edição. São Paulo: McGraw-<br />
Hill. 2006.<br />
SOMMERVILLE, Ian. Engenharia de Software, 6ª Edição. São Paulo: Pearso<br />
Addison-Wesley, 2004.<br />
SOMMERVILLE, Ian. Engenharia de Software, 8ª Edição. São Paulo: Pearso<br />
Addison-Wesley, 2007.<br />
VON HALLE, Barbara. Business rules applied : building better systems using<br />
the business rules approach. New York: John Wiley & Sons, 2002.<br />
ZSIFKOV, N; CAMPEANU, R. Business Rules Domains and Business Rules<br />
Modeling. Las Vegas, Nevada 2004.172-177p. Dissertação In: INTERNATIONAL<br />
46
SYMPOSIUM ON INFORMATION AND COMMUNICATION TECHNOLOGIES<br />
(ISICT), Trinity College Dublin.<br />
47
APÊNDICE A<br />
Código fonte da classe Processor.<br />
public class Processor<br />
{<br />
/**<br />
Processes all ActionListenerFor annotations in the given object.<br />
@param obj an object whose methods may have ActionListenerFor annotations<br />
* @throws NoSuchMethodException<br />
* @throws SecurityException<br />
*/<br />
public static void processorAnnotations(Object obj)<br />
{<br />
try<br />
{<br />
Class
}<br />
public static void addCollor(Object source) throws SecurityException,<br />
NoSuchMethodException, IllegalArgumentException, IllegalAccessException,<br />
InvocationTargetException<br />
{<br />
Class
Object listener = Proxy.newProxyInstance(null, new Class[] {<br />
java.awt.event.ActionListener.class }, handler);<br />
//Method adder = source.getClass().getMethod("addActionListener",<br />
ActionListener.class);<br />
Object listener = Proxy.newProxyInstance(null, new Class[] {<br />
java.awt.event.MouseListener.class }, handler);<br />
Method adder = source.getClass().getMethod("addMouseListener",<br />
MouseListener.class);<br />
adder.invoke(source, listener);<br />
}<br />
}<br />
Código fonte da classe BusinessRulesXml.<br />
public class BusinessRulesXml{<br />
public BusinessRulesXml(){}<br />
public Boolean saveData(Iterator i, FileWriter file)<br />
{<br />
Element businessRulesXml = new Element("BusinessRules");<br />
while(i.hasNext())<br />
{<br />
BusinessRule br = i.next();<br />
Element businessRule = new Element("BusinessRule");<br />
Element objective = new Element("Objective");<br />
Element creationDate = new Element("CreationDate");<br />
Element version = new Element("Version");<br />
Element description = new Element("Description");<br />
Element author = new Element("Author");<br />
Element groupBusinessRule = new<br />
Element("BusinessRulesGroup");<br />
businessRule.setAttribute("id", br.getId());<br />
objective.setText(br.getObjective());<br />
creationDate.setText(br.getCreationDate());<br />
version.setText(br.getVersion().toString());<br />
description.setText(br.getDescription());<br />
author.setText(br.getAuthor());<br />
businessRule.addContent(objective);<br />
businessRule.addContent(creationDate);<br />
businessRule.addContent(version);<br />
businessRule.addContent(description);<br />
businessRule.addContent(author);<br />
Iterator iChildren =<br />
br.getGrouptBusinessRule();<br />
while(iChildren.hasNext())<br />
{<br />
BusinessRule brChildren = iChildren.next();<br />
50
Element("BusinessRule");<br />
Element("Objective");<br />
Element("CreationDate");<br />
Element("Version");<br />
Element("Description");<br />
Element("Author");<br />
brChildren.getId());<br />
Element businessRuleChildren = new<br />
Element objectiveChildren = new<br />
Element creationDateChildren = new<br />
Element versionChildren = new<br />
Element descriptionChildren = new<br />
Element authorChildren = new<br />
businessRuleChildren.setAttribute("id",<br />
objectiveChildren.setText(brChildren.getObjective());<br />
creationDateChildren.setText(brChildren.getCreationDate());<br />
versionChildren.setText(brChildren.getVersion().toString());<br />
descriptionChildren.setText(brChildren.getDescription());<br />
authorChildren.setText(brChildren.getAuthor());<br />
businessRuleChildren.addContent(objectiveChildren);<br />
businessRuleChildren.addContent(creationDateChildren);<br />
businessRuleChildren.addContent(versionChildren);<br />
businessRuleChildren.addContent(descriptionChildren);<br />
businessRuleChildren.addContent(authorChildren);<br />
groupBusinessRule.addContent(businessRuleChildren);<br />
}<br />
businessRule.addContent(groupBusinessRule);<br />
}<br />
try<br />
{<br />
businessRulesXml.addContent(businessRule);<br />
Document doc = new Document();<br />
doc.setRootElement(businessRulesXml);<br />
XMLOutputter xout = new XMLOutputter();<br />
Format formatXML = org.jdom.output.Format.getPrettyFormat();<br />
formatXML.setEncoding("ISO-8859-1");<br />
xout.setFormat(formatXML);<br />
xout.output(doc, file);<br />
return true;<br />
}<br />
catch(Exception e)<br />
{<br />
51
}<br />
}<br />
return false;<br />
public void loadData(File file) throws JDOMException, IOException,<br />
Exception<br />
{<br />
Element businessRulesXml = new Element("BusinessRules");<br />
SAXBuilder sb = new SAXBuilder();<br />
Document d = sb.build(file);<br />
businessRulesXml = d.getRootElement();<br />
List elements = businessRulesXml.getChildren();<br />
Iterator i = elements.iterator();<br />
while(i.hasNext())<br />
{<br />
Element element = (Element)i.next();<br />
String id = element.getAttributeValue("id");<br />
if(id.isEmpty()) throw new Exception("Fild Id is<br />
empyt : " + element.getText());<br />
String objective =<br />
element.getChildText("Objective");<br />
if(objective.isEmpty()) throw new Exception("Fild<br />
Objective is empyt : " + element.getText());<br />
String creationDate =<br />
element.getChildText("CreationDate");<br />
if(creationDate.isEmpty()) throw new<br />
Exception("Fild CreationDate is empyt : " + element.getText());<br />
DateFormat dateFormat = new<br />
SimpleDateFormat("dd/MM/yyyy");<br />
try<br />
{<br />
Date creationDateTest =<br />
dateFormat.parse(creationDate);<br />
creationDate =<br />
dateFormat.format(creationDateTest);<br />
} catch (ParseException e)<br />
{<br />
throw new Exception("Data in wrong<br />
format : " + e.getMessage());<br />
}<br />
String version = element.getChildText("Version");<br />
if(version.isEmpty()) throw new Exception("Fild<br />
Version is empyt : " + element.getText());<br />
String description =<br />
element.getChildText("Description");<br />
if(description.isEmpty()) throw new Exception("Fild<br />
Description is empyt : " + element.getText());<br />
String author = element.getChildText("Author");<br />
if(author.isEmpty()) throw new Exception("Fild<br />
Author is empyt : " + element.getText());<br />
52
BusinessRule br = new BusinessRule(id, objective,<br />
creationDate, Integer.parseInt(version), description, author);<br />
Element elementsGroup =<br />
element.getChild("BusinessRulesGroup");<br />
List elementsChildren =<br />
elementsGroup.getChildren("BusinessRule");<br />
Iterator iChildren =<br />
elementsChildren.iterator();<br />
(Element)iChildren.next();<br />
while(iChildren.hasNext())<br />
{<br />
Element elementChildren =<br />
String idChildren =<br />
elementChildren.getAttributeValue("id");<br />
String objectiveChildren =<br />
elementChildren.getChildText("Objective");<br />
String creationDateChildren =<br />
elementChildren.getChildText("CreationDate");<br />
String versionChildren =<br />
elementChildren.getChildText("Version");<br />
String descriptionChildren =<br />
elementChildren.getChildText("Description");<br />
String authorChildren =<br />
elementChildren.getChildText("Author");<br />
BusinessRule brChildren = new<br />
BusinessRule(idChildren, objectiveChildren, creationDateChildren,<br />
Integer.parseInt(versionChildren), descriptionChildren, authorChildren);<br />
br.addWithinGroupBusinessRule(brChildren);<br />
}<br />
}<br />
}<br />
BusinessRules.getInstance().addBusinessRule(br);<br />
public Boolean saveProperties(Boolean properties, FileWriter file)<br />
{<br />
Element propertiesElement = new Element("Properties");<br />
Element runBusinessRulesElement = new<br />
Element("RunBusinessRules");<br />
runBusinessRulesElement.setText(properties.toString());<br />
propertiesElement.addContent(runBusinessRulesElement);<br />
try<br />
{<br />
Document doc = new Document();<br />
doc.setRootElement(propertiesElement);<br />
XMLOutputter xout = new XMLOutputter();<br />
Format formatXML = org.jdom.output.Format.getPrettyFormat();<br />
formatXML.setEncoding("ISO-8859-1");<br />
xout.setFormat(formatXML);<br />
53
}<br />
xout.output(doc, file);<br />
return true;<br />
}<br />
catch(Exception e)<br />
{<br />
return false;<br />
}<br />
public Boolean loadProperties(File file) throws JDOMException,<br />
IOException, Exception<br />
{<br />
Element propertiesElement = new Element("Properties");<br />
SAXBuilder sb = new SAXBuilder();<br />
Document d = sb.build(file);<br />
propertiesElement = d.getRootElement();<br />
String properties =<br />
propertiesElement.getChildText("RunBusinessRules");<br />
}<br />
}<br />
return Boolean.parseBoolean(properties);<br />
54
APÊNDICE B<br />
Estrutura do arquivo plugin.xml<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
55
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
56
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
57