Diretrizes: Estruturando o Modelo de Implementação para Aplicativos J2EE

Tópicos

Introdução To top of page

Assumimos que você esteja familiarizado com as informações gerais sobre o J2EE como uma plataforma de tecnologia, descritas em Conceitos: Visão Geral da Plataforma J2EE, Enterprise JavaBeans e Conceitos: Mapeando de Design para Código. Alguns dos conceitos nessa diretriz pertencem à UML 1.4, enquanto você pode estar utilizando-a no contexto de um plug-in com base na UML 1.3. Se for difícil para você tentar entender essas coisas, verifique o que as duas especificações UML tem a dizer sobre o assunto.

Estruturando o Modelo de Implementação To top of page

A Atividade: Estruturar o Modelo de Implementação descreve como produzir uma estrutura de Modelo de Implementação firmemente alinhada com a estrutura do Modelo de Design mas que, ao mesmo tempo, reflete qualquer restrição do ambiente de desenvolvimento e suporta o desenvolvimento paralelo e a integração incremental.

A estrutura do Modelo de Implementação para um aplicativo J2EE depende do ambiente de desenvolvimento e de implementação, entretanto, em geral, há quatro prováveis estruturas em um Modelo de Implementação do J2EE:

  • Suporte de implementação (módulos e descritores de implementação do J2EE)
  • Estrutura de diretórios virtual (JSPs, páginas HTML)
  • Diretório Java para elementos implementados em um servidor da Web (servlets, JavaBeans)
  • Diretório Java para elementos implementados em um servidor de aplicativos EJB (EJBs)

Modelando Subsistemas de Implementação To top of page

A Visualização da Implementação no Artefato: Documento da Arquitetura de Software fornece uma visão geral de alto nível do modelo de implementação. Isso inclui a identificação dos Subsistemas de Implementação. Em um aplicativo J2EE, os Subsistemas de Implementação podem não ser mapeados para um único diretório no sistema de arquivo ou um único pacote em um modelo, porque o Subsistema de Implementação pode incluir elementos não-Java de um modelo (como JSPs e páginas HTML) e elementos Java de outro. Uma estratégia para a manipulação desse impasse é ter uma estrutura de pacotes em paralelo em cada modelo. Os pacotes com nomes iguais em cada modelo são associados implicitamente.

É comum para um Subsistema de Implementação fornecer a implementação para um único Arquivo de Implementação implementável (um arquivo JAR, WAR ou EAR). Nesse caso, a identificação dos arquivos implementáveis pode servir para identificar os Subsistemas de Implementação.

Uma representação de elementos físicos, consistindo em Diretórios de Implementação e Arquivos de Implementação, pode estar em cada Subsistema de Implementação. É possível que também haja elementos lógicos, consistindo em classes, componentes, pacotes, etc. que correspondem aos elementos de Artefato: Modelo de Design, mas que são um modelo preciso do código fonte (um modelo de engenharia de permuta). Consulte Conceitos: Mapeando de Design para Código para obter informações adicionais sobre o relacionamento entre o Modelo de Design e o Modelo de Implementação.

Os modelos de engenharia de permuta fornecem uma representação precisa do código fonte. No J2EE, cada pacote em um modelo Java representa um pacote Java, cada classe representa uma classe Java e assim por diante. Entretanto, há sempre uma necessidade de suplementar os modelos de engenharia de permuta com informações adicionais, incluindo:

  • diagramas que mostrem informações não produzidas automaticamente como parte da engenharia de permuta
  • abstrações de nível superior do modelo

O Modelo de Design resume classes, componentes, pacotes, etc. Entretanto, também pode haver uma necessidade de abstrações de nível superior ou de diagramação adicional para os elementos físicos (arquivos e diretórios). Eles são descritos nas seções subseqüentes.

Modelando Diretórios de Implementação To top of page

A engenharia de permuta geralmente manipula apenas um subconjunto dos diretórios requeridos no ambiente de desenvolvimento. Os diretórios adicionais são sempre necessários para organizar artefatos de teste, unidades de implementação, documentação, etc. Geralmente, a modelagem não é necessária, já que os diretórios podem ser visualizados como parte do sistema de arquivo.

Modelando Arquivos de Implementação To top of page

Os arquivos de implementação, em geral, não são modelados, a menos que algum suporte seja fornecido por uma ferramenta de engenharia de permuta ou algum relacionamento não tão óbvio precise ser mostrado.

Geralmente, há um arquivo .java para cada interface ou classe Java e um arquivo .class compilado para cada arquivo .java. Portanto, a modelagem desses arquivos não apresenta muito interesse.

No J2EE, um subsistema contém geralmente um ou mais arquivos archive (arquivos JAR, WAR ou EAR).

Os arquivos archive são modelados mais corretamente como um relacionamento de composição do arquivo archive para os arquivos nele contidos. Entretanto, quando os arquivos .class compilados são combinados para compor um arquivo JAR, talvez seja mais útil mostrar uma dependência do arquivo JAR para as classes e interfaces implementadas por último.

Se o Subsistema de Implementação produzir apenas um arquivo JAR, talvez então não seja preciso nenhuma modelagem; especialmente se todos os arquivos implementáveis no Subsistema de Implementação puderem ser assumidos como parte do arquivo JAR.

Sobrepondo Arquivos Archive

É possível, mas geralmente não aconselhável, definir dois arquivos archive que contenham alguns dos mesmos elementos. Por exemplo, dois arquivos EAR podem conter alguns, mas não todos os mesmos EJB JARs; ou dois EJB JARs poderiam conter os mesmos EJBs, mas descritores de implementação diferentes.

É melhor que os arquivos archive não se sobreponham para manter uma correspondência próxima entre os subsistemas de implementação e os arquivos archive implementáveis. Entretanto, quando a sobreposição for necessária, poderia ser útil fazer a modelagem juntamente com análise racional.



Rational Unified Process   2003.06.15