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.
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?
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.
Figure 3 : Vue "boîte blanche" du sous-système de conception client
|