Finalidade

Essa seção fornece links às informações adicionais relacionadas ao mentor de ferramentas.


As etapas no mentor da ferramenta correspondem com as da atividade. Os links para os tópicos na Ajuda on-line do RSA estão marcados com .

Visão Geral

Este mentor de ferramentas assume que você definiu a estrutura de nível superior de seu Modelo de Implementação, conforme descrito nas Diretrizes da Estrutura do Modelo para o Rational Studio Architect. As etapas neste mentor de ferramentas permitem que essa estrutura inicial seja refinada.

As etapas a seguir são executadas neste mentor de ferramentas:

Informações de Ferramenta Adicional

Estabelecer a Estrutura do Modelo de Implementação Para o início da página

A abordagem recomendada no RSA é MDD - Desenvolvimento Orientado a Modelos (consulte Desenvolvimento Orientado a Modelos e Arquitetura Orientada a Modelos). Se essa abordagem for seguida pela equipe de desenvolvimento, o Modelo de Implementação será consistentemente direcionado pela organização do Modelo de Design. À medida que os Subsistemas de Implementação são identificados, eles devem ser modelados como pacotes ou subsistemas no Modelo de Design. De um modo geral, ao identificar os pacotes no Modelo de Design, você deve considerar como eles serão mapeados para projetos do Eclipse/RSA. Subsistemas maiores geralmente são mapeados para seus próprios projetos, pacotes mais granulares geralmente são mapeados para pastas de origem nos projetos. Consulte as seções das Diretrizes da Estrutura do Modelo para o Rational Software Architect que descrevem as Estruturas do Projeto e a organização interna do Modelos de Implementação e de Design.

No RSA, a Visualização de Implementação pode ser definida utilizando os pacotes de <<perspectiva>>, contendo diagramas que mostram dependência entre os subsistemas. Dependendo do tipo de transformação aplicada ao Modelo de Design, as dependências que você define entre os pacotes/subsistemas podem ser mapeadas para as declarações de importação 3GL e declarações de dependência do projeto em metadados do projeto Eclipse/RSA.

Uma vez gerado o código, diagramas mais detalhados da UML podem ser produzidos, mostrando as construções em nível de implementação e seus relacionamentos, criando Diagramas de Classe diretamente nos projetos e ocupando-os arrastando os artefatos de implementação até eles. Consulte os tópicos da Ajuda on-line relacionados ao UML Visual Editor para Java.

Se houver necessidade de representar os projetos e pacotes reais do RSA nos quais você espera que o código e os arquivos relacionados residam, antes de qualquer geração de código, um Modelo de Visão Geral de Implementação poderá ser útil. Para obter informações adicionais, consulte os tópicos relacionados ao Modelo de Implementação no white paper Diretrizes da Estrutura do Modelo para o Rational Software Architect.

Ajustar Subsistemas de Implementação Para o início da página

Não há orientação RSA específica para esta etapa.

Definir Importações para cada Subsistema de Implementação Para o início da página

Em um ambiente MDD, as dependências no Modelo de Implementação se refletirão bastante naqueles definidas explicitamente ou implicitamente no Modelo de Design. As características específicas são determinadas pelas transformações de geração de código aplicadas ao Modelo de Design.

Se um Modelo de Visão Geral de Implementação for utilizado, este será o local para mostrar as dependências esperadas entre os objetos e pacotes, que podem ser úteis na identificação dos requisitos de construção do sistema (consulte Diretrizes da Estrutura do Modelo para o Rational Software Architect).

Decidir Como Tratar Executáveis (e Outros Objetos Derivados) Para o início da página

Em um ambiente MDD, dependendo do tipo de transformação aplicada ao Modelo de Design, vários tipos de artefatos implementáveis podem ser gerados. Por exemplo, a partir de elementos como as classes de <<controle>> e <<entidade>>, EJBs de entidade e de sessão podem ser gerados para um destino do J2EE, incluindo: o código para as classes de implementação, as interfaces e o conteúdo do descritor de implementação que aloca os EJBs para JARs do EJB e mapeia esses JARs para EARs.

Você pode optar por modelar artefatos implementáveis no nível conceitual, utilizando um modelo de implementação do RSA. Se optar por fazer isso, irá modelá-los utilizando nós e artefatos da UML. Atualmente, as transformações do RSA não alavancam a semântica desses diagramas para gerar dados de implementação, portanto seus diagramas serão puramente conceituais e úteis apenas como documentação.

Opcionalmente, você também pode representar os artefatos reais de implementação nesses diagramas, soltando-os no canvas e conectando-os (utilizando dependências) aos elementos conceituais do diagrama.

Decidir como Tratar Recursos de Teste Para o início da página

Não há orientação RSA específica para esta etapa.

Atualizar a Visualização de Implementação Para o início da página

Se houver uma Visualização de Implementação separada, ela deverá ser mantida. A recomendação geral apresentada no white paper Diretrizes da Estrutura do Modelo para o Rational Software Architect é utilizar os pacotes de <<perspectiva>>, contendo diagramas que mostram dependências entre os subsistemas.

Avaliar o Modelo de Implementação Para o início da página

Pode ser útil publicar modelos no formato html. Observe também que é possível copiar diagramas do RSA para o Microsoft Word e outros programas.

Para obter informações adicionais, consulte Publicando Modelos para Revisão Fora da Ferramenta de Modelagem e os tutoriais a seguir:

  • Gerando Relatórios de Modelo Padrão
  • Gerando Relatórios de Modelo Personalizado
  • Publicando Modelos na Web

Informações da Ferramenta AdicionalPara o início da página

Folhas de Dicas:

  • Estruturando o Modelo de Implementação

Rational Unified Process   2003.06.15