From DesignWizardWiki

In this work we investigate and propose a fully automated technique to perform conformance checking of Java implementations against UML class diagrams. In our approach, we reused the DesignWizard a Java API capable to extract the structure of the source code and use the framework JUnit to verify if this structure is in conformance with the expected. 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 proof of concept of the technique has been implemented and evaluated. We performed several experiments on simple scenarios. Simple designs involving classes, associations, inheritance have been checked. Compared to previous related work, the advantage of our approach lies in the fact that we automatically generate design tests from UML class diagrams to Java code that play the dual role of design test and implementation language.

Presently, we generate teste to verify three features of UML Class Diagram. However, the we just generate the code model. Now, we are developing a transformation to generate the concrete syntaxe, i.e., the executable source code.

Contents 1 The Tool 2 UML Features Verified 2.1 Classe 2.1.1 Métodos e Atributos 2.1.2 Somente Métodos 2.1.3 Somente Métodos 2.2 Associações 2.3 Interface 2.4 Pacote 2.5 Dependência

The Tool

We developed a tool for conceptual proof of our ideia. It is available here.

Now, the interation mode with the tool is by comand line:

java -jar UDT.jar <<XMIpathFile>> <<outputDirectory>> <<pathToProjectToBeTested>>

Where:

1. <<XMIpathFile>> path to XMI representing the class diagram of design to be verified;
2. <<outputDirectory>> place where the tests must be generated;
3. <<pathToProjectToBeTested>> path to the Jar or project to be tested.

An example of a script for Windows to execute the test is:

set UDT_PATH=Z:/<<pathToUDTPlace>>
set XMI_FILE=Z:/<<PathToXMIFile>>
set DEST_DIR=Z:/<<PathToTargetDirectory>>
set TARGET_SW=Z:/<<PathToProjectToBeTested>>
cd "%UDT_PATH%"
java -jar UDT.jar "%XMI_FILE%" "%DEST_DIR%"  "%TARGET_SW%" 

To test our tool we created a simple scenario, available here.

This archive has an eclipse project with:

• models: a directory with the model files. We create this scenario using the modeling Tool MagicDraw. In this directory there is: the project file of MagicDraw; and, the XMI generated by the MagicDraw;
• src: in this directory is the source code reflecting the design proposed (class, generalization and association).
• dist: the project jar.
• lib: the jar of design wizard necessary to execute the tests.

A flash presentation is available to guild an experiment using the tool magicdraw to create the design and our tool to verify the design conformance its against the avariable scenario. here

UML Features Verified

Legenda:
Itálico: já está sendo verificada.
Sublinhada: não está sendo veficidada, mas é passível de ser.
Riscada: não pode ser verificada.

Classe

As características de classe que são verificadas são:

• nome: os testes verificam se existe uma classe no código com os mesmo nome da presente no design;
• super Classe: os testes verificam a hierarquia de classes presente no design, vale salientar que UML permite herança múltipla de classe, contudo descartamos essa verificação, pois não é uma propriedade intrínseca da linguagem Java;
• isAbstract: os testes verificam se a classe é uma classe abstrata;
• visibilidade: os testes verificam se a classe possui a mesma visibilidade (mapeamos a visibilidade package de UML como protected de Java);
• isLeaf: os testes verificam verifica se nenhuma outra classe herda dessa classe.
• isRoot: os testes verificam verifica se nenhuma se essa classe não herda de nenhuma outra classe (Exceto Object).
• realizacao de Interfaces: os testes verificam se essa classe obedece as mesmas interfaces.

The template codes to test are here Class and Generalization.

Métodos e Atributos

Outra característica importante de classe que são verificadas são os atributos e os métodos. As características de atributos e métodos que são abordados são:

• nome: os testes verificam se a classe possui um atributo/método com o mesmo nome;
• tipo: os testes verificam se esse atributo/método possui o mesmo tipo (para método é o tipo de retorno);
• visibilidade: os testes verificam se a atributo/método possui a mesma visibilidade;
• isStatic: os testes verificam se o atributo/método é estático.

Somente Métodos

• multiplicidade, se a multiplicidade do atributo for maior que 1, os testes verifica se ele é uma coleção.

Somente Métodos

Para os métodos da classe ainda são verificados:

• IsAbstract: os testes verificam se o método é abstrato;
• nome e tipo dos parâmetros: os testes verificam se todos os parâmetros dos método possuem os mesmos nomes e tipos especificados no design e se estão na seqüência correta. Não implementado ainda no design wizard.

Associações

The template codes are here. Association

Associações também são verificadas no código seguindo a abordagem proposta por Akehurst et al. [Akehurst et al. 2007]. Sendo assim, consideramos que cada membro de uma associação navegável deve possuir um atributo com o tipo do outro membro (ou uma coleção dele) e um método get e set para manipular a o atributo referente à associação. Nem todas as características de abordadas por Akehurst et al. podem ser verificadas, pois a análise estática do código não fornece informação suficiente. As características verificadas atualmente são:

• nome: os testes verificam se possui um atributo com o mesmo nome da associação;
• tipo: os testes verificam se esse atributo possui o mesmo tipo do seu respectivo MemberEnd ou se a multiplicidade for maior que 1 verifica se coleção especializada;
• visibilidade: os testes verificam a visibilidade dos métodos get e set estão de acordo com a visibilidade de cada MemberEnd;
• isReadOnly, essa característica é difícil de ser verificado por uma análise estática, pois só é possível certificá-lo verificando a execução do sistema. Porém, para associações com multiplicidade maior que 1, os testes verificam se o método get retorna uma coleção através do método Collections.unmodifiable.
• isDerived, não encontramos um meio de verificar.???????
• RefinedProperties, não encontramos um meio de verificar.???????
• Subsetting properties, não encontramos um meio de verificar.???????
• Qualifiers, não encontramos um meio de verificar.???????
• IsComposite, impossível de verificar por meio de análise de estática do código. Pois, Depende muito da forma como a associações foi implementada.
• Lower e Upper bounder, impossível de verificar por meio de análise de estática do código. Pois, essa informacao só está disponível em tempo de execucao do sistema a ser verificado.

Interface

A ser verifcado.

Pacote

A ser verifcado.

Dependência

A ser verifcado.