L'exécution immobilière propose principalement une réponse aux deux questions suivantes. Ce chapitre est consacré à l’examen de l’applicabilité des méthodes de vérification de la propriété, d’application et de test en matière d’application.
A propos des s´equences, et s´equences d’ex´ecution `
Expressions r´eguli`eres et omega-r´eguli`eres
Propri´et´es, propri´et´es finitaires, propri´et´es infinitaires
- Notion de moniteur
- Les autres saveurs de la v´erification `a l’ex´ecution
- Caract´erisations des propri´et´es v´erifiables `a l’ex´ecution
- Perspectives et futurs challenges
Les propriétés dont nous parlerons ensuite sont des ensembles de séquences d'exécution. À la connaissance de l'auteur, deux caractérisations de propriétés vérifiables à l'exécution (ou propriétés contrôlables) ont été données à ce jour.
Enforcement de propri´et´es ` a l’ex´ecution
- Bref historique des approches d’enforcement par moniteur
- Pouvoir calculatoire des m´ecanismes d’enforcement
- Caract´erisations de l’ensemble des propri´et´es enfor¸cables avec des moniteurs d’ex´e-
- Synth`ese de m´ecanismes d’enforcement `a l’ex´ecution
- Quelques approches d’enforcement
Nous nous concentrerons sur les propriétés qui peuvent être implémentées par les moniteurs d'exécution. Automates à historique peu profond et réseau informatif de propriétés obligatoires [Fon04].
Test de propri´et´es
- Caract´erisation des propri´et´es testables
- Approches pour le test de propri´et´es
- Test de propri´et´es sans sp´ecification comportementale
- La classification Safety-Liveness
- La classification Safety-Progress (r´esultats pr´ec´edents)
- Motivations et contributions
La classe de propriétés de sécurité [Lam77,Lam83] (« rien de grave ne se produit »). Dans cette vue, les propriétés sont des ensembles de séquences d'exécution infinies.
Description informelle de la classification
Par exemple, les classes de propriétés Sécurité et Garantie sont les deux plus petites classes. L'exemple suivant présente de manière informelle les propriétés de chaque classe mentionnée ci-dessus.
Pour les séquences appartenant à des propriétés de réponse, les préfixes doivent régulièrement (« infiniment souvent ») appartenir à ψ. Pour les propriétés de persistance, les préfixes doivent tous appartenir à un rang spécifique.
La vue langage des r -propri´et´es
Construction de propri´et´es finitaires et infinitaires
Π est une r-propriété de garanties si toutes les continuations d'une série finie qui appartiennent à Π appartiennent également à Π. Soit une propriété telle que toutes les continuations d'une série finie appartenant à Π appartiennent également à Π.
La hi´erarchie des langages
La classe de propriétés r de réponse contient la classe de sécurité et de garantie : A(ψ)=R(Af(ψ)). La classe de persistance de la r-propriété contient la classe de sécurité et de garantie : A(ψ)=P(Af(ψ)).
La vue logique temporelle des r-propri´et´es
Hi´erarchie des formules temporelles
La classe des propriétés définies par la sécurité n'est pas fermée par négation. La classe des propriétés r qui peuvent être déterminées par des formules de réponse est fermée par des combinaisons logiques positives.
La vue automates des r -propri´et´es
Automates de Streett
La propriété lar Π1 est donnée par l’automate ordinaire AΠ1 présenté sur la figure 3.5. La propriété lar Π2 est déterminée par l’automate ordinaire AΠ2 présenté sur la figure 3.6.
La hi´erarchie des automates
La propriété larΠ3 est spécifiée par l’automate ordinaire AΠ3 représenté sur la Fig. La propriété larΠ4 est spécifiée par l'automate ordinaire AΠ4 représenté sur la Fig.3.8 page ci-contre.
Synth`ese d’automates de Streett `a partir de DFAs
Si σ∈Σω, alors par la définition du critère d'acceptation pour les séquences infinies pour les automates de Streett (Définition 16), nous avons que vinf(σ,AΠ)⊆P. Soit σ∈Σω, alors par la définition du critère d'acceptation des séquences infinies pour les automates de Streett (Définition 16), nous avons que finf(σ,AΠ)⊆P.
La vue topologique des r-propri´et´es (Remarque)
Il n'est généralement pas possible de trouver le langage final à partir duquel une machine Streett est construite. En fait, pour les obtenir, il suffit d'abord de retransformer cet automate en un DFA « minimal », en oubliant l'information sur les paires acceptantes en transformant les états R en état acceptant.
Connexions entre les diff´erentes vues
La représentation hiérarchique de la classification des propriétés Sécurité-Progrès est donnée dans la Figure 3.17. De plus, nous avons donné à tous les opérateurs une définition formelle, qui nous permet de construire des r-propriétés pour les classes de base.
Conclusion et perspectives
Nous commençons par revoir la définition classique de la contrôlabilité et donnons une caractérisation des propriétés contrôlables selon cette définition. Nous donnons une caractérisation précise de l’ensemble des propriétés contraignantes indépendamment de tout mécanisme d’application.
Monitorabilit´e dans la classification Safety-Progress
Selon la d´efinition classique du monitoring
Ce lemme stipule que les propriétés monifiables MP(B3) sont fermées par conjonction et disjonction (du point de vue logique), ou de manière équivalente, par union et intersection (du point de vue linguistique). Mais en réalité, il existe plusieurs caractéristiques de sécurité qui ne peuvent être déterminées négativement.
Une d´efinition alternative du monitoring
Certaines caractéristiques de réponse peuvent être surveillées et d’autres ne le peuvent pas. On note MP∗(B), selon cette définition, l'ensemble des propriétés qui peuvent être surveillées avec le domaine de vérité B.
Enfor¸cabilit´e par rapport `a la classification Safety-Progress
Crit`eres d’enforcement
Semblable à la preuve de la propriété 5 (direction⇐), le run deσsurAΠ visite SCC une infinité de fois et peut être exprimé. La propriété reconnue par cet automate Streett vérifie la condition (4.1), mais pas la condition.
Caract´erisation des propri´et´es enfor¸cables
Une conséquence directe est que les propriétés r des classes inférieures sont applicables. Preuve : Il reste à prouver que l’ensemble de propriétés r-obligatoire est inclus dans l’ensemble de propriétés r-response.
Testabilit´e dans la classification Safety-Progress
- Notion de testabilit´e
- Caract´erisation des propri´et´es testables
- Raffinement de la notion de verdict
- Introduction de la notion de quiescence
De plus, les séquences d'exécution finales contenues dans la propriété ne peuvent pas être utilisées directement. En fait, il satisfait à la condition de testabilité des propriétés garanties : ψ, ∅.
Conclusion et perspectives
L'approche d'application des propriétés suppose l'utilisation d'une mémoire finie mais non limitée. Imposer des contraintes sur le mécanisme de mémoire affecte toutes les propriétés d'application.
Retour sur les notions de monitorabilit´e et testabilit´e
De même, en examinant les états d'un automate de Streett, il est possible de savoir si la propriété reconnue par cet automate est testable par rapport à une relation.
Notion de moniteur
Nous souhaitons établir un cadre pour vérifier et appliquer les propriétés au moment de l'exécution. Pour les deux types de moniteurs, nous présentons le concept de contrôle de propriété.
V´erification par moniteur
Ensuite, dans la section 6.5, nous montrons comment à partir d'un automate Streett reconnaissant une propriété r exécutoire donnée, il est possible d'obtenir un moniteur d'applicabilité qui respecte les contraintes d'exactitude et de transparence. En utilisant l’ensemble PAΠ d’un automate Streett AΠ, nous montrons comment il est possible d’obtenir un moniteur de vérification de la propriété larΠ. Rm,Pm)}) un automate de Streett qui reconnaît Π∈MP(B4).
Enforcement par moniteur
- Notion de moniteur d’enforcement g´en´erique
- Enforcement de propri´et´es par un moniteur
- Instantiation des moniteurs d’enforcement g´en´eriques
- Propri´et´es des moniteurs d’enforcement instanci´es
Ainsi, le moniteur d'exécution n'applique pas l'opération d'exécution sur l'état initial lors de la soumission de la séquence d'entrée. Nous examinons maintenant les propriétés des contrôleurs d'exécution avec l'ensemble des opérations d'exécution {halt, store, dump, off}.
Operations de composition sur les moniteurs d’enforcement
N´egation
Il s'ensuit (Property.11) que l'ensemble des opérations de mise en application produites sur A↓Π a la forme dumpω+dump∗·offω. Ensuite, en utilisant la propriété 11 (p.105), nous pouvons trouver l'ordre des opérations d'exécution effectuées par A↓Π:dumpn·.
Union et intersection
La séquence d'opérations d'exécution effectuée par A↓Πest de la forme shop∗·haltω+(halt)ω. Il s'ensuit que la séquence d'opérations d'implémentation effectuées par A↓Π2 est (store+dump)k−1·dump·(stop+store)n−k où k=| o2|.
Synth`ese de moniteurs d’enforcement
Transformations sp´ecifiques aux classes de propri´et´es
Étant donné un automate Streett de m-obligation AΠ =(QAΠ,qinit. Rm,Pm)}) qui reconnaît une r-propriété (exécutoire) de l'obligation Π ∈ Obligation(Σ ). Dans la partie droite, vous pouvez voir que l'EM applique la même propriété obtenue par la transformation TransResponse.
Correction des transformations
Considérons maintenant la r-propriété de l'obligation (k+1), AΠ, reconnue par l'automate d'obligation (k+1), et A↓Π=TransObligation(AΠ). Ensuite, la forme de la séquence d'opérations d'assertion est (store+dump)*·(storeω+store*·haltω).
Transformation g´en´erale
Semblable aux propriétés de garantie, nous considérons l’exécution d’une séquence d’exécution σ∈Exec(PΣ), puis, suite à la définition de la transformation TransResponse, dérivons la forme de la séquence d’opérations produite. La forme de la séquence d'actions coercitives est de la forme (entrepôt+dump)∗·dumpou(entrepôt+dump)∗·off∗.
Comparaison avec d’autres approches d’enforcement
Comparaison avec les m´ecanismes d’enforcement
Comparaison avec les moniteurs d’enforcement
Par exemple, dans le cas où la propriété à imposer est connue, on peut synthétiser un mécanisme d'exécution plus compact en termes de nombre d'états. Par exemple, à partir d'une re-propriété safeP, nous synthétisons un moniteur d'implémentation utilisant TransSafety(AΠ) où AΠ.
Conclusion
Une remarque similaire s'applique à edit-automate et à l'ensemble des propriétés de réponse. A partir d'un automate Streett qui reconnaît une propriété, nous allons générer un ensemble de processus de tests communicants.
Introduction
Par la propriété lar, une fonction de génération de test produit automatiquement un testeur AT abstrait. Dans la section 7.7, nous présentons une autre approche basée sur la syntaxe pour générer et exécuter des cas de test.
Principe de l’approche
Le principe de la méthode de test que nous proposons est présenté dans la section 7.2. Nous présentons la génération de tests en lien avec les propriétés de la classification Safety-Progress dans la section 7.4.
Repr´esentation alg´ebrique des processus de test
La sémantique d'un processus testeur de base de test donnée par un LTSSt=(Qt,Actt,Tt,qt0) de manière classique : les étatsQt sont les "configurations" de la forme (t, ρ), où u est un terme et ρ :Var→Val est un environnement . Classiquement, cet ensemble d'actions comprend des actions contrôlables par le testeur (entrée de l'IUT) et des actions observables (sortie de l'IUT).
Phase de g´en´eration de tests
Dès la réception de la commande d'évaluation d'un événement dans l'alphabetΣ, il démarre l'exécution de tous les modules de test pour évaluer l'événement reçu. Par exemple, pour évaluer event1, il est nécessaire d’évaluer p1 comme vrai et p2 comme faux.
Phase d’instanciation des tests
L'action!c verp(ver) vous permet d'émettre le verdictver au canal verp à la fin de l'exécution du module de test. Enfin, l'exécution du module de test peut être arrêtée à tout moment grâce à l'action ?c stopp().
Phase de s´election et d’ex´ecution des tests
L'action ?c loopp() permet de redémarrer le module de test à la fin de son exécution. Cette action est possible dans chaque mode grâce à l'opérateur {c stop} suivi de l'action.
Approche compositionnelle dirig´ee par la syntaxe
Principe g´en´eral
Les opérateurs Fn sont ensuite interprétés en séquences d'exécution abstraites, c'est-à-dire en séquences de prédicats. Ces trois langages définissent respectivement des séquences d'exécution concrètes qui satisfont pi, qui ne satisfont pas pi, et celles pour lesquelles la satisfiabilité de pi est inconnue.
G´en´eration des tests
Les prédicats ne sont pas atomiques, c’est-à-dire qu’ils ne correspondent pas à l’apparition d’actions manifestes simples, mais plutôt à des séquences d’actions manifestes concrètes. Ensuite, puisque l'un des objectifs est de tester la validité ou l'invalidité d'une propriété, la sémantique définit trois types de séquences d'exécution : l'exécution, correspondant aux verdicts possibles que peut rendre un testeur : ceux qui satisfont Π(pass) , ceux qui ne satisfont pasΠ(échec), et ceux pour lesquels on ne peut pas conclure sur la satisfaction deΠ(inconc).
Conclusion et perspectives
Cette approche vise à vérifier et implémenter les propriétés fournies par l'utilisateur dans les programmes Java. Ce module vous permet d'obtenir un moniteur à partir des entrées fournies lors de la phase de conception de la propriété.
Sp´ecification de la propri´et´e par l’utilisateur
La phase de planification des fonctionnalités est une opération manuelle à effectuer par l'utilisateur. L'association (mappage) entre les événements abstraits définis dans les propriétés et.
Vue d’ensemble
Ce script automatise les appels à divers outils dans la partie synthèse du moniteur. A partir du moniteur, de la carte, des directives d'intégration et de l'initialiseur, ce script automatise la transformation du moniteur précédemment créé en un moniteur représenté sous la forme d'un programme Java.
Synth`ese de moniteurs
DFA2Streett : synth`ese d’automates de Streett depuis des DFAs et des motifs
L'utilisateur identifie une propriété régulière ψ(Σa) et un « motif » qui apparaît dans la propriété. La propriété est exprimée sous la forme d'un DFA défini sur un vocabulaire abstrait Σa.
Streett2Monitor : synth`ese de moniteurs depuis les automates de Streett
Figure 8.7 – Automate de réponse Streett résultant de l'application de DFA2Streett à DFA qui reconnaît ψ2. L'outil vérifie ensuite le déterminisme et l'exhaustivité de l'automate Streett désérialisé.
Int´egration du moniteur
Mapping2Aspect : G´en´eration d’aspects `a partir de mappings
Unadvice correspond au code qui est exécuté lorsque son pointcut intercepte l'exécution d'une méthode qui correspond à un événement de la propriété. Pour la propriété Safeiterator, un extrait de carte généré est présenté dans le Listing8.4.
MonitorTranslator : traduction de moniteurs en Java
Cette génération automatique produit le fichier nécessaire à l'intégration du moniteur dans le programme.
Biblioth`eque pour le slicing
Dans le conseil, nous effectuons la division selon les paramètres effectifs indépendants et dépendants. Θ est une liste d'associations entre les paramètres effectifs dépendants et l'état du moniteur qui leur est associé, c'est-à-dire Θ : (X×VX)×QΠ∗.
Mod`ele et utilitaires communs pour les automates
GraphMaker : des graphes pour les DFAs, automates de Streett, et moniteurs
La propriétéψ1 est représentée sur la figure 8.2 et formellement définie par l'expression régulière suivante. Nous considérons une propriété paramétrée Π(X), où X est l'ensemble des paramètres de la propriété.
Monitor Composer : Composition de moniteurs
Par exemple, tous les graphiques des objets automates présentés dans ce chapitre sont obtenus à l'aide de l'outil GraphMaker.
Mod`ele pour les objets de type automate
Ex´ecution du programme avec son moniteur ´
Exp´erimentations en v´erification `a l’ex´ecution
La colonne Temps d'exécution brut correspond au temps d'exécution initial du programme sans moniteur intégré. Nous avons comparé les performances en termes de temps d'exécution et de consommation de mémoire entre les moniteurs produits par j-VETO et ceux produits par JavaMOP.
Exp´erimentations en enforcement `a l’ex´ecution
Conclusion et Perspectives
Cette chaîne d'outils comprend un concepteur de tests, un générateur de tests et un moteur d'exécution de tests. Dans ce chapitre, nous illustrerons la conception, la génération et l'exécution de tests avec j-POST pour tester les propriétés dans Journey.
Conception des tests
Exemple
Notez que les transitions marquées par c_start2,c_loop2,c_ver2etc_stop2 sont automatiquement ajoutées par le générateur de test pour gérer l'exécution du test (voir Section 7.4. Ici aussi les transitions marquées par c_start3,c_loop3,c_ver3etc_stop3 sont automatiquement ajoutées par le générateur de test.
G´en´eration des tests
- Vue d’ensemble de la g´en´eration de test
- Analyse syntaxique de l’exigence
- Implantation de la fonction de g´en´eration de test
- Exemple
Comme vu précédemment, les processus de test (prédicats et contrôleurs) sont représentés en XML. GenTest : créez un contrôleur maître qui gère les processus de test au niveau le plus élevé de l'arborescence.
Ex´ecution des tests
- Vue d’ensemble
- Principe de fonctionnement
- Concr´etisation des interactions avec l’IUT
- Exemple
La politique de planification utilisée dans le runtime peut ainsi être modifiée à l'aide d'une cible de test. L'exécution de chaque processus de test est régie par une politique d'ordonnancement globale définie dans le moteur d'exécution de test (voir [FMFR08a] pour plus de détails).
Conclusion et perspectives
Pour la technique de vérification à l'exécution (Chapitre 4, Section 4.2), nous avons caractérisé l'espace des propriétés définies comme observables. Pour la technique d'application d'exécution (Chapitre 4, Section 4.3), nous avons fourni une caractérisation de l'espace des propriétés exécutoires.
Preuves du Chapitre 3
Propri´et´es des op´erateurs Ef et E
Preuves du Chapitre 4
Preuves du Chapitre 5
Preuves du Chapitre 6
Preuve de la transformation sp´ecifique aux r -propri´et´es de guarantee
Preuve de la transformation sp´ecifique aux r -propri´et´es de response
DFA2Streett
Usage of j-POST
Test generator
Test engine
A Compositional Testing Framework Driven by Partial Specifications
Liste des Lemmes, Th´eor`emes, et Propositions
Liste des Exemples
