Vous pouvez également accéder à ce tutoriel en anglais et en allemand.

 

Ce tutoriel concerne les règles Ripple Down (RDR). Les RDR sont des arbres binaires utilisés dans YAWL pour étendre progressivement la gestion des cas particuliers dans les workflows. En combinaison avec des worklets et des exlets, ils offrent une flexibilité aux flux de travail YAWL. Le fichier zp joint contient les spécifications et les ensembles de règles nécessaires à l'installation sur votre propre système.

 

Bonjour et bienvenue dans le deuxième tutoriel sur la flexibilité! Cette fois, nous parlerons des règles de déformation. Les règles d'ondulation sont des arbres binaires avec une condition et une conclusion. La condition est quelque chose qui est évalué sur les données du cas et la conclusion est un worklet. En construisant ces règles d'ondulation vers le bas, nous sommes en mesure d'étendre dynamiquement le comportement d'une spécification de flux de travail en l'ajoutant à une tâche dans la spécification de flux de travail. Et puis cet arbre binaire peut se développer au fur et à mesure que des cas spéciaux arrivent et gérer un comportement spécial auquel nous n'avons pas pensé lors de la construction de la spécification d'origine. Ces règles d'ondulation sont évaluées avec un mécanisme en deux phases. Dans la première phase, nous descendons dans l'arborescence et chaque fois qu'une condition s'évalue à vrai, nous allons vers la droite et chaque fois qu'une condition s'évalue à fausse, nous allons vers la gauche. Nous faisons cela jusqu'à ce que nous atteignions une feuille de l'arbre. Quand nous arrivons à une feuille, nous passons à la deuxième phase. Et puis nous remontons l'arbre en évaluant à nouveau chacune des conditions. La première condition que nous trouvons vraie déterminera alors lequel des worklets est exécuté. Eh bien, cela semble très complexe et je pense que nous devons l'examiner plus en détail. Alors regardons un exemple. L'exemple vient donc de la distribution YAWL et concerne l'organisation d'un concert. Avant de faire le spectacle dans le concert, nous vérifions combien de billets ont été vendus. Et si le nombre de billets vendus est inférieur à un certain seuil, nous ferons une certaine action en modifiant la réservation du lieu. Cette action est déclenchée par une soi-disant violation pré-contrainte d'élément de travail et je vais vous montrer l'arborescence de règles d'ondulation qui lui est associée et qui se trouve dans la spécification. Ainsi, vous pouvez obtenir toutes les spécifications dans le matériel supplémentaire comme d'habitude, mais vous pouvez également les trouver dans la distribution YAWL. Ainsi, chaque arborescence de règles d'ondulation a un nœud de niveau supérieur avec la condition true et le comportement par défaut. Le comportement par défaut tel qu'il est spécifié dans la spécification YAWL. Et nous appelons cela la condition et cela la conclusion. Ainsi, chaque nœud de cet arbre - si ce n'est pas une feuille - a deux enfants. L'enfant sur le côté gauche est celui que nous prenons si la condition n'est pas évaluée mais ici c'est une constante vraie donc c'est toujours donné. Et sur le côté droit, nous avons un nœud qui est pris si la condition est évaluée à vrai. Donc, dans ce cas, nous allons ici sur le côté droit et disons que nous voulons avoir une règle selon laquelle si les billets vendus sont inférieurs à 75% des billets comme condition et dans ce cas, nous passerons au milieu de la salle. Donc, passer au lieu intermédiaire est le nom d'un worklet que nous avons spécifié auparavant. Et puis disons si c'est encore pire et que nous avons vendu moins de 50% des billets que nous voulons changer pour une petite salle. Donc, encore une fois, si c'est vrai et si c'est moins de 75% et si c'est moins de 50% des billets vendus, nous passons à une petite salle. Et si c'est moins de vingt pour cent, nous annulons le spectacle. Il s'agit donc de l'arbre rdr qui se trouve dans la spécification et dans le jeu de règles qui lui est attaché. Nous le verrons plus tard lorsque nous l'ouvrirons dans l'éditeur YAWL. Et puis nous pouvons penser à avoir ces nœuds feuilles ici, des nœuds vides, qui sont attachés à chacun des nœuds ici et juste pour des raisons de généralité, je veux vous montrer qu'il est également possible d'étendre l'arbre par des nœuds sur le côté gauche. Ainsi, par exemple, nous pourrions dire que si les billets vendus sont supérieurs à 95%, nous informons du fait que tout est épuisé. Quelque chose comme une information de presse. D'accord! Je veux dire que ce n'est pas dans la spécification YAWL mais nous allons simplement expliquer le comportement de l' algorithme maintenant avec cet arbre complet. Donc, dans la première phase, nous commençons ici et la première phase s'achève. Ainsi, chaque fois qu'une condition est évaluée comme vraie, nous allons vers le côté droit. Et si c'est faux, on passe du côté gauche. C'est donc la constante vraie. Nous allons donc de gauche à droite. Supposons que pour le premier cas, nous ayons des billets vendus à 40% et disons que dans le cas où deux billets vendus soient à 98%. Et puis voyez pour les deux cas comment cela fonctionne. Donc, dans le premier cas, le ticket vendu est de 40, donc c'est moins de 75%. C'est vrai que c'est moins de 50%. C'est vrai. Ce n'est pas moins de 20 pour cent. Donc, finalement, nous nous retrouvons dans ce nœud ici. Et puis nous sommes à une feuille et la deuxième phase commence. Alors maintenant, nous montons dans l'arbre et la première condition qui est vraie détermine la conclusion à prendre. Donc celui-ci est faux, celui-ci est vrai. Nous passons donc à une petite salle. Donc, au cas où nous aurions 40%, nous passons à une petite salle. Prenons maintenant le cas 2: 98% des billets vendus. Donc c'est vrai que nous allons du côté droit. C'est faux. Nous allons sur le côté gauche et c'est vrai. Donc, nous allons à la droite. Alors ce que nous sommes dans cette feuille maintenant. C'est maintenant la deuxième phase. Nous montons un cran et cette condition est vraie. Nous vous informons donc que les billets sont épuisés. Prenons un troisième cas et disons que c'est 91%. Celui-ci est vrai. Celui-ci est faux. Celui-ci est faux et nous arrivons donc à ce nœud ici. Maintenant, la deuxième phase avec 91 c'est faux. C'est faux. C'est vrai. Nous faisons donc le comportement par défaut. Nous faisons donc ce qui est dit dans la spécification elle-même et nous n'invoquons pas de worklet ici. Nous pouvons voir le flux de travail d' organiser un concert qui est le processus parent dans la couche inférieure et vous pouvez également le voir ici ouvert dans l'éditeur YAWL. Et nous venons de parler de l'arbre des règles à effet d'entraînement. Alors, où pouvons-nous voir l'arborescence des règles d'ondulation dans l'éditeur YAWL? La réponse est que nous devons sélectionner la tâche "Do show", puis nous avons ce nombre d'icônes pour le service de worklet ici et si nous cliquons sur celle-ci "afficher le jeu de règles pour la spécification actuelle", nous obtenons l'arborescence des règles d'ondulation vers le bas ici dans l'éditeur YAWL. C'est un peu plus petit que celui que nous venons de dessiner car d'abord, il ne mentionne jamais le nœud supérieur ce qui est toujours vrai. Cette note ne peut donc pas être modifiée. Ce n'est donc pas affiché dans l'éditeur. Nous commençons donc par le deuxième nœud. Et il ne montre pas non plus toutes les feuilles que nous avons ajoutées à l' arbre rdr. Alors regardons ce premier nœud ici, le nœud de niveau supérieur. Nous pouvons voir qu'il s'agit d'une violation pré-contrainte d'élément de travail, ce qui signifie qu'elle sera vérifiée avant le démarrage de l'élément de travail. Cela concerne la tâche "Do show" et sur le côté droit, nous pouvons voir le contexte des données pour cela. Nous avons donc les billets vendus à 20 000 et les 30 000 places assises. Et si les billets vendus sont plus petits que les sièges multipliés par 0,75, alors nous faisons les actions ici dans cette liste. Et en fait, le nombre de billets vendus doit vraiment être inférieur à 75% des sièges pour pouvoir modifier cette règle. Les actions qui viennent ensuite sont d'abord suspendre les éléments de travail, afin que personne ne puisse l'exécuter, puis effectuer une action de compensation, qui est le passage à mi-lieu, puis continuer l'élément de travail. Donc ces trois étapes, elles peuvent être représentées dans la notation graphique comme cela est montré ici dans le dessin et en fait lorsque nous éditons ces règles, nous obtenons la même notation ici dans l'éditeur. Je vais le montrer dans la vidéo suivante. On peut donc imaginer que celui-ci suspend l'élément de travail avec ce symbole. Ensuite, nous avons l'action de compensation, puis nous avons le symbole d'élément de travail continue. L'action compensatrice ici est le changement de worklet vers le lieu intermédiaire. Nous ne le regarderons pas pour le moment et nous pouvons voir qu'il s'agit de "Cancel stadium", "Book theatre" et "Advise fans". Donc, une fois que cela est fait, nous avons terminé la tâche "Do show". Et c'est la version modifiée dans cette situation spécifique. Si nous examinons les autres nœuds dans l'éditeur, le suivant concerne si seulement moins de 50% des sièges ont été vendus. Ensuite, nous passons à la petite salle. Cela peut donc être le deuxième ici dans ce dessin. Et le dernier ici est "Annuler le spectacle" qui est différent car le cas est supprimé à la fin et il n'est pas continué. Compensez donc "Annuler le spectacle" et puis nous avons cet arrêt du boîtier ou retrait du boîtier. Vous pouvez également voir que la règle composite effective définie par l'arborescence rdr est à nouveau affichée ici dans l'éditeur YAWL. Alors essayons de lancer cette affaire. Nous avons donc déjà tout chargé dans le système YAWL et nous allons maintenant télécharger la spécification principale, la spécification parente, et elle reçoit l'ID de cas 4. Et nous pouvons voir que nous avons "Book stadium" la première tâche qui n'est pas offerte maintenant. Je vais donc commencer cette tâche pour l'utilisateur Matt Murdock et je vais dans le même journal de temps avec cet utilisateur ici. Et nous pouvons voir ce qui se passe. Donc celui-ci est lancé et j'ai maintenant le coût du site, les 25 000 places assises et j'ai le nom du site qui est le stade ANZ. D'accord! Cette tâche est donc terminée. Gardez simplement à l'esprit que nous avons une capacité de 25 000 places et que nous regardons notre interface et voyons le prochain élément de travail "Vendre des billets" qui n'est pas encore offert. Je vais donc l'offrir au même utilisateur. Et maintenant, nous avons le coût des billets et les billets vendus et disons donc que nous avons 12 000 billets vendus, soit moins de la moitié des sièges. Ensuite, nous nous attendrions à changer pour une petite salle. Et maintenant, vous pouvez voir dans l'interface d'administration l'élément de travail "Do show" ici. Celui-ci est suspendu car nous l'avons suspendu dans nos actions et ensuite nous avons ici l'élément de travail "Annuler le stade" qui est activé et non proposé. Notez également que "Annuler le stade" a l'ID de cas 5 alors que notre cas parent a l'ID de cas 4. Un nouveau cas est donc créé pour notre worklet et nous redémarrons ce stade d'annulation pour le même utilisateur afin de simplifier les choses. Et puis nous pouvons annuler le stade. Maintenant, nous avons le prochain travail ici: "Book concert hall". Et maintenant, nous avons un autre lieu, disons, qui coûte moins cher avec quinze mille sièges. Et la tâche suivante s'appelle "Informer les parieurs". On recommence donc pour le même utilisateur. Ainsi, nous pouvons maintenant voir les sièges et la salle de concert du nom de la salle et maintenant le worklet est terminé et nous avons la tâche "Do show" non offerte ici. Et "Do show" est maintenant dans la salle de concert avec un plus petit nombre de places et nos billets vendus. C'est tout! Vous avez donc vu que c'est assez complexe. Mais c'est aussi assez puissant. Comme vous pouvez le voir dans les graphiques ici derrière moi, qui proviennent du livre YAWL, nous avons trois couches sur la couche inférieure, nous avons la spécification du flux de travail parent avec la tâche "Do show". Et puis "Do show" est connecté à un exlet. C'est dans la couche intermédiaire. Et cet exlet est une violation de contrainte d'élément de travail préalable: par exemple, le nombre de billets vendus n'est pas suffisant. Et puis il y a ce comportement défini dans cet exlet - et nous aborderons les exlets dans le prochain tutoriel - et cet exlet en tant qu'action de compensation appelle le worklet qui change en lieu intermédiaire ici. Et c'est le niveau le plus élevé. Vous pouvez donc combiner des worklets et des exlets de cette manière, mais vous pouvez également utiliser des worklets seuls sans exlets. Examinons donc cela plus en détail dans le prochain tutoriel. À plus tard!