1 / 25

Verifying the correct composition of distributed components: Formalisation and Tool

Verifying the correct composition of distributed components: Formalisation and Tool. Ludovic Henrio 1 , Oleksandra Kulankhina 1,2 , Dongqian Liu 3 , Eric Madelaine 1,2 1: Univ. of Nice Sophia Antipolis , CNRS, France 2: INRIA – Sophia Antipolis , SCALE team, France

nola
Download Presentation

Verifying the correct composition of distributed components: Formalisation and Tool

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Verifying the correct composition of distributed components:Formalisation and Tool Ludovic Henrio1, Oleksandra Kulankhina1,2, Dongqian Liu3, Eric Madelaine1,2 1: Univ. of Nice Sophia Antipolis, CNRS, France 2: INRIA – Sophia Antipolis, SCALE team, France 3: East China Normal University, China FOCLASA , 06/09/2014, Rome

  2. Context • Grid Component Model: hierarchical components for distributedsystems • Design and executionenvironment for GCM: ProActive: deploy and run components Component Factory: Generate components Global objective: ensure correct execution of large-scaledistributed applications VerCors: design application ADL files GCM Compo-nents

  3. Challenges • No formal model for GCM architecture • No notion of well-formed components in GCM • No communication between business logic and control part • VerCorstoolwas not completelyimplemented

  4. Contribution • formalisation of GCM component architecture • validation constraints that ensure static properties for GCM component assemblies • formalisationof the notion of interceptors in GCM • implementation of a graphical modeling environment for GCM • implementation of architecture validity checks with respect to the proposed formalisation

  5. Agenda • Motivation and goal • Background • Formalisation • Separation of concerns in GCM architecture • Interceptors • Constraints and properties • Implementation • Tool: VerCors • Application to the other component models • Conclusion and future work

  6. Background: Grid Component Model (GCM) Client interfaces: invokemethods, receiveresults Composite: containsother components Server interfaces: serve methods, sendresults Primitive: encapsulates code Asynchronous Distributed Hierarchical Bindings

  7. Agenda • Motivation and goal • Background • Formalisation • Separation of concerns in GCM architecture • Interceptors • Constraints and properties • Implementation • Tool: VerCors • Application to the other component models • Conclusion and future work

  8. Separation of concerns in GCM architecture • Content: responsible for business logic • Membrane: responsible for control part • Functional and non-functional interfaces • Business logic and control part can be designed separately

  9. Interceptors: what they are used for? • Example: Monitoring and reconfiguration

  10. How do we recognize interceptors chains? • all the components are nested inside the membrane • all the components have exactly one functional server and one functional client interface • The interceptors form a chain • the first and the last components of the chain are connected to the composing component

  11. Formalization • Validation Contraints • Architecture • Wellformness • Interceptors

  12. Static properties and validation rules (1) Component encapsulation Bindings do not cross the boundaries of the components Correct typing Interfaces connected by bindings have compatible roles Interfaces connected by bindings have compatible methods

  13. Static properties and validation rules (2) Deterministic communications Each client interface is connected to at most one server interface Unique naming Interfaces have unique names inside a container Components have unique names inside a container

  14. Static properties and validation rules (3) Separation of concerns The interfaces connected by a binding should have compatible control levels • CL of a functional interface = 1 • CL of a non-functional interface = 2 • CL isincreased by 1 for interfaces of controllers • Compatible CLs: eitherboth = 1, or both >1

  15. Static properties and validation rules (4) • CL of a functional interface = 1 • CL of a non-functional interface = 2 • CL isincreased by 1 for interfaces of controllers • Compatible CL: • either = 1, or >1 1 2 2 2 2 1 1 1 2 1 1

  16. Agenda • Motivation and goal • Background • Formalisation • Separation of concerns in GCM architecture • Interceptors • Constraints and properties • Implementation • Tool: VerCors • Application to the other component models • Conclusion and future work

  17. Tool: VerCors • Based on ObeoDesigner • Graphical environment for GCM Components and UML Diagrams Produces ADL files, Java classes and Java interfaces Distributed as Eclipse plugins

  18. Static validation in VerCors • Check all the constraints specified in the paper • Use Acceleo, OCL and Java Services • Inform user about the violation of constraints

  19. Agenda • Motivation and goal • Background • Formlisation • Separation of concerns in GCM architecture • Interceptors • Constraints and properties • Implementation • Tool: VerCors • Application to the other component models • Conclusion and future work

  20. Application to the other component models • Fractal: would reuse everything except non-functional aspect and interceptors • AOKell: would reuse non-functional part and componentized membrane • SOFA: hierarchical structure, componentized membrane, “delegation chains” that act like interceptors; would reuse most of our constraints • SCA: hierarchical model, would reuse a lot of notions

  21. Agenda • Motivation and goal • Background • Formlisation • Separation of concerns in GCM architecture • Interceptors • Constraints and properties • Implementation • Tool: VerCors • Application to the other component models • Conclusion and future work

  22. Conclusion • A formal model for GCM architecture • The well-formness properties of GCM components • Formalization of interceptors in GCM • A graphical specification environment for GCM components modeling and static validation • Application to other component models

  23. Future work • Toolevolution: • Producebehavioralmodels and model-check them • Generate Java code for UML State Machines • Validateotherstaticproperties as a prerequesite for the generation of behaviormodels • check compatibility between the State Machines and UML Interfaces

  24. Thankyou for your attention! Verifying the correct composition of distributed components:Formalisation and Tool LudovicHenrio, OleksandraKulankhina, DongqianLiu, Eric Madelaine References: • Vercors:https://team.inria.fr/scale/software/vercors/ • GCM: F. Baude, D. Caromel, C. Dalmasso, M. Danelutto, V. Getov, L. Henrio, C. Perez: GCM: A Grid Extension to Fractal for AutonomousDistributed Components, in Annals of Telecommunications, Vol. 64, no1, jan 2009. • FrancoiseBaude, Ludovic Henrio & Cristian Ruz (2014): Programmingdistributed and adapt- able autonomous components-the GCM/ProActiveframework. Software: Practice and Experience, doi:10.1002/spe.2270. Availableat http://dx.doi.org/10.1002/spe.2270.

  25. Group communications Nx1 communications: gathercast 1xN communications: multicast

More Related