Tâche: Structurer le modèle d'implémentation
Cette tâche décrit comment définir la structure des éléments de l'implémentation en fonction des responsabilités attribuées aux sous-systèmes d'implémentation et à leur contenu.
Disciplines: Implémentation
Relations
Etapes
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.

Illustration de l'extraction de déclaration de type de sous-système

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.

Exemple de diagramme de transfert de regroupement d'artefact

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
Plus d'informations