WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Réconciliation par consensus des mises à  jour des répliques partielles d'un document structuré.

( Télécharger le fichier original )
par Milliam Maxime Zekeng Ndadji
Université de Dschang - Master 2 2016
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

2.1.3. Une approche d'édition coopérative des documents structurés

Les documents structurés, peuvent être édités de manière coopérative par plusieurs co-auteurs. On peut imaginer plusieurs approches pour réaliser une telle édition. Nous décrivons ici l'approche qui est utilisée dans ce mémoire.

Initialement, le document t à éditer est dans un état précis (état initial) ; les différents co-auteurs qui sont situés sur des sites géographiques potentiellement éloignés, obtiennent une copie (une réplique) du document qu'ils éditeront localement. Pour des raisons de confidentialité (degré d'accréditation) un co-auteur (i) donné n'aura pas forcément accès à l'ensemble des symboles grammaticaux qui apparaissent dans l'arbre ; seul un sous-ensemble d'entre eux, d'un type donné, peut être jugé pertinent pour lui : c'est sa vue (v). La réplique qu'il devra donc éditer localement (sur son site) sera une partie du document initial : on parlera de réplique partielle et elle est notée tv. La réplique partielle sera obtenue par projection (x) du document initial en fonction de la vue du dit co-auteur (tv = xv(t)). Les co-auteurs éditeront alors de manière asynchrone les répliques partielles ; et les documents locaux obtenus seront appelés répliques partielles mises à jour

(tmaj

Vi ).

2.1. Documents structurés, conformité et édition 25

Mémoire - ZEKENG NDADJI Milliam Maxime LIFA

Nous nous intéressons uniquement à l'édition positive; les documents édités ne feront que grossir et le co-auteur ne pourra plus supprimer des parties du document une fois qu'une synchronisation aura été effectuée. Pour, à la fois, garantir cette propriété et pouvoir indiquer à un co-auteur l'endroit où il doit contribuer, les documents en cours d'édition seront représentés par des arbres contenant des bourgeons ou noeuds ouverts qui indiquent, dans un arbre, les seuls lieux où des éditions (mises à jour) sont possibles. Les bourgeons sont typés; un bourgeon de sorte X est un noeud feuille étiqueté X : il ne peut être édité (étendu en un sous-arbre) qu'en utilisant une X-production (production ayant

X en membre gauche). Ainsi donc, un document structuré en cours d'édition et ayant la grammaire G = (S,P,A) pour modèle est un arbre de dérivation pour la grammaire étendue Gç = (S,P uSç,A) obtenue de G en ajoutant à l'ensemble P des productions et pour tout sorte X S, une nouvelle E-production Xç : X --+ E ; Sç = {Xç : X --+ E, X S}. Les autres noeuds du document seront dit clos et le document sera clos si tous ses noeuds sont clos (s'il ne possède aucun bourgeon).

Lorsqu'un point de synchronisation4 sera atteint, on essayera de fusionner toutes les contributions tma j

Vi des différents co-auteurs pour obtenir un document global unique tf 5. Pour garantir que la fusion se fasse toujours sans conflits on peut:

1. Contrôler les éditions locales; pour cela on peut se servir d'une grammaire locale sur chaque site. Ces grammaires locales sont obtenues à partir de la grammaire globale (du document) et suivant les vues correspondantes. Un algorithme permettant d'obtenir de telles grammaires est proposé dans [TTTAD14];

2. Considérer l'hypothèse selon laquelle une catégorie syntaxique ne peut être éditée que par un co-auteur précis (hypothèse d'édition disjointe) : on évite ainsi les divergences et donc les conflits lors de la synchronisation. Lever cette hypothèse et gérer les conflits est l'objet principal du travail réalisé dans ce document (nous le faisons dans le chapitre 3) mais nous considérons cette hypothèse dans ce chapitre.

La figure 2.4 illustre grâce à un diagramme d'orchestration BPMN, cette approche d'édition coopérative comme procédure d'entreprise; sur le site 1 on réalise les opérations de (re)distribution et de fusion du document (global) conformément à un modèle G; sur les sites 2 et 3, on édite des répliques partielles conformément aux modèles G1 et G2 dérivés par projection du modèle global de documents G.

Toutes les opérations de synchronisation et de re-distribution peuvent être réalisées sur l'un des sites dédié à cet effet (comme sur le site 1 de la figure 2.4). Dans ce cas, le système est dit centralisé et le site de synchronisation est appelé le serveur central. On peut cependant envisager un système dans lequel les synchronisations se feront en pair à pair et sur n'importe quel site d'édition; les synchronisations n'impliqueront donc plus forcément les contributions de tous les co-auteurs. Une telle approche s'adapte mieux aux procédures d'entreprise et au fait que le document soit le support de coopération dans ces procédures. Les idées maîtresses pour la mise sur pied d'un éditeur coopératif en pair à pair sont, en ce moment, élaborées et étudiées au Laboratoire d'Informatique Fondamentale et Appliquée (LIFA) par TCHOUPÉ T. Maurice et ses collaborateurs.

Dans les sections qui vont suivre, nous allons définir formellement en accord avec [BTT08, BTT07, TT09] tous les concepts qui ont été brièvement décrits ici.

4. Un point de synchronisation peut être défini statiquement ou déclenché par un co-auteur dès que certaines propriétés sont satisfaites.

5. Il peut arriver que l'édition doive être poursuivie après la fusion (c'est le cas s'il existe encore des bourgeons dans le document fusionné) : on doit redistribuer à chacun des n co-auteurs une réplique (partielle) tVi de tf telle que tVi = ðVi(tf) pour la poursuite du processus d'édition.

2.2. Vues, projection et répliques partielles 26

Mémoire - ZEKENG NDADJI Milliam Maxime LIFA

FIGURE 2.4 - Un diagramme d'orchestration BPMN pour le processus d'édition coopérative désynchronisée.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Piètre disciple, qui ne surpasse pas son maitre !"   Léonard de Vinci