Aplicação de Reverse Engineering: Java para UML

Transcrição

1 Aplicação de Reverse Engineering: Java para UML Luís Ramos e Pedro Strecht Faculdade de Engenharia da Universidade do Porto, Rua Dr. Roberto Frias, s/n, Porto, Portugal {lramos, pstrecht}@fe.up.pt Abstract. Este documento descreve o desenvolvimento de uma aplicação web de reverse engineering que disponibiliza o serviço de conversão de código-fonte Java para a sua representação em UML através do dialecto XML Metadata Interchange (XMI). A aplicação efectuará a conversão sucessiva de documentos em vários formatos até obter o formato pretendido. O código-fonte Java é transformado em JavaML; os documentos JavaML são transformados em documentos XMI sem informação de visualização através de uma XSLT e a informação de visualização é acrescentada ao XMI por um módulo que utiliza DOM para navegar e alterar a estrutura do documento XMI. O trabalho consiste essencialmente no desenvolvimento de uma XSLT de conversão de JavaML em XMI e na implementação de um modelo de objectos (baseado em DOM) dos documentos XMI. Pretende-se que este modelo de objectos permita a implementação confortável de algumas heurísticas de construção do layout dos diagramas. Adicionalmente é feito um esforço de integração destes componentes numa aplicação web. 1. Introdução É habitual que elementos de equipas que iniciam um projecto de software transitem para outros projectos, originando a que a equipa responsável pela sua manutenção já não coincida com a que o desenvolveu. Para uma manutenção eficaz das aplicações do projecto, é necessário compreender todo o código já desenvolvido, sendo esta uma tarefa penosa, normalmente dificultada pela inexistência de documentação. As técnicas de reverse engineering aplicadas à engenharia de software tentam facilitar esta tarefa através da produção de informação (recorrendo a modelos ou outras representações) que permitam detectar a arquitectura de um sistema, fornecendo uma visão num nível de abstracção superior ao do código-fonte. A colocação deste tipo de ferramentas na internet vem aumentar a disponibilidade, a facilidade e a rapidez no uso de técnicas de reverse engineering. Para além disso, a aplicação descrita neste documento pode ser utilizada para desenvolvimento e teste de heurísticas de layout automático de diagramas. 1.1 Objectivos Pretende-se desenvolver uma aplicação web de reverse engineering que disponibilize o serviço de conversão de código-fonte Java na sua representação em Unified Modelling Language (UML), nomeadamente diagramas de classes. A representação desses diagramas é feita no dialecto da extensible Markup Language (XML): XML Metadata Interchange (XMI), mais precisamente o UML Diagram Interchange. A aplicação web basear-se-á na transformação da informação entre os formatos XML: Java Markup Language (JavaML) e XMI. Para efectuar esse processamento serão utilizadas as tecnologias XML: extensible Stylesheet Language Transformations (XSLT) e Document Object Model (DOM). A aplicação recebe como entrada de dados ficheiros com código-fonte em Java. As saídas são documentos XMI que possam ser importado por ferramentas CASE (Computer Aided Software Engineering) ou, em alternativa, um documento Scalar Vector Graphics (SVG) que permite a visualização directa num browser com um plug-in específico. O trabalho consistiu essencialmente no desenvolvimento de uma stylesheet de conversão de JavaML em XMI e na implementação de um modelo de objectos (baseado em DOM) dos documentos XMI. Pretende-se que este modelo de objectos permita a implementação confortável de algumas heurísticas de construção do layout dos diagramas. Adicionalmente foi feito um esforço para a integração destes componentes numa aplicação web.

2 2 Luís Ramos e Pedro Strecht 1.2 Estado da Arte Uma das formas de reverse engineering é a produção de diagramas UML a partir de código-fonte. O UML é um standard da Object Management Group (OMG) para modelação de sistemas de software. Este standard, cuja última versão 2.0 foi lançada em 2003, é o mais usado em todo o mundo para modelação. Nesta última versão do UML foram introduzidos novos diagramas e foi aumentada a complexidade dos já existentes. No surgimento do UML, em 1997, não existia nenhum formato para troca de modelos entre ferramentas CASE, tendo cada uma o seu próprio formato. Era possível efectuar reverse engineering destes formatos, no entanto, os resultados podiam ser imprevisíveis, já que estes não tinham sido concebidos para esse fim. O dialecto XMI foi criado para uniformizar um formato livre de constrangimentos impostos pelas ferramentas CASE e que pudesse ser conhecido por todas, independentemente do seu âmbito. As técnicas de reverse engineering têm assumido uma importância cada vez maior na manutenção de software, tendo-se tornado um requisito praticamente obrigatório nas ferramentas CASE. Existem actualmente dezenas de ferramentas CASE comerciais que produzem diagramas de classes a partir de código-fonte de linguagens orientadas a objectos. As mais populares são o Rational Rose (IBM) [1], o Together Control Centre (Borland) [2] e o Poseidon for UML (Gentleware) [3]. Estas ferramentas suportam mecanismos de importação e/ou exportação de diagramas para o formato XMI. Normalmente as ferramentas tratam o XMI como um formato externo, que pode ser importado ou exportado, no entanto, algumas como o Poseidon ou o ArgoUML [6], utilizam-no como formato nativo. É frequente também verificar que os documentos XMI gerados por diferentes ferramentas são incompatíveis entre si, pelo que é uma área em que ainda se aguarda alguma maturação. Para além de reverse engineering, as ferramentas também dão suporte a operações de forward engineering (tipicamente geração automática de código a partir de modelos de objectos) e round-trip engineering [4]. O Rational Rose tem a funcionalidade interessante de publicação de diagramas UML em páginas web como imagens, permitindo a distribuição fácil dos mesmos, sem obrigar que se instale a ferramenta. Esta funcionalidade pode ser encarada como um extensão ao trabalho descrito neste documento. O Poseidon, devido às suas origens no projecto opensource ArgoUML, oferece uma versão livre para utilização individual [5]. O Oracle JDeveloper 10g [11], Integrated Development Environment (IDE) da Oracle oferece capacidades notáveis de round-trip engineering: permite em qualquer momento a visualização do modelo de classes do código em desenvolvimento e também fazer alterações ao diagrama que se reflectem automaticamente no código. Para além disto, esta ferramenta suporta alguma interoperabilidade através de XMI, mas de forma unidireccional, ou seja, suporta apenas operações de importação. Resumindo uma análise feita a outras ferramentas CASE (Visual Paradigm [7], Eclipse [8], etc.), pode afirmar-se que quase todas têm um subconjunto das características oferecidas pelas principais ferramentas, e embora sejam boas para desenho de diagramas, nem sempre implementam as funcionalidades de reverse engineering ou importação/exportação de projectos em formato XMI. Verifica-se também que a maioria das ferramentas não implementa uma versão correcta do UML, nem oferece algoritmos de layout automático de diagramas com resultados satisfatórios [9]. Algumas ferramentas implementam um subconjunto do UML, restringindo a sua utilização e o nível de abstracção pretendido. Por outro lado, a falta de robustez dos algoritmos de layout automático obrigam o utilizador a ter de efectuar ajustes manuais ao diagrama, consumindo tempo útil para outras tarefas e pondo em causa o automatismo do processo. Para facilitar a interoperabilidade, muitas ferramentas, para além de gerarem os seus próprios formatos nativos, trabalham também com a descrição dos seus diagramas de classes em formato XMI. A tendência será para que este formato seja suportado por todas as ferramentas CASE, como mecanismo de troca de metainformação [10]. 1.3 Trabalhos Relacionados Foram efectuados estudos da análise de alterações no código-fonte e propagação das mesmas para o modelo de classes [12]. As técnicas de reverse engineering são as que tornam mais fácil fazer alterações ao código-fonte e propagá-las directa e automaticamente para o modelo. Este processo alivia o programador da tarefa de actualizar os modelos sempre que necessita de efectuar uma rápida alteração no código-fonte, e reduz as hipóteses de ele ser tentando a não fazer essa alteração no modelo. Um exemplo de operações de reverse engineering é o projecto Chava, que analisa e anota as alterações efectuadas em applets Java. Uma applet Java é um pequeno programa em Java que pode ser

3 Aplicação de Reverse Engineering: Java para UML 3 embebido numa página HTML. A informação é extraída directamente a partir do código-fonte em Java e organizada numa base de dados relacional [13]. Uma utilização alternativa deste sistema é a comparação entre documentos gerados por versões diferentes do Java Development Kit (JDK) para realçar as diferenças e avaliar o impacto que estas possam ter nos programadores. Na realização da sua tese de mestrado, Osvaldo Pinali, desenvolveu uma ferramenta de reverse engineering de Java para UML, uma vez que concluiu que as ferramentas existentes não satisfaziam as suas necessidades [14]. No âmbito da análise que fez sobre detecção de padrões em código-fonte em Java, pretendia gerar informação detalhada sobre o código-fonte, ter suporte em UML e ser customizável. São conhecidas várias representações XML de outras linguagens de programação para além do Java, como, por exemplo, a representação XML de ANSI C [15]. O objectivo dos principais trabalhos feitos nesta área é gerar representações de código-fonte independentes da linguagem [16], [17]. A Gentleware apoiou um projecto que consistiu no desenvolvimento de uma stylesheet de transformação de XMI em SVG, da autoria de M. Jeckle, D. Boicourt e B. Stritt [18]. Esse apoio consistiu na implementação da norma UML 2.0, o que implica que o Poseidon seja a única ferramenta que exporte XMI capaz de produzir bons resultados em SVG. Neste trabalho, essa stylesheet é utilizada para gerar os resultados em SVG a partir dos documentos XMI. No trabalho descrito neste documento, foram utilizados o conversor de código-fonte Java em JavaML desenvolvido por G. Badros (secção 2.1) e a stylesheet de conversão de XMI em SVG referida. 1.4 Plano de Trabalho O trabalho foi desenvolvido em sete etapas: 1. Estudo e aprofundamento de conhecimentos nos dialectos XML e tecnologias envolvidas; 2. Instalação e configuração do conversor de código-fonte Java em JavaML; 3. Desenvolvimento da XSLT de conversão do JavaML em XMI; 4. Desenvolvimento do módulo de cálculo do layout dos diagramas; 5. Desenvolvimento da interface web para o utilizador; 6. Integração dos vários componentes; 7. Testes e avaliação dos resultados. 2. Dialectos 2.1 JavaML Java Markup Language (JavaML) [19] é um dialecto XML de representação de código-fonte Java. Este dialecto reflecte a estrutura do código-fonte respectivo através de elementos XML. Para além da simples representação, o JavaML permite também registar ligações entre classes (registo da estrutura em grafo do programa) através dos atributos XML: ID e IDREF. Por exemplo, é possível, num documento JavaML, ligar a definição de um método à sua invocação. O JavaML foi desenvolvido por Greg Badros [20], existindo um conversor implementado e disponibilizado pelo autor no seu web site, que funciona como um patch ao Jikes. O Jikes é o compilador opensource de Java da IBM. O JavaML é considerado a melhor representação de código-fonte Java em XML [21]. Domínio da Aplicação. O domínio de aplicação do dialecto JavaML é a engenharia de software, principalmente a área de reverse engineering. Outra utilização do JavaML é, por exemplo, a edição e documentação de código-fonte [22]. Esquema de dados. Apresenta-se um pequeno exemplo de código-fonte em Java seguido da respectiva representação em JavaML. import java.applet.*; import java.awt.*; public class MyClass extends Applet { public Object obj;

4 4 Luís Ramos e Pedro Strecht } public void painted( Graphics g ) { g.drawstring( "MyClass", 25, 50 ); } O JavaML equivalente gerado pelo Jikes é o seguinte: <?xml version="1.0" encoding="utf-8"?> <java-source-program> <java-class-file name=" java-ml-windows/windows/myclass.java"> <import module="java.applet.*"/> <import module="java.awt.*"/> <class name="myclass" visibility="public"> <superclass name="applet"/> <field name="obj" visibility="public"> <type name="object"/> </field> <method name="painted" visibility="public" id="myclass:mth-20"> <type name="void" primitive="true"/> <formal-arguments> <formal-argument name="g" id="myclass:frm-18"> <type name="graphics"/> </formal-argument> </formal-arguments> <block> <send message="drawstring"> <target> <var-ref name="g" idref="myclass:frm-18"/> </target> <arguments> <literal-string value="myclass"/> <literal-number kind="integer" value="25"/> <literal-number kind="integer" value="50"/> </arguments> </send> </block> </method> </class> </java-class-file> </java-source-program> Este exemplo, apesar de usar apenas um conjunto mínimo de elementos do dialecto JavaML, mostra que o mapeamento entre os dois formatos é relativamente directo e fácil de compreender. O conversor funciona como um compilador em que o output é, em vez do bytecode, o ficheiro JavaML. É fornecido pelo autor do JavaML uma Document Type Definition (DTD) que define o esquema de dados completo do dialecto. A figura 1 apresenta um diagrama com o modelo de dados do dialecto JavaML. Neste diagrama são indicados os elementos, os seus atributos e as relações entre os elementos.

5 Aplicação de Reverse Engineering: Java para UML 5 Fig. 1. Modelo de Dados do Dialecto JavaML 2.2 XMI O XML Metadata Interchange (XMI) [23] é um standard da OMG que permite representar metainformação sobre modelos em formato XML. Exemplo dessa metainformação representada pelo XMI são as extensões a modelos, documentação, diferenciação de versões, representação de modelos incompletos, ligação entre elementos do modelo, etc. O XMI, dadas as vantagens de ser um dialecto XML, foi concebido essencialmente para troca dessa metainformação entre ferramentas, repositórios e aplicações. O XMI não é um formato de leitura fácil por um humano e mesmo pequenos modelos podem dar origem a ficheiros grandes e bastante verbosos. A grande vantagem do XMI reside precisamente no facto de ser XML e, portanto, haver um grande leque de aplicações disponíveis para o seu tratamento. O modelo estrutural dos documentos XMI é uma instância do Meta Object Facility (MOF) [24]. O MOF é outro standard da OMG usado para descrever modelos de objectos nos mais variados domínios. Mais genericamente, MOF é uma tecnologia que permite definir e gerir metainformação. Por outro lado, o XMI não está preso ao MOF pois permite serializar e trocar objectos genéricos que não obedeçam ao modelo MOF. Domínio da Aplicação. O dialecto XMI é usado em variadas aplicações, designadamente, de análise (UML, para o qual foi inicialmente concebido [12]), de componentes (EJBs, IDLs, etc.) e de bases de dados (CWM).

6 6 Luís Ramos e Pedro Strecht Uma aplicação do XMI é o Common Warehouse Metamodel (CWM) [25] que é usado para trocar metainformação entre tecnologias ligadas aos domínios dos armazéns de dados, da gestão de conhecimento e dos portais. Outra aplicação interessante do XMI é o Software Process Engineering Metamodel (SPEM) [26] para a representação de modelos de processos de desenvolvimento de software. Tanto o CWM como o SPEM são standards da OMG e ambos interligam o XMI e os modelos MOF. O XMI pode também ser usado juntamente com o UML para a serialização de modelos UML. Esta combinação é frequentemente usada para a troca de modelos UML entre ferramentas CASE (secção 1.2). Existem especificações de metamodelos (representados por XML Schemas ou DTDs) que definem a forma de incluir elementos UML nos documentos XMI. Este esquema é também usado para as três aplicações já referidas: o CWM, o SPEM e o UML. Para tal, é definido como parte da especificação UML 2.0 [27] o UML Diagram Interchange [27] que consiste no formato XMI com suporte para UML. Enquanto que em versões anteriores dos standards XMI e UML (UML 1.4 Metamodel Interchange) não era possível registar a representação gráfica dos diagramas UML, nas versões XMI 2.0 e UML 2.0 foi acrescentada essa funcionalidade através da especificação do UML 2.0 Diagram Interchange. Enquanto que para o UML 1.4 Metamodel Interchange foi disponibilizado pela OMG um DTD oficial, para o UML 2.0 Diagram Interchange não foi encontrado nenhum DTD. Esquema de dados. No trabalho descrito neste documento só são utilizadas algumas das potencialidades do XMI (UML+DI) pelo que se dará mais ênfase à apresentação das características mais ligadas ao mesmo, nomeadamente as capacidades de representação de diagramas de classes. Considerando um exemplo simples de um metamodelo como o seguinte: Modelo Negócio Classe Cliente Atributo ID e Operação update. Uma representação possível deste modelo em UML Metamodel Interchange versão 1.4 (que não inclui informação de visualização) seria: <XMI> <XMI.header> </XMI.header> <XMI.content> <UML:Model xmi.id="a1" name= Negócio > < UML:visibility xmi.value="public"/> <UML:Namespace.ownedElement> <UML:Class xmi. id="a7" name= Cliente > <UML:Classifier.feature> <UML:Attribute name= ID > <UML:multiplicity> <XMI.field>1</ XMI.field> < XMI.field>1</ XMI.field> </UML:multiplicity> <UML:type>< DataType href= a247"/></uml:type> </UML:Attribute> <UML:Operation name= update > <scope xmi.value="instance"/> </UML:Operation> </UML:Classifier.feature> </UML:Class> </UML.NamespaceownedElement> </UML:Model> </XMI.content> </XMI> Os elementos essenciais do metamodelo são mostrados a cheio.

7 Aplicação de Reverse Engineering: Java para UML 7 Na versão do XMI (UML) usada neste trabalho (UML 2.0 Diagram Interchange) foi acrescentada ao documento XMI a parte da representação gráfica dos modelos. O elemento UML:Diagram contém a representação em grafo de todos os elementos do diagrama. Na figura 2 mostramos o essencial do modelo de dados desta parte do XMI (retirado da especificação do UML 2.0 Diagram Interchange). Fig. 2. Modelo de Dados do Dialecto XMI Neste diagrama apresentamos apenas os elementos fundamentais do dialecto. A representação em grafo dos diagramas é feita através dos elementos GraphNode (representa cada um dos nós do grafo) e GraphEdge (cada uma das ligações entre nós). O elemento Diagram representa cada um dos diagramas e o elemento SemanticModelBridge destina-se a fazer a ligação entre o modelo semântico e o de layout. O elemento GraphElement representa um elemento genérico do grafo que contém GraphConnectors. Fig. 3. Exemplo da estrutura XMI A figura 3 apresenta a estrutura básica em termos de elemento XMI de um diagrama com duas classes e com uma associação entre elas. Podemos ver neste diagrama que os GraphConnectors servem para fazer a ligação entre GraphNodes e GraphEdges. Na figura 4 apresenta-se a estrutura básica de representação interna de uma classe com 2 atributos. Podemos ver que a classe (caixa) é dividida em compartimentos e cada compartimento contém os seus elementos.

8 8 Luís Ramos e Pedro Strecht Fig. 4. Exemplo da estrutura XMI De seguida apresenta-se um exemplo da parte da representação gráfica de um documento XMI (versão 2) do metamodelo apresentado como exemplo neste ponto. <?xml version="1.0" encoding="utf-8"?> <XMI xmi.version="1.2" timestamp="sun Oct 31 14:52:46 GMT 2004" xmlns:uml="org.omg.xmi.namespace.uml"> <XMI.header> <XMI.documentation> <XMI.exporter>Netbeans XMI Writer</XMI.exporter> <XMI.exporterVersion>1.0</XMI.exporterVersion> </XMI.documentation> </XMI.header> <XMI.content> <UML:Diagram xmi.id="di$b3f9b8: e35:-7fc1" isvisible="true" name="class Diagram_1" zoom="1.0"> <UML:GraphElement.position> </UML:GraphElement.position> <UML:GraphNode.size> </UML:GraphNode.size> <UML:Diagram.viewport> <XMI.field>0.0</XMI.field> <XMI.field>0.0</XMI.field> </UML:Diagram.viewport> <UML:GraphElement.semanticModel> <UML:SimpleSemanticModelElement xmi.id="di$b3f9b8: e35:-7fc0" presentation="" typeinfo="classdiagram" /> </UML:GraphElement.semanticModel> <UML:GraphElement.contained> <UML:GraphNode xmi.id="di$b3f9b8: e35:-7fbf" isvisible="true"> <UML:GraphElement.position> </UML:GraphElement.position> <UML:GraphNode.size> </UML:GraphNode.size> <UML:GraphElement.semanticModel> <UML:Uml1SemanticModelBridge xmi.id="di$b3f9b8: e35:-7fbe" presentation=""> <UML:Uml1SemanticModelBridge.element> <UML:Class xmi.idref="sm$b3f9b8: e35:-7fbd" /> </UML:Uml1SemanticModelBridge.element> O XMI é uma linguagem muito verbosa (a representação completa deste simples metamodelo ultrapassa as 200 linhas).

9 Aplicação de Reverse Engineering: Java para UML 9 3. Aplicação 3.1 Arquitectura A arquitectura do sistema encontra-se esquematizada na figura 5. Fig. 5. Arquitectura do Sistema A aplicação consiste numa página web que solicita a inserção de um ou vários ficheiros com código-fonte Java ao utilizador. Esse código é convertido num documento JavaML através do conversor disponibilizado por G. Badros (secção 2.1). Para obter um documento XMI, o documento JavaML é processado por uma XSLT. O documento XMI obtido não inclui informação de visualização, consistindo somente na tradução da representação das classes em JavaML para XMI. O cálculo da informação de visualização dos diagramas, por ser bastante complexo, não foi efectuado por uma XSLT, mas por um módulo desenvolvido em Microsoft C#.NET que recebe o documento XMI e acrescentar-lhe informação de visualização, utilizando para tal a implementação DOM incluída na framework Microsoft.NET. A saída de dados da aplicação é um documento XMI com a representação do diagrama de classes (gerado pelo módulo.net) ou um documento SVG com o desenho do diagrama de classes (gerado através da XSLT de transformação de XMI em SVG desenvolvida por M. Jeckle [18]). Os documentos XMI podem ser importados por uma ferramenta CASE que permite visualizar os diagramas construídos, mas podem surgir problemas de compatibilidade já referidos (secção 1.2). O Poseidon for UML, por ser considerado uma implementação correcta da norma XMI 2.0, é utilizado para este fim. Os documentos SVG podem ser visualizados directamente num browser com um plug-in SVG.

10 10 Luís Ramos e Pedro Strecht 3.2 Tecnologias Para além do XML, são utilizadas as seguintes tecnologias: - XSLT [29], standard de transformação de documentos XML; - DOM [30], [31], interface independente de plataformas e linguagens que define um standard de representação, acesso e manipulação de objectos que fazem o mapeamento da estrutura de um documento XML; - C#.NET, a conhecida linguagem de programação da Microsoft. - ASP.NET, liguagem de desenvolvimento de páginas web de fácil integração com C#.NET. - Jikes, compilador de Java opensource da IBM que é usado para a geração dos documentos JavaML. A utilização de XSLT simplifica a conversão de JavaML para XMI porque, embora os dialectos sejam extremamente diferentes na sintaxe, têm bastantes semelhanças a nível de estrutura. Este tipo de conversões são extremamente trabalhosas em DOM. A utilização de uma linguagem imperativa como o C#.NET usando DOM para fazer os cálculos da representação gráfica dos modelos apresentou-se como a opção mais natural pois grande parte destes algoritmos é de natureza imperativa. Por exemplo, a implementação de heurísticas para identificação de pseudo-hierarquias nos modelos seria de uma complexidade muito superior utilizando uma linguagem funcional como o XSLT. 3.3 Implementação A implementação do trabalho divide-se essencialmente em três partes: a construção da transformação (XSLT) de JavaML em XMI, o módulo de cálculo automático do layout dos diagramas e a integração das partes numa página web. Interface Web. A interface web consiste numa simples página que permite o upload de ficheiros com código-fonte Java e a definição do tipo de output: XMI ou SVG. Após clicarmos no botão Gen Diagram da página, é apresentada outra página com o output do processo de reverse engineering no formato seleccionado. Inicialmente, todos os ficheiros de código-fonte são processados para um único ficheiro em JavaML. Este ficheiro é transformado num ficheiro XMI pelos dois componentes descritos a seguir. Se o output desejado for XMI o documento produzido é apresentado, se for SVG, é usada adicionalmente a XSLT de transformação de XMI em SVG. O SVG é enviado directamente para o browser. Fig. 6. Interface da Aplicação Web

11 Aplicação de Reverse Engineering: Java para UML 11 Transformação de JavaML para XMI. Após a conversão do código-fonte Java em JavaML, este é transformado num diagrama de classes em XMI através de uma XSLT. O documento XMI a gerar é composto por um modelo semântico e por um modelo de layout. O modelo semântico descreve, classifica e hierarquiza os elementos do modelo de classes, nomeadamente classes, atributos, tipos, operações e associações. Os elementos são organizados numa semantic-tree e são-lhes atribuídos identificadores. O modelo de layout descreve todos os elementos gráficos que constituem o diagrama, nomeadamente coordenadas de posição do diagrama, tamanho, janela de visualização, compartimento de nome da classe, compartimento de atributos, compartimento de operadores, separadores, associações, indicadores de multiplicidade das associações, etc. O mapeamento de alguns elementos de JavaML para elementos de XMI no modelo semântico é directo, como é exemplificado na tabela 1: Tabela 1. Mapeamento de elementos de JavaML em XMI. JavaML class field method XMI UML:Class UML:Attribute UML:Operation e UML:Method Foi necessário efectuar a detecção de atributos simples, que são de tipo primitivo (nativos do Java, como int, char, string), de atributos de tipo objecto, ou seja, cujo tipo é uma classe também presente no documento JavaML. Neste último caso, em vez de ser criado um atributo na respectiva classe, é criado uma associação entre classes. As associações entre classes são elementos do modelo semântico que são criadas fora das classes, envolvendo sempre duas classes. Muitos dos elementos do documento XMI têm que ter um identificador único de tipo alfanumérico. A ferramenta CASE de teste utilizada, o Poseidon, gera identificadores num formato próprio que não faz parte da norma. A sua existência é necessária por um lado para identificar univocamente um elemento e por outro para possibilitar a associação entre elementos do modelo semântico e elementos do modelo de layout. Um dos maiores problemas durante a criação da XSLT foi a geração destes identificadores, e a correcta referência de elementos do modelo semântico em elementos do modelo de layout. Convencionou-se que os elementos do modelo semântico têm como prefixo mod e os elementos do modelo de layout têm como prefixo diag. Apresenta-se, a seguir, um exemplo da geração de um identificador para um elemento UML:Class do XMI extraído da XSLT desenvolvida. <xsl:variable name="pos_class"> <xsl:value-of select="position()"/> </xsl:variable> <UML:Class xmi.id="mod:class:{$pos_class}" > Neste exemplo, o elemento UML:Class tem um identificador (atributo xmi.id) que refere que o elemento em causa é do modelo semântico (prefixo mod), é uma classe (indicação de class), seguida da sua posição no documento (variável pos_class). A variável pos_class é definida no início da criação do elemento UML:Class, e é reutilizada noutros pontos do documento. A esta variável é atribuída a posição da classe no documento através da função position(). Para cada classe do documento JavaML é criado um elemento UML:Class com identificador mod:class:1, mod:class:2, etc. Estas classes podem ser referenciadas a partir do seu identificador em elementos do modelo de layout, através do atributo xmi.idref, como mostra o seguinte exemplo: <UML:Uml1SemanticModelBridge xmi.id="diag:cd:usmb:c{$pos_class}" presentation=""> <UML:Uml1SemanticModelBridge.element> <UML:Class xmi.idref="mod:class:{$pos_class}"/> </UML:Uml1SemanticModelBridge.element> </UML:Uml1SemanticModelBridge> Durante o desenvolvimento da XSLT, o Poseidon foi uma ferramenta essencial para importar e validar os documentos XMI que iam sendo produzidos. Através da representação do ficheiro nessa ferramenta foi possível avaliar a qualidade do XMI gerado. O Poseidon é particularmente exigente no que diz respeito à verificação de erros no XMI, produzindo um relatório de erros com as anomalias detectadas. As anomalias mais frequentes foram a repetição do mesmo identificador para diferentes elementos.

12 12 Luís Ramos e Pedro Strecht Fig. 7. Ficheiro XMI na ferramenta CASE Poseidon for UML O documento XMI produzido inclui também toda a estrutura de layout, no entanto, esta informação é intencionalmente deixada a zero. O problema de posicionamento dos elementos gráficos do diagrama é resolvido por outro módulo da aplicação que colocará nos elementos de layout os valores respectivos. Cálculo automático de layout dos diagramas. O módulo que processa o XMI produzido na fase anterior usa a interface DOM para calcular automaticamente o layout dos diagramas. Este módulo processa o ficheiro XMI e constrói uma estrutura de objectos que, não fazendo o mapeamento directo do XMI, permite navegar no modelo UML. Dada a extensão e o nível de encapsulamento do XMI é impraticável editar/navegar os objectos directamente mapeados do XMI. Foi necessário implementar uma camada de abstracção que permite pensar no modelo de objectos não como um documento XMI mas como um diagrama de classes. A escolha do nível de abstracção desta representação do XMI é fundamental para o conforto posterior na implementação de algoritmos de layout. A arquitectura deste módulo assenta nas classes UmlDiagram, UmlClass e UmlAssociation. O objectivo é permitir a utilização de métodos muito genéricos para desenhar os diagramas, como por exemplo, umlclass.layout() para fazer o layout automático interno da classe, isto é, para redistribuir os componentes da classe, como atributos e métodos, pela caixa que representa a classe. Para o layout dos diagramas foram implementados métodos como umldiagram.layout() e umlassociation.layout(). O excerto de código seguinte mostra a implementação da função umldiagram.layout() que distribui as classes pelo diagrama: // faz o layout das classes foreach( UmlClass classe in classes ) { classe.position = new Point( ((x==0)?(x=400):(x=0)), ((x==0)?(y):(y+=300)) ); classe.layout(); } ( ) // calculo das coordenadas máximas (maxx e maxy) // faz o layout das associações foreach( UmlAssociation assoc in associations ) assoc.layout(); // define o tamanho do diagrama this.size = new Point( maxx, maxy ); O método de layout das associações utiliza a informação dos GraphConnectors dos GraphEdges para obter a localização das classes e definir os pontos da associação. Foi implementado um método de layout para os elementos GraphNode, isto é, cada um dos tipos de GraphNodes (AttributeCompartment, OperationCompartment, AssociationEnd, etc.) tem um método de layout específico. Para o layout interno de uma classe basta chamar o método UmlClass.layout() que, por sua vez, chama recursivamente o método layout para os seus constituintes. Por razões de espaço não detalhamos a implementação destes métodos.

13 A figura 5 apresenta um modelo de classes simplificado deste módulo: Aplicação de Reverse Engineering: Java para UML 13 Fig. 8. Modelo de dados do módulo de cálculo automático de layout Este módulo usa a implementação da interface DOM da framework Microsoft.NET o que facilita bastante o trabalho, como se apresenta a seguir: // define um novo conteúdo do campo dado public void setgraphnodeelement( XmlNode node, string elementname, Point newvalue ) { node.selectsinglenode( "./UML:" + elementname + "/XMI.field[1]", XmiDoc.nsMgr ).InnerText = newvalue.x.tostring(); node.selectsinglenode( "./UML:" + elementname + "/XMI.field[2]", XmiDoc.nsMgr ).InnerText = newvalue.y.tostring(); } Este código define as coordenadas de um nó na árvore DOM do documento XMI através da utilização da função SelectSingleNode da classe.net XmlNode que aceita uma expressão XPath. Este é apenas um exemplo do esquema usado para a alteração do documento XMI. 4. Testes e Avaliação Foram efectuados testes à aplicação para avaliar o seu desempenho relativamente ao tempo de execução, à qualidade do documento XMI produzido e do layout do diagrama de classes. Para o efeito foram escritas algumas classes de teste em Java que foram submetidas à aplicação. Para avaliar se as transformações de JavaML para XMI são correctamente efectuadas, criaram-se classes com diferentes estruturas, ou seja, com número variável de atributos e métodos. Foi de particular interesse o teste das associações entre classes, pelo que alguns atributos tinham como tipo classes também submetidas à aplicação. Efectuaram-se testes com diferentes combinações de associações. Foi possível a partir dos testes efectuados, para cada um dos parâmetros referidos, obter as seguintes conclusões: Tempo de execução. A aplicação fornece os resultados de forma rápida, verificando-se tempos de execução da ordem dos três a cinco segundos. O tempo de execução varia com o tamanho dos ficheiros de código e da complexidade das associações entre as classes.

14 14 Luís Ramos e Pedro Strecht Qualidade do documento XMI produzido. Para validar a qualidade do documento XMI produzido foi utilizado o Poseidon. Sempre que existe algum erro no documento XMI o Poseidon não apresenta o diagrama e regista num ficheiro de erros os detalhes dos erros detectados. Os erros mais frequentes durante o desenvolvimento da XSLT de transformação de JavaML para XMI foram a repetição de identificadores para os mesmos elementos. À medida que o desenvolvimento decorria, esses erros foram sendo eliminados. Para os testes efectuados na fase final, não foram detectados quaisquer erros no XMI, uma vez que o Poseidon foi sempre capaz de apresentar o diagrama. Conclui-se que os documentos XMI produzidos são válidos. Layout do diagrama de classes. A validação e teste da qualidade do layout dos diagramas de classes só pode ser feita através da sua visualização. Para tal foi utilizado o Poseidon, importando o documento XMI produzido. Em alternativa, é possível definir o SVG como formato de saída de dados da aplicação que mostra o documento SVG gerado directamente no browser. O algoritmo de layout desenvolvido produz bons resultados no posicionamento das classes no diagrama. As classes são posicionadas de forma adjacente entre si e nunca são sobrepostas. As associações entre as classes são correctamente representadas através de linhas entre a classe de origem e a classe destino. Foi detectado que por vezes, as associações entre duas classes são desenhadas por cima de uma terceira classe. Isto acontece porque o algoritmo de layout das associações simplesmente não contempla este problema. 5. Conclusões 5.1 Satisfação dos Objectivos Podemos concluir que os principais objectivos deste trabalho foram alcançados. O objectivo central de gerar um diagrama a partir do código-fonte em Java foi completamente atingido. Conforme previsto no início do trabalho foram deixadas de fora algumas situações, como por exemplo, a representação de heranças. Foi atingido o objectivo de gerar documentos XMI 2.0 válidos e compreensíveis tanto pela ferramenta CASE Poseidon (única no mercado que implementa a norma) como pela XSLT de geração de SVGs [18]. A qualidade do layout dos diagramas gerados não é uma métrica de sucesso fundamental do trabalho dado que, neste aspecto, o objectivo do trabalho era somente demonstrar as potencialidades da arquitectura do sistema. De notar finalmente que foi possível neste trabalho construir uma camada de abstracção sobre o XMI que nos permitiu implementar um esquema que facilitasse o desenho dos diagramas. 5.2 Trabalho Futuro Uma das possibilidades de trabalho futuro, é o acrescento à aplicação de outras linguagens de programação, para além do Java, como entrada de dados. Este trabalho poderia basear-se, por exemplo, na construção de uma transformação XSLT entre a representação XML do código-fonte da nova linguagem em JavaML. Apesar de para efeitos de conversão de código-fonte entre várias linguagens esta tarefa ser muito complicada, para efeitos de representação UML esta transformada não necessitaria de ser muito completa para se obterem bons resultados ao nível dos diagramas. A geração de código-fonte a partir de diagramas UML poderia ser implementada através do esquema inverso ao usado neste trabalho. Isto é, uma XSLT de conversão de XMI em JavaML e por sua vez em código-fonte Java (XSLT já disponibilizada pelo autor do JavaML). Adicionalmente poderiam ser usados os mecanismos do XMI para guardar código-fonte que permitissem implementar um sistema de roundtrip engineering totalmente baseado em XML. A disponibilização num web service do serviço implementado neste trabalho poderia ser interessante para, por exemplo, ferramentas de documentação que utilizassem o serviço remoto de reverse engineering. Igualmente interessante seria a disponibilização em forma de biblioteca da API de acesso ao XMI desenvolvida que permite o fácil desenvolvimento de heurísticas de desenho dos diagramas.

15 Aplicação de Reverse Engineering: Java para UML 15 Referências [1] Rational Rose web site. [2] Together Control Centre web site. [3] Poseidon for UML web site. [4] Anders Henriksson, Henrik Larsson. A Definition of Round-trip Engineering. [5] Developer.com, UML Tools. [6] ArgoUML web site. [7] Visual Paradigm web site. [8] Plataforma Eclipse. [9] H. Eichelberger, J. Gudenberg. UML Class Diagrams State of the Art in Layout Techniques. [10] J. Michaud., M.-A. Storey, H. A. Müller. Integrating Information Sourced for Visualizing Java Programs. [11] Oracle JDeveloper 10g IDE. [12] Perdita Stevens. Small-Scale XMI Programming: A Revolution in UML Tool Use? [13] Jeffrei Korn, Yih-Farn Chen, Eleftherios Koutsofios. Chava: Reverse Engineering and Tracking of Java Applets. [14] Osvaldo Pinali Doederlein. Design Pattern Extraction for Software Documentation. [15] Mammas, E. and Kontogiannis, C., "Towards Portable Source Code Representations using XML", 7th Working Conference on Reverse Engineering WCRE.Australia, [16] Maletic, J.I., Collard, M., Marcus, A. Source Code Files as Structured Documents", 10th IEEE International Workshop on Program Comprehension IWPC, [17] Raihan Al-Ekram and Kostas Kontogiannis. An XML-based Framework for Language Neutral Program Representation and Generic Analysis. [18] M. Jeckle, D. Boicourt e B. Stritt. Projecto UML2SVG. [19] G. J. Badros. JavaML: A Markup Language for Java Source Code. International World Wide Web Conference (WWW9) [20] G. J. Badros. JavaML page. [21] Chu Tommy, Wong Ken. Benchmarking on Java XML Transformers. [22] Ademar Aguiar. XSDoc - an Extensible Infrastructure for Framework Documentation. [23] Object Management Group. XML Metadata Interchange (XMI) v [24] Object Management Group. Meta Object Facility (MOF) v1.4, [25] Object Management Group. Common Warehouse Metamodel (CWM), v1.1, [26] Object Management Group. Software Process Engineering Metamodel, v1.0, [27] Object Management Group. Unified Modeling Language (UML), v1.4, [28] Object Management Group. UML Diagram Interchange, v2.0, [29] J. Clark. XSL Transformations (XSLT) v1.0. W3C Recommendation, [30] DOM Level 2 Core v1.0, W3C Recommendation, [31] A. Le Hors et al. Document Object Model (DOM).