FAROL: Uma ferramenta de Apoio à Aplicação de
Heurísticas de Ordenação de Classes para Teste de Integração
Arilo C. Dias Neto1, Gladys Machado P.S. Lima1,2, Guilherme Horta Travassos1 1Universidade Federal do Rio de Janeiro – COPPE/Sistemas
Caixa Postal 68.511 – CEP 21.941-972 – Rio de Janeiro – RJ – Brasil
2Diretoria de Administração da Marinha – DAdM – Marinha do Brasil
Ilha das Cobras – Ed. Alte Gastão Mota – 3º andar – CEP 20.091-000 – Rio de Janeiro
{acdn, gladysmp, ght}@cos.ufrj.br
Abstract. In object-oriented software development, an activity to be accomplished is the Class Integration Testing. This activity requires the identification of the class integration order that will determine the number of stubs (component of testing support) to be built. Stubs represent additional effort in the software development process, and when we minimize its number the testing effort is reduced. Lima and Travassos developed a set of heuristics to identify the class integration order that results in a minimum testing effort. This paper presents a tool that support an automatic application of these heuristics based in UML class diagrams.
Resumo. Durante o desenvolvimento de um software orientado a objetos, uma atividade a ser realizada é o Teste de Integração das Classes. Esta atividade requer a identificação da ordem de integração das classes que determinará o número de stubs (componentes de apoio aos testes) a ser desenvolvido. Stubs representam esforço adicional no processo desenvolvimento, e minimizar o número de stubs resulta em reduzir o esforço de teste. Lima e Travassos desenvolveram um conjunto de heurísticas para identificação da ordem de integração das classes que resulta em um esforço mínimo de teste (número de stubs). Este artigo apresenta uma ferramenta de apoio à aplicação automática dessas heurísticas baseando-se em diagramas de classe UML.
1. Introdução
Uma das maneiras de se prevenir ou identificar defeitos cometidos ao longo do processo de desenvolvimento do software é através da definição de diferentes níveis de testes em relação às diversas fases do processo de desenvolvimento [1], tais como teste de unidade, de integração, de sistema, entre outros. O teste de integração, contexto deste trabalho, representa um conjunto de atividades com o intuito de descobrir defeitos na estrutura do software definida durante a fase de projeto, comumente associados com as interfaces dos módulos (componentes) que compõem a arquitetura [2].
O desafio do entendimento da execução de um software orientado a objetos, cujas características de arquitetura diferem do paradigma procedural (acíclico), trouxe a necessidade de rever alguns problemas e estratégias relacionados aos testes de integração. O enlace (dependências) entre os componentes (representados pelas classes), mais especificamente, tornou não trivial a tarefa de identificação da ordem de integração e teste desses componentes [3].
Diversas estratégias [4, 5, 6, 7] estão disponíveis para identificar a ordem de integração das classes em projetos de software OO. Elas visam minimizar o número de stubs para simular o comportamento dos componentes ainda não prontos (não integrados), necessários nas “quebras das dependências cíclicas”. O número total de stubs necessários representa o esforço de teste e precisa ser reduzido ao máximo.
A estratégia para teste de integração proposta por Lima e Travassos [8] é composta por um conjunto de heurísticas, que formalizam os critérios de precedências entre classes [9], e o processo de aplicação dessas heurísticas [8]. Diferentemente das propostas anteriores, a estratégia é aplicada diretamente ao diagrama de classes UML do projeto OO, utilizando a própria semântica UML. Os estudos experimentais realizados [8] para caracterização da estratégia quanto ao número de stubs, resultante da ordem identificada, forneceram indícios de redução de esforço de teste para os modelos empregados. Uma sumarização dessas heurísticas está apresentada na Tabela 1.
Tabela 1. Sumarização das Heurísticas propostas em [8]
Critério Precedência
Herança 1. Superclasses concretas Æ testar primeiro as superclasses. 2. Superclasses abstratas Æ testar primeiro a subclasse com menor dependência.
Assinatura de
método da classe 3. Classe servidora testada antes da classe cliente (que assinou o método).
Agregação 4. Classe parte testada antes da classe todo.
Navegabilidade 5. A classe que se tornou atributo deve ser testada primeiro. 6. Na associação a navegabilidade deve ser analisada nos dois sentidos. Classe Associação 7. Asclassesque originaram a associação devem ser testadas primeiro. Dependência 8. A classe fornecedora deve ser testada antes da classe consumidora. Cardinalidade 9. A classe com cardinalidade opcional deve ser testada antes de outra classe com cardinalidade opcional.
A observação dos resultados qualitativos dos estudos de caso realizados apontou um interesse dos participantes, gerentes de projetos e engenheiros de software, na utilização da estratégia em projetos reais futuros. No entanto, durante o processo de aplicação das heurísticas podem ser necessárias diversas iterações nos cálculos que devem ser realizados para obtenção da lista de classes ordenadas para teste de integração (LCOTI), o que torna sua aplicação manual repetitiva e passível de erros, principalmente em projetos de grande escala, cujo número de classes é bastante alto. Justificando, assim, sua automatização.
Este artigo apresenta o apoio automatizado ao processo de aplicação das heurísticas para identificar a ordem das classes para teste de integração [8], que recebe como entrada informações de diagramas de classe UML, no formato XMI, exportadas por ferramentas CASE de modelagem de sistemas OO, e fornece ao final a lista ordenada de classes que represente um número mínimo de stubs.
O artigo está organizado em 4 seções, além desta introdução que descreve a motivação e objetivo do trabalho. Na seção 2 são descritas a proposta técnica da ferramenta e sua arquitetura. Na seção 3 é apresentada a ferramenta FAROL por meio da descrição e ilustração de suas funcionalidades, além das suas decisões de projeto. A seção 4 apresenta as limitações e avaliações da ferramenta. Finalmente, a seção 5 descreve as conclusões deste trabalho.
2. Apoio ao Processo de Aplicação das Heurísticas
A aplicação das heurísticas propostas por Lima e Travassos [8] segue um processo definido, composto basicamente por três passos principais: Pesquisar Fator de Influência (FI); Tratar Fator de Integração Tardia (FIT); e Criar Lista de Classes Ordenadas. FI e FIT são propriedades que apóiam a aplicação das heurísticas e indicam o número de classes sobre as quais a classe em análise tem precedência e o momento quando a classe deve ser considerada para integração e teste, respectivamente. O processo trata situações especiais, como: Fator de Influência Nulo; Iterações sem Fator de Integração Tardia Nulo; e o Deadlock (classes com mesmo FIT). Uma descrição detalhada deste processo pode ser obtida em [9].
Para aplicação deste processo, definiu-se uma arquitetura visando à construção de uma ferramenta que contemple a realização de cada passo, de acordo com as regras do processo. Para cada elemento da arquitetura foram definidos seus papéis dentro do processo de aplicação das heurísticas. Os componentes da arquitetura são: Tradutor XMI, Ordenador, Avaliador, e de Exteriorização, conforme apresentado na Figura 1.
Figura 1. Arquitetura de Apoio ao Processo de Aplicação das Heurísticas
• Componente Tradutor XMI: recebe como entrada um arquivo no formato XMI (XML Metadata Interchange) e é responsável pela tradução deste arquivo, reconhecendo os elementos do diagrama original (classes, associações, composição/agregação, heranças e dependências) que são relevantes para a aplicação das heurísticas e geração da Matriz de Precedência. Esta matriz bidimensional (NxN) guarda as informações de precedências estabelecidas pelas heurísticas entre as N classes de um modelo. A fórmula a seguir descreve o mecanismo de criação da Matriz de Precedência (MP):
( , ) 1
MP Cx Cy = , se a classe Cx tem precedência sobre a classe Cy; e
( , ) 0
MP Cx Cy = , caso contrário.
Onde Cx e Cy são classes do diagrama analisado. Isso deve ocorrer para cada combinação de classes do diagrama. A Figura 2 apresenta um diagrama de classes e a Matriz de Precedência obtida a partir desta fórmula. Por exemplo, a precedência da classe A sobre as classes B e E está representada pelos valores 1 encontrados nas células (A,B) e (A,E), respectivamente.
• Componente Ordenador: recebe a Matriz de Precedência como entrada e calcula o Fator de Influência [8] (O FI de uma classe consiste na quantidade de colunas marcadas na Matriz de Precedências para a linha da classe) e Fator de Influência Tardia de cada classe [8] (O FIT para uma classe consiste no somatório do FI das classes marcadas na Matriz de Precedência, na coluna referente à classe em questão), para obtenção a Lista de Classes Ordenadas para Teste de Integração (LCOTI). Por exemplo, o FI da classe B na Figura 2 é 1,
FAROL Componente de Exteriorização Componente Avaliador Componente Tradutor XMI Documento XMI Mapeamento da Árvore de Objetos Geração da Matriz de Precedências Matriz de Precedências Componente Ordenador
Calcula Fator de Influência Calcula Fator de Integração
Tardia Calcula Esforço de Teste Exportação em Documento XML Modifica Ordem iterações Documento XML exportado por FAROL Geração de Relatório em HTML Relatório HTML LCOTI
pois somente a célula (B, A) está marcada em sua linha; e o seu FIT é 4, pois na coluna da classe B estão marcadas as classes A (FI=2) e C (FI=2).
Figura 2. Exemplo de Diagrama de Classes UML e sua Matriz de Precedência
• Componente Avaliador: calcula o número total de stubs necessários e o tamanho total dos stubs a serem construídos (tamanho é o somatório do número de atributos e número de operações de cada classe para a qual será construída um stub) para a LCOTI.
• Componente de Exteriorização: é responsável pela geração de relatórios em um formato HTML com a ordem das classes, e permite, também, a exportação dos resultados para um formato XML para que possam ser utilizados posteriormente através da ferramenta.
3. A Ferramenta FAROL
A ferramenta FAROL1 foi implementadautilizando-seumambientede desenvolvimento visual em C++ e funciona independentemente de qualquer configuração adicional de máquina, tais como base de dados ou bibliotecas externas. A ferramenta pode ser executada em plataforma Windows 98 ou superior. Para utilização de FAROL é necessário somente um diagrama de classes UML armazenado em arquivos no formato XMI seguindo o DTD da UML na sua versão 1.3 publicado pela OMG (Object Management Group). Diversas ferramentas CASE de modelagem UML possuem plug-in para exportação de seus diagramas em arquivos que seguem esse formato.
FAROL foi desenvolvida com o propósito de automatizar o processo de aplicação das heurísticas, seguindo a arquitetura descrita na seção 2. Conforme apresentado na Figura 3, a tela principal de FAROL é composta de cinco áreas:
(A) Menu Principal e Barra de Ferramentas: contém itens e botões de acesso a todas as funcionalidades de FAROL e se adaptam ao estado atual do processo de aplicação das heurísticas. As funcionalidades são: Abrir arquivo XMI (componente Tradutor XMI), Gerar Ordenação (componentes Ordenador e Avaliador), Fechar arquivo, Salvar Resultado (componente de Exteriorização), Importar Resultado (componente Tradutor XMI), Imprimir Resultado (componente de Exteriorização), Ajuda e Sair.
(B) Painel do Modelo de Classes: apresenta as informações capturadas do arquivo XMI (classes e relacionamentos) referentes ao diagrama de classes em uma visão de árvore.
(C) Painel de Seqüência de Ordenação: apresenta os valores calculados de FI e FIT obtidos nas iterações durante o processo de aplicação das heurísticas.
1 FAROL é um termo empregado na navegação: construção erguida na costa e em cuja parte superior há
uma luz com características especiais, para servir de guia ou ponto de referência para os navegantes.
Classes A B C D E A 0 1 0 0 1 B 1 0 0 0 0 C 0 1 0 1 0 D 0 0 0 0 1 E 1 0 0 0 0 D E C atribC1 opC1() opC2() B atribB1 opB1() A
(D) Lista Ordenada de Classes: apresenta a LCOTI estabelecida com todas as classes do diagrama UML ordenadas de acordo com as heurísticas.
(E) Esforço de Teste e Modificação da Lista Ordenada: indica o custo (esforço de teste através do número de stubs) de desenvolvimento associado à ordem identificada e o tamanho total dos stubs. FAROL também permite ao engenheiro de software conhecer novos custos no caso de necessitar alterar a ordem original identificada. Esta facilidade foi implementada por meio dos botões de “Mover para cima” ou “Mover para baixo” a ordem da classe selecionada (Figura 3 [E]).
Figura 3. Tela Principal de FAROL
A Figura 3 reflete na execução de FAROL para o diagrama de classes apresentado na Figura 2.
Outras facilidades foram incorporadas na ferramenta, como: mecanismos de ajuda sobre a ferramenta e sobre as heurísticas e possibilidade de alteração do idioma da ferramenta (no momento a ferramenta está disponível em inglês e português, podendo ser ajustados novos idiomas).
4. Limitações e Avaliação da Ferramenta
Atualmente FAROL está preparada para receber diagramas de classes UML (padrão de modelagem de software) em um formato reconhecido pela OMG (XMI) e que podem ser gerados nas principais ferramentas CASE utilizadas no mercado: Rational Rose, Together e ArgoUML. No entanto, identificou-se que apesar dessas ferramentas CASE adotarem o formato especificado, algumas modificações são realizadas por essas ferramentas durante a geração do arquivo XMI para um diagrama UML, tornando necessário, eventualmente, a adaptação desses arquivos para que eles possam ser utilizados por FAROL. Para importação dos modelos no formato XMI, foi utilizada ao longo do desenvolvimento de FAROL a ferramenta Rational Rose (2000 e 2002), utilizando add-in para exportação de diagramas UML no formato XMI2.
Um outro aspecto a ser destacado é que FAROL apresentou até o momento, resultados idênticos aos resultados obtidos na aplicação manual das heurísticas para
2
disponível em: ftp://www6.software.ibm.com/software/developer/library/rational/2834/Rose/RoseXMLTools1.3.6.01.zip.
(A)
(B)
(C)
(D)
identificar a ordem das classes para teste de integração, apresentando sempre o número mínimo de stubs para a integração das classes. Neste momento, a aplicação de FAROL está sendo transferida para a indústria, com o objetivo de viabilizar a sua utilização em projetos com diagramas de classes mais complexos, e desta forma, podemos obter melhor avaliação sobre a sua utilização e apoio neste contexto.
5. Conclusões
O presente trabalho procurou contribuir para o processo de aplicação de heurísticas para identificar a ordem das classes para teste de integração, evitando o esforço manual e possibilidade de erros durante a sua aplicação. Para isso, foi apresentada a ferramenta FAROL, que visa apoiar o processo de aplicação dessas heurísticas utilizando diagramas de classes UML gerados por ferramentas CASE utilizadas no mercado utilizando um formato de diagramas reconhecido pela OMG.
Apesar das heurísticas fornecerem uma ordem de integração de classes que representam um número mínimo de stubs, FAROL possibilita a alteração da ordem de integração original identificada pelas heurísticas, permitindo ao engenheiro de software conhecer custos adicionais (como número e tamanho dos stubs), no caso de avaliar outras necessidades do projeto. FAROL possibilita, ainda, a geração de relatório com a ordem de construção das classes, como um mecanismo de documentação desta atividade, permitindo, ainda, que a ordem das classes estabelecida possa ser salva e reutilizada posteriormente.
Agradecimentos
Agradecemos ao CNPq, FAPEAM e Marinha do Brasil pelo apoio fornecido durante o desenvolvimento deste trabalho, e à Borland pela disponibilização do ambiente de desenvolvimento de FAROL.
Referências Bibliográficas
[1] MYERS, G., The Art of Software Testing, John Wiley & Sons, 1979.
[2] BRIAND, L.C.; FENG, J.; LABICHE, Y., Experimenting with Genetic Algorithms and Coupling Measures to Devise Optimal Integration Test Orders, Carleton University, Technical Report SCE-02-03, Version 3, October, 2002.
[3] BINDER, R.V., Testing object-oriented systems: models, patterns, and tool, Addison-Wesley, 2000.
[4] KUNG, D., GAO, J., HSIA, P., TOYOSHYMA, Y., Class Firewall, Test Order, and Regression Testing of Object-Oriented Programs, Journal of Object-Oriented Programming, vol. 8 (2), pp 51-65, 1995.
[5] TAI, K.C; DANIELS, F.J, Test Order for Inter-Class Integration Testing of Object-Oriented Software. 21st International Computer Software and Applications Conference, pp 602-607, August, 1997.
[6] TRAON, Y.L.; JÉRON, T.; JÉZÉQUEL, J.; e MOREL, P., Efficient Object-Oriented Integration and Regression Testing, IEEE Transactions Reliability, Vol. 49, no. 1, Page(s): 12-25, 0018-9529/00, 2000.
[7] BRIAND, L.C.; LABICHE, Y.; YIHONG, W, An investigation of graph-based class integration test order strategies, IEEE Transactions on Software Engineering, 0098-5589/03, Vol. 29, Issue: 7, Page(s): 594 -607, July, 2003.
[8] LIMA, G.M.P.S., Heurísticas para Identificação da Ordem de Integração em Testes de Integração Aplicados a Software Orientado a Objetos, Tese de Mestrado, COPPE / UFRJ, Março, 2005.
[9] LIMA, G.M.P.S., TRAVASSOS, G.H., Testes de Integração Aplicados a Software Orientado a Objetos: Heurísticas para Ordenação de Classes, In: III Simpósio Brasileiro de Qualidade de Software (SBQS-2004), Brasília –DF, Junho de 2004.
