February 2000Programming Technology Lab, Vrije Universiteit Brussel Reuse Contracts Managing the evolution of reusable components Dr. Tom Mens Programming Technology Lab Vrije Universiteit Brussel Course OOSE.RC EMOOSE

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel Software Evolution... … is unavoidable … is crucial to reuse … is needed to reverse the effects of software aging

February 2000Programming Technology Lab, Vrije Universiteit Brussel Evolution is Unavoidable There are many reasons why components evolve: new requirements new technology –software –hardware new insights in the domain iterative development...

February 2000Programming Technology Lab, Vrije Universiteit Brussel Evolution is Unavoidable... maintenance use of components beyond their original goals reuse of components in other software systems Heisenberg 1 principle of software development … 1 requirements start changing from the moment you start building or using a software system

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel Evolution is Crucial to Reuse change propagation Iterative Learning Process case knowledge application components domain components cross-domain components

February 2000Programming Technology Lab, Vrije Universiteit Brussel Software Aging Programs, like people, get old. We can’t 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!

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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 !

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel Evolution Must be Managed Version proliferation Lack of domain insight Improper reuse and composition Architectural drift Overfeaturing Ripple effect (butterfly effect) Traceability problems

February 2000Programming Technology Lab, Vrije Universiteit Brussel Ripple effect! Change propagation Modifying a component Issue: Impact Analysis

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel Current software models are 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!

February 2000Programming Technology Lab, Vrije Universiteit Brussel Reuse Contracts

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel cross-domain components domain components application components General Idea provider reuser contract provider reuser contract

February 2000Programming Technology Lab, Vrije Universiteit Brussel Provider (Re-) users Changing a method Case Study (1): Evolution in Class Hierarchies

February 2000Programming Technology Lab, Vrije Universiteit Brussel DesktopFolder xpos, ypos contents move add addMany Example evolution DesktopFolder xpos, ypos contents move add addMany SizedFolder add size size + item.size SizedFolder add size size + item.size size is not updated when adding many items

February 2000Programming Technology Lab, Vrije Universiteit Brussel Changing Assumptions Reuse imposes obligations! add addMany {invokes add} Assumption made by reuser (before evolution) SizedFolder Assumes add addMany {} What can be assumed (after evolution) SizedFolder Actually gets

February 2000Programming Technology Lab, Vrije Universiteit Brussel xpos, ypos contents move add addMany {add} DesktopFolder Specialisation Interface The specialisation interface declares the assumptions that can be made about a class and how it can be reused. DesktopFolder xpos, ypos contents move add addMany documenting the specialisation interface implementation will invoke add Class DesktopFolder... method add (el) =... method addMany (set) = begin for each el in set do self.add(el) end

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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”

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel DesktopFolder xpos, ypos contents move add addMany {add} SizedFolder add {size:} size Documenting Reuse with Contract Types documenting different kinds of reuse DesktopFolder xpos, ypos contents move add addMany {add} SizedFolder add {size:} size Refinement add {+ size:}

February 2000Programming Technology Lab, Vrije Universiteit Brussel Documenting Reuse with Contract Types DesktopFolder xpos, ypos contents move add addMany {add} DesktopFolder xpos, ypos contents move add addMany evolution DesktopFolder xpos, ypos contents move add addMany {add} DesktopFolder xpos, ypos contents move add addMany Coarsening addMany {- add} documenting kind of reuse

February 2000Programming Technology Lab, Vrije Universiteit Brussel Estimating the Impact of Changes Coarsening addMany {- add} DesktopFolder xpos, ypos contents move add addMany {add} SizedFolder add {size:} size Refinement add {+ size:} DesktopFolder xpos, ypos contents move add addMany {} SizedFolder add {size:} size Refinement add {+ size:} Effort estimation : addMany needs to be overridden too

February 2000Programming Technology Lab, Vrije Universiteit Brussel extension refinement coarsening extensionrefinementcoarsening no conflicts inconsistent methods interface conflicts method capture, unanticipated recursion method capture, inconsistent methods no conflicts method capture, inconsistent methods Impact Analysis

February 2000Programming Technology Lab, Vrije Universiteit Brussel 3rules for impact analysis (conflict detection) Reuser 3declares how a com- ponent is reused 3declares what assumptions are made about the component 3formally, disciplined Provider 3declares how a com- ponent can be reused; 3declares what assumptions can be made about the software; 3formally, non- coercively Summary

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel Example: Syntactic Conflict Cancellation add DesktopFolder xpos, ypos contents move add Extension addMany {+ add} DesktopFolder xpos, ypos contents move Dangling method call! ExtDesktop addMany {add}

February 2000Programming Technology Lab, Vrije Universiteit Brussel Exercise: Syntactic Conflicts Give a few examples of syntactic conflicts that have to do with self sends and/or super sends.

February 2000Programming Technology Lab, Vrije Universiteit Brussel Solution: Syntactic Conflicts Coarsening m A mnmn Refinement m {+ super} Dangling super call! B m{super} A n

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel Exercise: Semantic conflicts Give a few examples of more complex semantic conflicts that have to do with self sends or super sends?

February 2000Programming Technology Lab, Vrije Universiteit Brussel Solution a: Semantic Conflicts Refinement m {+ self.n} A m n {… body …} 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! B n { shouldNotImplement } A m {self.n} n {… body …}

February 2000Programming Technology Lab, Vrije Universiteit Brussel Solution b: Semantic Conflicts Refinement p {+ self.m} A m {self.n} n Calling B n {self.p} p B n {self.p} m {self.m} C p {super} Calling p in C after base class exchange gives rise to an infinite recursion (due to late- binding of self)!

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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 –...

February 2000Programming Technology Lab, Vrije Universiteit Brussel Restructuring conflict. In the merge, Safe should not be handled by Bank, but by Agency. Example: Structural Conflict restructure the framework by introducing an intermediate class Agency extend the framework by introducing a new class Safe Bank Account isHandledBy Loan isHandledBy Company Agency Account isHandledBy Loan isHandledBy Bank Company represents Bank Account isHandledBy Loan isHandledBy Company Safe isHandledBy Agency Safe isHandledBy Account isHandledBy Bank Company represents Loan isHandledBy

February 2000Programming Technology Lab, Vrije Universiteit Brussel Identity MaleFemaleCompany Transformed Male Transformed Female Identity MaleFemaleCompany Restructuring conflict. When these two parallel modifications are merged, should TransformedMale and TransformedFemale be put under Person, Identity or MoralPerson? What with other classes? Identity MaleFemaleCompany PersonMoralPerson restructure the framework by introducing intermediate classes Person and MoralPerson extend the framework by introducing new classes TransformedMale and TransformedFemale Example: Structural Conflict

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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.

February 2000Programming Technology Lab, Vrije Universiteit Brussel OldNode DepNode2 DepNode3 DepNode1 DepNode2 DepNode3 DepNode1 Part1Part2 PartN Restructure (OldNode, [Part1,Part2,…PartN]) Solution a: Restructure Transfo 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

February 2000Programming Technology Lab, Vrije Universiteit Brussel Restructure (OldNode, [Part1,Part2,…PartN]) Solution b: Restructure Conflict Refinement to or from OldNode Restructure Conflict

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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.

February 2000Programming Technology Lab, Vrije Universiteit Brussel Company Bank Company BankAccount Company BankAccount Safe ATM owns Company BankAgencySafeATM Account isHandledBy owns Possible Bank-FW evolutions

February 2000Programming Technology Lab, Vrije Universiteit Brussel CreditAccount balance deposit(value) withdraw(value) creditLimitLog print(action,value) getInfo I S G I S 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 validate(value) G G Base Contract

February 2000Programming Technology Lab, Vrije Universiteit Brussel CreditAccount balance deposit(value) {S ET balance; CALL Log.print} withdraw(value) { GET balance; INVOKE validate; SET balance; CALL Log.print} creditLimit getInfo { GET balance} validate(value) { GET balance; GET withdrawLimit} Base Contract (alternative notation)

February 2000Programming Technology Lab, Vrije Universiteit Brussel Inline behaviour of validate in withdraw for efficiency reasons (but do not remove validate ) Can cause problems in inheritors that rely on the following assumption of the original contract which is not valid anymore - withdraw always invokes validate CreditAccount.2 balance deposit(value) {S ET balance; CALL Log.print} withdraw(value) { GET balance; GET creditLimit; INVOKE validate; SET balance; CALL Log.print} creditLimit getInfo { GET balance} validate(value) { GET balance; GET creditLimit} Evolved Base Contract (base class exchange)

February 2000Programming Technology Lab, Vrije Universiteit Brussel CreditAccount balance deposit(value) {S ET balance; CALL Log.print} withdraw(value) { GET balance; INVOKE validate; SET balance; CALL Log.print} creditLimit getInfo { GET balance} validate(value) { GET balance; GET creditLimit} ATMAccount daylyAmount atmLimit getInfo { INVOKE super; GET daylyAmount} validate(value) { INVOKE super; GET daylyAmount; GET atmLimit} ATMAccount complies to all assumptions of CreditAccount because of super calls Inherited Contract

February 2000Programming Technology Lab, Vrije Universiteit Brussel CreditAccount ATMAccount CreditAccount.2 inline validate in withdraw override validate Breach of assumption that - withdraw always invokes validate ATMAccount Evolution Conflict

February 2000Programming Technology Lab, Vrije Universiteit Brussel DepositAccountSavingsAccount CreditAccount withdraw(value) creditLimit getInfo validate(value) Account balance deposit(value) withdraw(value) getInfo 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. Task: Parallel evolution of Account hierarchy

February 2000Programming Technology Lab, Vrije Universiteit Brussel 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. Some possible evolutions