Exécution pas à pas
Préliminaires
Chaque acteur utilise le prototype DisCOO au travers d’une interface standard en français ou en anglais telle que celles-ci:
Nous allons dérouler l’exemple en nous plaçant du point de vue de l’architecte. Les autres acteurs travaillent de leur côté mais nous ne verrons leurs actions que par leurs effets (notifications,…) sur l’architecte. Par exemple, l’écran suivant montre les notifications de création des activités structure (i.e. ingénieur-structure) et urbaniste. Les notifications sont empilées, c’est-à-dire que la plus récente (indiquée par le symbole -->) est celle figurant en haut de la pile des notifications.
L’architecte crée le document $plan$ (version 0). Ce document est créé dans son propre espace de coopération.
Afin de pouvoir partager le document plan avec l’architecte, l’ingénieur-structure doit tout d’abord négocier un schéma de coopération. Dans le cas présent, il s’agit du schéma “Ecriture Coopérative”.
L’architecte accepte ce schéma de coopération pour partager le document $plan$ avec l’ingénieur-structure.
L’urbaniste crée alors le document $avis$ dans son propre espace de coopération.
Afin de pouvoir partager le document $plan$ avec l’architecte, l’urbaniste doit tout d’abord négocier un schéma de coopération. Dans le cas présent, il s’agit du schéma “Rédacteur/Relecteur”.
L’architecte accepte ce schéma de coopération pour partager les documents $plan$ et $avis$ avec l’urbaniste.
Étape n°1
Afin de pouvoir travailler sur le document $plan$, l’architecte le transfère de son espace de coopération vers son espace de travail (opération checkout). Il peut ainsi le modifier à l’aide de ses applications habituelles.
Lorsque l’architecte désire publier ses modifications, il transfère le $plan$ de son espace de travail vers son espace de coopération (opération checkin). Cette action a pour effet de créer une nouvelle version du document $plan$ dans son espace de coopération (version 1). Celle-ci est alors visible aux autres acteurs.
Étape n°2
L’ingénieur-structure importe le document $plan$ depuis l’espace de coopération de l’architecte.
Étape n°3
Quand l’ingénieur-structure publie une nouvelle version du $plan$ dans son espace de coopération, elle devient visible pour l’architecte. En outre, étant donné que l’architecte partage ce document avec l’ingénieur-structure, il en est informé par une notification.
Étape n°4
L’architecte importe depuis l’ingénieur-structure la dernière version en date du document $plan$.
Étape n°5
L’architecte transfère cette nouvelle version du $plan$ dans son espace de travail (chekout) afin de pouvoir l’utiliser avec ses outils existants.
L’architecte apporte de nouvelles modifications puis publie sa nouvelle version dans son espace de coopération (checkin).
Étape n°6
Pendant ce temps, l’urbaniste a importé le document $plan$ depuis l’espace de coopération de l’architecte.
Étape n°7
Quand l’urbaniste publie une nouvelle version du document $avis$ dans son espace de coopération, une notification est envoyée à l’architecte puisque celui-ci partage ce document avec l’urbaniste.
Étape n°8
Lorsque l’urbaniste est notifié de la nouvelle version du $plan$ publiée par l’architecte à lors de l’étape n°5, il décide de l’importer.
Étape n°9
De nouveau, l’architecte est notifié de la publication par l’urbaniste d’une nouvelle version du document $avis$.
Étape n°10
Afin de prendre en compte l’$avis$ émis par l’urbaniste, l’architecte importe le document $avis$ depuis l’espace de coopération de l’urbaniste.
Étape n°11
Lorsque l’ingénieur-structure est notifié de la nouvelle version du $plan$ publiée par l’architecte à lors de l’étape n°5, il décide de l’importer.
Étape n°12
À 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.