La théorie à base de contrats que nous avons définie est basée sur la relation d’inclusion des traces. Cependant cette relation est indécidable dans le cas général et ne peut pas être automatiquement vérifiée par des outils à l’exception de certaines catégories d’automates temporisés [131, 155]. Dans ce qui suit, nous décrivons notre technique pour la vérification automatique basée sur l’analyse d’accessibilité d’automates de propriété, qui s’appuie sur le fait que le composant abstrait représente une propriété de sûreté déterministe. Cette méthode est mise en
œuvre dans la boîte à outils IFx [34] qui permet de vérifier et simuler des automates temporisés communicants asynchrones.
Notre méthode utilise la notion d’automate de propriété. Un automate de propriété est la définition complète d’une exigence de sûreté : il définit un état d’erreur π vers lequel les comportements incorrects mèneront et se synchronise avec le composant étudié C sur les actions communes. Le raisonnement de la satisfaction d’un contrat est le suivant : (1) transformer la garantie en un automate de propriété, (2) exécuter en parallèle le composant C et l’automate de propriété et (3) explorer l’espace d’états pour vérifier si l’état d’erreur π peut être atteint. Atteindre l’état d’erreur π signifie la violation de la satisfaction d’un contrat.
Nous commençons par définir le processus de transformation d’une propriété de sûreté déterministe en un automate de propriété. Le mécanisme est similaire à celui défini dans [41] et plus tard utilisé pour automatiser le raisonnement hypothèse-garantie dans l’outil LTSA [84, 30].
Définition 16 (Automate temporisé de propriété). Soit un automate tem- porisé entrée/sortie déterministe A = (XA, ClkA, QA, θA, IA, OA, VA, HA, DA, TA).
L’automate temporisé de propriété correspondant à A est défini par l’automate temporisé entrée/sortie suivant OA = (XA, ClkA, Q, θA, ∅, ∅, V, HA, D, TA) où:
• Q = QA∪ {π}, où π est un état d’erreur additionnel,
• V = IA∪ OA∪ VA,
• D = DA ∪ {(x, a, π)|x ∈ QA, a ∈ V tel que (∃ x
0.(x, a, x0) ∈ D
A) ∧ (∃ ε ∈
HA∧ x0 ∈ QA.(x, ε, x0) ∈ DA)}.
L’idée de cette transformation est que les séquences d’actions qui ne sont pas explicitement modélisées devraient être considérées comme des comportements erronés. Comme un automate temporisé de propriété est utilisé pour surveiller un composant fermé, nous considérons que sa signature ne contient que des actions visibles, correspondant aux entrées, sorties et actions visibles de A. Puis, dans chaque état de l’automate à partir duquel il n’y a pas de transition interne sortante, nous complétons l’ensemble des transitions avec celles manquantes : pour chaque action visible il doit y avoir une transition discrète soit conduisant à un état défini en A ou à π. Ainsi, les actions menant à l’état d’erreur π ne sont pas autorisées à se produire dans une séquence temporelle décrite par A.
Nous remarquons que la définition de l’automate temporisé de propriété est similaire à la modélisation des exigences avec des observateurs dans OMEGA. En effet, un observateur formalise une propriété de sûreté en modélisant l’état d’erreur π via
le stéréotype d’erreur et ne définit que l’ensemble d’actions visibles, c.à.d aucune entrée ou sortie. Par conséquent, le même mécanisme de vérification peut être appliqué pour vérifier la relation de conformité. Dans ce cas, π n’est pas ajouté à Oϕ s’il a été modélisé par l’utilisateur.
Cependant, pour que cette méthode fonctionne, le composant A doit être une propriété déterministe de sûreté à la fois pour les actions visibles et les actions internes. Pour les actions internes, le déterminisme signifie qu’il y a au plus une transition sortant d’un état. La garantie présente déjà du non-déterminisme interne fini. Par conséquent, afin d’obtenir le déterminisme, nous limitons la deuxième condition de la définition 15 de telle sorte que le cardinal de l’ensemble d’états finaux soit égal à 2 : l’état final peut être soit l’état initial si aucune transition interne n’a été tirée ou l’état obtenu par l’exécution de la transition. Nous remarquons que ces conditions doivent tenir dans le cadre des automates temporisés entrée/sortie. Cela implique que, dans une machine à états SysML, on peut modéliser plusieurs transitions internes sortantes si elles ne sont pas actives en même temps, par exemple deux transitions ayant des gardes disjointes.
La synchronisation à l’exécution entre C et l’automate de la propriété OA est définie
par l’opérateur de composition suivant, noté ./. Il est similaire à l’opérateur de composition parallèle précédemment décrit à la définition 8 avec synchronisation sur les actions visibles communes et entrelacement des autres actions. L’opérateur peut s’appliquer sur deux automates temporisés entrée/sortie s’ils ne partagent pas d’actions internes et s’ils ne définissent pas d’entrées/sorties. Cette dernière condition est motivée par le fait que l’automate de propriété surveille généralement un composant fermé.
Définition 17 (Composition synchrone). Soient A1 un composant fermé et A2
un automate temporisé de propriété tels que EA1 ⊆ EA2. Alors A1 ./ A2 = A1 k A2
où la condition de compatibilité est donnée par la contrainte HA1 ∩ HA2 = ∅.
Le résultat suivant portant sur l’analyse d’accessibilité conclut le raisonnement. Le fait de ne pas atteindre l’état d’erreur au cours de toutes les exécutions du composant précédemment composé est suffisant pour satisfaire l’inclusion de traces. Théorème 9. Si K2 est un automate temporisé de propriété déterministe et
reach((K1 k Env k Env0) ./ OK2) ∩ {π} = ∅ alors K1 vEnv K2.
Le fait que l’automate temporisé entrée/sortie jouant le rôle de la garantie doit être déterministe est une limitation de cette méthode de vérification qui doit
être prise en compte dans la méthodologie. La limitation n’est généralement pas problématique pour vérifier la satisfaction d’un contrat car les garanties doivent être modélisées comme des automates temporisés entrée/sortie fermés sous limites et sous l’extension du temps et ils peuvent souvent être rendus déterministes. Toutefois, afin d’établir la dominance, il faut aussi vérifier la satisfaction du contrat inverse, qui est plus problématique puisque nous n’exigeons pas la modélisation des hypothèses comme des propriétés de sûreté. Dans ce cas il y a trois solutions disponibles : (1) modéliser l’hypothèse comme une propriété de sûreté déterministe et appliquer cette méthode, (2) utiliser la simulation temporisée à la place de l’inclusion de traces ou (3) utiliser, si possible, l’environnement concret comme hypothèse, de sorte que la satisfaction d’un contrat inverse devienne triviale.