3. Scénario d’usage dans un environnement de
3.4. Problème d’incohérence
Les exemples de conception présentés à la section 3.3 impliquent plusieurs acteurs et
conduisent souvent à des ensembles de représentations incohérentes entre elles. Différentes définitions ont été données pour le terme incohérence ou conflit en conception coopérative :
− un désaccord entre les concepteurs sur les composants du produit et/ou sur leur évolution
[Con98],
− une incompatibilité entre deux décisions concernant la conception ou les objectifs des
concepteurs [Kle00],
− une divergence d’objectifs [Cas00].
Dans tous les cas, une source de conflits apparaît lorsque plusieurs concepteurs proposent des représentations du produit ou d’une de ses parties et que ces propositions sont incompatibles. Il ne faut pas en conclure que plusieurs propositions ne peuvent coexister au même instant, mais plutôt qu’il est nécessaire d’organiser le suivi et la mise en cohérence de ces systèmes. Dans l’environnement coopératif GAM, les acteurs peuvent travailler de manière indépendante et asynchrone sur des versions différentes (Figure 3.19).
La cohérence des données entre ces versions demeure problématique. Selon les définitions précédentes de conflit, les sources majeures de conflit qui se manifestent pendant la synchronisation de ces versions sont :
− la modification concurrente de données communes : les conflits dans ce cas correspondent aux incompatibilités syntaxiques entre deux versions concernant des modifications différentes des données communes. Ce type de conflit peut être détecté par une comparaison de versions différentes,
− la violation des regèles métiers : une part importante de la conception coopérative consiste à communiquer et à échanger des données, des informations et des connaissances, entre concepteurs ayant des points de vue et des objectifs différents et spécifiques à leurs domaines d’expertise (mécanique, électricité, fabrication, marketing, …). Lorsque ces points de vue et ces objectifs sont mis en commun, de telles divergences (des points de vue différents) conduisent fréquemment à des conflits. Pour prendre en compte ces différents points de vue et règles métiers qui interviennent en avancement de la conception, l’intégration de l’ensemble des exigences et des règles métiers est une tâche importante de la conception. Cette intégration permet d’éviter des conflits entre leurs exigences.
Prenons deux exemples (Figure 3.20), issus du cas de la conception du relais
électromagnétique et qui illustrent l’intérêt de la modélisation des contraintes techniques en conception coopérative. L’épaisseur de la culasse et l’entrefer entre la culasse et le noyau sont deux paramètres géométriques contraints par les deux domaines de la mécanique et de l’électrotechnique.
Figure 3.20 Intérêt de modéliser les contraintes techniques
En ce qui concerne l’épaisseur de la culasse :
− du point de vue mécanique, il ne faut pas que l’épaisseur de la culasse soit trop importante pour permettre son pliage lors de sa fabrication mais il faut également qu’elle ne soit pas trop petite afin d’assurer une certaine rigidité de la structure,
− du point de vue électrotechnique, la culasse constitue une partie du circuit magnétique et son épaisseur influence le flux magnétique.
En ce qui concerne l’entrefer :
− pour l’électrotechnicien, cet entrefer représente une grande résistance dans le circuit magnétique et il doit être suffisamment petit pour ne pas empêcher le flux magnétique,
− pour le mécanicien, si l’entrefer est trop petit, le frottement entre le noyau et la culasse gêne le mouvement de la partie centrale ; il doit être suffisamment grand pour permettre au clou de glisser mécaniquement en prenant en compte aussi les tolérances de fabrication.
De telles contraintes, considérées comme des informations importantes de la conception, doivent être modélisées et échangées en parallèle avec le modèle produit et au fur et à mesure de l’avancement du projet de conception. Il faut que chaque acteur de la conception se demande quelles sont les influences et les contraintes imposées par son propre métier. Ainsi, en prenant en compte les différentes contraintes de chaque métier avec le modèle produit, les acteurs peuvent aboutir à un compromis afin soit d’éviter tous les conflits ou pour négocier et formuler des intervalles de variations tolérables par tous les métiers.
Les experts doivent disposer d’une configuration des événements pour vérifier quand et comment les conflits sont détectés, surveillés, stockés, présentés, et éventuellement automatiquement résolus. Ceci passe par des méthodes vérifiant la violation des contraintes et définissant l’importance relative des conflits. Tracer les évolutions de chaque modèle est aussi un élément important pour simplifier l’identification des conflits et leurs causes, cela simplifie l’accès à l’information associée et la prise de décision. La prise de décision peut être assistée par un support de négociation entre experts affichant les causes de conflits et formalisant les conséquences des décisions.
Pour résoudre le problème de cohérence entre les acteurs métiers dans l’environnement coopératif GAM, nous proposons deux composantes complémentaires : GAM-Constraint et GAM-Diff. Ces deux composantes sont des supports à la cohérence de l’ensemble des experts, facilitant ainsi la représentation et l’échange des règles métiers et le processus de synchronisation des versions avec le modèle partagé.
3.4.2. GAM-Diff
Le module GAM-Diff que nous utilisons, fournit un méta-modèle pour représenter la différence entre les modèles. Un algorithme générique compare deux modèles dans l’environnement GAM et retourne un modèle de différences conforme au méta-modèle de différences. Le mécanisme de comparaison permet d’identifier les modifications (ajout, suppression, modification d’éléments) du modèle de départ afin de représenter et traiter les différences entre le modèle de départ et le modèle évolué (la version).
Le module GAM-Diff est donc un outil d’aide pour la synchronisation des versions parallèles d’un même modèle. Les experts utilisent ensuite ces modèles de différences pour choisir les modifications qu’ils accepteront ou qu’ils refuseront lors de la mise à jour du modèle partagé. Le module GAM-Diff assure surtout la vérification de la cohérence syntaxique. Ce module est présentée et développée en détails dans les chapitres suivants.
3.4.3. GAM-Constraint
Le modèle partagé PPO est statique, le suivi de son évolution est laissé à la propre initiative des concepteurs. Ce mode est loin d’être suffisamment productif. En effet, les acteurs ont besoin d’un environnement dynamique pour gérer l’évolution du modèle partagé et pour maintenir la cohérence de la conception.
La caractéristique de cet environnement dynamique est le fait qu’il intervient comme un acteur de la conception. Le module GAM-Constraint est envisagé pour définir la dynamique de modèle.
Les contraintes sont issues des relations qui apparaissent entre les éléments du modèle produit pour maintenir la cohérence du modèle. Les contraintes définissent en quelques sortes les règles d’évolution du modèle partagé. Nous nous basons sur la déclaration et la vérification du réseau de contraintes définies sur un modèle produit. Les contraintes réduisent l’espace d’évolution des représentations du produit, mais permettent de maintenir la cohérence dans l’environnement de conception et imposent des règles d’évolution. Ceci est présenté et développé en détails dans les chapitres suivants.
3.5. Conclusion
Dans ce chapitre, nous avons présenté un environnement coopératif (GAM) pour modéliser les divers points de vue des experts de la conception. Nous utilisons une implémentation du méta-modèle PPO, permettant de décrire les différents aspects du produit à concevoir à différents nivaux d’abstraction (composant, interface, fonction, comportement).
Dans cet environnement, chaque expert importe au moins une partie du modèle partagé. Ils éditent de manière asynchrone leur copie du modèle partagé sans que les autres acteurs soient informés des modifications en cours chez leurs collaborateurs. Une fois ces tâches asynchrones finalisées une étape de fusion doit être assistée selon les modifications proposées dans les différentes versions. Cette étape illustre certains problèmes de cohérence de versions lors de la modification concurrente de données communes ou lors de la violation des règles métiers. Pour aider les experts à maintenir la cohérence globale de modèle, la suite du document consiste à développer d’une part, un modèle de contraintes (module GAM-CONSTRAINT) support à la cohérence entre l’ensemble des experts en facilitant la représentation et l’échange des règles métiers, et d’autre part, une méthode basée sur (GAM-DIFF) qui fournit un moyen d’obtenir la différence syntaxique entre modèles conformé au même méta-modèle afin de réaliser la synchronisation et de conserver la traçabilité des modifications sur des versions construites en parallèle.