1. 1 Reuse Contracts Patrick Steyaert Programming Technology Lab Vrije Universiteit Brussel E-mail: prsteyae@vnet3.vub.ac.be WWW: http://progwww.vub.ac.be/prog/pools/rcs/

2. 2 Goal: Object-Oriented Reuse Methodology 4Useful in e.g. commercial software development »solve practical problems: “good” reuse documentation, proliferation of versions, architectural drift, overfeaturing, reuse estimation »validation in practice – cases – tools 4Formal foundation »formal notation »“specification” of frameworks and how applications are derived

3. 3 Framework-based Developement 4Framework implementation »template consisting of abstract classes »contracts govern the interaction »hot spots (variation points in templates) 4Framework reuse »filling in hot spots (contract conformance) »refining the framework (contract refinement, inclusion, …)

4. 4 Class Q Class Y Class R conforming B Contracts (Helm&al.) Class X Class Y Class Z conforming A Participant AParticipant B Contract T 4Contract Specification »participants and type obligations »causal obligation and invariants 4Contract Reuse »conformance »refinement, inclusion

5. 5 Example: Observer Contract Subject subjectState attach(Observer) detach(Observer) notify() getState() setState() Observer observerState update() state forall o in observers o update observerState reflects subjectState INVARIANT Subject setState() -> forall o in observers: o.observerState reflects subjectState self notify

6. 6 Issues … 4What versus how »invariants are not allways specified (specifiable) ! 4Contracts allow “disciplined” reuse »if (and only if) conformance checking is automatic ! 4Contracts are too “coercive” »framework reuse is not necesarily filling in hot spots ! 4Change management »frameworks themselves evolve !

7. 7 Reuse Contracts 4Two-sided specification of contracts »framework specifies what can be assumed »reuser specifies what is assumed 4Specification that is “structural” »close to the “structure” of the code »static conformance checking »extraction/code generation 4Conflict checking rather than avoidance

8. 8 Quick Case Study : Reuse in Class Hierarchies Abstract A SubClass B SubClass C Abstract A SubClass B SubClass C SubClass D parent class change ? ?

9. 9 Specialisation Clauses declaring (part of) the specialisation interface Set add(Element) addAll(Set) Set add(Element) addAll(Set) [add] Class Set method add (e:Element) = 0 method addAll(aSet:Set) = begin for e in aSet do self.add(e) end End implementation will invoke add Specialisation clauses declare the assumptions that can be made about a class !

10. 10 Estimating Reuse with Specialisation Clauses CountingSet add(Element) [count] I am certain that I need to override both add and addAll. Set add(Element) [] addAll(Set) [] CountingSet add(Element) [count] Set add(Element) [] addAll(Set) [add] addAll(Set) [count] I have an indication that I only need to override add (addAll can be reused). count() []

11. 11 Evolution in Class Hierarchies Changing a method

12. 12 Example Set add(Element) addAll(Set) CountingSet add(Element) Set (Optimized) addAll(Set) add(Element) addAll(Set) CountingSet add(Element) addAll(Set) not all elements are counted count()

13. 13 Changing Assumptions add(Element) addAll(Set) [add] Assumption made by reuser (before change) CountingSet Assumes add(Element) addAll(Set) [] What can be assumed (after change) CountingSet Actually gets

14. 14 BUT… CountingSet add(Element) SomeSet …concrete parent class … add(Element) addAll(Set) [add] Assumes Too verbose ! Does not document how SomeSet is actually reused !

15. 15 Declaring How a Class is Actually Reused documenting different kinds of reuse Set add addAll [add] CountingSet count Refinement 3 add [+count] add [count] Set add addAll [add] CountingSet count add [count]

16. 16 Different Kinds of Reuse 3Assumption “preserving” »Concretisation: filling in the “hot spots” »Refinement: refining the overall design »Extension: adding new behaviour 3Assumption “breaching” »Abstraction: generalisation »Coarsening: performance optimisation »Cancellation: fixes, elimination of needless features

17. 17 Set add addAll [add] CountingSet count add [count] Estimating Impact of Changes Coarsening 3 addAll [-add] addAll needs to be overridden too Set add addAll [add] CountingSet count add [count] Refinement 3 add [+count] Refinement 3 add [+count]

18. 18 Checking Conflicts Base Contract M1 M2 Derived Contract New Base Contract Possible conflicts Interface conflicts Method capture Inconsistent methods Unimplemented methods Dangling reference Unanticipated recursion

19. 19 Reuse Contracts for Inheritance Asset reuser Asset provider 3 rules for detecting conflicts Set add() addAll() [add] Refinement 3 add […] 3 specialisation clauses declare how to reuse a class »formally »non-coercively 3 operators declare how a class is reused »formally »disciplined

20. 20 Multi-class Reuse Contracts node accept isDestinationFor handle send packet visit [action] action accept [visit] visit [isDestinationFor, send] action [handle] Contract: Packet Handling participant specification e.g. class, module, object … communication specification e.g. message, event, …

21. 21 LAN Contracts node accept(Packet) [send] send(Packet) nextNode accept(Packet) send[accept] Contract: Packet Forwarding next outputServer(node) accept(Packet) [+isDestinationFor, send, +handle] +isDestinationFor(Packet) +handle(Packet) send(Packet) Contract: Packet Handling Refines: Packet Forwarding Refinement

22. 22 LAN Contracts packet +visit(Node) [action] +action(Node) accept [+visit] visit [isDestinationFor, send] action [handle] Contract: Point To Point Communication Factorisation of: Packet Handling outputServer(node) accept(Packet) [isDestinationFor, send, handle] isDestinationFor(Packet) handle(Packet) send(Packet) Contract: Packet Handling Refines: Packet Forwarding Factorisation outputServer(node) accept(Packet) [-isDestinationFor, -send, -handle]

23. 23 Impact Analysis Changing a method AB AB Conflict when merging both modifications M1M1 M2M2 AB

24. 24 Variations on Communication outputServer broadcastPacket(packet) action(Node) action [handle, +send] Contract: Broadcasting Refines: Point To Point Communication outputServer collector(broadcastPacket) action(Node) [+addName] +addName() accept [visit] action: [-handle, send] Contract: NameCollecting Coarsens, Refines: Broadcasting

25. 25 Variations on Network Structure gateway(node) +relay(Packet) handle(Packet) [+relay] Contract: GatewayCommunication Refines, Extends: Point To Point Communication

26. 26 Conflicts ? node packet action [handle, +send] Contract: Broadcasting Refines: Point To Point Communication outputServer(node) accept(Packet) isDestinationFor(Packet) handle(Packet) send(Packet) packet visit(Node) [action] action(Node) accept [visit] visit [isDestinationFor, send] action [handle] Contract: PointToPointCommunication Contract: GatewayCommunication Refines, Extends: Point To Point Comm. gateway(node) +relay(Packet) handle(Packet) [+relay]

27. 27 Conflicts ! node collector action: [-handle, send] Contract: NameCollecting outputServer(node) accep(Packet) isDestinationFor(Packet) handle(Packet) send(Packet) packet visit(Node) [action] action(Node) accept [visit] visit [isDestinationFor, send] action [handle] Contract: PointToPointCommunication Contract: GatewayCommunication Refines, Extends: Point To Point Comm. gateway(node) +relay(Packet) handle(Packet) [+relay]

28. 28 Composition Problem ! Gateway NameCollector DomainAddress

29. 29 Combined Reuse Operators extension m+n M1 refinement m[+n] M2 extension m [n]+x M1 refinement x[+n] M2 coarsening m[-n] M2 extension m+n M1 refinement n[+m] M2 Connected extension Extending refinement coarsening n m[n] m[-n] M1 cancellation -n M2 Coarsening cancellation Factorisation

30. 30 Checking Conflicts A M1 M2 M3 N1 Conflicts ?

31. 31 Reuse Contracts & OOD node:Node accept [send] send nextNode:Node accept send[accept] Node accept [send] send send[accept] next previous Object level: Class level: Other issues: 4Multiplicity 4Super 4Inheritance 4Parameters, results

32. 32 Current & Future Work (I) 4Reuse Contracts for OO + established for inheritance and multi-classes + embedding in OOA/OOD … ? more expressive interaction specifications 4Formal Foundation + formalisation on “operational level” ? completeness, soundness 4Cases and methodolgy + OO Partners (CACM paper), EDS, student projects ? still needs lots of work 4Architecture, frameworks and design patterns 4Tools

33. 33 Drawing Editor Firstname Lastname Age Person Editor License Brand Age Car Editor Person Car Drawing Reusable Architectures ??

34. 34 Design Patterns Subject attach(Observer) detach(Observer) notify() getState() setState() [notify] Observer update() ConcreteObserver update() ConcreteSubject subjectState getState() setState() [notify] notify [update] subject update [getState] concretisation 3update concretisation 3getState, setState implementation must invoke update ConcreteSubject must make Subject concrete

35. 35 4Major technical challenges before reuse becomes standard practice: »disciplined, non-coercive reuse »“good” reuse documentation that can be used in practice »proliferation of versions, iterative development »estimates/ testing/ metrics 4Reuse contract between asset provider and reuser »declare how an asset can be reused, and is reused »formal rules for change propagation 4Towards a reuse methodology … »… emphasising the co-operation between asset provider and asset reuser Conclusion