Testes de Integrao Aplicados a Software Orientado a Objetos: Heursticas para Ordenao de Classes

Gladys Machado Pereira Santos Lima gladysmpsl@yahoo.com.br Centro de Anlises de Sistemas Navais Marinha do Brasil Guilherme Horta Travassos ght@cos.ufrj.br
Programa de Engenharia e Sistemas de Computao

COPPE / UFRJ Resumo

Uma questo crucial quando aplicando teste de integrao em software orientado a objetos decidir a ordem de integrao das classes. As classes precisam ser integradas uma de cada vez ou, em alguns casos, em pequenos clusters [7] j que a abordagem de integrao big-bang se demonstra inadequada nesta situao. Conceitos como encapsulamento, herana e polimorfismo adicionam complexidade aos testes, fazendo com que critrios precisem ser estabelecidos para, eventualmente, quebrar a dependncia existente entre as classes sem aumentar a complexidade (esforo) do teste. Este trabalho apresenta um conjunto de heursticas aplicadas aos diagramas de classes UML que permitem estabelecer uma ordem de prioridade para o teste de integrao das classes que compem o software, utilizando o nmero de stubs necessrios para o teste como medida do esforo requerido. Quando comparada s abordagens existentes, estas heursticas se aplicam em nvel mais alto de abstrao (projeto), facilitando sua utilizao e permitindo antecipar a tomada de deciso no planejamento do teste de integrao. Um estudo de caso demonstra sua aplicao e realiza uma comparao dos resultados com estudos realizados encontrados na literatura.

Palavras-chave: Teste de Integrao, Ordem de Integrao, Engenharia de Software Orientada a Objetos, Experimentao. Abstract
An important issue when applying object oriented integration testing is concerned with the decision about the classes integration order. The classes need to be integrated one by one or, in some cases, in small clusters [7], since big-bang integration approach can not be directly applied. Concepts such as encapsulation, inheritance and polymorphism can increase integration testing complexity, mainly for those situations when developers need to identify a set of criteria (heuristics) to break down the dependences among classes. This paper describes a set of heuristics applied to UML class diagrams that allows classes integration priority order identification. The number of stubs needed for testing is used as an effort measure. Such heuristics, when compared with the other existent approaches, can be applied in higher abstraction level (design) making possible decisions anticipation regarding the integration testing planning. A case study demonstrates its use and shows the results comparison with other related studies found in technical literature.

Key-Words: Integration Test, Integration Order, Object-Oriented Software Engineering, Experimentation. 1. Introduo O planejamento cuidadoso ajuda a projetar e organizar testes de um sistema de forma a garantir sua adequao. Muitos aspectos esto envolvidos no teste e na integrao de componentes para construir um sistema. Podemos dizer que conhecidos os objetivos dos testes, devemos decidir como integrar os componentes de um sistema. Entretanto, a introduo do paradigma orientado a objetos (OO), no contexto de desenvolvimento de software, provocou mudanas significativas na forma como os produtos de software so criados e mantidos. As mudanas foram motivadas pela nova perspectiva adotada pelo paradigma (nfase nos objetos), em oposio ao paradigma procedural, que utiliza uma abordagem focada na funcionalidade e no fluxo de informao dos sistemas.

Em conseqncia dessa nova viso para o desenvolvimento de software, muitas reas tiveram que ser revisadas, pois teorias, prticas, modelos e mtricas que eram adequados para software convencionais no podem ser aplicados de forma irrestrita quando se desenvolve software OO. Uma dessas reas o teste de software, no qual esse trabalho encontra-se inserido. Segundo Vieira [7], os principais fatores que diferenciam testes em software OO de testes em software convencionais so: encapsulamento; classes abstratas; herana; e polimorfismo. Estes fatores adicionam complexidade que no existe quando se desenvolve software utilizando o paradigma convencional. Graham resume as diferenas entre os testes orientados a objetos e os testes tradicionais, de duas maneiras [14]. Por exemplo, os objetos tendem a ser pequenos, e a complexidade, que pode geralmente residir no componente, freqentemente transferida para a interface entre os componentes. Essa diferena quer dizer que o teste de unidade menos difcil, ao passo que o teste de integrao deve ser muito mais extensivo. O encapsulamento considerado um atributo positivo do projeto OO, mas tambm requer um teste de integrao mais extensivo. De maneira semelhante, a herana introduz a necessidade de mais testes. O teste de integrao constitui-se em uma atividade de se descobrir erros associados s interfaces entre os mdulos quando esses so integrados para construir a estrutura do software que foi estabelecida na fase de projeto, conforme Maldonado [16]. Segundo Pfleeger, o processo de verificar se os componentes do sistema, juntos, trabalham conforme descrito nas especificaes do sistema e do projeto do programa [14]. Portanto, uma estratgia de integrao deve responder a trs questes: quais componentes so focados pelos testes de integrao, em que seqncia as interfaces de componentes devero ser exercitadas e qual tcnica de teste ser empregada para exercitar a interface? Devido aos problemas associados com a integrao big-bang, as classes precisam ser integradas uma de cada vez ou, em alguns casos, em pequenos clusters [7]. Dentro deste contexto, o problema pode ser descrito em como identificar uma ordem de prioridade das classes para testes de integrao, ou seja, estabelecer critrios de precedncia entre as classes para verificar o funcionamento conjunto das mesmas. Alguns pesquisadores apresentam estratgias baseadas em grafos que representam as interaes entre as classes do sistema, obtidos a partir da codificao destas. Entretanto, estas solues no focam esforos para facilitar decises de projeto em nvel de abstrao mais alto, apesar de buscarem um esforo de teste reduzido, em funo do nmero de stubs necessrios para a integrao conforme a ordem estabelecida. Segundo Pfleeger, a ordem em que os componentes so testados afeta a escolha dos casos de teste e das ferramentas [14]. A partir desta motivao, o objetivo deste estudo identificar heursticas que possam ser aplicadas aos diagramas de classes (UML Unified Modeling Language), a fim de estabelecer uma ordem de prioridade das classes para teste de integrao. 2. Teste de Integrao: Stubs e Esforo de Teste Independentemente da estratgia de teste de integrao escolhida (bottom-up ou topdow ou, as duas combinadas), os componentes so integrados com outros que, por definio, j se encontram desenvolvidos e com seus testes de unidades executados. Ou seja, o cdigo do componente foi examinado, revisado e defeitos, porventura existentes nos dados ou na sintaxe, j foram retirados. Alm disto, cada componente integrado para teste somente uma vez e, em nenhum momento, um componente pode ser modificado para simplificar o teste, segundo Pfleeger [14].

Entretanto, num processo de desenvolvimento de software, principalmente para grandes sistemas, os componentes podem estar em fases distintas do seu ciclo de desenvolvimento. Enquanto alguns podem estar prontos para executar testes de integrao, outros podem ainda estar em fase de codificao ou em fase de testes individuais (testes de unidades). Assim, para dar prosseguimento aos testes quando existirem componentes necessrios integrao ainda no codificados e testados preciso que sejam criados os stubs de testes. Os stubs so pedaos de software que devem ser construdos para simular partes de software que ainda no foram desenvolvidas ou que ainda no foram testadas, mas necessrios para testar as classes dependentes deles. Um stub a implementao parcial de um componente [3]. Um componente usado como fachada para simular o comportamento de um componente real [2]. O teste de um componente A, que chama um componente B, mas B ainda no foi testado, implica na substituio de B por um componente chamado stub. Um stub especfico escrito para simular o comportamento de B em relao ao componente A. Stubs so confiveis, apesar de se tornarem obsoletos. Entretanto, alguns componentes precisam ter seus stubs implementados (stubbed component ou stubbed class). Um stub realstico escrito para simular o comportamento do componente B em qualquer caminho de teste [10]. A estratgia de testes explica por que e como os componentes so combinados para testar o sistema [14]. A ordem de integrao dos componentes (classes) pode afetar o custo e a eficcia do teste. O custo da integrao pode ser majorado caso o nmero de stubs necessrios para sua concluso tambm aumente. Dentro deste contexto, o esforo de teste pode ser medido pelo nmero de stubs que precisam ser escritos conforme a estratgia de integrao. O nmero de stubs calculado dependendo do tipo que foi escrito. Se um stub realstico usado, o esforo 1. Se dois stubs especficos de um mesmo componente so escritos para testar outros dois componentes, ento, o esforo contabilizado em 2 [10]. O stub representa despesa indireta. software que precisa ser escrito, mas que no entregue com o produto final do software. Se os stubs so mantidos bem simples, as despesas indiretas reais so relativamente baixas. [15]. 2.1. Anlise de Dependncia Segundo Binder, os componentes, tipicamente, dependem uns dos outros de diversas maneiras [3]. As dependncias so necessrias para implementar colaboraes e conseguir a separao de alguns interesses. Algumas dependncias so acidentais ou efeitos colaterais de uma implementao, linguagem ou ambiente. As dependncias no escopo das classes e clusters resultam de alguns mecanismos como: composio e agregao, herana, variveis globais, uso de objetos como parmetros de mensagens, entre outros. Como pode ser observado no diagrama de classes de um sistema de controle de vendas, mostrado na Figura 1, existe um ciclo de dependncia entre as classes: Cliente; Pedido; e CondioEntrega. Neste exemplo, para testarmos a classe Cliente necessrio que as classes Pedido e CondioEntrega j tenham sido testadas, mas ambas apresentam dependncia de Cliente, sendo, ento, formado um ciclo de dependncia. Outro ciclo encontrado no exemplo formado por Cliente; Pedido; e CondioPagamento.

CondioEntrega

Cliente CondioPagamento

Pedido

Produto

ItemPedido

Figura 1 Diagrama de Classe: Sistema de Controle de Vendas De maneira semelhante, as dependncias ocorrem entre componentes no escopo de um sistema. Algumas abordagens usam a anlise de dependncias para apoiar o teste de integrao bottom-up. As dependncias explcitas entre componentes correspondem s interfaces que necessitam serem exercitadas pelos testes de integrao adequados [3]. 3. Estratgias Existentes Baseadas em Grafos Alguns pesquisadores apresentaram trabalhos relacionados com a busca de uma soluo (estratgias ou algoritmos) para determinar a ordem de integrao das classes e com o objetivo de minimizar o nmero de stubs a serem produzidos durante os testes de integrao das classes, com a finalidade de reduzir o esforo de teste. Estas abordagens empregam a anlise das dependncias para quebrar alguns ciclos de dependncias e, ento, criar os respectivos stubs. Segundo Briand [8], Kung et al, por exemplo, identificam componentes fortemente conectados (SCC- strongly connected components) e removem as associaes entre classes at no existir mais ciclos, mas no apresentando soluo para os casos de mais de uma associao candidata. Outros pesquisadores, como Tai e Daniels apresentaram uma soluo para tratamento dos ciclos que, na situao particular onde no existem associaes no ciclo, os resultados no eram timos em termos do nmero de stubs gerados. Le Traon et al propuseram uma estratgia alternativa baseada em algoritmos de busca em profundidade para identificao de componentes fortemente acoplados em grafos de dependncias [10]. Entretanto, este algoritmo depende de algumas decises arbitrrias para a pesquisa, o que poderia levar a resultados significativamente diferentes. Alm disto, ao quebrar os ciclos de dependncias, esta abordagem remove relacionamentos de herana ou agregao, o que pode levar a stubs necessrios mais complexos. Briand et al, assim como Le Traon e seus colegas, identificam os SCCs recursivamente usando o algoritmo de busca baseado em chamadas recursivas para o algoritmo de Tarjan. Pode-se dizer que Briand et al aliou esta estratgia com uma soluo modificada para o conceito de peso de Tai e Daniels, pois em cada etapa, isto , dentro de cada SCC no trivial, calcula-se o peso de cada dependncia da associao, como critrio para quebrar a dependncia da associao, escolhendo aquela de maior peso [8]. Briand et al realizaram cinco estudos de caso, para analisar o uso das trs tcnicas (Tai e Daniels; Le Traon et al; e Briand et al) de ordenao baseadas em grafos (ORD) para execuo de testes de integrao, no contexto de ambientes de desenvolvimento orientado a objetos utilizando

modelos representados em ORD, obtidos por engenharia reversa de cinco sistemas desenvolvidas em Java [8]. Outra abordagem, no baseada em grafos, mas em algoritmos genticos, tambm prope uma soluo para o problema da ordenao de classes para testes de integrao, por meio de uma tcnica de otimizao global baseada em heursticas [7]. Entretanto, neste caso, o propsito minimizar a complexidade dos stubs necessrios integrao. 4. Heursticas Alternativas As heursticas apresentadas por Briand et al foram realizadas com base em diagramas de relacionamento entre objetos, obtidos a partir da prpria implementao das classes em estudo [8]. Diferentemente das propostas anteriores, as heursticas apresentadas neste artigo visam o estudo das dependncias entre classes em um nvel de abstrao mais elevado, empregando como modelo o diagrama de classes de um projeto, descrito pela UML (Unified Modeling Language), como base de entrada para todas as informaes necessrias ao seu emprego. A partir da aplicao de um conjunto de heursticas que determinam critrios de precedncia entre classes, poder ser estabelecida uma lista ordenada das classes para execuo de testes de integrao, anteriormente ao detalhamento de projeto e implementao do modelo em estudo. 4.1. Verso inicial: Travassos e Oliveira As heursticas apresentadas a seguir foram retiradas de Oliveira [13] e so fruto de observao e aplicao desta abordagem na academia e na indstria, discutidas no curso de Engenharia de Software Orientada a Objetos da COPPE / UFRJ por Travassos. 4.1.1. Critrios de Precedncia Os critrios de precedncia foram definidos com o propsito de verificar, com base na semntica estabelecida pela UML, quais so as caractersticas determinantes para que certas classes sejam testadas antes de outras, de modo a realizar satisfatoriamente os testes de integrao, minimizando o nmero de stubs especficos a serem gerados. Os critrios de precedncia, descritos a seguir, so: herana; assinatura dos mtodos de uma classe; agregao; navegabilidade; classes de associao; e dependncia. As definies para estes conceitos podem ser encontradas em Booch [4]. Herana Considerando que as subclasses herdam as caractersticas e, principalmente, o comportamento das classes-base, garantir que a subclasse funcione de forma adequada significa garantir, primeiramente, que a superclasse tenha sido devidamente testada. Quando a superclasse for abstrata, deve-se testar primeiro a classe-filha que seja menos acoplada. A anlise das dependncias em relao classe-base propicia uma anlise indireta das dependncias da subclasse, na medida que a subclasse somente ser testada aps as classes das quais a classe-base depende terem sido testadas. Assinatura dos mtodos de uma classe Se uma classe (cliente) utiliza servios de outra classe (servidora), deve-se primeiro avaliar se estes servios esto corretamente implementados. Ento, testar, primeiramente, a classe servidora e depois a classe cliente. Agregao Neste contexto, agregaes simples e composta possuem a mesma semntica, e a classe todo depende dos servios fornecidos pelas classes partes. Ento a

classe parte na agregao ter precedncia para teste de integrao sobre a classe que representa o todo. Navegabilidade A navegabilidade indica que uma classe torna-se atributo de outra. Segundo Booch, a menos que seja declarado explicitamente o contrrio, uma associao implica navegao bidirecional [4]. Sendo assim, ser utilizada a navegabilidade para definir critrio de precedncia quando a ligao entre as duas classes ocorrer atravs da associao. Nos casos em que houver navegabilidade bidirecional, sero analisadas as possibilidades de propiciar a escolha da classe a ser ordenada primeiramente pelo desenvolvedor, configurando um processo semi-automtico. Classes de Associao Uma classe de associao surge a partir da necessidade de colaborao entre duas outras classes. As classes que deram origem classe de associao tero precedncia de teste de integrao sobre a classe derivada. Dependncia Uma dependncia indica a ocorrncia de um relacionamento semntico entre dois ou mais elementos do modelo. Uma classe cliente dependente de alguns servios da classe fornecedora, mas no tem uma dependncia estrutural interna com esse fornecedor. No teste de integrao, a classe cliente ter precedncia para ser testada. 4.1.2. Fator de Integrao e Fator de Integrao Tardia Para viabilizar a aplicao dos critrios de precedncia e estabelecer a ordem de prioridade, foram definidas duas propriedades: Fator de Influncia (FI) e Fator de Integrao Tardia (FIT). O fator de influncia (FI) de uma classe um valor que quantifica a relao de precedncia entre as classes, sendo, portanto, diretamente proporcional ao nmero de classes que precisam ser integradas posteriormente classe em questo. Deve ser definido considerando os relacionamentos diretos da classe em questo. Quanto maior o nmero de classes que possuam relao de precedncia com a classe sob anlise, maior ser seu fator de influncia. O fator de integrao tardia (FIT) de uma classe expressa a relao que estabelecida entre as classes aps a definio do fator de influncia e obtido a partir da soma dos fatores de influncia de todas as classes que tm precedncia direta sobre a classe em questo. Quanto maior o fator de integrao tardia de uma classe, mais tarde deve ser realizado o teste de integrao para a classe em questo. As propriedades fator de influncia e fator de integrao tardia so utilizadas para possibilitar a implementao da ordenao das classes por ordem de prioridade para teste de integrao. Exemplificando. A partir da combinao dos critrios de precedncia, por meio dos fatores de influncia (FI) e de integrao tardia (FIT), que sero calculados para todas as classes existentes do modelo, ser possvel estabelecer uma lista ordenada das classes para execuo de testes de integrao. Em anlise Figura 2, observa-se que a classe Escola no tem precedncia sobre nenhuma outra classe do modelo, sendo seu fator de influncia igual a zero. Departamento tem precedncia em relao classe Escola (parte-todo), o que significa que seu fator de influncia para a classe Departamento igual a um, pois influencia apenas uma classe do modelo. Da mesma forma que a classe Departamento, a classe Aluno possui fator de influncia igual a um, uma vez que influencia apenas uma classe do modelo, a classe Escola.

Por outro lado, a classe Curso tem precedncia sobre as classes Departamento e Aluno, seu fator de influncia, ento, igual a dois. A ordem de preenchimento da lista de classes surgir, inicialmente, a partir da seleo daquelas classes que apresentarem fatores de integrao tardia iguais a zero (Tabela 1), como calculado para a classe Curso do exemplo da Figura 2. Tabela 1. Valores para FI e FIT iniciais FI
Escola Departamento

FIT 2 2 2 0

CLASSE Escola Departamento Aluno Curso

0 1 1 2

Aluno

Curso

Figura 2. Modelo de Classes Inicial Para selecionar as prximas classes, devero ser recalculados os fatores de integrao tardia das demais classes desprezando o fator de influncia das classes anteriormente selecionadas (Figura 2) e, ento, incluir na lista aquelas que apresentarem novo fator igual a zero (Tabela 2). Neste exemplo, o resultado da lista ordenada para teste de integrao seria {Curso; Departamento ou Aluno; e Escola}. Tabela 2. Novos Valores para FI e FIT CLASSE FI FIT Escola 0 2 Departamento 1 0 Aluno 1 0 Curso 2 0 4.2. Evoluindo as Heursticas A aplicao das heursticas em diagramas que no continham classes fortemente acopladas mostrou-se eficiente. Entretanto, para diagramas contendo mais de uma classe com mesmo fator de integrao tardia, representando ciclos de dependncias entre classes, as heursticas no resultaram um esforo de teste satisfatrio, demandando um tratamento especial para situaes de deadlock [11]. Outras situaes de melhoria das heursticas foram observadas, em cursos, durante estudos de casos, bem como na observao direta de alguns aspectos, como a anlise do fator de influncia nulos, levando necessidade de complementao das heursticas, inicialmente sugeridas por Travassos e Oliveira [13], as quais apresentamos a seguir.

4.2.1. Novo critrio de precedncia: a Cardinalidade A cardinalidade, quando se analisa a navegabilidade bidirecional, tambm pode expressar um critrio de precedncia. Um dos aspectos chaves em associaes a cardinalidade de uma associao, tambm chamada multiplicidade. A cardinalidade representa o nmero de objetos que participam em cada lado da associao, correspondendo noo de obrigatrio, opcional, um-para-muitos, muitos-para-muitos ou outras variaes desta possibilidade, sendo especificada para cada extremidade da associao. Ser utilizada a cardinalidade para definir critrio de precedncia quando a cardinalidade representar a noo de opcionalidade (zero ou zero-para-muitos). Neste caso, a classe com cardinalidade opcional dever ser testada aps a outra classe da associao. 4.2.2. Anlise do Fator de Influncia Nulo O resultado de valor nulo para o clculo do fator de influncia (FI) de alguma classe de um modelo bastante significativo no processo de ordenao das classes. Expressa que a referida classe dever ter seu teste de integrao executado posteriormente execuo dos testes das demais classes com fatores de influncia no nulos do modelo. Estas classes tm seu teste de integrao totalmente dependente da integrao das demais classes do modelo. Conceitualmente, a classe com FI nulo representa a generalizao de outras classes do modelo. 4.2.3. Inexistncia de Fatores de Integrao Tardia Nulos Conforme exposto por Oliveira [13], busca-se, primeiramente, para execuo dos testes de integrao, as classes que se encontram com fator de integrao tardia nulos. Entretanto, alguns modelos podem ser representados somente por classes com forte acoplamento, no existindo inicialmente classes com fator de integrao tardia nulos. Nestes casos, a seqncia ao teste de integrao deve ser feita por meio das classes que possuam o menor FIT calculado. 4.2.4. Tratamento de Deadlock Existem situaes em que mais de uma classe do modelo apresenta o mesmo valor de FIT, significando que de alguma forma estas classes possuem uma dependncia, existindo um ciclo. Nestes casos, a quebra da dependncia implicar na implementao de um ou mais stubs para as classes destino daquela escolhida para dar continuidade ao teste de integrao. O tratamento dos ciclos ser realizado por meio da integrao de todas as classes que apresentarem o mesmo valor de fator de integrao tardia (FIT), com a conseqente gerao de stubs especficos necessrios, antes de subtrair o valor da influncia destas classes dos valores do FIT das demais classes ainda no integradas, ou seja, antes de outra iterao para o clculo do FIT. Para estabelecer prioridade entre as classes com mesmo valor de FIT, deve-se respeitar os seguintes critrios: A classe selecionada deve gerar o menor nmero de stubs especficos necessrios em comparao com o nmero de stubs gerados pelas outras classes com mesmo valor de FIT.

No caso das classes necessitarem da implementao do mesmo nmero de stubs, dever ser testada aquela que os stubs apresentarem a menor complexidade (medida pelo tamanho da classe, ou seja, pelo somatrio do nmero de atributos e do nmero de mtodos de cada stubs, [12]. No caso de alguma dessas classes a serem testadas contribuir para diminuir o nmero de stubs necessrios para testar as outras de mesmo FIT, indicando uma dependncia interna, esta dever ser testada primeiramente. Caso apresente alguma associao com navegabilidade obrigatria, a classe dever ser testada primeira, preferencialmente.

4.3. Estudo de Caso: o modelo de Briand Para ilustrar as tcnicas estudadas e compar-las com sua prpria proposta, Briand [8] utilizou como exemplo o diagrama de relacionamento entre objetos (ORD) da Figura 3, onde: heranas so identificadas por I; agregaes por Ag; associaes por As; e as classes por letras maisculas.

Figura 3. Exemplo extrado de Briand [8]. Segundo Briand [7] um critrio de avaliao para comparar ordens o esforo de construo de stubs (esforo de teste) requeridos para integrar classes conforme a ordem especfica. Se uma ordem de integrao de classes necessita de outras classes que ainda no foram integradas, faz-se necessrio o desenvolvimento de stubs para continuidade dos testes. A tabela 3 resume os resultados obtidos com a aplicao das estratgias relatadas por Briand [8] sobre o modelo da Figura 3. Podemos observar que Le Traon et al apresentam melhores resultados do que Tai e Daniels. Como o resultado de Briand et al determinstico, seu esforo de teste pode ser considerado melhor que o apresentado por Le Traon et al, pois este ltimo somente apresenta resultado igual ao de Briand quando o vrtice escolhido inicialmente for G.

Tabela 3. Resultados do Estudo de Briand [8] Seqncia de Stubs Especficos Teste Tai e Daniels {A, Stub (C, A) E, Stub (F, E) C, Stub (H, C) F, Stub (D, F) e H, Stub (B, H) D, B, G} Le Traon et al {A, Stub (C,A) (comeando com o n H, Stub (B, H) e Stub(C, H) G) D, E, Stub (F,E) F, C, B, G} Briand et al {A, Stub (C,A) E, Stub (F,E) C, Stub (H, C) H, Stub (B, H) D, F, B, G} Proposta Tendo por base os conceitos utilizados em [6] para efetuar a relao entre um diagrama de classes e seu correspondente ORD, foi gerado o diagrama de classes da Figura 4, que ser usado para demonstrar uma aplicao das heursticas alternativas proposta neste trabalho, considerando que todas as classes so concretas.

Figura 4. Diagrama de Classes correspondente a Figura 3.

Tabela 4. Valores de FI Com base nos critrios de precedncia (seo 4.1.1.), veremos Classes FI que a classe A tem precedncia sobre as classes: E (pelo critrio da A 3 navegabilidade); D (pelo critrio de herana); e C (pelo critrio de B 1 navegabilidade). Ou seja, existem trs classes que devem ser C 3 integradas aps a classe A em questo, portanto, o valor trs deve ser D 2 atribudo ao fator de influncia (FI) da classe A. O valor dois deve E 2 ser atribudo ao FI da classe E, pois a classe C (pelo critrio de F 1 navegabilidade) e a classe F (pelo critrio da agregao) devem ser G 0 integradas aps a classe E. H 2 Ao calcular o valor do fator de influncia para a lista de classes no ordenadas, composta por LCNO={A, B, C, D, E, F, G, H,}, obteremos os valores de fatores de influncia apresentados na Tabela 4. A classe G, por possuir fator de influncia nulo, ser retirada da LCNO por ser totalmente dependente dos testes de integrao das classes B e H, que por sua vez so dependentes das demais classes, sendo, ento, includa posteriormente ao final da lista ordenada a ser gerada. Tabela 5. Valores de FI e FIT nas diferentes interaes FIT FIT FIT Classes FI 1. 2. 3. Interao interao interao A 3 3 B 1 7 2 0 C 3 5 0 D 2 5 0 E 2 3 F 1 4 2 0 H 2 3 O fator de integrao tardia para nova lista LCNO={A, B, C, D, E, F, H} inicia-se com os valores mostrados pela Tabela 5. Observando a inexistncia de fatores de integrao tardia nulos, as classes A, E e H sero priorizadas conforme a necessidade da dependncia interna entre E e A, pois ambas necessitam de 1 stub especfico. A lista de classes ordenadas para teste de integrao ser, neste momento, LCOTI={A, E, H}. Devemos reduzir a influncia das classes A, E e H, e recalcular o FIT, numa segunda interao, para a LCNO={B, C, D, F}, composta pelas demais classes a ordenar. Neste momento, selecionamos as classes C e D, por serem folhas (FIT=0), que atualizam a LCOTI. Como os valores de FIT para as classes F e B na terceira interao so nulos, a LCOTI={A, E, H, D, C, F, B, G} finalmente estabelecida com a incluso da classe G ao final mesma. A utilizao da seqncia de ordenao das classes para os testes de integrao encontrada seguindo as heursticas apresentadas neste trabalho, implicar na necessidade de implementao de dois stubs especficos: um stub de C para testar A e um outro stub de C para testar H, determinando um esforo de teste igual a dois, ou ainda, na implementao de um stub realstico de C para ambas as classes A e C. Comparando este resultado com o valor de quatro stubs para a ordem estabelecida por Briand et al [8], podemos observar que houve uma reduo substancial do esforo de teste. Alie-se a isto, a facilidade de entendimento das

abstraes representadas num diagrama de classe UML comparativamente ao manuseio de um ORD. 5. Concluses e Trabalho Futuro A garantia de resultados corretos em modelos com grande nmero de classes envolvidas e com diversos ciclos de dependncias, a serem tratados durante a aplicao das heursticas na determinao da ordem de integrao das diversas classes, muitas vezes obtida por meio de uma aplicao criteriosa e organizada. Esta observao mostra a necessidade da formalizao do processo de aplicao das heursticas. Para avaliar de forma mais abrangente a aplicao das heursticas em diferentes situaes de projeto e tentar, minimamente, ampliar a abrangncia dos resultados encontrados, evitando qualquer vis ou risco de aplicao em apenas um modelo, identificamos a necessidade de elaborar estudo experimental visando caracterizao destas heursticas. Devido ao processo manual de clculo dos fatores de influncia (FI) e integrao tardia (FIT) para diagramas com grande nmero de classes e relacionamentos ser dispendioso, deve-se preparar, anteriormente aplicao do estudo experimental de caracterizao das heursticas, uma ferramenta para automatizar o processo de ordenao das classes para aplicao dos testes de integrao. A possibilidade de automatizar, tambm, a gerao da lista de stubs especficos necessrios ao teste ser estudada. A melhoria nos testes pode reduzir os custos de desenvolvimento de software ou ainda melhorar o desempenho. Desta maneira, podemos pensar na ordem de integrao das classes como guia na determinao da ordem de implementao das classes, o que poder ajudar na reduo do tempo requerido para o desenvolvimento e teste de sistemas. Agradecimentos Ao Hamilton Oliveira pelo trabalho inicial com as heursticas para integrao de classes. Marinha do Brasil pela oportunidade de participao desta Oficial no Curso de Mestrado em Engenharia de Sistemas e Computao do Instituto Alberto Luiz Coimbra de Ps-Graduao e Pesquisa de Engenharia - COPPE / UFRJ. Este trabalho est sendo realizado no contexto do projeto CNPq 475407/2003-2. Referncias Bibliogrficas [1] ANTONIOL, G.; BRIAND, L.C.; DI PENTA, M.; LABICHE, Y.; A case study using the round-trip strategy for state-based class testing, Proceedings of the 13th International Symposium on Software Reliability Engineering, 12-15 Nov. 2002, Page(s): 269 279 [2] BEIZER, B.; Software System Testing and Quality Assurance; Van Nostrand Reinhold Company Inc, 1984. [3] BINDER, R.V.; Testing object-oriented systems: models, patterns, and tool; AddisonWesley, 2000. [4] BOOCH, G., RUMBAUCH, J., JACOBSON, I., UML Guia do Usurio, Editora Campus, 2000. [5] BRIAND, L.C.; LABICHE, Y.; YIHONG, W; Revisiting strategies for ordering class integration testing in the presence of dependency cycles, ISSRE 2001. Proceedings of

the. 12th International Symposium on Software Reliability Engineering, Nov. 2001, Page(s): 287 -296 [6] BRIAND, L.C.; LABICHE, Y.; SOCCAR, G.; Automating impact analysis and regression test selection based on UML designs, Software Maintenance, 2002. Proceedings. International Conference on, 3-6 Oct, 2002. [7] 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, Oct, 2002. [8] BRIAND, L.C.; LABICHE, Y.; YIHONG, W; An investigation of graph-based class integration test order strategies, IEEE Transactions on Software Engineering, 00985589/03, Vol. 29, Issue: 7, July, 2003, Page(s): 594 -607 [9] FURLAN, J.D.; Modelagem de Objetos atravs da UML, Makron Books, So Paulo, 1998. [10] Le TRAON, Y.; JRON, T.; JZQUEL, 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. [11] LIMA, G.M.P.S.; TRAVASSOS, G.H.; Testes de Integrao Aplicados a Software Orientado a Objetos: Heursticas para Ordenao de Classes, Relatrios Tcnicos do Programa de Engenharia de Sistemas e Computao, ES-632/04, COPPE, UFRJ, 2004. [12] LORENZ, M., KIDD, J.; Object-Oriented Metrics: A Pratical Guide, Prentice Hall, USA, 1994. [13] OLIVEIRA, H.; Construo de um componente genrico baseado em heursticas para ordenao das classes em ordem de prioridade de teste de integrao, Estudo da disciplina Laboratrios de Engenharia de Software, COPPE, UFRJ, 2003. [14] PFLEEGER, S. L., Engenharia de Software: Teoria e Prtica, Prentice Hall, 2a. Edio, 2004. [15] PRESSMAN, R. S., Engenharia de Software, Mc Graw Hill, 5a. Edio, 2001. [16] ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C., Qualidade de Software: Teoria e Prtica, Prentice Hall, 2001. [17] TRAVASSOS, G.H.; GUROV, D.; AMARAL, E.A.G.G., Introduo Engenharia de Software Experimental, Relatrio Tcnico ES-590/02-Abril, Programa de Engenharia de Sistemas e Computao, COPPE/UFRJ. [18] VIEIRA, M.E.R.; Abordagem para Apoio ao Teste Baseado no Comportamento de Sistemas Orientados a Objetos, Tese de Mestrado, Programa de Engenharia de Sistemas e Computao, COPPE, UFRJ, Rio de Janeiro, 1998.