CRITÉRIOS DE TESTABILIDADE PARA AVALIAÇÃO DO MODELO DE PROJETO DE SOFTWARE ORIENTADO A ASPECTOS - PDF
CRITÉRIOS DE TESTABILIDADE PARA AVALIAÇÃO DO MODELO DE PROJETO DE SOFTWARE ORIENTADO A ASPECTOS
Download "CRITÉRIOS DE TESTABILIDADE PARA AVALIAÇÃO DO MODELO DE PROJETO DE SOFTWARE ORIENTADO A ASPECTOS"
Natália Branco Estrada
1 PAULO AFONSO PARREIRA JÚNIOR CRITÉRIOS DE TESTABILIDADE PARA AVALIAÇÃO DO MODELO DE PROJETO DE SOFTWARE ORIENTADO A ASPECTOS Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras como parte das exigências do curso de Ciência da Computação para obtenção do título de Bacharel em Ciência da Computação. LAVRAS MINAS GERAIS BRASIL 2008
2 PAULO AFONSO PARREIRA JÚNIOR CRITÉRIOS DE TESTABILIDADE PARA AVALIAÇÃO DO MODELO DE PROJETO DE SOFTWARE ORIENTADO A ASPECTOS Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras como parte das exigências do curso de Ciência da Computação para obtenção do título de Bacharel em Ciência da Computação. Área de Concentração: Engenharia e Qualidade de Software Orientador: Prof. Dr. Heitor Augustus Xavier Costa LAVRAS MINAS GERAIS BRASIL 2008
3 Ficha Catalográfica preparada pela Divisão de Processo Técnico da Biblioteca Central da UFLA Parreira Júnior, Paulo Afonso Critérios de Testabilidade para Avaliação do Modelo de Projeto de Software Orientado a Aspectos / Paulo Afonso Parreira Júnior. Lavras Minas Gerais, p. 62. Monografia de Graduação Universidade Federal de Lavras. Departamento de Ciência da Computação. 1. Qualidade de Software. 2. Testabilidade. 3. Orientação a Aspectos. I. PARREIRA JÚNIOR, P. A. II. Universidade Federal de Lavras. III. Critérios de Testabilidade para Avaliação do Modelo de Projeto de Software Orientado a Aspectos.
4 PAULO AFONSO PARREIRA JÚNIOR CRITÉRIOS DE TESTABILIDADE PARA AVALIAÇÃO DO MODELO DE PROJETO DE SOFTWARE ORIENTADO A ASPECTOS Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras como parte das exigências do curso de Ciência da Computação para obtenção do título de Bacharel em Ciência da Computação. Aprovada em 18/11/2008 Prof. Dr. Antônio Maria Pereira de Resende Prof. Dr. Valter Vieira de Camargo Prof. Dr. Heitor Augustus Xavier Costa (Orientador) LAVRAS MINAS GERAIS BRASIL iii
5 O coração do homem pode fazer planos, mas a resposta certa dos lábios vem do Senhor. Pv.16:1 Dedico à minha mãe Eliana, ao meu pai Paulo, ao meu irmão Ricardo e à minha noiva Flávia Mendonça, que contribuíram de um modo muito especial para o meu crescimento como ser humano e como profissional Amo todos vocês! iv
6 AGRADECIMENTOS Agradeço, primeiramente a Deus, que tem me privilegiado com suas bênçãos enriquecedoras. Aos meus pais Paulo e Eliana, pessoas fundamentais que me ensinaram a lutar pelos meus objetivos e a quem sou eternamente grato por todo amor e dedicação oferecidos a mim. Ao meu irmão Ricardo, companheiro de todas as horas, amigo e amado irmão. Às minhas tias Nadir, Sirlene e Rosilene, que estiveram presentes durante minha trajetória acadêmica, acreditando e ajudando a concretizar meus sonhos. Sempre serei grato a vocês. À minha amada noiva Flávia Mendonça, que tornou os dias de minha vida mais felizes e sem a qual não posso mais viver. Obrigado por toda dedicação e paciência que teve durante esses anos. Amo você! Aos meus amigos de república, especialmente Stenio Elias e Luis Paulo (vulgo Caboclo), pela cumplicidade e presença em vários momentos. Sempre me lembrarei de vocês. Obrigado pelo companheirismo e pelas agradáveis horas de confraternização. Aos meus alunos, muito importantes para meu desenvolvimento. Foram momentos marcantes que estarão para sempre presentes em minha memória. Por fim, agradeço ao meu orientador, o professor Heitor Augustus Xavier Costa, por todo seu caráter, profissionalismo, paciência e dedicação para comigo durante as diversas atividades de pesquisa e conclusão deste trabalho. v
7 SUMÁRIO Lista de Figuras Lista de Tabelas Lista de Abreviaturas e Siglas 1. INTRODUÇÃO Contextualização Motivação Objetivos Metodologia Tipo da Pesquisa Procedimentos Metodológicos Estrutura do Trabalho ORIENTAÇÃO A ASPECTOS Considerações Iniciais Surgimento da Programação Orientada a Aspectos Programação Orientada a Aspectos Modelagem Visual de Aspectos A Abordagem asideml Diagrama de Aspectos Diagrama de Classes Estendido Diagrama de Colaboração e Diagrama de Interação Aspectuais Considerações Finais TESTE DE SOFTWARE Considerações Iniciais Qualidade de Software Norma ISO/IEC Testabilidade Teste de Software: Conceitos e Atividades Relacionadas Técnica de Teste de Software Técnica de Teste Estrutural Técnica de Teste Funcional Técnica de Teste Baseado em Estado Teste de Software Orientado a Objetos Teste de Software Orientado a Aspectos Considerações Finais ESTADO DA ARTE Considerações Iniciais Trabalhos Relacionados Considerações Finais vi
8 5. CRITÉRIOS DE TESTABILIDADE Considerações Iniciais Critérios de Testabilidade Aplicabilidade dos Critérios de Testabilidade Descrição do Software GDB Uso dos Critérios de Testabilidade Considerações Finais CONSIDERAÇÕES FINAIS Conclusões Contribuições Trabalhos Futuros REFERÊNCIAS BIBLIOGRÁFICAS vii
9 LISTA DE FIGURAS Figura 2-1 Exemplo de um Sistema Visto como um Conjunto de Interesses (Fonte: Laddad (2003) apud Silveira (2007))... 5 Figura 2-2 Exemplo de Ponto de Junção na Chamada de Método (Fonte: Silveira (2007))... 8 Figura 2-3 Interesse Transversal de Atualização da Tela (Fonte: Elrad et al. (2001))... 9 Figura 2-4 Representação Visual dos Elementos da GAADA (Fonte: Krechetoc (2006) apud Silveira ( 2007)) Figura 2-5 Dimensões da Modelagem Orientada a Aspectos com asideml (Fonte: Chavez (2004)) Figura 2-6 Padrão de Projeto Observer Modelado como um Aspecto (Fonte: Chavez (2004)) Figura 2-7 Declaração Condensada de Aspecto (Fonte: Chavez (2004)) Figura 2-8 Diagrama de Classes Estendido (Fonte: Chavez (2004)) Figura 2-9 Relacionamento Requirement (Fonte: Chavez (2004)) Figura 2-10 Interação Aspectual (Diagrama de Seqüência com Adornos) (Fonte: Chavez (2004)) Figura 2-11 Diagrama de Colaboração Aspectual para statechange_ (Fonte: Chavez (2004)) Figura 3-1 Defeito x Erro x Falha (Fonte: NETO (2007)) Figura 3-2 Atividades Relacionadas com o Teste de Software Figura 3-3 Técnica de Teste Estrutural (Fonte: NETO (2007)) Figura 3-4 Código Fonte do Programa Identifier.c (Fonte: NETO (2007)) Figura 3-5 GFC do Programa Identifier.c (Fonte: NETO (2007)) Figura 3-6 Técnica de Teste Funcional (Fonte: NETO (2007)) Figura 3-7 Grafo Causa-Efeito (Fonte: NETO (2007)) Figura 5-1 Diagrama de Caso de Uso do Software GDB Figura 5-2 Diagrama de Classes Estendido de ALogging e ATracing viii
10 Figura 5-3 Diagrama de Aspectos de AAutenticacao Figura 5-4 Diagrama de Aspectos de ATransacoes e ATransacoesBancarias ix
11 LISTA DE TABELAS Tabela 2-1 Elementos do Diagrama de Aspectos Tabela 2-2 Elementos do Diagrama de Classes Estendido (Fonte: Chavez (2004)). 18 Tabela 2-3 Elementos do Diagrama de Colaboração Aspectual (Fonte: Chavez (2004)) Tabela 3-1 Características e Subcaracterísticas do Modelo de Qualidade da Norma ISO/IEC 9126 (Fonte: Gomes (2001)) Tabela 3-2 Classes de Equivalência do Programa Identifier.c (Fonte: NETO (2007)) Tabela 3-3 Tabela de Decisão Derivada do Grafo de Causa-Efeito (Fonte: NETO (2007)) x
12 LISTA DE ABREVIATURAS E SIGLAS DSOA EROA MOA OA OO POA POO UML Desenvolvimento de Software Orientado a Aspectos Engenharia de Requisitos Orientada a Aspectos Modelagem Orientada a Aspectos Orientado a Aspectos ou Orientação a Aspectos Orientado a Objetos ou Orientação a Objetos Programação Orientada a Aspectos Programação Orientada a Objetos Unified Modeling Language xi
13 Critérios de Testabilidade para Avaliação do Modelo de Projeto de Software Orientado a Aspectos 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.. Testability Criteria for Evaluation of Design Model of Aspect- Oriented Software 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.. xii
14 1. INTRODUÇÃO 1.1. Contextualização O termo aspecto representa uma unidade modular projetada para implementar um interesse, que em Engenharia de Software pode caracterizar um objetivo particular, um conceito ou uma responsabilidade que possa ser adotada na solução de um software, por exemplo, persistência, controle de logging e segurança [LADDAD, 2003]. Ainda que existam várias afirmações na literatura [ZHAO; RINARD, 2003; ZHAO 2003; ZHAO, 2002] de que a adoção do Desenvolvimento de Software Orientado a Aspectos (DSOA) eventualmente leve a software com melhor qualidade, por conduzir a uma melhor arquitetura e de que uma linguagem Orientada a Aspectos (OA) force um estilo de codificação mais disciplinado, ambos não possuem imunidade contra erros de programadores, tampouco contra problemas de falta de entendimento na fase de especificação. Sendo assim, o teste continua sendo uma importante atividade, mesmo no DSOA [ZHAO, 2003]. Segundo Silveira (2007), a incorporação de interesses adicionais à lógica primária da aplicação (core concerns) deve passar por rigorosos e diferentes níveis de testes, com o intuito de garantir que esses interesses adicionais conhecidos como funções auxiliares comportem-se conforme o especificado, bem como garantir que não introduzam defeitos na aplicação Motivação Um fator motivador para esta pesquisa é a importância, destacada por vários autores [BINDER, 2000; COLANZI, 1999; MCGREGOR; SYKES, 2001], de realizar as atividades de teste desde o início do ciclo de desenvolvimento, abrangendo as suas fases. Desta forma, esta pesquisa propõe um desenvolvimento que considere as atividades de teste desde as fases iniciais do desenvolvimento, incluindo as características de testabilidade nos Modelos de Projeto 1 e realizando a avaliação destas características pela da definição de critérios a serem seguidos. 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].
15 É importante salientar também, que outro fator motivador deste trabalho é o crescente uso do paradigma OA em desenvolvimento de software. Isso pode ser comprovado com os eventos que têm acontecido e tomado proporção considerável entre os pesquisadores: Latin American Workshop on Aspect-Oriented Software Development e International Conference on Aspect-Oriented Software Development Objetivos O objetivo deste trabalho é definir critérios de testabilidade que possam ser aplicados ao Modelo de Projeto para aumentar a característica de qualidade testabilidade de software OA. Segundo a norma ISO/IEC 9126, a característica de qualidade testabilidade consiste em atributos do software que evidenciam o esforço necessário, visando minimizá-lo, para validar o software modificado [ISO Std. 9126, 1991; ISO Std. 9126, 2001; ABNT NBR13596, 1996]. A linguagem de modelagem usada para representação os artefatos do Modelo de Projeto foi asideml. Esta linguagem foi proposta na tese de doutorado de Chavez (2004) e consiste em uma linguagem para especificar e comunicar projetos (design) OA Metodologia Tipo da Pesquisa Conforme Jung (2004) e Marconi; Lakatos (2003) e observando o método científico, pode-se caracterizar esta pesquisa de natureza tecnológica, com objetivos de caráter exploratório, usando procedimentos experimentais fundamentados em um trabalho de campo Procedimentos Metodológicos O trabalho foi iniciado realizando um levantamento bibliográfico na Internet e em bibliotecas de artigos científicos relacionados ao tema. Em seguida, foi estudado o paradigma OA, de forma a verificar suas características, suas técnicas e suas contribuições para a área de computação. Posteriormente, foram estudados os principais conceitos e técnicas relacionadas ao teste de software, em particular, teste de software OA. 2
16 A etapa seguinte constituiu-se em identificar os aspectos de testabilidade a serem incorporados nos artefatos de software do Modelo de Projeto, sob a luz da norma ISO/IEC 9126 [ISO Std. 9126, 1991; ISO Std. 9126, 2001; ABNT NBR13596, 1996], definindo os critérios de testabilidade. Reuniões semanais ocorrerão entre o autor e o orientador visando manter a consistência e bom andamento do trabalho. Por fim, os resultados obtidos foram usados em um estudo de caso, possibilitando verificar a aplicabilidade dos critérios propostos Estrutura do Trabalho Este trabalho está organizado da seguinte forma. O Capítulo 2 apresenta a definição e os principais conceitos do paradigma OA, bem como algumas abordagens para a modelagem visual de programas OA. O Capítulo 3 discorre sobre teste de software, qualidade de software, testabilidade em software e sintetiza a norma ISO/IEC 9126, mostrando as seis características de qualidade para software e suas respectivas subcaracterísticas. O Capítulo 4 descreve os principais trabalhos da literatura relacionados a testabilidade de software. O Capítulo 5 define os critérios de testabilidade aplicáveis na construção e/ou avaliação/adaptação do Modelo de Projeto de software orientados a aspectos. Além disso, apresenta um estudo de caso, o software Gestão de Domínio Bancário (GDB), visando ilustrar a aplicabilidade dos critérios. O Capítulo 6 conclui o trabalho fazendo algumas considerações finais sobre a pesquisa realizada. Neste capítulo, além das contribuições, são apresentados os resultados alcançados e sugeridos trabalhos futuros. 3
17 2. ORIENTAÇÃO A ASPECTOS 2.1. Considerações Iniciais Este capítulo apresenta os principais conceitos da Programação Orientada a Aspectos (POA), uma nova tecnologia que objetiva solucionar alguns dos problemas identificados na Programação Orientada a Objetos (POO) e descreve as abordagens para modelagem visual de software OA. A terminologia utilizada neste trabalho, quando referente a POA, segue as traduções realizadas pela Comunidade Brasileira de Desenvolvimento de Software Orientado a Aspectos (AOSDbr) para a Língua Portuguesa [AOSDbr, 2008]. A seção 2.2 descreve breve histórico sobre a POA, abordando sua origem e sua importância. A seção 2.3 apresenta conceitos básicos envolvidos na POA. A seção 2.4 apresenta diversas abordagens propostas para a modelagem visual de aspectos, destacando a abordagem asideml Surgimento da Programação Orientada a Aspectos O conceito de interesse (concern) foi apresentado por Dijkstra (1976) e é utilizado em Engenharia de Software para separar os atributos ou as funções de um software [ELRAD et al., 2001a]. Um software pode ser visto como uma implementação combinada de múltiplos interesses, tais como regras de negócios, desempenho, persistência, registro de informações (logging), autenticação, segurança, gerenciamento de memória, balanceamento de carga e replicação [KICZALES et al., 2001]. A Figura 2-1 apresenta um exemplo de software visto como a implementação de um conjunto de interesses. Os interesses em um software podem representar Requisitos Funcionais (RFs) e Requisitos Não-Funcionais (RNFs). Os RFs definem a funcionalidade de um software ou de seus componentes. Os RNFs podem estar relacionados a propriedades emergentes do software, como confiabilidade e tempo de resposta, e incluir limitações (desempenho e segurança) e/ou no processo de desenvolvimento (custos, atrasos, metodologias adotadas e componentes a serem utilizados) [SOMMERVILLE, 2001].
18 Com o constante crescimento da complexidade dos sistemas modelados em Engenharia de Software, diversas dificuldades têm sido ocasionadas no processo de desenvolvimento de software em conformidade com RFs e RNFs, dentro dos cronogramas e dos orçamentos planejados [SILVEIRA, 2007]. Figura 2-1 Exemplo de um Sistema Visto como um Conjunto de Interesses (Fonte: Laddad (2003) apud Silveira (2007)) À medida que aumenta a complexidade do software, surge a necessidade de melhores técnicas de programação, objetivando organizar e apoiar o seu processo de desenvolvimento. No âmbito da Ciência da Computação, as técnicas de programação vêm evoluindo desde construções de baixo nível (linguagens de máquina) a abordagens de alto nível (POO) [ELRAD et al., 2001b]. Os paradigmas de programação constituem forte influência no projeto de linguagens de programação, porque permitem o desenvolvimento de software cada vez mais complexo e contribuem para a diminuição do seu custo final. Cada novo paradigma que surge e alcança sua maturidade proporciona um avanço na tecnologia de programação [SEBESTA, 2008]. Segundo Resende; Silva (2005), inicialmente, desenvolvia-se software usando a programação desestruturada. Comandos de desvio de fluxo (por exemplo, GOTO) eram 5
19 utilizados sem critérios, tornando árduo o entendimento, a reutilização e a manutenção do código-fonte. A programação estruturada foi um grande avanço, pois as funções e/ou os procedimentos eram agrupados e chamados a partir de um programa principal. Quem usava a programação estruturada podia reusar as funções e os procedimentos, desde que devidamente projetados. Nesta época, a reusabilidade foi explorada usando o conceito de bibliotecas. Com o advento da POO, em meados da década 70, com a linguagem de programação Smalltalk, inicia-se um novo paradigma de desenvolvimento de software presente até os tempos atuais [SANTOS, 2007]. Tendo o reuso como objetivo, a POO ganhou popularidade, por dividir software em um conjunto de classes e objetos que representam abstrações de entidades do mundo real ou de artefatos de implementação. Nota-se que, cada classe e objeto resultante deste estilo de decomposição representa um interesse [SILVEIRA, 2007]. A POO trouxe avanços para o desenvolvimento de software, permitindo a construção de projetos mais facilmente, maior reusabilidade de componentes, modularidade, componentização, implementações mais robustas e redução do custo de manutenção [JUNIOR; WINCK, 2006]. Diversas aplicações não estão em apenas um único módulo de código contido em um único arquivo. Conforme Gradecki; Lesiecki (2003), aplicações são coleções de módulos que trabalham juntas para fornecer determinadas funções para um conjunto de requisitos bem definidos. Entretanto, apesar de tais avanços, o aumento da complexidade inseriu novos problemas que a orientação a objetos (OO) é incapaz de resolver. Isso ocorre principalmente quando se trata de RNFs, que afetam o comportamento das classes, tais como persistência de dados (data persistence) e pontos de verificação para fins de tolerância a falhas (checkpoints for fault-tolerance). Na concepção de Kiczales et al. (1997), as técnicas de POO e da programação estruturada não são suficientes para implementar com clareza importantes decisões de projeto. Isto conduz a uma implementação espalhada pelo código-fonte, resultando em um emaranhado de código que se torna excessivamente difícil de desenvolver e manter. Conforme Silveira (2007), isto ocorre porque a solução para estas decisões não é facilmente encapsulada em uma estrutura de atributos e comportamentos, pois a sua 6
20 implementação requer que tais interesses estejam espalhados (scattered) e entrelaçados (tangled) ao longo de diversas classes, simultaneamente. A necessidade de novas abstrações capazes de propiciar maior clareza na separação de interesses motivou a definição de novas técnicas de programação e de desenvolvimento de software [SILVEIRA, 2007]. Dentre as principais técnicas, há: Adaptive Programming (AP) [LIEBERHERR et al., 2001]; Composition Filters (CF) [AKSIT et al., 1992]; Subject-Oriented Programming (SOP) [OSSHER; TARR, 1999]; e Aspect-Oriented Programming (AOP) [KICZALES et al., 1997]. Dentre essas técnicas, a que tem se mostrado mais promissora é a POA (ELRAD et al., 2001b), sendo ela a técnica abordada neste trabalho Programação Orientada a Aspectos De acordo com Kiczales et al. (1997), aspectos não tendem a ser unidades de decomposição funcional do software, mas propriedades que afetam de forma sistemática o desempenho ou a semântica dos componentes. O estilo de decomposição da OA preserva os princípios estabelecidos pelo paradigma OO e adiciona a capacidade de modelar RNFs em estruturas bem definidas chamadas aspectos [SILVEIRA, 2007]. A POA não trabalha isoladamente; ela é um paradigma que estende outros paradigmas de programação, complementando-os [SANTOS, 2007]. Para melhor entender o paradigma OA, faz-se necessário descrever alguns de seus termos específicos [FILMAN et al., 2005; RESENDE; SILVA, 2005]: Interesses (Concerns). São preocupações presentes no processo de construção de um software, que envolvem desde assuntos e requisitos de alto nível aos relacionados a implementações de baixo nível. Algumas destas preocupações localizam-se em pontos bem específicos e bem definidos, enquanto outras se referem às propriedades mensuráveis do software como um todo. A Figura 2-1 apresenta alguns exemplos desses interesses; Pontos de Junção (Join points). Este termo refere-se a pontos bem definidos em uma estrutura ou em um fluxo de execução de um software, onde um comportamento adicional pode ser anexado. Um modelo de pontos de junção provê um conjunto de referências que propiciam a definição de estruturas de aspectos. Os elementos mais comuns de um modelo de pontos de junção são as chamadas de métodos, apesar das 7
21 linguagens OA terem definido pontos de junção para outras circunstâncias (por exemplo, acesso, modificação e definição de atributos, exceções e execução de eventos e estados). Se uma linguagem OA permite chamadas de métodos no seu modelo de pontos de junção, um programador pode designar um código adicional para ser executado em uma chamada de método. A Figura 2-2 ilustra esta situação, apresentando o ponto de junção onde um comportamento extra pode ser acrescentado ao código original da aplicação; Figura 2-2 Exemplo de Ponto de Junção na Chamada de Método (Fonte: Silveira (2007)) Interesses transversais (Crosscutting concerns). Freqüentemente, a implementação de um interesse deve ser espalhada ao longo de uma ou mais implementações. Neste caso, o interesse cuja implementação entrecorta a implementação de outros interesses é denominado interesses transversais. Segundo Araújo (2002), interesses transversais são responsabilidades que produzem representações entrelaçadas e espalhadas pelo ciclo de vida de um software. Como exemplo de um interesse transversal, tem-se um editor de figuras apresentado em Elrad et al. (2001). O software de edição de figuras é composto por duas classes concretas de elementos de figura (Ponto e Linha). Sempre que os elementos da figura forem movimentados, é necessário que a tela seja atualizada. Desta maneira, observa-se no Diagrama de Classes (Figura 2-3) o interesse de atualização da tela não pertencer às classes Ponto e Linha, mas entrecorta-as e, por isso, pode ser entendido como transversal a essas classes. As linguagens OA utilizam cincos elementos principais para modularizar os interesses transversais [ELRAD et al., 2001]: 8
22 Um modelo de pontos de junção, descrevendo os ganchos (hooks) onde melhoramentos ou funções podem ser adicionados; Meios de identificação desses pontos de junção; Meios de especificações de comportamento nesses pontos de junção; Unidades encapsuladas, combinando especificações e melhoramentos comportamentais nos pontos de junção; Um método para interligar ou combinar esses interesses ao programa alvo. Figura 2-3 Interesse Transversal de Atualização da Tela (Fonte: Elrad et al. (2001)) Aspecto (Aspects). Este termo representa uma unidade modular projetada para implementar um interesse. Uma definição de aspectos pode conter códigos e instruções sobre onde, quando e como será invocado; Conjunto (de pontos) de junção (Pointcut). Este termo é utilizado para descrever um conjunto de pontos de junção (join points). Esta característica provê um mecanismo que possibilita a declaração de pontos bem definidos no fluxo de execução de um software para implementação de comportamentos adicionais; Adendo (Advice). Este termo refere-se a construções similares aos métodos de objetos do paradigma OO e compreende o comportamento que deve ser executado em cada ponto de junção (join point) especificado por um conjunto de junção (pointcut). Por exemplo, o código de segurança responsável por realizar a autenticação e o controle de acesso. Muitas linguagens OA possuem mecanismos para executar o adendo antes 9
23 (before), depois (after), em substituição ou acerca (around) dos pontos de junção convenientes Modelagem Visual de Aspectos Segundo Chavez (2004), software OA precisa ser visualizado e comunicado entre os desenvolvedores. Ademais, suas propriedades precisam ser especificadas de modo a permitir a análise de modelos e a evitar o entrelaçamento e o espalhamento nas especificações. A Modelagem Orientada a Aspectos (MOA) é uma parte crítica do DSOA que se concentra em notações e em técnicas para a especificação, a representação, a visualização e a comunicação de soluções OA por meio do percurso que leva da Engenharia de Requisitos Orientada a Aspectos (EROA) a POA. A seguir, é apresentada uma descrição sucinta de algumas abordagens para MOA disponíveis na literatura: Abordagem Tema: Clarke; Baniassad (2005) propuseram uma abordagem de desenvolvimento de software OA denominada Tema. A abordagem Tema é divida em dois níveis para diferentes fases do ciclo de vida do software: Tema/Doc e o Tema/UML. O nível Tema/Doc é utilizado para a fase de requisitos, fornecendo visões do texto da especificação de requisitos e expõe o relacionamento entre os comportamentos de um software. Ele permite ao desenvolvedor refinar a visão dos requisitos de modo a revelar quais funções do software são transversais e onde elas se entrecortam. O nível Tema/UML trabalha com dois tipos de temas: i) Tema-base (possui a funcionalidade do domínio do problema); e ii) Tema-transversal (encapsula os interesses transversais que afetam o Tema-base). Um tema é o encapsulamento de um interesse (concern) representado graficamente por meio das operações-gabaritos (templates). Definidos o Tema-base e o Tema-transversal, é necessário realizar a composição entre eles por meio de um relacionamento de ligação denominado bind. Com esse relacionamento, sabe-se quais métodos do Tema-base serão afetados pelo Tema-transversal. Após realizar o relacionamento de ligação, é possível fazer a composição para que seja gerado o modelo resultante da aplicação; Abordagem Geral de Modelagem Arquitetural Orientada a Aspectos (General Aspect-Oriented Architecture Design Approach GAADA): esta abordagem foi 2 Neste trabalho, a terminologia adotada para adendos do tipo before, after e around é anteriores, posteriores e de contorno, respectivamente. 10
24 proposta por Krechetov et al. (2006) e é baseada no Trabalho do Grupo de Pesquisa em Modelagem Arquitetural do AOSD-Europe [AOSD-EUROPE, 2006]. A GAADA pretende fornecer, em sua versão final, a representação dos seguintes conceitos: i) Aspecto; ii) Componente; iii) Conjunto de Junção; iv) Adendo; v) Entrecortes estático (declarações intertipos 3 ) e dinâmico (pointcut); vi) Relacionamento Aspecto- Componente; e vii) Relacionamento Aspecto-Aspecto. A Figura 2-4 mostra a representação visual dos elementos da GAADA. Nota-se que, nesta abordagem, não existem notações gráficas para os elementos adendos e entrecortes estáticos. Os autores consideram estas representações e a modelagem visual das máscaras 4 de conjuntos de junção como questões em aberto e evidenciam a necessidade de mais estudos nesse tema; Linguagem de Modelagem asideml: Chavez (2004) propôs uma linguagem de modelagem chamada asideml para especificar e comunicar projetos (design) OA. Esta linguagem oferece semântica, notação e regras que permitem ao projetista construir modelos cujo foco sejam os principais conceitos, mecanismos e propriedades de software OA, no qual os aspectos sejam explicitamente tratados como cidadãos de primeira classe. A linguagem asideml organiza os elementos de modelagem em diagramas gráficos que fornecem várias visões do software em desenvolvimento. A Figura 2-5 apresenta descrições dos modelos, dos diagramas, dos novos elementos de modelagem e das perspectivas relevantes para cada diagrama de asideml. Apesar das abordagens apresentadas anteriormente proverem suporte para MOA em nível de projeto, para este trabalho, a abordagem asideml se apresentou mais adequada, pois ela propõe um modelo de aspectos de alto nível, independente de linguagem e contempla os principais conceitos, propriedades e arquitetura introduzidos pelo projeto OA. Desta forma, asideml oferece recursos suficientes para o levantamento de informações para os testes. 3 É uma característica presente em algumas linguagens OA que permite alterar a estrutura de uma classe introduzindo novos atributos, métodos, construtores, getters, setters, herança e interface [RESENDE; SILVA, 2005]. 4 Estrutura disponibilizada em algumas linguagens OA para facilitar o trabalho de escrever pointcuts. Por exemplo, o uso de curingas, como *, +,.. (dois pontos seqüenciais), pode simplificar a declaração de pontos de junção (salvar*() = métodos que começam com o prefixo salvar ) [RESENDE & SILVA, 2005]. 11
25 Figura 2-4 Representação Visual dos Elementos da GAADA (Fonte: Krechetoc (2006) apud Silveira ( 2007)) 12
26 Figura 2-5 Dimensões da Modelagem Orientada a Aspectos com asideml (Fonte: Chavez (2004)) A Abordagem asideml A asideml é uma dentre as várias abordagens existentes para MOA. Proposta na tese de doutorado de Chavez (2004), asideml consiste em uma linguagem de modelagem desenvolvida para especificar e comunicar projetos OA. Segundo Chavez (2004), o nome aside vem do termo em inglês aside (to or toward the side), para denotar elementos que estão ao lado de outros. O nome pode também ser interpretado como denotando um lado (a side), no sentido de uma faceta ou um aspecto. Os principais objetivos relacionados ao projeto asideml são: fornecer uma linguagem de modelagem visual expressiva a fim de desenvolver e de comunicar modelos de aspectos; fornecer semântica e notação para oferecer apoio aos novos requisitos de modelagem introduzidos pelos aspectos; fornecer um framework conceitual que incorpora o consenso da comunidade OA sobre os principais conceitos do DSOA e uma base rigorosa para compreender a linguagem de modelagem; 13
27 oferecer apoio às especificações independentes de linguagem que podem ser mapeadas para linguagens de programação OA particulares; seguir os padrões da indústria. A linguagem asideml define três dimensões de modelagem para sistemas AO (Figura 2-5): modelagem estrutural fornece visão estática de um software na presença de aspectos. Os principais elementos estruturais são: i) aspectos; ii) elementos base (de UML Unified Modeling Language) que os aspectos afetam (as classes); e iii) seus relacionamentos. O comportamento dinâmico destes elementos é descrito por modelos comportamentais; modelagem comportamental oferece visão de interação de um software na presença de aspectos. Os principais elementos comportamentais são: i) objetos; ii) instâncias de aspectos; e iii) suas colaborações e interações. Esta modelagem caracteriza o comportamento de aspectos em termos da forma como interagem com objetos; modelagem de processo de combinação (ou composicional) descreve as visões estáticas e de interação de um software depois da combinação de modelos de objetos e modelos de aspectos. Os principais elementos composicionais são: i) classes combinadas; ii) colaborações combinadas; e iii) interações combinadas. Esses elementos são apresentados em diagramas de processo de combinação. Os resultados de combinação dependem da estratégia de combinação adotada, que depende do modelo de implementação suportado pela ferramenta ou linguagem de programação OA 5. As próximas subseções apresentam a descrição geral dos diagramas e dos elementos de modelagem presentes em asideml Diagrama de Aspectos Um Diagrama de Aspectos fornece uma descrição completa de um aspecto. A descrição incorpora as interfaces transversais, as características locais e os relacionamentos de herança. Cada característica transversal comportamental pode ser visualizada em um 5 O escopo deste trabalho baseia-se na definição e na incorporação de características de testabilidade nos artefatos gerados durante a fase de projeto de software AO. Assim, a modelagem de processo de combinação não é abordada neste trabalho. 14
28 Diagrama de Colaboração Aspectual. A Tabela 2-1 apresenta breve descrição e respectivas representações gráficas dos elementos que compõem um Diagrama de Aspectos. Tabela 2-1 Elementos 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 usando entrecortes 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 usando entrecortes. Uma interface transversal é conjuntos de características transversais com nome associado, que caracterizam o comportamento entrecortante de aspectos. Um aspecto é representado como um retângulo tracejado, com um losango contendo o nome do aspecto, que toca um retângulo usado para descrever suas características locais (atributos e métodos). Um aspecto pode conter vários elementos internos, como interfaces transversais, classes, interfaces e relacionamentos. A notação para descrever interfaces transversais é apresentada na Figura 2-6. Esta figura apresenta Observation, um aspecto que descreve o padrão de projeto (design pattern) Observer [GAMMA et al. 1996]. Um aspecto pode ser representado de forma condensada, onde se omite as informações sobre seus elementos internos, exceto os nomes das interfaces transversais; cada interface transversal é exibida como um pequeno círculo com seu nome colocado ao lado (Figura 2-7). O círculo está ligado por uma linha sólida ao losango que representa o 15
29 aspecto. A visão condensada é o padrão para a apresentação de aspectos em Diagramas de Classes Estendidos. Figura 2-6 Padrão de Projeto Observer Modelado como um Aspecto (Fonte: Chavez (2004)) Figura 2-7 Declaração Condensada de Aspecto (Fonte: Chavez (2004)) Uma interface transversal é representada por um retângulo com linhas sólidas com compartimentos separados por linhas horizontais. No primeiro compartimento, o nome no topo representa o nome da interface transversal. O segundo compartimento contém um conjunto de características comportamentais e estruturais que o aspecto adiciona a uma classe base (additions). O terceiro e o quarto compartimentos (refinements e redefinitions) contêm os conjuntos de características transversais comportamentais que refinam ou redefinem algumas características comportamentais existentes na classe base (obrigatoriamente, um deles não deve estar vazio). Um compartimento opcional (uses) 16
30 pode ser fornecido para definir um conjunto de assinaturas para características requisitadas (required features) usadas pelo aspecto. Características transversais comportamentais são listadas em diferentes compartimentos, dependendo do tipo de melhoria (adição, refinamento, redefinição). Características transversais comportamentais que permitem adição são listadas no compartimento Additions e não são parametrizadas. Características transversais comportamentais que permitem refinamento são listadas no compartimento Refinements. Nesse compartimento, o nome das operações é representado com o símbolo _ (underscore), em três combinações permitidas: _op, op_ e _op_. Esses adornos indicam que a operação entrecortante oferece o comportamento que deve ser combinado antes, depois ou antes/depois do comportamento da operação base. Características transversais comportamentais que permitem redefinição são listadas no compartimento Redefinitions. Neste caso, comportamento de op é redefinido (ou sobreposto) pelo comportamento de _op_. Adornos textuais (before, after, around e use) podem substituir o símbolo _. Por exemplo, pode-se escrever before op em vez de _op. A Tabela 2-1 apresenta uma interface transversal na qual o símbolo _ é substituído por adornos textuais que descrevem o tipo de entrecorte Diagrama de Classes Estendido O Diagrama de Classes Estendido é um grafo de aspectos e de classes conectado por seus diferentes relacionamentos estáticos e oferece uma apresentação gráfica da visão estática de projeto de um software em que as classes e os aspectos residem como cidadãos de primeira classe. Cada aspecto pode ser apresentado em uma visão detalhada separada por um Diagrama de Aspectos. O Diagrama de Classes Estendido agrega novos elementos de modelagem ao Diagrama de Classes definido pela UML; por isso, alguns elementos deste diagrama são omitidos neste trabalho. A Tabela 2-2 apresenta breve descrição e respectivas representações gráficas dos elementos que compõem o Diagrama de Classes Estendido. Uma tabela equivalente à Tabela 2-2 que apresenta a descrição e a representação gráfica 17
31 dos elementos que compõem o Diagrama de Classes da UML pode ser encontrada em Souza (2003). Tabela 2-2 Elementos do Diagrama de Classes Estendido (Fonte: Chavez (2004)) Elemento Representação Descrição Entrecorte 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. Define que um aspecto (o cliente) precede outro aspecto (o fornecedor). Precedência Isso significa que o comportamento do aspecto cliente tem precedência em relação ao comportamento do aspecto fornecedor no tipo de entrecorte que esperam realizar. Oferece uma conexão explícita entre um Requirement aspecto (o cliente) que requer a presença de outro aspecto (o fornecedor) para sua implementação ou funcionamento correto. Um relacionamento de entrecorte é representado como uma seta tracejada, com a parte final no elemento entrecortante e a parte inicial no elemento base, e o estereótipo <<crosscut>>. Cada associação relaciona um parâmetro definido na interface transversal do aspecto (nome da interface ou nome da operação) a um nome (ou seqüência de nomes) definido na interface de uma classe (nome de classe ou um nome de método). 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 parte inicial da seta (o fornecedor). O relacionamento requirement é apresentado como uma seta tracejada entre dois elementos do modelo e rotulada com o estereótipo <<require>>. O aspecto na parte final da seta (o cliente) requer a presença do aspecto na cabeça da seta (o fornecedor). A Figura 2-8 apresenta dois relacionamentos de entrecorteque associam o aspecto Observation a Button (ligando statechange a click) e ColorLabel (ligando update a colorcycle). O aspecto Observation intercepta o método click da classe Button, a estrutura da classe Button recebe atributos e operações novos listados no compartimento Additions 18
32 do aspecto Observation e seu comportamento é alterado por Observation no ponto de combinação definido (click). Observation também afeta a estrutura de instâncias de ColorLabel. Ainda na Figura 2-8, pode-se observar o aspecto Tracing, que rastreia chamadas a click e colorlabel. Um relacionamento precedence é representado do aspecto Observation ao aspecto Tracing. Isso significa que o comportamento de notificação ocorre antes do comportamento de rastreamento. A Figura 2-9 apresenta dois relacionamentos requirement: i) do aspecto Autonomy ao aspecto Interaction; e ii) do aspecto Adaptation ao aspecto Interaction. Figura 2-8 Diagrama de Classes Estendido (Fonte: Chavez (2004)) Figura 2-9 Relacionamento Requirement (Fonte: Chavez (2004)) 19
33 Diagrama de Colaboração e Diagrama de Interação Aspectuais Um Diagrama de Colaboração Aspectual oferece uma apresentação gráfica de uma colaboração aspectual, um tipo especial de colaboração que modela a realização de uma operação transversal definida dentro de um aspecto. Esse diagrama oferece suporte à visão de interação (interaction view) que envolve instâncias de aspectos e elementos base. A Tabela 2-3 apresenta uma breve descrição e as respectivas representações gráficas dos elementos que compõem o Diagrama de Colaboração Aspectual. Tabela 2-3 Elementos do Diagrama de Colaboração Aspectual (Fonte: Chavez (2004)) Elemento Representação Descrição Instância de Aspectos Tem identidade, pode ter estado, não podem ser explicitamente criadas ou destruídas e só podem ser tratadas dentro de aspectos. Elas são elementos de modelagem que podem ser objetos comuns no nível de implementação. Colaboração Aspectual Define um conjunto de papéis e um conjunto de interações que descreve a estrutura e a comunicação entre a instância de aspecto e de objetos que exercem os papéis definidos. Interação Aspectual (Ver Figura 2-10) Oferece uma conexão explícita entre um aspecto (o cliente) que requer a presença de outro aspecto (o fornecedor) para sua implementação ou funcionamento correto. A notação da instância de aspecto é derivada da notação de objeto, sendo representada por um losango acima. Por definição, as instâncias de aspecto são instâncias anônimas, portanto o nome da instância de aspecto é sempre omitido, mas o nome do aspecto que dá origem está sempre presente, usando a sintaxe: aspectname. 20
34 Uma colaboração aspectual possui (Figura 2-10): i) uma parte estática que descreve os papéis que objetos e instâncias de aspecto exercem; e ii) uma parte dinâmica que mostra os fluxos de mensagens ao longo do tempo para realizar o comportamento entrecortante de acordo com os papéis. Há três papéis de associação: i) um papel do aspecto para um objeto, que denota a base; ii) um papel do emissor para o receptor; e iii) um papel de associação do objeto base para a instância de aspecto. Figura 2-10 Interação Aspectual (Diagrama de Seqüência com Adornos) (Fonte: Chavez (2004)) A parte superior da Figura 2-11 apresenta uma colaboração aspectual para a operação statechange. Ela descreve o comportamento estendido de um objeto de um tipo denotado por Sender que chama a operação statechange. As melhorias incorporam a inserção de um link chamado aspect a partir do objeto base (denotado por Sender) até a instância de aspecto e a inserção de uma chamada na operação de entrecorte (statechange_) na sombra estática associada com o ponto de combinação dinâmico. Nesse caso, a chamada a statechange_ é inserida depois da chamada a statechange. As interações aspectuais são mostradas como Diagramas de Seqüência (da UML) com alguns adornos. A interação aspectual para a operação statechange é apresentada na parte inferior da Figura As colaborações e as interações aspectuais são apresentadas nos Diagramas de Colaboração Aspectuais e Diagramas de Interação Aspectuais, respectivamente. 21
35 Figura 2-11 Diagrama de Colaboração Aspectual para statechange_ (Fonte: Chavez (2004)) 2.5. Considerações Finais Neste capítulo, foram apresentados os principais conceitos sobre OA, abordando a sua origem e evolução e as abordagens sobre MOA. Pelo exposto, OA traz vários benefícios mediante a possibilidade de tornar os programas mais modulares. O objetivo da técnica é separar interesses transversais (crosscutting concerns), de modo a evitar o entrelaçamento de código com diferentes propósitos e o espalhamento de código com propósito específico em várias partes do software. Foram apresentadas algumas das abordagens para MOA existentes na literatura, enfatizando a abordagem asideml, que consiste de uma linguagem de modelagem criada para especificar e comunicar projetos OA. Não existe ainda uma convenção ou uma abordagem padrão, tal como a UML é para a OO, gerando a necessidade de levar as vantagens dos aspectos às etapas anteriores do processo de desenvolvimento de software. Isso decorre, pois as pesquisas em modelagem são recentes em relação às pesquisas em implementação. 22
36 3. TESTE DE SOFTWARE 3.1. Considerações Iniciais Este capítulo apresenta conceitos e terminologias envolvidos com as atividades de teste que devem ser realizadas durante o processo de desenvolvimento de software. Além disso, ele apresenta uma descrição sucinta da norma ISO/IEC 9126 e uma discussão sintética de testes e de testabilidade de software. A seção 3.2 apresenta a definição de qualidade e de qualidade de software, sob a visão de alguns autores relevantes da literatura. A seção 3.3 e a seção 3.4 apresentam breve discussão sobre a norma ISO/IEC 9126 sob o contexto de teste e de testabilidade de software. A seção 3.5 descreve as atividades relacionadas com o teste que devem ser executadas durante as fases do desenvolvimento de software. A seção 3.6 apresenta as diversas técnicas de teste existentes que auxiliam no projeto de casos de teste. A seção 3.7 e a seção 3.8 apresentam as estratégias de teste definidas na literatura para software OO e software OA Qualidade de Software Conforme Costa (2005), a literatura oferece várias definições de qualidade. A seguir, são apresentadas algumas destas definições: Crosby (1979) diz que qualidade significa conformidade do produto com os seus requisitos, que devem estar bem definidos, a fim de não serem mal-interpretados; Deming (1982) diz que qualidade é um grau previsível de uniformidade e dependência, baixo custo e satisfação no mercado, ou seja, qualidade é sempre aquilo que o cliente necessita e quer. Controle estatístico da qualidade, participação do trabalhador no processo de decisão e limitação das fontes de fornecimento são os passos para a sua abordagem [CÔRTES; CHIOSSI, 2001]; Feigenbaum (1994) diz que qualidade é uma estratégia que requer percepção de todos na empresa. Além disso, ele diz que é um compromisso para com a excelência, um modo de vida corporativa, um modo de gerenciamento. A liderança para a qualidade, a tecnologia moderna da qualidade e o compromisso organizacional são os passos da sua abordagem [CÔRTES; CHIOSSI, 2001]; ISO Std (1990) caracteriza o termo qualidade como a capacidade de satisfazer as necessidades implícitas e explícitas dos seus usuários;
37 Juran; Gryna Jr. (1970) dizem que qualidade significa conveniência para o uso, ou seja, os requisitos e as expectativas dos clientes devem ser considerados, uma vez que cada cliente pode usar o mesmo produto de maneiras diferentes; Rothery (1993) diz que qualidade significa adequação ao uso conforme as exigências, ou seja, o produto em questão deve realizar de maneira adequada a sua função. Considerando o contexto de software, o termo qualidade recebeu uma definição especial na norma ISO/IEC 9126 [ISO Std. 9126, 1991; ISO Std. 9126, 2001; ABNT NBR13596, 1996], na qual a qualidade é a totalidade das características de um software, que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas. As necessidades explícitas são requisitos para o desenvolvimento de software explicitamente sugerido pelo cliente ou obtidos na modelagem do problema. Por outro lado, as necessidades implícitas podem não ser explicitadas nem documentadas, mas devem estar presentes quando o software é usado em condições particulares; elas são necessidades subjetivas dos usuários, inclusive operadores, destinatários dos resultados do software e os mantenedores. Estas necessidades, também chamadas de fatores externos, podem ser percebidas pelos desenvolvedores e usuários. Outra denominação utilizada trata da qualidade em uso e deve permitir a usuários atingir metas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado [GOMES, 2001]. No entanto, os problemas relacionados com a Engenharia de Software e com o gerenciamento de qualidade decorrem da situação do termo qualidade possuir diferentes definições, conduzindo a mal-entendidos [TOLEDO, 1987]. Conforme Kan (1995), isto pode ocorrer, pois: o termo qualidade possui um único sentido, mas com conceitos multidimensionais a quem se interessa, os seus pontos de vista e os atributos de qualidade relevantes para cada um deles; para cada conceito, há níveis de abstrações diferentes, ou seja, um grupo de pessoas pode referir-se à qualidade com sentido geral e outro grupo referir-se com sentido específico; o termo qualidade está presente na linguagem diária das pessoas. Assim, a visão popular pode entrar em conflito com a visão profissional visão da Engenharia de Software e visão do gerenciamento da qualidade. Na visão popular, o termo qualidade 24