Instructions: Conception de sous-systèmes des applications J2EE
Ces instructions portent sur la conception des sous-systèmes d'une application J2EE.
Relations
Description principale

Introduction

Ces instructions sont un complément à Instructions : Conception d'un sous-système avec des conseils spécifiques au développement d'application J2EE. Nous vous recommandons de lire Instructions : Conception d'un sous-système, avant de lire les instructions relatives à J2EE. Ces instructions s'appliquent aux sous-systèmes de conception de granularité plus grossière que les EJB individuels. Pour les instructions relatives aux EJB, reportez-vous à Instructions : Enterprise JavaBean (EJB).

Remarque : un client d'application est considéré comme un sous-système de conception spécialisé. Voir Instructions : Client d'application J2EE.

Développement des sous-systèmes de conception

Il se peut qu'un sous-système soit initialement neutre au niveau technologique lorsqu'on l'identifie pour la première fois, c'est-à-dire qu'il peut être décrit par des interfaces, une description textuelle et quelques machines d'état qui décrivent le comportement attendu des opérations. Cependant, de tels sous-systèmes sont en général développés en représentations spécifiques en termes de technologie.

L'exemple ci-dessous montre comment un sous-système de conception neutre au niveau technologique est développé en un sous-système spécifique.

Spécification de sous-système (vue "boîte noire" du sous-système)

La spécification d'un sous-système peut initialement être modélisée comme ayant des interfaces UML abstraites.

Considérez la conception préliminaire d'un sous-système client, comme le montre la figure 1. 

Diagramme décrit dans le texte d'accompagnement.

Figure 1 : Sous-système de conception client préliminaire

ICustomerMgt est défini plus en détail pour comprendre des opérations telles que "getCustomerDetails" et "setCustomerDetails".

Au fur et à mesure que la conception devient de plus en plus détaillée (Tâche : subsystem_design_real-time_design), les interfaces abstraites sont remplacées par des éléments de langage et des éléments de technologie. (Vous pouvez choisir de maintenir le modèle le plus abstrait du sous-système, par exemple s'il faut implémenter la même conception dans plusieurs langages ou technologies. Voir Concept : Mappage de la conception au code pour plus de détails sur ce sujet.) La conception correspondante Produit : Réalisation de cas d'utilisation est mise à jour pour correspondre aux changements d'interface.

Dans cet exemple, la figure 2 est une vue "boîte noire" ou spécification du sous-système client. La conception ultérieure indique que le sous-système client doit être une EJB entity. Le sous-système de conception préliminaire est transformé en interfaces d'EJB comme suit :

  • ICustomerMgt =>
    • CustomerHome ?EJBEntityHomeInterface?
  • ICustomer =>
    • Customer ?EJBRemoteInterface?

Diagramme décrit dans le texte d'accompagnement.

Figure 2 : Vue "boîte noire" du sous-système de conception client

Les interfaces exposées par les sous-systèmes de conception peuvent comprendre les interfaces Java classiques, des interfaces d'EJB (telles que des interfaces Java), des interfaces d'EJB (distantes et home), voire une ou plusieurs classes déléguées ou d'accès qui masquent complètement l'existence d'un ou plusieurs EJB. Ces interfaces, y compris les interfaces Java, sont modélisées en tant que classes UML et non en tant qu'interfaces UML (voir Instructions : Interfaces des applications J2EE). Par exemple, un bean session sert souvent de façade pour accéder à un ensemble de beans entity étroitement liés. Dans ce cas, seules les interfaces des beans session sont exportées du sous-système.

Les beans gérés par message consomment les messages de manière asynchrone à partir d'une destination (ou noeud final). Une destination peut donc servir comme "interface" d'un sous-système de conception qui contient des beans gérés par message.

Remarque : les interfaces locales étant utilisées par d'autres EJB étroitement liés dans le même sous-système de conception, elles apparaissent plus souvent dans la réalisation des sous-systèmes que dans les interfaces visibles exposées par un sous-système.

Pour plus d'informations sur les interfaces pour les applications J2EE, reportez-vous à Instructions : Interfaces pour les applications J2EE. Pour plus d'informations sur la modélisation d'EJB, reportez-vous à Instructions : Enterprise JavaBean (EJB).

Réalisation de sous-système (vue "boîte blanche" du sous-système)

Les sous-systèmes de conception doivent uniquement exposer ce qui est requis par les clients. Par conséquent, la classe qui implémente un EJB est un élément spécifique au sous-système et fait logiquement partie de sa réalisation. La réalisation du sous-système peut prendre la forme suivante :

  • un ensemble d'EJB et de classes collaboratives, masqués par une ou plusieurs classes déléguées ou d'accès
  • un EJB unique sans aucune autre classe collaborative

Si l'on revient à l'exemple précédent du sous-système client, la réalisation de ce dernier comprend :

  • CustomerEntityEJB (composant) ?EJBEntityBean?
  • CustomerBean ?EJBImplementation?
  • classes auxiliaires supplémentaires

La figure 3 montre une vue "boîte blanche" (c'est-à-dire au sein du sous-système) du sous-système de conception. Les classes d'EJB sont modélisées comme décrit dans Instructions : Enterprise JavaBean (EJB). On appelle cette vue interne la réalisation du sous-système. On peut y voir les décisions qui ne sont pas visibles pour les clients. Par exemple, dans cette réalisation de sous-système, une classe DAO (Data Access Object) accède à des données persistantes à l'aide de l'API de la connectivité JDBC. (Pour une autre conception, une persistance gérée par conteneur aurait pu être utilisée) Voir Instructions : Enterprise JavaBean (EJB) pour plus d'informations sur les classes DAO.

Diagramme décrit dans le texte d'accompagnement.

Figure 3 : Vue "boîte blanche" du sous-système de conception client