Dans le chapitre I section 6.2, nous avons évoqué les six utilisations possibles du contexte dans un environnement sensible au contexte. Notre système utilise les informations du contexte afin d’effectuer un lancement d’actions et de réaction selon la valeur de celui ci.
Il existe plusieurs définitions d’un système sensible au contexte. [Dey 2001] donne une défi-nition plus générale en incluant même un système qui ne fait que collecter le contexte pour le fournir à une application. Par conséquent, [Dey 2001] stipule qu’ un système est sensible au contexte s’il utilise le contexte pour fournir des informations pertinentes et/ou des services à l’utilisateur. Cette pertinence des données dépend des tâches de l’utilisateur .
Un système sensible au contexte est caractérisé par des fonctionnalités qui lui permettent d’interagir avec des capteurs, d’analyser les données collectées et d’agir en conséquence (voir figureII.6). Ceci nous a inspiré dans notre démarche de définition des différents modules de notre système.
Un système sensible au contexte peut utiliser un modèle de description du contexte qui lui offre un haut niveau d’abstraction du contexte (Voir chapitre I section6.3.2).
Dans cette section, nous décrivons les fonctionnalités de notre système sensible au contexte. Nous montrons aussi comment adapter les concepts de ce genre de système pour le contexte des processus métier.
Acquisition du contexte Interprétation
et analyse
Adaptation
Système sensible au contexte
5.1 Acquisition du contexte
L ’acquisition du contexte représente le processus de collecte des données à partir de l’envi-ronnement qui entoure le système. Pour un processus métier le contexte d’exécution est consti-tué d’un ensemble de valeurs de variables appelées variables de contexte . Elles sont de plusieurs catégories. Lorsque les valeurs de ces variables changent le processus métier doit s’adapter. Les valeurs collectées sont sauvegardées dans un dépositaire de contexte pour être utilisées ultérieurement par le système. L’acquisition de ces valeurs se fait par l’utilisation des techniques de process mining.
5.2 Interprétation et analyse du contexte
L ’analyse du contexte est un processus qui contrôle continuellement les données collectées. Ce contrôle permet de filtrer les observations et les interprétations du contexte pour détecter les situations pertinentes dans le but d’adapter le système en conséquence ou de notifier les applications sensibles à ces situations pertinentes. Le développement du processus d’analyse nécessite une interaction avec le processus de collecte du contexte via le dépositaire de contexte pour vérifier les valeurs du contexte et détecter leurs changements pertinents. Grâce aux ré-sultats obtenus par cette analyse, des décisions sont prises par le processus d’adaptation afin d’effectuer des changements sur le comportement de l’application selon les nouvelles situations pertinentes.
5.3 Adaptation aux changements de contexte
Une adaptation est une modification d’un système, en réponse à un changement dans son contexte, avec l’objectif que le système résultant soit mieux à même de réaliser sa fonction dans le nouveau contexte. En général, on peut décomposer le processus d’adaptation quelque-soit son type en deux étapes successives :
– Prise de décision concernant les opérations d’adaptation à effectuer,
– Application des actions d’adaptation en utilisant un mécanisme d’adaptation fourni par le système.
Les conditions qui engendrent l’exécution de chaque étape nous permettent de distinguer deux natures d’adaptation : l’adaptation de nature réactive et l’adaptation de nature proactive. Si la prise de décision d’adaptation et son exécution sont conditionnées par la détection d’une situation pertinente, on dit que c’est une adaptation réactive. Alors que si la décision d’adap-tation est prise au moment de la détection de la situation pertinente alors que son exécution
est conditionnée par un autre évènement, on dit que c’est une adaptation proactive.Nous nous intéressons à un type d’adaptation proactive qui consiste à prendre la décision d’adaptation avant la détection d’une situation pertinente, simplement en utilisant l’historique (fichier log) des variations du contexte et un mécanisme d’apprentissage (process mining).
Le développement du mécanisme d’adaptation est difficile à mettre en oeuvre. Mais plusieurs techniques peuvent être utilisées pour faciliter cette tâche comme la réflexivité, la programma-tion par aspect, le paradigme composant conteneur et le moteur d’inférence.
Un moteur d’inférence est un programme qui effectue des déductions logiques d’un système à partir d’une base de connaissance et d’une base de règles. Les règles sont utilisées pour manipuler les connaissances et aboutir à des conclusions. Dans les systèmes sensibles au contexte, la base de connaissances peut être représentée par les informations de contexte observées ou interprétées. Par conséquent, les règles manipulent les informations de contexte pour détecter des situations pertinentes. Lors de la détection d’une situation pertinente, le moteur d’inférence exécute les actions d’adaptation appropriées.
6 Spécification des règles métier
La dimension comportementale d’un processus métier représente le flux de contrôle des éléments à exécuter dans un processus. En effet, les flux de contrôle sont les dépendances entre diverses activités. Ce sont les relations logiques qui contrôlent l’acheminement et l’ordre d’exécution des activités. Ces relations sont la formalisation des décisions à prendre et cela en tenant compte du contexte du processus et d’un certain nombre de contraintes. Ce sont aussi les règles qui permettent de contraindre, contrôler et influencer l’aspect du métier du processus. Ces règles sont appelées les règles métier ou règles de gestion.
Dans ce cas, la logique d’un processus métier peut être décrite, d’une manière déclarative, par un ensemble de règles. En effet, lorsqu’un événement se produit, un moteur évalue l’ensemble des règles, pour exécuter les activités métier décrites dans la partie d’une action en vérifiant certaines conditions. L’exécution de l’action d’une règle peut provoquer un événement qui active une ou plusieurs règles. Ainsi ce déclenchement permet d’exécuter les activités métier en suivant la logique du processus.
Dans un environnement ouvert et qui est en perpétuel changement, définir les règles métier préalablement semble une tâche difficile. Un système sensible au contexte permet aux règles métier d’être adaptatives dans le respect du contexte perçu.
l’Administrateur s’appuie pour exécuter telle ou telle entité. Elles doivent refléter le contexte afin de permettre de sélectionner l’entité la plus adaptable à l’environnement à cet instant.
Par conséquent, dans notre système, nous avons une représentation initiale du processus mé-tier à base de règles. Ce modèle basé règles est représenté par un des languages de modélisation pour formaliser la définition des règles.
Le choix d’un modèle de règles dépend de la catégorie des règles métier. Ils existent cinq catégories de règle (d’intégrité, de dérivation, de production, de transformation et de réaction). Dans le cadre de ce travail nous considérons que nos règles sont des règles de réaction car elles se déclenchent par des occurrences d’événements et qui exigent une satisfaction de conditions pour exécuter des actions. Exemple : à la réception d’une commande, si les matières premières sont disponibles alors lancer la production.
Les règles de réaction sont les plus adaptées pour décrire la logique du processus par un ensemble de règles. Elles sont supportées par le formalisme ECA8 [Boukhebouze 2010].
D’une manière générale, une règle ECA se formalise par : ON <Event>
IF <Condition> DO <Action>
L’évènement détermine quand une règle doit être évaluée. La condition est un prédicat dont dépend l’exécution de l’action. L’action spécifie le code à exécuter si la condition est vraie.
La sémantique attachée à une règle est la suivante : lorsqu’un événement se produit, la partie condition est vérifiée. Si la condition est satisfaite, alors la partie action est exécutée en tenant compte des attributs associés à la règle.
En d’autres termes, la partie Évènement renseigne sur Quand une activité se termine. La partie Condition permet de connaître Quel chemin prendre selon les valeurs des variables par le workflow. La partie Action permet de connaître la prochaine activité qui sera exécutée.
Exemple :
W henEndOf (A)T henif (a == true)Start.Activity(B)if (b == true)Start.Activity(C)
D’un autre coté la décomposition de la structure d’un processus métier en règles métier est une procedure basée sur l’identification des patrons workflow [Bernal 2010]. Dans ce contexte, YAWL présente une grande expressivité des patrons workflow que nous détaillerons dans les prochains chapitres.