A Method for Generation of Tests Instances of Models from Business Rules Expressed in OCL

Abstract— In this paper proposes a method for the generation of tests instances from business rules of a system, expressed using OCL. The aim of this method is to give one a better support for test activities like, for example, the generation of tests instances to test models in the initial phases of the software development lifecycle, showing the inconsistencies and ambiguities in earlier in the project. A differential of this method, compared to others with similar intention, is that, beyond the generation of the test cases, the generated tests could be validated and be followed in an automatized way through the USE tool. To help in the execution of the proposed method, the TestiMonium tool was implemented and integrated to the environment. Keywords—Software Testing, Model Based Test Generation,

UML, OCL.

I. INTRODUÇÃO

ODE-SE considerar que o principal objetivo da realização de testes é antever problemas. Por este motivo, a atividade

de testes torna-se indispensável para garantir a qualidade de um sistema. Um dos principais problemas da área de testes está relacionado à geração e execução das instâncias de testes [1]. À medida que a complexidade e tamanho dos sistemas crescem, necessita-se de uma demanda maior de tempo e esforço para os testes. Além disso, gerar instâncias de testes de forma manual requer muito tempo e elas podem estar sujeitas a erros. Portanto, é necessário investir na geração automática de instâncias de testes.

Independentemente do processo de desenvolvimento utilizado na indústria, seja um processo formal baseado no RUP (Rational Unified Process) [2] ou informal baseado em metodologias ágeis [3] com ou sem TDD (Test Driven Development) [4], os testes assumem um importante papel como indicadores de qualidade funcional mínima do produto a ser entregue [1]. É a realização de uma ou várias baterias de testes que atesta a confiabilidade do produto em termos funcionais. Não negligenciando, porém, que um conceito mais geral de qualidade engloba um conjunto bem maior de requisitos (i.e.: documentação clara, adequação a padrões e facilidade de manutenção de código, etc.).

Este trabalho tem como objetivo facilitar a geração de instâncias de casos de testes a partir de modelos que sejam expressivos e incluam um certo grau de formalização das E. M. Bizerra JR, Universidade de Pernambuco (UPE), Recife, Pernambuco, Brasil, [email protected]

D. S. Silveira, Universidade Federal de Pernambuco (UFPE), Recife, Pernambuco, Brasil, [email protected]

M. L. P. M. Cruz, Universidade de Pernambuco (UPE), Recife, Pernambuco, Brasil, [email protected]

F. J. A. Wanderley, Universidade de Pernambuco (UPE), Recife, Pernambuco, Brasil, [email protected]

regras de negócio; para isso, este artigo propõe um método para geração dessas instâncias a partir do modelo conceitual de informação, que deve conter as regras de negócios expressas em OCL (Object Constraint Language), adotada em 1997 pelo OMG (Object Management Group). A OCL é uma linguagem de expressões para especificar restrições sobre modelos orientados a objetos ou outros artefatos da linguagem UML (Unified Modeling Language), como forma de complementar a parte gráfica dos modelos. A OCL permite descrever restrições, que não conseguem ser diagramaticamente representadas; a OCL é uma linguagem precisa, textual e formal [6]. Uma das suas principais características é que seu uso não exige um forte conhecimento matemático, como ocorre nos modelos Z [7] e VDM (Vienna Development Method) [8].

O problema de encontrar inconsistências em regras de negócio expressas em OCL é equivalente ao problema de encontrar inconsistências (contradições) em modelos baseados na lógica de primeira ordem. Este problema, por sua vez, cai na classe dos problemas indecidíveis [9]. Sendo assim, optamos por propor um método para gerar uma amostra de instâncias para casos de testes.

O método aqui apresentado está dividido nas seguintes etapas: i) identificar os parâmetros nas expressões em OCL e seus respectivos tipos no modelo conceitual de informação; ii) geração de valores para os parâmetros identificados na etapa anterior; e, iii) geração de casos de teste propriamente dita. Além do método, este artigo apresenta a ferramenta TestiMonium que dá suporte ao método, fornecendo apoio automatizado em todas as suas etapas.

Apesar de na literatura existirem vários trabalhos na área, que tem como objetivo facilitar o processo de testes derivando os casos de testes a partir de modelos [10,11,12,13,14], a maioria não usa uma formalização para as regras de negócio. Além disso, um diferencial do método proposto é que os testes gerados poderão ser integrados e validados da geração de script para o ambiente USE (UML-Based Specification Environment), [15] que é uma ferramenta que suporta a verificação de um modelo de projeto orientado a objetos.

Este artigo se encontra estruturado da seguinte forma: a Seção 2 apresenta um referencial teórico sobre os principais tópicos relacionados a este trabalho; na Seção 3 o método proposto é descrito; na Seção 4 um fragmento de um experimento para o método é apresentado; a Seção 5 descreve alguns trabalhos relacionados. Por fim, a Seção 6 apresenta as conclusões e perspectivas futuras deste trabalho.

E. M. Bizerra JR, D. S. Silveira, M. L. P. M. Cruz and F. J. A. Wanderley

A Method for Generation of Tests Instances of Models from Business Rules Expressed in OCL

P

IEEE LATIN AMERICA TRANSACTIONS, VOL. 10, NO. 5, SEPTEMBER 2012 2105

II. REFERENCIAL TEÓRICO

O IEEE Glossary of Software Engineering Terminology [27] define teste software como sendo o processo de operar um sistema ou um componente sobre as condições especificadas, observando ou gravando os resultados, e fazendo uma evolução de alguns aspectos do sistema ou componente. As condições especificadas, citadas pela definição, fazem parte dos casos de teste que auxiliam a execução dos testes.

Um caso de teste consiste em um conjunto de dados de testes, condições de execução e resultados esperados para um objetivo de teste específico [1,16]. Os casos de testes serão bem sucedidos se os mesmos elevam a probabilidade de detecção de erros, bem como que um teste bem sucedido é aquele que aponta falhas ainda não foram constatadas [1].

Embora a qualidade do sistema vá além dos testes realizados, os testes representam um importante passo que ajuda a garantir que o produto final atenderá aos requisitos existentes durante a sua concepção [1]. Nas próximas subseções são apresentados os conceitos necessários para a compreensão do método de geração de testes proposta neste artigo. Incialmente são descritas brevemente técnicas de teste, sendo em seguida descritos conceitos de OCL, e por fim o ambiente de especificação USE, que neste artigo é enriquecido com uma forma de geração automática de combinação de instâncias concretas de teste (baseado no método proposto).

A. Técnicas de Teste

As técnicas de testes servem como base para gerar as instâncias para os casos de testes. As técnicas de testes mais conhecidas são: funcional e estrutural [1]. A diferença entre elas está na fonte de informação usada para avaliar ou construir o conjunto de instâncias. Porém, nenhuma dessas técnicas é completa o suficiente para garantir a qualidade dos testes. Como este trabalho se baseia na técnica caixa preta, ela será detalhada a seguir.

Na técnica de caixa preta, as entradas são fornecidas e suas saídas são verificadas de acordo com o comportamento especificado. Como o teste funcional ignora a estrutura interna, a atenção volta-se para o domínio das informações. Alguns critérios de teste funcional são descritos a seguir, conforme apresentado em [1]:

• Particionamento de Equivalência: este critério divide o domínio de entrada do sistema em classes de equivalência válidas e inválidas e supõe que se um elemento de uma classe provocar a falha de um teste, todos os demais membros da classe também provocarão falhas. O contrário também é válido, se um elemento de entrada resulta num teste bem sucedido, então os outros elementos da mesma classe também o serão. O uso deste critério permite restringir o número de casos de teste necessários.

• Análise do Valor Limite: este critério complementa o particionamento de equivalência. Ele é usado, pois uma grande quantidade de erros geralmente ocorre nas fronteiras do domínio de entrada [1]. Com isso, a

técnica de análise de valor limite, ao invés de selecionar um elemento qualquer de uma classe de equivalência, seleciona elementos que atuam nas extremidades das variáveis [17].

B. A Linguagem de Restrições da UML – A OCL

A UML é um dos mais importantes padrões mantidos pelo OMG [5] para criar modelos que permitem documentar e visualizar os artefatos que são especificados e construídos durante as fases de análise e projeto de um sistema. Embora a UML ofereça um grande número de diagramas que possibilitam a construção de visões estáticas e dinâmicas de um sistema, eles não são suficientes para descrever todas as restrições que compõem um software. Algumas regras de negócio e definições contratuais de operações são exemplos de informações que não são cobertas por esses diagramas, e que demandam uma especificação mais precisa [18].

Freqüentemente, as regras de negócio são descritas em linguagem natural. Entretanto, especificações produzidas em linguagem natural estão intrinsecamente ligadas a problemas de ambigüidade. O emprego de uma linguagem mais formal na especificação dessas regras é uma alternativa natural para lidar com a questão da ambigüidade, que abre várias possibilidades de apoio automatizado ao longo do processo de desenvolvimento [19].

A OCL permite uma definição precisa desse tipo de regras em modelos descritos através da UML. Porém, essas regras quando especificadas em OCL se apresentam como expressões declarativas e sem efeitos colaterais. Declarativas, pois representam o que se pode fazer e não como deve ser feito, e sem efeitos colaterais significa que a avaliação de uma expressão nunca muda o estado dos objetos [6,19].

As expressões OCL permitem escrever restrições – regras de negócio – no comportamento dos objetos (entidades do mundo real) através de invariantes (inv), pré e pós-condições (pre e post) [6]. Essas restrições escritas em OCL devem ser associadas a um classificador do modelo UML, ou seja, uma classe, ação, transição, indicando que o seu resultado deve ser verdadeiro para todas as instâncias do referido elemento em qualquer instante do tempo. Porém, outros autores [15,19,28] sugerem uma interpretação menos rígida, definindo uma restrição em OCL como um predicado que deve ser verdadeiro em qualquer instante de tempo, como por exemplo, em uma fotografia instantânea (snapshot) dos objetos do modelo, isto é, nos momentos anterior e posterior a qualquer ação do modelo.

C. O Ambiente de Especificação USE

O ambiente USE é um ambiente para a especificação de Sistemas de Informação, onde é possível especificar o modelo conceitual de informação [15]. O modelo conceitual de informação representa os objetos, suas características e seus relacionamentos, independentemente do uso de técnicas de implementação, tecnologias ou dispositivos físicos [20]. A notação utilizada para a definição do modelo conceitual de informação no ambiente USE é a do Diagrama de Classes da UML. Este modelo deve ser anotado com as regras de negócio

2106 IEEE LATIN AMERICA TRANSACTIONS, VOL. 10, NO. 5, SEPTEMBER 2012

estruturais, que são definidas no contexto de especificações OCL [15].

Dentro deste contexto, a ferramenta USE oferece apoio à validação de modelos através de recursos de animação. Essa validação é realizada através animação dos objetos instanciados do modelo conceitual. A animação é uma técnica de validação baseada na execução de modelos, de modo semelhante à técnica de prototipação, com a diferença de que nenhuma tradução manual da especificação é realizada de modo a permitir a sua execução [19].

Mas, para executar a animação a definição das classes é especificada em uma linguagem textual própria da ferramenta. Além da verificação sintática e de tipos, a ferramenta possui um módulo onde o projetista pode modificar o estado do sistema criando ou destruindo objetos, criando ou destruindo associações entre objetos, ou ainda, mudando os valores de atributos de objetos. Essas modificações são realizadas de forma interativa através de comandos escritos em uma linguagem de script do ambiente.

A ferramenta USE permite, ainda, que essas modificações do estado do sistema possam ser feitas dentro de uma operação, simulando mudanças geradas pela sua execução. Ao final dessa execução simulada, todas as pós-condições da operação são verificadas. O USE informa o estado de cada pós-condição, e caso alguma não tenha sido atendida, o projetista pode solicitar a exibição do estado de certos objetos do sistema, de modo a facilitar a investigação dos motivos que causaram a falha.

No contexto da modelagem de conceitual de informação, este ambiente, se munido de boas instâncias de teste, pode dar a chance aos projetistas de interagirem com o modelo e observar o seu comportamento operacional. Além disso, a técnica de animação permite aos envolvidos, através de exploração das instâncias concretas de testes e da observação dos efeitos produzidos, aumentarem a confiança de que o modelo reflete corretamente a sua intenção original.

III. O MÉTODO

O método aqui proposto e apresentado tem como objetivo a geração automática das instâncias dos casos de teste, chamados de cenários de teste, utilizando os critérios de particionamento de equivalência e análise do valor limite da técnica de teste funcional.

No entanto, este método pode facilmente interoperar com qualquer outra técnica ou método que forneça as entradas exigidas pela ferramenta que automatiza o método, estando no formato XMI (XML Metadata Interchange) que é um padrão baseado em XML (eXtensible Markup Language).

A Fig. 1 ilustra as quatro principais etapas do método com as suas entradas e saídas. A saber: a) Transformar o diagrama de classes e as suas restrições (regras de negócio) expressas em OCL – elementos de entrada para o método – em uma estrutura interna; b) Identificar todos os parâmetros das expressões OCL; c) Gerar valores para cada parâmetro; d) Combinar todos os valores possíveis para a geração dos cenários de testes.

Figura 1. O Fluxo do Método Proposto.

A seguir as etapas do método são detalhadas.

A. Transformação do Diagrama de Classe e das Expressões em OCL na Estrutura Interna

Os modelos fornecidos são transformados em uma estrutura interna (lista de objetos), que representa uma versão simplificada do metamodelo do diagrama de classes da UML (Fig. 2) [5], a partir do qual serão aplicadas as regras de que darão origem as instâncias.

ModelElement

#name

Classifier Feature Parameter

Class DataType Attribute Operation

OCLExpression

-features

1 1..*

-type

0..*1

-specializations

-generalizations

0..*

0..*

-parameters0..*

1

-context

-definitions

0..1

0..*

-context

-derivationRule

0..10..1 -context

-initialValue

0..1

0..1

-postconditions

-context

0..*

0..1

-preconditions

-context

0..*

0..1 Figura 2. O Fragmento do Meta-Modelo da UML Implementado na Ferramenta que Automatiza o Método.

Para realizar essa transformação, os modelos fornecidos ao método proposto, no caso o diagrama de classe e as restrições em expressas em OCL, são analisados e à medida que os elementos vão sendo identificados eles são mapeados em suas classes correspondentes no diagrama apresentado na Fig. 2. A Tabela I apresenta os elementos de entrada e suas classes correspondentes no modelo proposto.

TABELA I

ELEMENTOS DE ENTRADA E SUAS CLASSES CORRESPONDENTES NO MODELO.

Elemento Formato XMI Classe

Classe <element type="TObjClasse"> <name>Carro</name> </element>

Class

Atributo <attribute visibility="1" type="STRING"> <name>placa</name> </attribute>

Attribute

Tipo do

Atributo

<attribute visibility="1" type="STRING"> <name>placa</name> </attribute>

DataType

Pré-

condição pre: paramDataAluguel >= Data::now

OCLExpression

Pós-

condição post: grupo->select(g | g.nome = paramGrupo)->size() = 1

OCLExpression

MENDES BIZERRA et al.: A METHOD FOR GENERATION 2107

No final desta etapa, teremos todos os elementos transformados na sua respectiva classe do modelo, que será utilizado pela ferramenta para a geração dos cenários de teste.

B. Identificação dos Parâmetros nas Restrições Expressas em OCL e seus Tipos

Para a identificação dos parâmetros nas expressões OCL foram utilizados gabaritos (templates) definidos de acordo com a sintaxe da OCL. Um gabarito é um modelo parametrizado responsável por especificar os elementos participantes de um modelo. Na estratégia utilizando gabaritos [21], um conjunto de marcas é associado a um gabarito para indicar como as instâncias de um modelo devem ser transformadas.

Na Fig. 5 pode ser observada a marca <param>, usada para identificar os parâmetros de entrada das expressões OCL. O método proposto gera os valores de entrada para esses parâmetros. Por exemplo, na expressão OCL da linha 001 da figura são identificados os parâmetro de entrada paramClienteCNH, paramClienteIdade e paramClienteTempoCNH. Após identificar os parâmetros, o nome do atributo é extraído desconsiderando a marca param do parâmetro. Neste caso, desconsiderando param do parâmetro paramClienteCNH, temos o atributo ClienteCNH. Depois disso, o paramClienteCNH deve ser associado a algum atributo das classes do modelo conceitual de informação. Essa associação é necessária para identificar o tipo primitivo desse parâmetro (Boolean, Integer, Real e String).

C. Geração de Valores para os Parâmetros

Após a identificação dos tipos para os parâmetros de entrada das expressões OCLs, ocorre à geração dos valores de acordo com os tipos seguindo os critérios: a) Tipo String: Será gerado um valor válido e um valor nulo (null); b) Tipo numérico: Caso exista alguma restrição de valor nas expressões OCLs será adotado os critérios de particionamento de equivalência com a análise de valor limite. Caso não exista nenhuma restrição serão gerados três valores aleatórios: um positivo, um negativo e um nulo; c) Tipo Date: Assim como o tipo numérico, caso seja encontrado alguma restrição os critérios de particionamento de equivalência e o de análise do valor limite serão empregados. No caso de não ocorrer nenhuma restrição, uma data válida e uma inválida serão geradas; e d) Tipo Booleano: Será gerado um valor verdadeiro (true) e outro falso (false).

D. Geração das Instâncias

Para a geração das instâncias de teste foi implementado um algoritmo (Fig. 3), para fazer o produto cartesiano dos conjuntos dos valores gerados na etapa anterior.

1. Combinação_Valores (M[n,m]) 2. Entrada 3. M[n,m] : matriz de valores; 4. Variáveis Locais 5. numComb, ind, i, j, k : inteiro; 6. result[n,m] : matriz de valores; 7. Início 8. numComb ← 1; 9. Para i de 1 até M.count Faça 10. numComb ← numComb * M[i].count;

11. Próximo i 12. Para i de 1 até numComb Faça 13. j ← 1; 14. Para k de 1 até M.count Faça 15. ind ← (i / j) mod M[k].count; // mod equivale ao // resto da divisão. 16. result[i][k] ← M[k][ind]; 17. j ← j * M[k].count; 18. Próximo k 19. Próximo i 20. Fim.

Figura 3. Algoritmo de Combinação.

Por meio da combinação de valores, cada instância de teste gerada contém um valor diferente das outras instâncias. Mas, fica a cargo do projetista selecionar quais valores dos parâmetros do modelo serão usados nas instâncias. Além disso, sobre a quantidade de instâncias de casos de teste, é possível observar que dependendo da quantidade de variáveis a ser avaliada, poderá ocorrer uma “explosão combinatorial” de possibilidades. Essa situação foi minimizada na ferramenta através da possibilidade de definição de faixas de valores (para os tipos numéricos e o tipo Date) e pela geração ou não de valores zeros ou nulos. Com isso, o projetista pode optar pela geração de alguns valores dependendo do negócio em questão, esperando, desta maneira, que uma menor quantidade de instâncias de testes seja gerada.

IV. VALIDANDO O MÉTODO

O método proposto foi validado através de estudos de caso controlados. Entre eles destacou-se o que foi extraído do trabalho de [19], referente a uma Locadora de Veículos (EURent idealizado pelo Business Rules Group – BRG [22]). Nele optou-se por detalhar um dos principais processos de negócio: o aluguel de veículos (sem reserva). A Fig. 4 ilustra um fragmento do modelo conceitual usado no decorrer do estudo de caso aqui apresentado.

Figura 4. Um Fragmento do Modelo Conceitual Usado no Estudo de Caso.

Na realização dos estudos de caso foi utilizado o ambiente

de especificação USE para utilizar as instâncias de testes geradas na validação dos modelos. A Fig. 5 apresenta o fragmento das expressões OCL que foi usado na geração das instâncias de casos de teste.

001. pre: (paramClienteCNH.size()>0) and (paramClienteIdade>21) and (paramClienteTempoCNH > 2) 002. pre: (paramDataDevolucao > Data::now) and (paramGrupo.size() > 0) 003. post: grupo->select(g | g.nome = paramGrupo)->size()=1 004. post: carro->select(c | c.situacao = TipoSituacao::DISPONIVEL and c.grupo.nome = paramGrupo)->size() > 0

Figura 5. Um Fragmento das Expressões OCLs Utilizado no Experimento.

Neste exemplo foram gerados 20 arquivos, contendo cada

um deles um total de 3.774.873 instâncias. Supondo que cada


arquivo (com essa quantidade de instâncias) fosse executado de forma automática e que levasse seis milissegundos para executar cada instância de teste, a execução de todas as instâncias de um arquivo levaria em torno de seis horas. Portanto, a Fig. 6 ilustra duas das instâncias no ambiente USE: a primeira contendo um erro identificado pela análise do valor limite com a variável tempo de carteira de habilitação (umCliente.tempoCnh) menor que o valor especificado na restrição expressa em OCL (Fig. 5); e a segunda com a mesma variável sem o erro, onde a animação ocorreu com sucesso. A execução de uma instância com erro e sem erro, no ambiente USE com animação, são descritas nas próximas subseções, com um maior nível de detalhe. -- Instância com erro. !create popularComAr : Grupo !popularComAr.nome:= 'PopularComAR' !popularComAr.preco:= 80.00 !create umCarro: Carro !umCarro.placa:= 'KLM-1111' !umCarro.chassis:= '9876543' !umCarro.km:= 20.000 !umCarro.modelo:= 'NovoUno' !umCarro.fabricante:= 'FIAT' !umCarro.cor:= 'Preto' !umCarro.ano:= 2011 !umCarro.situacao:= TipoSituacao.Disponivel !create umCliente: Cliente !umCliente.nome:= 'Fernando' !umCliente.cnh:= '123530-09' !umCliente.telefone:= '3241-0987' !umCliente.endereco:= 'Rua AquiPerto - 231' !umCliente.tempoCnh:= 1 !umCliente.tipo:= TipoCliente.Normal !umCliente.idade:= 29 !create umAluguel: Aluguel !umAluguel.numAluguel:= 12 !umAluguel.dataAluguel:= '25/08/2011' !umAluguel.dataDevolucao:= '30/08/2011' !umAluguel.vistoriado:= TRUE !umAluguel.assinado:= TRUE !umAluguel.bloqueioCartao:= '200.00' !umAluguel.pagamento:= StatusPgto.Pago

-- Instância sem erro. !create popularComAr : Grupo !popularComAr.nome:= 'PopularComAR' !popularComAr.preco:= 80.00 !create umCarro: Carro !umCarro.placa:= 'KLM-1111' !umCarro.chassis:= '9876543' !umCarro.km:= 20.000 !umCarro.modelo:= 'NovoUno' !umCarro.fabricante:= 'FIAT' !umCarro.cor:= 'Preto' !umCarro.ano:= 2011 !umCarro.situacao:= TipoSituacao.Disponivel !create umCliente: Cliente !umCliente.nome:= 'Fernando' !umCliente.cnh:= '123530-09' !umCliente.telefone:= '3241-0987' !umCliente.endereco:= 'Rua AquiPerto - 231' !umCliente.tempoCnh:= 3 !umCliente.tipo:= TipoCliente.Normal !umCliente.idade:= 29 !create umAluguel: Aluguel !umAluguel.numAluguel:= 12 !umAluguel.dataAluguel:= '25/08/2011' !umAluguel.dataDevolucao:= '30/08/2011' !umAluguel.vistoriado:= TRUE !umAluguel.assinado:= TRUE !umAluguel.bloqueioCartao:= '200.00' !umAluguel.pagamento:= StatusPgto.Pago

Figura 6. Um Exemplo com Duas Instâncias Geradas para o Experimento.

A. Execução de uma Instância com Erro

Na instância com o erro gerada pelo método no atributo referente ao tempo de habilitação (umCliente.tempoCnh) é possível observar (Fig. 7) que o objeto Aluguel no diagrama de objetos (Object Diagram) não foi instanciado. Ou seja, a restrição definida inicialmente pelo projetista foi devidamente testada por uma das instâncias geradas pela ferramenta (TestiMonium) que implementa o método aqui apresentado.

Figura 7. O Ambiente USE com um Erro de Execução.

B. Execução de uma Instância sem Erro

A instância que foi animada com sucesso teve todos os valores gerados pela ferramenta (TestiMonium), que implementa o método, executada corretamente. Ou seja, no final da animação o objeto, que representa a instância da classe aluguel, em destaque na Fig. 8, foi devidamente criado.

Figura 8. O Ambiente USE Sem Erro de Execução.

No entanto, somente essa instância de teste animada com

sucesso não garante a correção dessa especificação. Mas, a execução de um conjunto de instâncias permite ao projetista um valioso feedback e, ao contrário das técnicas manuais de produção de protótipos, uma relação explícita entre a especificação e a animação pode ser mantida, o que previne eventuais divergências de uma em comparação à outra.

Além disso, as instâncias de testes podem ser repetidas, o que é bastante útil, pois comumente após modificações na especificação do modelo conceitual, deseja-se saber se todas as partes da mesma continuam se comportando como antes.


V. TRABALHOS RELACIONADOS

Um estudo realizado em [23] sobre pesquisas sendo desenvolvidas em geração automática de casos de teste na última década, mostrou que a maior parte dessas investigações tem se concentrado em geração de casos de teste baseadas em modelos.

Na literatura, são encontrados vários trabalhos [10,13,14,24,25] que visam facilitar o processo de testes derivando os casos de testes a partir de modelos. A Tabela 2 sumariza os trabalhos relacionados, considerando: o tipo de técnica de teste usada, se é funcional ou estrutural, os diagramas usados, se considera a eliminação de casos de teste semelhantes, se existe a execução de casos de testes, em qual fase do processo é aplicada, e se dependente de tecnologia.

TABELA II

RESUMO DAS CARACTERÍSTICAS DAS ABORDAGENS.

Tra

balh

os

Téc

nica

de

Tes

te

Mod

elo(

s)

Elim

inaç

ão d

os C

asos

de

Tes

te S

imila

res?

E

xecu

ção

dos

Cas

os

de T

este

?

Fas

e do

Pro

cess

o

Dep

ende

nte

de

Tec

nolo

gia?

[10] Estrutural Diagrama de

Classes + OCL Não Sim Implementação Sim

[24] Funcional Diagrama de Casos de Uso

Sim Não Requisitos Não

[13] Funcional

Diagrama de Casos de Uso +

Diagrama de Atividades

Não Não Análise Sim

[14] Funcional Diagrama de Atividades

Não Não Análise Não

[25] Funcional Diagrama de Atividades

Sim Não Análise Não

Este Funcional Diagrama de

Classes + OCL Não Sim Análise Não

VI. CONSIDERAÇÕES FINAIS

Este trabalho foi motivado pela necessidade de se facilitar a geração de instâncias de testes, considerando modelos com certo grau de formalização das regras de negócio; para isso, este artigo propõe um método para geração de instâncias de testes a partir de especificações precisas (modelagem conceitual e comportamental com as regras de negócios expressas na linguagem OCL).

Um ponto forte do método é que ele pode ser aplicado nas fases iniciais do processo de desenvolvimento antecipando a descoberta de erros. Um segundo benefício obtido, pelo fato do método aqui proposto interoperar com a ferramenta USE, foi o suporte automatizado para a atividade de validação de modelos, aumentando assim a potencialidade do método.

Como trabalhos futuros estão previstos o acréscimo de critérios da técnica estrutural, já que esta complementa a técnica funcional (usada no método) possibilitando identificar uma quantidade de erros maior [1]. Além disso, o método proposto possibilita a geração automática de testes e o método

automático pode vir a gerar um grande número de instâncias de testes, incluindo redundâncias [26]. Portanto, outro ponto de melhoria seria o desenvolvimento de estratégias para a seleção das instâncias de teste mais importantes para um dado contexto.

RERERÊNCIAS [1] R. S. Pressman, Engenharia de Software. McGraw-Hill, 2006. [2] I. Jacobson, G. Booch, and J. Rambough, The Unified Software

Development Process, Addison-Wesley, 1st Edition, 1999. [3] K. Beck, et al., Manifesto for Agile Software Development. Agile

Alliance, http://agilemanifesto.org, 2001. [4] K. Beck, Test-Driven Development by Example, Addison Wesley.

2002. [5] OMG - Object Management Group, Unified Modeling Language

(UML) Superstructure Specification, version 2.0, In: http://www.omg.org/cgi-bin/doc?formal/05-07-04, Accessed in 04/2010, 2005.

[6] OMG - Object Management Group, UML 2.0 OCL Specification, In: http://www.omg.org/cgi-bin/doc?ptc/2003-10-14, Accessed in 04/2010, 2003.

[7] J. M. Spivey, The Z Notation: A Reference Manual, 2nd Edition. Prentice Hall International, 1998.

[8] C. B. Jones, Systematic Software Development Using VDM. 2nd ed, Prentice-Hall, 1990.

[9] A. Church, An Unsolvable Problem of Elementary Number Theory. In: American Journal of Mathematics, pp. 345-363, 1936.

[10] Y. Cheon, and C. Avila, Automating Java Program Testing Using OCL and AspectJ. In: ITNG 2010: 7th International Conference on Information Technology: New Generations, Las Vegas, 2010.

[11] T. S. Chow, Testing Software Design Modeled by Finite-State Machines. In: IEEE Transaction on Software Engineering, pp. 178-187, 1978.

[12] M. Fantinato, Critérios de Teste Funcional Baseados em Máquinas de Estados Finitos Estendidas. Dissertação de Mestrado. FEEC, UNICAMP, 2002.

[13] J. Hartmann, C. Imoberdorf and M. Meisinger, UML-Based Integration Testing. In: ACM SIGSOFT Software Engineering Notes. Vol 25 Ed 5. 2000.

[14] D. Kundu and D. Samanta, A Novel Approach to Generate Test Cases from UML Activity Diagram. In: Journal of Object Technologies, pp. 65-83, 2009.

[15] M. Richters, M. Gogolla, Validating UML Models and OCL Constraints, v. 1939York, England, Proceedings of UML'2000 - The Unified Modeling Language: Advancing the Standard, Third International Conference), October, 2000.

[16] P. Kruchten, The Rational Unified Processes: An Introduction. 3ª Ed, Addison Wesley Longman, 2003.

[17] G. J. Myers, The Art of Software Testing. 2ª Ed, John Wiley & Sons. 2004.

[18] A. Kleppe, J. Warmer and W. Bast, MDA Explained – The Model Driven Architecture: Practice and Promise. Addison-Wesley, 2003.

[19] D. S. Silveira, Animare: Um Método de Validação dos Processos de Negócio Através da Animação. Tese de Doutorado. COPPE, UFRJ, 2009.

[20] C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3.ed, New York: Prentice-Hall, 2004.

[21] T. Miller and P. Strooper, Animation Can Show Only the Presence of Errors, Never Their Absence. In: Proceedings of the Australian Software Engineering Conference - ASWEC, pp. 76-88, Camberra, 2001.

[22] BRG - Business Rules Group. Disponível em: <http://www.businessrulesgroup.org/egsbrg.shtml>. Acesso em 0(24 de maio de 2010.

[23] M. Prasanna, S. N. Sivanadam, R. Venkatesan and R. Sundarrajan, A Survey on Automatic Test Case Generation. Disponível em: <www.acadjournal.com/2005/v15/part6/p4/>. Acesso em: 01 de Junho de 2010, 2005.

[24] P. Borba, D. Torres, R, Marques and L. Wetzel, TaRGeT: Test and Requirements Generation Tool. In Motorola's 2007 Innovation


Conference (IC'2007), Software Expo Session, Lombard, Illinois, USA, October 5, 2007.

[25] A. M., Orozco, K., Oliveira, F. M., Oliveira and A. F. Zorzo, Derivação de Casos de Testes Funcionais: uma Abordagem Baseada em Modelos UML, Brasilia, DF, Brasil. SBSI. 2009.

[26] R. Binder, Testing Object Oriented Systems: Models, Patterns and Tools. Addison Wesley, 1999.

[27] IEEE Standart Glossary of Software Engineering Terminology: IEEE Standart 610.12-1990. ISBN 1-55937-067-X. 2000.

[28] D. D'SOUZA, A. C. WILLS, Objects, Components and Frameworks with UML, 1 ed., Addison Wesley, 1998.

Edilson Mendes Bizerra Junior é Engenheiro de Sistemas do Centro de Estudos e Sistemas Avançados do Recife (C.E.S.A.R – www.cesar.org.br). Possui o título de Mestre em Engenharia da Computação pela Escola Politécnica de Pernambuco da Universidade de Pernambuco (POLI/UPE), adquirido em 2010; graduado em Ciência da Computação pela

Universidade Católica de Pernambuco (UNICAP) em 2007. Atualmente trabalha com desenvolvimento de aplicações para dispositivos móveis.

Denis Silva da Silveira é professor e pesquisador do Programa de Pós-Graduação em Administração (PROPAD) no Departamento de Ciências Administrativas da Universidade Federal de Pernambuco (UFPE) e colaborador do mestrado de Engenharia de Computação da Universidade de Pernambuco (UPE). Recebeu o título de Doutor em Engenharia de Produção pela COPPE na Universidade Federal do Rio de Janeiro, em 2009; Mestre em Informática pela Universidade Federal do Rio de

Janeiro (UFRJ) em 1999; e graduado em Informática pela PUC-Rio em 1996. De 1997 a 2009, foi professor do Departamento de Informática da PUC-Rio. De 2009 a 2010 foi professor da POLI/UPE na cidade de Recife. De 2010 a Julho de 2011 foi Professor do Departamento de Ciências da Informação da Universidade Federal de Pernambuco (UFPE). Atualmente suas pesquisas se concentram na área de Tecnologia de Informação.

Maria Lencastre Pinheiro de Menezes Cruz finished her D.Sc. in 2004 in Computer Science at the Federal University of Pernambuco, Brazil. She was a visiting professor at Universidade Nova de Lisboa, Lisbon, Portugal for the 2008 academic year. She is professor of the University of Pernambuco, Recife, Brazil, since 2004. She was the head of Computer Engineering Department of UPE from 2009 to 2011. Maria Lencastre

was the general chair of IDEAS 2008 – 11th Ibero-American Workshop on Requirement Engineering. She was the chair of the six editions of RE-Track (ACM-SAC’08 to ACM-SAC’13). She was the co-chair of Workshop on Requirement Engineering (WER´11) part of Cibse´11 in Rio Janeiro-Brazil. She was the track-chair of the Thematic Track Quality ICT in Requirement Engineering part of QUATIC´12 in Portugal. She was a member of the local organizer committee of 6th Latin American Conference on Pattern Languages of Programming (SugarLoafPLoP´07). General Chair of I Workshop Desafios em Engenharia de Requisitos de Pernambuco (I WDPER 2012), Pernambuco, Brasil. She is member of the program committee of several international events on this area including JISBs, the Iberoamerican Workshop on Requirements Engineering, Confêrencia Ibero-Americana WWW/Internet, International Workshop on Early Aspects (EA@AOSD2011), Conferência Latino Americana em Informática (CLEI), RCIS (International Conference on Research Challenges in Information Science)., CIBSE (Ibero-American Conference on Software Engineering). Areas of interest: Requirement Engineering, Software Quality, Reuse, Modeling and Simulation. Fernando Jose Araujo Wanderley é consultor e Analista Educacional em TI

pelo C.E.S.A.R (Centro de Estudo e Sistemas Avançados do Recife) – unidade de educação, onde também exerce a função de professor do curso de Especialização em Gestão Ágil de Projetos e Coordenador do curso de Especialização em Soluções e Serviços Inteligentes na Web. É também professor assistente da Faculdade Nova Roma lecionando no curso de graduação de Ciências da Computação. Atualmente, em seu mestrado, tem dedicado seus esforços

em pesquisas relacionadas à Especificação de Requisitos Software através de técnicas como Modelagem a partir de Mapas Mentais e Modelos UML.


A Method for Generation of Tests Instances of Models from Business Rules Expressed in OCL

Documents

Transcript of A Method for Generation of Tests Instances of Models from Business Rules Expressed in OCL