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

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

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

Evolution is Important ! Iterative development Changing requirements Repository Repository Evolution

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

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

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

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

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

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

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)

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

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

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

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).

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

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

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

Mailing List Subscription & More Information http://progwww.vub.ac.be/prog/pools/rcs/rc.html