Spécification des processus workflows évolutifs versionnés · PDF...

| 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],

[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


| 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.


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


| 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


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.


| 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


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.


| 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.


Spécification des processus workflows évolutifs versionnés · PDF...

Documents

Transcript of Spécification des processus workflows évolutifs versionnés · PDF...