Principes et conseils : Sous-systèmes de conception des applications J2EE
Rubriques
Introduction
Ces principes et conseils complètent le chapitre Principes et conseils : sous-systèmes par l'aide spécifique au développement des applications J2EE.
Nous vous recommandons de lire le chapitre Principes et conseils : sous-système de conception avant de lire ce chapitre de conseils spécifiques aux applications J2EE.
Ces principes et conseils s'appliquent aux sous-systèmes de conception de granularité supérieure aux EJB. Reportez-vous au chapitre Principes et conseils : Enterprise
Java Beans pour connaître les principes et conseils relatifs aux EJB.
Notez également qu'un client d'applications est considéré comme un sous-système de conception spécialisé. Voir le chapitre Principes et conseils : client d'application.
Evolution des sous-systèmes de conception
Si un sous-système est d'abord identifié, il est probablement neutre en termes de technologie.
Cela signifie qu'il peut être spécifié par des interfaces, par une description textuelle et par certaines machines décrivant le comportement prévu des opérations. Néanmoins, des sous-systèmes neutres sur le plan technologique évoluent habituellement vers des représentations spécifiques à la technologie.
Ce qui suit est l'exemple d'un sous-système de conception neutre sur le plan technologique évoluant vers un système spécifique à la technologie.
Spécification du sous-système (Vue de la 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 réduites.
Considérez la conception préliminaire d'un sous-système client, décrit dans la figure 1.

Figure 1: sous-système client de conception préliminaire
IClientMgt est en outre défini comme contenant des opérations telles que "getCustomerDetails"
et "setCustomerDetails".
Dès que la conception devient plus détaillée, (activité :
Concevoir des sous-systèmes), ces interfaces réduites sont remplacées par des éléments spécifiques au langage et à la technologie. Vous pouvez décider de maintenir le modèle le plus réduit du sous-système ; par exemple, s'il est nécessaire d'implémenter la même conception dans plus d'un langage ou d'une technologie. Voir le chapitre Concepts:
Mappage de la conception au code pour plus de détails sur ces options.) Les réalisations de cas d'utilisation de conception correspondantes sont actualisées pour s'adapter aux changements de l'interface.
Dans cet exemple, la figure 2 est une vue de boîte noire ou de spécification du sous-système client. La conception suivante a indiqué que le sous-système client devait être un bean d'entité EJB. Le sous-système de conception préliminaire est converti en interfaces EJB de la façon suivante :
- ICustomerMgt =>
- CustomerHome ?EJBEntityHomeInterface?
- ICustomer =>
- Customer ?EJBRemoteInterface?

Figure 2: Vue boîte noire du sous-système de conception client
Les interfaces représentées par les sous-systèmes de conception peuvent contenir des interfaces Java traditionnelles, des interfaces EJB (comme les interfaces Java), des interfaces EJB (distantes et locales), ou même une classe mandatée ou d'accès au minimum, masquant intégralement l'existence d'un ou plusieurs bean(s) EJB. Notez que toutes ces catégories, y compris les interfaces Java, sont modélisées comme des classes UML et non comme des interfaces UML (voir le chapitre Principes et conseils :
Interfaces des applications J2EE). Par exemple, un bean de session est souvent utilisé comme une façade concernant l'accès à un ensemble de beans d'entité étroitement apparentés. Dans ce cas, seules les interfaces des beans de session seraient exportées du sous-système.
Les beans contrôlés par les messages consomment des messages de manière asynchrone, à partir d'une destination (ou d'un noeud final). Une destination pourrait donc servir d'"interface" vis-à-vis d'un sous-système de conception comportant des beans contrôlés par messages.
Notez qu'étant donné que les interfaces locales sont utilisées par des beans EJB étroitement liés à l'intérieur d'un même sous-système de conception et qu'elles apparaissent dans la réalisation des sous-systèmes plus fréquemment que dans les interfaces visibles exposées par un sous-système.
Pour plus d'informations sur les interfaces d'une application J2EE, voir le chapitre Principes et conseils :
Interfaces des applications J2EE. Pour plus d'informations sur la modélisation des beans EJB, voir le chapitre Principes et conseils : Enterprise JavaBeans.
Réalisation d'un sous-système (vue de boîte noire du sous-système)
Les sous-systèmes de conception ne devraient représenter que ce que les clients demandent. Donc, la classe qui implémente un EJB est privée au sous-système, et elle fait logiquement partie de la réalisation du sous-système.La réalisation du sous-système pourrait devenir :
- un ensemble de beans EJB et de classes de collaboration masqués par une classe mandatée ou d'accès au minimum.
- un seul bean EJB sans aucune classe de collaboration
$Sur la base du précédent exemple d'un sous-système client, la réalisation du sous-système inclut :
- EJBd'EntitéClient (composant) ?Beand'EntitéEJB?
- BeanClient ?ImplémentationEJB?
- Classes auxiliaires supplémentaires
La figure 3 illustre une vue de boîte blanche (c'est à dire, à l'intérieur du sous-système) du sous-système de conception. Notez que les classes EJB sont modélisées comme cela est décrit dans le chapitre Principes et conseils :
Enterprise JavaBeans. La vue interne du sous-système est désignée par le terme réalisation du sous-système. Cette vue contient des décisions qui sont invisibles pour les clients. Par exemple, dans cette réalisation du sous-système, une classe objet d'accès aux données (DAO) accède aux données rémanentes utilisant l'interface de programme d'application JDBC. La persistance gérée par conteneur peut avoir été utilisée (dans une autre conception) Voir le chapitre Principes et conseils :
Enterprise JavaBeans pour obtenir plus d'informations sur les classes DAO.

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