Mentor de Ferramentas: Estruturando
o Modelo de Implementação Utilizando o Rational Software Architect
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
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.
Não há orientação RSA específica para esta etapa.
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).
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.
Não há orientação RSA específica para esta etapa.
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.
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
Folhas de Dicas:
Estruturando o Modelo de
Implementação
|