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.
|