Critérios de Testabilidade para Avaliação do Modelo de
Projeto de Software Orientado a Aspectos
Paulo Afonso Parreira Júnior1, Heitor Augustus Xavier Costa2, Antônio Maria Pereira de Resende3, Fábio Fagundes Silveira4 1, 2, 3 PqES – Grupo de Pesquisa em Engenharia de Software – Departamento de Ciência da Computação (DCC) – Universidade Federal de Lavras (UFLA) Caixa Postal 3037 – CEP 37.200-000 – Lavras – MG – Brasil 4 Departamento de Ciência e Tecnologia (DCT) – Universidade Federal de São Paulo (UNIFESP) – CEP 12231-280 – São José dos Campos – SP – Brasil1[email protected], 2[email protected], 3[email protected], 4[email protected]
Abstract. Software testing aims to ensure the best possible software quality. Despite being impossible to prove that software has no faults, testing supplies evidence of the conformity with the specified functionality. However, testing activities need to have their planning started at the beginning of the development cycle, contributing to avoid faults and their propagation throughout the development phases. This paper proposes an evaluation of the aspect-oriented software Design Model, considering testability characteristics. To achieve it, we have defined a set of testability criteria to be used in such an evaluation. These criteria were used in an application in order to evaluate their effectiveness.
Keywords: Software Quality, Software Test, Aspect-Oriented
Resumo. A atividade de teste de software é realizada visando assegurar a maior qualidade possível do software. Apesar de ser impossível provar que um software é livre de defeitos, a aplicação de testes fornece evidências da conformidade com a funcionalidade especificada. Entretanto, sabe-se que as atividades relacionadas com os testes precisam ter o seu planejamento iniciado logo no princípio do ciclo de desenvolvimento, contribuindo para evitar defeitos e sua propagação nas demais fases do desenvolvimento. Desta forma, este trabalho propõe a avaliação do Modelo de Projeto de software orientado a aspecto, considerando as características de testabilidade. Para isso, foi definido um conjunto de critérios de testabilidade para ser usado na avaliação. Estes critérios foram utilizados numa aplicação para verificar a sua usabilidade.
Palavras Chave: Qualidade de Software, Teste de Software, Orientação a Aspectos
1. Introdução
O processo de verificação e de validação compreende as atividades e as análises que asseguram que o software atende às especificações e às necessidades para as quais ele foi desenvolvido [Sommerville 2001]. A atividade de teste é uma das técnicas mais
utilizadas de verificação e de validação, constituindo-se num dos elementos para fornecer evidências sobre a confiabilidade do software em complemento a outras atividades, como por exemplo, o uso de revisões e de técnicas formais de especificação e de validação [Maldonado 1991]. Segundo Pressman (2006), a atividade de teste é um elemento crítico da garantia de qualidade de software e pode assumir até 50% do esforço despendido no desenvolvimento de software.
Em decorrência da complexidade das tarefas de criação e de implementação de software não-triviais, novas tecnologias são estudadas e aplicadas ao seu processo de desenvolvimento para facilitar essas tarefas. Isto é realizado desde os primórdios da programação, podendo-se observar a evolução destas tecnologias partindo-se da programação utilizando linguagens em nível de máquina e passando pelos paradigmas Procedural, Orientado a Objetos (OO) e Orientado a Aspectos (OA). O paradigma OA estende o paradigma OO com o intuito de tratar o entrelaçamento e o espalhamento de certos requisitos (interesses transversais), visando, entre outras características de qualidade, a manutenibilidade e a reusabilidade [Elrad et al. 2001].
Existem algumas referências na literatura [Zhao and Rinard 2003], [Zhao 2003], [Zhao 2002] que discorrem sobre o fato da adoção do Desenvolvimento de Software Orientado a Aspectos (DSOA) eventualmente propiciar software com maior qualidade, porém, a OA não provê corretude por si só [Silveira 2007]. Conforme descrito por Zhao (2003), ainda que a programação OA possa conduzir a uma melhor arquitetura e uma linguagem OA possa conduzir a um estilo de codificação mais disciplinado, ambas não possuem imunidade de erros de programadores nem de falta de entendimento de especificações. Sendo assim, a atividade de teste também é essencial para o DSOA. Um fator motivador deste trabalho é a importância, destacada por vários autores [Binder 2000], [Colanzi 1999], [McGregor and Sykes 2001], de realizar as atividades de teste desde o início do ciclo de desenvolvimento de software. Outro fator é o crescente uso de OA no desenvolvimento de software. Isso pode ser verificado com eventos de relevância que têm ocorrido, como por exemplo, o Latin-American Workshop on Oriented Software Development e a International Conference on Aspect-Oriented Software Development.
Desta forma, este trabalho baseia-se na incorporação de características de testabilidade na fase de projeto, realizando avaliação destas características no Modelo1 de Projeto por meio de critérios de testabilidade a serem seguidos. O Modelo de Implementação, embora apresente características importantes às atividades relacionadas com o teste, não é considerado neste trabalho. Esta decisão visa a incentivar a prática de construção de software com característica de testabilidade desde o início do desenvolvimento. Com isto, pode-se obter os seguintes benefícios: i) redução de esforços para a elaboração dos testes, visto que as contribuições para a sua elaboração são apontadas nos artefatos gerados no Modelo de Projeto; e ii) redução dos gastos associados à correção de defeitos identificados, pois diminui a possibilidade de propagação dos defeitos entre as diferentes fases do desenvolvimento.
1 Modelo do Software é uma representação do software em vários níveis de abstração, dependendo da
fase do processo de desenvolvimento (análise/projeto/implementação/teste/manutenção). Neste caso, o Modelo de Projeto está relacionado ao conjunto de artefatos gerados durante a fase de projeto, enquanto o Modelo de Implementação está relacionado à codificação dos sistemas de informação em desenvolvimento [Filman et al. 2005].
O objetivo deste trabalho é apresentar um conjunto de critérios de testabilidade para a avaliação do Modelo de Projeto de software OA, elaborada a partir de características de testabilidade identificadas à luz da norma ISO/IEC 9126 (Tecnologia da Informação – Características e Métricas de Qualidade de Software) [ISO Std. 9126 1991], [ISO Std. 9126 2001].
O artigo está organizado da seguinte forma: a Seção 2 discorre sobre a fundamentação teórica e lista alguns trabalhos relacionados; a Seção 3 apresenta os critérios de testabilidade; a Seção 4 ilustra o uso dos critérios de testabilidade propostos; por fim, a Seção 5 apresenta algumas conclusões.
2. Fundamentação Teórica
A norma ISO/IEC 9126 [ISO Std. 9126 1991], [ISO Std. 9126 2001] define testabilidade como o conjunto de atributos do software que evidenciam o esforço necessário para validá-lo após modificá-lo. Segundo Tannouri (2006), a característica de testabilidade pode ser incorporada nos vários estágios do desenvolvimento do software: i) especificação; ii) projeto; iii) codificação; e iv) testes.
Dentre as tecnologias para DSOA, utiliza-se a aSideML para a representação do Modelo de Projeto. aSideML foi proposta por Chavez (2004) e consiste em uma linguagem de modelagem desenvolvida para especificar e comunicar projetos OA. Para isto, a aSideML define novos e enriquece alguns diagramas da Unified Modeling Language (UML) para apresentar os elementos entrecortantes (crosscutting2) e os seus relacionamentos com os elementos base3 [Chavez 2004]:
�� Diagrama de Aspectos. Este diagrama exibe a descrição de um aspecto que incorpora as interfaces transversais4, as características locais (atributos e métodos) e os relacionamentos de herança. Cada característica transversal comportamental5 pode ser visualizada em um Diagrama de Colaboração Aspectual6;
�� Diagrama de Classes Estendido. Este diagrama apóia representação gráfica da visão de projeto estático do software. Além disso, ele permite visualizar cada aspecto em detalhe e separadamente no Diagrama de Aspecto correspondente e representa uma coleção de elementos de modelagem estrutural, como aspectos, classes, interfaces e seus relacionamentos, conectados entre si como um grafo; �� Diagrama de Seqüência Aspectual. Este diagrama fornece representação gráfica
de um conjunto de mensagens organizadas em seqüência temporal (algumas mensagens denotam invocações a operações de aspectos) e suporte à visão de interação;
�� Diagrama de Processo de Combinação. Este diagrama fornece representação gráfica para um grupo de elementos combinados (elementos base adornados de forma a enfatizar as melhorias proporcionadas pelos elementos crosscutting). Esses
2 Denota um mecanismo usado para compor aspectos e componentes nos join points designados.
3 A terminologia utilizada neste trabalho está de acordo com o trabalho de Chavez (2004) sobre aSideML,
não correspondendo necessariamente às traduções realizadas por Garcia et al. (2004).
4 Conjuntos de características transversais com nome associado, que caracterizam o comportamento
crosscutting de aspectos.
5 Operações que descrevem melhorias no comportamento de componentes (unidades da decomposição
funcional do sistema encapsuladas de forma clara).
6 Descrição da organização geral de objetos e instâncias de aspectos que interagem em um contexto a fim
elementos podem ser especializados para cada modelo de implementação disponível;
�� Diagrama de Colaboração Aspectual. Este diagrama fornece representação gráfica de uma colaboração aspectual, com suporte a interaction view, que envolve instâncias de aspectos e elementos base. Uma colaboração aspectual possui uma parte estática (descreve os papéis que objetos e instâncias de aspecto exercem) e uma parte dinâmica (mostra os fluxos de mensagens ao longo do tempo para realizar o comportamento crosscutting).
A Tabela 1 e a Tabela 2 apresentam breve descrição e respectivas representações gráficas de alguns elementos de modelagem que compõem o Diagrama de Aspectos e o Diagrama de Classe Estendido de aSideML utilizados no exemplo de aplicação deste trabalho.
Tabela 1 – Elementos de Modelagem do Diagrama de Aspectos
Elemento Representação Descrição
Aspecto
Um aspecto é uma descrição de um conjunto de características que alteram a estrutura e o comportamento de classes por meio de crosscutting de forma sistêmica. Interface Transversal e Característica Transversal
Características transversais descrevem uma propriedade nomeada (atributo ou operação) definida em um aspecto que pode afetar um ou mais elementos base em locais específicos por meio de crosscutting. Uma interface transversal é o conjunto de características transversais com nome associado, que caracterizam o comportamento crosscutting de aspectos.
Embora não haja consenso sobre qual a melhor linguagem de modelagem OA a ser utilizada, a abordagem aSideML se apresentou mais adequada, pois ela propõe um modelo de aspectos de alto nível, independente de linguagem, bem como contempla os principais conceitos, propriedades e a arquitetura introduzidos pelo projeto OA. Desta forma, aSideML oferece recursos (diagramas e elementos de modelagem) suficientes para o levantamento de informações para os testes. Além disso, uma nova versão da
aSideML está em desenvolvimento, objetivando atualizar e aumentar a sua funcionalidade de maneira a atender à demanda crescente dos seus usuários.
Tabela 2 – Elementos de Modelagem do Diagrama de Classe Estendido
Elemento Representação Descrição
Crosscutting
Em aSideML, o relacionamento de crosscutting classifica um relacionamento entre um aspecto e um elemento base. Ele especifica que o aspecto deve atravessar os limites do elemento base em pontos de combinação bem definidos e modificar, incrementalmente, a base nesses pontos. Precedência
Esse relacionamento define que um aspecto (o cliente) precede outro aspecto (o fornecedor). Isso significa que o comportamento do aspecto cliente tem precedência em relação ao comportamento do aspecto fornecedor no tipo de crosscutting que esperam realizar.
Durante pesquisas realizadas, notou-se a escassez de trabalhos que tratam diretamente a característica de testabilidade ao longo do processo de DSOA. Contudo, considerando OO, Souza (2003) realizou um trabalho relativo à testabilidade de software OO, utilizando UML e Processo Unificado, com o intuito de fornecer subsídios para a elaboração dos documentos de teste por meio da identificação das características que podem ser inseridas no Modelo de Análise. As características de testabilidade foram definidas através do estudo do conteúdo dos documentos de teste e das informações que podem ser inseridas durante a modelagem. Foram propostos critérios de forma a garantir que as características de testabilidade estejam adequadamente representadas nos modelos, além de procedimentos de verificação dos modelos.
Um outro trabalho é o de Freedman (1991), que definiu o conceito de testabilidade de domínio do software mediante a aplicação dos conceitos de observabilidade e controlabilidade. Um domínio é testável (domínio-testável) quando ele é observável e controlável, ou seja, quando ele não apresenta incoerências quanto às suas entradas e saídas. Além disso, o autor define métricas para serem usadas na avaliação do nível de esforço para modificar um programa domínio-testável na manutenção.
3. Critérios de Testabilidade para o Modelo de Projeto
O contexto de pesquisa deste trabalho envolve o desenvolvimento de uma abordagem relativa à incorporação da característica de testabilidade ao Modelo de Projeto no DSOA, mediante a elaboração de critérios de testabilidade que guiem a avaliação dos artefatos de software. Assim, busca-se reduzir o esforço de transição dos artefatos entre os diferentes níveis de abstração.
Estendendo o trabalho de Souza (2003), com o diferencial de tratar a testabilidade no DSOA, este trabalho apresenta um conjunto de critérios de testabilidade para o Modelo de Projeto de software OA, do tipo “atende” ou “não-atende”, que visam guiar a avaliação de seus artefatos. Esses critérios, denominados Critérios de Testabilidade para o Modelo de Projeto (Testability Criteria for Design Model – TC_DM), foram elaborados baseando-se nas características de testabilidade [ISO Std. 9126 1991], [ISO Std. 9126 2001].
Esta pesquisa encontra-se em nível intermediário e, desta forma, poucos critérios foram definidos até o momento. Por ora, três critérios são apresentados (Figura 1) e seguem a seguinte estrutura: i) critério: identifica o TC_DM com número e descrição; e ii) justificativa: justifica o uso do TC_DM.
4. Exemplo de Aplicação: Sistema do Domínio Bancário
A fim de verificar a aplicabilidade dos TC_DMs, decidiu-se utilizá-los para guiar a construção do Modelo de Projeto de um sistema hipotético, denominado SDB (Sistema de Domínio Bancário). Porém, os TC_DMs podem ser utilizados para avaliar um Modelo de Projeto pré-existente, quando necessário. O SDB gerencia operações requeridas por uma agência bancária: efetuar login e logoff, cadastrar e remover clientes, alterar senha, consultar saldo, realizar transferência e efetuar depósito e saque. Os usuários são classificados em administrador e cliente. O SDB possui os seguintes aspectos: APersistencia (persistência), ATransacoes e seu sub-aspecto ATransacoesBancarias (controle de transação), ALogging (histórico de acessos), AIUsuario (declare parents), ATracing (controle de fluxo de execução),
APreEPosCondicoes (suporte à verificação de pré e pós-condições),
AAutenticacao (autenticação de usuário) e AExcecoes (tratamento de exceções). A
seguir, são analisados artefatos do Modelo de Projeto do SDB, exemplificando a aplicação dos três TC_DMs apresentados.
TC_DM 1 – O relacionamento de precedência entre aspectos permite o rápido reconhecimento da ordem de execução de seus adendos.
Justificativa: A ordem em que os adendos de múltiplos aspectos são combinados na aplicação alvo pode afetar o comportamento do sistema, especialmente quando esses aspectos afetam conjuntos de junção coincidentes. Logo, a representação dos relacionamentos de precedência refletirá em implementações mais fáceis de serem testadas, uma vez que a ordem de execução dos adendos é definida a priori.
TC_DM 2 – Há um conjunto de pontos de junção a serem descartados num relacionamento aspecto-classe fraco.
Justificativa: Em um relacionamento crosscuting, caso a restrição seja fraca (pouco restritiva), pontos de junção não requeridos podem ser selecionados, os quais deveriam ser ignorados. Desta forma, uma lista contendo os pontos de junção que deverão ser descartados neste relacionamento facilitará a elaboração dos casos de teste.
TC_DM 3 – Há um conjunto de pontos de junção a serem considerados num relacionamento aspecto-classe rígido.
Justificativa: Em um relacionamento crosscuting, se a restrição for rígida, alguns pontos de junção requeridos podem não ser selecionados. Logo, uma lista contendo os pontos de junção que deverão ser considerados neste relacionamento facilitará a elaboração dos casos de teste.
O relacionamento de precedência entre aspectos deve ser respeitado. Como a ordem em que os adendos de múltiplos aspectos são combinados na aplicação alvo pode afetar o comportamento do sistema, especialmente quando esses aspectos interceptam conjuntos de junção coincidentes, a representação dos relacionamentos de precedência entre aspectos é uma boa prática. O TC_DM 1 é verificado no Diagrama de Classes Estendido dos aspectos ALogging e ATracing (Figura 2).
A Figura 2 apresenta dois relacionamentos de crosscutting que associam os aspectos ALogging e ATracing à classe Banco. Estes dois aspectos interceptam o
método saldo da classe Banco e seu comportamento é alterado nos pontos de
combinação definidos pelo pointcut7 verSaldo em ambos os aspectos. O
relacionamento precedence é apresentado como uma seta tracejada entre dois elementos do modelo e rotulada com o estereótipo <<precede>>. O aspecto na parte final da seta (o cliente) precede o aspecto na cabeça da seta (o fornecedor). Neste caso, um relacionamento precedence é representado do aspecto ATracing ao aspecto ALogging. Isso significa que o comportamento de tracing ocorre antes do comportamento de logging.
Figura 2 - Diagrama de Classes Estendido de ALogging e ATracing
O TC_DM 1 pode ser verificado no diagrama da Figura 2, pois existe uma referência explícita ao relacionamento de precedência entre os aspectos envolvidos. A representação dos relacionamentos de precedência refletirá em implementações mais fáceis de serem testadas, uma vez que a ordem de execução dos adendos é definida a priori, contribuindo para aumentar a testabilidade de software OA.
7 Declarações responsáveis por selecionar pontos de execução bem definidos em um programa (join
points), ou seja, detectam quais join points o aspecto deve interceptar [Kiczales 2001], [Garcia et al., 2004].
O TC_DM 2 e o TC_DM 3 contribuem para tornar a tarefa de elaboração de casos de teste menos árdua, pois exigem que os relacionamentos aspecto-classe a serem executados e/ou descartados sejam explicitados nos artefatos do Modelo de Projeto. A Figura 3 apresenta o diagrama de aspectos de AAutenticacao. Através dela,
é possível observar que existem dois pointcuts, _classes e _verSaldo, responsáveis
por redefinir características comportamentais na classe base. O pointcut _classes
representa um relacionamento aspecto-classe fraco e, por isso, pontos de junção não requeridos podem ser afetados por ele. Por outro lado, o pointcut _verSaldo
representa um relacionamento aspecto-classe forte. Assim, pontos de junção requeridos podem não ser afetados por ele. Para verificar o TC_DM 2, um estereótipo denominado
<<ignore>> foi incorporado ao Diagrama de Aspectos de AAutenticacao,
juntamente com uma listagem dos pontos de junção que devem ser ignorados para o relacionamento aspecto-classe em questão (pointcut _classes).
De modo análogo, para verificar o TC_DM 3, um estereótipo denominado
<<include>> foi incorporado ao diagrama juntamente com uma listagem dos pontos de junção que devem ser selecionados para o relacionamento aspecto-classe em questão (pointcut _verSaldo). Figura 3 - Diagrama de Aspectos de AAutenticacao
5. Conclusão e Trabalhos Futuros
A testabilidade é um importante atributo para a manutenção e garantia de qualidade do software [Chatterjee 2008]. Embora as novas metodologias busquem reduzir a complexidade da sua organização, a atividade de teste continua sendo essencial para o seu desenvolvimento. Além disso, dada a complexidade elevada do software, considera-se esta atividade responsável por metade do esforço despendido no seu desenvolvimento. Dessa forma, foi apresentado um conjunto de critérios de testabilidade para guiar a construção do Modelo de Projeto de software OA (TC_DMs). Para verificar a aplicabilidade dos TC_DMs, construiu-se um sistema hipotético de domínio bancário. Visando a atingir a completeza dos critérios, experimentos e estudos de caso, referentes à avaliação/adaptação de Modelos de Projeto OA existentes, devem ser realizados, abrangendo outros domínios do conhecimento, bem como a avaliação da efetividade dos TC_DMs estabelecidos. Desta forma, poderão ser adicionados novos critérios ao conjunto dos TC_DMs e efetuadas adaptações nos TC_DMs definidos.fOutros desdobramentos deste trabalho incluem: a) a elaboração de diretrizes de testabilidade para o Modelo de Projeto; b) a construção de critérios e diretrizes de testabilidade para os Modelos de Análise e de Implementação; c) a criação e a atualização de uma tabela de rastreabilidade de critérios entre os três modelos; e d) o desenvolvimento de um ambiente para apoiar a abordagem, visando a sua integração ao processo de desenvolvimento.
Referências
Binder, R. V. (2000) Testing Object-Oriented System – Models, Patterns and Tools. Addison-Wesley, 1191p.Chatterjee, I. (2008) Testing Testability. StickyMinds.com. Disponível em: <http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&O bjectId=8077&commex=1>. Acessado em: Maio 2008.
Chavez, C. V. F. G. (2004) Um Enfoque Baseado em Modelos para o Design Orientado a Aspectos. Tese de Doutorado. PUC – Rio, Departamento de Informática. 298 f.
Colanzi, T. E. (1999) Uma Abordagem Integrada de Desenvolvimento e Teste de Software Baseada na UML. São Carlos, 135p. Dissertação – Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo.
Elrad, T., Kiczales, G., Aksit, M., Lieberher, K., Ossher, H. (2001) Discussing Aspects of AOP. Communications of the ACM, v. 44, n. 10, p. 33-38.
Filman, R. E.; Elrad, T.; Clarke, S.; Aksit, M. Aspect-Oriented Software Development. Addison Wesley – Pearson Education, 2005, 755p.
Freedman, R. (1991) Testability of Software Components. IEEE Transactions on Software Engineering, 17(6):553-564, June 1991.
Garcia, A., Chavez, C., Soares, S., Piveta, E., Penteado, R., Camargo, V. V., Fernandes, F. (2004) Relatório do 1º WASP, 10p.
ISO Std. 9126. (1991) “Information Technology – Software Product Evaluation – Quality Characteristics and Guidelines for their use”. International Organization for Standardization.
ISO Std. 9126. (2001) “Software Enginnering – Product Quality Part 1: Quality Model”. International Organization for Standardization.
Kiczales, G. (2001) Aspect-Oriented Programming with AspectJ (Tutorial), In: OOPSLA’2001, Tampa, Flórida, EUA. Maldonado, J. C. (1991) Critérios Potenciais de Usos: Uma Contribuição ao Teste Estrutural de Software. 169 f. Tese de Doutorado. Unicamp. McGregor, J. D.; Sykes, D. A. (2001) A Pratical Guide to Testing Object-Oriented Software. Addison-Wesley. 393p. Pressman, R. S. (2006) Engenharia de Software, 6ª ed. McGraw-Hill. Silveira, F. F. (2007) METEORA: Um método de Testes Baseado em Estados para Software de Aplicação Orientado a Aspectos. 262f. Tese de Doutorado. Instituto Tecnológico de Aeronáutica (ITA).
Sommerville, I. (2001) Software Engineering. 6a. Ed. Addison-Wesley. 693p.
Souza, R. C. G. (2003) Características de Testabilidade nos Diagramas UML (Unified Modeling Language): Apoio aos Testes de Sistemas de Software Orientados a Objetos. Tese de Doutorado. Escola Politécnica da USP.
Tannouri, P. A. (2008) O que é testabilidade. Linha de Código. 2006. Disponível em: <http://www.linhadecodigo.com.br/ITC_Artigo.aspx?id=923>. Acessado em: Maio 2008.
Zhao, J. (2002) Slicing Aspect-Oriented Software. In: International Workshop on Program Comprehension, Paris. Proceedings. IEEE Computer Society. p.251-260. Zhao, J. (2003) Data-Flow-Based Unit Testing of Aspect-Oriented Programs. In:
Annual International Computer Software and Applications Conference, Proceedings. IEEE Computer Society. p.188-197.
Zhao, J. and Rinard, M. (2003) System Dependence Graph Construction for Aspect-Oriented Programs. Cambridge: MIT, Laboratory for Computer Science. (Technical Report MIT-LCS-TR-891).
