Exemple support
Présentation de l’exemple support
L’application considérée a pour objectif la conception d’un appartement sur un niveau ayant une salle de séjour et dont l’un des côtés est constitué intégralement d’une baie vitrée. Plusieurs partenaires interviennent lors de cette conception, formant ainsi une entreprise-projet. Ceux-ci travaillent sur trois documents qu’ils sont amenés à s’échanger: le plan rédigé conjointement par l’architecte et l’ingénieur-structure et l’avis de l’urbaniste. Dans cet exemple, pour des raisons de simplification, nous représenterons chaque partenaire par une activité.
- l’architecte: Il s’occupe de la conception du bâtiment en termes de disposition des murs (disposition et taille des pièces), d’emplacements de fenêtres (luminosité), etc…, c’est-à-dire de dessiner le plan du bâtiment en ne considérant que les aspects volume, espace et luminosité des appartements.
- l’ingénieur-structure: Son activité consiste à spécifier les éléments structurels de l’appartement et à garantir la stabilité de la construction. De tels éléments (murs porteurs, poutres ou colonnes de soutènement,…) seront choisis de manière à respecter le plus possible l’harmonie et les choix de l’architecte.
- l’urbaniste: Il contrôle le plan produit par l’architecte et émet un avis sur son travail en fonction de critères d’intégration urbaine du bâtiment. L’architecte doit alors tenir compte de cet avis pour rédiger un nouveau plan acceptable, et accepté, par l’urbaniste.
Les différents échanges de données entre les partenaires ne sont toutefois pas soumis aux mêmes règles. S’il est souhaitable, dans certains cas, d’encourager une coopération maximale entre les partenaires, dans d’autres il peut être nécessaire de fixer certaines contraintes. C’est le cas par exemple de l’urbaniste et de l’architecte: ils se partagent certains documents, mais seulement en lecture, chacun ne pouvant modifier les documents de l’autre. Les règles de coopération négociées pour contrôler ces échanges de documents entre les différents partenaires sont:
- rédacteur/relecteur: L’urbaniste (le “relecteur”) lit, mais ne modifie pas, le plan qui lui est fourni par l’architecte (le “rédacteur”). Il rédige alors son avis qu’il transmet à l’architecte qui le lit, mais ne le modifie pas, pour mettre à jour son plan, et ainsi de suite.
- écriture coopérative: L’architecte et l’ingénieur-structure travaillent tous les deux à la rédaction du plan (même objet logique). Durant toute la durée de l’activité de conception ils le modifient, éventuellement simultanément, intégrent les modifications effectuées par l’un ou l’autre, dans le but de fournir au final une version de ce plan qui les satisfait tous les deux.
Déroulement de l’exemple
Voici le scénario de notre exemple représentant les différentes étapes de la coopération entre l’architecte, l’ingénieur-structure et l’urbaniste. Nous donnons ensuite une exécution pas à pas faisant apparaître l’évolution de l’interface graphique de chacun des partenaires tout au long de cet exemple.
D’un côté, l’architecte et l’ingénieur-structure partagent le document $plan$ en “écriture coopérative” (critère de correction DisCOO). De l’autre côté, l’architecte et l’urbaniste coopèrent via les documents $plan$ et $avis$ selon le mode “rédacteur/relecteur” (critère de correction DisCOO augmenté de quelques contraintes pour orienter les échanges).
-
L’architecte travaille sur le plan puis, à un moment donné, publie une nouvelle version. La publication est matérialisée par l’opération $write_{archi}[plan_{archi}]$.
-
L’ingénieur-structure importe cette nouvelle version pour mettre à jour sa propre copie du plan. Ce sont les opérations $read_{inge}[plan_{archi}]$ et $write_{inge}[plan_{inge}]$.
-
L’ingénieur-structure modifie sa copie du plan puis, à son tour, publie une nouvelle version. C’est l’opération $write_{inge}[plan_{inge}]$.
-
L’architecte synchronise sa copie du plan avec celle de l’ingénieur-structure en important la version du plan produite par l’ingénieur-structure. Ce sont les opérations $read_{archi}[plan_{inge}]$ et $write_{archi}[plan_{archi}]$.
-
L’architecte peut alors intégrer ses propres modifications à la copie du plan se trouvant dans sa base locale. C’est l’opération $write_{archi}[plan_{archi}]$.
-
Pendant ce temps, l’urbaniste a importé la version du plan disponible dans la base locale de l’architecte. Ce sont les opérations $read_{urba}[plan_{archi}]$ et $write_{urba}[plan_{urba}]$.
-
L’urbaniste peut ainsi commencer sa relecture et produire une première version de son avis. C’est l’opération $write_{urba}[avis_{urba}]$.
-
Lorsque l’urbaniste a connaissance d’une nouvelle version du plan chez l’architecte, il synchronise sa copie du plan. Ce sont les opérations $read_{urba}[plan_{archi}]$ et $write_{urba}[plan_{urba}]$.
-
Fort de cette nouvelle version, l’urbaniste met à jour son avis et en publie une nouvelle version. C’est l’opération $write_{urba}[avis_{urba}]$.
-
L’architecte importe alors dans sa base locale l’avis émis par l’urbaniste. Ce sont les opérations $read_{archi}[avis_{urba}]$ et $write_{archi}[avis_{archi}]$.
-
De son côté, l’ingénieur-structure a importé la nouvelle version du plan produite par l’architecte. Ce sont les opérations $read_{inge}[plan_{archi}]$ et $write_{inge}[plan_{inge}]$.
-
À cet instant, l’architecte peut demander la validation de son activité. Étant donné que la transaction $archi$ a interagi avec les transactions $inge$ et $urba$, les trois axiomes de la DisCOO-sérialisabilité devront être évalués par rapport à ces deux autres transactions.
