être généré à partir des modèles originaux avec peu ou pas d’intervention de la part des développeurs. L’utilisation de modèles abstraits présente également l’avantage de pouvoir générer différents types de codes en passant éventuellement par différents PSM. Il est ainsi possible de générer du BPEL, du WSCI ou du XLANG à partir du même PIM. Il est même possible de générer différentes catégories de langages. Ainsi, il serait possible de générer des langages de description tel que le WSDL ou des langages de modélisation tel que le BPMN ou encore des langages d’exécution tel que le Java. Enfin, les transfor-mations entre les modèles sont généralement bidirectionnelles. Il est dans ce cas possible de générer des modèles de haut niveau à partir du code afin d’aider à la compréhension de la composition.
3.2 Vérification formelle
La complexité des systèmes logiciels et matériels actuels ne cesse de croître et rend leur vérification de plus en plus difficile. Cette étape de vérification est cependant primordiale afin d’assurer la qualité et la fiabilité des systèmes développés. Les microprocesseurs par exemple sont gravés de plus en plus fins, intègrent de plus en plus de transistors et fonctionnent à des fréquences de plus en plus élevées. Les coûts de production de tels microprocesseurs étant très élevés, se rendre compte d’une erreur de conception après la mise en production ou pire la commercialisation serait désastreux. Le même principe s’applique également aux logiciels et par là même à la composition de services. Les outils de vérification formelle constituent un atout indispensable pour prouver que le design d’un système est correct et ainsi éviter de tels problèmes.
Dans cette section, nous allons d’abord présenter et définir la vérification formelle dans la sous-section 3.2.1. Cette procédure de vérification passe par la description de propriétés comportementales relatives au système. Nous expliquerons l’étape de spécification de ces propriétés et les moyens pour les décrire dans la sous-section 3.2.2.
3.2.1 Présentation
Lors de l’élaboration de la spécification d’un système, le développeur crée en ensemble de blocs réalisant les comportements demandés avant de les interconnecter afin de modé-liser le fonctionnement global. Cependant, il existe des subtilités lors de la spécification de systèmes complexes qui font que le système n’aura pas forcément le comportement attendu une fois implémenté. Le développeur doit donc être en mesure de s’assurer que la spécification est correcte avant même de procéder à l’implémentation du système. Les outils de vérification formelle permettent de répondre à ce besoin.
La vérification formelle est le processus systématique de vérification, à travers des techniques algorithmiques exhaustives, qu’une implémentation est conforme à sa spécifi-cation [PF05]. En utilisant la vérifispécifi-cation formelle, tous les chemins d’exécution possibles sont analysés mathématiquement sans nécessiter la préparation de jeux de tests. En ef-fet, à la différence du processus de simulation, la vérification formelle n’utilise pas de bancs d’essais ni de jeux de tests. Ceci est dû au fait qu’elle procède à la compilation de la description formelle du système afin d’obtenir une représentation mathématique de celui-ci et ainsi prouver de manière exhaustive que son comportement est correct. Une différence clé entre la simulation et la vérification formelle repose dans l’attitude adop-tée pour trouver les bogues. En effet, avec la méthodologie de simulation, le développeur considère toutes les séquences d’événements possibles, souvent très complexes, afin de parvenir à produire un comportement anormal qui invalide la spécification. L’élaboration de jeux de tests complets par rapport à l’ensemble des fonctionnalités que l’on désire tester est donc primordiale. Au contraire, avec la méthodologie de la vérification formelle, le développeur n’a pas besoin de se préoccuper des différents scénarios possibles ni des jeux de tests. Le développeur décrit simplement les propriétés qu’il désire prouver et il laisse les outils de vérification formelle explorer de manière exhaustive tous les chemins d’exécution possibles sur la représentation mathématique. La spécification de propriétés comportementales concernant le système représente donc une pièce maîtresse de la véri-fication formelle. Nous allons voir dans la sous-section suivante comment il est possible d’exprimer ces propriétés de manière précise à l’aide de la logique mathématique.
3.2. Vérification formelle 59
3.2.2 Spécification des propriétés
La vérification formelle d’un système passe par la preuve de certaines de ses propriétés comportementales à l’aide d’outils de vérification automatique. Ces propriétés sont définies par le développeur en fonction des fonctionnalités du système qu’il désire tester. Il est donc nécessaire de fournir au développeur un langage précis et non ambigu pour l’expression de ces propriétés. Pour ce faire, les outils actuels font appel à la logique mathématique.
La logique dont l’origine remonte jusqu’aux anciens philosophes grecs, est une branche de la philosophie et aujourd’hui des mathématiques relative au raisonnement sur le com-portement. Dans un système logique classique, une proposition est exprimée et il est alors possible de déduire si un modèle donné satisfait la proposition, comme illustré dans la figure 3.3.
Figure3.3 – Système logique classique
A titre d’exemple, considérons l’ensemble des propositions suivantes: – La Lune est un satellite de la Terre
– La Lune est actuellement montante
Si nous prenons l’Univers comme modèle, nous pouvons vérifier si nos propositions sont correctes pour le modèle considéré, à l’aide de la logique classique. Une proposition est considérée correcte si elle est évaluée comme étant vraie.
La logique classique constitue un bon moyen pour décrire des situations statiques. En revanche, celle-ci n’est pas adaptée à la description de comportements dynamiques, évoluant au cours du temps. Pour revenir à l’exemple précédent, il nous serait impossible d’exprimer à l’aide de la logique classique la proposition suivante :
– La Lune est montante puis elle sera descendante
En effet, cette proposition requiert la notion de temps qui n’est pas descriptible en logique classique. Pour l’étude de systèmes complexes tels que les services composés, cette logique n’est donc pas suffisamment expressive. En effet, la notion de temps est primordiale à l’étude du comportement de systèmes concurrentiels tels que les services composés.
Pour cette raison, les standards proposés actuellement pour la description de propriétés sont fondés sur une autre branche de la logique nommée la logique temporelle. La logique temporelle permet d’exprimer les propriétés des systèmes réactifs et de raisonner sur ces systèmes d’une manière plus aisée. Sa syntaxe est simplifiée car il n’est pas nécessaire de spécifier explicitement le temps dans les relations entre les événements d’un système. A titre d’exemple, au lieu d’écrire la propriété suivante :
∀t.!(prop1(t) & prop2(t))
il est simplement possible d’utiliser la syntaxe suivante en utilisant la logique temporelle : always! (prop1 & prop2)
pour indiquer que les propriétés prop1 et prop2 sont mutuellement exclusives, c’est à dire qu’elles ne peuvent pas être toutes deux évaluées comme étant vraies au mêmes instants. La logique temporelle est actuellement le formalisme de spécification de propriétés le plus utilisé. Plus spécifiquement, la logique temporelle linéaire (LTL) [Pnu77] a émergé comme sémantique standard pour l’expression de ces propriétés. La LTL présente l’avan-tage de pouvoir raisonner le comportement attendu au cours d’une séquence linéaire d’états. Le futur est alors vu comme une séquence d’états ou plus généralement un che-min. Cette manière de spécifier est intuitive pour le développeur puisque la progression dans le temps peut être vue comme une trace d’exécution. La LTL permet d’exprimer des propriétés relatives à l’atteignabilité, la sûreté, la vivacité ou encore l’absence de blocage. L’atteignabilité ou reachability en anglais permet de s’assurer qu’il est possible d’atteindre un état donné à partir de l’état actuel. Un exemple de propriété relative à l’atteignabilité serait "si un missile a été lancé et s’il n’a pas atteint sa cible, il est possible d’annuler la frappe". La sûreté ou en anglais safety garantie qu’une propriété indésirable ne sera jamais satisfaite. Un exemple de propriété relative à la sûreté serait "un missile ne sera jamais lancé à moins que le bouton de lancement n’ait été pressé". La vivacité ou liveness en anglais assure qu’une propriété désirée sera toujours satisfaite par un état donné dans le futur. Ceci permet de vérifier que le système fait ce qu’il est supposé faire. Un exemple de propriété relative à la vivacité serait "si le bouton de lancement est pressé, le missile sera lancé". Enfin, l’absence de blocage indique qu’un état de blocage, c’est à dire sans successeur ne sera jamais atteint. Ceci permet de s’assurer que le système ne peut pas se
3.3. Approche proposée 61