Diretrizes: Estruturando o Modelo de Implementação para Aplicativos J2EE
Tópicos
Introdução
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
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
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
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
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.
|