ARIS2 vise (nous a promis) un système
dit "distribué" ou en ces termes : "multi-producteurs".
ARIS2 vise également (nous a également
promis) un modèle conceptuel orienté
objet, favorisant la réutilisation.
Malheureusement il s'avère que ces deux aspects sont
difficiles à concilier.
Pour l'heure, nous ne parlons même pas encore de l'aspect "multi-producteurs", justement, mais simplement du travail en parallèle sur plusieurs BDAs, au sein d'une même équipe travaillant un même système ARIS, une même base de données, BDC (faisant encore office de BDP pour l'instant).
Pour travailler sur plusieurs BDA en parallèle, vous devez actuellement faire attention à ces quelques points :
Chaque ordinateur possède une horloge (date et heure).
En général, il est déjà intéressant
que cette horloge soit relativement bien réglée
afin que les dates de création et dates de modification
de vos fichiers soient les plus correctes possible.
Ici, nous parlons d'un système distribué,
ARIS2, avec des informations manipulées sur plusieurs
ordinateurs. On parle alors d'un réseau. Et il est
alors impératif que tous les ordinateurs aient la
même date et heure, que leurs horloges soit réglées
à la même date et heure.
Nous n'avons pas encore déterminé à
quel point le système est sensible à une désynchronisation,
en d'autres termes : quelles sont les limites à ne
pas dépasser !
Néanmoins, nous pouvons vous dire que la date et
l'heure de création des BDA
et des versions servent à détecter des erreurs
humaines et également à vous afficher les
informations les plus récentes.
Considérant la plus grande différence observable,
je dirais que :
Vous pourriez choisir "arbitrairement" l'un d'entre-vous
comme référence et faire le tour de vos ordinateurs,
mais le problème ne sera pas vraiment réglé,
notamment par rapport au monde extérieur.
C'est pourquoi nous conseillons plus que vivement l'utilisation
d'un programme de synchronisation à partir d'un serveur
de temps sur internet.
Il existe plusieurs programmes, mais tous utilisent le même
protocole (mécanisme, système). Indépendamment
du programme utilisé, il existe plusieurs serveurs
de temps sur internet. Ces serveurs ne répondent
pas toujours mais ils indiquent tous la même date
et heure en théorie. En pratique, j'ai personnellement
cru déceler une différence de 5 secondes.
Voici quelques adresses web (à discuter avec votre administrateur système) :
Dernière remarque, Windows XP est le premier système d'exploitation Microsoft intégrant un tel programme de synchronisation.
Travailler en parallèle sur le même objet est un vrai problème car à l'arrivée, il faut choisir !
ARIS2 System Manager vous aide à l'arrivée,
en comparant la date de chaque proposition de nouvelles
versions d'objets existants de votre BDA,
avec la date des dernières versions respectives se
trouvant dans le BDC.
Voici un petit exemple de cas de figure :
2002-02-24, à 17h43, remonte la dernière modification
du système, au sein du BDC.
2002-02-25, à 10h20, Billy crée un nouveau
BDA.
2002-02-25, à 11h02, John crée, lui aussi,
un nouveau BDA.
2002-02-25, à 11h12, Billy termine sa mise à
jour d'un objet ARIS.
2002-02-25, à 11h13, Billy enregistre une dernière
fois ses opérations.
2002-02-25, à 12h14, John termine lui aussi, sa mise
à jour du même objet !
2002-02-25, à 12h15, John enregistre, confiant, ses
dernières opérations.
2002-02-25, à 12h30, C'est Billy qui, le premier,
applique son BDA
et crée ainsi une version existante, copie conforme
de sa proposition.
2002-02-25, vers 12h35, John veut appliquer son BDA,
sans savoir que Billy travaillait sur le même objet
que lui. ARIS2 System Manager lui présente un bouton
grisé, inerte. John vérifie les dates et il
comprend. La date de création de son BDA, 2002-02-25@11h02,
est plus ancienne que la date de la dernière version
de l'objet, celle créée par Billy il y a juste
quelques minutes. Et même si John cochait la case
"Ne pas se baser sur la date de création
du BDA", c'est la date de sa proposition qui compterait.
Et cette date aussi est plus ancienne. Bien sûr, si
il apportait encore quelques modifications à sa proposition,
la date serait mise à jour et il pourrait appliquer
en ne cochant que la case "Ne pas se baser sur la
date de création du BDA" mais il détruirait
ainsi le travail de Billy !
Bon, vous voyez maintenant, j'espère, le genre de
situation dramatique dans laquelle vous pouvez vous trouver
si vous ne faites pas bien attention.
Mais plutôt que de "faire attention", nous
vous conseillons réellement de vous organiser, de
sorte que jamais, au grand jamais, vous ne soyez amenés
à travailler en parallèle sur de mêmes
objets !
Le problème est particulièrement apparent
et pertinent en ce qui concerne les objets de type "Table
de matières".
En effet, contrairement aux mots-clés, la propriété
constituant le lien qui peut exister entre cette table de
matières et un objet recherché (variable,
source ou document), cette propriété donc,
appartient à l'objet table de matière. Ainsi,
il pourrait être demandé aux personnes s'occupant
de mettre à jour les différentes variables,
de les rattacher à telle et/ou telle rubrique de
telle et/ou telle table de matières. Cette démarche
mènerait à un cuisant échec si, effectivement,
ces différentes personnes, chacune de leur côté
mettait à jour la (ou les) table(s) de matières,
sans se soucier de ce que font (ont à faire) les
autres.
La solution est de définir un responsable (personne
ou entité organisée) pour chaque table de
matières.
Il est un problème pour lequel il est beaucoup plus
difficile de vous aider, de vous encadrer par quelques algorithmes
et mécanismes complexes au sein de nos programmes.
C'est le maintien de la cohérence des liens entre
les différents objets de votre système au
travers de leurs évolutions (mises à jour).
Par exemple, il vous est possible de modifier le libellé d'un objet. Un bon exemple est l'ajout d'un 's' (pluriel) au libellé d'un critère : "Année" devenant "Années" ou encore "Zone géographique" devenant "Zones géographiques".
Mais un très mauvais exemple, et c'est ici le problème,
c'est que rien ne vous empêche, techniquement, de
changer le libellé "Années" en "Zones
géographiques" !
En fait, vous changez là, la sémantique de
l'objet et non seulement le libellé.
Ce cas de figure est simple, mais les problèmes de
sémantique sont souvent plus subtils et/ou perfides.
Ce qui semble être une évidence pour les uns
peut paraître une erreur pour les autres et un réel
conflit d'intérêt au sens large du terme !
Pour éviter au mieux ce genre de problèmes, nous vous conseillons de bien former toute personne travaillant sur votre système ARIS. Vous avez pour cela, à votre disposition sur notre site web, des documents concernant les concepts de ARIS2 qu'il est impératif de bien maîtriser. Vaguement comprendre le topo n'est qu'un début, encourageant certes, mais insuffisant et pouvant entraîner des erreurs dommageables.
Egalement importante, la communication entre toutes
les personnes concernées par votre système
ARIS.
Pour travailler en parallèle, nous vous conseillons
vivement l'utilisation
de BDAs !
D'ailleurs, nous ne parlerons qu'à travers cette
méthode ici.
A ce propos, nous vous conseillons de travailler sur de
petits BDAs
(peu d'objets concernés) et de les appliquer "rapidement".
Premièrement, vous devez activer l'option "Rafraîchir
infos conteneurs." Via la
fenêtre "Configuration de ARIS2 System Manager"
de configuration de l'application disponible dans le menu
"Informations". Ainsi, périodiquement,
System Manager va vérifier la date de modification
du BDC et rafraîchir
les informations (nouvelles versions), le cas échéant.
Remarque : depuis peu, cette option est (2002-05-08) ) automatiquement
et obligatoirement activée.
Dans la fenêtre "Appliquer BDA sur BDC ...",
vous devrez fréquemment cocher la case "Accepter
la concurence de BDAs (travail en parallèle)",
ce qui, du fait que vous travaillez en parallèle,
ne constitue pas un problème.
Voyez à ce sujet les explications
suivantes... (méthodes de travail : appliquer le
BDA de travail)