Universität Karlsruhe (TH) Research University • founded 1825 Describing Softw are Com ponents w ith Param etric Contracts Ralf Reussner (reussner@ipd.uka.de) Chair Software Design and Quality Institute for Program Structures and Data Organization (IPD) Fakultät für Informatik, Universität Karlsruhe (TH), Karlsruhe Institute of Technology
Param etric Com ponent Properties Parametric Contract a: b 33ms 28ms ? a b 20ms 10ms c 5ms c ▪ Design-by-Contract for Software-Components ▪ Specification of the relation between provides and requires-interface(s) (and the usage profile and execution environment) Ingenieurdisziplin – Vorgehen – Komponenten – Modelle - Ausblick Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 2
Overview ▪ Contracts and Parametric Contracts ▪ Protocol Adaptation with Parametric Contracts ▪ Prediction of Non-Functional Properties with Parametric Contracts – Reliability – Performance ▪ Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 3
W hat is a com ponent? ▪ “A component is a contractually specified building unit of software which can be readily composed or deployed.” – “readily composed or deployed”: • without having to understand the interna as a human • these are the two main things to be done with components – not necessarily “black-box”: Information on interna can be available to tools. ▪ “Components are for composition, much beyond is unclear…” (Clemens Szyperski) Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 4
Different Abstraction of Com ponents QoS (i, es, up, d) CT Type Type FP (es) 1 1 «implements» * * IID QoS (es, up, d) Implementation Implementation Instance FP (es) Description 1 «deploys» * DID QoS (up) Deployment Deployment Instance FP () Description RID Not considered within the Palladio ComponentModel Runtime Runtime Instance i: implementation Description es: external services up: usage profile d: deployment Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 5
Contractual Use of Methods ▪ Design-by-contract (B. Meyer, 1992) “Supplier guarantees post-condition if pre-condition is fulfilled by client.” [Bertrand Meyer, Object Oriented Software Construction, Prentice-Hall, 1997 2 nd ed.] CustomerRecord getCustomerRecord (String ID) Post-condition Pre-condition Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 6
Design-by-Contract ( Bertrand Meyer, 1 9 9 2 ) Obligations Benefits Client Satisfy From postcondition: precondition: Get customer returned or null (attached database) Supplier Satisfy From Precondition: postcondition: Handle queries only if Get right customer database is attached. or return null . Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 7
Benefits of Contracts ▪ Developing less error-prone software through: – Better documentation – Reduced error-handling code – Clear responsibilities – Results of run-time checking as a debugging aid Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 8
Contractual Use of Com ponents Component Component’ Required Provided Interface Interface Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 9
Use of Com ponents There are two different times of component usage: 1. At system run-time (== component run- time): call of component services 2. At system design-time or system configuration time: plugging in of components Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 0
Contractual Use of Com ponents ▪ Design-by-contract (B. Meyer, 1992) – “Supplier guarantees post-condition if pre- condition is fulfilled by client.” ▪ Contractual Use of Components – (at system design- / configuration-time) – “Component guarantees provided services (as described in the provides-interface) if the environment offers all required services (as described in the requires-interface).” Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 1
Contractual Use of Com ponents ▪ Pre-condition – Required services – Information concerning required services (sequences, QoS) ▪ Post-condition – Offered services – Information concerning offered services (sequences, QoS) ▪ Invariant – Relation between provided and required services (as this is independent from the usage context) Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 2
Contractual use of Com ponents ▪ Design-by-contract (B. Meyer, 1992) {Pre} {Post} “ The service supplier guarantees the {Pre} {Post} {Pre} {Post} post-condition, if the client guarantees ... the precondition of the service.” ▪ Contractual Use of Components (at system-(re-) configuration time) “The component offers the provided services (as specified in the provides interfaces), if the environment ... ... guarantees the required services (as specified in the requires interfaces).” Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 3
Contractual Use of Com ponents ▪ Contractual use corresponds to interoperability checks: R C ⊆ P C´ ▪ Static checks of practical relevance Component Component’ Required Provided Interface Interface Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 4
Consequences ( 1 ) ▪ Interoperability checks during design- or reconfiguration time are possible by checking the pre-condition against the post-condition of the environment Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 5
Problem : Three external I nfluences on Quality ( Perform ance / Reliability) Performance / Reliability? … if (a>b) c = a; … Usage Model External Services Execution Evnironment Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 6
Consequences ( 2 ) ▪ But: – Fixed pre- and post-condition hinder adaptation – Pre- and post-condition are hard to fix at design-time – In particular, if non-functional properties are to be specified in interfaces. Com ponents and their contracts need to be adapted to context at deploym ent, w hich is after developm ent! Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 7
Need for Param etric Contracts ▪ One single pair of pre- and postcondition insufficient: – restriction of reuse – need for transparent component adaptation – QoS-properties depend on component context and are not fixed. Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 8
Param etric Contracts for Com ponents Parametric Contract Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 1 9
Param etric Contracts ▪ Link provides- and requires interface of the same component by bijective function p: {P} → {R} ▪ Pre-condition computed out of post- condition (and vice versa) ▪ Mechanism of automatic component adaptation (besides adaptor generation) Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 2 0
Param etric Contracts for Com ponents ▪ Computation of environment-dependent provides-interface ▪ Computation of use-dependent requires- interface (‘wp-calculus’) ▪ Fine-grain adaptation of large-grain components Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 2 1
Com putation of Param etric Contracts ▪ Computation of ▪ Computation of context-dependent context-dependent provides-interface: requires-interface: 1. (R A = p A (P A )) 1.P B’ := R A ∩ P B 2. R A’ := R A ∩ P B 2.R B’ = p B (P B’ ) 3. P A’ = p A -1 (R A’ ) R A R B P A P B A B p A p B Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 2 2
Param etric Contracts Parametric Contract a: b 33ms 28ms ? a b 20ms 10ms c 5ms c ▪ Lifting the Design-by-Contract Principle to Software Components ▪ Linking the provided and required services of the same component Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 2 3
Hierarchie of I nterface Models ... Quality of Service Protocols Signature-Lists Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 2 4
Param etric Contracts for Signature-list based I nterfaces Service-Effect-Specifications void foo () requires externalMethod1 Provides-Interface Service Effect externalMethod2 … provides-interface { Specification: { void foo (); List of required … int bar (); } … services for } each provided service R P Component Contracts – Protocols - Quality - Conclusions Ralf Reussner, FLACOS, Oslo 2 0 0 7 1 4 / 1 0 / 2 0 0 7 2 5
Recommend
More recommend
