Définition de la structure du modèle d'implémentation
Objet
|
Etablir la structure du modèle d'implémentation.
|
En passant de "l'espace conception" à "l'espace implémentation", commencez par recopier la structure du modèle de
conception dans le modèle d'implémentation.
Les packages de conception auront des sous-systèmes d'implémentation correspondants, qui contiendront un ou des
répertoires et fichiers (Artefact : élément d'implémentation) nécessaires pour implémenter les éléments de conception
correspondants. Le mappage du modèle de conception au modèle d'implémentation peut changer car chaque sous-système
d'implémentation est alloué à une couche spécifique de l'architecture.
Créez un diagramme pour représenter la structure du modèle d'implémentation (voir aussi Instructions : diagramme
d'implémentation).
|
Ajustement des sous-systèmes d'implémentation
Objet
|
Adapter la structure du modèle pour refléter l'organisation de l'équipe ou les contraintes du langage
d'implémentation.
|
Décidez si l'organisation des sous-systèmes doit être changée en traitant de certaines questions tactiques liées à
l'environnement de l'implémentation. Vous trouverez ci-dessous certaines de ces questions tactiques. Il convient de
remarquer que si vous décidez de changer l'organisation des sous-systèmes d'implémentation, vous devez aussi décider
soit de revenir en arrière et de mettre à jour le modèle de conception, soit d'accepter que le modèle de conception
diffère du modèle d'implémentation.
-
Organisation de l'équipe de développement. La structure du sous-système doit permettre à plusieurs
implémenteurs ou à plusieurs équipes d'implémenteurs de travailler parallèlement sans entraîner trop de
chevauchements ou d'agitation. Il est préférable que chaque sous-système d'implémentation soit sous la
responsabilité d'une seule équipe. Cela signifie qu'il peut être utile, par exemple, de diviser un sous-système en
deux (s'il est grand) et de confier chaque partie à deux implémenteurs ou deux équipes
d'implémenteurs, particulièrement si les deux implémenteurs (ou équipes) ont des cycles de construction ou
d'édition différents.
-
Déclarations de types. Lors de l'implémentation, vous pouvez réaliser qu'un sous-système doit importer des
produits depuis un autre sous-système car un type est déclaré dans ce sous-système. En général, cela se produit
lorsque vous utilisez des langages de programmation comme C++, Java et Ada. Dans ce cas, et de manière générale,
c'est une bonne idée de placer les déclarations de type dans un sous-système séparé.
Exemple
Vous extrayez des déclarations de type du sous-système D, pour les placer dans de nouveaux types de
sous-système, afin de rendre le sous-système A indépendant vis à vis des changements des produits (visibles) du
sous-système D.
Des déclarations de type sont extraites du sous-système D
.
-
Code et systèmes de composants existants. Vous pouvez avoir besoin d'intégrer un code existant, une
bibliothèque de composants réutilisables ou des produits prêts à utiliser. Si ces éléments n'ont pas été modélisés
lors de la conception, des sous-systèmes d'implémentation doivent alors être ajoutés.
-
Ajuster les dépendances. Admettons qu'un sous-système A et un sous-système B aient des dépendances
d'importation l'un par rapport à l'autre. Vous pouvez souhaiter que B soit moins dépendant des changements du
sous-système A. Extrayez les produits de A que B importe et placez-les dans un nouveau sous-système
d'implémentation A1, dans une couche plus basse.
Les produits sont extraits du sous-système A et placés dans un nouveau sous-système A1.
Maintenant que les sous-systèmes d'implémentation ne mappent plus des packages ou des sous-systèmes dans le modèle de
conception, vous pouvez soit effectuer le changement correspondant dans le modèle de conception (si vous avez décidé de
conserver un modèle de conception proche du modèle d'implémentation), soit garder une trace des mappages entre les
modèles d'implémentation et de conception (grâce à la traçabilité et aux dépendances de réalisation). La décision
d'effectuer ce mappage ou non et la façon dont il est effectué est une décision de processus devant être enregistrée
dans le Produit : Instructions relatives au projet.
|
Définition des importations pour chaque sous-système d'implémentation
Objet
|
Définir des dépendances entre des sous-systèmes
|
Pour chaque sous-système, il faut définir de quels autres sous-systèmes il fait des importations. Cela peut être fait
pour un ensemble de sous-systèmes, permettant à tous les sous-systèmes d'une couche d'importer tous les sous-systèmes
d'une couche inférieure. En général, les dépendances dans le modèle d'implémentation refléteront celles du modèle de
conception, excepté lorsque la structure du modèle d'implémentation a été ajustée (voir aussi Ajustement des sous-systèmes d'implémentation).
Présentez la structure en couches des sous-systèmes dans des diagrammes de composants.
|
Décidez comment traiter les programmes exécutables (et autres objets dérivés).
Les exécutables (et autres objets dérivés) résultent de l'application d'un processus de construction à un ou plusieurs
sous-système d'implémentation (ou à une de leur partie) et appartiennent donc logiquement au sous-système
d'implémentation. Toutefois, l'architecte logiciel, en collaboration avec le responsable de la gestion de la
configuration, devra choisir la structure des éléments de configuration à appliquer au modèle d'implémentation.
Pour simplifier le choix et la référence, plus particulièrement pour le déploiement, la recommandation par défaut est
de définir des éléments de configuration séparés pour contenir les ensembles de programmes exécutables déployables (les
informations concernant quels programmes sont exécutables sur quels noeuds sont enregistrées dans le modèle de déploiement). De cette façon, dans les cas les plus
simples, pour chaque sous-système d'implémentation, il y a un élément de configuration pour les programmes exécutables
déployables et un élément de configuration pour contenir la source, etc., utilisés pour les produire. Le
sous-système d'implémentation peut être considéré comme étant représenté par un élément de configuration composite
contenant ces éléments de configuration (et peut-être d'autres, comme des actifs de tests).
Du point de vue de la modélisation, un ensemble de programmes exécutables produit par un processus de construction peut
être représenté comme un Produit : Construction (qui est un package)contenu par le
sous-système d'implémentation associé (qui est lui-même un package).
|
Décidez comment traiter les actifs de tests
Objet
|
Ajouter des produits de test au modèle d'implémentation
|
En général, les produits de test et les sous-systèmes de test sont traités de manière similaire dans le Rational
Unified Process et dans les autres logiciels développés. Toutefois, les produits et les sous-systèmes de test ne font
généralement pas partie du système déployé et ne sont généralement pas livrables au client. La recommandation par
défaut est donc de faire correspondre les actifs de tests à la cible de test (par exemple les éléments d'implémentation
pour le test d'unité, le sous-système d'implémentation pour le test d'intégration, le système pour le test du système)
mais de conserver les actifs de tests dans des répertoires de test séparés (par exemple) si le référentiel du projet
est organisé comme une ensemble ou comme une hiérarchie de répertoires. Les sous-systèmes de test distincts (conçus
pour tester l'unité de niveau de test) doivent être traités de la même façon que les autres sous-systèmes
d'implémentation, comme des éléments de configurations distincts.
Pour la modélisation, un ensemble de produits de test peut être représenté comme un Produit : Sous-système d'implémentation (un package). Pour un test
d'unité, ce type de sous-système de test est normalement contenu par le sous-système d'implémentation associé (testé).
L'architecte logiciel, avec l'aide du responsable de la gestion de la configuration, doit décider si, à ce niveau, les
produits de test doivent être configurés en même temps que les éléments d'implémentation qu'ils testent ou comme des
éléments de configuration séparés. Pour les tests d'intégration et de système, les sous-systèmes de test peuvent être
des pairs des sous-systèmes d'implémentation testés.
|
Mise à jour de la vue d'implémentation
Objet
|
Mettre à jour la vue d'implémentation de l'architecture logicielle
|
La vue d'implémentation est décrite dans le document d'architecture logicielle. Cette section contient les
diagrammes de composants qui indiquent les couches et l'allocation des sous-système d'implémentation aux couches, ainsi
que les dépendances d'importation entre les sous-systèmes.
|
Evaluation du modèle d'implémentation
|