Activité :
|
Objet
|
|
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 : |
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).
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.
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.
Les déclarations de type sont extraites du sous-système D
.
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 Artefact : Principes et conseils spécifiques au projet.
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.
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).
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.
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.
Voir Points de contrôle : Modèle d'implémentation.
RUP (Rational Unified Process)
|