Instructions: Structuration du modèle d'implémentation des applications J2EE
Ces instructions portent sur la structuration du modèle d'implémentation d'une application J2EE.
Relations
Description principale

Introduction

Il est supposé que vous avez pris connaissance des informations générales concernant l'utilisation de J2EE en tant que plateforme, qui figurent dans Concept : Présentation de Java 2 Platform Enterprise Edition (J2EE) et Concept : Mappage de la conception au code. Certains concepts décrits dans ces instructions portent sur UML 1.4, alors que vous utilisez peut-être un plugin basé sur UML 1.3. S'il vous est difficile de comprendre ce qui vient d'être dit, consultez les deux spécifications UML sur le sujet.

Structuration du modèle d'implémentation

L'artefact Tâche : Structurer le modèle d'implémentation décrit le processus de génération d'une structure de modèle d'implémentation fortement analogue à la structure du modèle de conception et qui par ailleurs reflète toutes les contraintes liées à l'environnement de développement et prend en charge le développement parallèle et l'intégration incrémentielle.

La structure du modèle d'implémentation d'une application J2EE dépend de l'environnement de développement et d'implémentation. En règle générale, le modèle d'implémentation J2EE compte toutefois quatre structures possibles :

  • Prise en charge du déploiement (modules J2EE et descripteurs de déploiement)
  • Structure des répertoires virtuelle (pages JSP, HTML)
  • Répertoire Java pour des éléments déployés sur un serveur Web (servlets, JavaBeans)
  • Répertoire Java pour des éléments déployés sur un serveur d'application EJB (EJB)

Modélisation des sous-systèmes d'implémentation

La vue Implémentation de Produit : Document d'architecture logicielle présente le modèle d'implémentation de manière détaillée. Cette présentation comprend l'identification des sous-systèmes d'implémentation. Dans une application J2EE, ces sous-systèmes d'implémentation peuvent ne pas mapper à un répertoire unique du système de fichiers ou un package unique d'un modèle, car le sous-système d'implémentation peut inclure des éléments non Java, pages JSP et HTML par exemple, dans un modèle et des éléments Java dans un autre. Pour résoudre ce problème, une stratégie peut consister à disposer d'une structure parallèle pouvant accueillir des packages dans chaque modèle. Les packages portant le même nom dans chaque modèle sont alors implicitement associés.

Un sous-système d'implémentation offre souvent l'implémentation d'un fichier d'implémentation déployable unique (un fichier JAR, WAR ou EAR). Dans ce cas, l'identification des fichiers déployables peut servir à identifier les sous-systèmes d'implémentation.

Chaque sous-système d'implémentation peut contenir une représentation d'éléments physiques, constitués de répertoires et de fichiers d'implémentation. Il peut également s'agir d'éléments logiques, constitués de classes, de composants, de packages etc., qui correspondent à des éléments de Produit : Modèle de conception, mais qui constituent un modèle précis du code source (modèle d'ingénierie aller-retour). Pour plus d'informations sur la relation entre le modèle de conception et le modèle d'implémentation, reportez-vous à Concept : Mappage de la conception au code .

Les modèles d'ingénierie aller-retour représentent le code source avec précision. Dans J2EE, chaque package d'un modèle Java représente un package Java, chaque classe représente une classe Java, etc. Les modèles d'ingénierie aller-retour doivent cependant parfois être complétés avec d'autres informations, parmi lesquelles celles mentionnées ci-dessous :

  • Diagrammes fournissant des informations qui ne sont générées automatiquement avec l'ingénierie aller-retour
  • Abstractions de niveau important

Le modèle de conception peut ne pas tenir compte des classes, des composants, des packages, etc. Un plus grand niveau d'abstraction ou d'autres diagrammes des éléments physiques (fichiers et répertoires) peu(ven)t toutefois se faire sentir. Ceci est décrit en détail dans les sections suivantes.

Modélisation des répertoires d'implémentation

L'ingénierie aller-retour traite uniquement un sous-ensemble de répertoires requis dans l'environnement de développement. D'autres répertoires s'avèrent souvent nécessaires pour organiser les artefacts de test, les unités de déploiement, la documentation, etc. Les répertoires pouvant être affichés par le système de fichiers, aucune opération de modélisation n'est généralement requise.

Modélisation des fichiers d'implémentation

Les fichiers d'implémentation ne sont généralement pas modélisés, à moins qu'un outil d'ingénierie aller-retour ne fournisse une certaine prise en charge ou que des relations non évidentes ne doivent être indiquées.

Il existe généralement un fichier .java pour chaque interface ou classe Java et un fichier .class compilé pour chaque fichier .java. Modéliser ces fichiers ne présente donc que peu d'intérêt.

Dans J2EE, un sous-système contient souvent un ou plusieurs fichiers d'archive (fichiers JAR, WAR ou EAR).

Considérer la modélisation comme une relation de composition entre le fichier archive et les fichiers résulte le plus souvent en une modélisation correcte des fichiers archive. Une fois compilés, les fichiers .class sont toutefois combinés entre eux afin de former un fichier JAR. Il peut s'avérer plus utile de démontrer que le fichier JAR et les classes et interfaces implémentées au final sont dépendants.

Si le sous-système d'implémentation génère uniquement un fichier JAR, toute opération de modélisation sera peut-être tout à fait inutile, en particulier si les fichiers déployables du sous-système d'implémentation peuvent être considérés comme appartenant au fichier JAR.

Chevauchement des fichiers archive

Même si ce n'est généralement pas conseillé, il est possible de définir deux fichiers archive qui contiennent certains éléments identiques. Deux fichiers EAR peuvent par exemple contenir quelques fichiers JAR EJB identiques ou deux fichiers JAR EJB peuvent par exemple contenir les mêmes EJB, mais comporter des descripteurs de déploiement différents.

Pour conserver la correspondance entre les sous-systèmes d'implémentation et les fichiers archive déployables, il est préférable que les fichiers archive ne présentent aucun chevauchement. Lorsqu'un chevauchement s'avère nécessaire, il peut toutefois être utile de le modéliser et d'en apporter la justification.