Atividade:
|
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 é:
|
|
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: |
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.
Para obter informações adicionais sobre a identificação de EJBs, consulte Diretrizes: Identificar EJBs.
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.
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:
Para obter informações adicionais sobre a definição de operações EJB, consulte Diretrizes: Projetando EJBs.
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:
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.
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
|