Tamago: Une plateforme pour des comportements d agent sûre Séminaire DESIR Hakim Belhaouari Encadrant: Frederic Peschanski Laboratoire d Informatique de Paris 6 & UMPC Paris Universitas Equipe SMA 18 février 2008 1/33
Plan 1 Introduction Conception par contrat 2 Langages des contrats 3 Compilation des contrats Héritage des contrats Produit synchronisé 4 Monitoring Runtime Verification Evolution du comportement Performance 5 Analyses de Contrat Animation Symbolique Génération de Tests 6 Conclusion 2/33
Introduction 1 Introduction Conception par contrat 2 Langages des contrats 3 Compilation des contrats Héritage des contrats Produit synchronisé 4 Monitoring Runtime Verification Evolution du comportement Performance 5 Analyses de Contrat Animation Symbolique Génération de Tests 6 Conclusion 3/33
Introduction Idée générale Importance de l ingénierie logicielle dans les SMA, n est plus à montrer[briot06]! On s interesse aux agents correspondant aux critères de MALEVA [Meurisse01] : 1 décomposition en comportement 2 1 agent = 1 composant 3 1 agent = 1 composite (assemblage de composants plus élémentaire) Definition (Comportement) Un comportement représente un traitement (autonome et modulaire) au niveau de l implémentation de l agent. 4/33
Introduction Agent Comportement Contrat Tamago CDL Effecteurs Senseurs Plateforme Tamago 5/33
Introduction Le Composant Definition (Composant [Szyperski02]) Un composant suit trois règles : 1 représente l unité de composition 2 connait ces dépendances et ces besoins 3 peut-être déployé indépendamment Interface Requise Interface Fournie Composant 6/33
Introduction Le Composite Definition (Composite [Szyperski02]) Un composite est un composant qui contient une architecture interne de composant. L architecture interne suit le principe d information hiding. S2 Composant1 Composant2 S1 S3 Composant3 7/33
Introduction Conception par contrat Conception par contrat Introduit par Meyer dans le langage Eiffel (Design By Contract), dans le but de concrétiser l accord entre l appelant et l appelé [Meyer97] : 1 invariant : fixe des conditions sur l entité 2 precondition : pré-requis pour appeler une méthode (client) 3 postcondition : validation de l appel sur l état (fournisseur) = Si l appelant remplit sa part du contrat, alors l appelé doit lui aussi remplir sa part. Lightweight Formal Methods Mieux vaut sous-spécifier que pas du tout Plus les contrats seront précis, plus sûre sera l application 8/33
Introduction Conception par contrat Plateforme Tamago Design Time Implementation Test Case Generation (Tamago Test) Symbolic Interpretation (Tamago Check) Structural Analysis (Tamago StaticCheck) Contract Specification (Tamago CDL) Skeleton/Containers (Java Interfaces/Classes) Contract Compilation (Tamago CC) Implementations (Java Interfaces/Classes) Tamago Contract Monitoring Selection of Percolation pattern JDK (>1.5) Tamago API Runtime Deploy Time Client Provider 9/33
Langages des contrats 1 Introduction Conception par contrat 2 Langages des contrats 3 Compilation des contrats Héritage des contrats Produit synchronisé 4 Monitoring Runtime Verification Evolution du comportement Performance 5 Analyses de Contrat Animation Symbolique Génération de Tests 6 Conclusion 10/33
Langages des contrats Langages des contrats Principe d ingénierie, on sépare le contrat (public) de(s) l implantation(s) (privée). Description des contrats interface standard (signature des méthodes) Logique du premier ordre Description d un automate gouvernant l activation des méthodes automate finis déterministe transition augmentée gestion de l héritage via la plateforme 11/33
Langages des contrats Exemple : Robot component Robot { property int x ; property int y ; property string name ; property bool die ; invariant name null fail no name ; invariant ( x >= 0) ( y >= 0) ; provide service Agent module maleva ; require service Sensors module maleva ; require service Effectors module maleva ; voidmove(int dx, int dy) { pre (dx + x) 0 (dy + y) 0 ; post x = (dx + x@pre) y = (dy + y@pre) ; } behavior { init state live ; states { state live { allow move ; } ; state die { } ; } transitions { transition from live to die with move when die ; } } } 12/33
Compilation des contrats 1 Introduction Conception par contrat 2 Langages des contrats 3 Compilation des contrats Héritage des contrats Produit synchronisé 4 Monitoring Runtime Verification Evolution du comportement Performance 5 Analyses de Contrat Animation Symbolique Génération de Tests 6 Conclusion 13/33
Compilation des contrats Héritage des contrats Héritage des contrats Definition Raffinement Garantit aussi bien la subsomption, que le behavioral subtyping, vis-à-vis des super-contrats. mis en place par un mot-clé unique refine garder les comportements enrichir les contrats hérités (percolation pattern) 14/33
Compilation des contrats Produit synchronisé Produit Synchronisé Definition Produit synchronisé Fusionner tous les automates hérités en un unique automates. Pourquoi? Pour des raisons : optimisation concurrence 15/33
Compilation des contrats Produit synchronisé Exemple : Produit Synchronisé move live die move<die> 16/33
Compilation des contrats Produit synchronisé Exemple : Produit Synchronisé move live die + opt release debug move<die> verbose 16/33
Compilation des contrats Produit synchronisé Exemple : Produit Synchronisé move live die + opt release debug move<die> verbose = opt live/release live/debug verbose move<die> move<die> opt die/release die/debug verbose 16/33
Monitoring 1 Introduction Conception par contrat 2 Langages des contrats 3 Compilation des contrats Héritage des contrats Produit synchronisé 4 Monitoring Runtime Verification Evolution du comportement Performance 5 Analyses de Contrat Animation Symbolique Génération de Tests 6 Conclusion 17/33
Monitoring générée les contrats ne sont pas injecté dans le code. approche à conteneur hiérarchique Conteneur Spécifique à un type Spécifique pour une tâche particulière Interface de base générée automatiquement 18/33
Monitoring générée Tamago framework «Interface» Service «Interface» Component core_set(o : Prop): void «Interface» Container isbind() : boolean bind(label : string, o : Obj) : void «Service Interface» MyService +funct1(o : Object) : boolean +funct2(x : real) : void provides requires «Component Interface» MyComponent +funct3(i : int) : int delegates MyComponentImpl * provider implementation * «Container Interface» Abstract_Container -delegate: MyComponent «Container» Concrete_Container1 +getdescription(): String «Container» Concrete_Container2 +check(): boolean 19/33
Monitoring Runtime Verification à l exécution «Component Interface» MyComponent «Container» BehaviorManager -state: State -delegate: MyComponent # isactivate(id : MID): boolean Client «Container Interface» Container... «Container» ContractChecker -delegate: MyComponent... delegates delegates MyComponentImpl * provider implementation * Par défaut : un conteneur pour vérifier l automate un conteneur pour vérifier les assertions 20/33
Monitoring Evolution du comportement Evolution Definition (Evolution) Changement du comportement des agents : nouvelle façon de penser (implémentation) extension de certains traits Trois modes d évolution : 1 Hot-swapping : modification du code métier 2 Reconfiguration : modification des contrats 3 Interception/Extension des conteneurs et de leur utilité. 21/33
Monitoring Evolution du comportement Evolution : modification du code métier Signification Modification de son comportement sans changer son contrat. capacite de l implémentation optimisation dans l utilisation des ressources Tâches réalisées par la plateforme : 1 Bloque l accès au composant 2 Sauvegarde les propriétés observables 3 Affecte les nouvelles valeurs au nouveau composant 4 Redirection des binds vers le nouveau composant = impose des contraintes sur la nouvelle implémentation 22/33
Monitoring Evolution du comportement Evolution : Reconfiguration 1 Consiste à changer les indirections dans la chaîne des conteneurs. 2 Pas encore implémenter Problèmes Ré-activation des conteneurs? cas de la vérification d automate. Compatibilité avec l ancien contrat 23/33
Monitoring Evolution du comportement Evolution : Interception/Extension Correspond à ajouter un conteneur dans la chaîne de conteneur Exemple : QoS Ajout d un conteneur mesurant l overhead des contrats, ainsi que les temps d exécution. Conteneur indépendant entre-eux Tâche à réaliser rapidement 24/33
Monitoring Performance Performance Candidat : JML, jcontractor, STClass. Critère profondeur d héritage quantité de condition (largeur des contrats) (ms) 10000 1000 100 10 jcontractor Tamago JML STClass 1 (depth) 0 10 20 30 40 50 60 70 80 90 100 (ms) 50 45 40 35 30 25 20 15 10 5 STClass Tamago 0 (breadth) 0 10 20 30 40 50 60 70 80 90 100 25/33
Analyses de Contrat 1 Introduction Conception par contrat 2 Langages des contrats 3 Compilation des contrats Héritage des contrats Produit synchronisé 4 Monitoring Runtime Verification Evolution du comportement Performance 5 Analyses de Contrat Animation Symbolique Génération de Tests 6 Conclusion 26/33
Analyses de Contrat Animation Symbolique Animation Symbolique But Détecter les erreurs sémantiques ou les inconsistences du contrat. Principes Ne touche pas au code anime le contrat en suivant le comportement spécifié : précondition : impose certain domaine aux propriétés postcondition : joue le rôle d effecteur pour la prochaine étape minimise les domaines grâce à un solveur CSP découverte/injection de points fixes (problème de terminaison) 27/33
Analyses de Contrat Génération de Tests Génération de Tests But Détecter les erreurs au niveau du code d implémentation, vis-à-vis du contrat qu il fournit. Principes Similaire à l animation symbolique Génère des scénarii de test depuis l automate Se base sur des solutions de solveur de contrainte CSP Permet de choisir la stratégie de test Exécute les tests online ou offline 28/33
Analyses de Contrat Génération de Tests précondition : contraintes sur les arguments (forme normale disjonctive) postcondition : oracle Problème de génération : cas de test erroné 1 s aider de l animation pour inférer des valeurs plus cohérente 2 embarquer dans le harnais de test la condition effective Exemple [move] : pre (dx + x) 0 (dy + y) 0 ; Contraintes : 1 (dx + x) 0 avec x [0; + [ (via invariant) 2 (dy + y) 0 avec x [0; + [ (via invariant) = instancie : dx = 34 dy = 234 29/33
Conclusion 1 Introduction Conception par contrat 2 Langages des contrats 3 Compilation des contrats Héritage des contrats Produit synchronisé 4 Monitoring Runtime Verification Evolution du comportement Performance 5 Analyses de Contrat Animation Symbolique Génération de Tests 6 Conclusion 30/33
Conclusion Conclusion Contribution Méthodologie de conception d architecture sûre Hautement automatisé grâce à la plateforme Extraction de plus ample information grâce aux contrats Continuation sur : 1 Extraire propriété depuis les contrats (tautologie,... ) 2 Analyses de contrat (génération de tests,... ) 3 Etendre le langage à d autres problèmes (concurrence) 31/33
Conclusion Bibliographie I Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, 1997. Clemens Szyperski. Component Software : Beyond Object-Oriented Programming Addison-Wesley, 2002 Jean-Pierre Briot and Thomas Meurisse and Frédéric Peschanski Architectural Design of Component-Based Agents : A Behavior-Based Approach PROMAS, 2006 32/33
Conclusion Bibliographie II Thomas Meurisse and Jean-Pierre Briot Une approche à base de composants pour la conception d agents TSI - Hermes, Avril 2001 33/33