Upload
lyduong
View
215
Download
1
Embed Size (px)
Citation preview
| 21
Prépublication n° 11 | Fascicule n° 2
Spécification des processusworkflows évolutifs versionnés
Mohamed Amine Chaâbane, Lotfi Bouzguenda, Rafik Bouaziz, Faiez GargouriMIRACL-ISIMS, Route Mharza km 1,5, CP 3018, Sfax, Tunisie
[email protected], [email protected], [email protected],
Résumé :
Les processus d’entreprises évoluent suite à toute modification des actions / tâches (modèle de
processus), des données (modèle informationnel) et/ou des acteurs (modèle organisationnel).
Nous les appelons Processus Workflows Évolutifs (PWE). Cet article propose de spécifier des PWE
à l’aide des Réseaux de Petri à Objets (RPO), d’une part, et du versionnement, tel que utilisé
dans le domaine des Bases de Données Temporelles (BDT), d’autre part. Si les RPO sont bien
appropriés à la spécification des trois modèles (organisationnel, informationnel et processus) des
processus workflows stables, ils ne suffisent pas pour décrire les processus qui évoluent dans le
temps. Pour pallier cette limite, nous proposons une nouvelle approche basée sur une utilisation
conjointe des RPO et du versionnement pour assurer une spécification de bonne qualité des PWE
et la tenue de leurs différentes versions.
Mots-clés : processus workflows évolutifs, réseaux de petri à objets, versionnement,
versions.
1 Introduction
L’objectif du workflow est d’automatiser les processus des organisations [1]. Un processus
(e.g. suivi de dossier médical) est un enchaînement coordonné de tâches, suivant un certain
schéma, aboutissant à un résultat bien déterminé. Durant l’exécution d’un processus, dif-
férents formulaires, documents et informations sont partagés ou sont transmis d’un poste
de travail à un autre pour être traités.
Trois modèles sont généralement utilisés pour décrire la structure du processus [2], les
ressources et les informations nécessaires à sa mise en œuvre. Le Modèle Organisation-
nel (MO) structure les ressources en rôles et leur attribue des autorisations pour réaliser
les tâches composant le processus. Le Modèle Informationnel (MI) décrit la structure des
formulaires, des documents et des données qui sont utilisés et produits par le processus.
Mohamed Amine Chaâbane, Lotfi Bouzguenda, Rafik Bouaziz, Faiez Gargouri« Spécification des processus workflows évolutifs versionnés »
Schedae, 2007, prépublication n° 11, (fascicule n° 2, p. 21-29).
22 |
Le Modèle de Processus (MP) définit les tâches composantes, leur coordination, les infor-
mations et les ressources impliquées dans chaque tâche. C’est le MP qui constitue le com-
posant pivot d’un workflow, assurant le lien entre les différentes ressources impliquées et
les différentes informations utilisées.
Nous avons montré dans [3], à travers une étude comparative de quelques langages
existants, que les Réseaux de Petri à Objets (RPO) [4] sont bien adaptés pour spécifier des
processus workflows stables, bien identifiés et prévisibles. Cependant, les RPO n’intègrent
pas la dimension temporelle ; il est donc impossible d’intégrer l’évolution des processus
workflows qui subissent des modifications fréquentes de leurs actions / tâches (modèle de
processus), de leurs données (modèle informationnel) et/ou de leurs acteurs (modèle organ-
isationnel). Pour pallier cette limite, nous proposons dans cet article d’utiliser : (i) les RPO, en
tant que langage formel, pour spécifier les processus workflows, à travers leurs trois mod-
èles (informationnel, organisationnel et processus). (ii) le versionnement, tel que défini dans
le domaine des Bases de Données Temporelles (BDT) [5], pour prendre en considération
l’évolution de ces processus dans le temps.
La suite de cet article est organisée comme suit : La section 2 présente les motivations
pour l’utilisation des RPO en tant que langage de spécification des processus workflows
stables et bien définis, ensuite elle le présente brièvement, et enfin elle expose leur limite
majeure ; la non possibilité de prendre en compte l’évolution des processus dans le temps.
La section 3 introduit le versionnement, en tant que technique d’historisation de l’infor-
mation temporelle. La section 4 décrit les principes de notre approche et présente notre
contribution, consistant à utiliser conjointement et d’une manière cohérente les RPO et le
versionnement. La section 5 situe le travail réalisé par rapport aux travaux existants dans la
littérature et la section 6 dresse un bilan de l’article et donne la perspective de nos futurs
travaux.
2 RPO : Un langage approprié pour la spécification des proces-sus workflows
2.1 Motivations pour l’utilisation des RPOTout d’abord, plusieurs raisons justifient l’utilisation des Réseaux de Petri (RP) dans le con-
texte du workflow [6] :
– un pouvoir d’expression approprié puisque les RP permettent de décrire clairement
les différentes tâches composant un processus workflow et leur coordination ;
– une représentation graphique qui aide au processus de spécification du workflow ;
– une sémantique opérationnelle qui facilite le passage des spécifications à l’exécu-
tion ;
– des fondements théoriques qui permettent l’analyse, la vérification de propriétés
comportementales et l’évaluation de performances.
Cependant, les RP se concentrent sur le processus lui-même et n’accordent que peu d’at-
tention aux autres dimensions du workflow, à savoir le modèle organisationnel et le modèle
informationnel. Comme indiqué précédemment, les RPO étendent les RP en intégrant des
structures de haut niveau (en l’occurrence des objets) et permettent de modéliser les ac-
teurs du modèle organisationnel et les actions qu’ils réalisent ainsi que les informations et
données du modèle informationnel.
2.2 Une rapide présentation de RPOLes RPO proposent un formalisme qui combine la technologie des Réseaux de Petri [7]
et l’approche Orientée Objet (OO). Les RP sont utilisés pour décrire la dynamique d’un
Schedae, 2007, prépublication n° 11, (fascicule n° 2, p. 21-29).
| 23
système, tandis que l’approche objet permet de modéliser les acteurs et les informations
du système. Un modèle RPO est constitué, comme tout modèle RP, de places, d’arcs et de
transitions. Dans les RPO, les jetons du réseau font référence à des objets. Plus précisément,
les caractéristiques propres à un RPO sont les suivantes :
– Les places sont typées. Le type d’une place prend le type d’un objet. Un jeton dans
une place a une valeur conforme au type de la place et la valeur d’une place est
l’ensemble des jetons qu’elle contient ;
– Les arcs sont étiquetés. Chaque arc est étiqueté par une variable du type de la place
auquel l’arc est relié. Les variables jouent le rôle de paramètres formels pour une
transition et définissent les jetons qui circulent des places d’entrée vers les places de
sortie de la transition ;
– une sémantique opérationnelle qui facilite le passage des spécifications à l’exécu-
tion ;
– Chaque transition est décrite par un triplet (pré-condition, action, règle d’émission).
La pré-condition est une expression logique faisant intervenir les variables d’entrée
(c’est-à-dire les variables des arcs d’entrée allant d’une place d’entrée à la transi-
tion). L’action décrit le code à exécuter pour franchir la transition. Cette action n’est
exécutée que si la pré-condition est vérifiée. Les règles d’émission sont des expres-
sions logiques qui traduisent les résultats possibles après l’exécution de l’action. Plus
précisément, ces expressions logiques déterminent les arcs et les places de sortie.
2.3 Limite majeure des RPO pour les PWEDans ce qui suit, nous présentons la limite majeure des RPO pour les PWE à travers un exem-
ple illustratif. Il s’agit du PWE d’inscription des nouveaux étudiants en troisième cycle [8]. Ce
processus est constitué essentiellement de deux tâches. La première tâche, « Enregistrement
Demande », consiste à enregistrer les demandes d’inscription par la secrétaire au début de
mois de septembre de chaque année. La demande sera rejetée si elle est incomplète. La
deuxième tâche, « Entrevue », consiste à passer une entrevue entre l’étudiant concerné et
un examinateur. Suite à l’entrevue une autorisation d’inscription est accordée à l’étudiant
si l’examinateur donne un avis favorable ; autrement il y a rejet d’inscription. La figure 1
modélise ce processus d’inscription à l’aide des RPO.
Cependant, l’université a constaté que les entrevues constituent une tâche difficile pour
les demandes arrivant en retard ; souvent l’université doit faire appel, pour réaliser les entre-
vues à des gens ayant de l’expérience, qualifiés (professeurs, chefs de laboratoires, etc.) et
doit tenir compte de leur disponibilité. Elle a décidée alors d’adopter un nouveau processus
pour les demandes d’inscription reçues après le 30 septembre. Chaque demande doit être
accompagnée d’un CV détaillé de l’étudiant, qui sera examiné par l’examinateur de la for-
mation doctorale. Seuls les étudiants retenus après une présélection des CV peuvent passer
l’entrevue. Ce nouveau processus modélisé en figure 2, utilise le processus initial (cf. figure
1) mais lui ajoute la nouvelle transition (modélisant une tâche) « Examen CV » et la nouvelle
classe d’objets CV. Les éléments ajoutés sont représentés en gris. Cependant, il est difficile
de décrire à l’aide des RPO les deux processus dans un modèle unique pour tenir compte
de l’évolution subie dans le temps. En conclusion, les RPO dans leur état actuel sont peu
adaptés pour modéliser des PWE. Cet article montre la nécessité de maintenir des versions
de processus à utilisation alternative. On peut aussi avoir besoin de maintenir des versions
historiques pour rester capable d’expliquer le comportement du système à tout moment.
Schedae, 2007, prépublication n° 11, (fascicule n° 2, p. 21-29).
24 |
Fig. 1: Processus d’inscription d’un nouveau étudiant en troisième cycle.
Fig. 2: Processus d’inscription d’un nouveau étudiant après le 30 septembre.
3 Le Versionnement :Une technique d’historisation de l’information temporelle
Une Base de Données Temporelles (BDT) est définie comme une BD supportant des faits
temporels et des faits non temporels. Un fait temporel est un fait caractérisé dans le temps
par plusieurs valeurs, dont on a besoin de garder trace. C’est le cas du salaire d’un employé
qui évolue dans le temps et dont les valeurs historiques intéressent l’application gestion
des carrières. Pour l’historisation des faits temporels, les BDT utilisent principalement deux
Schedae, 2007, prépublication n° 11, (fascicule n° 2, p. 21-29).
| 25
types de temps : le temps de validité et le temps de transaction. Le temps de validité d’un
fait est le temps de sa validité dans le monde réel alors que le temps de transaction d’un
fait représente le temps de sa prise en charge dans la base de données. Par ailleurs, la
modification de structure d’une BD classique nécessite la migration des données vers l’es-
pace de stockage de la nouvelle structure et la destruction de l’ancien. Par contre, une BDT
peut être étendue pour assurer également l’historisation de son schéma. Elle devient alors
capable de conserver toute version de schéma, créée suite à la modification de sa structure
et/ou à l’augmentation ou la diminution de sa dimension temporelle. Un tel environnement
multiversions de schéma (EMVS) permet de prendre en compte plusieurs versions. Dans [9],
les auteurs distinguent trois pratiques de versionnement de schémas selon le type de temps
appliqué à une version :
– Le versionnement de schémas selon le temps de transaction : c’est le type de ver-
sionnement de schémas qui estampille les versions avec leurs temps de transaction
(ou temps physiques) ;
– Le versionnement de schémas selon le temps de validité : c’est le type de version-
nement de schémas qui estampille les versions avec leurs temps de validité (ou temps
logiques) ;
– Le versionnement bitemporel de schémas : c’est le versionnement de schémas qui
utilise à la fois le temps de transaction et le temps de validité pour estampiller les
versions de schémas.
Les auteurs de [10] montrent que les axes temporels de validité et de transaction, utili-
sés pour l’historisation des données, conviennent peu aux exigences du versionnement et
posent des problèmes de gestion. Ils proposent plutôt de gérer les versions conformément
à un autre axe : l’axe temporel d’application des versions, avec un temps de début d’appli-
cation (TDA) et un temps de fin d’application (TFA) pour chacune.
Le versionnement est donc une technique facilitant l’historisation des schémas. Nous
envisageons alors de l’utiliser pour décrire l’évolution des processus workflows, en adoptant
l’axe temporel d’application.
4 Spécification des Processus Workflows Évolutifs Versionnés
Nous considérons un PWE comme étant un ensemble fini de versions relatives à un pro-
cessus workflows donné. Ces versions concernent la même application, mais diffèrent au
niveau de certaines spécifications de leurs schémas d’enchaînement de tâches (MP), leurs
acteurs (MO) et/ou leurs informations (MI). Nous spécifions séparément, dans un premier
temps, chaque version du processus workflows considéré à l’aide des RPO. Dans un deux-
ième temps, nous intégrons les différentes versions dans un modèle unique tout en pré-
cisant le temps d’application de chaque version conformément aux décisions de l’admin-
istrateur. Le résultat obtenu est un PWE versionné spécifié à l’aide des RPO. La figure 3
illustre notre approche. Notre proposition vise alors à étendre les RPO afin qu’ils puissent
historiser les différentes informations nécessaires pour l’exécution d’une tâche dans un envi-
ronnement multiversions de processus (EMVP). Un même processus peut changer au cours
du temps au niveau de l’ordre d’exécution de ses tâches, des patterns de coordination entre
les tâches [11], des ressources (humaine oumachine pouvant exécuter une tâche) invoquées
et/ou des informations utilisées. Cette proposition consiste à associer à chaque élément du
modèle RPO (place, arc, action, pré et post-condition) une étiquette informant l’intervalle
de temps d’applicabilité de cet élément.
En effet, à chaque version, on peut associer deux temps de application TDA et TFA. Ces
deux temps définissent l’intervalle d’application [TDA - TFA] de toute version considérée
Schedae, 2007, prépublication n° 11, (fascicule n° 2, p. 21-29).
26 |
Fig. 3: Approche de versionnement des PWE.
par l’administrateur. Ainsi, il devient possible de disposer de différentes versions alterna-
tives et de différentes versions historisées.
La figure 4 illustre notre proposition en modélisant le processus d’inscription des étudi-
ants en troisième cycle (cf. section 2.3) dans un EMVP. Il s’agit de modéliser des versions
alternatives à utiliser en fonction de la période de chaque année. La première transition En-
registrement Demande est représentée en deux versions. La première version possède deux
places d’entrée « Secrétaire disponible » et « Demande arrivée » ayant un intervalle d’ap-
plication [01/09 - 31/12] et respectant la pré-condition P1= S ˆ D. Cette version fait appel
à la méthode EnregistrerD de l’objet secrétaire. Alors que la deuxième version de cette
même transition possède, en plus des deux places d’entrée de la première version, une
nouvelle place d’entrée « CV arrivé » applicable dans l’intervalle [01/10 - 31/12] respectant
une deuxième version de la pré-condition P1’= S ˆ Dˆ CV avec un intervalle d’application
[01/10 - 31/12], et deux places de sortie, «Demande et CV enregistrés » ou «Enregistrement
refusé » selon la méthode EnregisterDCV de l’objet secrétaire. La deuxième transition Exa-
men CV, figurant seulement dans la deuxième version, possède deux places d’entrée «De-
mande et CV enregistrés » et « Examinateur disponible » respectant la pré-condition P2 =
Ex ˆ Dˆ CV, deux places de sorties « Demande refusée » ou « Demande et CV retenus » et
elle appelle la méthode examiner de l’objet examinateur. Cette transition et ses différents
composants (places d’entrée, places de sortie, actions, pré et post conditions, arcs entrants
et arcs sortants) sont applicables dans l’intervalle [01/10 - 31/12]. La troisième transition
entrevue est représentée en deux versions. La première version possède trois places d’en-
trées « Examinateur disponible », « Etudiant présent » applicable dans l’intervalle [01/09
- 31/12] et « Demande enregistrée » ayant un intervalle d’applicabilité [01/10 - 31/12], et
deux places de sortie « Demande et CV retenus » ou « Demande refusée ». Cette ver-
sion n’est déclanchée que si la pré-condition P3= Ex ˆ D ˆ E est vérifiée. Elle fait appel à
la méthode questionnerED de l’objet examinateur. Alors que la deuxième version de cette
même transition possède, en plus des deux premières places d’entrée de la première ver-
sion, une troisième place « Demande et CV retenus » applicable dans l’intervalle [01/10 -
31/12] respectant une deuxième version de la pré-condition P3’= Ex ˆ CV ˆ E avec un inter-
valle d’applicabilité [01/10 - 31/12], et deux places de sortie, «Demande et CV retenus » ou
« Demande refusée » selon la post-condition associé à cette transition. Cette deuxième ver-
sion exécute la méthode questionnerEDCV de l’objet examinateur. Les versions qui ne sont
pas applicables qu’à partir du début de mois d’octobre sont représentées dans la figure 4
avec des traits discontinus.
Schedae, 2007, prépublication n° 11, (fascicule n° 2, p. 21-29).
| 27
Fig. 4: Spécification d’un PWE à l’aide des RPO dans un EMVP.
5 Positionnement par rapport à d’autres approches
L’étude de la spécification des processus workflows n’est pas nouvelle. Elle a déjà donné
lieu à plusieurs travaux, tels que ceux décrits dans [4, 12, 13]. Ces travaux sont dédiés aux
processus workflows stables, bien identifiés et prévisibles : ils ne prennent pas en compte
l’évolution des processus dans le temps (c’est-à-dire les PWE tel que nous les avons définis
précédemment). Par ailleurs, les trois modèles complémentaires utilisés dans le workflow
ne sont pas souvent décrits dans un cadre cohérent.
En ce qui concerne les travaux exploitant les versions, sont aussi nombreux [5, 14, 15,
16]. Ces travaux en réalité mettent l’accent sur le modèle informationnel et n’accordent pas
d’attention aux autres modèles organisationnel et de processus.
Quant aux travaux traitant la spécification des processus workflows évolutifs, ils sont très
peu [17, 18]. Ces travaux proposent une solution permettant la migration d’une version d’un
PWE à une autre, sans garder la trace des versions antérieures qui peuvent être réutilisées
dans le futur.
Notre travail diffère des travaux existants sur les points suivants : notre proposition utilise
la technique de versionnement (telle que utilisée dans le domaine des bases de données)
pour étendre les Réseaux de Petri à Objets. Bien articulés, ces deux outils (RPO et le ver-
sionnement) permettent de traiter de manière appropriée les problèmes de spécification
des PWE. L’utilisation des RPO, possède en effet un pouvoir d’expression adapté à la spé-
cification des processus workflows. Ce pouvoir d’expression est notamment dû au fait qu’il
intègre judicieusement l’approche Objet et les Réseaux de Petri. Cette expressivité a pu
Schedae, 2007, prépublication n° 11, (fascicule n° 2, p. 21-29).
28 |
être démontrée dans les exemples de la section 2.3. Quant au versionnement, il permet de
supporter l’évolution des trois modèles d’un workflow dans le temps.
6 Conclusion
Cet article concerne la problématique des langages de spécification des PWE. Cet article a
montré que les RPO conviennent bien à la description des processus workflows bien identi-
fiés et prévisibles, mais non évolutifs. Pour pallier cette limite, cet article a proposé d’utiliser
conjointement les RPO et le Versionnement. Notre approche a les avantages suivants :
– une spécification de bonne qualité des processus workflows grâce à l’utilisation des
RPO ;
– prise en compte de l’évolution des processus dans le temps, qui devient une néces-
sité pour les entreprises souhaitant faire face à l’évolution du monde réel, dans un
EMVP.Nous visons maintenant de mettre en œuvre notre proposition, en développant un outilpermettant la spécification des PWE à l’aide d’une utilisation conjuguée des RPO et duversionnement.
Références[1] The Workflow Management Coalition. Workflow management coalition terminology and glossary.
WFMC-TC-1011, Febrary 1999.
[2] M. Divitini, C. Hanachi, and C. Sibertin-Blanc. Inter-orgaanizational workflow for enterprise coor-
dination. Coordination of Internet Agents, chapter 15, A. Omicini, F. Zambonelli, M. Klusch, R.
Tolksdorf (Eds), Springer Verlag,, 2001.
[3] M.A. Chaâbane, L. Bouzguenda, R. Bouaziz, and F. Gargouri. Etude comparative de quelques
langages de spécification de processus workflow. Actes des 7èmes journées scientifiques des
jeunes chercheurs en Génie Electrique et Informatique (GEI), 2007.
[4] C. Sibertin-Blanc. High level petri nets with data structure. In 6th International Workshop on Petri
Nets and Applications Espoo, Finland, 1985.
[5] R. Bouaziz and M. Moalla. Gestion des versions de schémas dans les bases de données. Forum
de Recherche en Informatique (FRI)-Tunis, juillet 1996.
[6] W.M.A. Van der Aalst. The application of petri nets to workflow management. the International
Journal of Circuits, System and Computers 8(1), pages 21–66, 1998.
[7] C.A. Petri. Kommunication mit automaten. Institute für Instrumentelle Mathematik, Schriften des
IMM, (n°2), 1962.
[8] C. Combi and G. Pozzi. Architectures for a temporal workflow management system. In SAC’04,
Nicosia, Cyprus, March 2004.
[9] C. De Castro, F. Grandi, and M.R. Scalas. Schema versioning for multitemporal relational
databases. Information Systems, Vol. 22(N° 5) :249–290, july 1997.
[10] Z. Brahmia and R. Bouaziz. Problématique du versionnement des schémas dans les bases de
données temporelles relationnelles. Actes des 5èmes journées scientifiques des jeunes chercheurs
en Génie Electrique et Informatique (GEI), mars 2005.
[11] W.M.A. Van der Aalst, A.H.M. Ter Hofstede, B. Kiepuszewski, and A. Barros. Workflow patterns.
In the International Journal on Distributed and Parallel Databases 34(1), pages 5–51, 2003.
[12] S.A. White. Introduction to bpmn. Business Process modeling Notation - IBM, www.bpmn.org,
May 2004.
[13] W.M.A. Van der Aalst and A.H.M. Ter Hofstede. Yawl : Yet another workflow language. In the
International Journal on Information Systems, 30(4), pages 245–275, March 2005.
[14] S. Gançarski and G. Jomier. Vers un langage demanipulation pour bases de données multiversion.
BDA, pages 161–180, 1996.
[15] S. Gançarski. Database versions to represent bitemporal databases. DEXA, pages 832–841, 1999.
Schedae, 2007, prépublication n° 11, (fascicule n° 2, p. 21-29).
| 29
[16] A. Doucet, S. Gançarski, G. Jomier, and S. Monties. Mantien de la cohérence dans une base de
données multiversion. BDA, pages 181–, 1996.
[17] F. Casati, S. Ceri, B. Pernici, and G. Pozzi. Workflow evolution. Proceedings of the 15th ER’96
international Conference, Oct 7-10 1996. Cottbus, Germany, Springer Verlag Lecture Notes in
Computer Science.
[18] M. Kradolfer and A. Geppert. Dynamic workflow schema evolution based on workflow type ver-
sioning and workflow migration. International Conference on Cooperative Information Systems
(CoopIS‘99), Edimburgh. IEEE Computer Society Press, 1999.
Schedae, 2007, prépublication n° 11, (fascicule n° 2, p. 21-29).