1. Reuse Contracts: Managing the Evolution of Reusable Assets
Patrick Steyaert
Kim Mens
Carine Lucas
Theo D’Hondt
Programming Technology Lab
Vrije Universiteit Brussel

2. Reuse is Extremely Important !
RAD (Rapid Application Development)
Reduced maintenance
Reduced testing …
Avoid over-featuring
Avoid “legacy systems”

3. Proliferation of Versions
Application A
Asset A’
Asset B
Repository
Asset A
Asset B
Application B
Asset B’
Application C
Asset A’’
One obvious problem, one problem that is more subtle.
The first has to do with maintenance.
Consider a repository and applications that reuse assets out of this repository, possibly adapting the assets before reuse. Each application now has its own version of the assets it reuses. How hard is it to make modifications to the assets in the repository ? As we already said this might be a problem for white-box assets. It is hard to propagate changes from the repository to the applications. Thus the assets in the repository and those in the application become disconnected, they start living their own live. Rather than making maintenance easier, maintenance now becomes very difficult, as we have to manage all these different versions.
The second problem has to do with iterative development. Reusable assets become only truely reusable by a number of iterations (i.e. reusing them in different applications, refining them when necessary). This is especially true with frameworks. You create a framework, develop an application with it, where necessary, adapt the framework so that it becomes more reusable. When application start using their own version of a reusable asset, then there is a big chance that the knowledge they acquire, the improvements they make to the asset does not flow back to the repository. So the repository will not evolve and the assets in it will not become really reusable.
Example: class hierarchy of matrix manipulations.
Maintenance problem: version management
Development problem: iterative development

4. Evolution is Important !
Iterative development
Changing requirements
Repository
Repository
Evolution

5. What are the Challenges ?
Supporting reuse
what can be reused, what must be adapted, and what must be built from scratch ?
documentation on how assets are reused
Supporting evolution
change propagation
Difficult to do estimates/testing/metrics
feasability of reusing an asset
the cost of “upgrading” the reuse repository
What are the problems to be solved
- assets that come out of the repository must often be adapted before reuse, so that black-box reuse doesn’t work on itself. white-box reuse doesn’t work because of the danger of reuse by copy and a lack of documentation of how to adapt. Framework reuse goes in the right direction.
- estimates
In the current state of the art estimations for changing and reusing assets can only be done by informal reasoning. What do we want to estimate ?
- where and how to test
what is the impact of changes to the repository, which code will break what code will work ?
- proliferation of version -> next slide

6. Reuse Contracts Asset provider Asset reuser
declares how an asset can be reused (formally, non-coercively)
declares how an asset is reused (formally, disciplined)
So asset providers and asset reusers need to work together so that the asset reuser can profit from enhancements made to the assets he/she reuses and the asset provider can profit from the knowledge and improvements asset reusers make to assets.
They need a contract to do so.
Let’s have a look at the problems first:
black-box, or generic components: adaptation in a predefined way
white-box: everithing can be adapted/changed, no indication on what is adapted/changed
So, clearly, the asset provider must expose some of the internal workings, but only part of it only those parts that he can commit to that if they change, reusers are notified. It’s an interface, but one that not only hides the internal workings, but also one that can change.
Asset reusers need to declare how the rely on this interface, so that if it changes we know which reusers, and which part of the reusers of will need attention.
rules for change propagation

7. Case Study: Evolution in Class Hierarchies
Abstract A
Abstract A’
parent class
exchange ?
SubClass B
SubClass B
SubClass C
SubClass C
We took abstract classes as assets and inheritance as a reuase mechanisms as a case study to explore the idea of reuse contracts. Inheritance is relatively well-known, this gives us a good framework to explore the idea of reuse contracts. The idea is (and we are doing this right now) to start with inheritance and explore reuse contracts in general later on.
The idea is to explore how parent classes can change and what the impact is on existing inheritors.
There are three problems here:
1) what to override? Depends on the calling structure of the parent class.
2) if we change a parent class, what will be the effect on existing inheritors. Will all of the overriden methods still work?
3)we have a parent class, I want to add some behaviour. Where do I inherit, directly from the parent class, one of its inheritors. If I inherit from one of the inheritors, do I need to inspect all of the intermediate classes in order to know what must be overriden ?
Let’s have a look at one of the problems that might occure when exchanging a parent class. ?
SubClass D

8. Possible Conflicts Name & annotation conflicts
Incomplete implementation
Method capture
Inconsistent methods
Abstract A
Abstract A’
parent class
exchange
SubClass B
SubClass B

9. Conflicts: Inconsistent Methods
Set
Set (Optimized)
add(Element)
add(Element)
addAll(Set)
addAll(Set)
CountingSet
count+1
CountingSet
count+1
add(Element)
add(Element)
explain problem
notice that we need to look at the implementation to detect this problem
addAll(Set)
addAll(Set)
not all elements are counted

10. Step 1: Documenting the Design
documenting (part of) the
specialisation interface
Set
add(Element)
addAll(Set)
Specialisation
interface
Set
abstract
add(Element)
addAll(Set) {add}
invokes add

11. Step 2: Declaring How a Class is Actually Reused
Set
Set
add(Element)
documenting different
kinds of reuse
add(Element)
addAll(Set)
addAll(Set) {add}
Concretisation
add
CountingSet
CountingSet
add(Element)
add(Element)

12. Different Kinds of Reuse
Design “preserving”
Concretisation: filling in the “hotspots”
Refinement: refining the overall design
Extension: adding new behaviour
Design “breaching”
Abstraction: generalisation
Coarsening: performance optimisation
Cancellation: fixes

13. Remember: Inconsistent Methods
Set
Set (Optimized)
add(Element)
add(Element)
addAll(Set)
addAll(Set)
implementation level
Detection at
CountingSet
CountingSet
add(Element)
add(Element)
addAll(Set)
addAll(Set)
Not all elements are counted

14. Detecting Conflicts Coarsening Set Set (Optimized) add(Element)
addAll(Set) {-add}
Set
Set (Optimized)
add(Element)
add(Element)
addAll(Set) {add}
addAll(Set) {}
Concretisation
add
Concretisation
add
CountingSet
CountingSet
We can detect the inconsistent method problem with reuse contracts
what are the advantages ?
add(Element)
add(Element)
inconsistent method conflict
for add and addAll

15. Step 3: Formal Rules for Detecting Conflicts
…automated checking !
inconsistentMethods(Aexch,A,Mapp, I) :-
affectedMethods(Affected,Mapp), client(CAexch,Aexch),
findAllSet(inconsistency(N,M),
(member(N,CAexch), member(M,Affected),
spec(SpecAN,A,N), member(M,SpecAN),
transSpecClause(SpecAexchN,Aexch,N), not member(M,SpecAexchN)), I).

16. Reuse Contracts for Inheritance
Asset provider
Asset reuser
Set
Concretisation
add
add(Element)
addAll(Set) {add}
formally
non-coercively
formally
disciplined
rules for detecting conflicts

17. Reuse Contracts at Work ...
inter-object reuse contracts
Enhancing OOA/OOD methods
reuse notation
iterative design
Estimation/testing/metrics
Reuse repository
automatic signalling of possible conflicts on change
enhanced component interface descriptions
Re-engineering
extraction of reuse contracts
larger case-studies

18. Conclusion
Major technical challenges before reuse becomes standard practice:
proliferation of versions, iterative development
assessments, estimates
Reuse contract between asset provider and reuser
declare how an asset can be reused
declare how an asset is reused
formal rules for change propagation
Towards a reuse methodology …
… emphasising the co-operation between asset provider and asset reuser

19. Mailing List Subscription & More Information