Dans cette page nous étudions la structure de l'implémentation de Pavot. Le langage utilisé est Java qui offre tous les avantages des langages objets (réutilisabilité, polymorphismes...) et de bonnes bibliothèques d'interfaçage.
Architecture
 |
Comme on peut le voir sur ce schéma simplifié, Pavot ("connection part") a été conçu comme un composant intermédiaire entre des solveurs ("solvers part") et des viewers ("viewers part"). En théorie les entrées et sorties peuvent être totalement hétérogénes. C'est le cas pour les solveurs qui n'ont comme contrainte que de sortir une trace XML respectant la DTD OADymPPaC. Par contre, dans la pratique, les visualiseurs en sortie sont intégrés directement dans Pavot. Ceci est du essentiellement à un manque de protocole de visualisation (par exemple on aimerait envoyer en sortie un arbre de recherche, un tableau de données ... interprétable par un maximum d'outil de visualisation). Le connecteur se charge de relier toutes les parties entre elles ainsi que de gérer les différentes requêtes de l'utilisateur. Dans l'état d'avancement actuel le pilotage de la trace à partir des visualiseurs n'est pas possible, ceci en raison du faible avancement à ce sujet du projet OADymPPaC.
| [Partie connection] | [Solver manager (In)] | [Viewer Manager (Out)] | [Requêtes] |
Partie connection
Architecture de Pavot: les flèches numérotées donnent l'ordre d'instanciation de chaque entité, certaines ne pouvant être instanciées avant d'autres ("view manager" a besoin de "data struct" par exemple). 
Le connecteur est l'architecture principale permettant de relier les différentes entités, chaque entité étant déconnectée le plus possible des autres afin de faciliter au maximum les extensions futures. Il est apparu important entre autre de bien séparer la partie structure de données (arbre de recherche, de propagation, tableau contraintes/contraintes, variables/valeurs...) de la partie visualisation. La structure de donnée est branchée aux différents événements du solveur qui lui donnent les informations nécessaire pour sa construction. On peut ainsi avoir plusieurs arbres avec des sémantiques différentes, un arbre de recherche classique(?), un arbre de propagation (à chaque noeud on a l'information sur le nombre de propagation avec raffinement plus ou moins grand) ou encore un arbre prolog (?). Selon les vues et le niveau d'information demandés on instanciera uniquement les structures de données nécessaires et une même structure peut être utilisée par différents visualiseurs, ce qui permet d'économiser de l'espace-temps.
Voir : [Structure de données]-[Requêtes]
La partie interface utilisateur permet de spécifier les vues et le filtrage désirés, et de se connecter à une sortie de trace d'un solveur ou de charger un fichier, elle n'intervient que dans la phase d'initialisation.
Solver manager
Le solver manager est basé essentiellement sur le travail de Jean-Daniel Fekete et Mohamad Ghoniem. Il est constitué d'un parser XML (SAX) et d'un générateur d'événements simulant le fonctionnement d'un solveur. Ceci permet d'avoir à la fois un filtrage de la trace et une restructuration des données reçues sous la forme de "méta-événements" (les différents événements propagation sont réunis en un seul par exemple).
Schéma partiel du solver manager 
Pavot est capable de se connecter à une socket émettant la trace XML ou de lire la trace directement dans un fichier (*.xml ou *.xml.gz).
Viewer manager
Schéma du viewer manager 
Le viewer manager enregistre les différents viewers demandés dans une liste. Chacun des viewers est connecté aux différentes structures de données nécessaires à leur affichage.Requêtes de filtrage