Objet

EJB Design a pour objet d'identifier et de spécifier les Classes de conception qui constituent les Enterprise JavaBeans (EJB).  

De même que pour l'Activité : Conception d'une classe, le but est le suivant :

  • Vérifier que les informations fournies sont suffisantes pour implémenter sans ambiguïté les EJB.
  • Manipuler les exigences non fonctionnelles liées à l'EJB.
  • Incorporer des mécanismes de conception utilisés par l'EJB, notamment ceux spécifiques au type d'EJB conçu.
Rôle :  Concepteur 
Fréquence : A lieu de nombreuses reprises dans toutes les itérations suivant la phase de création. Peut également apparaître dès la création en cas d'activités de prototypage.
Etapes
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   
Plus d'informations :   

Détails de l'enchaînement d'activités :   

Identification des EJB Haut de la page

Distinguez les EJB des classes d'analyse et/ou des éléments initiaux du modèle de conception. Les EJB peuvent également être identifiés à l'intérieur d'un modèle de conception. L'incorporation d'un pattern permet d'exécuter efficacement de nombreuses étapes de cette activité (ajout de nouvelles classes, opérations, attributs et relations), mais selon les règles définies par le pattern. Des exemples de patterns J2EE sont donnés dans Patterns J2EE de base ([ALU01].

Un certain nombre de décisions essentielles doivent être prises.

  • Choix du mode de mappage de la "logique métier" aux EJB et aux classes non EJB, choix du nombre et du type de classes nécessaires. Par exemple, les classes représentant des objets avec une information "d'état" qui doit persister doivent être mappées à des EJB d'entité. Celles qui exécutent des services et ne comportent pas de données persistantes doivent être mappées à des EJB de session ou orientés message.
  • Pour les beans de session, choix entre un bean avec ou sans état (ce choix joue un rôle décisif dans l'identification de la responsabilité entre le bean de session et les autres classes identifiées). Les beans de session sans état sont plus efficaces, parce qu'une instance peut être partagée par plusieurs requêtes non contiguës, au lieu d'être "liée" à une session d'activité particulière. De plus, si l'EJB doit être utilisé comme point final d'un Web service, il doit nécessairement être sans état.
  • Choix des patterns et mécanismes de conception auxquels le bean doit faire appel ou participer. L'utilisation de patterns et mécanismes spécifiques affecte le nombre et le type des EJB identifiés.
    Remarque :
    Il revient généralement à l'architecte logiciel de décider des patterns et mécanismes à utiliser dans le projet, le Concepteur se contentant de suivre les directives fournies.

Pour plus d'informations sur l'identification des EJB, voir Principes et conseils : Identification des EJB.

Définition des attributs Haut de la page

Identifiez tous les attributs de l'EJB.

Pour chaque bean d'entité, il s'agit notamment d'identifier ses attributs persistants et sa clé primaire.

Pour plus d'informations sur la définition des attributs des EJB, voir Principes et conseils: Conception des beans d'entité.

Définition des opérations Haut de la page

Cette étape s'applique aux beans de session et d'entité. Elle ne concerne pas les beans orientés message.

La conception des opérations est couverte par l'Activité: Conception des classes, notamment l'étape Définition des opérations.

Les EJB demandent certaines décisions capitales, notamment :

  • Si une opération particulière doit ou non être accessible aux clients locaux ou distants. Généralement, un EJB dispose d'interfaces de composants soit locales, soit distantes. Si vous utilisez une version de J2EE supérieure à 1.3, une pratique standard consiste à faire traiter tous les accès des clients distants par des EJB de session, qui manient les EJB d'entité dans la même machine virtuelle par des interfaces de composants locaux.
  • Comment regrouper les attributs dans des objets représentant des valeurs pour les opérations obtenir/ définir. Si vous fournissez des interfaces distantes aux EJB d'entité, il vaut mieux définir une classe "objet valeur" servant à passer directement un instantané des données du bean dans les deux directions. La charge du réseau est ainsi réduite car elle élimine les appels obtenir/ définir répétés pour chaque champ de bean. Pour plus d'informations, voir Patterns J2EE de base ([ALU01].

Pour plus d'informations sur la définition des opérations EJB, voir Principes et conseils : Conception des EJB.

Définition du comportementHaut de la page

La conception du comportement d'une classe est traitée dans Activité : Conception d'une classe.

Une des principales étapes de la conception d'un EJB consiste à identifier les mécanismes de l'EJB à utiliser, s'ils ne l'ont pas été lors de son identification initiale. Il s'agit alors de décider :

  • Si des transactions doivent ou non être utilisées et, si oui, si elles doivent être gérées par le bean ou par le conteneur.
  • Si des règles d'administration doivent être fournies pour la sécurité et, si oui, en quoi elles doivent consister, comment elles doivent être liées à chaque méthode fournie par le bean, et quels "rôles" d'utilisateurs sont associés à chacune d'elles. Le concepteur doit également choisir entre autorisation programmatique et déclarative.
  • Pour les beans d'entité, si la persistance doit être gérée par le conteneur ou par le bean. Si elle apporte davantage de flexibilité, la persistance gérée par le bean demande néanmoins davantage de travail au développeur. A l'inverse, la persistance gérée par le conteneur est moins flexible tout en automatisant une grande partie du travail.

Beaucoup de ces décisions sur les mécanismes relèvent de l'architecte logiciel à l'échelon du projet, le Concepteur se contentant de suivre les principes et conseils définis pour le projet.

Alors qu'une partie du comportement des EJB est fournie par les méthodes, l'autre partie est fournie par les collaborations entre EJB. Vous pouvez créer des références entre EJB et, pour les EJB entité CMP 2.0, des relations gérées par conteneur (CMR) entre eux.

Des instructions détaillées sur la conception du comportement des EJB sont fournies dans Principes et conseils : Conception des EJB.

Conception des classes de prise en chargeHaut de la page

Cette étape s'applique à tous les EJB.

Elle comporte l'identification des classes de conception supplémentaires sur lesquelles repose la conception des EJB.  Les classes les plus courantes de cette catégorie sont les classes de clé primaire (classes PK), les objets d'accès aux données (DAO) et les objets "valeurs" (VO). Les DAO sont utilisés dans l'implémentation des EJB entité à persistance gérée par le bean pour masquer les détails de manipulation de la base de données. Cela facilite le portage d'une application entre serveurs de bases de données. Les VO sont utilisés pour accéder de façon transparente aux données et passer efficacement les valeurs des données entre composants.

Vous pouvez créer des références entre EJB, ainsi que des relations gérées par le conteneur (CMR).

Des classes de prise en charge supplémentaires peuvent être définies par l'application de patterns. Pour plus d'informations sur les patterns J2EE, voir patterns J2EE de base ([ALU01].

Voir Activité : Conception d'une classe pour des instructions d'ordre général sur la conception des classes.



RUP (Rational Unified Process)   2003.06.15