Finalidade

A finalidade do EJB Design é identificar e especificar as Classes de Design que constituem os EJBs (Enterprise JavaBeans).  

Assim como com atividade: Design da Classe, a finalidade é:

  • Assegurar que sejam fornecidas informações suficientes para implementar o EJB sem ambigüidade.
  • Manipular os requisitos não-funcionais relativos ao EJB.
  • Incorporar os mecanismos de design utilizados pelo EJB; particularmente, incorporar os mecanismos de design específicos ao tipo de EJB que está sendo projetado.
Função:  Designer  
Freqüência:  Ocorre repetidamente durante todas as iterações após a Iniciação. É possível que também ocorra na Iniciação se houver atividades de protótipo.
Etapas
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   
Informações Adicionais:   

Detalhes de Workflow:   

Identificar EJBs Para o início da página

Identifique os EJBs nas Classes de Análise e/ou elementos iniciais do Modelo de Design. Também é possível identificá-los como parte de um padrão de design. Incorporar um padrão é executar efetivamente várias das etapas nesta atividade (incluindo novas classes, operações, atributos e relacionamentos), porém, de acordo com as regras definidas pelo padrão. Para obter exemplos de padrões de J2EE, consulte Padrões Núcleo de J2EE ([ALU01].

Algumas decisões-chave devem ser tomadas.

  • Como mapear a "lógica de negócios" para as classes EJB e não-EJB - quantas classes são necessárias e de quais tipos. Por exemplo, as classes que representam objetos com informações de "estado" que precisam persistir devem ser mapeadas para os EJBs de entidade. As classes que executam serviços e não possuem seus próprios dados persistentes devem ser mapeadas para os EJBs de sessão ou de mensagem.
  • Para os beans de sessão, se o bean de sessão com preservação de estado ou sem preservação de estado deve ou não ser utilizado (a decisão de utilizar um bean de sessão com preservação de estado versus um sem preservação de estado é uma parte crítica da identificação da responsabilidade do bean de sessão versus outras classes identificadas). Os beans de sessão sem preservação de estado são mais eficientes porque é possível compartilhar uma instância entre os pedidos não-contíguos, em vez de "ligar" a uma determinada sessão de atividade. Além disso, se o EJB for utilizado como um nó de extremidade de serviço da Web, é necessário que ele seja sem preservação de estado.
  • Quais padrões e mecanismos de design o bean deve utilizar ou de quais deve participar. A utilização de padrões e mecanismos específicos afeta o número e o tipo de EJBs identificados.
    Nota:
    O Arquiteto de Software decide geralmente quais padrões e mecanismos devem ser utilizados pelo projeto e o Designer segue as diretrizes.

Para obter informações adicionais sobre a identificação de EJBs, consulte Diretrizes: Identificar EJBs.

Definir Atributos Ir para o início da página

Identifique os atributos para o EJB.

Especificamente, para cada bean de entidade, identifique seus atributos persistentes e chave principal.

Para obter informações adicionais sobre a definição de atributos do EJB de entidade, consulte Diretrizes: Projetando Beans de Entidade.

Definir Operações Para o início da página

Esta etapa é aplicável a beans de sessão e de entidade. Não é aplicável a beans orientados a mensagens.

O design de operações é descrito por Atividade: Design da Classe, especificamente a etapa Definir Operações.

Algumas decisões-chave para os EJBs:

  • Se uma operação específica precisa ou não estar disponível para clientes locais ou remotos. Normalmente, um EJB possui apenas interfaces de componentes locais ou remotas. Se você estiver trabalhando com uma versão do J2EE superior a 1.3, uma prática padrão é manipular todo o acesso ao cliente remoto por meio de EJBs de sessão, que manipulam EJBs de entidade na mesma JVM por meio de interfaces de componentes locais.
  • Como agrupar os atributos em objetos de valores para operações get/set. Se você fornecer interfaces remotas para EJBs de entidade, é melhor definir uma classe de "objeto de valor" para a transmissão de uma captura instantânea dos dados do bean de uma vez, em ambas as direções. Isso minimiza o código extra da rede em comparação com as repetidas chamadas get/set para campos de bean individuais. Consulte Padrões Núcleo de J2EE ([ALU01] para obter informações adicionais.

Para obter informações adicionais sobre a definição de operações EJB, consulte Diretrizes: Projetando EJBs.

Definir ComportamentoPara o início da página

O comportamento do design da classe é descrito por Atividade: Design da Classe.

Uma etapa-chave no design de um EJB é identificar quais mecanismos de EJB devem ser utilizados, se ainda não tiverem sido especificados quando o EJB foi identificado pela primeira vez. As decisões incluem:

  • Se as transações devem ou não ser utilizadas e, em caso positivo, se devem ser utilizadas as transações gerenciadas por bean ou gerenciadas por contêiner.
  • Se é necessário fornecer políticas de segurança e, em caso positivo, o que são elas, como se relacionam com cada método fornecido pelo bean e quais "funções" do usuário estão associadas a cada uma delas. O designer também deve decidir se será utilizada a autorização programática ou declarativa.
  • Para os beans de entidade, se será ou não utilizada a persistência gerenciada por contêiner ou gerenciada por bean. A persistência gerenciada por bean fornece maior flexibilidade, mas também mais trabalho na parte do desenvolvedor. A persistência gerenciada por contêiner automatiza boa parte do trabalho, mas é menos flexível.

Várias decisões desse mecanismo terão sido feitas pelo Arquiteto de Software em um nível de projeto e, nesse caso, o Designer segue as diretrizes do projeto.

Enquanto parte do comportamento do EJB é fornecido pelos métodos, o comportamento adicional é fornecido por meio de colaborações do EJB. É possível criar referências entre os EJBs e para os EJBs de entidade CMP 2.0, é possível criar CMRs (Relacionamentos Gerenciados por Contêiner) entre eles.

Orientação detalhada sobre como projetar o comportamento do EJB é fornecida por Diretrizes: Projetando EJBs.

Projetar Classes de Suporte Para o início da página

Esta etapa é aplicável a todos os EJBs.

Este é o local em que Classes de Design adicionais que suportam o design EJB são identificadas.  As classes de suporte comuns incluem as classes PK (Primary Key), os DAOs (Data Accessor Objects) e os VOs (Value Objects). Os DAOs são utilizados na implementação de EJBs de entidade BMP para ocultar os detalhes de manipulação do banco de dados. Isso facilita o transporte de aplicativos de um servidor de banco de dados para o outro. Os VOs são utilizados para acessar os dados de forma transparente e para transmitir valores de dados entre os componentes de maneiras eficientes.

É possível criar referências entre os EJBs e os CMRs entre os EJBs.

É possível definir classes de suporte adicionais por meio da aplicação de padrões. Para obter informações adicionais sobre os padrões de J2EE, consulte Padrões Núcleo de J2EE ([ALU01].

Consulte Atividade: Design da Classe para obter orientação geral sobre como projetar classes.



Rational Unified Process   2003.06.15