Object-oriented Software Engineering with Reuse

ContractsKoen De Hondt,Carine Lucas,

Kim Mens,Tom Mens,

Patrick Steyaert,Roel Wuyts

Programming Technology LabVrije Universiteit Brussel

2

Software Development Challenges

Productivity» time to market» optimal use of experts

Adaptability» everchanging market

Complexity» ever-increasing customer demands:

interoperability, distribution, WWW, GUI

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

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

Framework Approach

Off-the-shelf Framework-based Project-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

What can go wrong ... Ariane 4

» well tested software

» proven correctly

Ariane 5

» reuse of pieces of Ariane 4 software

» result: trivial error (floating point error), large consequences

What happened ?» changed flight specifications

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

Reuse ContractsComponent

ReuserComponent

Provider

rules for change propagation

declares how a com-ponent is reused

declares what assumptions are made about the component

formally, disciplined

declares how a com-ponent can be reused

declares what assumptions can be made about the component

formally, non-coercively

9

Case Study: Reuse of Classes through Inheritance

Class A

SubClass B

SubClass C

Class A’

SubClass B’

SubClass C’

SubClass D

parent classexchange ?

?

10

Step 1: Documenting the Design

documenting thespecialisation 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 Cashiermethod single = 0method group (nr) = begin for i is 1 to nr do

self.single end

End

Specialisation

interface

11

Changing AssumptionsAssumption made by reuser (before change)

Valid assumptions after composition or change

Cashier.group [single]Assumes

Accountant

Actually gets

Accountant

Cashier.group [ ]

12

Step 2: Declaring How a Class is Actually Reused

documenting differentkinds of reuse Refinement

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

Different Kinds of Reuse Design “preserving”

» Concretisation: filling in the “hotspots”» Extension: adding new behaviour» Refinement: refining the overall design» Factorisation: abstracting out aspects of the design

Design “breaching”» Abstraction: generalisation» Cancellation: fixes» Coarsening: performance optimisation» Recombination: composing aspects of the design

14

Inconsistent Methods

count+1 count+1

not all sold ticketsare counted

Cashier

single

group

Accountant

singlegroup

count

Cashier

single

group

Accountant

singlegroup

count

new policy

15

Estimating Impact of Changes

countsingle {count}

Coarsening group {-single}

Accountant

Inconsistent Methodsgroup needs to beoverridden too

Refinement single {+count}

Refinement single {+count}

Accountant

countsingle {count}

Cashier

singlegroup {single}

Cashier

singlegroup { }

16

Reuse contracts for inheritance

Componentreuser

Componentprovider

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

Conclusion Reuse contracts support reuse and evolution

» automated checking of impact on change or composition» effort estimation » component development» ....

Reuse contracts can also be applied to» multi-class components, frameworks, ...» software architectures» state transition diagrams» ....

Reuse Methodology

18

More Information

http://progwww.vub.ac.be/prog/pools/rcs/

my email: clucas@vub.ac.be