2.3 Formalisation
2.3.10 Normalisation sur domaine
Afin de rendre valide une activité composite sur son domaine d’application, nous intro-duisons une fonction de normalisation sur domaine qui permet soit d’invalider un en-semble d’activités simples liées par une relation de précédence et de condition comme n’appartenant pas au domaine (dans ce cas, elle correspond simplement à la fonction1 isInDomainD), soit de corriger cet ensemble.
Fonction sur domaine 2 (FD2) : Normalisation Sur Domaine La fonction de normalisation sur domaine est définie de : SA+× Rp× Rc−→ (SA+× Rp× Rc) ∨ Υ.
Soit (la, Rp, Rc), normalizeOnDomainD(la, Rp, Rc) = (la′, R′ p, R′
c) si la normalisation sur domaine est possible ; elle lève sinon l’erreur "impossible normalisation sur do-maine".
2.3. Formalisation 51
L’activité do3 est initialement conditionnée par des activités qui s’excluent. L’activité est alors dupliquée en autant d’activités que de traces possibles. Par exemple do31représente l’activité do3 lorsque les tests c1 et c2 sont évalués à vrai. Par exemple do34 représente l’activité do3 lorsque les tests c1 et c2 sont évalués à faux.
Exemple Fil rouge:Normalisation sur Domaine
La fonction de normalisation sur domaine normalizeOnDomainF ilRougeconsiste uniquement à vérifier que les activités respectent les propriétés du domaine. Elle correspond donc si l’appel à la fonction isInDomainF ilRougerenvoie vraie à retourner les ensembles sans modification.
C’est au niveau de cette fonction que nous pouvons trouver des transformations vers d’autres espaces technologiques et en particulier les algèbres de processus afin de vali-der des propriétés qu’il serait difficile de vérifier au niveau de notre formalisation. Par exemple, dans [Pou07], le langage diapason-* permet de formuler des propriétés spéci-fiques à une orchestration qu’il pourrait être intéressant de valider par une transforma-tion vers ce langage. De même le respect de contraintes de temps pourrait être situé au niveau de cette fonction. Néanmoins des propriétés telles que l’unicité d’une invocation (une et une seule facture est produite), ou la présence d’une séquence d’activités (il n’y a pas d’action de facturation qui ne soit suivie d’une livraison) semble pouvoir être vé-rifiées directement dans notre représentation, et ceci d’autant plus facilement que nous utilisons Prolog pour représenter les graphes d’activités.
CHAPITRE 3
Composition d’activités
La composition d’activités vise à définir une nouvelle activité composite à partir d’un ensemble d’activités composites. Contrairement aux travaux de Straeten [VDS05], la composition d’activités ne repose pas nécessairement sur la préservation du comporte-ment comme dans le cas d’un raffinecomporte-ment. En effet lors de la composition il est possible de rendre obsolète un ancien comportement (par exemple parce que deprecated ou de-venu interdit lorsque l’on ajoute de la sécurité). Ainsi la composition d’activités nécessite des mécanismes de "fusion" dans lesquels des activités se fusionnent pour engendrer de nouvelles activités (par exemple, la fusion de deux invocations à un même service peut donner lieu à une nouvelle invocation dans laquelle les valeurs des paramètres ont été agrégées par appel à une nouvelle activité). La maîtrise du mécanisme de composition est l’objectif de ce chapitre. Pour ce faire, nous précisons l’algorithme que nous proposons et les propriétés qui doivent être vérifiées ou peuvent être attendues et leurs conséquences sur les différentes étapes de l’algorithme.
Dans la partieIIapplicationsnous donnons différentes interpretations correspondantes à cet algorithme.
Comme dans le chapitre précédent pour faciliter la lecture, nous illustrons l’algorithme sur le domaine fil rouge. Avec le même objectif, nous donnons à présent une description informelle de l’algorithme de composition.
3.1 Vue synthétique de la composition d’activités
compo-sites
Procédé de composition : présentation informelle
La composition d’un ensemble d’activités composites indépendantes va dépendre du do-maine d’application. Cependant nous avons dégagé un algorithme général qui repose sur les étapes suivantes :
1. Copie des activités composites à composer.
Cette étape nous permet de préserver l’unicité des activités simples relativement à une activité composite, de même que la portée des variables relativement à chaque activité composite.
2. Recherche des activités fusionnables (cf.3.2).
Entre plusieurs activités composites seules certaines activités simples sont poten-tiellement fusionnables, elles sont dites pivots. Les activités pivots fusionnables deux à deux vont constituer des paires de fusion, puis par regroupement des en-sembles de fusion.
Cette étape est à rapprocher de la recherche de correspondances telle que définie dans [Pas06b].
La fonction detectMergeP airsDdépendante du domaine capture cette étape, tandis que la fonction detectMergeSets sur la base de la fonction précédente calcule les ensembles de fusion.
A cette étape desconflits dit de "pivots" pourront être détectés lorsque des fusions attendues ne peuvent pas être réalisées.
3. Calcul des nouvelles activités et relations engendrées par la fusion d’ensembles d’activités pivots et détermination des transformations à opérer sur l’union des ac-tivités simples composant les acac-tivités composites initiales (cf.3.4).
La fusion d’un ensemble d’activités simples peut donner lieu à la création de nou-velles activités, l’ajout de nounou-velles précédences et conditions mettant en jeu ces nouvelles activités et un ensemble de transformations à opérer.
La fonction mergeSimpleActivitiesD, dépendante domaine, capture cette étape. A cette étape des conflits dits de "fusion" peuvent être détectés lorsque l’on ne parvient pas à calculer la fusion sur la base de l’ensemble des activités et relations en présence.
4. Application des transformations (cf.3.3).
La détermination de l’ordre d’application des transformations et l’application or-donnée des transformations va permettre d’assurer l’indépendance vis-à-vis de l’ordre des activités.
La fonction PD dépendante domaine capture cette étape.
A cette étape desconflits dits de "transformation" peuvent apparaître ; par exemple lorsque l’on ne parvient pas à calculer un ordre d’application des transformations qui assure un résultat unique au sens de l’équivalence.
5. Normalisation partielle (cf.3.5)
La normalisation partielle permet de rester dans le domaine des activités compo-sites valides qui sert d’hypothèse de base à toutes les fonctions.
La fonction P artiallyNormalizeD dépendante domaine capture cette étape.
A cette étape desconflits correspondant à "impossible normalisation partielle" peuvent apparaître lorsque l’on ne parvient pas à normaliser l’ensemble d’activités et de relations obtenu. Cela peut se produire, par exemple, si un circuit a été détecté que la fonction de normalisation partielle ne sait pas résoudre.
6. La fusion donnant lieu à la création de nouvelles activités, de nouveaux ensembles de fusion peuvent apparaître. Le procédé est donc réitéré tant qu’il existe des en-sembles de fusion.
7. Le résultat final (quand il n’y a plus d’ensemble de fusion) est alors un ensemble normalisé d’activités simples liées par des relations de précédence et de conditions. Cet ensemble est alors validé et éventuellement transformé pour se conformer au domaine ciblé, dans ce cas nous utilisons la normalisation sur Domaine vue au chapitre précédent (cf.2.3.5).
3.1. Vue synthétique de la composition d’activités composites 55
Cette figure présente un exemple de composition de deux activités composites définies dans le cadre du domaine fil rouge. Les deux activités composites ac1 et ac2 sont composées autour de leurs pivots respectifs (activités proceed ) pour engendrer la nouvelle activité composite ac1 + ac2. La fusion des activités pivots engendrent de nouvelles activités (sa*). La représentation en haut à droite montre le résultat de la
composition avant la normalisation.
FIGURE3.1: EXEMPLE DE COMPOSITION D’ACTIVITÉS COMPOSITES DANS LE DOMAINE FIL