Date post: | 16-Dec-2015 |
Category: |
Documents |
Upload: | darrius-duck |
View: | 213 times |
Download: | 0 times |
1
Reuse Contracts
Patrick Steyaert
Programming Technology Lab
Vrije Universiteit BrusselE-mail: [email protected]
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() []
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]
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]
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
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