Principes et conseils : Structurer le modèle d'implémentation des applications J2EE
Rubriques
Introduction
On suppose que vous avez une connaissance générale de la plate-forme technologique J2EE, abordée dans les chapitres Concepts:
généralités sur la plate-forme J2EE, Enterprise JavaBeans et Concepts:
Mappage de la conception au code. Certains concepts de ce chapitre font partie du langage UML 1.4, alors que vous pouvez peut-être les utiliser dans le contexte d'un plug-in basé sur le langage UML 1.3.
Si vous avez des difficultés à comprendre un sujet, référez-vous au contenu des deux spécifications UML sur ce sujet.
Structurer le modèle d'implémentation
Le chapitre Activité : structurer le modèle d'implémentation décrit comment produire une structure de modèle d'implémentation véritablement alignée sur la structure du modèle de conception, qui reflète aussi toutes les contraintes liées à l'environnement de développement et supporte un développement parallèle et une intégration incrémentale.
La structure du modèle d 'implémentation d'une application J2EE dépend de l'environnement de développement et d'implémentation ; cependant, il existe en général quatre structures potentielles à l'intérieur d'un modèle d'implémentation J2EE :
- Support de déploiement (modules J2EE et descripteurs de déploiement)
- Structure virtuelle du répertoire (Pages JSP et HTML)
- Répertoire Java des éléments déployés sur un serveur Web (servlet, Java beans)
- Répertoire Java des éléments déployés sur un serveur d'applications (EJB)
Modéliser les sous-systèmes d'implémentation
La vue d'implémentation du chapitre artefact :
Document d'architecture du logiciel donne des renseignements généraux détaillés sur le modèle d'implémentation. Cela inclut l'identification des sous-systèmes d'implémentation. Dans une application J2EE, il se peut qu'aucun mappage des sous-systèmes d'implémentation ne soit réalisé vers un seul répertoire du système de fichiers ou vers un seul package d'un modèle, du fait que le sous-système d'implémentation peut inclure les éléments non Java d'un modèle (comme les pages JSP ou HTML) et les éléments Java d'un autre modèle. Une stratégie pour traiter cela est d'avoir une structure de regroupement parallèle dans chaque modèle. Dans chaque modèle, les packages du même nom sont associés de manière implicite.
Il est courant pour un sous-système d'implémentation d'assurer l'implémentation d'un seul fichier d'implémentation déployable (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.
Une représentation des éléments physiques, comprenant les répertoires et fichiers d'implémentation peut se trouver dans chaque sous-système d'implémentation. Ils peuvent également intégrer des éléments logiques, comme les classes,
les composants, les packages, et ainsi de suite, qui correspondent aux éléments de l'Artefact : Modèle de conception, mais qui constituent un modèle précis du code source (un modèle d'ingénierie aller-retour). Voir le chapitre Concepts: Mappage de la conception au code pour plus d'informations sur la relation existant entre le modèle de conception et le modèle d'implémentation.
Les modèles d"ingénierie aller-retour fournissent une représentation du code source.
Dans l'environnement J2EE, chaque package du modèle Java représente un package Java, chaque classe représente une classe Java et ainsi de suite. Néanmoins, il est souvent nécessaire de compléter les modèles d'ingénierie aller-retour par des informations supplémentaires comme :
- les diagrammes décrivant les informations qui ne sont pas directement générées par le processus d'ingénierie aller-retour
- les abstractions de haut niveau du modèle
Le modèle de conception fournit un résumé des classes, des composants, des packages et ainsi de suite. Il peut cependant être nécessaire d'intégrer des abstractions de haut niveau et des diagrammes supplémentaires correspondant aux éléments physiques (fichiers et répertoires). Ceux-ci sont décrits dans les chapitres suivants.
Modéliser les répertoires d'implémentation
L'ingénierie aller-retour ne manipule qu'un sous-ensemble des répertoires requis dans l'environnement de développement. Les répertoires supplémentaires sont souvent utiles dans l'organisation des artefacts de tests, des unités de déploiement, de la documentation, etc. En général, aucune modélisation n'est nécessaire, étant donné que les répertoires peuvent être visualisés comme une partie du système de fichiers.
Modéliser les fichiers d'implémentation
Les fichiers d'implémentation ne sont généralement pas modélisés, à moins que l'outil d'ingénierie aller-retour n'offre un support et que certaines relations pas si évidentes ne doivent être décrites.
Il existe généralement une fichier .java file pour chaque interface ou classe Java et un fichier compilé .class pour chaque fichier .java. Ces fichiers n'ont donc pas beaucoup d'intérêt.
Dans l'environnement J2EE, un sous-système contient habituellement un ou plusieurs fichiers d'archives (fichiers JAR, WAR,
ou EAR).
La plupart des fichiers d'archives sont correctement modélisés, sous la forme d'une relation de composition allant du fichier d'archives aux fichiers qu'il contient. Cependant, lorsque les fichiers compilés .class
sont regroupés pour former un fichier JAR, il peut s'avérer plus utile de décrire une dépendance liant le fichier JAR aux classes et interfaces qu'il implémente en dernier lieu.
Si le sous-système d'implémentation ne produit qu'un fichier JAR, alors la modélisation ne sera probablement pas nécessaire du tout ; particulièrement, si l'on suppose que les fichiers déployables du sous-système d'implémentation font partie du fichier JAR.
Chevauchement des fichiers d'archives
Il est possible, mais néanmoins peu recommandé de définir deux fichiers d'archives contenant certains éléments communs. Deux fichiers EAR peuvent par exemple contenir certains, mais pas tous les éléments liés aux fichiers JAR des beans EJB ; ou encore deux fichiers JAR des beans EJB peuvent comprendre les mêmes beans EJB mais comporter des descripteurs de déploiement différents.
La meilleure solution serait que les fichiers d'archives ne se chevauchent pas, afin de conserver une bonne correspondance entre les sous-systèmes d'implémentation et les fichiers d'archives déployables. Cependant, si le chevauchement s'impose, il serait utile de prévoir la modélisation de ces chevauchements.
|