formal specification and verification of distributed
play

Formal Specification and Verification of Distributed Components - PowerPoint PPT Presentation

Formal Specification and Verification of Distributed Components Soutenance de Thse pour obtenir le titre de Docteur en Sciences de l'Universit de Nice-Sophia Antipolis Jean-Paul R IGAULT Prsident Rapporteurs Carlos C ANAL Frantisek P


  1. Formal Specification and Verification of Distributed Components Soutenance de Thèse pour obtenir le titre de Docteur en Sciences de l'Université de Nice-Sophia Antipolis Jean-Paul R IGAULT Président Rapporteurs Carlos C ANAL Frantisek P LASIL Candidat Antonio C ANSADO Examinateurs Tomás B ARROS Fréderic L ANG Lionel S EINTURIER Directeur Eric M ADELAINE 4 December 2008 Antonio Cansado 1

  2. Motivation ● Software Components software modules well-defined interfaces ● provided and required services composition ● Distributed Components asynchronous Does the system behave correctly? 2 4 December 2008 Antonio Cansado

  3. Approach Code Model Generation Generation Specification Language Static Analysis Behavioural Source Code Model Software Engineers! Verification Tools 3 4 December 2008 Antonio Cansado

  4. Agenda ● Context GCM ● Specification Language Specification Language Architecture Architecture Behaviour Behaviour Model Code Generation Generation Data Abstractions Data Abstraction ● Behavioural Models Behavioural Model GCM Runtime Primitive Components Hierarchical ADLs and Composite Components Formalism Java Skeletons Futures ● On-going work and Conclusions 4 4 December 2008 Antonio Cansado

  5. Grid Component Model (GCM) ● Extends Fractal Bindings Membrane NF (server) interfaces Composite component Primitive component Server Client interfaces Business code interfaces Primitive component Business code Abstracts away distribution and deployment No specification language 5 4 December 2008 Antonio Cansado

  6. Futures for Components qm qm.query(s); Data d = ... db.insert(t,d); ... d.read(); db ● Data-driven synchronisation model ● mono-threaded primitives Other component ● asynchronous remote method calls 6 4 December 2008 Antonio Cansado

  7. Concurrency and Futures Query Manager Data query(String s) { Query q = Database new Query(s); db Client return db.query(q); Data query (Query q) { } void run(Table t) { return database.query(q); Data d = qm } qm.query(s); void insert (Table t, Data d) { db.insert(t,d); database.insert(t,d); d.read(); db } } 7 4 December 2008 Antonio Cansado

  8. Concurrency and Futures Query Manager Data query(String s) { Query q = Database new Query(s); db Client return db.query(q); Data query (Query q) { } void run(Table t) { return database.query(q); Data d = qm } qm.query(s); void insert (Table t, Data d) { db.insert(t,d); database.insert(t,d); d.read(); db } } • Race-Condition on access to components • Deadlocks related to futures 8 4 December 2008 Antonio Cansado

  9. Summary of GCM / ProActive ● Hierarchical model primitive and composite components ● Mono-threaded primitive components ● Asynchronous method call transparent first-class futures data-driven synchronisation 9 4 December 2008 Antonio Cansado

  10. Agenda ● Introduction GCM ● Specification Language Specification Language Architecture Architecture Behaviour Behaviour Model Code Generation Generation Data Abstractions Data Abstraction ● Behavioural Models Behavioural Model GCM Runtime Primitive Components Hierarchical ADLs and Composite Components Formalism Java Skeletons Futures ● On-going work and Conclusions 10 4 December 2008 Antonio Cansado

  11. Wish-List ● Expressive architecture and behaviour dynamic behaviour visible at the interface deal with data and futures ● Easy to use suitable for non-specialists in formal methods ● Sound automatic verification generate guaranteed code 11 4 December 2008 Antonio Cansado

  12. Related Work ● SOFA (Behavior Protocols) synchronous communications formalism ● trace semantics ● regular expressions of events ● compositional reasoning runtime ● implementation compliance (through static analysis) 12 4 December 2008 Antonio Cansado

  13. Related Work ● STSLib synchronous component model formalism ● Symbolic Transition Systems (STS) ● synchronisation vectors ● Algebraic Data Types (ADT) ● symbolic product runtime ● synthesis of components with guaranteed behaviour 13 4 December 2008 Antonio Cansado

  14. Related Work ● Java/A, ArchJava extends Java with component-wise primitives synchronous component model formalism ● interface protocols given in LTS (Java/A) ● behaviour given in Pi-calculus (ArchJava) runtime ● Java compiler 14 4 December 2008 Antonio Cansado

  15. Our Proposal ● JDC: Java Distributed Components specification language close to Java targets asynchronous distributed component models ● 3 Layers Architecture ● extend Java with component-wise language primitives Behaviour ● define the control part of a component ● Java syntax to specify the control and data flow Data Abstractions ● variables influence synchronisations, control and data flow 15 4 December 2008 Antonio Cansado

  16. General Schema of JDC component i d ’ { ’ Component → external interfaces I n t e r f a c e ∗ id [ A r ch i t e c t u r e ] [ Services ] ’} ’ Service Service Policy ... SM SM LM 16 4 December 2008 Antonio Cansado

  17. Component Architecture component CashDesk { Cash Desk ex te rnal i n t e r f a c e s eventBusIf s e r v e r i n t e r f a c e ApplicationIf appIf; Application c l i e n t i n t e r f a c e EventBusIf eventBusIf; appIf appIf c l i e n t i n t e r f a c e ScannerIf scannerIf; scannerIf architecture Scanner contents component Application application; component Scanner scanner; Server interface i n t e r n a l i n t e r f a c e s s e r v e r i n t e r f a c e ApplicationIf appIf; Client interface / / . . . i n t e r n a l i n t e r f a c e s bindings bind ( t h i s . a p p I f, a p p l i c a t i o n . a p p I f ) ; / / . . . b i n d i n g s } 17 4 December 2008 Antonio Cansado

  18. Service ● Java-like language to define behaviour each sequential activity is called a service Service Policy s e r v i c e ’ { ’ Service → LocalVariableDecl ∗ Service Methods p o l i c y ’ { ’ Po l i c y ’ } ’ ServiceMethodDecl ∗ LocalMethodDecl ∗ ’} ’ Service Policy ... SM SM LM 18 4 December 2008 Antonio Cansado

  19. Service Policy ● Rough specification of the interactions/ordering of one of the services provided by the component defined by a regular expression Policy → ServeMode ’(’ [ Filter ] ’)’ | MethodCall | Po l i c y ’ ; ’ Po l i c y | Po l i c y ’ | ’ Po l i c y | Po l i c y ’ * ’ serveOldest | serveYoungest ServeMode → Filter → | InterfaceName | InterfaceName ’.’ MethodName | F i l t e r ’ , ’ F i l t e r 19 4 December 2008 Antonio Cansado

  20. Example: Service vo i d barcodeScanned(Barcode barcode); vo i d f n i s h S a l e ( ) ; s e r v i c e s / / . . . s e r v i c e { Bool expressMode; public enum CashState{ applicationIf IDLE , ST ARTED , PAYING Application } CashState cashState; / / . . . o t h e r v a r i a b l e s p o l i c y { i n i t ( ) ; serveOldest ( a p p l i c a t i o n I f ) * } // service methods } Serves in FIFO 20 4 December 2008 Antonio Cansado

  21. Service Method ● Asynchronous Method Calls transparent first-class futures ● Abstraction of the control and data flow reference to user-defined classes all remote method calls, with arguments access on received values (futures) ● No business code dealing with calculi 21 4 December 2008 Antonio Cansado

  22. Example: Service Method vo i d ap p l i c at i o n I f .barcodeScanned(Barcode barcode) { switch (c a sh S ta te) { Is it a future? c a s e IDLE : c a s e PAYING : break; / / i g n o r e s i g n a l c a s e ST ARTED : Product product = cashDeskIf .getProduct(barcode); i f (product == n u l l ) { Future! eventBusIf.productBarcodeNotValid(); break ; } . . . Seamless Futures for Developers ● No specification of synchronisations ● Reuse components in different contexts 22 4 December 2008 Antonio Cansado

  23. Agenda ● Introduction GCM ● Specification Language Specification Language Architecture Architecture Behaviour Behaviour Model Code Generation Generation Data Abstractions Data Abstraction ● Behavioural Models Behavioural Model GCM Runtime Primitive Components Hierarchical ADLs and Composite Components Formalism Java Skeletons Futures ● On-going work and Conclusions 23 4 December 2008 Antonio Cansado

  24. Why use Data Abstraction ? ● Have to consider variables that influence synchronisations, control and data flow ● Don't want to specify equations too difficult not useful for code generation ● Solution use user-classes in the specification ● generated code is directly useful include abstract versions of user classes given in Java ● derive an abstracted specification 24 4 December 2008 Antonio Cansado

  25. How to Define an Abstraction ? ● For each variable in JDC, define an abstract type abstract domain ● based on provided library of simple types abstract operators of concrete methods ● Java syntax encoding the results of expressions assign abstract types to fields 25 4 December 2008 Antonio Cansado

Recommend


More recommend