Présentation
Ce guide d'utilisation de l'outil implique que vous ayez défini la structure générale de votre modèle d'implémentation,
comme indiqué dans les Instructions relatives aux structures de modèles pour RSx. Les étapes
ci-dessous permettent d'améliorer la structure initiale.
Etapes constituant ce guide d'utilisation de l'outil :
L'approche recommandée est le MDD (Model Driven Development - Développement guidé par modèle ; voir Développement guidé par modèle et architecture guidée par modèle). Si l'équipe de
développement adopte cette approche, le modèle d'implémentation dépendra étroitement de l'organisation du modèle de
conception. Au fur et à mesure de l'identification de nouveaux sous-systèmes d'implémentation, il convient de les
modéliser en tant que packages ou sous-systèmes dans le modèle de conception. En général, lorsque vous identifiez des
packages dans le modèle de conception, vous devez penser à la manière dont ils seront mappés aux
projets spécifiques à l'outil. En principe, les grands sous-systèmes mappent vers leur propre projet, alors que
les petits sous-systèmes mappent plutôt vers des dossiers source au sein de projets. Reportez-vous aux sections des Instructions relatives aux structures de modèles pour RSx consacrées aux structures
de projet et à l'organisation interne des modèles d'implémentation et de conception.
La vue d'implémentation peut être définie à l'aide de packages de
<<perspective>>, 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 au sein des
packages/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.
Une fois le code généré, il est possible de produire des diagrammes UML plus détaillés, qui illustrent les
constructions de niveau d'implémentation et leurs relations : il suffit pour cela de créer des diagrammes de classes
directement dans les projets et de les remplir en y faisant glisser des artefacts d'implémentation. Consultez les
rubriques de l'aide en ligne consacrées à l'éditeur visuel UML pour Java.
Si vous voulez que les références à des classes, des interfaces, des packages spécifiques etc. d'une bibliothèque de
codes soient représentées dans votre modèle d'implémentation, vous pouvez utiliser les fonctions de visualisation de
code du produit pour créer ces représentations. Les fichiers jar suivants contiennent des fichiers qui peuvent vous
intéresser pour la conception et le développement d'applications J2EE :
-
j2ee.jar, jsf-api.jar, soap.jar, soap-sec.jar (ils figurent tous dans le répertoire lib)
-
core.jar, xml.jar, security.jar (dans le répertoire java\jre\lib)
Si vous devez référencer un élément de l'une de ces bibliothèques dans votre modèle, suivez les étapes ci-dessous :
-
Créez un nouveau projet Java et ajoutez des références bibliothèques
-
Ouvrez le diagramme auquel vous voulez ajouter l'élément visualisé
-
Basculez vers la perspective Java
-
Recherchez l'élément (package, classe, interface etc.) que vous voulez ajouter à votre modèle
-
Cliquez avec le bouton droit de la souris sur l'élément puis sélectionnez Visualize > Add to Current Diagram
(Visualiser > Ajouter au diagramme en cours)
S'il est nécessaire de représenter les projets et packages dans lesquels se trouveront réellement, d'après vous, le
code et les fichiers associés, avant toute génération de code, un modèle de présentation d'implémentation peut être
utile. Pour plus d'informations, voir les rubriques du livre blanc Instructions relatives aux structures de modèles pour RSx consacrées au modèle
d'implémentation.
La séquence d'étapes suivante va vous aider à ajuster les sous-systèmes d'implémentation :
-
Identifiez les sous-systèmes posant problème, comme une dépendance cyclique par exemple, à l'aide de :
-
-
Diagrammes de rubrique et de navigateur
-
Reconnaissance d'architecture
-
Revue de code / Analyse de code structurel
-
Créez un nouveau sous-système
-
Faites passer les éléments identifiés dans le nouveau sous-système
-
Représentez les nouvelles dépendances
Dans un environnement MDD, les dépendances du modèle d'implémentation refléteront très étroitement les dépendances
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.
Outre le modèle d'entrée, d'autres artefacts sont nécessaires pour effectuer une transformation. Un processus de
transformation doit avoir une définition de la transformation et des règles relatives à cette transformation.
Les règles fournissent une description que le processus de transformation utilise pour convertir un élément du modèle
source en zéro, un ou plusieurs éléments dans le modèle cible. Elles mappent en particulier les éléments d'un certain
niveau d'abstraction aux éléments analogues plus détaillés situés à un niveau d'abstraction moins élevé.
Si vous utilisez un manuel sur les transformations, assurez-vous de fournir suffisamment de conseils à vos développeurs
lorsqu'ils transforment le modèle de conception en code. En d'autres termes, vous devez fournir une définition des
transformations comprenant un ensemble de règles de transformation. Ces conseils supplémentaires peuvent prendre la
forme suivante :
-
Eléments de profils documentés
-
Notes dans le modèle
-
Informations supplémentaires dans le document d'architecture logicielle
-
Instructions relatives au développement
S'il existe un modèle de présentation d'implémentation, vous pouvez l'utiliser pour indiquer les dépendances prévues au
sein des projets et packages, ce qui peut permettre d'identifier les exigences relatives à la construction du système
(voir Instructions relatives aux structures de modèles pour RSx).
Dans un environnement MDD, suivant le type de transformation appliqué au modèle de conception, différents types
d'artefacts déployables peuvent être générés. Par exemple, à partir d'éléments tels que les classes
<<control>> et <<entity>>, des EJB session et entity peuvent être générés pour une cible J2EE,
notamment : le code pour les classes d'implémentation, les interfaces, le contenu du descripteur de déploiement, qui
procède à l'attribution des EJB (Enterprise JavaBeans) et des fichiers d'archive Java (JAR) EJB et mappe ces fichiers
d'archive à des fichiers d'archive d'entreprise (EAR).
Vous pouvez décider de modéliser des artefacts déployables au niveau conceptuel à l'aide d'un modèle de déploiement.
Dans ce cas, effectuez la modélisation en utilisant des noeuds et artefacts UML. A ce jour, les transformations
groupées en packages avec l'outil ne prennent pas en charge la sémantique de ce type de diagramme pour générer des
données de déploiement ; vos diagrammes seront donc purement conceptuels et serviront uniquement de documentation.
Vous pouvez éventuellement décrire des artefacts d'implémentation réels dans ce type de diagrammes en les faisant
glisser dans le canevas, puis en les connectant (au moyen de dépendances) aux éléments conceptuels du diagramme.
La méthode que vous choisirez d'utiliser pour créer vos actifs de test est un élément clé car elle aura une incidence
sur la structure de ces actifs.
Vous pouvez choisir les fonctions de test de composants automatisé pour créer vos tests. Dans ce cas, un ou plusieurs
projets de jeu d'essai sont configurés pour vous dans le processus de création. L'un des avantages clés de cette
fonction est de pouvoir utiliser une génération de code initiale et les modules de remplacement du code pour exécuter
la création du jeu d'essai.
Le référentiel du projet doit être organisé en un ensemble de répertoires ou en répertoires hiérarchisés. Il est
recommandé de conserver les actifs de test dans des répertoires de test séparés qui différencient les types de test :
test d'unité, test d'intégration, test de système.
S'il existe une vue d'implémentation distincte, vous devez en assurer la maintenance. Pour ce faire, le livre blanc Instructions relatives aux structures de modèles pour RSx recommande d'utiliser des
packages de <<perspective>>, qui contiennent des diagrammes illustrant les dépendances entre les
sous-systèmes.
Vous voulez être sûr que les dépendances de votre sous-système (et d'autres dépendances) suivent bien les meilleures
pratiques pendant que le système évolue. Vous devez pour cela utiliser en général la reconnaissance d'architecture et
la revue de code et particulièrement l'analyse de structure pour vérifier que les modèles suivent ces pratiques.
Comme il est mentionné plus haut, vous voulez peut-être prendre le temps d'introduire des règles personnalisées pour
appliquer les dépendances que vous avez identifiées. Lors de la partie manuelle de la revue, vous pouvez relever les
règles qui n'ont pas encore été développées et les ajouter dans l'ensemble de règles pour l'itération suivante.
Il peut être utile de publier les modèles au format html. Notez également que les diagrammes peuvent être copiés dans
Microsoft Word et d'autres programmes.
Pour plus d'informations, voir Publishing Models (Publication de modèles) et le tutoriel Publishing a Model to Web (Publication d'un modèle dans le
Web).
|