2.5.2.2 La coordination
Dans le cadre de notre SI hétérogène,
l'objectif est de pouvoir répondre à des buts communs et
transversaux aux différents blocs applicatifs, qui le constituent. Deux
modes de coordination sont envisageables : soit la planification est
collective et centralisée (elle repose alors sur un agent coordinateur),
soit elle est distribuée et répartie sur plusieurs
systèmes (où chaque agent construit son plan de solutions de
façon indépendante puis tente de le synchroniser avec ceux des
autres agents). En quelque sorte, ces agents nous renvoient au concept des
services WEB dont la modélisation peut être prise en charge par
OWL-S. Il fait partie d'un ensemble avec lequel il se trouve en interaction.
Chacun des agents joue un ou plusieurs rôles dans le système.
Chaque rôle accède à un certain nombre de méthodes
et chaque méthode fait appel à des opérations
conditionnées.
Illustration 87 : Diagramme
de classes de l'Agent, réalisé sous magicdraw
Quatre rôles distincts ont été
déterminés précédemment : la
préparation, la détection-transformation d'un message, la
transmission et la consommation d'un message. Le
« Fournisseur » prépare le message.
Le « Consommateur » est le nom
donné au système cible qui attend le message afin de
l'intégrer à son rythme dans son propre référentiel
de données.
L' « orchestrateur » exécute
un script d'exploitation basé sur la détection puis la
transformation (d'un contenu Oracle vers un format fichier CSV), suivie de la
transmission du fichier. Mais avant de proposer ce diagramme d'activité,
encore faut-il modéliser la communication actuelle.
2.5.2.3 La Modélisation de la
communication actuelle
Les deux diagrammes suivants (de communication et de classes)
représentent la structure spatiale de la communication actuelle. Ils
décrivent l'échange de fichiers entre un système dit
« le Fournisseur » et un autre, appelé
« le Consommateur ». Le premier diagramme (de
communication) est composé de :
q agent émetteur/ agent récepteur : dans la
réalité les agents prennent les deux rôles,
q agent superviseur : dans notre cas ce superviseur est
l'outil de coordination, notre orchestrateur OPEN PROCESS dont le comportement
est guidé par des scripts d'exploitation,
q agent observateur : il n'existe pas en tant que tel
aujourd'hui mais dans l'absolu il peut représenter toute personne (du
service exploitation ou autre) souhaitant être informée des
différentes étapes d'un fichier,
q objet de la communication : cela représente les
informations Tiers à transmettre au(x) consommateur(s),
q message : les messages échangés dans ce
processus sont des fichiers au format fixe Csv,
q code : le code utilisé ici représente la
structure de message échangé entre les deux partenaires. Le
format de message doit être connu des deux protagonistes,
q canal : le canal utilisé pour véhiculer le
message entre les deux partenaires, ici FTP RFC959,
q localisation : la localisation du message est l'emplacement
où est positionné le fichier.
Ainsi cet échange est orchestré par un outil de
planification. Ce dernier est appelé « Open
Process ». Il joue un rôle de
« superviseur » de façon
distribuée (en ce sens qu'il n'est pas localisé que sur le
système central, mais il est réparti sur l'ensemble des
systèmes protagonistes de cet échange). Il détecte
l'arrivée de nouveaux fichiers tiers au format Csv assimilables, dans la
représentation, à des messages. Les appels FTP
gérés par Open Process donnent au fournisseur et au consommateur
un rôle d'« émetteur » et de
« récepteur » d'informations.
L'agent récepteur dispose d'une boite à outils, puisqu'une fois
reçu, le message doit être transformé et
intégré. L' « observateur »
représente le technicien d'exploitation amené à
traiter manuellement des fichiers rejetés par le superviseur.
Illustration 88 : Diagramme
de communication, réalisé sous Magicdraw
Le diagramme de classe quant à lui présente la
structure du modèle actuel :
Illustration 89 : Diagramme
de classes, réalisé sous Magicdraw
Le premier constat est peut être l'aspect rigide de
cette communication (un seul canal, des règles de transformations non
intégrées au processus de communication, seule la dernière
version de code du message peut entrer dans le processus, des interventions
manuelles sont requises pour traiter les rejets etc...). Mais avant de
poursuivre davantage l'analyse des faiblesses, il faut présenter les
différentes vues afin de rendre lisible le SI, un peu à la
façon d'un urbaniste qui souhaiterait faire évoluer ou moderniser
tout ou partie d'un système d'information.
| 
