Une approche à base de composants pour la

Transcription

Une approche à base de composants pour la
modélisation des procédés logiciels
Ma. Lizbeth GALLARDO
DEA préparé dans l’équipe ADELE, au laboratoire LSR
Soutenance à Grenoble,
Le 20 Septembre 2000.
Responsable du stage :
Noureddine BELKHATIR, Maître de Conférences UPMF Grenoble
Responsable de formation DEA :
Marie-France BRUANDET, Professeur à l’UJF
Remerciements.
Je tiens à remercier tout particulièrement :
Jacky Estublier, responsable de l’équipe ADELE,
Directeur CNRS, pour m’avoir accueilli dans son
équipe.
Noureddine Belkhatir, Maître de Conférences UPMF
pour son encadrement, ses nombreux conseils et son
soutien.
L’ensemble des personnes de l’équipe ADELE de
laboratoire Logiciel Systèmes et Réseaux.
Manuel Aguilar, mon époux, par son amour si précieux
et son soutien inconditionnel.
Lizbeth Gallardo – DEA Systèmes d’Information
20 Septembre 2000 - 1
Table des Matières
1. INTRODUCTION....................................................................................................... 5
1.1 Problématique............................................................................................................ 5
1.2 Contexte..................................................................................................................... 6
1.3 Contenu du document................................................................................................. 6
CHAPITRE 2. ETAT DE L’ART................................................................................... 7
2.1 Définitions de procédé et de support automatisé......................................................... 7
2.2 Communautés de procédés : procédé d’affaires et procédé logiciel. ........................... 7
2.3 Les Environnements centrés procédés. ....................................................................... 8
2.3.1
2.3.2
Définition ..................................................................................................................8
L’architecture.............................................................................................................9
2.4 Techniques d’interopérabilité................................................................................... 10
2.4.1
2.4.2
2.4.3
Définition de Composant..........................................................................................10
Définition d’Interopérabilité.....................................................................................10
Interopérabilité par échange de donnés. ....................................................................11
2.4.3.6 Interopérabilité sémantique : Vocabulaire commun. ..................................................11
2.4.3.7 Le schéma conceptuel procédé..................................................................................12
2.4.3.8 Interopérabilité par les données : Langage de traduction commun..............................13
2.4.4
Interopérabilité par le contrôle..................................................................................14
2.4.4.1
2.4.4.2
2.4.4.3
2.4.4.4
2.4.4.5
2.4.4.6
2.4.4.7
2.4.4.8
2.4.5
WAPI4 (Workflow Application Programming Interface/Interchange 4).....................15
SWAP......................................................................................................................17
Jflow........................................................................................................................17
Wf - XML................................................................................................................17
Le Modèle « Mission » : utilisation du protocole Wf-XML. ......................................19
OZ ...........................................................................................................................21
Process wall .............................................................................................................21
APEL.......................................................................................................................22
Approche par composant pour la modélisation des procédés.....................................22
2.4.5.1
2.4.5.2
2.4.5.3
2.4.5.4
Endeavors. ...............................................................................................................22
Pynode .....................................................................................................................22
SPMS. Software Process Management System..........................................................23
OPC. Open Process Components Framework. ...........................................................23
2.5 SYNTHESE .............................................................................................................. 25
CHAPITRE 3. NOTRE APPROCHE. ......................................................................... 26
3.1 Introduction. ............................................................................................................ 26
3.2 Concepts. .................................................................................................................. 26
3.2.1 Modèle. .......................................................................................................................26
3.2.2 Composant procédé..................................................................................................26
3.2.3 Modélisation basée composants................................................................................27
3.2.4 L’exécution basée composants procédés...................................................................27
3.2.5 Le vocabulaire commun. ..........................................................................................27
3.2.6
3.2.7
3.2.8
3.2.9
3.2.10
Le schéma conceptuel procédé. ................................................................................27
Framework orienté objet ..........................................................................................28
L’état procédé. .........................................................................................................28
Classement hiérarchique ..........................................................................................28
Architecture de l’Environnement Centré Procédé. ....................................................29
3.3 Modèle pour des Composants procédés.................................................................... 29
3.3.1
3.3.2
Les cas d’utilisation. ................................................................................................29
Scénarios principaux identifiés au travers des cas d’utilisation..................................30
3.3.2.1
3.3.2.2
3.3.2.3
3.3.2.4
3.3.3
3.3.4
Créer un composant procédé :...................................................................................30
Exécuter un composant procédé................................................................................31
Contrôler l’exécution d’un composant procédé..........................................................32
Abonner un observateur global externe. ....................................................................32
Diagramme de transition d’états. ..............................................................................33
Diagramme de classes ..............................................................................................34
3.3.4.1
3.3.4.2
3.3.4.3
3.3.4.4
3.3.4.5
Le patron Fabrication. ..............................................................................................34
L’Observateur global................................................................................................35
Le patron de façade. .................................................................................................36
Le ComposantMétaData. ..........................................................................................36
Fonctionnement de la machine d'exécution : exemple................................................36
CHAPITRE 4 PROTOTYPAGE................................................................................. 40
4.1 Modèle par composants procédés............................................................................. 40
4.2 Dépendances............................................................................................................ 41
4.3 L’observateur global. ............................................................................................... 41
CHAPITRE 5. CONCLUSION ET PERSPECTIVES ................................................ 43
BIBLIOGRAPHIE........................................................................................................ 44
Table des illustrations
Figure 1 : Procédé d'affaire: Traitement de dossiers de gestion de prêts bancaires .............................3
Figure 2 : Procédé logiciel: Cycle de vie du logiciel .............................................................................4
Figure 3 : Architecture de référence pour les PSEE [Sch99] ...............................................................5
Figure 4 : Schéma conceptuel............................................................................................................8
Figure 5 : PCIS LCPS Model [Der94] ..................................................................................................9
Figure 6 : Modèle par langage canonique .........................................................................................10
Figure 7 : Interopérabilité par control (WAPI 4) [WfMC2-1] ................................................................11
Figure 8 : Modèle de procédés chaînés............................................................................................12
Figure 9 : Modèle de procédés imbriqués.........................................................................................12
Figure 10 : Modèle de procédé parallèle ..........................................................................................12
Figure 11 : Modèle de ressource logique...........................................................................................14
Figure 12 : Modèle pour une mission ................................................................................................16
Figure 13 : Hiérarchie de classes pour l'entité "procédé" ...................................................................20
Figure 14 : Conception d'un procédé par composants .......................................................................22
Figure 15 : Schéma conceptuel.........................................................................................................24
Figure 16 : Les cas d'utilisation .........................................................................................................26
Figure 17 : Diagramme de séquences : création d’un composant procédé ........................................27
Figure 18 : Diagramme de séquence : Exécution d’un composant procédé .......................................27
Figure 19 : Diagramme de séquence : Contrôle de l'exécution ..........................................................28
Figure 20 : Diagramme de séquence : Abonnement un observateur..................................................29
Figure 21 : Diagramme de transition d'états pour un composant procédé ..........................................29
Figure 22 : Diagramme de classes : Framework pour des composants procédés ..............................30
Figure 23 : Diagramme de classes : Patron fabrication......................................................................31
Figure 24 : Diagramme de classes: L'observateur global ...................................................................31
Figure 25 : Diagramme de classes: Méta données produits par un composant procédé ....................27
Figure 26 : Le schéma pour test........................................................................................................33
Figure 27 : Arbres illustrant la création et exécution des sous composants test .................................33
Figure 29 : Diagramme de séquences pour exécution de Test ..........................................................34
Figure 30: Diagramme de séquence : interopérabilité entre des composants procédés ....................35
Figure 31 : Diagramme de transition d'état pour le composant test ...................................................35
Figure 32 : Fenêtre pour créer un modèle par composants................................................................36
Figure 33 : Fenêtre pour remplir les dépendances entre composants ................................................37
Figure 34 : Fenêtre pour observer cours de l'exécution des composants ...........................................38
Chapitre 1. Introduction.
Dans les années 1990 une équipe d’ingénieurs a mis en avant le fait que les outils logiciels pouvaient
être utilisés pour automatiser les procédures de travail impliquant la circulation de documents papier
[SW92]. La gestion de flux de travaux est une technique de modélisation de procédés logiciels, qui est
née de cette idée. Ainsi commence l’étude des procédés dirigée principalement vers le
développement de techniques et de mécanismes facilitant la modélisation et le support de procédés.
Par procédé on désigne l’ensemble des activités faisant intervenir de nombreux agents humains et
outils ayant un but commun, la création et la maintenance d’un produit ou la réalisation de services
en respectant un ensemble de caractéristiques bien définies. Un modèle est la description abstraite
des pratiques réelles concernant le déroulement des projets au sein d’un groupe de travail ou d'une
organisation. Plusieurs formalismes de représentation ont été proposés pour la modélisation de
procédés. Les systèmes supportant l’exécution de ces formalismes sont appelés environnements
centrés procédés.
1.1 Problématique.
Actuellement les procédés mis en œuvre dans notre société sont de plus en plus complexes et
difficiles à gérer; la raison principale est l'évolution rapide des activités sociales et économiques
durant les dernières décennies, en plus de la diffusion de la technologie de l’information dans
beaucoup de domaines » [Avr96]. En conséquence, la conception, l’exécution et la maintenance des
modèles pour ces procédés sont de plus en plus complexes.
Nous nous interessons plus particulièrement aux procédés logiciels et à leur modélisation pour faire
face à la complexité des procédés, la communauté génie logiciel propose leur construction en faisant
coopérer plusieurs équipes (peut-être géographiquement distribuées). En considérant que chaque
équipe peut avoir ses propres environnements de développement (formalismes de représentation,
moteur procédé, bases de données etc.), les modèles fournis par ces équipes seront hétérogènes. Et
malheureusement, les formalismes de représentation actuels liés à l’infrastructure qui les supporte ne
facilitent ni l’interopérabilité, ni la réutilisation de modèles procédés exécutables.
Comme nous le présentons dans l’état de l’art, les travaux cherchant à résoudre le problème de
l’interopérabilité sont nombreux. Une approche intéressante et récente consiste à appliquer la
technologie des composants et objets au développement de procédés. Parmi ces travaux on trouve
APEL et OZ, qui proposent une architecture par composants et Pynode, Endeavors et OPC, qui
proposent une approche par composant au niveau modélisation.
Les avantages attendus par l’approche composant pour le support de procédés sont :
Obtention d’environnements de développement de logiciels coopératifs et ouverts
Interopérabilité entre des composants hétérogènes (fédération de composants)
Dépendances entre procédés délimitées, mieux reconnues et gérées
Réutilisation des composants procédés
1.2 Contexte
Notre domaine de recherche s’inscrit dans une approche par composant pour le support automatisé
aux procédés logiciels. Nous proposons un framework orienté objet permettant construire, exécuter et
faire évoluer des modèles de procédés logiciels. Le contexte de ce travail est caractérisé par les
aspects suivants :
Approfondissement du concept de composant procédé logiciel.
Etude des différentes techniques d’interopérabilité.
Les buts de notre travail sont :
La proposition d’un framework orienté objet pour le support de procédés qui permette :
D'augmenter le potentiel de réutilisation des modèles de procédés fonctionnels,
D'assurer l'interopérabilité entre des composants hétérogènes.
L’intégration dynamique de composants.
La présentation des concepts et de la terminologie qui caractérisent la technologie de procédés.
Le développement d’un prototype pour valider nos idées, en utilisant des technologies actuelles
telles que Java, XML, protocoles de communication comme CORBA, etc.
1.3 Contenu du document.
Nous allons présenter dans le chapitre 2 l’état de l’art qui comprend plusieurs techniques
d’interopérabilité identifiées dans le domaine de procédés. Dans le chapitre 3, nous présenterons les
concepts et la terminologie utilisés dans notre approche, ensuite le framework pour un composant
procédé. Dans le chapitre 4, nous présenterons le prototype comprenant les interfaces de dialogue
pour la création et gestion d’un modèle par composants. Le chapitre 5 présentera les conclusions
ainsi que les perspectives de ce travail.
Chapitre 2. Etat de l’Art
2.1 Définitions de procédé et de support automatisé.
Par procédé on entend l’ensemble des activités faisant intervenir des équipes de personnes (souvent
nombreuses), des outils et des techniques pour assurer le développement et la maintenance de
produits ou de services.
Le support automatisé aux procédés correspond à l’application de la technologie informatique pour
assister et automatiser le travail d’une organisation.
2.2 Communautés de procédés : procédé d’affaires et procédé logiciel.
On distingue deux communautés dans l’étude de procédés : La communauté de procédé logiciel
(Software process) et celle des procédés d’affaires (Workflow). Les deux partagent le même objet
d’étude : le procédé ainsi que de l’intérêt d’accroître la connaissance autour de celui-ci mais ils
diffèrent dans l’approche initiale du problème.
Dans les années 1990, une équipe d’ingénieurs a mis en avant que les outils logiciels peuvent être
utilisés pour automatiser les procédures de travail impliquant la circulation de documents papier
[SW92]. La gestion des flux de travaux (workflow management système) est la technologie logicielle
inspirée de cette idée. Elle permet de modéliser les procédures de travail et d’en assurer la mise en
œuvre.
L’approche adoptée par la communauté de procédés d’affaire est pragmatique. Les recherches
effectuées dans le domaine visent dès le départ l’application pratique de cette nouvelle technologie
dans des situations de travail réelles. On assiste alors aux développement de systèmes dédiés à la
gestion des documents dans des organisations caractérisées par des procédés d’affaires de type
traitements de dossier. Pour illustrer cette approche, considérons par exemple le dossier de gestion
de prêts dans une banque. La figure suivante montre l’ensemble des activités nécessaires pour son
traitement.
Figure 1 : Procédé d'affaire: Traitement de dossiers de gestion de prêts bancaires
Quand à la démarche adoptée par la communauté procédé logiciel, elle est plus orientée vers l’étude
de modèles pour les procédés que dans la production de systèmes directement exploitables. Les
aspects technologiques étudiés se focalisent sur l’élaboration d’environnements destinés à supporter
les modèles développés. Un exemple est le modèle en cascades [JCJ+93] de cycles de vie du
logiciel, la figure 2 illustre un procédé suivi pour le développement d’un logiciel. Les flèches arrondis
indiquent le flux d’exécution des différents activités dans le développement du logiciel. Par exemple
quand l’activité Analyser le problème soit fini, l’activité Concevoir la solution logiciel sera initiée. Si
dans le développement de cet activité on trouve des erreurs, l’activité analyser le problème sera
appelé pour réaliser les corrections pertinents au modèle. Les flèches droits indiquent que tous les
produits fournis par les activités seront validés, dans l’activité Valider les modèles et l’implémentation.
Figure 2 : Procédé logiciel: Cycle de vie du logiciel
Les principales différences entre les deux types de procédés peuvent être résumées de la manière
suivante :
Les procédés d’affaires (Workflow)
Les procédés logiciel
•
Travail sur l’automatisation de procédés •
d’affaires
Travail sur
logiciels
•
Ils sont stables. (la définition du procédé •
ne change pas fréquemment).
Sont relativement instables. (développement
d’activités peut être changé ou raffiné quand le
procédé est en train de s’exécuter)
•
Environnement
industriels
(WFMS) • Produits universitaires (PSEE).
(Workflow Management Systems)
(Process S/W Engineering Environment)
l’automatisation
de
procédés
Malgré les différences décrites auparavant, les orientations suivies par chacune des deux
communautés ont permis de faire avancer en parallèle et de façon complémentaire les recherches sur
les procédés. Peu à peu, les 2 courants se sont rapprochés, chacun intégrant les avancées de l’autre
dans son approche du problème.
2.3 Les Environnements centrés procédés.
2.3.1 Définition
Un Environnement Centré procédé ( PSEE - Process Software Engineering Environment) est un
système permettant de décrire explicitement et avec suffisamment de détails la manière de produire
un logiciel. Cette description, appelée modèle du procédé, est exprimée dans un formalisme approprié
appelé langage de modélisation de procédés [Ami99]. Pour le groupe de travail PROMOTER 2, un
environnement de développement peut être qualifié de centré procédé si son architecture est basée
sur un moteur de processus qui, par interprétation ou exécution du modèle de procédé, contrôle la
démarche de production en cours. L’environnement peut en outre comporter des outils dédiés au
suivi, à l’analyse et à l’évolution des modèles de procédés [Der94].
On peut trouver dans la littérature plusieurs études comparant les différentes PSEE développés en
tant que prototypes de recherche, industriels ou systèmes commercialisés [Lon94], [CJ99]. Il ressort
de ces travaux que la plupart de ces systèmes offrent les moyens de mener à bien l’ensemble des
activités relevants de l’ingénierie du procédé. Toutes les étapes depuis la définition jusqu’au support
automatisé et à l’évolution du procédé forment le cycle de vie du procédé, communément appelé Méta
– Procédé [Avr96].
2.3.2 L’architecture
L’identification des différents services de base que doit fournir un PSEE permet d’élaborer un modèle
de référence pour l’architecture générale de ce type de systèmes [Sch99]. La figure 3 illustre les
services : gestion des dialogues, des procédés, des espaces de travail et des bases de données. Ils
sont organisés dans une architecture comportant quatre couches abstraites.
Figure 3 : Architecture de référence pour les PSEE [Sch99]
Tout PSEE doit permettre la gestion des dialogues afin d’informer les utilisateurs sur le procédé et
de leur permettre, sur la base des informations fournies, d’effectuer leurs tâches. Le service de
gestion des dialogues concerne directement l’interface proposée à l’utilisateur, qui doit par ailleurs
correspondre directement au rôle de celui-ci. Via les informations gérées par ce service,
l’environnement répond en adéquation avec les besoins inhérents au rôle de l’utilisateur.
La gestion des processus est le service rendu par un PSEE qui fait référence à l’exécution d’un
modèle de procédés donné. C’est à ce niveau qu’est gérée la coordination des activités
concurrentes des divers acteurs impliqués. Par ailleurs, ce service « calcule » l’espace de travail à
fournir à l’utilisateur, en fonction de l’état du procédé en cours.
Un espace de travail doit être consacré à chaque utilisateur en fonction de son rôle. Un service
dédié à la gestion de ces espaces de travail permet de maintenir, pour chacun et à un instant
donné, les éléments logiciels nécessaires et suffisants pour procéder à la réalisation de la tâche.
La gestion de base d’objets est un quatrième service inhérent aux PSEE. L’objectif est ici d’assurer
l’accès aux objets logiciels et à leurs relations qui sont stockés de façon persistante. Un
gestionnaire de données est un des éléments clé des PSEE : il est responsable de la cohérence et
de la disponibilité des informations nécessaires aux autres composants de l’environnement (i.e. la
résolution des conflits d’accès notamment).
La gestion des communications suppose que des interfaces de communication soient créées pour
les composants et que des protocoles de communication soient établis pour définir les modalités
d’utilisation des services disponibles. L’intégration de ce service au sein de l’architecture présente
l’intérêt non négligeable de rendre l’environnement adaptable, flexible et extensible.
2.4 Techniques d’interopérabilité
La tendance actuelle dans les systèmes supportant des procédés est d’offrir un environnement
coopératif dans lequel le support se fait à travers un ensemble de composants. Chaque composant
prend en charge la gestion d’un aspect particulier du procédé.
Les récents travaux de recherche [BK95] [GLK97] dont les nôtres [ABC94] [ABC96] [Ami99]
proposent une approche par composant pour le support de procédés. Les avantages attendus sont:
L’obtention des environnements coopératifs et ouverts
L’Interopérabilité entre composants hétérogènes
Les Dépendances entre procédés sont délimitées et par conséquent mieux reconnues et gérées
La réutilisation des composants procédés
Notre étude est centrée sur le développement d’un modèle de procédé à base de composants avec
deux aspects importants à expliciter : Le concept de composants et l’interopérabilité entre
composants.
2.4.1 Définition de Composant
« Un composant est un fragment de logiciel assez petit pour qu’on puisse le créer et le maintenir, et
assez grand pour qu’on puisse l’installer et en assurer le support. De plus, il est doté d’interfaces
standard pour pouvoir intéropérer ». [OHE99]
Un composant procédé est constitué d’un groupe significatif d’activités. Le composant procédé
contient tous les rôles et produits qui sont liées à ces procédés et activités [LD97].
2.4.2 Définition d’Interopérabilité
Deux ou plusieurs ressources sont interopérables si elles peuvent interagir pour exécuter ensemble
une tâche [NWM93]. L’interopérabilité implique la distribution d’informations, la communication et la
compréhension mutuelle entre les différents domaines d’exécution.
L’hétérogénéité des composants rend complexe l’interopérabilité. Cette hétérogénéité peut être due à
la diversité des solutions proposées pour couvrir les différents aspects du procédé. En effet, pour
chaque aspect dans le procédé, on peut envisager des solutions conceptuelles et technologiques
différentes. Ceci concerne les concepts utilisés, les formalismes proposés et les plates formes
d’exécution, etc.
On peut distinguer trois niveaux d'hétérogénéité :
•
•
•
sémantique
syntaxique
des plate formes d'exécution.
L'hétérogénéité sémantique est due à la diversité des concepts utilisés par les composants. Chaque
composant peut offrir des concepts différents pour gérer l’aspect du procédé auquel il est dédié.
L'hétérogénéité syntaxique. Les composants peuvent offrir un formalisme différent pour décrire
l’aspect de procédé qui leur correspond. Le choix d’un formalisme par rapport à un autre peut avoir un
impact considérable sur l’amélioration de la compréhension des modèles et de la capture du domaine
du problème.
L’hétérogénéité des plates formes d’exécution. En considérant que l’exécution du procédé est répartie
sur un ensemble de composants autonomes, chaque composant peut faire appel à des plates formes
matérielles différentes. Le problème consiste ici à trouver les mécanismes appropriés qui permettent
aux composants d’interagir, d’échanger des données et du contrôle.
Les travaux qui proposent des solutions aux problèmes d’hétérogénéité sont nombreux. Dans notre
état de l’art nous avons classifiés en trois groupes les techniques d’interopérabilité trouvées dans
plusieurs propositions du domaine de procédés et correspondant à une évolution dans le temps.
1. Interopérabilité par échange de données :
Vocabulaire commun (sémantique)
Schéma conceptuel procédé.
Langage (syntaxe)
2. Interopérabilité par le contrôle (plates formes d’exécution)
3. Interopérabilité par composants
Nous proposons à présent d’aborder chacune des techniques d’interopérabilité, en remarquant les
concepts apportés par les groupes de recherche.
2.4.3 Interopérabilité par échange de donnés.
2.4.3.6 Interopérabilité sémantique : Vocabulaire commun.
Les environnements coopératifs impliquent que de multiples participants travaillent ensemble pour
réaliser un but commun.. Pour atteindre ce but, ils ont besoin d’échanger des idées et des résultats.
Cependant, lorsque les participants interagissent, il apparaît un problème de vocabulaire, à cause des
différentes définitions qu’ils utilisent pour décrire le même concept.
Le problème du vocabulaire commun a été abordé par différents domaines de l’informatique tels que
les bases données [BFL94] ou les systèmes collaboratifs [Che94] [WfMC98. Une des solutions
proposées consiste à proposer des normes définissant les concepts relatifs à un domaine particulier
(ontologies).
Dans le domaine de procédés, des efforts importants ont été mis en œuvre afin de clarifier les
concepts et la terminologie. Les contributions en rapport avec ce sujet viennent principalement de la
communauté procédés logiciels [CFF94] [Lon93].
Nous allons définir les éléments basiques qui interviennent dans le procédé. Bien que nous ayons
trouvé différentes définitions pour les éléments du procédé, nous avons essayé de donner une
définition qui fasse l’objet d’un large consensus. Nous montrerons dans ce qui suit la façon d’abstraire
de tels éléments dans un schéma d’objets. Tout composant doit adhérer à ce schéma. Il représente
les éléments et les relations qui les lient.
Procédé : tous les éléments impliquées dans le développement et la maintenance d’un produit ou
service, i.e. artefacts, support de production (outils), activités, agents [CFF94].
Artefact : produit créé ou modifié pendant un procédé [Lon93]. Il correspond à des objets tels que
des documents ou des codes ayant une structure bien identifiée.
Agent : celui qui exécute le procédé. Cela peut être un humain ou un outil logiciel [CFF94]. Un
agent est caractérisé par les propriétés de son rôle.
Rôle : décrit un ensemble de responsabilités, droits et compétences d’un agent dans le contexte
des activités où il intervient.
Activité : c'est une unité élémentaire du procédé. Elle correspond à l’ensemble des actions
effectuées par les rôles dans le but de créer, de consommer, de transformer des produits ou de
réaliser un service.
2.4.3.7 Le schéma conceptuel procédé.
Une proposition pour le développement d’une théorie unifiée dans la modélisation des procédés, est
le « schéma conceptuel commun ». Un schéma conceptuel commun offre une information importante
sur l’ensemble des entités participant au procédé et sur les relations existant entre les entités.
Armitage et Kellner [AK94] ont proposé « un schéma conceptuel qui représente une vue unique et
intégrée de l’information nécessaire dans les modèles et définitions d’un procédé ».
Le schéma conceptuel est suffisamment général et abstrait, ce qui permet de l’utiliser avec une large
variété de langages de définition ou de modélisation de procédés. L’objectif visé est d’obtenir :
•
•
•
Une base pour la représentation et la transformation d’un procédé dans différents formalismes.
L’assistance au développement, à la révision et à l’amélioration du modèle de procédé.
La constitution d’une base de modèles de procédés réutilisables.
Le schéma est constitué de trois entités de bases : activité, artefact et agent et des relations qui les
lient. La figure 4 montre le schéma conceptuel.
Figure 4 : Schéma conceptuel
Nous pouvons interpréter le schéma de la manière suivante : Un agent exécute une activité
produisant un artefact. Par ailleurs, un artefact est issu d’un autre artefact ; un agent est géré par un
autre agent ; et une activité vérifiant le travail d’une autre activité.
Un procédé est de nature dynamique. Par conséquent, le comportement dans le temps est un aspect
critique du procédé. Les principales entités et relations peuvent être envisagées comme une photo
instantanée. La figure 4 montre que le comportement est un aspect fourni par tous les entités et les
relations. Exemples de comportements :
Quand (sous quelles circonstances)
Une activité peut commencer ?
Une activité peut être considérée comme terminée ?
Un artefact est produit (output) ?
Un artefact est acquis (input) ?
Un agent peut commencer à travailler dans une activité ?
L’information du comportement peut être représentée par plusieurs approches de modélisation et de
définition de procédés, comme : les diagrammes à transition d’ état, les déclencheurs ou les règles
événements – conditions - actions, les pré / post-condition.
Un autre approche de schéma conceptuel commun est le modèle proposé dans le cadre du projet
PCIS LCPS (Portable Common Interface Set Life Cycle Process Support). Ce modèle identifie les
entités basiques du procédé et les relations entre elles. Voir figure 5.
Figure 5 : PCIS LCPS Model [Der94]
Le PCIS LCPS est centré sur les relations entre les activités (Activity) et les produits (Product). Une
activité produit ou consomme des produits. L’activité emploie des outils (Tools) pour assister ou
mettre en œuvre l’activité. Toute activité est exécutée par un agent via son Rôle (Role), lequel
identifie le responsable de l’activité. Finalement, chaque activité a un but (Direction) associé, lequel
représente les objectifs de l’activité.
2.4.3.8 Interopérabilité par les données : Langage de traduction commun.
Nous avons dit précédemment que le schéma conceptuel servait de base pour la représentation d’un
procédé dans différents langages de modélisation. Dans un environnement coopératif chaque
composant peut offrir un langage de modélisation différent pour décrire l’aspect du procédé qui lui
correspond.
Le but de l’interopérabilité syntaxique est de minimiser les conversions de données entre deux
composants souhaitant échanger des définitions de procédés. L’approche par modèle canonique a
été dégagée des différents travaux d’interopérabilité syntaxique.
Cette approche préconise une représentation canonique et considère un convertisseur du formalisme
du composant vers le formalisme canonique et vice versa. Généralement, les critères de choix d’un tel
langage dépendent de la nature du domaine et de l’objectif à atteindre [Ami99].
Figure 6 : Modèle par langage canonique
Des exemples de langages basés sur le modèle canonique sont PIF et WPDL.
PIF (Process Interchange Format)
Le PIF a commencé à se développer en octobre de 1993 par un groupe de travail comprenant des
représentants de plusieurs universités et de sociétés de développement. L’objectif principal est d’offrir
des formats et des schémas standards pour permettre l’échange automatique de représentations de
procédés entre des systèmes hétérogènes [LGJ+98].
PIF est basé sur un modèle objet. Il inclut un noyau de type objet (classe) prédéfini représentant les
activités, les acteurs et les ressources. PIF permet à des groupes de travail de définir des extensions
locales au modèle à savoir, de nouvelles classes ou nouveaux attributs.
WPDL (Workflow Process Langage)
Le WPDL a été défini par la coalition du workflow (WfMC). Il s’agit d’un langage standard qui supporte
la transmission des définitions de procédés entre différents systèmes workflow [WfMC98]. Le langage
est basé sur un méta – modèle (modèle d’objets). L’objectif est de rendre possible l’échange de
modèles et de documentation entre des systèmes hétérogènes provenant de vendeurs différents.
2.4.4 Interopérabilité par le contrôle.
L’interopérabilité au niveau exécution, peut être défini comme la capacité pour un serveur d’exécution
de communiquer avec un autre afin d'exécuter ensemble un procédé. Rappelons que dans le contexte
des composants, l’exécution d’un procédé est répartie entre un ensemble de composants autonomes
et chaque composant peut faire appel à d’autres pour interagir. Un mécanisme qui permet
l’interopérabilité est dit d'intégration par le contrôle.
L’objectif de l’intégration par le contrôle est de permettre à des systèmes hétérogènes de
communiquer entre eux et de faire varier leurs comportements en fonction des informations recueillies
à travers ces communications [Was90]. Deux types de contrôles peuvent être distingués [Boy94] : la
notification de l’information et la demande de services.
La notification d’information permet à un système d’émettre une information (souvent sous forme
de messages ou d’événements) vers d’autres systèmes. Les notifications se font généralement au
travers d’un système de messagerie ou de middleware tel que Corba.
La demande de services permet à un système de faire appel à un service (généralement un
service est une méthode) offert par un autre système. Ce type d’interaction se fait souvent à
travers des interfaces qui contiennent l’ensemble des services que le composant veut rendre
visibles.
Les travaux réalisés au niveau d’interopérabilité d’exécution sont nombreux, nous allons en décrire
quelques-uns. Nous présentons d’abord la spécification de WAPI 4 fournie par la WfMC, notre
intention est d'identifier les besoins qui conduisent à supporter l’interopérabilité d’exécution. Après
nous présenterons trois protocoles de communication proposés par différents groups de recherche
afin de supporter l’interopérabilité entre les serveurs d’exécution : SWAP, Jflow et Wf - XML
2.4.4.1 WAPI4 (Workflow Application Programming Interface/Interchange 4)
WAPI4 est la spécification abstraite défiant les fonctionnalités nécessaires pour supporter
l’interopérabilité entre les différents moteurs de procédés.
Figure 7 : Interopérabilité par control (WAPI 4) [WfMC2-1]
Le but est de définir un standard permettant de passer des items de travail (instances des procédés
ou des activités) d’un système workflow à un autre système différent.
Deux ou plusieurs moteurs workflow peuvent communiquer pour réaliser : la sélection, l’instantiation
et l’exécution d’une définition de procédé connu, et (optionnellement) retourner les résultats sur
l’exécution de la définition du procédé. On peut distinguer deux modèles de communication :
Communication synchrone : Où une requête demande une réponse « immédiate », elle nécessite
une connexion directe via le protocole TCP/IP.
Communication asynchrone : Où la réponse peut arriver quelques temps après la requête (de
l’ordre de quelques jours, semaines ou mois). La communication peut être réalisée en utilisant des
mécanismes de type « stocker– transférer » tel que la messagerie électronique.
Les types de messages pour effectuer l’interopérabilité.
Un message est la représentation abstraite de l’information qui doit être passée d’un moteur
d’exécution à l’autre, afin que ce dernier puisse réaliser les opérations décrites dans le message. Un
message contient : des opérations et leurs paramètres respectifs ; et l’information additionnelle pour
que ces opérations puissent être exécutées. Il y a trois classes de messages : requête, réponse et
notification.
Un message « requête » est utilisé quand un moteur d’exécution A a besoin de déclencher une
activité ou un sous procédé dans un moteur B. A tout message de requête correspond un message
« réponse » qui retourne le résultat de succès ou d’échec de la demande. Le message notification
permet au moteur B d’informer sur les événements significatifs qui arrivent pendant l’exécution du
sous procédé. Tout message « notification » aura un message de réponse informant que le moteur A
a reçu la notification.
Les modèles d’interopérabilité par contrôle supportés sont :
•
Procédés chaînés. Ce modèle considère qu’un procédé qui est exécuté dans le moteur de
procédé A, déclenche la création et l’exécution d'un sous–procédé dans le moteur B. Pendant
l’exécution du sous–procédé, le moteur A peut finir ou continuer l’exécution de son propre
procédé.
Figure 8 : Modèle de procédés chaînés
•
Sous–procédés imbriqué. Ce modèle considère qu’un procédé en cours d’exécution dans un
moteur d’exécution A provoque la création et l’exécution d’un sous–procédé dans un moteur B.
Ainsi, le premier moteur attend la terminaison du deuxième moteur avant de continuer sa propre
exécution.
Figure 9 : Modèle de procédés imbriqués
•
Parallèle synchronisé. Ce modèle considère que deux moteurs d’exécution sont en train de
dérouler chacun des procédés différents, et que chaque définition de procédé possède un rendezvous spécifié. Une fois que tout les deux ont atteint leur point rendez-vous, il y a des échanges
entre les moteurs avant de continuer l’exécution de leurs procédés respectifs.
Figure 10 : Modèle de procédé parallèle
Pour cette spécification abstraite d’interopérabilité par contrôle nous avons trouvé trois protocoles de
communication proposés : SWAP lequel travaille sur HTTP, jFlow travaillant sur CORBA et une
proposition récente : Wf-XML généralisation de SWAP et Jflow, car il reste indépendant du protocole
de communication.
2.4.4.2 SWAP
En 1998 le protocole SWAP (Simple Workflow Acces Protocole) à été introduit par Netscape, HP et
Sun comme une solution simple destinée à supporter l’interopérabilité entre serveurs d’exécution
workflow. La spécification d’interopérabilité définit un standard de communication basé sur le
protocole HTTP, et utilise XML pour la structure d ’échange de données.
Les buts du SWAP sont d’intégrer des fournisseurs procédés ; de fournir des services asynchrones, à
travers Internet ou de réseaux Intranet ; et de subvenir aux besoins de leurs interactions. Le protocole
SWAP offre un chemin pour commencer une instance d’un service générique asynchrone. Il offre
aussi, des mécanismes pour contrôler et diriger l’instance; et un autre mécanisme pour notifier quand
elle est terminée.
Par exemple une demande asynchrone est faite pour l’exécution d’un service. Des demandes
additionnelles (synchrones ou bien asynchrones) peuvent être faites durant l ’exécution du service
pour contrôler l’avancement.
2.4.4.3 Jflow
En 1998 l’OMG (Object Management Group) a défini un protocole d’interopérabilité workflow nommé
jFlow en utilisant le protocole CORBA. Le standard CORBA établit la façon dont les objets distribués
peuvent participer à un workflow au moyen d’invocations par un ORB (Object Request Broker). JFlow
support l’interaction des procédés workflow pendant l’exécution, en utilisant des mécanismes de
contrôle, de monitoring et de distribution des procédés.
Le but de l’OMG est de créer un framework architectural pour des applications distribuées basées sur
des spécifications supportant des objets distribués. Le but inclut la réutilisation, la portabilité et
l’interopérabilité de composants logiciels dans des environnements hétérogènes [OMG98]. Pour
atteindre ce but, l’OMG adopte des spécifications de protocoles et d’interfaces, basés sur la
technologie objet commercialement disponible.
Wf-XML est un protocole plus général que SWAP et jFlow. Il reste indépendant des protocoles de
communication HTTP et CORBA.
2.4.4.4 Wf - XML
Wf-XML est la spécification d’un langage XML (eXtensible Markup Langage) désigné pour modéliser
le transfert de données demandé par la spécification d’interopérabilité WfMC. Ce langage sera utilisé
comme base pour les implémentations des fonctionnalités de l’interface 4 de WfMC. Wf-XML supporte
deux types d’interopérabilité : workflow simple chaîne et workflows imbriqués.
Le standard d’interopérabilité [WfMC2-2] permet l’interaction entre fournisseurs et demandeurs de
services workflow (lesquels peuvent ou non être des services d’exécution workflow). Il définit des
opérations permettant à des fournisseurs de retourner des rapports sur l’état d’un procédé éloigné.
Wf-XML définit le format de la requête qu’un demandeur de services A envoie au fournisseur de
service B pour contrôler et surveiller l’exécution d’un procédé. Le fournisseur répond à chaque
requête avec une réponse assortie. Alors, le fournisseur B renseignera A sur les changements d’état
d’un procédé, qui résultent des événements dans le domaine de B [WfMC2-1].
Les caractéristiques de la spécification Wf-XML:
1. Le corps du protocole est structuré et « bien formé ». Il est constitué de structures de messages
contenant des données et des entêtes.
2. L’utilisation de messages synchrones et asynchrones.
3. L’indépendance du mécanisme de transport. La spécification Wf-XML définit le contenu des
données nécessaires pour la communication effective entre deux moteurs d’exécution. La
méthode de transport dépend de la solution du fournisseur. Quelques exemples de méthodes de
transport : HTTP, E-mail, CORBA, IIOP, COM/DCOM ou des systèmes de queue de messages.
4. Contrat d’interopérabilité. Typiquement le contrat d’interopérabilité s’adresse au sujet de
connectivité, sécurité et le format de données qui sont associés à un procédé workflow spécifique.
Dans le Wf-XML, le contrat définit clairement les besoins de chaque vendeur.
5. Facilite l’extensibilité grâce à l’utilisation du XML, et grâce à l’utilisation d’un contexte de donnés
dynamique.
Le concept d’interopérabilité entre systèmes workflow peut être étendu pour couvrir des interactions
entre d’autres types de systèmes et services dits « services génériques » et peuvent représenter des
ressources identifiables avec qui arrivent des interactions.
L’interopérabilité est menée à bien par des fonctions individuelles dites « opérations ». Chaque
opération peut être passée comme un ensemble de paramètres en utilisant un message « requête » ;
de la même façon, ses résultats peuvent être retournées comme un ensemble de paramètres en
utilisant un message « réponse ». Les opérations sont classifiées dans trois groupes, afin de les
identifier en accord à leur contexte, à savoir : le ProcessDefinition, le ProcessInstance et l'Observer.
Les groupes d’opérations et leurs relations sont illustrées par la figure suivante.
Figure 11 : Modèle de ressource logique
Le processDefinition est le groupe fondamental des opérations nécessaires pour l’interaction de
ressources. Il représente la description de fonctions plus basiques, et il est la ressource par
laquelle des instances d’un service seront crées.
Le groupe ProcessInstance représente l’exécution réelle d’un procédé défini. Chaque instance de
procédé aura son propre identificateur séparé de l’identificateur de sa définition.
Le groupe Observer fournit les moyens par lesquels l’instance d’un procédé peut communiquer
son terminaison.
Wf XML a spécifié les opérations suivantes :
CreateProcessInstance
Process
Definition
X
Process
Instance
Observer
Description
Crée une nouvelle instance d’un procédé particulier
laquelle sera contrôlée par le fournisseur de service.
GetProcessInstanceData
X
Obtient les valeurs de toues les propriétés définies pour
une instance du procédé.
ChangeProcessInstanceState
X
Change l’état de l’instance du procédé.
ProcessInstanceSetChanged
X
Renseigne sur les changements d’état closed.completed
et closed.abnormalCompleted.
2.4.4.5 Le Modèle « Mission » : utilisation du protocole Wf-XML.
Nous allons présenter le modèle mission comme un exemple de la démarche du protocole Wf-XML.
La « mission » a par but atteindre l’interopérabilité entre les différents composants procédés, en
utilisant le modèle client - serveur et le protocole Wf-XML [WfMC2-1], sur HTTP.
Description.
La mission commence quand un serveur reçoit une requête Wf-XML avec les paramètres nécessaires
dans la démarche d’une opération, tel que « CréerComposant » ; et elle finit quand le client reçoit une
réponse avec les résultats de l’opération demandé. On peut distinguer deux types de requêtes :
synchrone et asynchrone.
La requête synchrone. La réponse à une requête est presque immédiate, quelques secondes ou
minutes.
La requête asynchrone. La réponse à une requête est plus tardive que précédemment, quelques
heures, jours ou mois.
Il y a trois types d'opérations qui définissent la nature de la requête. Une mission doit avoir au
minimum un des types d’opération suivants:
Enregistrer : pour réaliser des requêtes impliquant des actions et pour retourner des résultats.
Rapporter : pour demander la progression et le résultat d’une requête finie. Cette opération est
utile quand un client invoque une mission incluant des centaines de requêtes.
Contrôler : pour annuler, arrêter ou reprendre l’exécution d’une requête.
Les opérations de nature synchrones sont constituées en deux phases : La phase de « requête » et la
phase de « réponse ». Dans la figure les messages No. 10 et No. 11.
Les opérations de nature asynchrones sont constituées en quatre phases : la « requête » tel que le
message No. 6, la phase de « Reconnaissance » sortante tel que le message No. 7, la phase de
« Réponse » tel que le message No. 8, et « Reconnaissance » entrante tel que le message No. 9.
On peut distinguer deux types de directions : Sortant et entrant. Quand le client A fait une requête au
serveur B, la direction « sortant » indique que le message est envoyé du client A au serveur B ;
pendant que la direction « entrant » indique que le message est envoie du serveur B au client A
Figure 12 : Modèle pour une mission
1. Le gestionnaire de requêtes A ressemble toutes les requêtes Wf-XML. Il fait un script de
commandes avec les requêtes nombres.
2. Le gestionnaire de requêtes A fournit un identificateur à la mission « IdMission »
3. Le gestionnaire de requêtes A envoie le script au gestionnaire de requêtes B, à travers d’un
message Enregistrer.requête. Ce message contient : L'« IdMission », une étiquette contenant
l’URL du gestionnaire de requêtes A, et une étiquette <Asynchrone> indiquant que l’opération est
asynchrone.
4. Le gestionnaire de requêtes B retourne un message de « Enregistres.reconnaissance » avec
l'« IdMission ».
5. Le gestionnaire de requêtes B exécute chacune des requêtes trouvées dans le script.
6. Quand le gestionnaire de requêtes A veut connaître la progression et le résultat de toute requête
finie, il envoie un message Rapporter.requête. Ce message contient : Le « IdMission » passé
dans le pas 3, et une étiquette <Asynchrone> indiquant que l’opération sera menée à bien de
façon asynchrone.
7. Le gestionnaire de requêtes B retourne un message de « Rapporter.reconnaissance » avec
l'« IdMission ».
8. Le gestionnaire de requêtes B retourne le message réponse de l'opération Rapporter
« Rapporter.réponse », avec la progression et le résultat.
9. Le gestionnaire de requêtes A retourne un message de « Rapporter.reconnaissance » avec
l'« IdMission ».
10. Quand le gestionnaire de requêtes A veut déclencher une action sur l’exécution du composant
procédé, il envoie un message Control.requête. Ce message contient : L'« IdMission » et une
étiquette <Synchrone> indiquant que l’opération sera menée à bien de façon synchrone.
11. Le gestionnaire de requêtes B envoi un message réponse de l'opération Contrôle
« Control.réponse ».
12. Lorsque que toutes les requêtes dans le script sont finies, un message réponse de l'opération
enregistrer « Enregistrer.réponse » est envoyé vers le gestionnaire de requêtes A. Le message
peut inclure des exceptions sur les requêtes qui ont présenté des pannes pendant leur exécution.
13. Le gestionnaire de requêtes A retourne un message de « reconnaissances » par le résultat.
2.4.4.6 OZ
OZ [BK95] est un système développé dans le but de permettre l’interopérabilité entre des
environnements homogènes (les PSEE’s pris en compte par l’environnement sont identiques),
autonomes et géographiquement distribués. L’approche utilisée consiste à répartir l’exécution du
modèle de procédé sur des sites différents en fonction de la disponibilité des ressources nécessaires
à son exécution.
Oz utilise la métaphore « alliance internationale » pour gérer la communication entre PSEE’s
décentralisés. La Métaphore implique deux concepts : traités et sommets. Les sites PSEE’s sont
interconnectés, pour établir des traités. Un traité est un sous procédé partagé par plusieurs PSEE’s.
La réalisation d’une tâche multi-site définie dans un traité est un sommet. Seulement les tâches
spécifiées dans le traité peuvent accéder aux données des sites en accord avec les restrictions
définies dans le traité. Les sommets permettent l’exécution d’activités multi-sites globales et
partagées.
2.4.4.7 Process wall
Process Wall [Hei92] est un moteur de procédé basé sur un serveur d’états. Il a été développé par
l’Université du Colarado. Il permet le stockage des états d’un procédé et offre des opérations
manipulant la structure des états.
Une caractéristique importante du Process Wall est la séparation du formalisme décrivant le code de
procédé du formalisme décrivant l’état du procédé. Cette séparation permet l’interopérabilité entre
différents formalismes de code (langages de procédés) car ils adhérent à la structure d’un état
commun.
L’architecture du serveur d’état est de type client – serveur. Les clients hétérogènes, manipulent le
serveur d ’état du procédé central. La communication entre le client et le serveur est bidirectionnelle et
utilise RPC (Remote–Procedure Call). Un client manipule une instance de procédé partagé et reçoit
les notifications des mises à jour de l’instance.
2.4.4.8 APEL.
APEL [EAD98] est un environnement centré procédé pour la modélisation et l’exécution de procédés.
Il est basé sur une architecture dénommé « fédération de composants ».
L’idée consiste à partager le modèle global d’un procédé dans un nombre d’aspects (activités d’un
procédé) indépendants; chacun des aspects seront réalisés par un composant spécifique. Tous les
composants dans cet environnement sont des Process (Sensitive) Support Systems1 (PSS)
hétérogènes à niveau représentation ; cependant ils partagent les mêmes concepts de procédés
fondamentaux. Bien qu’eux sont hétérogènes APEL essaye de les faire interopérer, pour mener à
bien le procédé global.
L’interopérabilité est supporté au niveau de la modélisation et au niveau de l’abstraction
(interopérabilité sémantique) ; elle est de plus renforcée en utilisant les moteurs procédés distribués et
hétérogènes au niveau de l’exécution.
APEL utilise le paradigme d’interopérabilité dit « ultra libéral ». Ici, les composants réagissent par
notification d’événements. Les principales caractéristiques:
Les composants sont libres de choisir les événements auxquels ils souscrivent.
Les composants sont libres de décider comment réagir quand un événement arrive.
Il n’y a pas de contrôle sur les actions qu’un composant peut effectuer dans un serveur de
procédé.
2.4.5 Approche par composant pour la modélisation des procédés
Nous nous sommes intéressés plus particulièrement aux approches de modélisation de procédés à
base de composants. Ainsi, le contrôle et l’intégration des données sont mis en œuvre à partir d ’un
modèle basé composants. Alors, le procédé est vu comme un ensemble de composants inter
opérants. Les dépendances de données sont réduites en encapsulant les composants derrière des
interfaces bien définies. Cela permet d’éliminer le besoin de traduction entre langages de procédés.
Les systèmes suivants illustrent une telle approche : Endeavors, Pynode, SPMS et OPC
2.4.5.1 Endeavors.
Le système Endeavors [BT96] est un système distribué destiné à assister les procédés. Le système
est basé sur la combinaison d’une approche homogène au niveau de la modélisation et d’une
approche hétérogène à l’exécution.
Un procédé peut être décrit à travers un ensemble de modèles (composants) en utilisant le même
formalisme et les mêmes concepts. Chaque modèle est interprété par un ensemble de « handlers ».
L’implémentation en Java de ces « handlers » permet de les porter sur des plate-formes hétérogènes.
Bien qu’Endeavors supporte l’interopérabilité au niveau exécution, l’interopérabilité au niveau
sémantique et syntaxique n’a pas été abordé.
2.4.5.2 Pynode
La principale motivation de Pynode [ABC94], est de développer un environnement interactif et
intégré, supportant des procédés. L’idée consiste à éliminer les aspects monolithiques des
formalismes de procédés, et ainsi fournir des possibilités de réutilisation et d’intégration de
représentations de procédés hétérogènes.
1
Un PSS est un système dans lequel un procédé peut être modelé.
Pynode propose la construction de composants procédés aboutissant à la production d’artefacts
procédés. Un composant procédé est essentiellement un fragment de modèle de procédé écrit dans
un langage de modélisation de procédé. Les composants sont dynamiquement combinés pour
construire un modèle de procédé à travers des interfaces et des ports de connexions.
Les types de ports de l’interface de connexion donnent des relations d’entrée, de sortie et de
synchronisation pour permettre à des composants d’interagir dynamiquement. Les types de ports de
l’interface d’échange permettent aux composants d’échanger des informations (lecture/écriture) de
manière asynchrone durant l’exécution.
L’exécution de procédés est supportée via les vues d’exécution. Une vue d’exécution définit une
collection de composants et de relations de composition. La composition dynamique de composants
via les vues d’exécution avec l’exécution des composants définit l’exécution de procédés.
2.4.5.3 SPMS. Software Process Management System.
Dans SPMS [KTL+92] les composants sont des collections nommées de fragments de procédés
organisés en réseau. Un composant procédé représente un fragment de procédé à un niveau donné
de granularité et complexité, et qui a été élaboré avec suffisamment de détails nécessaires à son
exécution. Les modèles de procédés sont construits à partir d’une hiérarchie de et un réseau de flots
d’informations entre les composants.
Les auteurs décrivent les objectifs d’une approche à base de composants sans décrire la machinerie
de support. Aucune définition rigoureuse du composant procédé n’est fournie ni une description sur la
manière d’implémenter les composants. En général le terme composant est utilisé pour décrire des
fragments de procédés réutilisables. Cependant ce système a été présenté en 1992 avant le boom
courant sur le développement de logiciel à base de composants.
2.4.5.4 OPC. Open Process Components Framework.
L’OPC [GLK97] propose un environnement pour la production de procédés à base de composants.
Dans cette approche, les modèles de procédés sont construits comme un ensemble de composants
qui interagissent à travers des interfaces bien définies. Il propose aussi une infrastructure, pour
l’interopérabilité et la réutilisation de composants procédés hétérogènes, construit selon trois niveaux
d’abstraction.
1. Le niveau méta–modèle qui identifie les entités fondamentales du procédé et leurs relations.
2. La Machine d’états–finis. Représentation du comportement des entités du procédé
3. Un framework orienté objet lié au formalisme de représentation du procédé et à son domaine
d’application.
La figure illustre un exemple sur l’hiérarchie de classes, séparés en trois niveaux, pour le entité
procédé.
Figure 13 : Hiérarchie de classes pour l'entité "procédé"
Le niveau de base dit « framework » qui capture les abstractions de base des entités du procédé.
Les classes et les interfaces de la couche framework servent comme ‘contrat’ minimum que tout
composant doit supporter.
Le niveau de représentation capture les abstraction des formalismes spécifiques. Elle encapsule la
sémantique d’un langage de modélisation du procédé donné.
Le niveau domaine incorpore aux classes les comportements de domaine spécifique à partir
desquelles les composants d’exécution sont dérivés. Ici est possible de contrôler les interactions
entre les composants de type particulier.
2.5 SYNTHESE
Dans ce chapitre nous avons présenté différentes techniques d’interopérabilité décrits dans le
domaine des procédés.
Ces techniques ont évolués dans le temps. La première est l’interopérabilité par échange de données,
qui est caractérisée par :
L'unification des concepts et des terminologies relatives au domaine des procédés.
La proposition d’un modèle générique contenant les éléments et leurs relations afin de rester
indépendant au formalisme de représentation du procédé.
La création d’un formalisme canonique pour l’échange automatique de représentations de
procédés entre des systèmes hétérogènes.
La deuxième technique est l’interopérabilité par le contrôle, dont le but est la communication entre des
moteurs de procédés hétérogènes2, afin qu’ils exécutent ensemble un procédé. Plusieurs protocoles
d’interopérabilité ont été proposés, le plus récent, étant Wf-XML qui est indépendant du mécanisme
de transport (HTTP et CORBA).
La troisième technique est l’interopérabilité par composant, dont les principales caractéristiques sont:
Le contrôle et l’intégration de données sont mis en œuvre à partir d’un modèle à base de
composants.
Les dépendances de données sont réduites en capsulant les composants par des interfaces bien
définies. Ceci permet d’éliminant la traduction entre les différents formalismes de représentation.
Les bénéfices attendus par cette dernière approche sont :
La réutilisation de modèles de procédés (composants) autonomes et fonctionnels.
L'interopérabilité entre composants hétérogènes.
L'évolution dynamique du modèle par composant.
Nous allons proposer dans le chapitre suivant un framework qui couvre les aspects décrits ci-dessus.
Ce framework pourra être étendu afin de répondre à des besoins particuliers pour certaines
applications.
2
Chaque moteur procédé exécute un formalisme particulier
CHAPITRE 3. Notre Approche.
3.1 Introduction.
Dans le domaine de la modélisation des procédés, l’approche par composants vise à construire de
nouveaux procédés de façon coopérative, dans un environnement distribué et hétérogène. Pour qu’un
système puisse supporter de tels besoins, il doit compter sur une architecture physique appropriée.
Comme Les composants sont hétérogènes, on doit implémenter des mécanismes supportant les
niveaux d’interopérabilité décrits dans l’état de l’art. La figure 14 illustre le scénario pour la
construction et l'exécution du procédé « conception d’un logiciel ».
Figure 14 : Conception d'un procédé par composants
Nous allons appliquer la philosophie des objets distribués et des composants pour le développement
des procédés. Au cours de ce chapitre, nous présenterons les concepts de base de notre proposition.
Après, nous menerons à bien le développement d’un framework orienté objet pour des composants
procédés ; il constituera le moteur d’ un environnement centré procédé permettant la modélisation de
procédés par composants. Finalement, nous proposerons un modèle d’interopérabilité par contrôle
des composants procédés.
3.2 Concepts.
3.2.1 Modèle.
Un modèle est la représentation abstraite d’un procédé dans un formalisme donné, qui permet de
comprendre et de simuler. Ce modèle est en suite spécialisé pour obtenir une instance pouvant être
exécutée par un environnement centré procédé.
3.2.2 Composant procédé.
Un composant procédé est l’instance d’un procédé, dérivée d’un modèle stocké dans une base de
données. Le composant encapsule sa représentation et fournit une interface simple pour établir la
communication avec l’extérieur.
Si on approfondit le concept du procédé, un composant correspond à une activité ou à un sous
procédé qui contribue à la réalisation d’un but spécifique dans le procédé. Il vise à générer ou à
modifier un ensemble de produits.
3.2.3 Modélisation basée composants.
Le but de la modélisation basée composant est la construction de modèles plus complexes, à travers
la réutilisation de modèles consistants et fonctionnels. Chacun d’eux constitue un composant procédé.
Voici les points à considérer pour la modélisation par composants :
Construire une base d’information sur les composants réutilisables
Déterminer la fonction de chaque composant dans le nouveau modèle procédé
Composition dynamique des composants hétérogènes
3.2.4 L’exécution basée composants procédés.
Notre vision concernant le support de procédés est un environnement où deux ou plusieurs
composants hétérogènes exécutent et coopèrent de façon distribuée. Cet environnement doit être
capable de rendre l’hétérogénéité et la distribution des composants transparentes. Ainsi, par exemple,
le rôle charge de la modélisation, voit les composant comme des boîtes noires, qu’il utilise pour créer
un nouveau modèle.
3.2.5 Le vocabulaire commun.
La terminologie utilisée dans notre approche est inspirée de [CFF+92]. Ce vocabulaire commun sera
exprimé à travers d’un schéma conceptuel dans le prochain point.
Composant procédé : Il correspond à une activité ou à un sous procédé qui contribue à la
réalisation d’un but dans le procédé. Il vise à générer ou à modifier un ensemble de produits.
Produit, le résultat d’un procédé : Il correspond à des objets tels que des documents, codes ou
services.
Agent : C’est un performeur d’un procédé, cela peut être un humain ou un outil logiciel. Un agent
est caractérisé par les propriétés de son rôle.
Rôle : Décrit l’ensemble de responsabilités, droits et compétences d’un agent dans le contexte des
activités où il intervient.
3.2.6 Le schéma conceptuel procédé.
Un schéma conceptuel procédé rassemble toute l’information des entités qui appartiennent au
procédé, dès que des relations existent entre elles. Le schéma conceptuel pour notre environnement
procédés est illustré par la figure suivante.
EntitéProcédé
Agent
can_perform
agentId : String
1..*
name : String 1..*
ProcessComponet
sieExécution : String
nomProcédé : String
dateCreation : Date
durée : Date
sujet : String
description : String
Role
roleId : String
roleName : enumerate
1..*
assigned_to
1..*
Role( )
~Role( )
AffectRole( )
has_input
0..*
PropriétésComposant( )
TerminerComposant( )
Suspendre( )
1..*
RéprendreComposant( )
AnnulerComposant( )
AttacherObservateur( )
DétacherObservateur( )
ListEvénements( )
Notifier( )
1..*
Produit
produitId : String
produitName : String
version : String
1..*
TransferProduit( )
has_output
has_sub
Figure 15 : Schéma conceptuel
3.2.7 Framework orienté objet
Un framework est un ensemble de classes qui coopèrent et permettent des conceptions réutilisables.
Il apporte de nombreuses fonctionnalités et des relations entre classes d’objets, ainsi qu’une
infrastructure au développeur. On spécialise un framework afin qu’il répond aux caractéristiques d’une
application, par création de sous classes spécifiques à partir des classes abstraites du framework
[GHJ99].
3.2.8 L’état procédé.
L’état procédé correspond au comportement des entités d’un procédé. Le changement d’état est
déclenché par des événements produits quand des méthodes sont exécutées. Par exemple,
l’exécution de la méthode ChangeEtatProcédé(Suspendre) produit l’événement :
( :Composant Procédé, suspendu)
et en suite, il produit un changement d’état de l’entité ComposantProcédé.
3.2.9 Classement hiérarchique
Nous proposons un classement hiérarchique. Il consiste à structurer la base de composants
réutilisables par domaine d’application. Par exemple :
Analyse
Dessin
Implémentation
Test
Chaque domaine d’application peut être raffiné en sous-domaines. Par exemple on peut raffiner
Implémentation en :
Les structures de données
Les composant graphiques
Pour entrer un composant dans la base, on détermine à quel domaine il correspond, puis à quel sousdomaine, et ainsi de suite jusqu'à arriver à l’emplacement qui lui convient.
3.2.10 Architecture de l’Environnement Centré Procédé.
L’architecture correspond à un ensemble des outils nécessaires pour l’exécution d’un procédé. Notre
architecture, est une extension de l’architecture PSEE traité dans l’état de l’art. De telle sorte qu’elle
supporte l’hétérogénéité et la distribution des composants. L’architecture est donc formée par :
L’Interface permettant à l’utilisateur de regarder le développement d’un procédé. L’information
fournie par celle-ci, doit répondre en adéquation avec les besoins inhérents au rôle de l’utilisateur.
Les moteurs d’exécution, chacun étant spécifique à un formalisme donné, regroupent les
différents modules de la définition d’un procédé et les exécutent.
La base d’objets contient la définition des procédés stockés de façon persistante. Il y aura un
gestionnaire de la base d’objets responsable de la cohérence et de la disponibilité des
informations nécessaire aux autres composants de l’environnement.
Le serveur des communications, suppose que des interfaces de communication soient créées
pour les composants et que des protocoles de communication soient établis pour définir les
modalités d’utilisation des services disponibles.
Mécanismes d’interaction.
•
Evénement. Un événement est une action instantanée et non persistante, qui apparaît
pendant l’exécution d’une instance d’un certain procédé. Un événement est levé pour indiquer
l’état actuel de l’instance du procédé.
•
Service d’événements. Au temps d’exécution, le serveur d’événements capture des
événements provenant de l’exécution des composants ; et en suite, il fait la notification à des
composants abonnés à tels événements.
3.3 Modèle pour des Composants procédés.
Le modèle que nous proposons pour des composants procédés, est représenté par la notation
UML[Mul97]. La démarche adoptée consiste à considérer un modèle de procédé, représenté dans un
formalisme quelconque, comme un composant réutilisable, qui fournit une interface simple à des
concepteur de procédés.
Dans ce qui suit, nous allons décrire les diagrammes de modélisation, en commençant par les cas
d’utilisation, puis les diagrammes de séquence, le diagramme d’état et finalement le diagramme de
classes.
3.3.1 Les cas d’utilisation.
A travers la présentation des cas d’utilisation nous mettons en évidence les rôles qu’implique
l’introduction d’un composant procédé dans la modélisation d’un procédé. Nous identifions trois rôles
principaux : celui chargé de la définition d’un composant procédé, celui chargé de l’exécution et celui
chargé de l’observation.
Le premier cas d’utilisation correspond au rôle chargé de la définition des composants procédés au
sein de la modélisation d’un procédé. Il va définir chaque composant procédé, dont les fonctionnalités
et les propriétés sont similaires à un autre, en appliquant les changements à une définition existant
(dans une base de données) de composant. Le chargé de la définition va spécifier la composition des
composants, i.e. comment des composant doivent interagir avec des autres composant procédés.
Le deuxième cas d’utilisation correspond au rôle chargé de l’exécution du composant procédé. Une
fois que le procédé est déclenché, chaque composant sera exécuté dans l’ordre et sous les conditions
définies par celui chargé de la définition.
Le dernier cas d’utilisation est relatif au rôle de celui chargé de l’observation. Les besoins de ce type
d’acteur sont de visualiser l’information concernant les composants qui l’intéressent, en train de
s’exécuter (combien de temps il dispose pour le mener à bien, si le procédé a fini, dans quel état se
trouve-t-il, etc.).
Pour eux la distribution des composants est transparente. Ils les observent et les contrôlent comme si
les composants étaient dans son propre site. Les manipulations de base définis pour les composants
procédés peuvent être résumés de la manière suivante :
1. Définition d’un composant procédé selon le méta modèle.
2. Définir un composant procédé, dont les fonctionnalités et les propriétés sont similaires à un autre,
en appliquant les changements à une définition existante de composant procédé.
3. Spécifier la composition. Comment les composants procédés interagissent avec d’autres
composants procédés.
4. Instancier un composant procédé en spécifiant les liaisons nécessaires pour lui permettre d’être
exécuté.
5. Exécuter un composant procédé.
La figure suivante illustre les différents cas d’utilisation décrits auparavant.
Charge de la
définition
Créer composant
procédé
utilise
Charge de
l'observation
Regarder course
de l'exécution
Exécuter composant
procédé
Charge de
l'exécution
Contrôler l'exécution
Figure 16 : Les cas d'utilisation
3.3.2 Scénarios principaux identifiés au travers des cas d’utilisation.
3.3.2.1 Créer un composant procédé :
1. Le rôle chargé de la définition demande la liste de composants procédés à la base de données.
2. La base de données affiche la liste des composants (à travers une interface de dialogue)
disponibles dans la bibliothèque de composants procédés.
3. Le rôle chargé de la définition d’un procédé sélectionne les composants procédés à partir de
fabriques (factory’s) composants concrets.
4. L’objet FactoryComposant crée un composant procédé concret.
5. La factory est responsable de la création du diagramme de transition d’état du composant en
utilisant le FactoryDiagrammeEtat.
6. Le FactoryDiagrammeEtat crée le DiagrammeEtatComposant.
: Charge de la
définition
: BaseDonnées
: Factory
Composant
: Composant
Procédé
: Factory
DiagrammeEtat
: DiagrammeEtat
Composant
1: Démande liste de
2: Liste de composants
3. Création des composants
4. CréerComposant ( )
5. appelle
6. créé
Figure 17 Diagramme de séquences : création d’un composant procédé
Les objets FactoryComposant deviennent les fabriques de composants procédés. Ils correspondent à
des modèles des composants procédés enregistrés dans une base de données. Chaque modèle a un
formalisme de représentation dépendant de l'environnement centré procédé sur lequel il a été créé.
3.3.2.2 Exécuter un composant procédé
1. Le rôle chargé de l’exécution demande l’instanciation et l’exécution du composant procédé
2. Avec l’instanciation commence proprement l’exécution du composant procédé.
3. Un observateur global est déclenché pour observer le développement de l’exécution pour ce
composant.
: Charge de
l'exécution
: Composant
Procédé
: Observateur
Global
1: Instancier et exécuter
2: Exécution
3: déclencher
Figure 18 Diagramme de séquence : Exécution d’un composant procédé
3.3.2.3 Contrôler l’exécution d’un composant procédé
1. Le rôle chargé de l’exécution active l’observateur global correspondant, avec la méthode
PropriétésObservateur().
2. L’observateur global affiche les propriétés du composant et des sous composants fils, enregistrés
jusqu'à présent.
3. Le rôle chargé de l’exécution demande le changement d’état du composant procédé au travers de
l’observateur global.
4. L’observateur global exécute par exemple, la méthode Suspendre().
5. Quand la méthode s’exécute, il se produit un changement d’état.
6. Le composant procédé notifie le changement d’état à son propre observateurs global et à ceux
observateurs externes intéresses par tel événement.
7. La méthode MisAJour actualise les propriétés enregistrées par l'observateur global.
8. L’observateur global affiche les propriétés plus récentes du composant procédé.
: Observateur
Global
: Charge de
l'exécution
: Composant
Procédé
1. PropriétésObservateur ( )
2. propriétés
3. ChangeEtatProcédé(susprendre)
4. susprendre ( )
5. change d'état
6. Notifier ( )
7.MisAJour ( )
8. PropriétésObservateur ( )
Figure 19 Diagramme de séquence : Contrôle de l'exécution
3.3.2.4 Abonner un observateur global externe.
1. L’observateur global externe demande à être abonné à des événements via la méthode
AttacheObservateur()
2. Le composant procédé retourne la liste d’événements.
3. L’observateur sélectionne le ou les événements auxquels il veut s’abonner.
4. Validation de l’attachement pour éviter par exemple d'abonner plusieurs fois un observateur au
même événement ou bien d'abonner un observateur sans permission.
5. Si l’attachement est validé, le message de confirmation est envoyé.
6. En même temps le composant procédé fait l’attachement de l'observateur.
7. Dans l'autre cas le composant envoie un message d’erreur.
: Observateur
Global
: Composant
Procédé
1. AttacheObservateur ( )
2. liste d'événements
3. Selection d'événements
4. validation
5. Message de confirmation
if attachement valid
6: attachement
7. Message d'erreur
else
Figure 20 Diagramme de séquence : Abonnement un observateur
3.3.3 Diagramme de transition d’états.
Les états qui peuvent arriver au composant procédé sont :
Figure 21 : Diagramme de transition d'états pour un composant procédé
Bien que le composant procédé a été mis en exécution, le rôle chargé de l’exécution pourra
abandonner le composant procédé
Le composant procédé passe de l’état prêt à l’état exécution avec l’arrivée de l’événement
« débutProcédé »
Si l’exécution est menée à bien sans erreurs, alors le composant sera terminé normalement.
Si pendant l’exécution, des erreurs interviennent, le rôle chargé de l’exécution peut prendre une
des deux décisions suivantes, dépendant du type d’erreur.
Suspendre le procédé pour corriger le problème et après reprendre l’exécution. Mais si ce
n'est pas possible de le corriger, alors le rôle chargé de l’exécution pourra abandonner le
procédé.
Il peut opter pour l'abandon du procédé.
3.3.4 Diagramme de classes
Dans la suite, nous décrivons le framework orienté objet permettant la définition des composants
procédés selon le méta modèle ; la création des composants procédés dont les fonctionnalités et
propriétés sont similaires à un autre, en appliquant les changements à la définition d’un composant
procédé existant ; finalement l’instanciation d’un composant procédé en spécifiant les liaisons que lui
permet d’être exécuté.
appelle
0..*
appelle
0..*
Agent
agentId : String
name : String
Rôle
roleId : String
roleName : Enumerate
a_par_rôle
1..*
1..*
Role( )
~Role( )
AffectRole( )
selec_facteur_concret
0..*
1..*
DaigrammeEtatComposant
Etat : String
description
CréerComposant( )
a_DiagrammeEtat
0..*
assigné_à
assigné_à
1..*
lié_à
0..*
PropriétésObservateur( )
MiseAJour( )
ProcédéTerminé( )
ChangeEtatProcédé( )
crée
FactoryComposant
NomFacteur : String
crée
ObservateurGlobal
idObservateurGlobal : String
siteExécution : URL
InfoProcédé : Elément
FactoryDiagrammeEtat
nomEtat : String
0..*
abonne
0..*
sous
ComposantProcédé
siteExecution : URL
dateCreation : Date
durée : Période
sujet : String
BaseDonnés
idBasedonné
stocke
0..*
0..*
SusprendreComposant( )
< exécuter
AnnulerComposant( )
AttacheObservateur( )
DetacheObservateur( )
ListEvénements( )
Ajouter( )
Modifier( )
Suprimer( )
Notifie( )
MoteurProcédé
idMoteurProcédé : String
nomMoteurProcédé : String
produit
0..*
Attribut
< a_attribut
nomAttribut : String
0..*
type : String
ComposantMetaData
nomComposant : String
a_shema
a_method
capture
Schéma
nomShema : String
0..*
0..*
Evénement
nomEvénement
AffectEtat( )
0..*
<déclenche
Méthode
nomMéthode : String
name : type = initval
Figure 22 Diagramme de classes : Framework pour des composants procédés
On peut identifier trois patrons basiques dans ce modèle: fabrication ( factory ), observateur
(observer) et façade (façade) dans le sens de Gamma [GHJ99]. Dans ce qui suit nous allons analyser
ces patrons et les classes principales qui constituent notre framework.
3.3.4.1 Le patron Fabrication.
Nous proposons un framework conçu pour la modélisation susceptible d’intégrer différents
composants procédés. Les classes basiques dans notre modèle de fabrication sont :
FactoryComposant et ComposantProcede. Ce sont deux classes abstraites, par conséquent, nous
devons en dériver des sous classes pour réaliser l’implémentation spécifique d'un composant
procédé.
Par exemple, considérons le composant procédé représenté dans le formalisme APEL. Alors
modèleAPEL devient la classe concrète de FactoryComposant et test la classe concrète de
ComposantProcédé.
a_sous
0..*
ComposantProcédé
siteExecution : URL
dateCreation : Date
durée : Période
sujet : String
appelle
0..*
FactoryComposant
NomFacteur : String
crée
0..*
CréerComposant( )
AnnulerComposant( )
ListEvénements( )
Notifie( )
modèleAPEL
CréerProcédéInstance( )
ListeInstances( )
Test
Figure 23 Diagramme de classes : Patron fabrication
L’interprétation pour le diagramme de classes de la figure 23 :
ComposantProcede : définit l’interface des objets créés par le FactoryComposant.
FactoryComposant : déclare la fabrication, celle-ci renvoie un objet de type Composant Procede.
Le test implémente l’interface ComposantProcede.
ModelApel surcharge la fabrication pour renvoyer un objet de type test.
3.3.4.2 L’Observateur global
Rôle
Agent
à_par_rôle
agentId : String
1..*
1..*
name : Strng
roleId : String
roleName : Enumerate
Role( )
~Role( )
AffectRole( )
ComposantProcédé
assigné_à
ObservateurGlobal
lié_à
idObservateurGlobal : String
siteExécution : URL
InfoProcédé : Elément
PropriétésObservateur( )
MiseAJour( )
ProcédéTerminé( )
ChangeEtatProcédé( )
siteExecution : URL
dateCreation : Date
durée : Période
sujet : String
0..*
0..*
abbonne
0..*
AnnulerComposant( )
ListEvénements( )
Notifie( )
sous
Figure 24 Diagramme de classes: L'observateur global
La classe observateur global, illustré par la figure 24, a deux types de relations :
La relation lié_à définit une relation d’un observateur global avec un composant procédé. Ici la tâche
de l’observateur est d'enregistrer l’information plus importante sur le composant procédé auquel il
appartient et l’information sur les possibles sous composants fils, tel que : nom du composant, son
état, la durée, le rôle responsable de l'exécution du composant, etc. L’observateur a le contrôle sur le
composant et sur ses sous composants fils ; en lui peut par exemple, modifier l’état du ou des
composants procédés.
La relation abonné définit une interdépendance de façon telle que, quand le composant procédé
change d’état, tous ceux observateurs globales externes qui en dépendent soient notifiés, et
automatiquement mis à jour. L’observateur global externe n’aura pas la permission de modifier
l’état du composant procédé en question.
3.3.4.3 Le patron de façade.
La classe ComposantProcédé joue le rôle de façade : elle doit offrir à l’utilisateur une interface unique
et simple vers les services du composant procédé. Elle connaît les classes pour une requête. Mais
les classes du sous système ne connaissent pas la façade, c’est à dire qu’elles n’ont pas de référence
à celle-ci. Les observateurs communiquent avec le composant procédé en envoyant des requêtes à la
façade, qui répercute celles-ci aux objets appropriés du sous-système.
3.3.4.4 Le ComposantMétaData.
Le composant procédé produit des méta données constituées par les classes : attribut, méthode et
événements. On peut ainsi manipuler l’information et des opérations des composants procédés. Il
suivi un schéma conceptuel bien établi. La figure 25 illustre le diagramme de classes correspondant.
a_sous
0..*
ComposantProcédé
siteExecution : URL
dateCreation : Date
durée : Période
sujet : String
AnnulerComposant( )
ListEvénements( )
Notifie( )
produit
0..*
Attribut
< a_attribut
nomAttribut : String
type : String
ComposantMetaData
nomComposant : String
0..*
a_Schema
capture
a_method
1..*
Schéma
nomShema : String
0..*
0..*
Evénement
nomEvénement
AffectEtat( )
0..*
<déclenche
Méthode
nomMéthode : String
name : type = initval
Figure 25 : Diagramme de classes: Méta données produits par un composant procédé
3.3.4.5 Fonctionnement de la machine d'exécution : exemple.
Remarquons, que la création et l’exécution d’un modèle par composants est assez dynamique,
surtout car elle peut impliquer l’exécution parallèle de plusieurs composants, chaque composant à son
tour peut déclencher l’exécution de d'autres sous composants parallèles, enchaînes ou imbriqués
(modèles étudiés dans l’état de l’art).
Analysons un exemple pratique: Le procédé test dans le développement d’un système logiciel. Les
sous-composants du test sont : test d’intégration et test unitaire. Chacun d’eux reçoit comme entrée
un plan de test, ils fournissent un documents contenant le rapport du test. Par chaque composant il
existe un rôle gestionnaire responsable de exécution, pour chaque composant procédé. La figure 26
illustre le schéma pour le test avec des éléments décrits au dessus :
Figure 26 : Le schéma pour test
Le composant « test unitaire » est le niveau de test plus bas réalisé pour les classes, les blocs et
les paquets de service.
Le but composant « test d’intégration » est de tester si différentes unités développées
fonctionnent correctement ensemble.
Chaque composant décris au dessus est composé, à son tour, de sous-composants test dans son
domaine d’application. Pour simplifier notre exemple, nous considérons le cas où l’exécution du test
se trouve dans le niveau plus bas, i.e. dans les composants d’unité.
La création de composants procédés est mené à bien par des fabriques « factory » illustrés par l’arbre
à gauche de la figure 27. En cours d’exécution, une factory en appele une autre pour demander la
création d’un composant procédé. La phase d’exécution est illustré par l’arbre à droite, ici le
composant test lance l’exécution des sous composants test unitaire, il à son tour lance l’exécution en
parallèle des sous composants test d’unité. Le composant test d’intégration est mis en exécution, une
fois que les test d’unité ont fini leur exécution.
Figure 27 : Arbres illustrant la création et exécution des sous composants test
Regardons le comportement de la machine d’exécution pour le composant test au travers des
diagrammes de séquence suivants :
Le composant test demande la liste de composants procédés à la base de données. Après il appelle
l’outil qui va créer le composant sélectionné. Cet outil va créer l’environnement nécessaire pour mener
à bien l’exécution du composant procédé TestUnitaire, à savoir : le diagramme d’états, les variables,
etc. En suite un événement est diffusé signalant l’existence du nouveau composant TestUnitaire. Test
lance l’exécution de ce composant, et un autre événement est diffusé signalant le début de l’exécution
de TestUnitaire. Quand il termine son exécution, l’evénément terminé est diffusé via le gestionnaire
d’événements.
Test : Composant
Procédé
: BaseDonnées
TestUnitaire :
ComposantProcédé
: Environnement
de test
: Gestionnaire
Evénements
Démande liste composants
nom de l'outil
nom de l'outil
créer
Evénement "création composant"
lancer exécution
Evénément "début exécution"
fin d'exécution
Evénement "terminé"
Figure 29 Diagramme de séquences pour exécution de Test
La figure 29 illustre l’intéropérabilité entre des composants basé sur des événements. Le composant
test s’abonne a des événements fin de l’exécution du TestUnitaire et TestIntegration. Le composant
testUnitaire est en train de s’exécuter. Quand le TestUnitaire termine son exécution, un événement
« terminé » est diffusé par le gestionnaire d’événements, et en suit il renseigne le composant test sur
le changement d’état.
Après, le composant procédé lance l’exécution du composant TestIntégration. Cette action déclenche
l’événement « débutProcédé ». La fin de l’exécution du composant TestIntégration finalisera le
composant Test. Ce composant notifiera aux observateurs abonnés à l’événement «terminé Test»
afin de que ceux ci déclenchent des actions propres à son exécution.
Test : Composant
Procédé
TestUnitaire : Composant
Procédé
TestIntegration :
ComposantProcédé
: Gestionnaire
Evénements
abonnement événement fin d'exécution test unitaire
abonnement événement fin d'exécution test
fin d'exécution
événement "TestUnitaire Terminé"
test unitaire a été Terminé
lancer exécution
événement "débutProcédé"
test d'intégration en "exécution"
Fin de l'exécution
événement "TestIntégration Terminé"
test d'intégration a étéTerminé
Fin de l'exécution
événement " Test Terminé"
Figure 30 Diagramme de séquence : interopérabilité entre des composants procédés
Le diagramme d’état de notre exemple est illustré par la figure ci dessous. Remarquons que tous ces
sous composant auront le même comportement, la récursivité est indiquée par la flèche « créer sous
composant test ».
Figure 31 : Diagramme de transition d'état pour le composant test
Chapitre 4 Prototypage
Dans cette section nous allons présenter le prototype permettant la mise en œuvre du modèle de
composants procédé. Nous présentons les interfaces de dialogue pour la création d’un modèle par
composants, et pour la gestion de l’exécution de chacun des composants procédés.
4.1 Modèle par composants procédés.
Cette fenêtre permet de réaliser la modélisation d'un procédé par sélection de composants procédés.
Description.
Dans champ « Créer modèle » on doit entrer le nom du modèle à développer.
La liste composants disponibles affiche tous les composant procédés disponibles dans la base de
données.
La liste composants inclus affiche des composants sélectionnés par l’utilisateur.
Les boutons : Dépendances, Stocker, Exécuter y annuler.
Fonctionnalité.
On sélectionne les composants à partir de la liste des Composants disponibles. Pour ajouter un
composant à la liste de Composants inclus, on appuie sur le bouton « >> ». L’action inverse
« << », retire le composant sélectionné de la liste de composants inclus.
Les dépendances pour chaque composant sélectionné pourront être remplies en appuyant sur le
bouton Dépendances…
Le bouton Stocker sauvegarde le modèle par composants
Le bouton Annuler ferme la fenêtre sans sauvegarder le modèle par composants.
Le bouton Exécuter démarre l’exécution du modèle par composants.
Figure 32 : Fenêtre pour créer un modèle par composants
4.2 Dépendances.
La fenêtre de propriétés permet de remplir l’information nécessaire dans le contrôle des composants
procédés.
Description.
Le champ nom composant procédé permet de sélectionner un composant procédé de la liste de
composants inclus dans le modèle par composants. L’information à remplir est :
Rôle responsable de l’exécution
Date de début de l’exécution du composant procédé
Date de terminaison de l’exécution du composant procédé
Le Composant source correspond au procédé qui lui précède dans le flux d’exécution du modèle.
Produit entrant correspond au document que le composant procédé recevra du composant source
liée avec lui.
Le Composant cible correspond au procédé qui lui précède dans le flux d’exécution du modèle.
Produit sortant correspond au document que le composant procédé envoiera à l’autre composant
lié à lui.
Figure 33 : Fenêtre pour remplir les dépendances entre composants
4.3 L’observateur global.
La fenêtre de l’observateur global affiche le temps d’exécution et l’état actuel d’un composant procédé
de son domaine. A partir de cette fenêtre le rôle chargé de l’exécution d’un composant procédé pourra
modifier l’état du composant procédé ou du sous procédé dérivé du premier.
Fonctionnalité.
Dans le champ Composant Procédé apparaît par défaut le composant procédé père ;
Dans la liste de sous composant apparaît ses fils. Par chaque fils sélectionné la liste de sous
composants sera rafraîchie, avec des sous composants procédés propres à celui-ci.
Le champ état actuel permettra de changer l’état du composant sélectionné : exécution,
abandonné, suspendu et repris.
Le bouton dépendances affiche la fenêtre Dépendances en mode lecture uniquement.
Figure 34 : Fenêtre pour observer cours de l'exécution des composants
Chapitre 5. Conclusion et perspectives
Ce travail s’inscrit dans le cadre d’une recherche sur le support automatisé aux procédés logiciels.
Une approche à base de composants est proposée pour distribuer, faire intéropérer et réutiliser des
procédés. Les bénéfices attendus de cette recherche sont :
L’Interopérabilité : Différentes représentations de procédés peuvent être supportées.
La réutilisation : Un composant procédé est une unité qui peut être décrite, déployée et manipulée
indépendamment d’autre composants.
Le support aux procédés dynamiques. Un composant est défini avec le modèle et les informations
d’instanciation permettant au composant de gérer sa propre évolution. Un composant possède
des informations génériques (framework), spécialisées (adaptation) et d’instanciation. Ainsi un
composant peut s’adapter aux situations dynamiquement.
Le but de notre travail est une contribution à cette recherche. Nous proposons un framework orienté
objet pour le support aux procédés. Les principales contributions de notre travail sont :
La présentation des concepts et de la terminologie qui caractérisent la technologie de procédés.
La proposition d’un framework orienté objet pour le support de procédés. Les principales
caractéristiques de notre framework sont :
extensible pour couvrir les fonctionnalités d’une application particulière.
interopérabilité par événements. L’encapsulation du composant permet de l’utiliser sans avoir
besoin de connaître son fonctionnement.
intégration dynamique de composants car chaque composant est indépendant.
Un prototype qui présente l’interface graphique pour l’environnement supportant la modélisation
par composants. Ce prototype est en cours de construction.
Les perspectives de ce travail sont :
La proposition d’un langage de définition de composants basé sur XML.
La construction de composants procédés. Prendre différents modèles existants, les encapsuler et
leur fournir une interface simple pour leur utilisation.
La création d’une bibliothèque de composants réutilisables dans laquelle l’utilisateur sélectionnera
des composants pour sa modélisation.
La mise en œuvre du protocole d’interopérabilité par contrôle basé sur le standard Wf XML et de
l’environnement d’exécution des procédés.
.
Bibliographie.
[Ami99]
Amiour, Mahfoud, Vers une fédération de composants interopérables pour les
environnements centrés procédés logiciels, Thèse de Doctorat, Université Joseph
Fourier, Grenoble I, juin 1999.
[AK94]
Armitage, J. and Kellner, M. A Conceptuel Schema for Process Definitions and
Models. In Procedings of the third International Conference on the Software Process
(ICSP3), pp. 153-165, Reston, VA. Octoer, 1994.
[ABC94]
Avrilionis, D., Belkhatir, N., and Cunin P. A Unified Framework for Software Pocess
Enactment and Improvement. Proceedings of the Fourth International Conference on
the Software Process (ICSP4).
[ABC96]
Avrilionis, D., Belkhatir, N., and Cunin P. Improving Software Pocess Modelling and
Enactment Techniques. Proceedings of the Fifth European Workshop on Software
Process Technology (EWSPT’96), pp. 65 – 74, Nancy, France. October 1996.
[Avr96]
Avrilionis, D., Mécanismes pour l’Evolution et la Réutilisation des processus de
Production de Logiciels, Thèse de Doctorat, Université Joseph Fourier, Grenoble
I,1996.
[BK95]
Ben – Shaul, I. and Kaiser, G. An Interoperability Model for Process – Centered
Software Engineering Environments and its Implementation in OZ. Technical Report
CUCS – 034 – 95, Computer Science Department, Culumbia University, 1995.
[BK98]
Ben–Shaul, I. and Kaiser, G. Federating Process–Centered Environments : the OZ
Experience. Journal of Automated Software Engineering, vol. 5, no. 1, pp. 97 – 132.
January 1998.
[CKO92]
Curtis, B., Kellner M., and Over, J., Process modeling, Communications of the ACM,
35(9) : 75-90, Septembre 1992.
[BFL94]
Bonjour M., Falquet G. and Léonard M. « Bases de concepts et d’intégration de bases
de données » INFORSID’94, Aix-En-Provence, France 1994.
[Boy94]
Boyer, F., « Coordinations entre outils dans un environnement intégré de
développement de logiciels ». Thèse de doctorat de l’Université Joseph Fourier,
Grenoble 1, février 1994.
[BT96]
Bolcer, G-A, Taylor, R-N, Endeavors : A Process System Integration Infrastructure, In
procedings of the IEEE, August 1996.
[Che]
Chen, H., Collaborative Systems : Solving the Vocabulary Problem. In IEEE computer,
May 1994, pp.58-66.
[CFF94]
Conradi, R. Fernström, C., and Fuggetta, A. Concepts for Evolving Software Process.
In Software Process Modeling and Technology, A. Finklestin, J. Kramer, and B.
Nuseibeh (Eds.), pp. 9 – 31. John Wiley, 1994.
[CFF+92]
Conradi, R. Fernström, C., Fuggetta, A. and Snowdon R. Towards a Reference
framework for Process Concepts, Proceedings of the second European Workshop on
software Process Technology (EWSPT’92), pp. 3-17, Trondheim, Norway. Septembre
1992.
[CJ99]
Conradi, R. and Jaccheri L. Process Modeling Languages, Chapter 3, pp 27-52. In
[DKW99],1999.
[Der94]
Derniame, J.-C. and all. « Life Cycle Process Support in PCIS. » In Proceedings of
PCTE’94, San Francisco, november 1994.
[DKW99]
Derniame J-C, Kaba B. A., Wastell D., Software Process : Principles, Methodology,
and Technology, LNCS. pp.1500, Springer, 1999.
[EAD98]
Estublier, Jacky, Amiour, Mahfoud and Dami, Samir, Building a Federation of Process
Support Systems, Septiembre, 1998, Rapport interne group ADEL.
[FH93]
Feiler P.H., and Humphrey W.S., Software Process Development and Enactment :
Concepts and Definitions. In proceedings of the Second International Conference on
the software Process. IEEE Computer Society Press,1993, pp. 28-40.
[GHJ99]
Gamma E., Helm R., Johnson R., Vlissides J., Design Patterns : Catalogue de
modèles de conception réutilisables, Traduction de Jean-Marie Lasvergères, Ed.
Vuibert Informatique, 1999, 459 pages.
[GLK97]
Gary K., Lindquist T., Koehnemann H. Component-based Process Modeling. May
1997. Available at http://pooh.eas.asu.edu/yfppg/pubs/abstracts.5.html#pgfId=282178
[Hei92]
Heimbigner, D. The Process Wall : A Process State Server Approach to process
Programming. Proceeding of the Fifth ACM SIGSOFT Symposium on Software
Development Environments, pp. 159-168, Tyson’s Coners, VA, December 1992.
[JCJ+93]
Jacobson, I., Christerson, M., Jonsson, P. Övergaard, Gunnar, Le génie logiciel
ème
Orienté Objet, Ed. Addison-Wesley, 2
Edition, 1993, 536 pages
[KTL+92]
Krasner, H. Terrel, J. Linehan, A., Arnold, P. and Ett, W.H. Lessons Learned from a
Software Process Modeling System. Communications of the ACM, vol. 35(9), pp. 9110. September 1992.
[LGJ+98]
Lee, J., Gruniger, M., Jin, Y., Malone, T., Tate, A., Yost, G., and the PIF Working
Group, The PIF Process Interchange Format w.1.2. Available at http://ccs.mit.edu/pif,
Decembre 8 1997. Also published in The Knowledge Engineering Review, vol 13(1),
pp. 91-120. Cambridge University Press. March 1998.
[LD97]
Lindquist, T., Derniame J.C.Towards Distributed and Composable
Components. May 1997 Available at
http://pooh.eas.asu.edu/yfppg/pubs/abstracts.5.html#pgfId=282178
[Lon94]
Lonchamp, J., An Assesment Excercice, chapter 13, pages 335-356. In Software
Process Modelling and Technology, research Studies Press LTD, Tauton,
Somerset,England, 1994.
[Lon93]
Lonchamp, J., A Structured Conceptuel and Terminological Framework for Software
Process Enginnering. In proceedings of the Second International Conference on the
software Process. IEEE Computer Society Press,1993, pp. 41-53.
ère
Muller Pierre-Alain, Modélisation objet avec UML, Ed. Eyrolles, 1 edition, Paris
1997, 421 pages
[Mul97]
[NWM93]
[OMG98]
[OHE99]
Process
Nicol, J.-R., Wilkes T., and Manola F.-A. Objet Orientation in Heterogeneous
Distributed Computing Systems. IEEE Computer, june 1993 pp. 57-67.
Objet Management Group. Workflow Management Facility Submission (jFlow). OMG
Document Number bom/98-06-0. July 4 1998.
Orfali R., Harkey D., Edwards J., Client/Serveur : Guide de survie. Troisième édition.
Traduction de françois Leroy et Jean-Pierre Gout. Edit. Vuibert, Paris 1999, 782 pages
[Sch99]
Schaefer W. editor, Architectural Views and Alternatives, chapter 5, pp. 95-116. In
[DKW99],1999
[SW92]
Smith B., and Wellington J., TC184/SC4 Reference Manual, Technical Report,
International Organisation for Standarisation, April 1992.
[Swe98]
Swenson, K. Simple Worflow Acess Protocol (SWAP). Internet Draft Netscape
Communications Corp. Available at http://www.ics.uci.edu/~ietfswap/swap-prot.txt.
August 7, 1998.
The Workflow Management Coalition. The reference Model. WfMC Document Number
TC-1003, Issue 2.0, jan 1995.
[WfMC95]
[WfMC96]
The Workflow Management Coalition. Terminology and Glossary. WfMC Document
Number WFMC-TC-1011, Issue 2.0, June 1996.
[WfMC98]
The Workflow Management Coalition. Interface 1 : Process Definition Interchange.
WfMC Document Number TC-1016, November 1998.
[WfMC2-1]
The Workflow Management Coalition. Interoperability Abstract Specification. WfMC
Document Number TC-1012, new version June 2000.
[WfMC2-2]
The Workflow Management Coalition. Interoperability Wf-XML Binding Document
Number TC-1023, FINAL SPECIFICATION May 8, 2000.
[WfXML]
The Workflow Management Coalition. Proposal for an Asynchronous HTTP binding of
Wf-XML. June 1, 2000.
[Was90]
Wasserman A. « Tools Integration in Software Engineering Environnements. In
Software Engineering Environnements : International Workshop on Environnements,
Berlin 1990.

Une approche à base de composants pour la

Transcription

Documents pareils

correction

La fabrication - GIE SESAM

Crit, spécialiste du recrutement et des prestations de ressources

Usine nouvelle - le spécialiste du traitement fin

Peinture 2K-époxy «antistatique»

Vos interlocuteurs - Orne Développement

VITA PLUS - Proquimia

crocodile physics

Fiche d`utilisation de Crocodile Physics

Eco-conception en ennoblissement textile