Version support et suivi de modification

2.2.4.1. Systèmes existants

Les représentations multi-vues du produit dans des environnements collaboratifs doivent permettre aux experts de travailler ensemble à différents niveaux du processus de développement de produit. L’environnement collaboratif exige le maintien de cohérence des différents modèles construits au cours du processus de conception ; cette cohérence est obtenue par trois principaux composants :

− un modèle commun qui intègre tous les autres modèles,

− un système de versionement qui permet d’une part de décrire des alternatives, des choix et

des solutions et d’autre part de suivre les évolutions de l’information,

− un système de synchronisation, qui détecte les incohérences et les conflits entre les

modèles. Il doit fournir aux acteurs un support pour observer, configurer et résoudre des conflits entre les différentes vues métier.

Comme la conception évolue au fil du temps, de nombreuses révisions, variantes, ou alternatives de la conception, peuvent être créées. La gestion de versions trace ces différences et assure que les différentes versions du modèle de conception sont cohérentes avec les attentes des concepteurs. Alors que la gestion de versions a été utilisée avec succès dans certaines disciplines de l’ingénieur, notamment en génie logiciel (RCS : Revision Control System, CVS : Concurrent Versions System), nous constatons peu de systèmes de conception mécanique qui supporte la gestion de versions pour des modèles de conception. En effet, les modèles de conception mécanique présentent des caractéristiques qui rendent difficile la

gestion de versions et qui doivent être considérées lors du développement d’un système de versionement :

− les applications métier développées à l’origine par des concepteurs spécialistes, ne se

préoccupent que de la technologie métier et beaucoup moins des problèmes de collaboration.

− les éléments d’un modèle en conception s’organisent hiérarchiquement par des relations

spécifiques dans chaque modèle,

− il y a de multiples représentations pour un objet de conception,

Pour tenir compte de ces caractéristiques, les approches adaptatives de versionement, doivent permettre de décrire les caractéristiques des objets de conception ainsi que les relations entre ces objets. La plupart des bases de données en conception sont basées sur des approches

parallèles de copies multiples pour coordonner l’évolution de la conception (Figure 2.18).

Figure 2.18 Evolutions de la conception par les versions parallèles

Cela se traduit par trois étapes :

− Copier : les utilisateurs réservent des copies d’objets qu’ils veulent modifier dans leurs applications locales. Les autres utilisateurs potentiels n’accèdent pas à ces copies tant qu’elles ne sont pas déposées de nouveau dans la base partagée.

− Modifier : plusieurs applications acquièrent simultanément des copies du même objet et les modifient indépendamment les unes des autres, créant ainsi des versions parallèles pour le même objet.

− Fusionner : pour coordonner le dépôt des nouvelles versions dans la base partagée, on opère au préalable une fusion des versions (réconciliation). Cette réconciliation génère une version spécifique pour chaque objet modifié et cette version est amenée à être déposée dans la base.

2.2.4.2. Conséquence en conception

Ces approches sont fondées sur l’isolement des différentes copies d’un objet de conception puis leur fusion. Chaque version représente l’état de l’objet à un moment donné de

l’historique du projet de conception. Ces approches sont introduites afin de garantir que les concepteurs ne perturbent pas les travaux de leurs collègues en phase synchrone.

Il est alors nécessaire de supporter la gestion et la fusion des différentes copies. Lors d’un projet de conception collaborative, il n’est pas rare que deux concepteurs accèdent simultanément à un même objet de conception (par exemple, un composant du produit), et travaillent par la suite de façon isolée (en mode asynchrone). Chaque concepteur modifie l’objet considéré selon ses propres contraintes et critères. Pour assurer l’émergence d’une solution commune, leurs résultats doivent donc être fusionnés. Avant de les fusionner dans la base partagée, chaque concepteur doit valider ses modifications au regard de celles proposées par les autres concepteurs.

Le plus souvent, les concepteurs travaillent de manière indépendante, modifiant des versions alternatives. Tous les conflits qui apparaissent exigent la négociation et la propagation des décisions de modifications vers les différentes vues des autres concepteurs. Ceci est habituellement réalisé lors de la phase de synchronisation entre les différentes versions. Ainsi, la modification d’une entité d’une vue spécifique peut être cause de conflits avec les entités d’autres vues indiquées dans le modèle partagé. En conséquence, l’identification des impacts issus d’une modification passe par une identification manuelle par les concepteurs. Ce processus manuel n’assure pas un cheminement complet de toutes les modifications du modèle partagé. Par conséquent, une approche efficace pour dépister les modifications de modèle commun est nécessaire pour améliorer de manière significative le processus de synchronisation.

Si des confits apparaissent, les concepteurs doivent négocier la fusion de leurs modifications, donnant ainsi, lieu à une nouvelle version de l’objet. En résumé, le conflit est défini comme un désaccord entre au moins deux experts de la conception dont les points de vue ou objectifs apparaissent contradictoires.

Certains conflits syntaxiques peuvent être automatiquement identifiés par des outils mettant à jour l’information dans une vue quand une autre vue est éditée. Toutefois, la plupart du temps les conflits ne seront pas automatiquement détectés et résolus. Par conséquent de nouveaux mécanismes sont nécessaires pour détecter et évaluer ces conflits afin de notifier les acteurs concernés. Beaucoup de travaux sur la détection et la notification de conflits dans le domaine des bases de données existent dans la littérature ; on distingue les bases de données actives et les bases de données distribuées.

Habituellement, les systèmes de base de données actives utilisent les règles de type "ECA : Événement-Condition-Action". Si la condition de la règle ECA est satisfaite alors des actions associées seront exécutées. La complexité de l’environnement de conception, la grande hétérogénéité des outils de conception et le manque d’interopérabilité entre ces outils limitent l’application de ces concepts aux modèles partagés en conception collaborative.

D’autre part, les systèmes de bases de données actives et distribuées proposées dans la littérature n’utilisent aucun mécanisme de détection de conflits complexes et de notification pour contrôler les dépendances entre le modèle partagé et les contraintes définies par le concepteur. La gestion de tels conflits requière une assistance pour :

− Identifier et mesurer une évolution conflictuelle d’un environnement collaboratif : connaître les sources d’incohérence et de conflit ainsi que les étapes d’évolution des versions vers l’incohérence entre elles, dans le but quand synchroniser. Nous avons constaté que si la durée d’évolution des versions excède une limite difficile à cerner, la synchronisation des versions devient ingérable.

− Analyser les vraies raisons d’un conflit : 1) identifier les différents types d’incohérences et de conflits ; conflits liés aux violations d’une ou plusieurs règles métiers, aux méthodes, aux valeurs, etc., 2) utiliser les méthodes et outils spécifiques d’analyse de conflits en conception pour définir les différentes causes de conflits et le classement de ces causes.

− Gérer les comportements d’un conflit : marquer les différents types de comportements d’un conflit dans le processus de conception collaborative.

− Assister la résolution les conflits inter experts : 1) évaluer le positionnement et l’importance des acteurs concernant le conflit dans une réunion de projet de conception, 2) résoudre le conflit par une stratégie adaptée qui peut être un processus automatique ou un processus semi-automatique avec une phase de négociation.

La gestion de conflits pourrait être améliorée si le système de conception intégrée emploie un système temps réel pour détecter les conflits structuraux ou sémantiques entre les différentes vues. Dans tous les cas, il est nécessaire de modéliser les interactions entre les entités du modèle partagé.