Towards a Versatile Contract Model to Organize Behavioral Specifications

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