La comparaison avec BranchManager for DOORS®
BranchManager for DOORS® fournit un mécanisme de comparaison puissant pour identifier les différences entre les versions de référence, à travers les branches. Ce moteur de comparaison intelligent peut comparer,
à partir d'une liste d'attributs (sélectionnables), et peut détecter les changements sur les attributs, les objets OLE, les liens, et les changements structurels tel que le déplacement d'une exigence dans la hiérarchie.
Comprendre la comparaison
Correspondance entre objets
La fonctionnalité de comparaison permet de trouver les différences entre un module A et un module B. L'algorithme de comparaison fonctionne au niveau objet, i.e. BranchManager for DOORS® trouvera tout d'abord
quel objet du module A correspond à quel objet du module B. Ceci est appelé "phase de correspondance". Pour la correspondance, BranchManager for DOORS® n'a pas encore la possibilité de trouver l'objet par contenu.
Par conséquent, l'utilisateur doit fournir à l'outil un moyen de faire correspondre les objets des deux modules:
- Correspondance par attribut
Si dans les deux modules il y a deux attributs qui ont une référence correspondante, BranchManager for DOORS® peut utiliser ces attributs pour faire correspondre les objets. Ceci est le scenario le plus commun.
Dans ce cas, il y a deux modules, qui sont une copie l'un de l'autre et qui ont le même Absolute Number. L'Absolute Number peut être utilisé pour faire correspondre les objets.
Dans un autre scénario, vous pourriez avoir exporté un module vers Excel, réalisé quelques changements et importé de nouveau dans un nouveau module. Dans le nouveau module, les objets doivent avoir de nouveaux Absolute Numbers,
mais si vous avez exporté et importé l'Absolute Number des objets originaux et stocké dans un attribut, vous pouvez utiliser cet attribut pour faire correspondre les objets. A noter que dans deux versions de référence d'un module,
les objets peuvent être retrouvés en utilisant l'Absolute Number.
- Correspondance par lien
Si dans deux modules, les objets sont liés 1:1, alors les objets peuvent être mis en correspondance en utilisant les liens. Ce scénario est commun, quand par exemple les modules ont été copiés en utilisant Copy-And-Link
ou dans les cas où des scripts DXL sont utilisés pour maintenir les exigences à travers plusieurs modules. Une autre façon serait d'utiliser la fonctionnalité de comparaison sur deux modules n'ayant pas
d'identifiant commun. La direction du lien ou le module de lien n'a pas d'importance dans ce cas. BranchManager for DOORS® prendra en compte les liens dans les deux directions.

- Correspondance par branche
Faire la correspondance par branche des objets de deux modules est comme faire la correspondance des modules par attribut, avec une différence importante. Bien que BranchManager for DOORS® stocke l'identifiant d'un objet de la branche
dans l'attribut "BranchManager Internal Reference Long", cet attribut ne peut pas être utilisé pour faire correspondre les objets des deux modules. La réelle référence est calculée
à la volée, en prenant en compte qu'un objet peut avoir une valeur d'attribut vide ou non valide - dans ce cas un nouvel identifiant unique sera calculé. Lors de la correspondance entre objets,
cet identifiant calculé est utilisé, en s'assurant que les versions de référence n'ont pas déjà l'attribut et qu'elles peuvent donc être utilisées et qu'il n'y a pas d'erreur à cause d'une copie.
Avant et après - La comparaison "dirigée"
Il est important de comprendre que les résultats d'une comparaison rapporte une différence, c'est-à-dire la liste de changements à apporter à un module pour avoir le même contenu qu'un autre module.
Pour cela, BranchManager for DOORS® assume que les deux modules sont originaires du même module ou de la même version de référence et que l'un des modules comparé contient l'état d'avant,
c'est-à-dire que des changements y ont été réalisés et que l'autre module contient l'état d'après, c'est-à-dire après que tous les changements ont été appliqués.
Il faut comprendre qu'il n'y a pas de moyen sûr de détecter dans quel module les changements ont été réalisés (dans tous les cas, il n'y a pas d'historique)
Example:
Object Text dans le Module A: This is a requirement
Object Text dans le Module B: There is no requirement here.
Si A est le plus vieux module et B est un nouveau module, alors le résultat sera:
This
There is
a
no requirement
here.
Les mots "This" et "a" ont été supprimés et les mots "There", "no" et "here." ont été insérés.
Si B est le plus vieux module et A est un nouveau module, alors le résultat pourrait être:
This
There
is
no
a requirement
here.
Les mots "There", "no" et "here." ont été supprimés, alors que les mots "This" et "a" ont été ajoutés.
En fonction du module considéré comme le plus ancien, le résultat de la comparaison pourrait être inversé. En fait, on ne peut pas déterminer, à partir de l'exemple précédent, quels changements ont vraiment été réalisés.
Il est aussi possible que les deux modules soient modifiés - c'est-à-dire qu'il y a eu un changement d'un text dans les deux modules.
Dans ce cas, le résultat de la comparaison peut paraître illogique ou faux.
Si dans le module A, un objet existe et qu'il n'y a pas l'objet correspondant dans le module B, il y a deux raisons possibles:
- l'objet a été créé dans le module A (le module A est nouveau, c'est-à-dire "après changement", le module B est ancien, c'est-à-dire "avant changement")
- l'objet a été supprimé du module B (le module B est nouveau, c'est-à-dire "après changement", le module A est ancien, c'est-à-dire "avant changement")
En fonction du module sélectionné comme étant le plus ancien, BranchManager for DOORS® donnera comme résultat: "L'objet dans le module A a été supprimé", ce qui pourrait surprendre sachant que l'objet n'a jamais été supprimé
- que rien n'a jamais été supprimé dans le module A. Dans ce cas, les options de comparaison doivent s'adapter au véritable sens avant et après changement. Si les changements ont été faits
des deux côtés, il peut être plus difficile de lire les résultats de compraison, puisque certains changements seront inversés (et d'autres non). A noter qu'on aura le même problème avec
la Fusion Rapide mais pas avec l'Intégration.
Quels sont les changements identifiés par BranchManager for DOORS®?
La fonctionnalité de comparaison a été créée pour repérer, sur un module DOORS, les modifications suivantes:
- Les objets créés
- Les objets supprimés
- Les objets supprimés et purgés
- L'ajout / suppression / modification d'une image DOORS
- Le changement d'un attribut de module ou d'objet:
- changement de format
- changement du contenu
- changement d'un objet OLE
- La création ou la suppression d'un lien DOORS
- Le déplacement d'un objet DOORS
A noter que la comparaison ne fait référence qu'au contenu des modules. Des changements sur le modèle de données ne font pas partis de la comparaison, c'est-à-dire des changements sur les liens, vues, permissions, attributs,
ainsi que sur les types si ils n'affectent pas le contenu. Par contre, si l'utilisateur change la valeur par défaut d'un attribut, ce qui impliquera un changement des valeurs de l'attribut pour tous les objets qui ont
cette valeur par défaut, ce changement apparaîtra lors de la comparaison. Un changement sur les valeurs des énumérations (par exemple, l'ajout d'une valeur d'énumération pour un type)
n'affectera la comparaison seulement si la valeur d'attribut d'un objet est changée.
Détails sur la comparaison des objets OLE
La comparaison des objets OLE n'est pas facile à réaliser dans DOORS. La comparaison native DOORS ne comparera pas les objets OLE, à cause d'un bug dans DOORS. En conséquence,
la taille des données de l'objet OLE change si l'objet est copié, versionné ou même lu plusieurs fois avec ré-ouverture du module entre-temps (même s'il n'a pas été changé entre les lectures).
BranchManager for DOORS® compare les objets OLE en examinant leur aspect visuel ainsi que leur taille. En utilisant cet algorithme, BranchManager for DOORS® n'a jamais échoué pour trouver un changement sur un objet OLE.
Les changements visuels, c'est-à-dire les changements qui résultent d'une différence sur l'image sont détectés à 100%. Il existe aussi des "changements invisibles" sur un objet OLE,
par exemple une table excel qui a des données en dehors de la zone affichée, dans une feuille de calcul caché de l'objet OLE. Un changement non visible est détecté en utilisant la comparaison de la taille des données.
Par contre, un changement non visible qui ne change pas la taille de l'objet OLE ne serait pas détecté par BranchManager for DOORS®.
Comprendre la comparaison hiérarchique
Les règles décrites dans la section Avant et après s'appliquent pour la détection des déplacements d'objets. Il est cependant plus probable que les changements détectés ne reflètent pas
les modifications exactes qui ont été réalisées. Les changements de structure sont souvent ambigus, c'est-à-dire que le même résultat peut être obtenu de plusieurs façons. Cela signifie que si BranchManager for DOORS®
retournera à 100% de bons résultats sur la détection de mouvements, il se peut que le résultat ne reflète pas ce que l'utilisateur a réellement fait pour obtenir l'état courant du module.
Exemple
Supposons deux modules qui ont chacun 5 éléments de plus haut niveau, sans aucune hiérarchie:

A partir de l'image, on peut voir que les objets 3 et 4 ont été échangés, cependant ceci a pu se faire de deux façons différentes:
- L'utilisateur a pu déplacer l'objet 3 après l'objet 4
- L'utilisateur a pu déplacer l'objet 4 après l'objet 2
Pour cet exemple simple, BranchManager for DOORS® n'a pas de façon de savoir lequel de ces changements a été réalisé. Cependant, cela ne posera pas de problème sachant que le résultat des deux changements est le même.
Dans le cas de déplacements ambigues, BranchManager for DOORS® montrera toujours le déplacement minimal. Le même résultat peut être obtenu en déplaçant un nombre différent d'objets. Supposons que dans notre exemple, quelqu'un a déplacé l'objet 5
en haut du module, ceci peut aussi être obtenu en déplaçant les objets 1,2,3 et 4 après l'objet 5. Le deuxième mouvement implique 4 objets, au lieu d'un objet.
Dans ce cas, BranchManager for DOORS® montre toujours la variante la plus petite, c'est-à-dire celle où le moins d'objets a été déplacés. Si, dans notre exemple, le même nombre d'objets est déplacé, alors l'objet qui intervient
en premier dans le module sera montré.
A noter que les ambiguités apparaissent pour les déplacements d'objets sous le même parent (ou au niveau le plus haut). Pour les objets qui sont déplacés vers un nouveau parent, la situation est habituellement non ambigue:

Dans ce cas, la seule façon d'obtenir cet état est de déplacer l'objet 4 sous l'objet 2.
Comprendre la comparaison des liens
L'algorithme de comparaison de liens dans BranchManager for DOORS® détermine les changements sur les liens sortants d'un module DOORS. Afin de s'adapter au concept de liens dans DOORS,
un changement sur un lien entrant est un changement sur le module à partir duquel le lien provient. Par conséquent, Branch Manager for DOORS® compare seulement les liens DOORS qui proviennent d'objets qui correspondent.
A noter que dans DOORS, ni la source, ni la cible d'un lien ne peut changer. BranchManager for DOORS® ne prendra donc en compte que deux cas:
- La création d'un lien
- La suppression d'un lien
Techniquement, les liens dans DOORS peuvent avoir des attributs qui peuvent être changés. BranchManager for DOORS® ne compare pas les attributs des liens. De plus, BranchManager for DOORS®
ne supporte pas la comparaison de liens externes. BranchManager for DOORS® ne considère pas le module de lien d'un lien, puisque celui-ci est considéré comme faisant partie du modèle de données.
Pour déterminer les liens créés et supprimés, BranchManager for DOORS® regarde les liens existants sur les objets avant et après changements.
Lorsqu'un lien existe "avant" changement et n'existe pas "après" changement, alors ce lien est considéré comme supprimé. Si un lien existe "après" changement et
n'existe pas "avant" changement, alors ce lien est considéré comme créé.
Exemple:

On voit sur la figure que les liens 3 et 4 ont été supprimés, alors que le lien 6 a été créé. Les mêmes règles que celles décrites dans la section Avant et Après s'appliquent ici.
La comparaison dans BranchManager for DOORS® doit prendre en compte que la cible d'un lien peut être n'importe quel objet de la base.
Comment peut-on dans ce cas considérer qu'un lien est le même qu'un autre lien ou non? Evidemment, quand les liens sur un objet "avant" et un objet "après" pointent exactement sur le même objet,
alors on peut considérer que ce sont les mêmes liens. Cependant, lorsque l'on créé une version de référence, copie ou échange des données, les liens peuvent ne pas pointer exactement vers le même objet.
Voici les scénarios, lorsque la comparaison de lien fonctionne avec BranchManager for DOORS®, même si la cible des liens comparés n'est pas la même.
Liens vers des versions de référence différentes de la même cible
Spécialement lorsque l'on travaille avec des ensembles de versions de référence, les liens d'une version de référence pointera vers une version de référence différente du même module cible.
Branch Manager for DOORS® est capable de comparer les liens des deux versions de référence, même si les liens des versions de référence pointent vers différents objets.
Dans la figure suivante, BranchManager for DOORS® détermine que la version du module cible pour la version de référence d'"avant" est 1.0 et que la version du module cible du
module d'"après" est la version courante. Ceci permettra à BranchManager for DOORS® de détecter les changements de lien.
Cependant, au fil de temps, il peut arriver que des liens sortent d'un des modules source vers les deux versions de référence.
Dans ce cas, BranchManager for DOORS® considère que la version du module cible est celle vers laquelle le plus de liens pointent.

Liens à partir de différents modules sources vers le même module cible
Lorsque l'on fait des copiés/collés ou que l'on fait des développements parallèles, on peut se retrouver dans une telle situation:

Il y a deux modules différents "avant" et "après", mais tous les deux contiennent des liens vers le même module cible (même version de référence ou différente,
la même règle s'appliquera).
Puisque les "avant" et "après" correspondent (par lien ou par attribut), BranchManager for DOORS® peut déterminer les changements de lien entre "avant" et "après".
Liens vers des modules cibles différents
Lorsque les liens cibles "avant" et "après" sont dans différents modules, qui ne sont pas dans une branche, alors la comparaison ne permettra pas de déterminer si les deux liens sont égaux.
Dans ce cas, BranchManager for DOORS® échouera à conclure que les deux liens sont égaux:

Liens dans des branches différentes
Si les modules "avant" et "après" sont des modules parallèles dans différentes branches (voir Comprendre les branches),
alors BranchManager for DOORS® peut "coupler" les liens qui sont dans la même branche que le module "avant" / "après". Lorqu'un lien pointe de la branche vers un projet externe,
alors BranchManager for DOORS® peut associer les liens, puisqu'ils pointent sur le même module.
Comprendre les messages de comparaison
L'outil de comparaison de BranchManager for DOORS® permet de visualiser les changements soit sur le module "avant", soit sur le module "après".
Les résultats de comparaison dépendent du sens de la comparaison. Si dans notre exemple un objet est supprimé (c'est-à-dire qu'il existe du côté "avant" et il n'existe pas
du côté "après"), si les changements sont vus du côté "avant", BranchManager for DOORS® mentionnera que l'objet a été supprimé.
Par contre, si le même changement est vu du côté "après", BranchManager mentionnera qu'un objet a été ajouté.
Dans le cas simple d'une différence sur un attribut, BranchManager for DOORS® montrera la différence en rouge. La figure suivante montre les différents
messages de comparaison pour le cas de création ou suppression d'un objet/lien. A noter que "l'objet du côté avant" et "l'objet du côté après" seront remplacés par l'identifiant
et le module de l'objet affecté.