A Methodology for the Documentation and Management of Reusable Assets

1. A Methodology for the Documentation and Management of Reusable Assets Carine Lucas Programming Technology Lab, Vrije Universiteit Brussel

2. Why Reuse ? • Rapid Application Development • Reduced Maintenance • Reduced Testing • Increased Adaptability • Avoid “Legacy Systems” • Build Assets • …

3. Problems with Reuse Object-oriented software engineering has failed to fulfil these high expectations concerning reuse ... ... because current day reuse techniques do not sufficiently support co-operation betweenasset providers and reusers.

4. Ad hoc versus Pre-planned Reuse • Ad hoc reuse • copy-and-edit • only marginal gains • Pre-planned reuse • overly restricting possible reuses and • adaptations Reuse should be disciplined, but not too coercive.

5. Black Box versus White Box Black box White box • safe • hard to adapt • easily adapted • risk of errors

6. Selective White Box Reuse selective white box reuse Reuse should be selective white box .

7. Reuse as-is versus by-adaptation • Application A • Asset A’ • Asset B • Repository • Asset A • Asset B Proliferation of versions • Application B • Asset B’ • Application C • Asset A’’ Reuse should be based on a formal understanding of change propagation.

8. Design for Reuse versus Iteration Asset Provider Asset Reuser • declares how an asset can be reused (formally) • declares how an asset is reused (formally) Reuse documentation should be two-way.

9. Summary: Problems with Reuse Reuse requires an explicit contract between asset provider and reuser that: • allows disciplined, but non-coercive reuse • allowsselective white box reuse • offers a formal basis for change propagation Reuse Contracts Our approach:

10. Case Study: Reuse of Abstract Classes through Inheritance Abstract A Abstract A’ parent class exchange ? SubClass B SubClass B’ SubClass C SubClass C’ ? SubClass D

11. Possible Conflicts • name & annotation conflicts • incomplete implementation • method capture • inconsistent methods Abstract A Abstract A’ parent class exchange SubClass B SubClass B’

12. Inconsistent Methods Set OptimizedSet add(Element) add(Element) addAll(Set) addAll(Set) CountingSet CountingSet count+1 count+1 add(Element) add(Element) addAll(Set) addAll(Set) Not all elementsare counted

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

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

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

16. Detecting Conflicts • Coarsening • addAll(Set) {-add} Set OptimizedSet add(Element) add(Element) addAll(Set) {add} addAll(Set) {} • Concretisation • add • Concretisation • add CountingSet CountingSet add(Element) add(Element) inconsistent method conflict for add and addAll

17. Step 3: Rules for Detecting Conflicts Formal rules … …automated checking ! inconsistentMethods(Aexch,A,Mapp,IntroducedIncons) :- 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)), IntroducedIncons).

18. Our conjecture (1) Reuse contracts can be developed for other reuse mechanisms through the same methodology: • documenting the design of an asset • identifying a set of reuse operators • setting up rules for change propagation Moreover, we are searching for reuse operators that are as general as possible !

19. Proving Our Conjecture Elaborating along 3 axes: • granularity of the assets: classes, inter-class components, design patterns, ... • phases in the software life-cycle: OOA&D, implementation, refactoring, ... •formal detail: ordering on message sends, type information, ...

20. Our Conjecture (2) Reuse contracts that comply to our criteria: • two-way communication between asset developers and reusers • disciplined, but non-coercive reuse • selective white box reuse • a formal basis for change propagation actually increase reusability. This will be proven through a number of case studies

21. Where are we now ? • OOPSLA paper: abstract classes and inheritance • preliminary results on inter-class components and design notation • older work on typing • some feedback through Smalltalk extractor and industrial course

22. Work to do • finish work on inter-class components • integrate in design notation • find and carry out GOOD CASES !!! • include type information and experiment with Java • write it all down

23. Comparison with other approaches Lamping: Specialisation Interfaces [OOPSLA93] Holland: Contracts [OOPSLA90] [ECOOP9?] “While the Law of Demeter removes excessive behavioural dependencies, contracts focus on the important ones” Minimisation of dependencies is a general software engineering principle. Lamping and Holland focus on documenting the important dependencies that still exist. We focus on how they evolve.