Tópicos

Introdução To top of page

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 To top of page

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. 

Diagrama descrito no texto de acompanhamento.

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?

Diagrama descrito no texto de acompanhamento.

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.

Diagrama descrito no texto de acompanhamento.

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



Rational Unified Process   2003.06.15