Transformações de Java em UML

A transformação de Java em UML transforma o código Java™ em elementos de modelo UML.

Origens de Transformação Válidas

É possível especificar os seguintes itens como a origem de uma transformação de Java em UML:
  • Projeto Java
  • Pasta de origem em um projeto Java
  • Pacotes Java
  • Classes Java

Destinos de Transformação Válidos

É possível especificar os seguintes itens como um destino de transformação:
  • Projeto ou pasta no espaço de trabalho
  • Modelo UML
  • Pacotes raiz
Nota: Se a configuração de transformação implementa o design contract management protocol (DCMP) do Modelagem Reconciliada, você deve especificar elementos de origem e de destino que são válidos para transformações de Java em UML e de UML-para-Java.

Se você especificar um projeto ou pasta no espaço de trabalho como o destino da transformação, a transformação cria um novo modelo UML no contêiner especificado. O nome do modelo é JavaUMLModel e um registro de data e hora é anexado ao nome para assegurar que o modelo e o nome do arquivo sejam exclusivos. O registro de data e hora é a hora do sistema especificada; por exemplo, JavaUMLModel1164050609968.emx.

Se você especificar um modelo UML como o destino de transformação, a transformação cria um modelo UML temporário e compara o modelo temporário para o modelo de destino especificado.

Suporte para Enumerações Customizadas

É possível ativar uma extensão de transformação de UML em Java para gerar enumerações que preservam o nome e os valores dos literais de enumeração como cadeias recuperáveis. Em engenharia de roundtrip ou em um ambiente de desenvolvimento iterativo, é possível transformar estas enumerações customizadas em UML, ativando a Extensão de Enumeração Customizada de Java em UML ao configurar uma transformação de Java em UML.

Suporte para Diversos Projetos e suas Interdependências

Se você trabalhar com diversos projetos Java ou modelos UML, é possível criar um arquivo de associação que define associações entre elementos de origem Java e elementos de destino UML em diferentes projetos quando os elementos podem estar fora do escopo de uma configuração de transformação. Uma associação define um link entre um elemento Java e um elemento UML. Um arquivo de associação de Java em UML tem .xmi como uma extensão de nome de arquivo. Diversas configurações de transformações podem compartilhar um arquivo de associação.

Cada associação especifica o local de um elemento Java e um elemento UML. É possível especificar os seguintes elementos Java em uma associação:
  • Projeto
  • Pacote
  • Pasta de origem
  • Arquivo JAR
É possível especificar os seguintes elementos UML em uma associação:
  • Modelo
  • Pacote

Por padrão, se a transformação de Java em UML não puder criar uma referência a um elemento de destino UML concreto, ela cria uma referência visual a um elemento Java correspondente. Se você definir uma associação entre os elementos, a transformação cria uma referência a um elemento de destino UML concreto e não cria uma referência visual.

Por exemplo, considere um espaço de trabalho que contém os seguintes itens:
  • Projetos Java denominados JP1 e JP2
    • JP2 contém um pacote denominado Package1 que contém uma classe denominada Class2
    • JP1 contém diversos arquivos JAR e uma classe, denominada Class1, que contém uma referência a JP2.Package1.Class2
  • Modelos UML denominados M1 e M2
  • Uma configuração de transformação denominada TC1 que especifica JP1 como a origem de transformação e M1 como o destino de transformação
  • Uma configuração de transformação denominada TC2 que especifica JP2 como a origem de transformação e M2 como o destino de transformação
Outro usuário de TC1 cria um arquivo de associação que contém as seguintes associações de Java em UML:
  • JP1 em M1
  • JP2 para M2

Porque Class2 existe em JP1 e não em JP2, a primeira entrada no arquivo de associação, apesar de desnecessária, pode ser útil para os outros usuários de transformação cujas configurações de transformação definem esse projetos como projetos de origem ou de destino.

Neste exemplo, a transformação cria diferentes referências dependendo de onde você aplica o TC1.
  • Se TC1 executar antes de TC2, então a transformação de Java em UML cria uma referência ao elemento UML concreto denominado M2.Package1.Class2.
  • Se TC1 não tiver sido executado antes de TC2, então M2.Package1.Class2 não existe. Neste exemplo, se uma associação se refere a um elemento que não existe, a transformação de Java em UML cria uma referência visual com JP2.Package1.Class2.

Preservação de Informações de Javadoc de Releases Anteriores de Produtos de Modelagem do Rational

Para preservar as informações entre as tags Javadoc que foram geradas em releases anteriores do produto, execute a transformação de Java em UML ao migrar as informações de Javadoc para a propriedade da documentação do elemento correspondente no modelo UML.
Nota: Para gerar tags Javadoc que foram geradas em releases anteriores do produto, é possível modificar os modelos de código no Java Development Toolkit.

Comparando e Fundindo Saída de Transformação com Modelos UML de Destino

A transformação de Java em UML utiliza a funcionalidade de comparação e fusão para determinar as diferenças entre o modelo de destino e o modelo temporário gerados pela transformação. Ao executar a transformação de Java em UML, o editor de fusão exibe as diferenças entre os dois modelos. No editor de fusão, é possível selecionar as alterações que a transformação funde ao modelo de destino.

Filtros no Editor de Fusão

Você pode utilizar os filtros no editor de fusão para mostrar ou ocultar os diferentes tipos de deltas que ocorrem quando você executa a transformação de Java em UML. Para simplificar a visualização no editor de fusão, clique no ícone Filtros na barra de ferramentas e selecione os filtros para aplicar.

Por exemplo, a transformação não configura limites superiores e inferiores ao transformar elementos de multiplicidade, como atributos e parâmetros. No modelo temporário, limites superior e inferior são configurados para nulo se nenhum tipo de coleta for gerado. Se os limites superior e inferior forem especificados explicitamente no modelo UML de destino, mesmo se esses valores de limite especificarem uma multiplicidade padrão igual a 0..1, existe um delta entre o modelo temporário e o modelo de destino. Para modelos grandes, esses deltas triviais podem ser numerosos, o que dificultaria ver outros deltas no editor de fusão. Para ocultar esse tipo de delta, selecione o filtro Remover por Filtro Alterações Triviais de Limite Inferior e Superior.

Integração com a Equipe de Suporte

A transformação fornece funcionalidade de integração com os sistemas de controle de versão IBM® Rational Team Concert, CVS, Rational ClearCase, e Rational ClearCase LT, que possibilita efetuar o registro de saída dos arquivos automaticamente ou incluir novos arquivos. É necessário ativar os recursos de equipe para trabalhar com os sistemas de gerenciamento de configuração.


Feedback