Diretrizes: Projetando Subsistemas para Aplicativos J2EE
Tópicos
Introdução
Essas diretrizes suplementam as Diretrizes: Subsistema de Design
com orientação específica ao desenvolvimento de aplicativos J2EE. Recomendamos a leitura de
Diretrizes: Subsistema de Design antes da leitura dessas diretrizes específicas do J2EE.
Essas diretrizes aplicam-se a subsistemas de design com maior granularidade que EJBs
individuais. Para obter as diretrizes sobre EJBs, consulte Diretrizes: Enterprise
Java Beans.
Observe também que um Cliente Aplicativo é considerado um Subsistema de Design
especializado. Consulte Diretrizes: Cliente Aplicativo.
Desenvolvendo Subsistemas de Design
Quando um subsistema é identificado pela primeira vez, sua tecnologia pode ser neutra, inicialmente.
Isto é, ele pode ser especificado por interfaces, uma descrição textual e algumas
máquinas de estado que descrevem o comportamento esperado das operações. Entretanto,
esses subsistemas com tecnologia neutra evoluem normalmente para representações
de tecnologias específicas.
A seguir, um exemplo de como um subsistema de design com tecnologia neutra
evolui para um subsistema com tecnologia específica.
Especificação do Subsistema (Visualização da caixa preta do subsistema)
Uma especificação de subsistema pode, inicialmente, ser modelada como tendo interfaces UML abstratas.
Considere o design preliminar de um subsistema do Cliente, mostrado na Figura 1.

Figura 1: Subsistema do Cliente com Design
Preliminar
ICustomerMgt é definido ainda mais para ter operações, como um "getCustomerDetails"
e um "setCustomerDetails".
Conforme o design se torna mais detalhado (Atividade:
Design do Subsistema), essas interfaces abstratas são substituídas por elementos específicos
do idioma e da tecnologia. (Você pode optar por manter o modelo mais abstrato
do subsistema; por exemplo, se houver necessidade de implementar o mesmo
design em mais de um idioma ou tecnologia. Consulte Conceitos:
Mapeando de Design para Código para obter uma discussão dessas opções.) As
realizações de caso de uso de design correspondentes são atualizadas
para corresponderem a mudanças da interface.
Neste exemplo, a Figura 2 é uma visualização da caixa preta ou da especificação do subsistema do
Cliente. Um design subseqüente indicava que o subsistema do Cliente deveria ser
um EJB de entidade. O subsistema de design preliminar é transformado nas
interfaces EJB, como a seguir:
- ICustomerMgt =>
- CustomerHome ?EJBEntityHomeInterface?
- ICustomer =>
- Customer ?EJBRemoteInterface?

Figura 2: Visualização da Caixa Preta do Subsistema de Design
do Cliente
As interfaces expostas pelos Subsistemas de Design podem incluir interfaces Java
comuns, interfaces EJB (como Interfaces Java), interfaces EJB (remotas
e home) ou até mesmo uma ou mais classes delegadas ou de acesso que
ocultam a existência de um ou mais EJBs completamente. Observe que todas elas, incluindo
as interfaces Java, são modeladas como classes UML e não como interfaces UML (consulte Diretrizes:
Interfaces para Aplicativos J2EE). Por exemplo, um bean de sessão é sempre
utilizado como fachada para acessar um conjunto de beans de entidade estreitamente relacionado. Nesse
caso, apenas as interfaces do bean de sessão seriam exportadas do subsistema.
Os beans orientados a mensagens consomem mensagens assincronicamente de um destino (ou
nó de extremidade). Portanto, um destino também poderia servir como uma "interface"
para um Subsistema de Design que contém beans orientados a mensagens.
Observe que, desde então, as interfaces locais são utilizadas por outros EJBs estreitamente acoplados no
mesmo Subsistema de Design e aparecem na realização de subsistemas
com maior freqüência que nas interfaces visíveis expostas por um subsistema.
Para obter informações adicionais sobre interfaces em um aplicativo J2EE, consulte Diretrizes:
Interfaces para Aplicativos J2EE. Para obter informações adicionais sobre a modelagem de EJBs,
consulte Diretrizes: Enterprise JavaBeans.
Realização do Subsistema (Visualização da caixa branca do subsistema)
Os Subsistemas de Design devem expor apenas o que os clientes requerem. Portanto,
a classe que implementa um EJB é privada para o subsistema e, logicamente,
faz parte da realização do subsistema. A realização do subsistema poderia tornar-se:
- um conjunto de EJBs e classes de colaboração, ocultas por uma ou mais classes visíveis
delegadas ou de acesso
- um único EJB sem outras classes de colaboração
Continuando o exemplo anterior de subsistema do Cliente, a realização do
subsistema inclui:
- CustomerEntityEJB (componente) ?EJBEntityBean?
- CustomerBean ?EJBImplementation?
- classes auxiliares adicionais
A Figura 3 mostra uma visualização da caixa branca (isto é, dentro do subsistema) do
Subsistema de Design. Observe que as classes EJB são modeladas conforme descrito em Diretrizes:
Enterprise JavaBeans. Essa visualização interna do subsistema é referida como
a realização do subsistema. Nessa visualização, vemos decisões não visíveis aos
clientes. Por exemplo, nessa realização do subsistema, uma classe DAO (Data Access
Object) acessa dados persistentes utilizando a API do JDBC. (Em outro design,
a persistência gerenciada pelo contêiner pode ter sido utilizada.) Consulte Diretrizes:
Enterprise JavaBeans para obter informações adicionais sobre as classes DAO.

Figura 3: Visualização da Caixa Branca do Subsistema de Design
do Cliente
|