1

Reuse Contracts

Patrick Steyaert

Programming Technology Lab

Vrije Universiteit BrusselE-mail: prsteyae@vnet3.vub.ac.be

WWW: http://progwww.vub.ac.be/prog/pools/rcs/

2

Goal: Object-Oriented Reuse Methodology

Useful 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

Formal foundation» formal notation

» “specification” of frameworks and how applications are derived

3

Framework-based Developement

Framework implementation» template consisting of abstract classes» contracts govern the interaction» hot spots (variation points in templates)

Framework reuse» filling in hot spots (contract conformance)» refining the framework (contract

refinement, inclusion, …)

4

Class QClass Y

Class R conforming B

Contracts (Helm&al.)

Class X

Class YClass Z conforming A

Participant A Participant B

Contract T

Contract Specification» participants and type obligations» causal obligation and invariants

Contract Reuse» conformance» refinement, inclusion

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

INVARIANTSubject setState() -> forall o in observers: o.observerState reflects subjectState

self notify

6

Issues …

What versus how» invariants are not allways specified (specifiable) !

Contracts allow “disciplined” reuse» if (and only if) conformance checking is automatic !

Contracts are too “coercive”» framework reuse is not necesarily

filling in hot spots !

Change management» frameworks themselves evolve !

7

Reuse Contracts

Two-sided specification of contracts» framework specifies what can be assumed» reuser specifies what is assumed

Specification that is “structural”» close to the “structure” of the code» static conformance checking» extraction/code generation

Conflict checking rather than avoidance

8

Quick Case Study : Reuse in Class Hierarchies

Abstract A

SubClass B

SubClass C

Abstract A

SubClass B

SubClass C

SubClass D

parent classchange ?

?

9

Specialisation Clauses

declaring (part of) thespecialisation interface

Set

add(Element)addAll(Set)

Set

add(Element)addAll(Set) [add]

Class Setmethod add (e:Element) = 0method addAll(aSet:Set) =

beginfor 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

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() []count() []

11

Evolution in Class Hierarchies

Changing a method

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 elementsare counted

count() count()

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

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

Declaring How a Class is Actually Reused

documenting differentkinds of reuse

Set

addaddAll [add]

CountingSet

count

Refinement add [+count]

add [count]

Set

addaddAll [add]

CountingSet

countadd [count]

16

Different Kinds of Reuse

Assumption “preserving”» Concretisation: filling in the “hot spots”» Refinement: refining the overall design» Extension: adding new behaviour

Assumption “breaching”» Abstraction: generalisation» Coarsening: performance optimisation» Cancellation: fixes, elimination of needless features

17

Set

addaddAll [add]

CountingSet

countadd [count]

Estimating Impact of Changes

Coarsening addAll [-add]

addAll needs to be overridden too

Set

addaddAll [add]

CountingSet

countadd [count]

Refinement add [+count]

Refinement add [+count]

18

Checking Conflicts

M1M2

extension m refinement m refinementn{m}

cancellation m coarsening m coarseningn{-m}

extension m name refinement m spec. clause capture dangling ref. spec. clause inconsistentrefinement

n{m} . spec. clause dangling ref. capture spec. clause

cancellation m . . . OK dangling ref. dangling ref.coarsening m . . . . spec. clause inconsistent

coarseningn{-m}

. . . . . spec. clause

Base ContractM1

M2

Derived Contract

New Base Contract

Possible conflicts

Interface conflicts

Method capture

Inconsistent methods

Unimplemented methods

Dangling reference

Unanticipated recursion

19

Reuse Contracts for Inheritance

Asset reuserAsset provider

rules for detecting conflicts

Set

add()

addAll() [add]

Refinement add […]

specialisation clauses declare how to reuse a class

»formally»non-coercively

operators declare how a class is reused

»formally»disciplined

20

Multi-class Reuse Contracts

node

acceptisDestinationForhandlesend

packet

visit [action]action

accept [visit]

visit [isDestinationFor, send]action [handle]

Contract: Packet Handling

participant specificatione.g. class, module, object …

communication specificatione.g. message, event, …

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

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

Impact Analysis

Changing a method

A B

A B

Conflict when merging both modificationsM1

M2

A B

24

Variations on Communication

outputServerbroadcastPacket(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

Variations on Network Structure

gateway(node)

+relay(Packet)handle(Packet) [+relay]

Contract: GatewayCommunication Refines, Extends: Point To Point Communication

26

Conflicts ?

node packet

action [handle, +send]

Contract: BroadcastingRefines: 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: GatewayCommunicationRefines, Extends: Point To Point Comm.

gateway(node)

+relay(Packet)handle(Packet) [+relay]

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: GatewayCommunicationRefines, Extends: Point To Point Comm.

gateway(node)

+relay(Packet)handle(Packet) [+relay]

28

Composition Problem !

Gat

eway

Na

me

Co

llect

or

DomainAddress

29

Combined Reuse Operators

extensionm +n

M1

refinementm[+n]

M2

extensionm [n] +x

M1

refinementx[+n]

M2

coarseningm[-n]

M2

extensionm +n

M1

refinementn[+m]

M2

Connected extension

Extending refinement

coarseningnm[n]

m[-n]M1

cancellation-n

M2

Coarsening cancellation

Factorisation

30

Checking Conflicts

A

M1

M2

M3

N1

N1 Conflicts ?

31

Reuse Contracts & OOD

node:Node

accept [send]send

nextNode:Node

accept

send[accept]

Node

accept [send]send

send[accept]

next

next

previous

previous

Object level:

Class level: Other issues:MultiplicitySuperInheritanceParameters, results

32

Current & Future Work (I)

Reuse Contracts for OO+ established for inheritance and multi-classes

+ embedding in OOA/OOD …

? more expressive interaction specifications

Formal Foundation+ formalisation on “operational level”

? completeness, soundness

Cases and methodolgy+ OO Partners (CACM paper), EDS, student projects

? still needs lots of work

Architecture, frameworks and design patterns Tools

33

Application LayerApplication Layer

Domain LayerDomain Layer

Persistency LayerPersistency Layer

Drawing Editor Firstname

Lastname

Age

Person Editor

License

Brand

Age

Car Editor

Person

CarDrawing

Reusable Architectures

?

?

34

Design Patterns

Subject

attach(Observer)detach(Observer)notify()getState()setState() [notify]

Observer

update()

ConcreteObserver

update()ConcreteSubjectsubjectState

getState()setState() [notify]

notify [update]

subjectupdate [getState]

concretisationupdateconcretisation

getState, setState

implementation must invoke

update

ConcreteSubject must make

Subject concrete

35

Major 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

Reuse contract between asset provider and reuser» declare how an asset can be reused, and is reused

» formal rules for change propagation

Towards a reuse methodology …» … emphasising the co-operation between asset provider and asset reuser

Conclusion