next up previous contents
Next: 2.2 Propice Up: 2.1 Kheops Previous: 2.1.1 Présentation   Table des matières

2.1.2 L'exécutif

L'exécutif se base sur des règles pour modéliser l'évolution du système sous l'influence des évènements réceptionnés (requêtes et réponses) et surtout pour détecter les conflits. Ces règles expriment en particulier les conflits entre les services offerts par le niveau fonctionnel et les modes de résolution.

Le système Kheops génère un automate après compilation de ces règles. Le choix de cette approche est une alternative interessante à l'expression directe de l'automate complet, tâche de fait irréalisable étant donné la combinatoire.

En effet, si nous avons N services, chaque service pouvant être actif ou inactif indépendament des autres services, le nombre d'états de l'automate équivalent est de 2N. Ce nombre est encore à multiplier par le nombre de services pouvant être demandés à tout instant, afin de prendre en compte, pour chaque état de l'automate, les conflits que pourraient susciter une demande de service. Cela donne au total : N x 2N.

L'intérêt de la modélisation par règles réside dans la facilité de modification de la base de règles par exemple pour l'ajout d'un nouveau service. Tandis qu'une modélisaton par réseaux de Petri - qui génère aussi un automate - obligerait à remettre à jour les liens entre tous les services.

Dans les faits, la mise en \oeuvre des modifications n'est pas aussi aisée. L'ajout de services entraine une modification sensible des autres règles. Cependant comme nous alloons le voir, la synthèse automatique des règles rend le processus beaucoup plus simple.

Enfin, afin de maitriser la combinatoire, il a été décidé de réunir les services incompatibles entre eux dans des groupes. L'intérêt de ce regroupement est d'éviter une explosion combinatoire de règles.


next up previous contents
Next: 2.2 Propice Up: 2.1 Kheops Previous: 2.1.1 Présentation   Table des matières
Thomas Nemeth
1999-10-03