Managing the evolution of reusable components

1
Reuse Contracts

• Managing the evolution of reusable components

Dr. Tom Mens Programming Technology Lab Vrije
Universiteit Brussel Course OOSE.RC EMOOSE
1999-2000
2
Goals

• Explain relation between reuse and evolution
• Discuss technical problems that occur when
  reusable components evolve
• Explain the reuse contract technique for
  dealing with evolution and reuse of software
  components
• Discuss how to incorporate this technique in
  tools that support reuse and evolution

3
Software Evolution...

• is unavoidable
• is crucial to reuse
• is needed to reverse the effects of software
  aging

4
Evolution is Unavoidable

• There are many reasons why components evolve
• new requirements
• new technology
• software
• hardware
• new insights in the domain
• iterative development
• ...

5
Evolution is Unavoidable

• ...
• maintenance
• use of components beyond their original goals
• reuse of components in other software systems
• Heisenberg1 principle of software development
• 1 requirements start changing from the moment you
  start building or using a software system

6
Evolution is Crucial to Reuse

• Reusable components have a long life span
• Requirements might be incorrect or incomplete and
  evolve themselves
• It is inconceivable to anticipate all possible
  reuses
• Reuse can only be achieved after numerous reuses
  and adaptations

7
Evolution is Crucial to Reuse
case knowledge
8
Software Aging
Programs, like people, get old. We cant prevent
aging, but we can understand its causes, take
steps to limit its effects, temporarily reverse
some of the damage it has caused, and prepare for
the day when the software is no longer viable.
Parnas94
We need to learn how to reverse the effects of
aging!
9
Reasons Why Software Ages

• lack of movement
• maintenance
• ignorant surgery and architectural erosion
• inflexibility from the start
• inadequate documentation
• deadline pressure
• ...

The difference between legacy systems and
reusable software is the ability to change !
10
Goals

• Explain relation between reuse and evolution
• Discuss technical problems that occur when
  reusable components evolve
• Explain the reuse contract technique for
  dealing with evolution and reuse of software
  components
• Discuss how to incorporate this technique in
  tools that support reuse and evolution

11
Evolution Must be Managed

• Version proliferation
• Lack of domain insight
• Improper reuse and composition
• Architectural drift
• Overfeaturing
• Ripple effect (butterfly effect)
• Traceability problems

12
Issue Impact Analysis
13
Some Typical Evolution Conflicts

• (component class)
• Signature collision two developers introduce or
  remove the same method signature
• Method body conflict two developers change the
  body of the same method
• Dangling reference one developer refers to a
  method while the other one removes it
• Method capture one developer changes a method
  under the assumption that the method is not
  invoked, while the other developer adds the
  method invocation
• Inconsistent methods one developer changes a
  method under the assumption that the method is
  invoked, while the other developer removes the
  method invocation

14
Goals

• Explain relation between reuse and evolution
• Discuss some technical problems that can occur
  when reusable components evolve
• Explain the reuse contract technique for
  dealing with evolution and reuse of software
  components
• Discuss how to incorporate this technique in
  tools that support reuse and evolution

15
Current software modelsare too static

• A system is a set of communicating parts or
  components that collaborate to realise a certain
  behaviour
• A part or component is understood to be a systems
  building block that is defined by its external
  interface (like an ADT).
• A software architecture is a specification of a
  set of components and a communication pattern or
  protocol among them to achieve the behaviour.

Software models should take evolution into
account!
16
Reuse Contracts
17
Reuse Contracts

• Technique for documenting reuse/evolution of
• single (abstract) classes, collaborating set of
  classes, applications, frameworks, software
  architectures, ...
• Improve reuse at the design level
• highlight reuse information at the design level
• Manage change/evolution
• make estimation of the impact of a change to a
  class/framework more easy
• Enhance existing OO methodologies

18
General Idea
cross-domain components
domain components
application components
19
Case Study (1)Evolution in Class
Hierarchies
20
Example
evolution
size item.size
size item.size
SizedFolder
size
add
21
Changing Assumptions
Reuse imposes obligations!
22
Specialisation Interface
The specialisation interface declares the
assumptions that can be made about a class and
how it can be reused.
documenting the specialisation interface
23
Contract Types

• Document the intentions of reusers by
• telling the component provider how a component is
  reused
• documenting good (re-)uses but also hacks
• Impose restrictions
• extenders may only add new services
• refiners may not add new services
• concretisers may only fill in the hot spots

24
Kinds of Contract Types

• Obligation full-filling
• Concretisation filling in the hot spots
• Obligation strengthening
• Refinement refining the overall model
• Extension adding new services
• Obligation relaxing
• Coarsening e.g., performance optimisation
• Cancellation removing needless features

25
Documenting Reusewith Contract Types
documenting different kinds of reuse
26
Documenting Reusewith Contract Types
documenting kind of reuse
27
Estimating theImpact of Changes
Coarsening addMany - add
Refinement add size
SizedFolder
size
add size
Effort estimation addMany needs to be overridden
too
28
Impact Analysis
extension refinement coarsening
extension
refinement
coarsening
interface conflicts
no conflicts
no conflicts
no conflicts
no conflicts
method capture, unanticipated recursion
method capture, inconsistent methods
no conflicts
method capture, inconsistent methods
no conflicts
inconsistent methods
29
Summary

• rules for impact analysis (conflict detection)

30
Kinds of conflicts

• syntactic conflicts
• lead to an ill-formed result
• semantic conflicts
• lead to a result that contains unexpected
  behaviour / unexpected side-effects / ...
• structural conflicts
• occur after restructuring or refactoring

31
Syntactic Conflicts

• Can typically be checked by a compiler
• Examples
• Double occurences
• Accidentally adding the same method in a base
  class and one of its subclasses
• (can also occur during renaming)
• Dangling method call
• Adding a call to a method that is removed by base
  class exchange

32
Example Syntactic Conflict
Cancellation add
DesktopFolder
xpos, ypos contents move add
Extension addMany add
Dangling method call!
33
Exercise Syntactic Conflicts

• Give a few examples of syntactic conflicts that
  have to do with self sends and/or super sends.

34
Solution Syntactic Conflicts
Coarsening m
Refinement m super
Dangling super call!
35
Semantic Conflicts

• Cannot be checked by a compiler
• Examples
• inconsistent methods
• see earlier example (refinement vs coarsening)
• method capture
• making a call to a method whose implementation is
  being modified
• unanticipated recursion
• adding two method calls in the opposite direction

36
Exercise Semantic conflicts

• Give a few examples of more complex semantic
  conflicts that have to do with self sends or
  super sends?

37
Solution a Semantic Conflicts
Refinement m self.n
Coarsening n - body
Calling m in B after base class exchange gives a
run-time error because it indirectly calls the
unimplemented method n from B!
38
Solution b Semantic Conflicts
Calling p in C after base class exchange gives
rise to an infinite recursion (due to
late-binding of self)!
Refinement p self.m
Calling
39
Structural Conflicts

• Occur when the framework is being restructured
• Examples
• introducing an intermediate abstract class
• splitting up the behaviour of one class in two
  new (associated) classes
• ...

40
Example Structural Conflict
restructure the framework by introducing an
intermediate class Agency
Restructuring conflict. In the merge, Safe should
not be handled by Bank, but by Agency.
extend the framework by introducing a new class
Safe
41
Example Structural Conflict
restructure the framework by introducing
intermediate classes Person and MoralPerson
extend the framework by introducing new classes
TransformedMale and TransformedFemale
Restructuring conflict. When these two parallel
modifications are merged, should TransformedMale
and TransformedFemale be put under Person,
Identity or MoralPerson? What with other classes?
42
Exercise Structural Conflict

• Try to find a general characterisation of a
  restructuring transformation based on the two
  examples.
• Try to find a general characterisation of a
  restructuring conflict using the above
  characterisation.

43
Solution a Restructure Transfo
Restructure(OldNode, Part1,Part2,PartN)
DepNode2
DepNode1
DepNode3
Part1
Part2
PartN

• Step 1 replace OldNode by a number of Part-nodes
• Step 2 redirect all dependencies to or from
  OldNode to all of the Part-nodes

44
Solution b Restructure Conflict
Restructure(OldNode, Part1,Part2,PartN)
Refinement to or from OldNode
Restructure Conflict
45
Case Study Bank Example

• Try to express the design of a Bank-framework,
  find some interesting evolutions and
  customisations of the framework, and try to find
  some interesting evolution conflicts, at class
  level as well as method level.

46
Possible Bank-FW evolutions
47
Base Contract
CreditAccount
balance
G
creditLimit
Log
G
I
withdraw(value)
S
print(action,value)
deposit(value)
getInfo
validate(value)
I
G
All inheritors must satisfy this contract.
Contract makes certain assumptions explicit, such
as

• withdraw and deposit must always log their
  actions
• withdraw and deposit make changes to balance
• withdraw always invokes validate

48
Base Contract(alternative notation)
CreditAccount
balance
creditLimit
withdraw(value) GET balance INVOKE validate
SET balance CALL Log.print
deposit(value) SET balance CALL Log.print
getInfoGET balance
validate(value) GET balance GET withdrawLimit
49
Evolved Base Contract(base class exchange)
CreditAccount.2
balance
creditLimit
withdraw(value) GET balance GET creditLimit
INVOKE validate SET balance CALL Log.print
deposit(value) SET balance CALL Log.print
getInfoGET balance
validate(value) GET balance GET creditLimit
Inline behaviour of validate in withdraw for
efficiency reasons (but do not remove
validate) Can cause problems in inheritors that
rely on the following assumptionof the original
contract which is not valid anymore - withdraw
always invokes validate
50
Inherited Contract
CreditAccount
balance
creditLimit
withdraw(value) GET balance INVOKE validate
SET balance CALL Log.print
deposit(value) SET balance CALL Log.print
getInfoGET balance
validate(value) GET balance GET creditLimit
ATMAccount
daylyAmount
atmLimit
getInfoINVOKE super GET daylyAmount
validate(value) INVOKE super GET daylyAmount
GET atmLimit
ATMAccount complies to all assumptions of
CreditAccount because of super calls
51
Evolution Conflict
CreditAccount
CreditAccount.2
inline validate in withdraw
override validate
ATMAccount
ATMAccount
Breach of assumption that - withdraw always
invokes validate
52
Task Parallel evolution of Account hierarchy

• Account contains the basic functionality that is
  common to all accounts (abstract superclass)
• A CreditAccount can have a negative balance up to
  a certain creditLimit.
• Money can be deposited on a SavingsAccount by
  everyone, but withdrawing is only possible by
  transferring the money to the associated
  DepositAccount.

DepositAccount
SavingsAccount
53
Some possible evolutions

1. A TransferAccount is a special kind of account
   that automatically transfers money to
   SavingsAccount if a certain upper limit is
   reached, and leaves a preset amount on the
   original account.
2. Allow to remove money from the account by drawing
   a cheque, as long as the cheque has been approved
   by the bank
3. Security money can only be withdrawn after
   having provided a password.
4. Phone banking account can be accessed by phone
   via a special interface, and provided that the
   correct pin code is provided
5. Internet banking account can be accessed by
   internet, after having provided a password.
   Typically, internet banking offers more features
   than phone banking.
6. Add logging information to accounts
7. Account warns user during withdraw when balance
   is going to be negative
8. Add an extra transfer operation to transfer money
   from account to other accounts
9. Add behaviour for calculating the interest rate.
   SavingsAccount has higher interest than
   DepositAccount. They also have a fidelityBonus
   and growthBonus calculated on a annual basis. If
   balance is negative on a creditAccount, a high
   negative intrest is charged.
10. Add behaviour for calculating the cost charged by
    the bank for managing the account. Some accounts
    have a default cost per year, other accounts
    require a small fee for each transaction being
    made, but do not require fees for electronic
    transactions (phone banking and internet banking)
11. Accounts specifically for persons below 18 years,
    with higher intrest rates and other bonusses.