Technologie du workow et contribution pratique
1.9. PRÉSENTATION DE L'OUTIL JPNET
jPdl est un langage de description de processus d'entreprise spécique au moteur de workow jBPM de JBoss. La description d'un tel processus en jPdl fait l'objet d'un chier XML conforme à la spécication jPdl. A cet eet, une DTD (Document Type Denition) a été mise en place. Elle est détaillée dans [66]. Le fragment DTD relatif à la dénition de processus 'Process Denition' est donné dans la gure 1.6. Dans cette DTD,x?signie zéro ou une occurrence dex,x∗ signie zéro ou plusieurs occurrences de x etx|y signie
x ouy. <!ELEMENT process−d e f i n i t i o n ( d e s c r i p t i o n ? , swimlane∗ , type∗ , s t a r t−sta te , ( s t a t e | m i l e s t o n e | process−s t a t e | d e c i s i o n | f o r k | j o i n )∗, end−stat e , a c t i o n∗ ) >
<!ATTLIST process−d e f i n i t i o n name CDATA #REQUIRED > Figure 1.6 DTD relatif à la dénition de processus jPdl
Cette DTD indique qu'en dénissant son processus d'entreprise dans le langage jPdl, le développeur peut :
décrire le processus (description ?),
assigner des états à des acteurs (swimlane*),
dénir les types des données qui seront enregistrées dans le moteur jBPM (types*), ajouter des fragments de code java dont l'exécution sera déclenchée lors d'événements
spéciques réalisés lors de l'exécution du processus (action*).
!ATTLIST dénit la liste des attributs alors que #REQUIRED après un attribut in-dique que celui-ci est obligatoire.
Dans les points qui suivent, nous résumons les constructions : state, start-state, miles-tone, process-state, decision, fork, join et end-state.
state : c'est le concept central de jBPM. C'est un état dans lequel peut se trouver un processus d'entreprise. Le fragment DTD relatif à cette construction est le suivant :
<!ELEM EN T state (
description?, assignment?, action∗, transition+ )>
<!AT T LIST state name CDAT A #REQU IRED >
Cette DTD indique qu'en dénissant un état, le développeur peut lui associer une description, un assignement (une dépendance d'un ou plusieurs acteurs externes), des actions et au moins une transition (i.e. une connexion dirigée entre l'état en cours et
un autre).
start-state : c'est l'unique état, dans le processus, à partir duquel toutes les instances de ce dernier sont générées. Plusieurs transitions peuvent sortir du start-state, milestone : est un type spécial d'état utilisé pour synchroniser entre deux chemins
d'exécution concurrents,
process-state : le processus père lance un sous processus quand l'exécution arrive au process-state,
decision : il s'agit d'une structure alternative permettant le choix d'un chemin d'exé-cution parmi plusieurs. Une décision modélise une situation où le moteur de workow décide de la route à prendre, en se basant sur le contexte, et éventuellement de cer-taines ressources externes,
fork : il génère plusieurs chemins d'exécution concurrents,
join : il réunit plusieurs chemins d'exécution concurrents. Un join ne peut avoir qu'une transition sortante,
end-state : un processus possède exactement un état de n (end-state). Il marque la n d'une instance du processus.
Pour passer d'un chier écrit en langage jPdl à un graphe de réseau de Petri, nous avons eectué une analyse sémantique du chier donné en jPdl tout en supposant qu'il est syntaxiquement correct.
Le mapping de jPdl vers réseau de Petri est eectué en traduisant les constructions de jPdl en termes de réseaux de Petri.
1.9.1.1 Traduction des états
En jBPM, le terme state possède la même dénition que dans une machine à état ni (Finite State Machine). Il est donc possible de traduire les états en des places dans les réseaux de Petri. En particulier, l'état de début (start-state) et l'état de n (end-state) sont respectivement traduits en place source et place destination dans les WF-nets (gure 1.7).
Figure 1.7 Traduction en WF-net de a- start-state ; b- state ; c- end-state 1.9.1.2 Traduction des liens
jPdl dénit les ux de contrôle entre les états avec des transitions, décisions, forks, joins et milestones. En examinant la séquence simple d'états et leurs relations, nous déduisons facilement la réalisation de cette séquence par le pattern 1 de la liste des patterns dénis dans [3]. Ce pattern nommé "Sequence" informe qu'une activité dans le workow ne se déclenche qu'après la terminaison d'une autre activité dans le même processus. La gure 1.8 présente une séquence simple d'états et de transitions.
1.9. PRÉSENTATION DE L'OUTIL JPNET
Figure 1.8 Traduction d'une séquence simple d'états et de transitions 1.9.1.3 Traduction des structures de contrôle
Pour modéliser les structures de contrôle, jPdl dispose des constructions fork, join, decision et milestone.
fork produit, à partir d'un état plusieurs chemins d'exécution concurrents. Cette structure est traduite par "AND-SPLIT" (gure 1.9(a)). Dans ce contexte, la n de l'exécution d'un état provoque le déclenchement de deux ou plusieurs états.
join relie plusieurs chemins d'exécution concurrents dans un état. Ainsi join se traduit naturellement par une "Synchronization" (gure 1.9(b)) : le passage du processus à l'état suivant dépend de la réalisation de deux ou plusieurs états précédents.
Figure 1.9 Traduction de : a-fork ; b-join
decision indique la possibilité de décider après la terminaison d'un état, l'exécution d'un état parmi deux ou plusieurs. Nous l'avons donc traduite par la structure OU EXCLUSIF (XOR-SPLIT) représentée dans la gure 1.10(a).
milestone : cette construction est traduite par la structure (OR-JOIN) puisqu'elle ne permet le passage à l'état suivant que si un des états précédents est terminé (gure 1.10.b).
Figure 1.10 Traduction de : a- decision ; b- milestone
Le détail du mapping entre jPdl et WF-net est présenté dans [102] et est résumé dans la gure 1.11.
Figure 1.11 Mapping de jPdl vers workow-net
Le mapping résumé dans la gure 1.11 a été implémenté sous jPnet et testé sur des exemples concrets.
1.9.2 Mapping entre PNML et RdP
Outre jBPM, jPnet peut être utile pour d'autres moteurs de workow puisqu'il permet de modéliser un processus selon le formalisme graphique WF-net et de vérier sa cohérence. Pour que le processus modélisé soit compréhensible par ces moteurs, nous avons implémenté la génération d'un chier de description de processus conforme à la spécication PNML (Petri Net Markup Language) [31, 74, 77] à partir d'un workow-net. Cette génération ne sera réalisée qu'après vérication de la cohérence du processus en question. Dans le sens inverse, un chier donné en PNML est traduit en workow-net en vue de la vérication de sa cohérence.
Petri Net Markup Language (PNML) est un format d'échange largement accepté basé sur XML pour les réseaux de Petri, qui est actuellement standardisé ISO/IEC 15909-2 [75]. Le principal problème avec l'élaboration d'un format d'échange standard pour les réseaux de Petri est la multitude de versions et des variantes existantes des réseaux de Petri. An de remédier à ce problème, PNML fournit des interfaces pour dénir de nouvelles fonction-nalités et de nouveaux types de réseaux de Petri : interface de dénition des fonctionfonction-nalités et interface de dénition des types.
1.9. PRÉSENTATION DE L'OUTIL JPNET
Un document qui satisfait aux exigences du modèle PNML est appelé un document de réseau de Petri (PetriNetDoc). Il peut contenir plusieurs réseaux de Petri (PetriNet). Chaque réseau de Petri comporte un identiant unique et un type. Le type est une URL de référence pour le nom du package à sa dénition.
Un réseau de Petri se compose de quelques pages à un niveau supérieur qui sont, à leur tour composées de plusieurs objets. Ces objets représentent la structure graphique du réseau de Petri. Chaque objet dans un PetriNetDoc possède un identiant unique, qui peut être utilisé pour faire référence à cet objet. En outre, chaque objet peut être équipé d'informations graphiques dénissant sa position, taille, couleur, forme et d'autres informations sur son aspect graphique.
Un objet d'un réseau est une place, une transition, un arc, ou autre type d'objet (une page ou un n÷ud de référence). Par convention, les places et les transitions sont généralisées à des n÷uds qui peuvent être reliés par des arcs.
Un chier PNML est un chier écrit en langage PNML qui décrit les propriétés gra-phiques des éléments du RdP modélisant le processus workow.
La description d'un processus en PNML fait l'objet d'un chier XML conforme à la spécication PNML. Nous nous sommes inspirés de [74] pour comprendre le mapping du modèle PNML vers la syntaxe XML. Par ailleurs, nous avons déni une DTD (Document Type Denition) spécique à jPnet à travers laquelle la traduction vers WF-net est aisée. Cette DTD est détaillée dans la gure 1.12.
La DTD de la gure 1.12 dénit la structure minimale d'un chier PNML. !ELEMENT dénit les éléments enfants de l'élément racine. Ces enfants sont cités entre parenthèses. Le caractère virgule donne l'ordre de citation des éléments enfants. La présence ou non d'un des caractères ?, * et + à la suite d'un élément enfant détermine le nombre de ses occurrences. #PCDATA, indique qu'un élément contient des données textuelles et EMPTY indique qu'un élément est vide. !ATTLIST dénit la liste des attributs alors que #REQUIRED après un attribut indique que celui-ci est obligatoire et #IMPLIED pour dire optionnel.
Un élément pnml réfère à un document de réseau de Petri (PetriNetDoc) et doit contenir un élément net. Un élément net doit contenir au moins un élément place suivi par au moins un élément transition lui même suivi par au moins un élément arc. Les attributs id et type de l'élément net sont obligatoires.
Les éléments place et transition possèdent un attribut obligatoire id. De même, ils possèdent l'élément graphics suivi de l'élément name ; ces deux éléments peuvent avoir occurrence zéro ou plusieurs fois. Un élément name contient l'élément text, ce dernier contient des données textuelles. Un élément graphics contient un élément oset qui réfère à la position dénie par les attributs optionnels x et y. Un élément arc possède trois attributs obligatoires id, source et target. Il peut contenir l'élément graphics zéro ou plusieurs fois.
A partir de cette DTD, nous proposons le mapping entre PNML et WF-net résumé dans la gure 1.13.
Figure 1.13 Mapping entre PNML et workow-net
Le mapping entre PNML et WF-net résumé dans la gure 1.13 a été implémenté sous jPnet et testé sur des exemples concrets.
1.10. CONCLUSION
1.10 Conclusion
Dans ce chapitre, nous avons en premier lieu rappelé les concepts fondamentaux relatifs à la gestion des processus workow et introduit la terminologie qui va être utilisée dans le reste de cette thèse. Nous avons tout d'abord rappelé les principales notions relatives aux processus métier et à leur implémentation. Nous nous sommes ensuite centrés sur les technologies de processus métier et aux détails de la technologie de workow. Puis, après avoir résumé les diérentes classes de workows existantes, nous avons détaillé le modèle de référence de la WfMC décrivant les interfaces liant un système workow et son environnement. Enn, nous avons présenté les principaux formalismes et langages de modélisation de processus workow.
En deuxième lieu, nous avons étudié quelques systèmes de gestion de workow et dégagé leur problématique majeure à savoir le manque d'outils de modélisation et de vérication des processus conés à ces systèmes. A l'issu de cette étude, nous avons exposé notre première contribution à la modélisation et à la vérication de processus workow. Cette contribution a consisté en l'implémentation d'un outil de modélisation de processus work-ow par des workwork-ow-nets, de vérication de leur cohérence et de leur traduction vers des langages de dénition de processus connu par des systèmes de gestion de workow exis-tants. Notre outil, dénommé jPnet [99], permet d'autres fonctionnalités qui seront exposées dans les chapitres qui suivent.
Ce premier travail nous a permis de nous assurer du besoin de vérication des processus workow et de souligner les insusances des langages de description des processus utilisés par les WFMSs actuels en général et le langage jPdl en particulier. Ainsi, nous notons le manque d'outils et de langages qui proposent des structures supportant les construc-teurs avancés tels que les états à instances multiples, la possibilité de passer des données d'une instance d'état précédent vers un état suivant capable de supporter des instances d'exécution multiples et enn la gestion des ressources partagées.