Laboratoire dInformatique Appliquée IUT Informatique de Bayonne Ré-Ingénierie dApplications pour la mise en oeuvre de la Coopération : Méthodologie et

Laboratoire d’Informatique AppliquéeIUT Informatique de Bayonne

Ré-Ingénierie d’Applications pour la Ré-Ingénierie d’Applications pour la mise en oeuvre de la Coopérationmise en oeuvre de la Coopération : : Méthodologie et ArchitectureMéthodologie et Architecture

ELKAR - Soutenance de Thèse - Roose Philippe - 2000

2

Objectifs

Nous proposons une méthode et une architecture Nous proposons une méthode et une architecture pour permettre la ré-ingénierie d ’applications pour permettre la ré-ingénierie d ’applications

basées sur des modules opératifs distribués afin basées sur des modules opératifs distribués afin de les organiser en groupes de travail et de les organiser en groupes de travail et

permettre une mise en coopérationpermettre une mise en coopération

En fait nous voulons ajouter la coopération dans En fait nous voulons ajouter la coopération dans des applications qui ne sont pas coopératives et des applications qui ne sont pas coopératives et

ceci sans modifier l’implémentation des ceci sans modifier l’implémentation des modules.modules.


3

Travaux connexes Nous travaillons à la croisée de plusieurs domaines de

recherche :– Les Bases de Données Actives

• avec leurs règles ÉCA

– Les Applications Distribuées • Avec des événements distribués

– La Modélisation avec des éléments de coopération• Nous modélisons des événements, des messages et des

données

– Le travail Coopératif• avec la notion de groupes de travail• avec la notion de dynamique.


4

Plan

Comment réaliser la coopérationComment réaliser la coopération

Élements de CoopérationÉlements de Coopération

La MéthodeLa Méthode

Le Langage de SpécificationsLe Langage de Spécifications

L’Architecture CoopérativeL’Architecture Coopérative

RésultatsRésultats

BibliographieBibliographie

Le FuturLe Futur


5

Les coopérations actuellesPourquoi : parce que la plupart du temps, la coopération est réalisée à l’aide d’opérateurs externes ou de programmes dédiés, nous voulons automatiser ceci.


6

Automatisation de la coopérationComment : nous automatisons la circulation des informations. Nous les capturons lorsqu’elles sont produites par le module dans son environnement et nous les incorporons dans l ’environnement du module destinataire. Nous créons les éléments de coopération manquants à partir des informations déjà existantes.


7

Comment réaliser la coopération (1) Des applications composées de modules

distribués opératoires Il existe un besoin de coopération exprimé par

les sociétésSite A Site B Site C

M1

M2

M3

M4 M8

M6

M7

M9 M10 M5

M11 M12

Réseau

Groupe deTravail #1

Groupe deTravail #2

Groupe de Travail #3


8

Comment réaliser la coopération (2) La coopération entre modules est généralement fournie

à l’aide d’opérateurs externes (humains, programmes dédiés, …)

Ceci est synonyme de :

– Perte et duplication d’informations

– Perte de temps (certains travaux sont réalisés plusieurs fois comme des ré-entrées par exemple).

Notre objectif est de réaliser la coopération par capture d’élément de l’activité sans modifier les modules.

Nous faisons circuler l’information et créons les éléments manquants.


9

Le Module

Module

C ’est une entité opératoire, éventuellement complexe, qui peut réaliser une tâche et communiquer avec l ’extérieur.

ME

S

E nv iro nm e nt

E S

M : M o d u leE : E ntré eS : S o rtie


10

Coopération Externe(Applications Actuelles)

C o o pé ra tio n E xte rne

M o dul e

E nviro ne m e nt

M o d u le

E nviro ne m e nt

S E ES

E : E ntré eS : S o rtie


11

Réalisation de la Coopération(Application mise à jour)

•Nous capturons l’information à sa source.• Nous fournissons cette information aux entités concernées.• Nous intervenons sur l’IHM des modules pour modifier leur comportement.

C ou ch e C oop érativ e

M o d u le

E nviro ne m e nt

M o d u le

E nviro ne m e nt

S

E

S

E


12

Groupes de Travail Dynamiques (1) Définition

C’est un ensemble de modules éventuellement distants sur un réseau et réalisant un ou plusieurs tâches bien déterminées.

Leur composition (modules composants le groupe de travail) peut évoluer dynamiquement dans le temps pour s’adapter ux besoins du système et ainsi répondre de la manière la plus satisfaisante possible (critères temporels et qualitatifs).

Gestion

La composition du groupe est réalisée par la couche coopérative.


13

Groupes de Travail Dynamiques (2)

M o du le

E nv iro ne m e nt

S

E

M o d ule

S

E

M o d ule

E nv iro ne m e nt

S

E

E nv iro ne m e nt

E S

S

E

M o d ule

E nv iro ne m e nt

S

E

M o d ule

E nv iro ne m e nt

S

E

G ro u p e d e Trava il # 1 G ro u p e d e Trava il # 2

C o u ch e C o o p é ra tive ave c ges tio n d es g ro u p es d e trava il

E /S

• Nous pouvons maintenant obtenir des informations de groupes qui sont plus expressives et qui reflètent plus l ’état de l’application.


14

Avantages de la Dynamique des Groupes de Travail

Les groupes de travail dynamiques permettent de :

Filtrer les informations. Le module ne reçoivent que les informations nécessaires à leur activité courante. Nous essayons ainsi d’éviter que trop d’informations soient reçues par un module à un mauvais moment.

Création d’informations synthétiques. En capturant l’information produite par certains modules d’un groupe de travail, il est possible d’en créer de nouvelles qui reflètent mieux l’activité du groupe de travail et non plus uniquement l’état d’un seul module.

La spécialisation de modules. En modifiant les informations reçues, en filtrant celles envoyées, ou en faisant réagir l’opérateur sur l’IHM, il est possible de modifier le rôle d’un module


15

Plan








Le FuturLe Futur


16

Eléments de Coopération Événements

– La sémantique est contenue dans leur propre occurrence.

– Ce sont des informations non-persistantes. Messages

– La sémantique est encapsulée dans le message.– Ce sont des informations non-persistantes.

Données du Système d ’Information– Ce sont des informations persistantes.


17

Plan








Le FuturLe Futur


18

La méthode (1)

Définition des groupes de travail

R écep tionE xp éd itionN ation a le

S erv iceC om m ercia l

E xp éd itionR ég ion a le

L og istiq u e


19

La méthode (2) Identification des éléments de coopération

(événements, messages, données).

R écep tionE xp éd itio nN a tion a le

S erv iceC o m m ercia l

E 4 N

E 1

E 4 R

E 3 N

E 3 R E xp éd itio nR ég ion a le

E P N

E P R


20

La méthode (3) Inventaire des modules présents dans le système. Pour chaque groupe, nous réalisons une liste

de membres potentiels.

E xp é d itio n N a tio na le

IH M 1 IH M 3

IH M 2


21

La méthode (4) Identification des éléments de coopération (événements,

messages, données) nécessaires et produits par chaque module.

N a tio n a l S h ip m e n t

I H M 1

I H M 2

I H M 3

E c e '

E c e '

E c e '

E pa

E pa

E paE C

E C

E C


22

La méthode (5) Les conditions d ’E/S dans un groupe de travail

dynamique pour une règle sont évaluées par une règle ÉCA (règle de gestion de groupe).

S’il n ’existe pas d ’information produite suffisamment précise, il sera nécessaire de la créer.

R G 1

E P N

E 3 N

E P R

E 3 R

E pa


23

La méthode (6) Liens directs entre informations

– groupe groupe– module module– module groupe– groupe règle de gestion de groupe– module règle de gestion de groupe

…avec l ’utilisation de règles de mise en forme concernant les messages.

R ecep tio nN a tio n a l

S h ip m en t

E 4 N

E 4 R

E 3 N

E 3 R R eg io n a lS h ip m en t


24

La méthode (7)

Création des éléments manquants Utilisation des règles :

– Événements Composés– Messages Synthétiques– Données de Groupe

Synthétiques

Retour en arrière

possible

R é c e ptio n

S e rvic eC o m m e rc ia l

E 4 N

E 1

E 4 R

R D 1


25

La méthode (8)

La méthode permet d’obtenir un ensemble de règles permettant de :– Transformer et diffuser l’information.– Détecter les événements, messages et données et de réagir en

fonction de leur sémantique (création d’éléments manquants, mise à jour d’IHM).

– Gérer la dynamique des groupes. La méthode termine avec la production d’un langage de spécification. Il permet sa dérivation en règles (en Java) avec lesquelles des rendez-

vous seront pris. L ’homogénéité de la méthode est permise grâce à l’uniformisation de la

méthode : l’analyse aux deux niveaux d’abstraction - inter et intra groupes - est identique.


26

Plan








Le FuturLe Futur


27

Le langage de spécification

Quelques exemples de primitives du langage de spécification : DéfinirÉvénement <nomÉvénement> [De origine] [Pour destination] DéfinirRègle <nomRègle> Comme <Modèle d’Activité> Déclencher <nomRègle> Quand <nomÉvénement> Envoyer <nomÉvénement>

Pourquoi un langage de specification ?

• Afin de faciliter la dérivation et donc l’implémentation.

• De vérifier formellement la validation des liens.


28

Points forts de notre méthode Elle est :

– Particulièrement adaptée à la ré-ingénierie.– Fonctionne à la fois avec des modules

logiques et physiques.– Associée à un langage de spécification

permettant une vérification formelle et une dérivation en règles.

– Homogène (représentation, règles)


29

Plan








Le FuturLe Futur


30

L’architecture Coopérative C ’est une extension d ’ADACTIF à :

– La distribution,

– La gestion des groupes de travail dynamiques,

– Aux différents éléments de coopération,

– Différents types dinformation (événements, messages & données)

Le langage de spécification permet d ’être facilement et automatiquement dérivé en règles détectrices (création d ’éléments de coopération) et ÉCA (gestion des groupes dynamiques).


31

L’Architecture Coopérative (sites)

S ite 1

G C

S ite 2

G C

S ite 1

G C

S ite n

G C

R és eau


32

L’Architecture Coopérative (sur chaque site)

G C

G É C

G R

RR

évén

emen

ts , m

essa

ges

événem en ts

évén

emen

ts, m

essa

ges événem

en ts , messages

Ren

dez -

vou s

événemen ts , m

essages

R 1

B D -G C

ré su lta t/req u ê te s

a ge

G M 1

M 1

G M 1

M 1

G M 1

BAL

mes

sag e

s

ré su lta t/re q u ê tem ise à jo u r

S ite B

S ite A

évén

emen

ts

mes

sages

requête/résultats

S ite C


33

Plan








Le FuturLe Futur


34

Résultats (1) - L’ Architecture Coopérative Extension d ’une architecture locale active

(ADACTIF) une architecture distribuée et adaptée au travail coopératif (ELKAR)– Groupes de Travail Dynamiques, – Types d ’Informations Différents (événements,

messages, données)

– Règles implémentées en tâches Java avec la notion de rendez-vous.

Un langage de spécification formel permettant de facilement dériver les résultats de la méthodes en règles ÉCA et détectrices.


35

Résultats (2) - La méthode La méthode

– Coopérative– Particulièrement adaptée à la ré-ingénierie– Fonctionne indifféremment avec des

modules physiques et/ou logiciels.– Associée à un langage de spécification afin

de réaliser les vérifications nécessaires et de facilement implémenter les résultats.

– Homogène


36

Résultats (3)Nous avons une approche globale démarrant avec une méthode et terminant avec l’implémentation, le tout avec

une totale homogénéité.

Méthode

Language de Specification

Règles

Architecture Coopérative Distribuée

(Java)}


37

Plan








Le FuturLe Futur


38

Bibliographie (1)Publications Internationales avec Comité de Lecture

“ Supporting Collaborative Work in Intranet Using an Active DBMS implemented with Java ” - Proc. WebNet'97 - Toronto - Canada - Novembre 1997.

“ Using Active Database Mechanisms to Build Cooperative Applications ” - Proc. Integrated Design on Process Technology (IDPT) 98 - Berlin - Allemagne - Juillet 1998.

“ Mechanisms for Synchronous and Asynchronous Communication in Distributed Cooperative Work ” – Proc. 6th Int’l Conference on Information Systems Methodologies (ISM) 98 – Salford – Angleterre – Springer Edition – ISBN 1-85233-079-1 - Septembre 1998.

“ How to achieve synchronous and asynchronous communication in distributed cooperative systems using ECA mechanisms ” - Simposio Español de Informatica Distribuida (SEID) 99 – Santiago de Compostela – Espagne – Février 1999.


39

Bibliographie (2)Publications Internationales avec Comité de Lecture

“ Using Active Database Mechanisms to Build Cooperative Applications ” – Transaction of the SDPS Journal – Vol. 3, N° 1 – pp. 1-14 - Mars 1999.

“ A method for designing cooperative distributed applications ” - Coop’2000 – 4th Int’l Conference on the Design of Cooperative Systems – Sophia Antipolis – France – Mai 2000.

“ Turning non-cooperative applications into cooperative ones by adding dynamics to the information system ” - 5th Annual Conference of the UKAIS (UK Academy for Information Systems) – Cardiff – U.K. - Avril 2000.

“ A method for re-engineering/redesigning cooperatively distributed applications ” 5th Int’l conf. On Integrated Design & Process Science (IDPT/IDEATE) - Dallas - USA - Juin 2000.


40

Plan








Le FuturLe Futur


41

Le Futur La méthode peut être améliorée en amont en réalisant

une première partie plus proche des aspects de rétro-conception.

Étendre la méthode à des domaines plus généraux que la ré-ingénierie. Nous voulons généraliser notre approche.

Nous pensons que notre approche peut être utilisée pour résoudre des problèmes de re-configuration dynamique ou des problèmes de traçabilité.

Nous désirons développer notre propre outil de modélisation visuelle.

Documents

Laboratoire dInformatique Appliquée IUT Informatique de Bayonne Ré-Ingénierie dApplications pour la mise en oeuvre de la Coopération : Méthodologie et