Artefact :
|
![]() |
Une construction désigne une version fonctionnelle d'un système, ou d'une partie du système exposant un sous-ensemble des capacités que le produit final doit fournir. Elle comprend un ou plusieurs éléments d'implémentation (souvent exécutables), construits chacun à partir d'autres éléments, habituellement à travers un processus de compilation et de liaison du code source. | |
Rôle : | Intégrateur | |
---|---|---|
Caractère facultatif/Occurrence: | A chaque itération. | |
Canevas et rapports : |
|
|
Exemples : | ||
Représentation UML : | Package dans le modèle d'implémentation (soit son package de plus haut niveau, soit un sous-système d'implémentation), stéréotypé en tant que <<construction>>. | |
Informations supplémentaires : | ||
Entrée d'activités : | Sortie d'activités : |
L'objet d'une construction, qui est construite à partir d'autres éléments dans l'implémentation, est de soumettre un sous-ensemble testable des fonctions et des capacités du système dans son contexte d'exécution. Le processus de Rational Unified Process (RUP) préconise la construction d'une séquence de constructions au cours d'une itération, chacune apportant de nouvelles capacités au fur et à mesure de l'ajout ou de l'amélioration d'éléments de sous-systèmes d'implémentation. Des constructions peuvent être construites à tous les niveaux d'un système et englober un seul ou de multiples sous-systèmes mais RUP s'intéresse tout particulièrement à celles définies dans l'Artefact : Plan de construction d'intégration, dans la mesure où elles constituent le tremplin pour compléter l'itération. Si les dimensions du système ou sa complexité le justifient, le plan de construction d'intégration peut être peaufiné en plusieurs plans couvrant des sous-systèmes distincts.
Notez que des constructions informelles peuvent être construites par un implémenteur pour diverses raisons, par exemple pour des tests unitaires utilisant des éléments de son espace de travail de développement privé et des espaces de travail d'intégration du système et du sous-système, selon ses besoins. Cependant, pour les besoins de notre discussion, ce terme se réfère aux constructions construites par un intégrateur à partir de versions d'éléments identifiées et déposées par les implémenteurs dans les espaces de travail d'intégration du système ou du sous-système, tel que défini dans l'Artefact : Plan de construction d'intégration.
Nom de la propriété |
Brève description |
Représentation UML |
---|---|---|
Description | Brève description de la construction | Valeur marquée, de type "texte court" |
Sous-systèmes d'implémentation | Sous-systèmes représentés dans la construction | Appartenance via la méta-association "représente", ou récursivement via la méta-agrégation "propriétaire de" |
Eléments | Eléments d'implémentation dans la construction, appartiennent aux sous-systèmes | Appartenance récursive via la méta-agrégation "propriétaire de" |
Référence du plan de construction d'intégration | Référence à la description détaillée de la construction dans le plan de constructiond'intégration correspondant | Valeur marquée |
Des versions détaillées seront construites, pour chaque itération, comme défini dans l' Artefact : Plan de construction d'intégration. RUP n'impose pas de calendrier ou de fréquence spéciale : ces paramètres sont sélectionnés pour convenir aux besoins spécifiques du projet. Il est tout à fait envisageable, avec le niveau d'automatisation adéquat, d'adopter une stratégie de construction quotidienne où un flux régulier d'éléments est soumis par les implémenteurs, intégré et testé dans la construction correspondante du jour au lendemain. Ceci ne convient pas à tous les projets, notamment ceux de grande envergure et requérant un test de régression prolongé.
L' intégrateur est responsable de la production des constructions. Si le développement est planifié autour de sous-systèmes (avec leurs équipes associées), qui sont ensuite intégrés dans le système, plusieurs individus peuvent remplir le rôle d'intégrateur (un, par exemple, dans chaque équipe de sous-système, pour intégration au niveau de leur sous-système, et un autre pour l'intégration au niveau du système).
Les constructions sont de toute évidence obligatoires, cependant les types de versions produites évoluent au cours du cycle de vie du projet. Pour la phase de création, l'objectif peut être de générer des prototypes afin de mieux cerner le problème ou de mieux communiquer avec le client ; pour la phase d'élaboration, de produire une architecture stable ; et pour la phase de construction, d'ajouter des fonctionnalités. Dans la phase de transition, la qualité du logiciel pour livraison devient la préoccupation principale.
RUP (Rational Unified Process)
|