argus oliveira guedes williams falcão damasceno ... - UCSAL

ARGUS OLIVEIRA GUEDES
WILLIAMS FALCÃO DAMASCENO MACHADO
ABREP - UMA FERRAMENTA PARA ANOTAÇÃO DAS REGRAS DE
NEGÓCIO EM PROTÓTIPOS EVOLUTIVOS.
SALVADOR
2010

ARGUS OLIVEIRA GUEDES
WILLIAMS FALCÃO DAMASCENO MACHADO
ABREP - UMA FERRAMENTA PARA ANOTAÇÃO DAS REGRAS DE
NEGÓCIO EM PROTÓTIPOS EVOLUTIVOS.
Monografia apresentada ao Curso de
Bacharelado em Informática da
Universidade Católica do Salvador como
requisito parcial à obtenção do diploma de
Bacharel em Informática.
Orientador: Prof. Antonio Claudio Pedreira
Neiva.
SALVADOR
2010

UNIVERSIDADE CATÓLICA DO SALVADOR
CURSO DE BACHARELADO EM INFORMÁTICA
DEPARTAMENTO DE INFORMÁTICA
ABREP - UMA FERRAMENTA PARA ANOTAÇÃO DAS REGRAS DE
NEGÓCIO EM PROTÓTIPOS EVOLUTIVOS.
BANCA EXAMINADORA
__________________________________
Prof. Antonio Claudio Pedreira Neiva
__________________________________
Prof. Likiso Hattori
__________________________________
Prof. Jorge Luiz Falcão Perrone
SALVADOR
2010

CERTIFICADO
Certifico que a presente memória, ABREP - Uma ferramenta para anotação das
regras de negócio em protótipos evolutivos, foi realizada sob minha orientação
por ARGUS OLIVEIRA GUEDES e WILLIAMS FALCÃO DAMASCENO MACHADO,
constituindo o Projeto Final do Curso de Bacharelado em Informática da Universidade
Católica do Salvador – UCSAL.
Salvador, 07 de junho de 2010
Antonio Claudio Pedreira Neiva
Curso de Bacharelado em Informática
Universidade Católica do Salvador
SALVADOR
2010

AGRADECIMENTOS
Em primeiro lugar agradecemos a Deus, pela força e resignação para conseguirmos
chegar até aqui.
Aos nossos pais e namoradas, por toda paciência, compreensão e carinho; por
acreditarem em nosso potencial, por nos incentivarem, por estarem sempre ao nosso
lado em todos os momentos difíceis ao longo dessa jornada. Agradecemos também
aos membros de nossa família que sempre estiveram de nosso lado.
Aos nossos amigos que participaram conosco dessa caminhada, onde vivenciamos
muito momentos marcantes, felizes e alguns poucos tristes. Agradecemos a velha e
boa feijoada da Escaldaria onde nos reuníamos em todos os primeiros dias aula do
semestre para matar a saudade, colocar a conversa em dia e beber umas
cervejinhas para enfrentar o semestre que ali começava.
Agradecemos ao grande mestre Claudio Neiva, nosso orientador, pela paciência,
ajuda e disponibilidade; ao mestre Likiso Hattori, que nos apoiou, nos aconselhou em
momentos de dúvidas. Agradecemos a todos os outros professores pelo
conhecimento passado ao longo desses cinco anos.
Por último agrademos aos nossos chefes, coordenadores e colegas de trabalho pela
ajuda, compreensão e liberação em todos os momentos que houve necessidade.
Argus Guedes e Willians Falcão

“A vida é para quem topa qualquer parada. Não para quem pára em qualquer
topada.”
(Bob Marley)

RESUMO
Este projeto apresenta o desenvolvimento de uma ferramenta para Eclipse que
permite a anotação das regras de negócio no código fonte de uma aplicação Java
(Swing) na construção de protótipos evolutivos. O objetivo dessa ferramenta é de
poder recuperar as informações sobre as regras de negócio anotadas nos diversos
componentes da aplicação, durante a execução da mesma, de forma intuitiva,
facilitando o entendimento das mesmas (as regras) para o cliente o que contribui
para verificação e validação dos requisitos do sistema a ser desenvolvido.
Palavras chave: protótipo, prototipação evolutiva, requisitos, regras de negócio,
anotação.

ABSTRACT
This project presents the development of a tool for Eclipse that allows annotation of
business rules in the source code of a Java (Swing) in evolutionary prototyping. The
purpose of this tool is able to retrieve information about the business rules recorded
in the various application components during the execution of it, intuitively, facilitating
the understanding of these (rules) to the client which helps to check and validation of
system requirements to be developed.
Key words: prototype, evolutionary prototyping, requirements, business rules,
annotations

SUMÁRIO
INTRODUÇÃO ........................................................................................................... 1
1 - REQUISITOS. ....................................................................................................... 3
1.1 – CLASSIFICAÇÃO DOS REQUISITOS. ............................................................ 4
1.2 – TIPOS DE REQUISITOS. .................................................................................. 5
1.2.1 - Requisitos Funcionais .................................................................................. 6
1.2.2 - Requisitos Não-Funcionais. ......................................................................... 6
1.2.3 - Requisitos de Domínio. ................................................................................. 7
2 – ENGENHARIA DE REQUISITOS. ........................................................................ 8
3 – REGRAS DE NEGÓCIO. ................................................................................... 10
3.1 – CLASSIFICAÇÃO DAS REGRAS DE NEGÓCIO. .......................................... 11
4 - PROTÓTIPO. ...................................................................................................... 15
4.1 – PROTOTIPAÇÃO DE SOFTWARE. ............................................................... 15
4.2 – FASES DO PROCESSO DE DESENVOLVIMENTO DE UM PROTÓTIPO. ... 16
4.3 – PROTOTIPAÇÃO DESCARTÁVEL. ............................................................... 17
4.4 – PROTOTIPAÇÃO EVOLUCIONÁRIA OU EVOLUTIVA. ................................ 19
4.5 – PROTÓTIPO EM PAPEL. ............................................................................... 21
4.6 – PROTÓTIPO “WIZARD OF OZ”. .................................................................... 21
4.7 – PROTÓTIPO AUTOMÁTICO. ......................................................................... 21
4.8 – MODELOS DE DESENVOLVIMENTO. ........................................................... 22
4.9 – DESENVOLVIMENTO RÁPIDO DE SOFTWARE. ......................................... 22
5 - PROJETO. .......................................................................................................... 24
5.1- REQUISITOS DA FERRAMENTA. ................................................................... 26

5.2 – DIAGRAMA DE CASO DE USO. .................................................................... 27
5.2.1 - Casos de uso. .............................................................................................. 27
5.2.2 - Especificação do caso de uso. ................................................................... 28
5.3 – ARQUITETURA DO PLUG-IN......................................................................... 31
5.4 – PROJETO DE DESENVOLVIMENTO. ............................................................ 33
5.4.1 - Diagrama de Classe .................................................................................... 33
5.4.2 - Arquivo plugin.xml ...................................................................................... 35
5.4.3 - Estrutura do arquivo de regras. ................................................................. 36
5.5 - FERRAMENTA. ............................................................................................... 37
5.5.1 - Uso da ferramenta. ...................................................................................... 38
5.5.2 - Avaliação da ferramenta. ............................................................................ 42
CONCLUSÃO. ......................................................................................................... 44
REFERÊNCIAS ........................................................................................................ 46
APÊNDICE A ........................................................................................................... 48
APÊNDICE B ........................................................................................................... 55

LISTA DE FIGURAS
Figura 01: Leitores de diferentes tipos de especificações............................... 05
Figura 02: Tipos de Requisitos Não-Funcionais............................................... 07
Figura 03: Processo de engenharia de requisito.............................................. 09
Figura 04: Processo de desenvolvimento de protótipo.................................... 17
Figura 05: Um processo de software com prototipação descartável.............. 19
Figura 06: Prototipação evolucionária............................................................... 20
Figura 07: Caso de uso do projeto de criação da ferramenta.......................... 27
Figura 08: Estrutura de dependência de plug-in e bibliotecas........................ 32
Figura 09: Diagrama de classes.......................................................................... 33
Figura 10: Adicionando a biblioteca (BusinessRuleAnnotations.jar) ao
projeto...................................................................................................................
Figura 11: Tela de importação da regra de negócio......................................... 39
Figura 12: Tela que lista as regras de negócio associados ao projeto........... 39
Figura 13: Anotação da classe para poder anotar as regras de negócio nos
componentes........................................................................................................
Figura 14: Anotação da regra de negócios no componente jButton.............. 41
Figura 15: Recuperação da regra de negócio.................................................... 42
38
40

LISTA DE TABELAS
Tabela 01: Classificação das Regras de Negócio............................................. 12
Tabela 02: Modelo de sentenças utilizado pelo sistema RÉGULA.................. 14
Tabela 03: Requisitos não funcionais................................................................ 26
Tabela 04: Requisitos funcionais........................................................................ 26
Tabela 05: Casos de uso relacionado aos requisitos....................................... 28
Tabela 06: Casos de uso UC001......................................................................... 28
Tabela 07: Casos de uso UC002......................................................................... 29
Tabela 08: Casos de uso UC003......................................................................... 30
Tabela 09: Casos de uso UC004......................................................................... 30
Tabela 10: Casos de uso UC005......................................................................... 31
Tabela 11: Casos de uso UC006......................................................................... 31
Tabela 12: Descrição das tags do arquivo de importação............................... 37

INTRODUÇÃO
A engenharia de requisitos tem fundamental importância no processo de
desenvolvimento de um software, pois normalmente a engenharia de requisitos é
constituída das atividades de obtenção, especificação e validação dos requisitos,
que quando bem executadas, proporcionam um software que atende as reais
necessidades propostas ao sistema, evitando com isso a insatisfação do cliente.
Nesse processo estão inclusas também as regras de negócios, que no decorrer da
construção do software, vão sendo expostas como necessidades pelo cliente,
tornando-se posteriormente os requisitos do software.
Uma das técnicas utilizadas pela engenharia de software para o levantamento,
verificação e, validação dos requisitos é conhecida como prototipação de software.
Essas técnicas, prototipação, trazem ainda como benefícios o amadurecimento dos
requisitos e familiarização do novo sistema em desenvolvimento com os usuários.
(SOMMERVILLE, 2004)
Normalmente os protótipos são uma versão simplificada dos sistemas a serem
desenvolvidos. Freqüentemente os protótipos são a representação da interface
gráfica com o objetivo de representar as regras de negócio. Nessa representação
normalmente existe uma dificuldade dos stakeholders 1 visualizar as regras de
negócio, cálculos e procedimentos completos por causa das dificuldades da
representação.
Com essa dificuldade de representação da visualização geralmente se recorre para
uma leitura da documentação, tornando-se assim um trabalho árduo e impreciso.
Neste projeto é proposto a ferramenta ABREP, que permite através da técnica de
Annotations, efetuar anotações das regras de negócio no código fonte de uma
aplicação JAVA(Swing), no desenvolvimento de protótipos evolutivos. Outra
1 “Os Stakeholders são as pessoas ou organizações que são de alguma forma, afetadas pelo sistema
e/ou que tem diretamente ou indiretamente influência nos requisitos do sistema” (SOMMERVILLE,
2004).
1

funcionalidade dessa ferramenta é a de proporcionar aos stakeholders a
recuperação dessas regras anotadas durante a execução dos protótipos de forma
mais intuitiva.
Este trabalho esta desmembrado em 5 capítulos, começando pelo primeiro capítulo,
que apresenta os conceitos dos requisitos de um software. O capitulo 2 que mostra
os conceitos da engenharia de requisitos e suas atividades, o capitulo 3 que
apresenta os conceito das regras de negócio, o capitulo 4 apresenta os conceitos,
os tipos dos protótipos e o processo de prototipação, os modelos de
desenvolvimento de software e alguns conceitos do desenvolvimento rápido de
software, o capitulo 5 que mostra toda a documentação e especificação, e um
exemplo de uso com avaliação dos pontos positivos e negativos da ferramenta
ABREP e por fim a conclusão do trabalho.
2

1 - REQUISITOS.
Durante a construção de um software, nem sempre é uma tarefa simples entender a
natureza dos problemas especificados pelos clientes e obter uma solução para
esses problemas. Por isso, analisar e compreender esses problemas são os
primeiros passos para construção de um software. Os problemas acima
mencionados são as descrições das funções e das restrições para o sistema a ser
criado (SOMMERVILLE, 2007).
Existem diversos conceitos para os requisitos e todos oferecem uma perspectiva
diferente para o mesmo assunto. Peters (2001) apresenta um conceito mais
completo, especialmente por tratar mais detalhadamente as características de um
requisito.
Um requisito de software é uma descrição dos principais recursos de
um produto de software, seu fluxo de informações, comportamento e
atributos. Em suma, um requisito fornece uma estrutura básica para o
desenvolvimento de um produto de software. O grau de
compreensibilidade, precisão e rigor da descrição fornecida por um
documento de requisitos de software tende ser diretamente
proporcional ao grau de qualidade do produto resultante. (PETERS,
2001)
Percebe-se, então, que os requisitos podem ser definidos como um conjunto de
necessidades especificadas pelo cliente com o intuito de solucionar um problema do
negócio de interece do cliente. Essas especificações se não forem bem
compreendidas pelos desenvolvedores acarretam no desenvolvimento de um
software com qualidade discutível. Para se obter um produto de qualidade, Filho
(2003) nos diz que, a especificação dos requisitos deve satisfazer a uma série de
características:
• Correção – Verificar se todo requisito presente na especificação de requisitos
é realmente um requisito do produto a ser construído. Essa verificação e feita
checando a coerência da especificação dos requisitos com outros
3

documentos da aplicação.
• Precisão – Garantir que todo requisito presente na especificação tenha
somente uma interpretação pelos envolvidos na criação do software.
• Completeza – Refletir todas as decisões da especificação que forram
tomadas como: requisitos significativos relativos à funcionalidade,
desempenho, restrições, atributos e interfaces. Definir as respostas do
software para as entradas possíveis, válidas e inválidas. Conter um glossário
de todos os termos técnicos, unidades de medida e referências a todos os
diagramas e figuras.
• Consistência – Não deve haver nenhum conflito entre os subconjuntos de
requisitos.
• Priorização – Classificar os requisitos de acordo com a sua importância e
estabilidade, pois é grande a probabilidade de que o requisito venha a ser
alterado no desenvolver do projeto.
• Verificabilidade – Garantir que todo requisito possa ser verificado através de
um processo finito de baixo custo e que possa ser executado por uma
máquina ou pessoa.
• Modificabilidade – Permitir que o requisito possa ser modificado de forma
fácil, clara e consistente.
• Rastreabilidade – Garantir a fácil determinação dos antecedentes e
conseqüências do requisito.
1.1 – CLASSIFICAÇÃO DOS REQUISITOS.
A descrição dos requisitos pode ser de alto nível, como uma linguagem natural, ou
específica, como a descrição de uma função matematicamente formal. Para fazer
essas distinções e facilitar a compreensão dos envolvidos no levantamento de
requisitos, Sommerville (2007) utilizou a seguinte classificação:
4

• Requisitos de usuário para tratar dos requisitos abstratos, aqueles definidos
pelo usuário através do uso da linguagem natural, com baixo grau de
detalhamento.
• Requisitos de sistema para descrever as funções e o que realmente o
sistema deve fazer, podendo até mesmo ser utilizado como contrato entre o
comprador e desenvolvedor de sistema, com alto grau de detalhamento.
• Especificação do projeto de software que pode ser utilizado para integrar
os requisitos de sistema e as especificações do projeto.
Existem diversas formas de classificar os requisitos. Pode-se, por exemplo, separá-
los por níveis de detalhamento, com o objetivo de buscar o entendimento dos
mesmos para diferentes leitores. A Figura 01 indica um quadro dos leitores e seus
diferentes tipos de especificações.
Figura 01 - Leitores de diferentes tipos de especificações (SOMMERVILLE, 2004)
1.2 – TIPOS DE REQUISITOS.
Os requisitos de sistema, geralmente, são divididos em três tipos: funcionais, não
funcionais e de domínio.
5

1.2.1 - Requisitos Funcionais
Entende-se por requisitos funcionais, “as declarações de serviços que o sistema
deve fornecer, como o sistema deve reagir a entradas especificas e como deve se
comportar em determinadas situações” (SOMMERVILLE, 2007). Os requisitos
funcionais dependem diretamente do tipo de software que está sendo desenvolvido
e dos stakeholders que os avaliarão. Normalmente os requisitos funcionais de
usuário são escritos de forma geral, enquanto que os requisitos funcionais de
sistema detalham, de forma precisa, as entradas, saídas, exceções do sistema,
entre outros. A descrição dos requisitos funcionais do sistema deve conter todas as
funções solicitadas pelo usuário de forma bem definida, não é permitido
contradições entres os requisitos. (SOMMERVILLE, 2007)
1.2.2 - Requisitos Não-Funcionais.
Os requisitos não-funcionais “são restrições sobre os serviços ou as funções
oferecidas pelo sistema. Eles incluem restrições de timing 2 , restrições sobre o
processo de desenvolvimento e padrões” (SOMMERVILLE, 2007). Geralmente, os
requisitos não-funcionais atingem a totalidade das funcionalidades do sistema. Com
isso, quando não atendidos, podem tornar o sistema inútil, diferente dos requisitos
funcionais que, quando não atendidos, podem degradar somente uma parte do
sistema. Existem diversas categorias de requisitos não-funcionais, a Figura 02
mostra as suas classificações:
2 Cronometragem, afinação.
6

Figura 02 – Tipos de Requisitos Não-Funcionais (SOMMERVILLER, 2007).
1.2.3 - Requisitos de Domínio.
Requisitos de domínio “são requisitos provenientes do domínio da aplicação do
sistema e que refletem as características e as restrições desse domínio”
(SOMMERVILLE, 2007). Com base nessa definição, esses requisitos são obtidos do
domínio da aplicação, diferentemente dos requisitos vistos anteriormente que são
obtidos através das necessidades especificas dos usuários. Esses requisitos podem
ser extremamente importantes para o perfeito funcionamento do sistema, já que os
mesmos refletem os fundamentos do universo da aplicação. Os requisitos de
domínio podem ser funcionais ou não funcionais.
7

2 – ENGENHARIA DE REQUISITOS.
No âmbito dos projetos de desenvolvimento de software, compreender as reais
necessidades do cliente é uma tarefa muito complexa. Por isso, exige-se um esforço
contínuo para analisar e consolidar os problemas para conciliá-los entre o cliente e o
projetista. O conjunto desses processos é conhecido como engenharia de requisitos,
que foi explicada por Pressman (2006) da seguinte forma:
A engenharia de requisitos ajuda os engenheiros de software a
compreender melhor o problema que eles vão trabalhar para resolver.
Ela inclui o conjunto de tarefas que levam a um entendimento de qual
será o impacto do software sobre o negócio, do que o cliente quer e de
como os usuários finais vão interagir com o software. (PRESSMAN,
2006)
Analisar e compreender os problemas propostos pelo cliente é muito importante para
evitar desenvolver as soluções de problemas maus compreendidos, o que
acarretaria em um sistema que não supriria as necessidades do cliente.
Os processos que compõem a engenharia de requisitos são formados por quatro
atividades genéricas consideradas de alto nível, segundo Sommerville (2004). Essas
quatro atividades são: o estudo da viabilidade do sistema; a obtenção e a análise de
requisito; a especificação de requisitos e sua documentação; e a validação desses
requisitos.
A Figura 03 mostra o fluxo das interações entre essas atividades e seus resultados.
Durante o projeto de construção do software, os requisitos naturalmente sofrem
modificações, e essas modificações, normalmente, partem das pessoas envolvidas
no processo, principalmente considerando que as opiniões sobre o que desejam que
o software faça podem ser modificadas com o passar do tempo. Outros motivos que
levam às alterações dos requisitos são: a evolução da organização contratante, o
mercado tecnológico e as modificações de hardware.
8

Figura 03 – Processo de engenharia de requisito (Adaptado de SOMMERVILE, 2004)
Essas mudanças dos requisitos são controladas pela atividade de gerenciamento de
requisitos. Atividade que tem extrema importância para negociar as modificações
necessárias com intuito de satisfazer a todos participantes do projeto da construção
do software.
9

3 – REGRAS DE NEGÓCIO.
Segundo o BRG (2000),
10
regras de negócio são expressões que definem ou restringem alguns
aspectos do negócio, com a intenção de declarar a estrutura do
negócio, controlar ou influenciar o comportamento do mesmo. As
regras de negócio as quais o projeto se preocupa, são atômicas, isto é,
não podem ser decompostas. (BRG, 2000)
Entende-se com isso que as regras de negócio são um conjunto de condições que
regem uma empresa para que um evento ocorra de forma aceitável para o negócio.
As regras de negócio têm duas importantes funções que são: “reduzir o tempo de
desenvolvimento de software e fornecer um sistema que seja projetado para ser
mutável” (VON HALLE, 2002). Para elaboração de uma regra de negócio é
necessário a utilização de uma metodologia diferente das demais metodologias de
desenvolvimento de sistemas, pois, segundo o BRG (2000), “as regras de negócio
são superficiais, não se desligam dos artefatos de outros sistemas, não se
aperfeiçoam e não se mantêm ao longo do tempo”. Essa metodologia “coloca mais
ênfase na importância, disciplina e formalização das regras de negócio e
conseqüentemente, a entrega dessas regras dentro da lógica do sistema
correspondente mutável” (VON HALLE, 2002).
Sob a perspectiva dos sistemas de informação as regra de negócio são definidas
como declarações que definem ou restringem aspectos do negócio (BRG, 2000). A
partir desse principio, percebe-se que através das operações de negócio as regras
de negócios são definidas como restrições ou metadados (informações sobre os
dados). As regras de negócio também são conhecidas como regras do domínio da
aplicação, ou regras de minimundo (problema específico de uma organização)
(ZSIFKOV, 2004).

Segundo as definições acima fica fácil identificar que o funcionamento correto do
negócio depende direta e essencialmente das regras de negócios, pois nelas estão
definidos os aspectos do negócio.
Conforme o que foi abordado entende-se que as regras de negócio são de
fundamental importância para as organizações, pois, elas refletem o domínio da
organização. A não utilização das regras de negócio no processo de
desenvolvimento de software pode acarretar na elaboração de um sistema que não
seja suscetível a acomodar mudanças o que não convêm a uma organização, pois
suas regras podem mudar com a necessidade e o passar do tempo, sendo então
necessário o desenvolvimento de um novo sistema para atender a essas mudanças.
Segundo Von Halle (2002), algumas características das regras de negócio podem
ser definidas como:
• Regras de Negócio são expressões declarativas: são declarações
objetivas, com o intuito de comunicar a essência da regra de maneira mais
clara possível.
• Regras de Negócio não são processos: as regras descrevem o que deve
ser feito e não como deve ser feito.
• Regras de Negócio não dependem de tecnologia: elas devem ser definidas
sem o comprometimento com tecnologias.
• Regras de Negócio são atômicas: as regras não podem ser decompostas
em mais de uma regra.
3.1 – CLASSIFICAÇÃO DAS REGRAS DE NEGÓCIO.
Como abordado nas definições anteriores, as regras de negócio estão contidas no
domínio da aplicação, fazendo com que não exista uma única classificação formal. A
Tabela 01 mostra diversos esquemas de classificação propostos por vários autores
e organizações:
11

Tabela 01 – Classificação das Regras de Negócio (VON HALLE, 2002)
Tabela de Classificação das Regras de Negócio
Fonte Sistema de Classificação de Regras de Negócio
Business Rules Group
(2000)
Ross(2001) • Fatos
• Termos
• Regras
• Restrições
• Derivações
• Inferências
• Cronometragem
• Seqüencia
General Data Analysis
Tipos de Regras
Derivação: uma derivação de conhecimento que é derivado
de outros conhecimentos no negócio.
• Cálculo Matemático
• Inferência
Afirmação de caráter estrutural: um conceito definido da
declaração de um fato que expressa algum aspecto da
estrutura da empresa. Isso envolve tanto os termos e os
fatos montados a partir destes termos.
• Termos
• Fatos
Afirmação de ação: uma declaração de uma restrição ou
condição que limita ou controla as ações da empresa.
• Autorização
• Condição
• Restrições de integridade
• Heurística
Atributos das Regras
• Singularidade
• Opcionalidade
• Verificador de Valor
Computações
Inferências
Restrições de entidade multi-atributos
Regras de Relacionamento
• Cardinalidade
• Opcionalidade
• Integridade Referencial
• Contagens de Cardinalidade
C. J. Date (2000) • Restrições
• Restrição Estado
• Restrição de Transição
• Resposta a Estímulos
• Derivações
• Computação
• Inferência
C. J. Date (2000) Cris Date Further propõe ainda outro esquema de restrições
que é baseado na estrutura dos dados em si.
• Restrições de Domínio
• Restrições de Coluna
• Restrições de Tabela (restrições dentro de uma tabela)
• Restrições do Banco de Dados (restrições entre duas ou
12

mais tabelas)
Versate Inc. • Regras de Integridade Referencial
• Derivações (Atributos computacionais)
• Validação (atributo obrigatório/valores opcionais. Min,
max)
• Restrição (atributo para atributo. Restrições dentro da
entidade)
• Evento/Ação
• Regras de Apresentação
USoft Inc. (Mallens(1997)) • Regras de restrição: restrições comerciais sobre a
informação a ser armazenada, o que não é permitido.
• Regras de Comportamento: como o sistema se
comportar em determinadas situações, o que o sistema
deve fazer automaticamente.
• Regras Dedutivas: como as informações devem ser
calculadas ou derivadas.
• Regras de Apresentação: como o sistema se apresenta
para o usuário, como o trabalho e tarefa devem ser
organizados.
• Regras de instrução: como o usuário irá operar o
sistema em determinadas situações.
Esse sistema de classificação depende dos serviços fornecidos pelos diversos
autores e organizações, conforme visto na tabela acima, para atingir o público-alvo.
Essa forma sistemática de classificação serve para identificar e analisar os negócios
das empresas.
Esses sistemas de classificação podem ser utilizados por diversos públicos alvos
como: desenvolvedores, administradores de banco de dados, analistas /
modeladores de dados, dentre outros.
Para Morgado (2007) as regras de negócio também podem ser agrupadas através
de algumas características comuns como:
• Termos – são os elementos básicos da linguagem utilizada para expressar as
Regras de Negócio, onde a própria definição de um termo é considerada
como uma regra.
• Fatos – descrevem a natureza ou estrutura operacional de um negócio,
relacionando os termos uns aos outros.
13

• Cálculos e Derivações – determinam como um conhecimento ou informação
pode ser transformado em outro, através de fórmulas ou mudanças de
estado.
• Restrições – restringem algum comportamento do negócio, estando
relacionadas às decisões sobre quais dados podem ou não ser atualizados.
• Habilitações de Ação – regras dedutivas, de raciocínio encadeado à frente,
representadas através de um par contendo uma condição e respectiva ação.
A Tabela 02 exemplifica a utilização das características definidas por Morgado
(2007) em um sistema.
Tabela 02 – Modelo de sentenças utilizado pelo sistema RÉGULA (MORGADO, 2007).
Conclui-se então que não existe uma forma única para se classificar as regras de
negócio, pois como já foi abordado antes, cada autor/organização pode elaborar seu
próprio conjunto de regras de negócio de acordo com o domínio de sua aplicação.
14

4 - PROTÓTIPO.
A palavra protótipo vem do grego protos (primeiro) + typos (impressão), ou seja,
‘primeira impressão’. O Dicionário Priberam da Língua Portuguesa nos da os
seguintes significados para a palavra protótipo: primeiro tipo, modelo, exemplar e
padrão. Entende-se com isso que um protótipo é um modelo inicial para servir de
teste antes da construção do produto final.
4.1 – PROTOTIPAÇÃO DE SOFTWARE.
“Um protótipo é uma versão inicial de um sistema de software usado para
demonstrar conceitos, experimentar opções de projetos e, geralmente, conhecer
mais sobre o problema e suas possíveis soluções”. (SOMMERVILLE, 2007)
15
[...] os protótipos são as representações reais do software, que
permitem a equipe do software ter uma experiência do projeto sem
precisar programar o software. Um protótipo é toda a tentativa de
realizar qualquer aspecto do conteúdo do software. Por exemplo, o
protótipo pode ser uma realização da interação e da navegação de um
ponto em um produto a outro. Um protótipo pode igualmente ser um
esquema hierárquico de um projeto da informação, separado do olhar
e da sensação do software final. (ARNOWITZ, 2006)
Os conceitos acima mostram que as principais funções da prototipação é facilitar o
entendimento dos requisitos de sistemas para usuários e os stakeholders, e
contribuir para que haja redução de riscos, já que com a prototipação pode-se
identificar os erros e/ou omissões de requisitos que prejudicariam o funcionamento
correto do software. Para Pressman (2006), o paradigma da prototipação auxilia o
engenheiro de software e o comprador a entenderem melhor o que deve ser
construído quando os requisitos de sistema estão confusos.
Sommerville (2004) define os benefícios da prototipação como:

• A prototipação permite demonstrar aos stakeholders o significado dos
requisitos;
• A Prototipação permite verificar se existem equívocos na interpretação dos
requisitos entre os programadores e os stakeholders;
• Redução dos riscos numa fase avançada do desenvolvimento já que erros ou
omissões dos requisitos são identificados na prototipação.
• Serviços esquecidos podem ser detectados e serviços confusos podem ser
identificados.
• Um sistema funcionando está disponível nos primeiros estágios no processo
de desenvolvimento. (somente na prototipação evolutiva)
• O protótipo pode servir como uma base para derivar uma especificação do
sistema com qualidade de produção.
• O protótipo pode ser usado para treinamento do usuário e teste de sistema.
Não são relatados problemas de prototipação e sim conseqüências negativas que as
técnicas de prototipagem podem gerar se mal administradas como:
• A demora na entrega do protótipo acarreta no atraso do desenvolvimento do
sistema o que acaba gerando um aumento do custo do sistema final
• A reutilização de um código de protótipo ineficiente acaba por diversas vezes
degradando o desempenho geral do sistema.
4.2 – FASES DO PROCESSO DE DESENVOLVIMENTO DE UM PROTÓTIPO.
A Figura 04 mostra as fases do processo de desenvolvimento de um protótipo.
16

Figura 04 – Processo de desenvolvimento de protótipo (SOMMERVILLE, 2004).
A primeira tarefa é a de estabelecer de forma explicita os objetivos do protótipo para
que não ocorra um mau entendimento por parte dos gerentes ou dos usuários finais
do sistema, o que acarretaria na perda dos benefícios da construção do protótipo. A
tarefa seguinte é a definição das funcionalidades do protótipo, é nessa fase que se
estabelece as funções que devem ser incluídas ou excluídas dos protótipos para
alcançar os objetivos propostos, com menor prazo e menor custo. Após a fase de
desenvolvimento, os protótipos são apresentados aos usuários que os utilizarão
para que os mesmo possam se adaptar ao novo padrão de uso. Com essa
adaptação os usuários descobrirão os erros e omissões dos requisitos.
(SOMMERVILLE, 2004)
4.3 – PROTOTIPAÇÃO DESCARTÁVEL.
Segundo Filho (2003),
17
protótipo descartável (throw-away) é aquele tipicamente construído
durante a engenharia de requisitos cuja única finalidade é demonstrar
para os usuários o que o analista captou dos requisitos do sistema ou
parte deles. O fundamental na construção de um protótipo descartável
é a rapidez de construção, devendo esse ser produzido em poucas
horas ou no máximo em poucos dias. (FILHO, 2003)
A decisão de utilizar esse tipo de prototipação é que o custo de construí-los e depois
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
no qual fornece informações sobre os requisitos para os gerentes avaliarem os
riscos dos processos. Após essa avaliação, os protótipos são descartados e não são
mais utilizados para posterior desenvolvimento. O descarte do protótipo só ocorre
após a criação do documento de requisitos e satisfação parcial ou total do cliente.
Para se obter esse documento e a satisfação do cliente, algumas etapas são
necessárias, como a: elaboração de um documento de requisitos provisório,
obtenção de opiniões do usuário e se necessário uma reformulação do documento
de requisitos. Essas etapas são repetidas por diversas vezes, já que o objetivo é a
criação de um documento de requisitos final, item fundamental para sistemas de
grande porte, pois, facilitam e diminuem futuramente o custo com manutenções e
novas implementações que venham a ocorrer, além de aumentar a satisfação do
cliente. A partir daí o sistema poderá ser desenvolvido em processo cascata,
incremental, ou outro.
Filho (2003) destaca os seguintes benefícios, com o uso da prototipação
descartável:
• Redução dos riscos na construção;
• Aumento da manutenibilidade - uma característica da engenharia de software
atribuída a facilidade de um software ser modificado para a correção de
defeitos, alteração/ inclusão de novos requisitos, adequação a um novo
ambiente dentre outras atividades de manutenção de software;
• Aumento da estabilidade dos requisitos;
• Oportunidade para treinamento dos programadores menos experientes,
trabalhando como codificadores.
As desvantagens da utilização da prototipação descartável é um aumento no custo
de implementação, já que o protótipo construído será descartado. Mas como já foi
abordando, esse aumento no custo da implementação nos traz o beneficio da
redução dos riscos na construção do sistema final. A Figura 05 mostra um processo
de desenvolvimento de software através da prototipação descartável.
18

Figura 05 – Um processo de software com prototipação descartável (SOMMERVILLE, 2006).
Nesse processo de desenvolvimento, um protótipo é desenvolvido a partir de um
modelo inicial definido a partir da especificação do sistema, sendo disponibilizado ao
cliente para experimentação. Esse protótipo pode sofrer mudanças até que o cliente
esteja satisfeito com suas funcionalidades. Com a aprovação do cliente uma nova
especificação do sistema é elabora a partir do protótipo aprovado e o sistema pode
ser reimplementado em uma versão final de produção. (SOMMERVILLE, 2004).
4.4 – PROTOTIPAÇÃO EVOLUCIONÁRIA OU EVOLUTIVA.
Estudos mostraram que um software, como todos os sistemas complexos, evoluem
com o passar do tempo. “Os requisitos do negócio e do produto mudam
freqüentemente à medida que o desenvolvimento prossegue, dificultando um
caminho direto para o produto final”. (PRESSMAN, 2006)
A prototipação evolutiva parte do principio, como o próprio nome já diz, de evolução.
Desta forma, cria-se um protótipo inicial contendo os requisitos que são mais bem
compreendidos e de maior prioridade para o sistema a ser desenvolvido. Esse
protótipo inicial passa por diversas fases de melhorias e incrementos até se tornar o
sistema final.
19

Segundo Filho (2003), alguns benefícios da prototipação evolutiva são:
• Rápida entrega do sistema;
• O sistema é desenvolvido de forma incremental;
• Utilização de técnicas de rápido desenvolvimento de software;
• Possui funcionalidades semelhantes ao do sistema final;
• Alto grau de interatividade com o usuário;
• Exploração e teste diversos com elevado grau de realismo.
Filho (2003) também define alguns pontos negativos como:
• Elevado custo e tempo de desenvolvimento na fase inicial do processo de
prototipação;
• Ineficiente para testes de opções de design de implementação;
• Requisitos não funcionais não são testados de forma adequada;
Esse alto custo inicial com o desenvolvimento é compensado futuramente com a
evolução do protótipo para o sistema final. A Figura 06 nos mostra um processo de
prototipação evolutiva.
Figura 06 – Prototipação evolucionária (SOMMERVILLER, 2004).
Na prototipação evolutiva o “desenvolvimento rápido e iterativo do protótipo é
essencial, de modo que os custos são controlados e os stakeholders do sistema
podem experimentar o protótipo mais cedo no processo de software”
(SOMMERVILLE, 2007). Para se obter esse rápido desenvolvimento e iteratividade
20

no desenvolvimento de um protótipo, a engenharia de software dispõe de modelos
de desenvolvimento incremental e ferramentas de desenvolvimento rápido para
auxiliarem essa tarefa.
4.5 – PROTÓTIPO EM PAPEL.
“É desenvolvido um conjunto de interfaces associadas a cenários de utilização que
são apresentados aos usuários. Esse tipo de prototipagem é barata e eficiente”
(Kotonya, 1998). O desenvolvimento de um software executável não é necessário no
protótipo em papel. Esse tipo de protótipo é muito eficiente para sistemas interativos,
pois permite que os analistas e usuários percorram esses cenários.
4.6 – PROTÓTIPO “WIZARD OF OZ”.
“Uma pessoa simula as respostas do sistema em resposta as ações dos usuários.
Esse tipo de prototipagem é relativamente barata visto que apenas a interface do
sistema tem quer ser desenvolvida” (Kotonya, 1998). Quando se tem uma interface
existente esse é o tipo de protótipo mais adequado a ser desenvolvido, pois os
usuários interagem com o que parece ser o sistema. Essas interações são
analisadas por uma pessoa que simula as respostas do sistema.
4.7 – PROTÓTIPO AUTOMÁTICO.
“É utilizado em linguagens de 4ª geração ou outras linguagens que permitem um
rápido desenvolvimento de protótipos executáveis. Esse tipo de prototipagem é a
mais cara” (Kotonya, 1998). Esse tipo de protótipo envolve o desenvolvimento de
software, recorrendo a linguagens de programação de alto nível, que simulem as
funcionalidades do sistema final a ser construído.
21

4.8 – MODELOS DE DESENVOLVIMENTO.
Conforme abordado, os sistemas evoluem com o passar do tempo e com essas
mudanças os requisitos do sistema também mudam. Com isso nota-se que no
processo de desenvolvimento de software, as atividades do processo são repetidas
regularmente a medida que o sistema é refeito para atender a essas mudanças.
Para facilitar esse processo de mudança existem alguns modelos de processos que
auxiliam essa atividade. Dois modelos de processo são os: modelo incremental onde
“a especificação, o projeto e a implementação do software são divididos em uma
série de incrementos desenvolvidos um de cada vez” (SOMMERVILLE, 2007) e o
modelo espiral onde “o desenvolvimento do sistema evolui em espiral para fora a
partir de um esboço inicial até o sistema final” (SOMMERVILLE, 2007).
4.9 – DESENVOLVIMENTO RÁPIDO DE SOFTWARE.
Existem atualmente no mercado diversas ferramentas e metodologias para o
desenvolvimento rápido de software que auxiliam no processo de elaboração dos
protótipos evolutivos. Essas metodologias utilizam os conceitos dos Métodos Ágeis
(em inglês Agile Modeling, ou AG) “que visam a redução do ciclo de vida do software
(e, por conseguinte acelerar o seu desenvolvimento) desenvolvendo uma versão
mínima, seguidamente integrando as funcionalidades por um processo iterativo
baseado na escuta do cliente e testes ao longo de todo o ciclo de desenvolvimento”
(KIOSKES, 2009).
A metodologia XP (Extreme Programming) e as técnicas de RAD (Rapid Aplication
Development) são exemplos de metodologias de rápido desenvolvimento de
software. A programação XP é uma metodologia ágil criada no final da década de
90, voltada a equipes pequenas e médias que produzem software baseados em
requisitos vagos e que mudam com rapidez e as técnicas de RAD são um modelo de
processo de desenvolvimento de software iterativo e incremental que enfatiza um
22

ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias). (PRESSMAN,
2006)
23

5 - PROJETO.
Os requisitos e sua engenharia compõem um conjunto de atividades muito
importantes para aquisição dos objetos fundamentais de um software, tais como
obtenção, especificação e validação dos requisitos. Freqüentemente, estão contidas
no software as regras de negócios que, normalmente, são manifestadas como
necessidades pelos clientes, o que, ao longo das atividades da engenharia de
requisitos, vão compondo os requisitos do software.
Durante a construção de um software, dentro da atividade de levantamento de
requisitos é muito comum a utilização dos protótipos para que os stakeholders
tenham noção do significado dos requisitos. No momento da avaliação dos
protótipos se faz necessária a recuperação dos requisitos para que os stakeholders
visualizem as necessidades solicitadas e vejam como foi proposta a solução para as
mesmas.
No processo de avaliação dos protótipos pelos stakeholders, nota-se geralmente
uma dificuldade na compreensão da proposta apresentada pelos desenvolvedores
do protótipo em relação às necessidades expostas pelo cliente. Normalmente existe
a dificuldade de se recuperar as informações, principalmente as regras de negócios
contidas nas necessidades do cliente, o que pode acarretar na dificuldade do
amadurecimento dos requisitos e até mesmo impossibilitar a extração de novos
requisitos por conta da falta de informações. Então, como tornar a recuperação das
informações das regras de negócios mais eficiente e eficaz para ajudar na avaliação
dos protótipos?
Utiliza-se como exemplo a construção de um sistema para uma escola, onde se faz
necessário a associação dos alunos para as suas respectivas turmas. Foram
levantadas as seguintes regras de negócio: o aluno não pode ser associado a mais
de uma turma e uma turma não pode ultrapassar o limite máximo estabelecido. O
desenvolvedor cria então o protótipo do sistema. Os stakeholders precisam fazer a
análise deste protótipo para aprovar ou não a criação do sistema nos moldes
24

propostos pelo desenvolvedor. Como, então, tornar este momento mais proveitoso
tanto para o desenvolvedor quanto para o cliente?
Pensando nisto, foi desenvolvida, neste projeto, uma ferramenta que possibilita,
durante a criação dos protótipos evolutivos, anotações das regras de negócio nos
componentes das interfaces desenvolvidas em Swing na linguagem de programação
JAVA. O que, posteriormente, permite também a recuperação das regras nas telas
propostas, de forma intuitiva, ajudando no processo de amadurecimento e
esclarecimento dos requisitos, levantamento de novos requisitos e, até mesmo, a
familiarização dos usuários finais com o novo sistema que será construído. Dessa
forma, durante o processo de criação do protótipo do sistema da escola do exemplo
acima citado, o desenvolvedor poderá anotar, nos elementos do protótipo, as regras
levantadas, como: um aluno só deve estar vinculado a uma turma, que há um limite
máximo de alunos em cada turma, e os stakeholders poderão recuperá-las em
momentos como apresentação, validação e simulação dos protótipos do sistema,
analisando com maior clareza se o sistema se adequará ou não às suas
necessidades.
A construção dessa ferramenta tomou como base o estudo sobre a criação dos plug-
ins para a ferramenta Eclipse. Notou-se que seria necessária uma estrutura em
XML, onde essa estrutura indicaria a integração das funcionalidades criadas pela
ferramenta proposta neste projeto com a ferramenta Eclipse. Após a compreensão
dessa estrutura foi necessário o estudo sobre os padrões de desenvolvimento, para
facilitar a junção entre as funcionalidades da ferramenta e a estrutura padrão do
plug-in para o Eclipse. Com base nos padrões de desenvolvimento, facade e
singleton, foi construído um conjunto de classes com as funcionalidades da
ferramenta proposta neste projeto. Foram também utilizados os conceitos de
Annotations e Reflection para tornar possível à recuperação das regras de negócio.
Os conceitos Annotations foram utilizados para associar os componentes do Swing
com as regras de negócio do protótipo desenvolvido, e os conceitos de Reflection
foram utilizados para chamar um template (um modelo padrão de interface) para
tornar possível à visualização das regras de negócio.
25

5.1- REQUISITOS DA FERRAMENTA.
As tabelas 03 e 04 listam os requisitos que foram levantados para a ferramenta.
Identificação
Tabela 03 – Requisitos não funcionais
Descrição Prioridade
RNF01
A ferramenta deverá ser implementada seguindo os padrões
do Eclipse, no que diz respeito à interface gráfica.
Importante
RNF02
RNF03
RNF04
RNF05
A ferramenta deve ser construída no formato de plug-in para
o Eclipse
A ferramenta deverá disponibilizar, nos protótipos
desenvolvidos, um acesso intuitivo às regras de negócios
vinculadas pelo usuário
A ferramenta deverá sinalizar os componentes que possuem
associação com as regras de negócios
A ferramenta deverá permitir as anotações em protótipos
desenvolvidos em Swing do JAVA
Essencial
Essencial
Essencial
Essencial
Identificação
Tabela 04 – Requisitos funcionais
Descrição
A ferramenta deverá permitir que a associação das regras
Prioridade
RF01
de negócios seja realizada através de anotações nos
componentes do código fonte do protótipo em Swing do
JAVA
Essencial
RF02
A ferramenta deverá listar as regras de negócios por
projeto existente no Eclipse para auxiliar na anotação Importante
RF03
RF04
RF05
A ferramenta deverá permitir que o usuário desenvolvedor
do protótipo importe, para a ferramenta, as regras de
negócios por meio de arquivo (.xml)
A ferramenta deverá verificar se o arquivo importado
possui inconsistência na estrutura do XML , verificar se
possui campos não preenchidos e verificar se os tipos
estão corretos
A ferramenta deverá permitir que o desenvolvedor tenha a
opção de ativar ou desativar a inclusão das regras de
negócios nos protótipos anotados.
Essencial
Essencial
Essencial
26

5.2 – DIAGRAMA DE CASO DE USO.
A Figura 07 mostra os casos de uso identificados.
5.2.1 - Casos de uso.
Figura 07 – Caso de uso do projeto de criação da ferramenta
A Tabela 05 mostra os casos de uso.
27

Tabela 05 – Casos de uso relacionado aos requisitos
Identificação Descrição Requisito
UC001 Importar as regras de negócio RF03
UC002 Validar o padrão do arquivo RF04
UC003
Anotar as regras de negócios nos componentes do
protótipo
RF01
UC004 Configurar as propriedades do plug-in RF05
UC005 Listar regras de negócios RF02
UC006 Recuperar as regras de negócios RNF03/RNF04
Segue a especificação do caso de uso, detalhando as ações da ferramenta
construída neste projeto.
5.2.2 - Especificação do caso de uso.
Tabela 06 – Casos de uso UC001
Número do Caso de UC001
Uso
Nome do Caso de Importar as regras de negócio
Uso
Ator(es) Desenvolvedor
Descrição Este caso de uso tem como objetivo importar as
regras de negócios para um determinado projeto do
Eclipse, por meio de arquivo .xml
Pré-condições Ter a ferramenta Eclipse inicializada com o plug-in
Pós-condições Não se aplica
Fluxo principal 1 - O usuário deve selecionar um projeto para
associar o arquivo (EXC001).
2 - O usuário deve selecionar um arquivo no formato
XML (EXC001).
3 - A ferramenta verifica o arquivo: Ver caso de uso
UC002
Fluxo alternativo Não se aplica
Exceções EXC001 - Campos não preenchidos
Essa exceção indica que o campo não foi preenchido
corretamente.
28

Inclusão (includes) UC002
Extensões (extend) Não se aplica
Tabela 07 – Casos de uso UC002
Número do Caso de UC002
Uso
Nome do Caso de Validar o padrão do arquivo
Uso
Ator(es) Sistema
Descrição Este caso de uso tem como objetivo analisar a
estrutura do arquivo e verificar se existe alguma falha
de padrão.
Pré-condições Ter recebido o caminho do arquivo a importar e um
projeto de desenvolvimento do Eclipse
Pós-condições Não se aplica
Fluxo principal 1 - A classe de importação da ferramenta verifica se a
estrutura do XML no arquivo está de acordo com o
padrão especificado pela ferramenta. (EXC001)
2 - A classe de importação da ferramenta verifica se
os campos da estrutura do XML no arquivo não estão
preenchidos. (EXC002)
3 - A classe de importação da ferramenta verifica se o
tipo de dados está de acordo com o padrão
especificado na ferramenta. (EXC003)
Fluxo alternativo Não se aplica
Exceções EXC001 - Erro de estrutura
É exibido uma mensagem de erro, indicando a linha e
o que é esperado na estrutura do arquivo XML.
EXC002 - Erro de campos não preenchidos
É exibido uma mensagem de erro, indicando que o
campo do XML está vazio.
EXC003 - Erro de tipo de dados
É exibido uma mensagem de erro informando qual
campo está com problemas no tipo de dados
especificado.
Inclusão (includes) Não se aplica
Extensões (extend) Não se aplica
Número do Caso de
Uso
Nome do Caso de
Uso
Tabela 08 – Casos de uso UC003
UC003
Anotar as regras de negócios nos componentes do
protótipo
29

Ator(es) Desenvolvedor
Descrição Este caso de uso tem como objetivo anotar as regras
de negócios no componente do protótipo direto no
código fonte por meio de Annotation.
Pré-condições O protótipo tem que ser em Java com a utilização da
classe Swing
Pós-condições Não se aplica
Fluxo principal 1 - O desenvolvedor arrasta o objeto listado na visão
das regras de negócio e solta acima do componente
que deseja associar a regra.
2 – O sistema inclui o código do Annotation com o
identificador da regra de negócio.
Fluxo alternativo Não se aplica
Exceções Não se aplica
Inclusão (includes) Não se aplica
Extensões (extend) Não se aplica
Tabela 09 – Casos de uso UC004
Número do Caso de UC004
Uso
Nome do Caso de Configurar as propriedades do plug-in
Uso
Ator(es) Desenvolvedor
Descrição Este caso de uso tem como objetivo possibilitar o
usuário optar por compilar o protótipo com as regras
de negócios ou não.
Pré-condições Não se aplica
Pós-condições Não se aplica
Fluxo principal 1 - Selecionar um projeto do Eclipse
2 - Selecionar true para compilar as regras de
negócios ou false para não compilar as regras de
negócios no protótipo.
Fluxo alternativo Não se aplica
Exceções Não se aplica
Inclusão (includes) Não se aplica
Extensões (extend) Não se aplica
Tabela 10 – Casos de uso UC005
Número do Caso de UC005
Uso
Nome do Caso de Listar regras de negócios
Uso
Ator(es) Desenvolvedor
30

Descrição Este caso de uso tem como objetivo listar as regras
de negócios que estão vinculadas a um projeto do
Eclipse.
Pré-condições Ter a ferramenta Eclipse inicializada com o plug-in
Pós-condições Não se aplica
Fluxo principal 1 - O desenvolvedor seleciona a opção de mostrar a
visão de listagem das regras de negócio associadas
aos projetos.
Fluxo alternativo Não se aplica
Exceções Não se aplica
Inclusão (includes) Não se aplica
Extensões (extend) Não se aplica
Tabela 11 – Casos de uso UC006
Número do Caso de UC006
Uso
Nome do Caso de Recuperar as regras de negócios
Uso
Ator(es) Stakeholders
Descrição Este caso de uso tem como objetivo recuperar as
regras de negócio para serem visualizadas pelos
usuários.
Pré-condições Ter executado um protótipo com regras de negócios
anotadas em algum componente
Pós-condições Não se aplica
Fluxo principal 1 - O stakeholder seleciona com o click direito do
mouse um componente sinalizado em vermelho
2 - O protótipo recupera a regra de negócio associado
ao componente e disponibiliza em um formulário para
a visualização.
Fluxo alternativo Não se aplica
Exceções Não se aplica
Inclusão (includes) Não se aplica
Extensões (extend) Não se aplica
5.3 – ARQUITETURA DO PLUG-IN.
O plug-in desenvolvido neste projeto foi destinado para a ferramenta Eclipse que é
uma plataforma livre que possibilita o usuário construir ferramentas integráveis de
31

forma transparente para o ambiente de desenvolvimento. O Eclipse é uma
ferramenta construída sobre um núcleo, o Kernel de tempo de execução, e suas
funcionalidades todas elas desenvolvidas como plug-in. (GALLARDO, 2002)
O plug-in construído neste projeto depende de mais dois plug-ins que são os
Workbench e o Workspace. Esses dois componentes são indispensáveis para
plataforma do Eclipse, pois eles fornecem os pontos de extensões usados pela
maioria dos plug-ins. O Workbench possui as extensões ligadas à interface do
Eclipse como, por exemplo, a criação do menu e a tela que lista as regras de
negócios do plug-in desenvolvido no projeto. Já o Workspace possui as extensões
de recursos dos projetos existentes no Eclipse como, por exemplo, a listagem de
projetos que foi utilizado no plug-in desenvolvido no projeto. (GALLARDO, 2002)
A Figura 08 – mostra a dependência dos plug-ins no Eclipse.
Figura 08 – Estrutura de dependência de plug-in e bibliotecas
Neste caso o plug-in desenvolvido no projeto depende dos componentes Workbench
e o Workspace para utilizar dos recursos de interface e informações dos projetos
existentes no Eclipse.
32

5.4 – PROJETO DE DESENVOLVIMENTO.
No item a seguir mostra o diagrama de classe e a explicação das classes mais
relevantes deste projeto.
5.4.1 - Diagrama de Classe
A Figura 09 mostra o diagrama de classe da ferramenta proposta neste projeto.
Figura 09 – Diagrama de classes.
33

As classes e suas funcionalidades são:
BusinessRules – Classe responsável por armazenar um conjunto de regras de
negócio na ferramenta.
BusinessRulesXML – Classe responsável pela importação do arquivo XML para a
ferramenta.
Processor – Classe responsável por processar as anotações do código fonte dos
protótipos.
Facade - Classe responsável por estabelecer a interface da ferramenta com as
classes do plug-in.
BusinessRulesView – Classe responsável por criar a estrutura que lista as regras de
negócio na ferramenta Eclipse.
BusinessRulesProperties – Classe responsável pela interface que disponibiliza a
configuração do plug-in.
BusinessRulesImport – Classe responsável pela interface de entrada de dados para
realizar a importação do arquivo.
Handlers – Classe responsável por inicializar as interfaces do plug-in, quando o
evento no Eclipse é disparado.
As classes mais importantes do projeto são Processor, BusinessRulesXml. A classe
Processor é responsável por inserir um método template, que cria um formulário com
as informações da regra de negócio associado, no evento do componente em Swing
anotado. Essa anotação é feita pelo recurso disponibilizado na linguagem JAVA, o
Annotations. Já a classe BusinessRulesXml é responsável pela importação do
arquivo em XML, que utiliza os recursos da biblioteca JDom(Conjunto de funções
que ler e cria arquivos no formato XML). Nesta classe, BusinessRulesXml, também é
feita a verificação se os campos estão preenchidos corretamente. Os códigos fontes
dessas classes podem ser visualizados no APÊNDICE A.
34

5.4.2 - Arquivo plugin.xml
O arquivo plugin.xml é responsável por indicar para o Eclipse quais as
funcionalidades proposta pelo plug-in a ser criado. No caso deste projeto proposto, o
arquivo de plug-in.xml, por exemplo, foi criado uma Tag para inserir um novo Menu
contendo uma opção para iniciar a interface de importação do arquivo de regras de
negócio.
Como já explicado anteriormente no item 3 do capitulo 5 deste projeto, o Eclipse é
constituído de vários plug-ins, no trecho do código fonte acima a Tag Extension
indica a inclusão de um novo Menu na UI( user interface, interface usuário) do
Eclipse. No APÊNDICE B pode-se visualizar todo o código fonte do arquivo
plugin.xml utilizado neste projeto.
35

5.4.3 - Estrutura do arquivo de regras.
A estrutura de arquivo para importação que está sendo utilizado neste projeto foi
criado para atender as necessidades da ferramenta ABREP. O padrão criado foi
tomando como base o padrão de Gisele P Morgado. O padrão criado para a
ferramenta proposto neste projeto é uma estrutura simples que possui dois níveis de
hierarquia. (MORGADO, 2007)
No código fonte a seguir, é mostrado um exemplo contendo as regras de negócios e
sua estrutura.
-
-
Cadastro de Aluno
03/04/2010
1
Para cadastrar o aluno é necessario que ele esteja presente com os pais na hora
da matricula, portando Rg.
Antonio Carlos
-
+
+
+
+
-
Filhiação
03/04/2010
1
É necessário informar o nome, Rg e CPF do pai e da mãe, para que ele se torne o
responsável pelo aluno.
Antonio Carlos
36

+
Essa estrutura das tags é explicada na Tabela 12 a seguir:
Tabela 12 – Descrição das tags do arquivo de importação
Tag Descrição
Corpo principal, onde contem o conjunto de regras de negócio
A regra de negócio possui um identificar (Id) como atributo da
tag
Objetivo da regra de negócio
Data da criação da regra de negócio
Versão da regra de negócio
Descrição dos detalhes da regra de negócio
O autor da regra de negócio
Sub conjuntos de regras de negócio dependentes
5.5 - FERRAMENTA.
A ferramenta foi desenvolvida para o Eclipse Galileo na versão 3.5.2. Para a
utilização da ferramenta proposta neste projeto é necessário que se copie o arquivo
org.businessRules_1.0.0.201006061526.jar para pasta plugins dentro do Eclipse,
geralmente o endereço da pasta fica localizado no endereço “C:\Arquivos de
programas\eclipse\plugins\”. Para poder processar as anotações é necessário
também incluir um biblioteca (BusinessRuleAnnotations.jar) no projeto que contem o
protótipo a ser desenvolvido. A Figura 10 mostra a adição da biblioteca no projeto.
37

Figura 10 – Adicionando a biblioteca (BusinessRuleAnnotations.jar) ao projeto.
5.5.1 - Uso da ferramenta.
Seguindo como exemplo o sistema de escola, para a utilização da ferramenta
proposta neste projeto, dentro da ferramenta do Eclipse, após a criação de um
projeto em Java, no exemplo utilizado “SistemaEscolar”, o desenvolvedor tem a
opção de importar as regras de negócio para o Eclipse. Conforme a Figura 11:
38

Figura 11 – Tela de importação da regra de negócio.
Para importar as regras como a Figura 12, é necessário escolher um arquivo no
formato XML e escolher um projeto para associar as regras. No campo Status serão
exibidas as mensagens do processo de importação. Essas mensagens são de
confirmação da importação ou de erro de tipagem de dados, formatação do arquivo
XML ou quando o campo no arquivo não está preenchido.
Durante a criação do protótipo o desenvolvedor tem a opção de listar as regras de
negócios para ajudar no processo de anotação aos componentes do protótipo. Para
mandar exibir a visão que lista as regras, o desenvolvedor tem que escolher na
opção de visões na janela e escolher a opção de visões do Business Rules.
Figura 12 – Tela que lista as regras de negócio associados ao projeto.
39

Para a utilização da técnica proposta neste projeto, o desenvolvedor terá que
realizar três procedimentos para realizar toda a anotação das regras de negócios
nos componentes dos protótipos desenvolvidos em Swing. O primeiro procedimento,
o desenvolvedor deverá anotar a classe que utilizará as regras de negócio passando
como parâmetro o nome do projeto. A Figura 13 mostra um exemplo de anotação da
classe com o projeto de “SistemaEscolar”.
Figura 13 – Anotação da classe para poder anotar as regras de negócio nos componentes.
Existem duas possibilidades de realizar a anotação da classe, a primeira, o
desenvolvedor digita o comando “@BusinessRulesProject
(Project=”SistemaEscolar")” , a segunda forma, é arrastar da listagem da regra de
negócio o projeto para o código fonte do protótipo.
O segundo procedimento é a realização das anotações dos componentes com o
identificador da regra de negócio. A Figura 14 mostra a anotação de uma regra em
um componente do protótipo.
40

Figura 14 – Anotação da regra de negócios no componente jButton.
Conforme visto no procedimento anterior, também pode-se arrastar da listagem das
regras de negócio para o código fonte do protótipo desenvolvido.
O terceiro procedimento é a inclusão de um método estático para processar as
anotações incluídas no código fonte do protótipo passando como parâmetro a classe
que contém os componentes. Utilizando os conceitos de reflexão (Reflection) e de
invocar (Invoke) é realizado a inclusão das regras de negócio nos protótipos para
posteriormente ser recuperados.
Para a recuperação das regras de negócio no protótipo, durante a execução do
mesmo, basta clicar com o botão direito do mouse os componentes sinalizados. O
desenvolvedor tem a possibilidade e optar por incluir as regras no protótipo ou não,
indo em Properties (Propriedades) do BusinessRules do Eclipse.
A Figura 15 mostra a tela que recupera as regras de negócio após o evento do botão
do mouse.
41

5.5.2 - Avaliação da ferramenta.
Figura 15 – Recuperação da regra de negócio.
Para a avaliação da ferramenta foi dedicado aproximadamente 20 horas de teste
para avaliar a sua estabilidade e usabilidade. A ferramenta durante todo o teste
apresentou-se estável e não foi constatado falhas durante sua execução. Durante a
recuperação das regras de negócios, todos os protótipos testados no exemplo do
sistema para escola, utilizado neste projeto, não demonstraram erros na
recuperação e continuaram estáveis. A utilização dos conceitos de Drag-And-Drop
(Arrastar e soltar), utilizados para ajudar na anotação, contribuiu para o
desenvolvedor e diminuiu os riscos de associações indevidas melhorando a
usabilidade da ferramenta.
Durante a inclusão do método estático para processar as anotações, foi encontrado
uma dificuldade, por que é necessário passar como parâmetro toda a classe que
contem os componentes instanciados e já configurados para a sua visualização o
que dificulta a usabilidade da ferramenta.
Os procedimentos de anotações e recuperações das regras de negócio foram bem
sucedidos em todos os componentes da classe Swing.
42

Existem alguns pontos da ferramenta passiveis de melhoria, principalmente a parte
da utilização do Annotaions, transformando o processamento das anotações em
plug-in, o que diminuiria a dificuldade de incluir o método estático no protótipo e
diminuiria a dependência dos protótipos a ferramenta. Outro ponto que necessita de
melhorias é do evento do mouse que recupera as informações das regras de
negócio, que atualmente só é realizado com o click do botão direito do mouse, o que
impossibilita o sistema de utilizar o evento no protótipo enquanto as regras estão
sendo recuperadas.
43

CONCLUSÃO.
Normalmente os requisitos são derivados das regras de negócio que compõem o
software. Durante a construção de um software, é de fundamental importância o
levantamento dos requisitos do sistema para a construção de um software bem
sucedido. A utilização da ferramenta protótipo auxilia de forma bastante positiva,
quando bem utilizado, a atividade de levantamento de requisitos.
O objetivo deste projeto foi apresentar uma forma prática de associação entre as
regras de negócios e os protótipos evolutivos. Para isso foi desenvolvido uma
ferramenta em formato de plug-in para o Eclipse que permite ao desenvolvedor
anotar as regras de negócio nos componentes dos protótipos construídos em Swing
da linguagem JAVA. Posteriormente durante a utilização desses protótipos, é
possível de forma bastante intuitiva, a recuperação das informações das regras de
negócio. Essas recuperações auxiliam bastante os stakeholders, onde a
visualização das regras de negócios facilita o entendimento da solução proposta no
protótipo e as necessidades que os stakeholders levantaram.
A pesquisa mostrou que existem outras formas de se recuperar as informações
durante o uso dos protótipos, porém essas formas de recuperação não foram
consideradas eficazes na utilização dos protótipos evolutivos e foram consideradas
também dispendiosas. Para isso a pesquisa foi realizada, tomado como base os
aspectos dos processos da engenharia de requisito e a prototipação de software.
Ainda em relação à pesquisa percebeu-se que a inclusão das regras de negócio no
código fonte dos protótipos seria uma forma eficaz de recuperar as informações das
regras de negócio.
As dificuldades encontradas neste projeto foram, a busca pela documentação dos
recursos do Eclipse para a construção do plug-in, e a dificuldade da construção do
referencial teórico sobre as Regras de Negócios.
44

Os estudos realizados neste projeto levam a conclusão de que essa forma de
associação e recuperação das regras de negócio pode ser utilizada no processo de
levantamento de requisitos e prototipação, da Engenharia Software, porém com
base nos próprios estudos, essa forma pode ser mais indicada na construção de um
software baseado nas metodologias ágeis.
O projeto de construção da ferramenta ABREP para ser encontrado no SourceForge
(Site que permite ao usuário disponibilizar o código fonte de um determinado projeto
com o intuito de contribuir com a comunidade para conhecimento, aprendizado e
aperfeiçoamento da tecnicas e metodologias utilizadas nos ambientes da Tecnologia
da Informação.), uma vez que a ferramenta é Open Sorce (ferramenta de código
livre) e não possui custos de licença nem na utilização e nem na criação.
Para trabalhos futuros são sugeridos a continuação da pesquisa das anotações em
componentes web (jsf), a integração da ferramenta para o NetBeans no formato de
plug-in, realização de teste mais aprofundados e o estudo da viabilidade da
utilização da ferramenta.
45

REFERÊNCIAS
ARNOWITZ, Jonathan; ARENT, Michael; BERGER, Nevin. Effective Prototyping
for Software Makers. São Paulo: Morgan Kaufmann, 2006.
BRG. Defining Business Rules ~ What Are They Really? 4th ed.
(July 2000). Disponível na internet.
http://www.businessrulesgroup.org. 08 mai. 2010.
GALLARDO, David. Desenvolvendo Plug-ins do Eclipse. 2002. Disponível na
internet. http://www.ibm.com/developerworks/br/library/os-ecplug/. 20 mai. 2010
KOTONYA, Gerald ; SOMMERVILLE, Ian. “Requirements Engineering”. Wiley,
1998.
MORGADO, Gisele P; et al. Práticas do CMMI® como regras de negócio. In:
PRODUÇÃO, v. 17, n. 2, p. 383-394, Rio de Janeiro, RJ, Maio/Ago, 2007.
FILHO, Wilson de Pádua Paula. Engenharia de Software; fundamentos, métodos
e padrões 2ª Edição. Rio de Janeiro: LTC, 2003.
PETERS, James. F; ET al. Engenharia de Software. Tradução Ana Patrícia Garcia.
Rio de Janeiro: Campus, 2001.
PRESSMAN, Roger S. Engenharia de Software 6ª Edição. São Paulo: McGraw-
Hill. 2006.
SOMMERVILLE, Ian. Engenharia de Software, 6ª Edição. São Paulo: Pearso
Addison-Wesley, 2004.
SOMMERVILLE, Ian. Engenharia de Software, 8ª Edição. São Paulo: Pearso
Addison-Wesley, 2007.
VON HALLE, Barbara. Business rules applied : building better systems using
the business rules approach. New York: John Wiley & Sons, 2002.
ZSIFKOV, N; CAMPEANU, R. Business Rules Domains and Business Rules
Modeling. Las Vegas, Nevada 2004.172-177p. Dissertação In: INTERNATIONAL
46

SYMPOSIUM ON INFORMATION AND COMMUNICATION TECHNOLOGIES
(ISICT), Trinity College Dublin.
47

APÊNDICE A
Código fonte da classe Processor.
public class Processor
{
/**
Processes all ActionListenerFor annotations in the given object.
@param obj an object whose methods may have ActionListenerFor annotations
* @throws NoSuchMethodException
* @throws SecurityException
*/
public static void processorAnnotations(Object obj)
{
try
{
Class

}
public static void addCollor(Object source) throws SecurityException,
NoSuchMethodException, IllegalArgumentException, IllegalAccessException,
InvocationTargetException
{
Class

Object listener = Proxy.newProxyInstance(null, new Class[] {
java.awt.event.ActionListener.class }, handler);
//Method adder = source.getClass().getMethod("addActionListener",
ActionListener.class);
Object listener = Proxy.newProxyInstance(null, new Class[] {
java.awt.event.MouseListener.class }, handler);
Method adder = source.getClass().getMethod("addMouseListener",
MouseListener.class);
adder.invoke(source, listener);
}
}
Código fonte da classe BusinessRulesXml.
public class BusinessRulesXml{
public BusinessRulesXml(){}
public Boolean saveData(Iterator i, FileWriter file)
{
Element businessRulesXml = new Element("BusinessRules");
while(i.hasNext())
{
BusinessRule br = i.next();
Element businessRule = new Element("BusinessRule");
Element objective = new Element("Objective");
Element creationDate = new Element("CreationDate");
Element version = new Element("Version");
Element description = new Element("Description");
Element author = new Element("Author");
Element groupBusinessRule = new
Element("BusinessRulesGroup");
businessRule.setAttribute("id", br.getId());
objective.setText(br.getObjective());
creationDate.setText(br.getCreationDate());
version.setText(br.getVersion().toString());
description.setText(br.getDescription());
author.setText(br.getAuthor());
businessRule.addContent(objective);
businessRule.addContent(creationDate);
businessRule.addContent(version);
businessRule.addContent(description);
businessRule.addContent(author);
Iterator iChildren =
br.getGrouptBusinessRule();
while(iChildren.hasNext())
{
BusinessRule brChildren = iChildren.next();
50

Element("BusinessRule");
Element("Objective");
Element("CreationDate");
Element("Version");
Element("Description");
Element("Author");
brChildren.getId());
Element businessRuleChildren = new
Element objectiveChildren = new
Element creationDateChildren = new
Element versionChildren = new
Element descriptionChildren = new
Element authorChildren = new
businessRuleChildren.setAttribute("id",
objectiveChildren.setText(brChildren.getObjective());
creationDateChildren.setText(brChildren.getCreationDate());
versionChildren.setText(brChildren.getVersion().toString());
descriptionChildren.setText(brChildren.getDescription());
authorChildren.setText(brChildren.getAuthor());
businessRuleChildren.addContent(objectiveChildren);
businessRuleChildren.addContent(creationDateChildren);
businessRuleChildren.addContent(versionChildren);
businessRuleChildren.addContent(descriptionChildren);
businessRuleChildren.addContent(authorChildren);
groupBusinessRule.addContent(businessRuleChildren);
}
businessRule.addContent(groupBusinessRule);
}
try
{
businessRulesXml.addContent(businessRule);
Document doc = new Document();
doc.setRootElement(businessRulesXml);
XMLOutputter xout = new XMLOutputter();
Format formatXML = org.jdom.output.Format.getPrettyFormat();
formatXML.setEncoding("ISO-8859-1");
xout.setFormat(formatXML);
xout.output(doc, file);
return true;
}
catch(Exception e)
{
51

}
}
return false;
public void loadData(File file) throws JDOMException, IOException,
Exception
{
Element businessRulesXml = new Element("BusinessRules");
SAXBuilder sb = new SAXBuilder();
Document d = sb.build(file);
businessRulesXml = d.getRootElement();
List elements = businessRulesXml.getChildren();
Iterator i = elements.iterator();
while(i.hasNext())
{
Element element = (Element)i.next();
String id = element.getAttributeValue("id");
if(id.isEmpty()) throw new Exception("Fild Id is
empyt : " + element.getText());
String objective =
element.getChildText("Objective");
if(objective.isEmpty()) throw new Exception("Fild
Objective is empyt : " + element.getText());
String creationDate =
element.getChildText("CreationDate");
if(creationDate.isEmpty()) throw new
Exception("Fild CreationDate is empyt : " + element.getText());
DateFormat dateFormat = new
SimpleDateFormat("dd/MM/yyyy");
try
{
Date creationDateTest =
dateFormat.parse(creationDate);
creationDate =
dateFormat.format(creationDateTest);
} catch (ParseException e)
{
throw new Exception("Data in wrong
format : " + e.getMessage());
}
String version = element.getChildText("Version");
if(version.isEmpty()) throw new Exception("Fild
Version is empyt : " + element.getText());
String description =
element.getChildText("Description");
if(description.isEmpty()) throw new Exception("Fild
Description is empyt : " + element.getText());
String author = element.getChildText("Author");
if(author.isEmpty()) throw new Exception("Fild
Author is empyt : " + element.getText());
52

BusinessRule br = new BusinessRule(id, objective,
creationDate, Integer.parseInt(version), description, author);
Element elementsGroup =
element.getChild("BusinessRulesGroup");
List elementsChildren =
elementsGroup.getChildren("BusinessRule");
Iterator iChildren =
elementsChildren.iterator();
(Element)iChildren.next();
while(iChildren.hasNext())
{
Element elementChildren =
String idChildren =
elementChildren.getAttributeValue("id");
String objectiveChildren =
elementChildren.getChildText("Objective");
String creationDateChildren =
elementChildren.getChildText("CreationDate");
String versionChildren =
elementChildren.getChildText("Version");
String descriptionChildren =
elementChildren.getChildText("Description");
String authorChildren =
elementChildren.getChildText("Author");
BusinessRule brChildren = new
BusinessRule(idChildren, objectiveChildren, creationDateChildren,
Integer.parseInt(versionChildren), descriptionChildren, authorChildren);
br.addWithinGroupBusinessRule(brChildren);
}
}
}
BusinessRules.getInstance().addBusinessRule(br);
public Boolean saveProperties(Boolean properties, FileWriter file)
{
Element propertiesElement = new Element("Properties");
Element runBusinessRulesElement = new
Element("RunBusinessRules");
runBusinessRulesElement.setText(properties.toString());
propertiesElement.addContent(runBusinessRulesElement);
try
{
Document doc = new Document();
doc.setRootElement(propertiesElement);
XMLOutputter xout = new XMLOutputter();
Format formatXML = org.jdom.output.Format.getPrettyFormat();
formatXML.setEncoding("ISO-8859-1");
xout.setFormat(formatXML);
53

}
xout.output(doc, file);
return true;
}
catch(Exception e)
{
return false;
}
public Boolean loadProperties(File file) throws JDOMException,
IOException, Exception
{
Element propertiesElement = new Element("Properties");
SAXBuilder sb = new SAXBuilder();
Document d = sb.build(file);
propertiesElement = d.getRootElement();
String properties =
propertiesElement.getChildText("RunBusinessRules");
}
}
return Boolean.parseBoolean(properties);
54

APÊNDICE B
Estrutura do arquivo plugin.xml
55

56

57