1 / 16

Towards a Versatile Contract Model to Organize Behavioral Specifications

Towards a Versatile Contract Model to Organize Behavioral Specifications. Philippe Collet 1 , Alain Ozanne 2 and Nicolas Rivierre 2 1. University of Nice, I3S Laboratory, France 2. France Telecom R&D, France. service. component. Context: Assembled Applications. Requirements:

finnea
Télécharger la présentation

Towards a Versatile Contract Model to Organize Behavioral Specifications

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. Towards a Versatile Contract Model to Organize Behavioral Specifications Philippe Collet1, Alain Ozanne2 and Nicolas Rivierre2 1. University of Nice, I3S Laboratory, France 2. France Telecom R&D, France

  2. service component Context: Assembled Applications • Requirements: - Dependability : assembly validity (requirements satisfaction), - Robustness : diagnosis, failure repair, Sound Composition • Locks : - Properties complexity : • kinds: QoS (SLA..), behavior (service interaction…), … [Beugnard] • formalisms: CQML, Quo, assertions, Behavior Protocol… - Dynamic evolutions

  3. Motivations and Requirements • A tool to improve the composition dependability • A tool that deals with various properties and verifications means • A tool compatible with the dynamic evolutions of architectures • A tool conceptually as secure and explicit as real life contracts

  4. Goal: a Contracting Framework • A framework that contractually: • P1 : Makes explicit the conformity of individual components with their specification • Conformity • P2 : Makes explicit, for a configuration of components, the compatibility of their specifications • Compatibility • P3 : Makes explicit the responsibilities of the components against their specifications • Responsibilities • P4 : Supports various specification formalisms and verification techniques • Formalisms

  5. J2EE Related Work Existing frameworks Conformity Goal Compatibility Responsibility Various formalisms

  6. Interface Contract assertion scope = interface Internal Composition Contract assertion scope = composite’s inside External Composition Contract assertion scope = component’s outside ConFract: - Assertions associated with a component - Components’ conformity to assertions - Associated responsibility System

  7. Assumption Clause Guarantee Agreement Guarantee Clause Clause Assumption Contract Model Participant Assumption Participant Participant Guarantee Clauses satisfaction + Agreement satisfaction => Sound Composition

  8. Contractual formalism P3 Component specification P1 P2 P4 Contract and Formalisms Contract { Participants : <component_name>* ; Clauses : { clause : <name> responsible : <component_name> ; assumption : < constraint > guarantee : < constraint > } * Agreement : { agreement : < constraint >*} } • Generic Contract : • Constraint description : On <component_name> Observe : ( val : <some values> at : <some events>; ) + Verify : < predicate >

  9. Behavior Protocols • Expressions specifying sequences of communication events: • Emitted and received method calls and returns of method calls • On the interfaces of one component ("frame protocol") • On the outside interfaces of an assembly of sub-components ("architecture protocol") • Regular-like expressions • <speedCtrl> : (?ppt.enable; !csp.setThrottle*; ?ppt.disable)* • Tools are provided to check • Implementation conformity • Protocols compatibility (horizontal and vertical)

  10. Application of Behavior Protocols <CruiseCtrl> ?sns.engineOn; (?sns.on; !csp.setThrottle*; (?sns.accelerate + ?sns.brake + ?sns.off)*)* + ?sns.engineOff <speedCtrl> (?ppt.enable; !csp.setThrottle*; ?ppt.disable)* <sensorCtrl> ?sns.engineOn; (?sns.on; !ppt.enable; (?sns.accelerate + ?sns.brake + ?sns.off)*; !ppt.disable)* + ?sns.engineOff

  11. ppt csp <SpeedCtrl> speedCtrlFP = (?ppt.enable; !csp.setThrottle*; ?ppt.disable)* Resulting Contract (1/2) • Frame protocols as clauses : Contract : Participants : <SensorCtrl>, <CruiseCtrl>, <SpeedCtrl> ; ... Clause : responsible : <SpeedCtrl> assumption : On <SpeedCtrl> Observe : val : at entry ppt.*; Verify : runtimeCheck(speedCtrlFP); guarantee : On <SpeedCtrl> Observe : val : at entry csp.*; Verify : runtimeCheck(speedCtrlFP); ...

  12. Contract : Participants : <SensorCtrl>, <CruiseCtrl>, <SpeedCtrl> ; ... Agreement : On <CruiseCtrl> Observe : val : at : entry <CruiseCtrl>.start Verify : verticalCheck (cruiseCtrlFP, parallelCheck (sensorCtrlFP, speedCtrlFP)) verticalCheck parallelCheck Resulting Contract (2/2) • Agreement : <CruiseCtrl> <SensorCtrl> <SpeedCtrl>

  13. <SpeedCtrl> pre : throttle > 10 pre : throttle > 0 post : return > 0 post : return > 10 Agreement : Client side <SpeedCtrl> Server side <CruiseCtrl> return > 10 => return > 0 throttle > 10 => throttle > 0 Contract for Assertion-based Formalism float getResponseTime(float throttle) <CruiseCtrl> csp Clause : <CruiseCtrl> Clause : <SpeedCtrl> G = A = Clause : <SpeedCtrl> A = G =

  14. R1. Formalisms integrator R2.Domain specifier Framework R3. User of the results of the contract evaluation Building Checking Pre/post conditions Contractual Spec. Contract Guarantee Fractal System Observations Integration and Use Example of use with an assertion translator :

  15. Conclusion • Operational contract model for components architecture • Supports the expected properties provided that: • Specifications can be translated in assumption-guarantee constraints • Specifications have tools for checking conformity and compatibility • Simple and pragmatic principles for software architects • Future works : • Vertical composition of contracts between consecutive levels of nesting (when the formalism supports it), • Application to other architectural platforms (components, services…)

  16. Questions

More Related