1. Object-oriented Software Engineering with Reuse Contracts Koen De Hondt, Carine Lucas, Kim Mens, Tom Mens, Patrick Steyaert, Roel Wuyts Programming Technology Lab Vrije Universiteit Brussel

2. 2 Software Development Challenges 3Productivity »time to market »optimal use of experts 3Adaptability »everchanging market 3Complexity »ever-increasing customer demands: interoperability, distribution, WWW, GUI

3. 3 Research Goal Develop techniques, tools and methods for building complex software solutions that are highly, and efficiently customizable to the needs of different customers. The solution must give the customer the feeling of a custom- built system with the qualities of a standard product. It should not contain needless features, must be adapted to the customer’s work process, and must be integrated with existing hardware and software. Moreover it should offer the stability and the possibility for future upgrades that is typically associated with off-the-shelf products

4. 4 Designing for Reuse Reusable Assets easy maintainable robust under change well defined structure investment up front Legacy Code hard to maintain difficult to adapt no clear structure cost comes at the end

5. 5 Framework Approach Off-the-shelfFramework-basedProject-based Consolidate the domain knowledge acquired during previous projects in a framework so that it can be reused in future projects as to realize the product goal. The framework thus constitutes an ever-evolving representation, in terms of variations and commonalities, of our knowledge of the domain at a certain point in time.

6. 6 What can go wrong... 4 Ariane 4 »well tested software »proven correctly 4 Ariane 5 »reuse of pieces of Ariane 4 software »result: trivial error (floating point error), large consequences 4 What happened ? »changed flight specifications

7. 7 Research Approach Research Spin-off — Joint Projects Industry Formal underpinnings - reuse contracts Tools & Methods - UML - design patterns - “CASE” Processes - team structures - ADI -> ? Cases

8. 8 Reuse Contracts Component Reuser Component Provider 3rules for change propagation 3declares how a com- ponent is reused 3declares what assumptions are made about the component 3formally, disciplined 3declares how a com- ponent can be reused 3declares what assumptions can be made about the component 3formally, non-coercively

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

10. 10 Step 1: Documenting the Design documenting the specialisation interface Cashier single() group() Cashier single() group() {single} The specialisation interface declares the assumptions that can be made about a class and how it can be reused. implementation will invoke single Class Cashier method single = 0 method group (nr) = begin for i is 1 to nr do self.single end End Specialisation interface

11. 11 Changing Assumptions Assumption made by reuser (before change) Valid assumptions after composition or change Cashier.group [single] Assumes Accountant Actually gets Accountant Cashier.group [ ]

12. 12 Step 2: Declaring How a Class is Actually Reused documenting different kinds of reuse Refinement 3 single {+count} The reuse operators declares the assumptions that are made about a class and how it is reused. Cashier single group {single} Accountant count single {count} Cashier single group {single} Accountant count single {count}

13. 13 Different Kinds of Reuse 3Design “ preserving ” » Concretisation : filling in the “hotspots” » Extension : adding new behaviour » Refinement : refining the overall design » Factorisation : abstracting out aspects of the design 3Design “ breaching ” » Abstraction : generalisation » Cancellation : fixes » Coarsening : performance optimisation » Recombination : composing aspects of the design

14. 14 Inconsistent Methods count+1 not all sold tickets are counted Cashier single group Accountant single group count Cashier single group Accountant single group count new policy

15. 15 Estimating Impact of Changes count single {count} Coarsening  group {-single} Accountant Inconsistent Methods group needs to be overridden too Refinement 3 single {+count} Refinement 3 single {+count} Accountant count single {count} Cashier single group {single} Cashier single group { }

16. 16 Reuse contracts for inheritance Component reuser Component provider Cashier single() group() {single} Refinement ¦ single {…} Reuse contract between provider and reuser » declares how a component can be reused and is reused » formal rules for change propagation

17. 17 Conclusion 3 Reuse contracts support reuse and evolution » automated checking of impact on change or composition » effort estimation » component development ».... 3 Reuse contracts can also be applied to » multi-class components, frameworks,... » software architectures » state transition diagrams ».... Reuse Methodology

18. 18 More Information http://progwww.vub.ac.be/prog/pools/rcs/ my email: clucas@vub.ac.be