Worldlex Wiki - Dans la gestion de configuration (CM), il faut contrôler (entre autres) les modifications apportées aux logiciels et à la documentation. C'est ce qu'on appelle le contrôle de révision , qui gère plusieurs versions d'une même unité d'information. Bien que le contrôle de révision soit important pour la gestion de configuration, il n'est pas équivalent à celui-ci.
Les modèles de synchronisation , également connus sous le nom de modèles de gestion de configuration (Feiler, 1991), décrivent des méthodes permettant de contrôler les révisions en autorisant des modifications simultanées et concurrentes sur des fichiers individuels.
Modèles de synchronisation
Feiler (1991) présente quatre modèles de synchronisation différents, brièvement décrits ci-dessous.
Départ/Arrivée
Dans le modèle check-out/check-in, les fichiers sont stockés individuellement dans un référentiel à partir duquel ils sont extraits à chaque fois qu'ils sont consultés et archivés lorsqu'ils ont été modifiés. Ce référentiel peut stocker plusieurs versions des fichiers. Étant donné que ces fichiers peuvent être de la documentation ou du code source , mais peuvent également être une collection de fichiers, le terme Élément de configuration (CI) sera désormais utilisé. Le mécanisme de base utilisé pour éviter les conflits par des modifications simultanées est celui du verrouillage .
Composition
Le modèle de composition est une extension du modèle d'extraction/archivage. Ce modèle permet aux développeurs de penser en termes de configurations plutôt que de fichiers individuels. Bien que le modèle d'extraction/archivage complet soit représenté dans le modèle de composition, il permet l'utilisation de différentes stratégies de mise à jour grâce à l'utilisation d'un support amélioré pour la gestion des configurations. Une configuration est définie comme étant construite à partir d'un modèle système et de règles de sélection de version. Le modèle système détermine quels fichiers sont utilisés, tandis que les règles de sélection de version déterminent quelle version des fichiers (par exemple les dernières versions ou d'un certain état de développement ).
Transactions longues
Le modèle des transactions longues adopte une approche plus large en supposant qu'un système est construit à partir de modifications logiques. Il se concentre sur la coordination et l'intégration de ces modifications. Il utilise essentiellement des versions de configurations et des versions de fichiers. Une configuration est créée sur la base d'une demande de modification qui est stockée séparément. Les fichiers de cette configuration peuvent être synchronisés à l'aide du modèle d'extraction/archivage. Une fois la modification terminée, la configuration complète est stockée dans le référentiel et intégrée aux autres modifications.
Changer l'ensemble
Le modèle de jeu de modifications fonctionne également sur la base de demandes de modification et présente de nombreux points communs avec le modèle de transactions longues. Cependant, il commence par une certaine configuration comme base des modifications. Celle-ci est ensuite modifiée en fonction des demandes de modification indépendantes qui arrivent. De nouvelles configurations du produit sont ensuite créées en appliquant des ensembles de modifications enregistrées indépendamment sur la version de base .
Cette entrée couvre le modèle de synchronisation check-out/check-in, y compris un méta-modèle (un diagramme de processus-données ). Étant donné que le modèle check-out/check-in est également inclus dans les autres modèles évoqués ci-dessus, il est donc développé plus en détail. Les questions qui ne sont pas abordées en détail sont les trois modèles de synchronisation restants et l'édition proprement dite des CI ainsi que les méthodes qui y sont liées.
Vocabulaire
| Concept | Définition | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Version | Une version est un état d’un objet ou d’un concept qui varie par rapport à son état ou à sa condition précédente. | ||||||||||||||||||||||||||||||||||||
| Élément de configuration | Un élément de logiciel ou un document placé sous contrôle de version. Un groupe de CI peut également être défini comme un CI (Crnkovic et al., 2003). | ||||||||||||||||||||||||||||||||||||
| Historique des éléments de configuration | Un concept pour faciliter l'horodatage des versions. Sépare les attributs spécifiques à la version des attributs communs à toutes les versions (Van de Weerd, 2005) | ||||||||||||||||||||||||||||||||||||
| Document | De nombreux types de documentation font partie de l'ingénierie logicielle. Pensez aux documents qui décrivent l'architecture du logiciel, à la documentation technique, aux manuels d'utilisation, etc. | ||||||||||||||||||||||||||||||||||||
| Fichier de code source | Un fichier de code source contient une série d'instructions écrites dans un langage de programmation informatique lisible par l' homme. Le code source d'un programme informatique est l'ensemble des fichiers qui peuvent être convertis d'une forme lisible par l'homme en une forme équivalente exécutable par ordinateur. | ||||||||||||||||||||||||||||||||||||
| Dépôt | Un référentiel est également appelé coffre-fort. Un référentiel ne contient qu'une seule version complète d'un élément de configuration. Les différences entre les versions sont généralement stockées à l'aide d'un algorithme delta (Crnkovic, Asklund et Persson-Dahlqvist, 2003). | ||||||||||||||||||||||||||||||||||||
| Organisation des versions | Les versions d'un CI peuvent être organisées de différentes manières. C'est le parent des concepts qui décrivent l'organisation des versions (Crnkovic et al., 2003). | ||||||||||||||||||||||||||||||||||||
| Bifurquer | Versions organisées en lignes de développement parallèles (Crnkovic et al., 2003). | ||||||||||||||||||||||||||||||||||||
| Révision | Versions organisées en séquence (Crnkovic et al., 2003). | ||||||||||||||||||||||||||||||||||||
| État de développement | Exprime la progression du développement d'un logiciel et le niveau de développement supplémentaire qu'il peut nécessiter. Chaque version majeure d'un produit passe généralement par une étape au cours de laquelle de nouvelles fonctionnalités sont ajoutées (étape/état alpha), puis une étape au cours de laquelle elle est activement déboguée (étape/état bêta), et enfin une étape au cours de laquelle tous les bugs importants ont été supprimés (étape/état stable). Élaboration du modèle de check-out/check-inCette section contient une élaboration du modèle de synchronisation d'enregistrement/de sortie. Diagramme de processus et de données
Le diagramme de processus-données ci-dessus décrit les différents concepts applicables dans le modèle de synchronisation check-out/check-in et leur relation avec les activités qui se déroulent. L'élément de configuration est au cœur du modèle de métadonnées (côté droit de la figure). Il est stocké dans un ou plusieurs référentiels et peut par exemple être un fichier de code source ou une collection d'autres CI. Le référentiel peut contenir plusieurs branches et révisions de fichiers. Ceux-ci sont à leur tour constitués d'éléments de configuration. Le modèle de métaprocessus (côté gauche de la figure) décrit le processus des activités de check-out et check-in. Les activités sont expliquées dans le tableau des activités ci-dessous.
|
