UDT ï Uma Ferramenta para Geração de Testes de Designpet/Artigos/007.pdfNós seguimos uma abordagem MDA ... conformidade entre design e implementação é uma prática que promove

UDT ï Uma Ferramenta para Geração de Testes de Design

Waldemar Pires1, Franklin Ramalho1, Dalton Serey1, Anderson Ledo1

1 Departamento de Sistemas e Computação, Universidade Federal de Campina Grande, Campina Grande, Brasil

{neto, franklin, Dalton, ledo}@dsc.ufcg.edu.br

Abstract. In this work we present UDT (UML Design Testers), a tool that automatically generates design tests to check the conformance between a system implementation in Java and its UML class diagram. We fully pursued MDA as the approach for generating the design tests and hence we used several MDA artifacts, such as metamodels, models and transformations. A prototype of this tool has been implemented and evaluated, by performing several experiments on simple scenarios of conformance checking. Simple designs involving classes, associations, inheritance have been automatically checked.

Resumo. Neste trabalho apresentamos UDT (UML Design Testers), uma ferramenta capaz de gerar automaticamente testes de design que verificam a conformidade entre o código de um sistema implementado em Java e os diagramas de classe UML desse sistema. Nós seguimos uma abordagem MDA para a geração automática dos testes de design, adotando vários artefatos de MDA: meta-modelos, modelos e transformações. Um protótipo dessa ferramenta foi desenvolvido e foram executados vários testes para designs simples. A especificação desses designs envolveu classes, associações e generalização.

1. Introdução

Uma atividade comum e fundamental a todo processo de software é o design do software. O design incorpora a descrição da estrutura do software, os dados que são manipulados pelo sistema, a descrição das interfaces entre os componentes do sistema, e algumas vezes o algoritmo usado [Sommerville 2004]. O design implementa importantes decisões sobre a arquitetura do software e possui um papel crucial no desenvolvimento, implantação e evolução do sistema [Kruchten et al. 2006]. Sendo assim, o design atua como o elo entre os requisitos e a implementação do software.

Contudo, nem sempre a implementação reflete o design proposto. De fato, com base em nossa experiência, isso raramente acontece. Em particular, porque a documentação que expressa o design é, com freqüência, imprecisa e/ou obsoleta. Esta inconsistência entre design documentado e implementação tem sido apontada, por vários pesquisadores, como uma das principais causas de baixa qualidade de software [Parnas 1994, van Gurp and Bosch 2002]. Neste contexto, a verificação de conformidade entre design e implementação é uma prática que promove a qualidade de software. Em particular, é especialmente relevante em processos de desenvolvimento que em que há uma clara distinção entre artefatos de design e de implementação, como por exemplo, o RUP [Hesse, 2001]. E, especialmente, se equipes diferentes

2nd Brazilian Workshop on Systematic and Automated Software Testing

64

desenvolvem os artefatos de design e de implementação. Porém, a verificação de conformidade entre design e implementação é ainda uma área pouco explorada na engenharia de software com poucas ferramentas de automação disponíveis. As ferramentas e técnicas disponíveis focam na verificação do comportamento do sistema em detrimento da sua organização interna ou estrutura.

Em trabalhos anteriores, para verificar a conformidade entre design e implementação, nós desenvolvemos os conceitos de teste de design [Design Wizard] [Pires et. al. 2008]. Para essa verificação considerando as informações estruturais do design em detrimento às informações comportamentais que possam estar descritas no design. Um teste de design é um teste automático que analisa uma implementação e verifica se ela satisfaz uma regra de design. Regras de design, por sua vez, especificam como as entidades do software devem (ou não) se relacionar com as demais. Por ser baseada em testes automáticos, esta abordagem permite automatizar o processo de verificação de conformidade entre uma implementação e o design desejado para o sistema. Um problema desta abordagem, contudo, é que o design deve ser expresso na forma de código de teste (as chamadas regras de design) ao invés de usar uma linguagem mais específica para esse fim.

UML 2.0 é um formalismo amplamente utilizado pela academia e pelo mercado na especificação de design de software [Object Management Group 2006]. UML é usada para descrever tanto características estruturais quanto comportamentais do software. Neste trabalho nós investigamos e apresentamos UDT (UML Design Testers), uma ferramenta que permite verificar automaticamente a conformidade entre a implementação de um sistema em Java e os aspectos estruturais de seu design especificados por meio de diagramas de classe UML.

A ferramenta UDT baseia-se nos conceitos de MDA para gerar automaticamente os testes de design necessários para verificar um design específico expresso em UML. Com esta abordagem, evitamos a necessidade de expressar o design na forma de regras de design como era feito na abordagem anterior e permitimos que UML seja o único artefato de design a ser mantido pela equipe de desenvolvimento. Os testes de design podem ser novamente gerados a cada revisão do design e re-executados a cada nova versão do software que for desenvolvida. Este processo tem um custo mínimo para a equipe de desenvolvimento, que se reduz à geração e execução dos testes, e tem o benefício de assegurar a consistência entre a implementação e o design proposto à medida que o software evolui.

O restante deste documento está organizado da seguinte forma. Na Seção 2 apresentamos em mais detalhes o conceito de testes de design e a abordagem de MDA que embasam nossa proposta. Na Seção 3 descrevemos a ferramenta UDT, destacando sua arquitetura e abordagem utilizada para sua construção. Na Seção 4, apresentamos um exemplo de uso da ferramenta para um diagrama de classes UML simples e analisamos os testes gerados. Na Seção 5, apresentamos e discutimos algumas ferramentas e técnicas correlatas à nossa. Finalmente, na Seção 6, concluímos o trabalho com algumas considerações e elencamos alguns trabalhos futuros.

2. Fundamentação Teórica

A seguir descrevemos alguns conceitos importantes para o entendimento do nosso trabalho: Testes de Design e MDA. Esses conceitos são abordados durante todo o artigo.


65

2.1. Teste de Design

Teste de Design [Design Wizard] é um tipo de teste capaz de verificar se o código desenvolvido segue uma estrutura pré-determinada. Esses testes são construídos considerando informações estruturais das entidades do código e seus relacionamentos. O principal objetivo de construir testes de design é verificar a conformidade entre o design do software proposto e o código usando testes automáticos.

De certo modo, teste de design se apresenta de uma forma muito parecida com teste de integração. Porém, enquanto os testes de integração verificam se código desenvolvido possui um determinado comportamento nas funcionalidades providas, os testes de design verificam a estrutura do sistema sem considerar suas funcionalidades. Dessa perspectiva, teste de design realiza uma análise estática do código para coletar informações sobre as entidades do código e seus relacionamentos e verificar se elas condizem com o design especificado previamente.

Com o intuito de criar um ambiente capaz de especificar e executar testes de design para aplicações Java, nós criamos uma biblioteca chamada design wizard [Design Wizard]. O Design Wizard provê uma API Java capaz de colher e disponibilizar informações estruturais sobre um código analisado. Por exemplo, essa API permite identificar quais os métodos do código são estáticos, ou saber quais outros métodos são invocados por um determinado método de uma classe. E, para verificar se essa estrutura recuperada pelo design wizard condiz com a esperada, devem ser adotadas as assertivas e a infra-estrutura provida pelo framework de teste JUnit [JUnit].

A Figura 1 mostra um teste de design simples que verifica se a classe A se comunica com a classe B. A linha 4 do código recupera uma instância de designwizard.ui.ClassNode que representa a classe A. As linhas 5 e 6 criam uma coleção com todos os nomes da classes usadas pela classe A. Por fim, a linha 7 verifica se a classe B está contida entre as classes usadas pela classe A.

Figura 1. Exemplo de Teste de Design

2.2. Model Driven Architecture (MDA)

MDA é uma abordagem na engenharia de software definida pela OMG [Mellor et al. 2004]. Ela representa uma visão de MDD (Model-Driven Development), sendo MDA a mais prevalecente até o presente momento [Hailpern and Tarr 2006]. A idéia chave de MDA é mudar a ênfase de esforço e tempo empregados durante o ciclo de vida do software, focando-se na modelagem, meta-modelagem e transformação entre modelos, ao invés de focar na implementação como é feito atualmente. Com esse objetivo, MDA sugere um conjunto de padrões de modelos. O primeiro deles é o CIM (Computational Independent Model) que captura a ontologia e requisitos independentes dos requisitos computacionais do sistema. O CIM é usado como entrada para a elaboração do PIM (Platform Independent Model), que captura os requisitos e desenho do sistema


66

computacional independentemente de qualquer plataforma de implementação. Seguindo ainda a proposta da OMG, o PIM serve como entrada para a elaboração do PSM (Platform Specific Model), no qual os requisitos do sistema são amarrados às peculiaridades da plataforma onde o sistema irá executar. E, finalmente, o PSM serve como entrada para a geração do código final em sintaxe concreta. Toda a arquitetura MDA pode ser observada na Figura 2. Os principais componentes de uma abordagem MDA são: i) Meta-modelos, estes descrevem como os modelos devem ser formados; ii) Modelos, estes são instâncias do meta-modelo; e iii) Transformações, estes são regras que definem como os modelos de entrada devem ser transformados nos modelos de saída, de acordo com os meta-modelos.

Figura 2: Arquitetura MDA.

MDA tem um alto potencial de automação alcançado por meio de transformações que especificam como a partir de um modelo podemos alcançar os outros. Nesse sentido, há um conjunto de linguagens de transformação, tais como QVT (Queries/Views/Transformations) [QVT 2006] ou ATL (Atlas Transformation Language) [AMMA Project 2005].

3. Ferramenta UDT

A ferramenta UDT (UML Design Tester) visa verificar a conformidade entre a implementação Java de um sistema e o seu design UML usando testes de design, gerados automaticamente a partir dos diagramas de classe UML. Para tanto, foi desenvolvida uma arquitetura que pode ser observada na Figura 3. Ela está dividida em dois módulos: i) o módulo Gerador dos Testes de Design, responsável por ler os arquivos XMI que descrevem os diagramas de classe e baseado nessas informações gera o modelo dos testes de design; ii) o módulo Gerador de Sintaxe Concreta, dado que o módulo anterior não gera o código real do testes de design, mas sim o modelo do código baseado no meta-modelo da linguagem Java. Ou seja, o segundo módulo é responsável por gerar a sintaxe concreta dos modelos de código gerados pelo primeiro.

A arquitetura da ferramenta UDT reflete uma abordagem MDA adotada, sendo: i) os digramas de classe UML são de fato PIMs; ii) os modelos do código de teste são PSMs; e iii) o código dos testes de design é a implementação em sintaxe concreta. Reusando os padrões e frameworks de MDA e especificando as transformações em cada


67

nível, auferimos os benefícios dessa abordagem, como produtividade, portabilidade e reuso [Mellor et al. 2004].

Figura 3. Arquitetura geral da ferramenta UDT.

Atualmente, o modo de interação com a ferramenta se dá por linha de comando. O comando de utilização é bastante simples:

UDT <<arquivoXMI>> <<diretorioDosTestes>>

Sendo: (1) <<arquivoXMI>> é o caminho absoluto para o arquivo XMI que descreve o diagrama de classes do design a ser testado; e (2) <<diretorioDosTestes>> é o lugar onde o sistema vai salvar os testes de design (classes Java) gerados.

3.1. Módulo Gerador de Testes Automáticos

Esse módulo é responsável pela fase de transformação do PIM para o PSM. Ele gera o modelo dos testes de design a partir das informações do design estrutural do sistema. A Figura 4 ilustra a abordagem MDA adotada para esse módulo. Nesta Figura, encontramos os seguintes artefatos: i) Meta-modelos: como esse módulo gera modelos de código Java a partir de modelos UML, então adotamos dois meta-modelos: a) o meta-modelo origem de UML 2.0, provido pelo consórcio OMG [Object Manegement Group 2006]; e b) o meta-modelo destino de Java - JAS (Java Abstract Syntax) [JAS-metamodel], uma representação completa do código Java, adotada pelo Eclipse, por exemplo; ii) Modelos: os modelos de entrada são os diagramas de classe UML contendo o design estrutural do software, enquanto os de saída são os modelos do código dos testes de design; iii) Transformações: as transformações foram feitas seguindo ATL. Escolhemos essa linguagem, pois ela possui um framework de criação e execução amplamente utilizado e está completamente alinhado com os atuais padrões MDA.

Em um trabalho anterior descrevemos o funcionamento dessa abordagem MDA [Pires et al. 2008]. Onde detalhamos como as regras ATL foram elaboradas e como os modelos de código são gerados pelas transformações.


68

Figura 4. Abordagem MDA do Módulo Gerador dos Testes de Design.

3.2. Gerador de Sintaxe Concreta

A fim de tornar os testes gerados pela nossa ferramenta compiláveis e executáveis, construímos um módulo para geração de sintaxe concreta. Ou seja, esse módulo é responsável pela transformação de PSM (modelos do código) em sintaxe concreta (código Java compilável e executável). Na Figura 5 é apresentada a abordagem MDA adotada para o módulo Gerador de Sintaxe Concreta. Nesta Figura, descrevemos os seguintes artefatos: i) Meta-modelos: dado que esse módulo gera a sintaxe concreta a partir de modelos de código Java, somente foi necessário adotar um meta-modelo, o Java Abstract Syntax (JAS), como meta-modelo de origem. Um meta-modelo destino é desnecessário na geração de sintaxe concreta; ii) Modelos: os modelos de entrada são os modelos do código dos testes de design. Os modelos de saída são os códigos dos testes de design em sintaxe concreta; iii) Transformações: As transformações de modelo para texto (M2T) foram definidas usando a linguagem MOFScript [MOFScript]. As vantagens dessa linguagem que motivaram a sua escolha foram: i) ela possui um ambiente de criação e execução para suas transformações; ii) ela possui características de orientação a objetos, como herança e polimorfismo; iii) o ambiente de criação possui algumas vantagens (como highlight de sintaxe, auto-complemento de código e indicação de erros mais clara) em relação a outras abordagens como o JET [JET], e o ATL DT [ATL-DT]; e iv) o MOFScript está em conformidade com os padrões propostos atualmente pela OMG, pois ele é uma das respostas ao Request for Proposals da OMG para a criação do padrão MOF2Text [MOF].

Figura 5. Abordagem MDA do Módulo Gerador de Sintaxe Concreta.

O processo de geração da sintaxe concreta se dá em três etapas: inicialmente, i) são carregados os modelos de código Java, baseados no meta-modelo Java Abstract Syntax; ii) os scripts de transformação realizam os mapeamentos do elementos dos modelos do código para a sintaxe concreta da linguagem; e por fim, iii) o código Java em sintaxe concreta é persistido em arquivo. Esse arquivo produzido é um código fonte Java compilável e executável, dado que ele está de acordo com o meta-modelo de Java.


69

4. Exemplo de Uso

Para ilustrar o funcionamento da ferramenta UDT, nesta Seção demonstramos exemplos bem simples de testes de design gerados pela ferramenta. A Figura 6a demonstra o exemplo do design de um sistema que será usado como base para a geração dos testes de design.

Figura 6. Exemplo de Utilização de UDT.

A Figura 6b é o código gerado para verificar a classe A. A linha 4 desse código recupera uma instância de ClassNode representando a classe A. Caso essa classe não exista uma exceção será lançada. A linha 5 verifica se essa classe, de fato, não é abstrata, conforme especificado no design. As linhas 7-18 verificam se a classe A possui o atributo id. Adicionalmente, elas verificam: seu tipo (linhas 12-13), se ele não é estático (linha 14) e a se a sua visibilidade é private (linhas 15-17). As linhas 19-32 verificam o método normalize, checando seu tipo de retorno (linhas 25-26), se ele não é estático (linha 27), se ele não é abstrato (linha 28), e, por fim, se a sua visibilidade é public (linhas 29-31), conforme indicado no design.

A Figura 6c exibe um outro teste de design, focado em verificar propriedades de associação, como a existente entre as classes A e B. A ferramenta verifica estas propriedades no código seguindo a abordagem proposta por Akehurst et al. [Akehurst et al. 2007]. Desta forma, a ferramenta verifica se cada membro de uma associação navegável possui um atributo cujo tipo reflete o outro membro da associação (ou uma coleção dele). Adicionalmente, a ferramenta verifica a existência dos métodos get e set para manipular a o atributo derivado da associação. Nem todas as características abordadas por Akehurst et al. podem ser verificadas, pois a análise estática do código não fornece informação suficiente, tais como isReadOnly, upperBound, lowerBound, etc. Esse tipo de informação só poderia ser verificada analisando o sistema em tempo de execução. Ainda na Figura 6c, a linha 5 recupera uma instância de FieldNode representando o atributo role derivado para a classe A. Caso esse atributo não exista, uma exceção será lançada. A linha 7 verifica se esse atributo é privado. As linhas 8-9 verificam se essa classe possui os métodos get e set, respectivamente, para este atributo. As linhas 10-11 verificam se o retorno do método get é do tipo de B, enquanto, as linhas


70

12-13 verificam se esse método é público. As linhas 14-15 verificam se o método set é público e, finalmente, a linha 16 verifica se o parâmetro desse método é do tipo da classe B.

5. Trabalhos Relacionados

Design Peer Review [Rowland 2002] sugere um processo de revisão de design amplamente usado em empresas. Esse processo consiste em um mecanismo que assegura os padrões de design separando a equipe de desenvolvimento do sistema em grupos que analisam o código produzido por outros grupos. A grande desvantagem desse trabalho é que o processo sugerido é manual e, assim, pode levar a erros durante a análise. Além do fato que é um processo que pode demorar demais pra ser executado, visto que para projetos muitos grandes com dezenas ou centenas de classes esse processo por durar várias horas.

Outra abordagem para verificação de design é proposta por Dinh-Trong et al. [Dinh-Trong et al. 2005]. Eles propõem um método para geração de entradas e digramas UML executáveis para o sistema a partir dos diagramas de classe e atividade. Depois disso, deve-se comparar o comportamento esperado dos diagramas com o comportamento do sistema em execução. Então, falhas devem ser reportadas sempre que for observado um comportamento diferente do esperado.

Existem ainda ferramentas, tais como [Barbosa et al. 2007] e [Kaplan et al. 2008], que baseadas nos diagramas comportamentais e estruturais de UML verificam se as funcionalidades da implementação satisfazem os requisitos funcionais do sistema. Já nossa ferramenta considera outra perspectiva de verificação, ela verifica se a estrutura da implementação segue a proposta pelo design especificado através de diagramas de classe. Ressaltando que não há nenhuma característica que não impeça que essas duas abordagens de verificação possam ser adotadas em paralelo.

O projeto PTIDEJ (Pattern Trace Identication, Detection, and Enhancement in Java) [Moha et al. 2006] visa desenvolver uma ferramenta capaz de avaliar e melhorar a qualidade de programas orientados a objetos. Essa ferramenta cria um modelo do código a partir de análises estáticas e dinâmicas do programa. E, analisando o modelo gerado, a ferramenta é capaz de detectar padrões de design e defeitos de design. Os padrões de design que podem ser identificados são fixos da ferramenta e a ferramenta possui uma gramática BNF para descrever os defeitos de design. A ferramenta não adota os padrões da OMG para descrever seus modelos, pois ela usa um meta-modelo próprio.

Outro trabalho sobre verificação de design em código é o Find Bugs [Find Bugs]. Esta ferramenta usa análise estática para descobrir bugs em códigos Java. Ela analisa os bytecodes de uma aplicação Java e gera um relatório descrevendo os prováveis bugs encontrados na análise. Um ferramenta similar é o LClint [Evans et al. 1994] que tem sido usada para verificar códigos escritos na linguagem C. Esta ferramenta foca-se na detecção de problemas baixo-nível em códigos fonte tais como referências a apontadores nulos ou código não usado. Ambas as ferramentas se concentram em detectar design em um nível de abstração muito baixo, e desconsideram completamente informações de design de mais alto nível.

6. Conclusões

Neste trabalho nós apresentamos UDT, uma ferramenta que permite verificar a conformidade de um design estrutural de um sistema especificado por meio de digramas


71

de classes UML e o seu código fonte em Java. Atualmente, UDT verifica características referentes a classe, generalização e associações dos diagramas de classe UML.

Nossa ferramenta ganha um especial destaque em processos de desenvolvimento que se baseiam no design anterior à implementação. Contudo, UDT pode parecer irrelevante nesse contexto se a geração do código do sistema adotar uma abordagem MDA para a geração do código. Todavia, atualmente, MDA não é aplicada de forma total ou adequada, e assim inviabilizando a completa geração do código. Sendo assim, o código gerado estará sujeito a alterações, e usando nossa ferramenta pode-se evitar que o design da implementação se degrade com essas alterações.

A atual implementação de UDT consiste de um conjunto de transformações ATL executadas sobre a plataforma AMMA [ATL-DT] (módulo Gerador de Testes de Design) e um conjunto de scripts executados sobre o framework MOFScript (módulo Gerador de Sintaxe Concreta) [MOFScript]. Um protótipo Black-box de UDT já se encontra disponível para download [Design Wizard], que recebe como entrada qualquer arquivo XMI descrevendo o design do sistema gerado por outras ferramentas (Poseidon, MagicDraw, etc.) e gera na saída o código dos testes de design para verificar o design.

Além do exemplo dado na Seção 4, testamos nossa ferramenta sobre sistemas mais complexos (embora ainda com menos de 50 classes). Implementações conformes e não conformes com o design foram automaticamente identificadas sem esforço adicional em escrever código de testes de design, confirmando a viabilidade da idéia e do propósito da ferramenta. Sobre o tamanho dos cenários testados, consideramos nossa abordagem escalável para sistemas maiores, dado que a relação entre número de testes de design gerados e o tamanho do design é linear.

Como trabalhos futuros, pretendemos incluir na ferramenta, o suporte a outros elementos dos diagramas de classes como interfaces e pacotes. Outra linha de trabalho é a verificação de designs comportamentais a partir de informações adquiridas dos diagramas comportamentais de UML, tais como diagramas de seqüência e atividades. Tal verificação pode ser realizada monitorando da execução do sistema por meio de aspectos (JAspects) gerados automaticamente. Também investigamos técnicas que permitam a execução parcial dos testes. A idéia é que mudanças na implementação não implicam que todos os testes de design devem ser novamente executados ï para isto, investigamos o uso de técnicas de regressão para determinar quais testes não precisam ser novamente executados. Por fim, como alternativa à interface atual, baseada em linha de comando, estamos desenvolvendo uma interface gráfica mais amigável para a ferramenta UDT.

Referências

Akehurst, D., Howells, G., and McDonald-Maier, K. (2007). Implementing associations: UML 2.0 to java 5.�In�Software and System Modeling, 6(1), pp. 3-35.

AMMA Project (2005). Atlas transformation language. http://www.sciences.univnantes.fr/lina/atl/.

ATL-DT. Atl-dt. http://www.eclipse.org/m2m/atl/.

Barbosa, D. L., Lima, H. S., Machado, P. D. L., Figueiredo, J. C. A., Juca, M. A., and Andrade, W. L. (2007). Automating functional testing of components from uml specifications. Int. Journal of Software Eng. and Knowledge Engineering.

Design Wizard. Design wizard. http://www.designwizard.org.


72

Dinh-Trong, T. T., Kawane, N., Ghosh, S., France, R. B., and Andrews, A. A. (2005). A tool-supported approach to testing UML design models. In ICECCS, pages 519ï 528.

Evans, D., Guttag, J. V., Horning, J. J., and Tan, Y. M. (1994). LCLint: A tool for using specifications to check code. In Symposium on the Foundations of Software Engineering.

Find Bugs. Find bugs. http://findbugs.sourceforge.net/.

Hailpern, B. and Tarr, P. (2006). Model-driven development: The good, the bad, and the ugly. IBM Systems Journal, 45(3):451ï 461.

Hesse, W. (2001). RUP - A process model for working with UML. In Unified Modeling Language: Systems Analysis, Design and Development Issues, pages 61ï 74.

JAS-metamodel. Jas-metamodel. http://www.eclipse.org/gmt/am3/zoos/atlanticZoo.

JET. Java Emitter Templates. http://www.eclipse.org/modeling/m2t/?project=jet.

JUnit Testing Framework. http://www.junit.org.

Kaplan, M., Klinger, T., Paradkar, A. M., Sinha, A., Williams, C., and Yilmaz, C. (2008). Less is more: A minimalistic approach to UML model-based conformance test generation. In ICST, pages 82ï 91. IEEE Computer Society.

Kruchten, P., Lago, P., and van Vliet, H. (2006). Building up and reasoning about architectural knowledge. In Hofmeister, C., Crnkovic, I., and Reussner, R., editors, QoSA, volume 4214 of Lecture Notes in Computer Science, pages 43ï 58. Springer.

Mellor, S. J., Scott, K., Uhl, A., and Weise, D. (2004). MDA Distilled: Principles of Model-Driven Architecture. Addison-Wesley, Boston.

MOF2Text - Object Manegement Group (2004). Mof model to text transformation language, request for proposal. OMG Document ad/2004-04-07.

MOFScript. Mofscript. http://www.eclipse.org/gmt/mofscript/.

Moha, N., Gueheneuc, Y.-G., and Leduc, P. (2006). Automatic generation of detection algorithms for design defects. In ASE ô06: Proceedings of the 21st IEEE International Conference on Automated Software Engineering (ASEô06), pages 297ï 300, Washington, DC, USA. IEEE Computer Society.

Parnas, D. L. (1994). Software aging. In Fadini, B., editor, Proceedings of the 16th International Conference on Software Engineering, pages 279ï 290, Sorrento, Italy. IEEE Computer Society Press.

Pires, W., Brunet, J., Ramalho, F., and Serey, D. (2008). Uml-based design test generation. In SAC ô08: Proceedings of the 2008 ACM symposium on Applied computing, pages 735ï 740, Fortaleza, CE, Brazil. ACM.

QVT. Object Management Group (2006). Mof, qyery/views/transformations. http://www.omg.org/cgi-bin/doc?ptc/2005-11-01.

Rowland, F. (2002). The peer-review process. Learned Publishing, 15:247ï 258.

Sommerville, I. (2004). Software Engineering. Addison-Wesley, 7th edition.

UML - Object Manegement Group (2006). Uml 2.0 specification. http://www.omg.org/technology/documents/formal/uml.htm.

van Gurp, J. and Bosch, J. (2002). Design erosion: problems and causes. The Journal of Systems and Software, 61(2):105ï 119.


73

Documents

UDT ï Uma Ferramenta para Geração de Testes de Designpet/Artigos/007.pdfNós seguimos uma abordagem MDA ... conformidade entre design e implementação é uma prática que promove