Objet
  • Mettre en place la structure qui accueillera l'implémentation.
  • Attribuer des responsabilités pour les sous-systèmes d'implémentation et leur contenu.
 
Rôle :  Architecte logiciel 
Fréquence :  Au moins une fois par itération, lorsque de nouveaux éléments d'implémentation sont découverts. 
Etapes  
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   
Plus d'informations : 

Détails de l'enchaînement des activités :   

Mettre en place la structure de modèle d'implémentation Haut de la page

Objet Mettre en place la structure du modèle d'implémentation. 

En passant de l'"espace de conception" à l'"espace d'implémentation", commencez par refléter la structure du modèle de conception dans le modèle d'implémentation.

Les packages de conception posséderont des sous-systèmes d'implémentation correspondants, contenant un ou plusieurs répertoires et fichiers (Artefact : Elé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 lors de l'attribution d'une couche spécifique de l'architecture à chaque sous-système d'implémentation.

Créez un diagramme pour représenter la structure du modèle d'implémentation (voir Principes et conseils : Diagramme d'implémentation).

Ajuster les sous-systèmes d'implémentation Haut de la page

Objet Adapter la structure du modèle pour refléter l'organisation de l'équipe ou les contraintes en termes de langues d'implémentation. 

Déterminez si l'organisation des sous-systèmes doit être changée, en abordant des problèmes tactiques mineurs liés à l'environnement d'implémentation. Vous trouverez ci-dessous quelques exemples de ces problèmes tactiques. Notez que si vous décidez de changer l'organisation des sous-systèmes d'implémentation, vous devez également déterminer s'il est préférable de revenir en arrière et de mettre à jour le modèle de conception, ou bien de permettre au modèle de conception de différer du modèle d'implémentation.

  • Organisation de l'équipe de développement. La structure des sous-systèmes doit permettre à plusieurs implémenteurs ou à une équipe d'implémenteurs d'avancer parallèlement sans trop de chevauchement ni de gêne. Il est recommandé que chaque sous-système d'implémentation dépende d'une seule équipe. Cela signifie qu'il vous faudra peut-être fractionner un sous-système en deux (s'il est de taille importante), et attribuer l'implémentation des deux parties à deux implémenteurs ou deux équipes d'implémenteurs, particulièrement si les deux implémenteurs (ou équipes) ont des cycles de construction/version différents.
  • Déclarations de types. Dans l'implémentation vous pouvez vous rendre compte qu'un sous-système doit importer des artefacts d'un autre sous-système, car un type est déclaré dans ce sous-système. Cela se produit par exemple lors de l'utilisation de langages de programmation typés comme C++, Java et Ada. Dans cette situation, et de manière générale, il peut être utile d'extraire les déclarations de type dans un sous-système indépendant.

Exemple

Vous extrayez certaines déclarations de type du sous-système D, dans un nouveau sous-système Types, afin de rendre le sous-système A indépendant des changements effectués sur les artefacts publics (visibles) du sous-système D.

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

Les déclarations de type sont extraites du sous-système D

.

  • Code existant et systèmes de composants. Vous devrez peut-être incorporer un code existant, une bibliothèque de composants réutilisables ou des produits standard. S'ils n'ont pas été modélisés lors de la conception, des sous-systèmes d'implémentation doivent être ajoutés.
  • Ajuster les dépendances. Supposons qu'un sous-système A et un sous-système B ont des dépendances d'importation l'un par rapport à l'autre. Vous souhaiterez peut-être rendre B moins dépendant des changements du sous-système A. Extrayez les artefacts de A que B importe et placez-les dans un nouveau sous-système d'implémentation A1 dans une couche inférieure.

Exemple de diagramme de transfert de regroupement d'artefacts

Les artefacts 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 exactement les packages/sous-systèmes du modèle de conception, vous pouvez choisir d'effectuer des changements correspondants dans le modèle de conception (si vous avez décidé que le modèle de conception doit être étroitement aligné au modèle d'implémentation) ou bien de suivre le mappage entre les modèles d'implémentation et de conception (par exemple, par le biais des dépendances de traçabilité ou de réalisations). Le fait d'effectuer ce mappage, et la manière de le faire, est une décision de processus qui doit être consignée dans ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websiteArtefact : Principes et conseils spécifiques au projet.

Définir les importations pour chaque sous-système d'implémentation Haut de la page

Objet Définir les dépendances entre les sous-systèmes. 

Pour chaque sous-système, définissez les autres sous-systèmes qu'il importe. Cela peut être fait pour des ensembles entiers 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. Généralement, les dépendances du 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 Ajuster les sous-systèmes d'implémentation).

Présentez la structure en couche des sous-systèmes dans des diagrammes de composants.

Déterminer comment traiter les exécutables (et autres objets dérivés) Haut de la page

Les exécutables (et autres objets dérivés) sont obtenus par l'application d'un processus de construction à un sous-système (ou à des sous-systèmes) d'implémentation ou à une partie de celui-ci, et appartiennent donc en toute logique au sous-système d'implémentation. Cependant, l'architecte logiciel, en collaboration avec le responsable de la configuration, devra décider de la structure d'éléments de configuration à appliquer au modèle d'implémentation. 

Pour faciliter la sélection et la référence, particulièrement pour le déploiement, la recommandation par défaut consiste à définir des éléments de configuration indépendants pour regrouper les ensembles d'exécutables déployables (pour savoir quels exécutables sont déployés et sur quel noeud, consultez le modèle de déploiement). Ainsi, pour simplifier, à chaque sous-système d'implémentation doit correspondre un élément de configuration pour les exécutables déployables et un élément de configuration contenant notamment la source utilisée pour les produire. On peut considérer que le sous-système d'implémentation est représenté par un élément de configuration composite contenant ces éléments de configuration (et peut-être d'autres, comme des ressources de test).

Du point de vue de la modélisation, un ensemble d'exécutables produits par un processus de construction peut être représenté comme un Artefact : Construction (qui est un package) faisant partie du sous-système d'implémentation associé (lui-même un package).  

Déterminer comment traiter les ressources de test Haut de la page

Objet Ajouter des artefacts de test au modèle d'implémentation. 

Généralement, les artefacts et les sous-systèmes de test sont traités de façon assez similaire dans le Rational Unified Process et dans les autres logiciels développés. Cependant, les artefacts et les sous-systèmes de test ne font généralement pas partie du système déployé, et ne sont souvent pas livrés au client. La recommandation par défaut préconise donc d'aligner les ressources de test à la cible du test (par exemple l'élément d'implémentation pour le test unitaire, le sous-système d'implémentation pour le test d'intégration, le système pour le test système), mais de maintenir les ressources du test dans, par exemple, des répertoires de test indépendants, si le référentiel du projet est organisé en un ensemble ou une hiérarchie de répertoires. Les sous-systèmes de test distincts (destinés à des niveaux de test supérieurs à l'unité) doivent être traités de la même manière que les autres sous-systèmes d'implémentation - en tant qu'éléments de configuration distincts.

Pour la modélisation, un ensemble d'artefacts de test peut être représenté comme un Artefact : Sous-système d'implémentation (un package). Pour un test unitaire, un sous-système de test de ce type doit normalement faire partie du sous-système d'implémentation associé (testé). L'architecte logiciel, doit, en accord avec le responsable de la configuration, décider si les artefacts de test à ce niveau doivent être configurés avec les éléments d'implémentation qu'ils testent ou en tant qu'éléments de configuration indépendants. Pour le test d'intégration et système, les sous-systèmes de test peuvent être les homologues des sous-systèmes d'implémentation testés.

Mettre à jour la vue d'implémentation Haut de la page

Objet Mettre à jour la vue d'implémentation du document d'architecture logicielle. 

La vue d'implémentation est décrite dans la section "Vue d'implémentation" du document d'architecture logicielle. Cette section comporte des diagrammes de composants montrant les couches et l'attribution des sous-systèmes d'implémentation à ces couches, ainsi que les dépendances d'importation entre les sous-systèmes.

Evaluer le modèle d'implémentation Haut de la page

Voir Points de contrôle : Modèle d'implémentation.

 

RUP (Rational Unified Process)   2003.06.15