Desenvolvimento Baseado em Modelos e Teste de Software

Transcrição

1 Desenvolvimento Baseado em Modelos e Teste de Software Paulo Gabriel Gadelha Queiroz 1 Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo (USP) Caixa Postal São Carlos SP Brazil pgabriel@icmc.usp.br Abstract. Model Driven Development (MDD) concentrates on the importance of models in the software life cycle, making them part of the final product. Thus, models are kept as simple as possible, and most of the complexity of the software belongs to the transformations that can be automatically obtained by application generators. This helps to increase the quality of the final product, as well as easing the future evolution of the software, that can be done by changing the high level models and automatically obtaining a new product.even in this context where code is generated automatically, the software testing activity is still needed and is realized in the models and in the transformations rules, once they are hand-made activities done by developers. There is the possibility to automatic generate test code and test cases based on models, through a tecnic know as model driven test. This paper presents an overview of MDD and software testing, addressing the tools and aproaches used in this kind of development and software test. Resumo. O desenvolvimento baseado em modelos (MDD) concentra-se na importância de modelos no ciclo de vida do software, tornando-os parte do produto final. Assim, mantêm-se os modelos simples, e a maioria da complexidade do software pertencerá às transformações que podem ser obtidas automaticamente por geradores de aplicações. Isso ajuda a aumentar a qualidade do produto final, bem como facilitar a futura evolução do software, que poderá ser feita mudando-se os modelos de alto nível e obtendo-se, de forma automática, o novo produto. Mesmo nesse contexto de geração de código automatizada, existe ainda, a necessidade da existência da atividade de teste, a qual é realizada nos modelos e nas regras de transformação, pois são atividades realizadas de forma manual pelo desenvolvedor. Existe ainda a possibilidade de geração automática do código e dos casos de teste com base em modelos, por meio da utilização de teste baseado em modelos (MDT). Esse artigo apresenta uma visão geral do estado da arte de MDD e teste de software, mostrando as abordagens e ferramentas utilizadas nesse tipo de desenvolvimento e teste de software. 1. Introdução Desde que foi criado, o computador vem ocupando cada vez mais espaço na vida das pessoas, as vezes até de forma imperceptível. O software é responsável pela maioria das funcionalidades existentes em um computador, e sua complexidade tem crescido muito ao longo dos anos. Chegou-se a um ponto no qual o software deve ser além de confiável, operar em ambientes computacionais embarcados e distribuídos, comunicar-se utilizando uma grande variedade de paradigmas de comunicação, e se adaptar dinamicamente a

2 mudanças nos ambientes operacionais [France and Rumpe 2007]. Além disso, o tempo de desenvolvimento deve ser reduzido para atender as necessidades de mercado (time-tomarket). Isso se deve às tecnologias utilizadas, que se tornaram significativamente mais complexas nos últimos anos, e ao fato dessas tecnologias mudarem mais rapidamente do que os negócios para os quais elas procuram dar apoio [Kent 2002]. Desse modo, se faz necessário a utilização de uma metodologia de engenharia mais disciplinada. O desenvolvimento baseado em modelos (do inglês Model-Driven Development ou MDD) é uma abordagem de desenvolvimento de software que surgiu para resolver esses problemas. O MDD enfatiza a importância de modelos no processo de desenvolvimento de software [Mellor et al. 2003]. No MDD, os modelos passam a fazer parte do produto final de software, assim como o código. A ideia é aumentar o nível de abstração do desenvolvimento, por meio da utilização de modelos de alto nível para proteger os desenvolvedores das complexidades da plataforma de implementação [France and Rumpe 2007], e ainda, realizar transformações nos modelos até gerar artefatos de implementação automaticamente, de forma a refletir a solução expressa nos modelos [Schmidt 2006]. Uma vez que o código é gerado de forma automatizada por meio das transformações de modelos, pode-se imaginar que realizar testes nesse contexto passa a ser redundante e sem sentido. Contudo, mesmo supondo a corretude dos motores de transformações utilizados, ainda existem artefatos feitos manualmente pelos desenvolvedores e sujeitos a erros, tais como os próprios modelos desenvolvidos e as regras de transformações. Portanto, o objetivo desse artigo é apresentar as técnicas de teste utilizadas no contexto de MDD. Esse artigo está dividido como segue. Na seção 2, são apresentados os conceitos de MDD. Na seção 3, são apresentadas as técnicas de teste utilizadas em MDD. Na seção 3.3, apresenta-se a abordagem de teste baseado em modelos. Por fim, na seção 4, são apresentadas as conclusões desse trabalho. 2. Desenvolvimento baseado em modelos O MDD tem como ideia principal reconhecer a importância dos modelos no processo de software, não apenas como um guia para tarefas de desenvolvimento e manutenção, mas como parte integrante do software. Também é conhecido como MDE (Model- Driven Engineering) [Schmidt 2006] ou MDSD (Model-Driven Software Development) [Völter and Groher 2007]. A proposta do MDD é fazer com que o engenheiro de software não precise interagir manualmente com todo o código-fonte, podendo se concentrar em modelos de mais alto nível, ficando protegido das complexidades requeridas para implementação nas diferentes plataformas. Um mecanismo automático é responsável por gerar automaticamente o código a partir dos modelos. Neste cenário, modelos não são apenas um guia, ou uma referência. Eles fazem parte do software, assim como o código fonte. O MDD surgiu como uma técnica que visa resolver diversos problemas existentes durante o ciclo de desenvolvimento de um software, tais como: evitar que os modelos gerados fiquem desatualizados em relação ao código fonte gerado; facilitar o reúso em níveis mais altos de abstração (modelos); aumentar a produtividade, uma vez que alterar modelos é mais simples do que alterações em códigos fonte; e, facilitar a validação e

3 manutenção do software, entre outros. Com a utilização do MDD pode-se evitar que o desenvolvedor precise executar as tarefas repetitivas necessárias para a transformação de modelos para o código final executável. Isto é alcançado por meio da automação dessas transformações. O tempo gasto nessas tarefas, que no desenvolvimento convencional (não orientado a modelos) inibe a execução do ciclo completo dos requisitos aos testes, é significativamente reduzido, fazendo com que mesmo atividades de urgência, como correção de erros, possam ser executadas sem produzir inconsistência com os modelos, mantendo-os sempre atualizados. Para possibilitar a criação de modelos, é necessária uma ferramenta de modelagem, por meio da qual o engenheiro de software produz modelos que descrevem os conceitos do domínio. Os modelos por ela criados precisam ser semanticamente completos e corretos, uma vez que devem poder ser compreendidos por um computador, e não um ser humano, capaz de corrigir pequenos enganos ou preencher lacunas por si só. O elemento que implementa estas características é normalmente uma linguagem específica de domínio, ou DSL [Lucrédio 2007]. Os modelos servem de entrada para transformações que irão gerar outros modelos ou o código-fonte. Para definir as transformações, é necessária uma ferramenta que permita que o engenheiro de software construa regras de mapeamento de modelo para modelo, ou de modelo para código. Idealmente, essa ferramenta deve possibilitar que as regras de mapeamento sejam construídas da forma mais natural possível, uma vez que a construção de transformadores é uma tarefa complexa. Por fim, é necessário um mecanismo que efetivamente aplique as transformações definidas pelo engenheiro de software. Esse mecanismo deve não só executar as transformações, mas também manter informações de rastreabilidade, possibilitando saber a origem de cada elemento gerado, seja no modelo ou no código-fonte [Lucrédio 2007]. Na Figura 1, apresenta-se um típico processo de desenvolvimento baseado em MDD. Observa-se que o desenvolvedor não mais manipula código fonte na sua IDE favorita, mas utiliza uma ferramenta de modelagem para elaborar os modelos do software em desenvolvimento, define as regras de transformações que devem ser seguidas e utiliza um mecanismo executor de transformações para gerar outros modelos ou mesmo código fonte. Figure 1. Processo de desenvolvimento utilizando MDD.

4 Embora existam diversas abordagens de MDD, a OMG (Object Management Group) definiu uma realização particular e usou, para nomeá-la, o termo Model Driven Architecture (MDA) [OMG 2003]. A seguir serão descritas as principais características do MDA MDA O MDA Introduz os conceitos de CIM (Computation Independet Model), PIM (Plataform Independet Model) e PSM (Platform-Specific Model). Um CIM representa uma visão do sistema de um ponto de vista não computacional, ou seja, ele não apresenta detalhes da estrutura do sistema e é conhecido como modelo de domínio, pois utiliza um vocabulário comum aos profissionais e especialistas no domínio em questão [OMG 2003]. Um PIM representa uma visão do sistema de forma independente da plataforma de implementação. A idéia é que esse modelo seja genérico o suficiente para que possa ser reaproveitado em diferentes plataformas de implementação [OMG 2003]. Um PSM representa uma visão do sistema do ponto de vista de uma plataforma específica. Ele combina as especificações de um PIM com detalhes sobre como o sistema utiliza aquele tipo particular de plataforma [OMG 2003]. A ideia por trás do MDA consiste em se realizar transformações sucessivas entre modelos até que se chegue ao código fonte. Percebe-se que a transformação entre CIM e PIM é menos passível de automação quando comparada a transformação de PSM para código, pois envolve mais decisões e maiores possibilidades de interpretações dos requisitos. O MDA utiliza como base o meta-modelo, chamado MOF (Meta-Object Facility), que serve como base para a definição de todas as linguagens de modelagem. Por meio do MOF permite-se que as ferramentas de modelagem e transformação possam trabalhar em conjunto. Ele consiste de um padrão orientado a objetos que permite a definição de classes com atributos e relacionamentos, de tal forma que é muito semelhante ao diagrama de classes da UML (Unified Modeling Language). O MDA define também o XMI (XML Metadata Interchange), que é um formato para representar modelos em XML e o QVT (Queries/Views/Transformations), que define uma linguagem textual e uma notação para definir consultas e transformações baseadas no MOF. Embora tenha uma proposta de ser genérica, podendo trabalhar com qualquer linguagem de modelagem, o MDA tem grande foco na UML. Por exemplo, perfis UML são o mecanismo preferido para representação de conceitos específicos de plataforma em um PSM. Existem ainda abordagens MDD desenvolvidas pela Sun Microsystems, que foca no MDD por meio da utilização do NetBeans e pela IBM que usa o eclipse como foco para realização de MDD Vantagens e desvantagens do MDD Assim como qualquer outra abordagem de desenvolvimento, a utilização de MDD não só trás benefícios ao longo do desenvolvimento como também pode apresentar pontos

5 negativos em alguns casos. Entre os pontos positivos do uso de MDD destacam-se: aumento de produtividade, pois reduz-se o tempo de desenvolvimento uma vez que a codificação passa a ser feita de forma automatizada; maior portabilidade, pois o desenvolvedor elabora modelos em mais alto nível que podem ser utilizados para gerar código em diferentes ambientes/plataformas; facilidade de prover interoperabilidade, visto que cada parte do modelo pode ser transformado em código para uma plataforma diferente, resultando em um software que executa em um ambiente heterogêneo, porém mantendo a funcionalidade global; facilitação da manutenção e documentação, visto que a manutenção passa a ser feita em modelos de mais alto nível e eles passam a ser parte tanto do software quanto da especificação. maior reutilização, pois segundo [Krueger 1992] a reutilização em mais alto nível, tais como projeto e arquitetura proporciona maiores benefícios em relação a reutilização de artefatos de códigos. facilitação das verificações e otimizações, pois modelos oferecem maior facilidade para verificadores e ainda podem ser realizadas otimizações automáticas específicas de domínio. corretude, pois além do fato de geradores não introduzirem erros acidentais, como erros de digitação, eles permitem que a identificação de erros conceituais aconteça em um nível mais alto de abstração. Conforme foi comentado anteriormente, mesmo que muitas vantagens possam ser enumeradas, todas as abordagens existentes apresentam desvantagens, e dessa forma, pode-se destacar as seguintes desvantagens da utilização de MDD: aumento da rigidez, pois grande parte do código é gerado e fica fora do alcance do desenvolvedor; maior complexidade, pois os artefatos necessários para utilização do MDD, tais como ferramentas de modelagem e geradores de código, introduzem complexidade adicional ao processo, visto que são difíceis de construir e manter; perda de desempenho, pois mesmo que algumas otimizações possam ser realizadas pelos geradores, eles acabam incluindo muito código desnecessário, por conseguinte, o resultado pode não apresentar resultados satisfatórios de desempenho, quando comparado ao código escrito a mão; maior curva de aprendizado, pois o desenvolvimento dos artefatos específicos de MDD exigem habilidade na construção de linguagens, ferramentas de modelagem, transformação e geradores de código; alto investimento inicial, pois é necessário montar uma infraestrutura de reutilização orientada a modelos que requer mais tempo e esforço. No entanto, os ganhos posteriores podem ser significativos e podem compensar esse alto investimento inicial Geradores de Aplicações Geradores de aplicações são ferramentas capazes de gerar artefatos a partir de uma especificação. A especificação descreve o problema ou tarefa a ser feita pelo artefato. Essa especificação pode ter a forma de um diálogo interativo, onde o usuário seleciona

6 as opções desejadas a partir de uma série de menus, pode aparecer de uma forma gráfica, onde o usuário edita um diagrama ou pode ser escrita em alguma linguagem. Os artefatos gerados pelo gerador de aplicações podem ser segmentos de código, sub-rotinas, sistemas de software, entre outros. Geradores de aplicações tem como objetivo maximizar a automação do desenvolvimento de aplicações por meio do uso de software customizado reusável [Cleaveland 1988, Czarnecki et al. 2002]. Pode-se dizer que um gerador de aplicações funciona de forma semelhante a um compilador, traduzindo as informações em alto nível para implementação de baixo nível. Alguns tipos são compiladores para linguagens de programação específicas de domínios (DSLs), esse termo é usado para descrever linguagens de programação para tarefas especializadas. Embora os compiladores possam ser vistos como geradores, a pesquisa e prática em geradores de aplicações foca em diferentes problemas daqueles tratados por compiladores, tais como transformação de programas [Smaragdakis and Batory 2000]. Sempre que for necessário modificar o produto, basta alterar as especificações de entrada e executá-las novamente no gerador de aplicação. Na Figura 2 apresenta-se o processo de desenvolvimento de uma aplicação ou código utilizando um gerador de aplicações típico. Os quadrados representam arquivos e as elipses representam programas executáveis. O processo inicia-se com uma especificação que é submetida ao gerador de aplicação. O gerador transforma essa especificação em um programa ou código por exemplo. Esse programa passa por um compilador de sua linguagem específica, que gera o executável. A aplicação gerada recebe entradas, processa e gera uma saída correspondente. Figure 2. Utilização de um gerador de aplicações (adaptado de [Cleaveland 1988]). Um dos principais problemas dos geradores é que podem ser usados efetivamente

7 somente em alguns tipos de aplicação [Cleaveland 1988]. Para minimizar esse problema, foram criados os geradores de aplicação configuráveis (GAC). Os GACs são geradores que podem ser adaptados para trabalharem com diferentes domínios. Um GAC configurado para um certo domínio deve apresentar as mesmas características de um gerador de aplicação específico, ou seja, receber uma especificação, armazená-la em meio persistente, permitir a edição e reedição dessa especificação, validá-la e transformá-la em artefatos de software. A configuração de um GAC pode ser uma atividade menos custosa do que a construção de um gerador de aplicações específico [Shimabukuro 2006]. Seção 2.3.1, apresenta-se o um gerador de aplicação configurável. Para construir um gerador de aplicações é necessário ter conhecimento sobre o domínio da aplicação. [Cleaveland 1988] destacou sete etapas necessárias para o desenvolvimento de um gerador de aplicações: 1. Reconhecimento de domínios, iniciado na maioria dos casos por meio do reconhecimento de padrões [Cleaveland 1988]. 2. Definição das fronteiras do domínio. 3. Definição do modelo subjacente. 4. Definição das partes fixas e variantes. 5. Definição da especificação de entrada. 6. Definição dos produtos. 7. Implementação do gerador Captor O Captor [Shimabukuro 2006] é um GAC que possui o objetivo de facilitar a geração de artefatos de software em diferentes domínios. Entre os artefatos que o captor pode gerar estão: código, documentação e testes. Esse gerador permite a definição de domínios com diferentes arquitetura de software. O Captor possui quatro módulos, conforme é mostrado na Figura 3. O módulo de gerenciamento de projetos é responsável por fazer a criação, manutenção e a remoção de projetos. O módulo de gerenciamento de domínio cria uma estrutura de dados para representar o domínio escolhido pelo usuário para ser usada pelos outros módulos do gerador. O módulo de gerenciamento de interface apresenta as janelas para o usuário. Por fim, o módulo de transformação de gabaritos gera os artefatos. O Captor se baseia em arquivos XML e gabaritos XSL para realizar a configuração para domínios específicos. Para utilizar o Captor corretamente é necessário seguir os seguintes passos: especificar a linguagem de modelagem de aplicação (LMA) em um conjunto de formulários organizados hierarquicamente em forma de árvore; criar gabaritos para cada artefato que deve ser gerado; fornecer um arquivo de mapeamento de transformação de gabaritos baseado na MTL (Mapping Transformation Language) definida por [Shimabukuro 2006]; configuração do captor e da ferramenta Ant [Davidson et al. 2009] para realização de pré e pós-processamentos específicos nos artefatos gerados. O Captor foi posteriormente atualizado para permitir a geração de software que utilize mais de um domínio. A nova versão do Captor é chamada de Captor-AO

8 Engenheiro de Aplicação Especificação GUI Gerenciamento de Domínio Configuração de Domínio Dados do Projeto + Especificação (XML) Motor de Transformação de Gabaritos Gerenciamento de Projeto Gabaritos Engenheiro de Domínio Figure 3. Arquitetura do Captor (adaptado de [Shimabukuro 2006]). [Pereira Júnior 2008], pois utiliza aspectos para a composição dos domínios. Com o Captor-AO, o engenheiro de aplicações pode utilizar um domínio principal, chamado de domínio base, e opcionalmente mais alguns domínios transversais compatíveis com o domínio base escolhido para compor as aplicações. Além dessa possibilidade de composição de aplicações com mais de um domínio o Captor-AO incorporou diversas melhorias relacionadas a usabilidade do Captor. 3. Teste de software no contexto de MDD O teste de software é uma atividade presente na maioria dos processos de desenvolvimento e visa garantir que o produto de software atende aos requisitos que foram definidos para ele. Entre esses requisitos destacam-se: garantir que o software está correto (correção); garantir que ele atende aos requisitos de desempenho; e garantir que ele é seguro. O teste de software não é a única atividade com esse objetivo, mas tem-se mostrado a mais utilizada e eficiente. Conforme foi visto na seção anterior o MDD visa automatizar o processo de desenvolvimento por meio da utilização de modelos de alto nível, transformações entre modelos e geração automática de código. Nesse contexto, surge a dúvida se o teste de software passa a ser uma atividade redundante e dispendiosa [Rutherford et al. 2003]. Afinal, o que deve-se testar quando utiliza-se o desenvolvimento baseado em modelos para produzir software? Em um primeiro momento testa-se a infraestrutura criada para o MDD, ou seja, as ferramentas a serem utilizadas. Para isso, são utilizadas todas as técnicas de testes convencionais (teste funcional, estrutural e análise de mutantes) e não interessam ao escopo deste artigo. Supondo que as ferramentas estão de acordo com o que espera-se delas e que elas de fato geram código correto e livre de erros, o foco do teste no MDD são as transformações entre modelos e o produto final de software. Caso encontrem-se erros no software, ocorreram problemas na transformação entre os modelos ou os modelos iniciais estavam incorretos. Existem basicamente duas vertentes de teste em MDD: Teste de

9 transformação entre modelos; teste baseado em modelos. Enquanto a primeira foca no teste de software desenvolvido com a utilização de MDD a segunda foca na utilização de técnicas de MDD para automatizar a derivação de casos de teste. Essas técnicas serão detalhadas a seguir Teste de transformação entre modelos A correção de uma transformação de modelos pode ser determinada com a verificação se a saída da transformação satisfaz seus objetivos, ou seja, se não existem diferenças entre o modelo esperado e o modelo de saída. Neste tipo de estratégia assumi-se que o motor de transformação está correto e que o modelo de entrada foi especificado corretamente. Isso significa que a especificação da transformação entre modelos é o único artefato que precisa ser validado e verificado [Lin et al. 2004]. Pode-se garantir a correção dessa especificação de várias formas, mas em geral recorre-se a duas alternativas: aplicar métodos formais em uma prova de corretude; e os testes de execução. Os teste de execução apresentam diversas vantagens que o tornam o método mais efetivo para determinar se a tarefa (transformação de modelos) foi executada corretamente, tais como: a relativa facilidade com que muitas atividades de teste podem ser executadas; o software desenvolvido pode ser executado no seu ambiente esperado de execução; grande parte do processo de teste pode ser automatizado. Assim como o teste de software convencional, o teste de especificação de modelos de transformação pode apenas mostrar a presença de erros na especificação e não garantir sua ausência. Contudo, mesmo sendo uma alternativa mais aplicável que os métodos formais, pode ser bem efetiva em revelar a presença de erros [Lin et al. 2004]. As atividades básicas de testes consistem em projetar casos de teste, executar o software com esses casos de teste e analisar os resultados produzidos por essas execuções. Assim, define-se o teste de transformação de modelos como a execução de uma especificação de transformação determinística com dados de teste (ou seja, entrada para casos de teste) e uma comparação entre os resultados reais (ou seja, o modelo obtido), com a saída esperada (ou seja, o modelo esperado), que devem satisfazer a intenção da transformação. Se não existem diferenças entre o modelo obtido e modelos esperado, pode-se inferir que a transformação do modelo está correta com relação à especificação dos testes. Se existem diferenças entre o modelo obtido e modelos esperado, a especificação da transformação precisa ser revista e modificada [Lin et al. 2004]. Apresenta-se na Figura 4 um framework para teste de especificação de transformação de modelos que consiste da geração de testes, execução de testes e documentação de testes automaticamente. Esse framework possui basicamente três componentes principais: o construtor de casos de teste, recebe como entrada a especificação de teste e produz casos de teste para a especificação de transformação a ser testada; o motor de teste, recebe como entrada os casos de teste gerados para os executar no modelo de entrada e ainda compara o modelo gerado com o modelo esperado; e por fim, o analisador de testes que recebe os resultados do motor de teste e permite a navegação entre as diferenças encontradas nos modelos. Uma das partes críticas do framework apresentado é a comparação de modelos. A principal tarefa da comparação de modelos é calcular o mapeamento e as diferenças entre os modelos. A comparação de modelos é utilizada para descobrir diferenças entre

10 Figure 4. Framework para teste de especificação de transformação de modelos (adaptado de [Lin et al. 2004]). o modelo esperado e o modelo gerado. Visto que a comparação de modelos feita de forma manual é uma atividade tediosa, consome muito tempo e é sujeita a erros, sugerese a automação dessa atividade. [Lin et al. 2004] levantou uma série de problemas que precisam ser explorados mais profundamente para atingir o objetivo de automatizar a comparação de modelos, dos quais destacam-se: Que propriedades dos modelos precisam ser comparadas? Em geral compara-se as propriedades estruturais dos modelos para descobrir diferenças. Contudo, as propriedades estruturais podem variar de acordo com a linguagem de modelagem. Por esse motivo utiliza-se o MOF da OMG em todas as linguagens de modelagem para o MDA; outro problema é a definição e representação do mapeamento e diferenças entre os modelos, as diversas abordagens existentes variam entre si; o último problema nesse contexto é a possibilidade da existência de múltiplos mapeamentos tais que o resultado da comparação de modelos não seja único. Em que nível deve-se comparar os modelos? Os modelos são geralmente renderizados em uma notação gráfica e podem ser persistidos em uma linguagem intermediária como o XML (Extensible Markup Language) [W3C 2008]. Com isso, torna-se possível comparar os modelos por meio da sua representação via XML. Contudo, alguns problemas surgem dessa abordagem tornando-a inviável Geração automática de casos de teste Com um apropriado nível de detalhe na especificação de componentes específicos de domínio é possível automatizar a geração de alguns ou todos os casos de teste. Visto que nem todo código de um sistema feito com MDD é gerado automaticamente. Acontece o mesmo com os casos de teste, pois para o código que é escrito a mão deve-se fazer casos de teste de forma tradicional. Dessa forma apresenta-se nesta subseção o trabalho de [Rutherford et al. 2003], que tem uma abordagem de geração automática de casos de teste baseada na utilização da ferramenta MODEST (Model-Driven Enterprise System Transformer).

11 A ferramenta MODEST é semelhante a ferramenta Captor-AO apresentada na seção Ela não implementa o padrão MDA. Contudo, existem muitas similaridades, de tal forma que, muitas das lições aprendidas com o MODEST podem ser rapidamente aplicadas as ferramentas MDA. O MODEST recebe como entrada uma especificação do sistema e templates de código, por fim o desenvolvedor implementa operações específicas de domínio e os casos de teste para elas. A geração de artefatos é feita por meio de um conjunto de transformações XSL. Ao fim do desenvolvimento o desenvolvedor entrega ao cliente tanto a aplicação quanto os códigos de teste. Na Figura 5, são apresentadas as entradas para o MODEST e suas possíveis saídas. Figure 5. Utilização do MODEST [Rutherford et al. 2003]. A utilização dessa ferramenta permite que o código de teste seja gerado em paralelo com o código da aplicação e que seja usado para validar e certificar atividades em tempo de desenvolvimento. Entre as possibilidades de geração de código de teste têm-se: geração de código para instanciar objetos gerenciados e estáticos representativos; geração de casos de teste para validar implementação de objetos estáticos; geração de casos de teste para validar implementações de objetos gerenciados; e geração de framework de teste para facilitar o teste de lógica específica de domínio. Com a utilização dessa ferramenta gera-se testes de unidade e testes de integração. O foco dessa abordagem é a apresentar a ferra MODEST e demonstrar que ela pode ser utilizada tanto para geração aplicações, quanto para geração de casos de teste de forma automatizada. Uma abordagem mais promissora é apresenta na subseção a seguir Teste baseado em modelos O teste baseado em modelos (MDT) apresenta-se como a mais promissora das abordagens, pois utiliza padrões e apresenta-se mais amadurecido que as outras abordagens. O

12 MDT consiste de três atividades: a geração de casos de teste a partir de modelos de acordo com um dado critério de cobertura; geração de um oraculo de teste para determinar o resultado esperado de um teste; e execução de testes no ambiente de teste, possivelmente gerado a partir de modelos [Born et al. 2004]. As atividades um e dois são independentes de plataforma. Em contrapartida, a execução dos testes tem lugar em uma determinada plataforma, seja ela uma plataforma de teste genérica para testar a lógica do aplicativo, ou uma plataforma de destino real da aplicação. Neste último caso, os modelos específicos de plataforma são necessárias para gerar ambientes de teste e mapear casos de teste independente de plataforma e oráculos sobre a plataforma desejada [Born et al. 2004]. Os casos de teste independente de plataforma são conhecidos como PIT e são gerados a partir do PIM. O PIT é mapeado posteriormente para plataformas alvo específicas. Os modelos independentes de plataforma servem como oráculos de teste. Para utilizar essa estratégia de teste utiliza-se o perfil UML U2TP (UML 2 Test Profile). Na Figura 6, apresenta-se os passos da utilização do MDT. Figure 6. MDT [Dai 2004]. O perfil U2TP introduz 4 conceitos lógicos para definir a linguagem de modelagem de um sistema de teste: a arquitetura de teste, o comportamento de teste, os dados de teste e o tempo. A arquitetura de teste define um ou mais objetos para serem testados e chama-os de SUT (System Under Test). Uma arquitetura de teste possui: os componentes de teste, que são objetos dentro do teste de sistema que podem se comunicar com o SUT para realizar o comportamento de teste; contexto de teste, que permitem aos usuários agrupar os casos de teste para descrever uma configuração de teste; arbitragem, que corresponde a uma maneira de avaliar um veredito para um contexto de teste; e um escalonador, que avalia um veredito para um contexto de teste [Heckel and Lohmann 2003]. O comportamento de teste define o propósito do teste. Utilizam-se os diagramas de interação UML para definir os estímulos de teste, observações, controle/invocação de testes, coordenações e ações. Os casos de teste determinam o comportamento normativo dos testes e correspondem a uma operação do contexto de teste que especifica como um

13 conjunto de componentes interage com o SUT. Um veredito de teste pode retornar : pass, inconclusive, fail ou error. Os dados de teste são de dois tipos: wildcards, que são usados para manipular eventos inesperados; e data pools, que são associados com o contexto de teste e incluem os dados de teste concretos. Para recuperar os dados de teste da data pool utiliza-se as operações chamadas seletores de dados. por fim, são definidas regras de codificação que permitem ao testador definir a codificação e decodificação dos dados de teste quando comunicados com o SUT. Para dar suporte a testes específicos define-se os conceitos de restrição e controle de comportamentos de teste com relação ao tempo. Para isso utilizam-se temporizadores e zonas de tempo. A utilização de todos esses conceitos para elaboração dos teste baseados em modelos acontece de acordo com o seguinte processo: defini-se um novo pacote UML como o pacote de teste do sistema, importa-se as classes e interfaces do sistema para o novo pacote, inicia-se a partir da especificação da arquitetura de teste e depois continua-se com a especificação do comportamento de teste, por fim, adiciona-se dados de teste e tempo nas especificações da arquitetura (Zona de tempo e data poll) e do comportamento de teste (Temporizador ou particionamento de dados) [Dai 2004]. Na Figura 7, apresenta-se um exemplo de criação de teste com U2TP. Figure 7. MDT [Dai 2004]. 4. Conclusão Conforme foi apresentado no artigo, a abordagem de desenvolvimento baseado em modelos vem ganhando grande atenção na academia e na industria, principalmente com a utilização da abordagem MDA da OMG. Mesmo nesse contexto, no qual boa parte do código passa a ser gerado automaticamente a atividade de teste de software continua a ter grande importância para a garantir a qualidade do software. Apresentou-se ainda as duas principais abordagens de teste no contexto de MDD. Na primeira, foca-se em testar as especificações das transformações entre modelos para garantir a corretude do software gerado. A segunda abordagem foca na automatização da atividade de testes por meio da utilização de uma abordagem semelhante ao MDD, o MDT. Embora as iniciativas sejam

14 promissoras, percebe-se que as pesquisas ainda estão muito incipientes na área, pois ainda falta muitos detalhes desse processo de teste. References Born, M., Schieferdecker, I., gerhard Gross, H., and Santos, P. (2004). Model-driven development and testing - a case study. In University of Twente, pages Cleaveland, J. C. (1988). Building application generators. IEEE Softw., 5(4): Czarnecki, K., Østerbye, K., and Völter, M. (2002). Generative programming. In ECOOP Workshops, pages Dai, Z. R. (2004). Model-driven testing with uml 2.0. Technical report, Computing Laboratory, University of Kent. Davidson, D. J., Atherton, B., Bailliez, S., and Ensin, M. B. (2009). The Apache Ant Project. Programa de computador. France, R. and Rumpe, B. (2007). Model-driven development of complex software: A research roadmap. In FOSE 07: 2007 Future of Software Engineering, pages 37 54, Washington, DC, USA. IEEE Computer Society. Heckel, R. and Lohmann, M. (2003). Towards model-driven testing. Kent, S. (2002). Model driven engineering. In IFM 02: Proceedings of the Third International Conference on Integrated Formal Methods, pages , London, UK. Springer-Verlag. Krueger, C. W. (1992). Software reuse. ACM Comput. Surv., 24(2): Lin, Y., Zhang, J., and Gray, J. (2004). Model comparison: A key challenge for transformation testing and version control in model driven software development. In Control in Model Driven Software Development. OOPSLA/GPCE: Best Practices for Model- Driven Software Development, pages Springer. Lucrédio, D. (2007). Uma Abordagem Orientada a Modelos para Reutilização de Software. PhD thesis, Sao Carlos, SP, Brasil. Director-Renata Pontin de Mattos Fortes. Mellor, S. J., Clark, A. N., and Futagami, T. (2003). Guest editors introduction: Modeldriven development. IEEE Software, 20: OMG (2003). Mda guide version Pereira Júnior, C. A. d. F. (2008). Geração de aplicações para linhas de produtos orientadas a aspectos com apoio da ferramenta Captor-AO. Master s thesis, Universidade de São Paulo, São Carlos, SP. Rutherford, M. J., Wolf, A. L., Rutherford, C. M. J., Wolf, E. L., and Wolf, E. L. (2003). A case for test-code generation in model-driven systems. In In International Conference on Generative Programming and Component Engineering (GPCE) 2003, pages Springer-Verlag. Schmidt, D. C. (2006). Model-driven engineering. IEEE Computer, 39(2). Shimabukuro, J. E. K. (2006). Um gerador de aplicações configurável. Master s thesis, ICMC-USP.

15 Smaragdakis, Y. and Batory, D. (2000). Application generators. In in Software Engineering volume of the Encyclopedia of Electrical and Electronics Engineering, pages John Wiley and Sons. Völter, M. and Groher, I. (2007). Product line implementation using aspect-oriented and model-driven software development. In SPLC, pages IEEE Computer Society. W3C (2008). Extensible Markup Language (XML). internet.