L’environnement CoDISS

L’observation des diff´erents objets interm´ediaires qui prennent vie dans une ac-tion de concepac-tion permet [Jea98] :

– de rep´erer la singularit´e de cette conception, `a travers le contenu que les objets interm´ediaires rendent visibles,

– de suivre l’avanc´ee de la conception, de rep´erer les diff´erents acteurs et leurs modalit´es de participation au projet, les moments d’ouverture, de n´egociation, d’incertitude, ou au contraire de clˆoture, de d´ecision, et de cr´eation d’irr´ ever-sibilit´es, et les points sur lesquels portent ces moments.

Suite `a ses ´etudes Jeantet propose trois types de caract´eristiques des objets interm´ e-diaires :la m´ediation, la traduction et la repr´esentation [JB98]. En d’autres termes, les objets permettent aux concepteurs d’agir ensemble. Ils permettent ´egalement d’effectuer la transition d’un ´etat du produit `a un autre. Pour terminer, ils repr´ e-sentent le produit ou une partie de celui-ci. En ce sens, toute repr´esentation n’est pas objet interm´ediaire. Elle ne l’est que si elle engage des interactions `a son sujet. C’est dans l’action de sa construction, pour un groupe donn´e, qu’une repr´esentation prend le statut d’objet interm´ediaire.

Les objets interm´ediaires peuvent ´egalement ˆetre caract´eris´es sur un axe “ouvert-ferm´e”, en relation avec l’organisation dans laquelle ils jouent un rˆole [MJT95]. Un objet qualifi´e d’ouvert laisse `a l’utilisateur une marge de manoeuvre au sein de la-quelle il peut plus ou moins diverger. Il incite `a une interpr´etation qui peut se concr´ e-tiser par des amendements ou des corrections. Il suscite les variantes. Exemple : une esquisse, un sch´ema. Un objet qualifi´e de ferm´e tend `a faire disparaˆıtre la marge de manœuvre de l’utilisateur. S’il engage l’interaction, il n’invite pas `a la modification. Il est irr´eversible (ou sa modification est tr`es coˆuteuse) et transmet une prescription. Exemple : un dessin d’ensemble d’un produit.

3.5 L’environnement CoDISS

L’environnement CoDISS est inspir´e des travaux sur les objets interm´ediaires [Mer98] [Bla98] [Lau00], qui ont mis en ´evidence l’importance de cette notion dans l’´etude de la coop´eration des concepteurs et de leurs activit´es, dans un processus de conception collaborative.

L’environnement CoDISS est un syst`eme qui permet aux diff´erents acteurs d’un processus de conception de travailler en collaboration autour d’objets interm´ediaires qu’ils auront ´etablis ensemble, apr`es un certain nombre d’´echanges informels, tout en leur permettant d’utiliser leurs logiciels m´etiers [RDG⁺02]. Travailler en colla-boration veut dire ´echanger des donn´ees ou des objets, autour desquels les acteurs vont discuter et r´egler un certain nombre de probl`emes qui peuvent apparaˆıtre dans

Fig.^{3.2: Sch´ema global de l’architecture de CoDISS}

le cycle de vie d’un produit ou simplement au cours de la conception de ce dernier. En plus, l’environnement CoDISS devra contenir les diff´erents moyens de communi-cation standards utilis´es sur le Web comme la vid´eo conf´erence, le chat, les forums et le mailing, pour permettre justement les ´echanges informels entre les diff´erents concepteurs.

L’environnement collaboratif CoDISS a une architecture Client-Serveur (voir fi-gure 3.2). Dans cette version, les outils de communication et d’´echange informel ne sont pas encore int´egr´es dans l’environnement. N´eanmoins, plusieurs am´ eliora-tions lui ont ´et´e apport´ees suite aux propositions que nous avons faites au cours de notre travail [MMR04]. Nous allons voir en d´etail ces modifications dans la suite du chapitre.

Avant de commencer `a expliquer le fonctionnement de CoDISS, on suppose que l’on se trouve dans un contexte o`u les acteurs du processus de conception se sont mis d’accord sur les donn´ees `a partager, parce que celles-ci leurs posaient des probl`emes concernant leurs contraintes m´etiers. A partir de l`a, on se basera sur les figures 3.3 et 3.4 qui nous montrent deux exemples de cas d’usage de l’environnement CoDISS. Maintenant, nous allons voir en d´etail les deux diagrammes de s´equences, pour com-prendre le fonctionnement du syst`eme.

3.5. L’environnement CoDISS

Acteur Logiciel métier Plug-in Vue Privée CoDISS Vue Publique CoDISS (image du serveur) get get set set set Trans

Fig.3.3: Diagramme de s´equence du cas d’usage n˚1

Acteur Logiciel métier Plug-in Vue Privée CoDISS Vue Publique CoDISS (image du serveur) get set Trans set set

travers l’utilisation d’un greffon (plug-in) sp´ecifique `a son application. Cette donn´ee est transmise directement au client CoDISS, dans une vue priv´ee. `A partir de l`a, il y a plusieurs possiblit´es de partager cette donn´ee, que l’on peut enrichir dans la vue priv´ee, comme on va le voir par la suite, vers la partie publique qui correspond `a l’espace partag´e par tous les utilisateurs de CoDISS, et qui appartiennent au mˆeme projet.

Dans la figure 3.4, l’utilisateur r´ecup`ere une donn´ee de l’espace partag´e en utili-sant la vue publique, qui correspond au contenu du serveur. Il y a deux possiblit´es pour r´ecup`erer une donn´ee du serveur. Dans le premier cas, il transf`ere la donn´ee directement vers sa vue priv´ee. Dans le deuxi`eme cas, il peut lui appliquer des re-lations avec d’autres donn´ees en utilisant le module de traduction, pour cr´eer une nouvelle donn´ee sur sa vue priv´ee. Apr`es, l’utilisateur pourra appliquer la donn´ee qui se trouve dans sa vue priv´ee dans son logiciel m´etier, en utilisant le greffon (plug-in) sp´ecifique.

Au final, on peut imaginer que, dans une situation de travail collaboratif, les utilisateurs vont avoir besoin de faire une succession de ces deux cas d’usage, pour connecter dynamiquement les donn´ees de leurs logiciels m´etiers respectifs. La chose importante sur laquelle on n’a pas trop insist´e jusqu’`a pr´esent est le fait de pouvoir enrichir ces donn´ees partag´ees avec des informations qui permettraient une utilisa-tion et une exploitautilisa-tion plus ais´ees (par exemple : des informations sur l’´etat de l’information “valeur initiale, en cour de modification, valeur fix´ee”). Et pour garder une coh´erence des donn´ees ´echang´ees on propose un petit moteur de notification. Ce dernier n’a pas pour objectif de r´esoudre les conflits au sein de l’application, mais plus d’informer les utilisateurs des conflits qui pourraient exister afin qu’ils les r´esolvent d’une mani`ere concert´ee.

On peut voir l’IHM client CoDISS dans la figure 3.5. Etant donn´e que cette application doit fonctionner sur tous les postes des utilisateurs, et que ces derniers peuvent travailler sur des plates-formes diff´erentes (windows, unix...), on a choisi d’utiliser le langage Java pour mettre en œuvre cette application, on a aussi utilis´e le format XML pour les fichiers de donn´ees ´echang´ees.