Guide d'utilisation de l'outil : Structuration du modèle d'implémentation à l'aide du Rational Software Architect
Objet
Cette section fournit des liens vers des informations complémentaires concernant ce guide d'utilisation de l'outil.
Les étapes de ce guide d'utilisation de l'outil correspondent à celles de l'activité. Les liens vers les rubriques de l'aide en ligne du RSA sont identifiés par le signe .
Présentation
Ce guide d'utilisation de l'outil suppose que vous avez défini la structure générale de votre modèle d'implémentation, de la manière indiquée dans Principes et conseils pour les structures de modèle dans Rational Studio Architect.
Les étapes de ce guide d'utilisation de l'outil permettent d'affiner la structure initiale.
Les étapes suivantes sont réalisées dans ce guide d'utilisation de l'outil :
Informations supplémentaires sur l'outil
L'approche recommandée dans RSA est le MDD - Model Driven Development (voir Développement basé sur les modèles et Architecture basée sur les modèles). Si l'équipe de développement adopte cette approche, le modèle d'implémentation dépend beaucoup de l'organisation du modèle de conception. Au fur et à mesure que vous identifiez de nouveaux sous-systèmes d'implémentation, vous devez les modéliser en tant que paquetages ou sous-systèmes dans le modèle de conception. En général, lorsque vous définissez des paquetages dans le modèle de conception, vous devez penser à la manière dont ils seront mappés aux projets Eclipse/RSA. Les grands sous-systèmes mappent en général vers leur propre projet, alors que les petits sous-systèmes mappent plutôt vers des dossiers source au sein de projets. Voir les sections des Principes et conseils pour les structures de modèle dans Rational Software Architect qui traitent des structures de projet et de l'organisation interne des modèles d'implémentation et de conception.
Dans RSA, la vue d'implémentation peut être définie à l'aide de paquetages <<perspectifs>>, qui contiennent des diagrammes illustrant les dépendances entre les sous-systèmes. Selon le type de transformation appliqué au modèle de conception, les dépendances que vous définissez entre les paquetages/sous-systèmes peuvent mapper vers des déclarations d'importation 3GL ou des déclarations de dépendance de projet dans les métadonnées des projets Eclipse/RSA.
Une fois que le code a été généré, des diagrammes UML plus détaillés peuvent être produits afin de montrer les constructions de niveau implémentation et leurs relations, en créant des diagrammes de classe directement dans les projets et en y plaçant des artefacts d'implémentation. Voir les rubriques de l'aide en ligne relatives à UML Visual Editor
for Java.
Si vous devez représenter les projets et paquetages RSA qui accueilleront le code et les fichiers associés avant de véritablement générer ce code, un modèle de présentation d'implémentation peut être utile. Pour plus d'informations, voir les rubriques consacrées au modèle d'implémentation dans le livre blanc Principes et conseils pour les structures de modèle dans Rational Software Architect.
Il n'existe aucune consigne spécifique à RSA pour cette étape.
Dans un environnement MDD, les dépendances du modèle d'implémentation reflètent très précisément celles définies explicitement ou implicitement dans le modèle de conception.
Les détails sont déterminés par les transformations de génération de code appliquées au modèle de conception.
Si un modèle de présentation d'implémentation est créé, vous pouvez l'utiliser pour indiquer les dépendances attendues entre les projets et les paquetages, ce qui peut s'avérer utile pour identifier les exigences liées au système (voir Principes et conseils pour les structures de modèle dans Rational Software Architect).
Dans un environnement MDD, selon les transformations appliquées au modèle de conception, différents types d'artefacts déployables peuvent être générés.
Par exemple, pour des éléments de type classe de <<contrôle>> et <<d'entité>>, des EJB de session et d'entité peuvent être générés pour une cible J2EE, avec le code pour les classes d'implémentation, mais aussi un descripteur de déploiement qui alloue les EJB à des fichiers JAR EJB et mappe ces fichiers JAR à des fichiers EAR.
Vous pouvez choisir de modéliser les artefacts déployables au niveau conceptuel, en utilisant un modèle de déploiement RSA. Dans ce cas, vous les modéliserez à l'aide d'artefacts et de noeuds UML. A ce jour, les transformations RSA ne prennent pas en charge la sémantique de ce type de diagramme pour générer les données de déploiement : par conséquent, vos diagrammes seront purement conceptuels et utilisables uniquement à des fins de documentation.
Si vous le souhaitez, vous pouvez également décrire les artefacts d'implémentation dans ces diagrammes en les faisant glisser sur le pattern et en les associant (à l'aide de dépendances) aux éléments conceptuels du diagramme.
Il n'existe aucune consigne spécifique à RSA pour cette étape.
S'il existe une vue d'implémentation séparée, vous devez en assurer la maintenance. Pour ce faire, le livre blanc Principes et conseils pour les structures de modèle dans Rational Software Architect recommande d'utiliser des paquetages <<perspectifs>>, qui contiennent des diagrammes illustrant les dépendances entre les sous-systèmes.
Il peut être utile de publier les modèles au format html. Il est également possible de copier des diagrammes de RSA vers Microsoft Word ou d'autres programmes.
Pour plus d'informations, voir
Publication de modèles pour revue en dehors de l'outil de modélisation, ainsi que les tutoriels suivants :
-
Génération de rapports de modèle standard
-
Génération de rapports de modèle personnalisés
-
Publication de modèles sur le Web
Aide-mémoire :
Structuration du modèle d'implémentation
|