1. August 1997 Carine Lucas 1 Documenting Reuse and Evolution with Reuse Contracts Carine Lucas August 1997

2. August 1997 Carine Lucas 2 » Motivation » Problems with Reuse » Basic principles » Reuse Contracts » Step 1: Documenting Dependencies » Step 2: Documenting Reuse » Step 3: Rules for Change Propagation » Validation » Conclusion Overview

3. August 1997 Carine Lucas 3 A New Approach » A new approach in establishing a notation and methodology for disciplined reuse. » Process models, planning reuse, disciplined reuse, domain analysis,... » Frameworks, design patterns, repositories,... » No established reuse notation as UML in OOA/D. » A lot of technical problems still need to be addressed: » testing reusable components, measuring reuse, design for reuse.

4. August 1997 Carine Lucas 4 Research Approach Research areas: » analysis of problems; » vocabulary and notation for disciplined reuse; » formal underpinnings; » tools and environments; » experimental validation; » process models.

5. August 1997 Carine Lucas 5 Basic Premises » A practical model » automatically processable, good basis for tools. » that is generally applicable » can be used on different models throughout the software life cycle. » and focusses on evolution.

6. August 1997 Carine Lucas 6 Evolution at the Heart of 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. August 1997 Carine Lucas 7 Structure and Operational Behaviour Structure of a system = a description of how different parts in a system are arranged Declarative behaviour of a system = a description of what a system does Operational behaviour of a system = a description of how this behaviour is achieved

8. August 1997 Carine Lucas 8 Reuse Documentation » Description of operational behaviour following recent work: » specialisation interfaces (Lamping), » interaction contracts (Holland), » architecture description languages (Garlan&Shaw), » design patterns (Gamma&al.), »... Interfaces documenting structural dependencies.

9. August 1997 Carine Lucas 9 Reuse Documentation (2) » Black boxes are robust to change, but hard to adapt. » White boxes are more fragile to change, but also more flexible. » Deciding what information is crucial to reusers is hard. Layered, selective white-box interfaces.

10. August 1997 Carine Lucas 10 Impact Analysis Changing an operation m m self m x [ a.m ] self m y [ b.x ]

11. August 1997 Carine Lucas 11 Example outputserver accept [handle] isDestFor output send packet handle [ if isDestFor then output else send] gateway accept [handle] isDestFor output [passOn] send visitorpacket handle [action send ] Inconsistent Methods visitor packets will not get past gateways

12. August 1997 Carine Lucas 12 Changing Assumptions Support for change propagation based on documenting assumptions. gateway assumes handle [if isDestFor then output] gateway actually gets handle [ send action ]

13. August 1997 Carine Lucas 13 Summary: Criteria for Reuse » Reuse requires an explicit contract between component provider and reuser that: » allows disciplined, but non-coercive reuse; » provides a layered, selective white-box interface documenting structural dependencies; » offers a formal basis for change propagation. Balance between flexibility and disciplined reuse.

14. August 1997 Carine Lucas 14 » Motivation » Problems with Reuse » Basic principles » Reuse Contracts » Step 1: Documenting Dependencies » Step 2: Documenting Reuse » Step 3: Rules for Change Propagation » Validation » Conclusion Overview

15. August 1997 Carine Lucas 15 Reuse Contracts Component Reuser Component 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

16. August 1997 Carine Lucas 16 Step 1: Documenting the Design a participant an operation the operation’s specialisation clause ATM checkCard Consortium verifyAccount checkCard {verifyAccount} theATMtheCons an acquaintance relationship an acquaintance name Start with a basic model of interacting components.

17. August 1997 Carine Lucas 17 Formal Documentation ATMContract = {(ATM, {theCons.Consortium}, {(checkCard, {theCons.verifyAccount}) } ), (Consortium, {theATM. ATM}, {(verifyAccount, {}) } ) } participant name specialisation clause acquaintance clause a participant Reuse contracts need to be well-formed.

18. August 1997 Carine Lucas 18 Step 2: Documenting How a Component is Reused Operator Name Participant Extension Participant Cancellation Participant Refinement Participant Coarsening Context Extension Context Cancellation Context Refinement Context Coarsening Meaning adding new operations removing operations adding new operation invocations removing operation invocations adding new participants removing participants adding new acquaintance relationships removing acquaintance relationships These operators can model all possible adaptations of a reuse contract.

19. August 1997 Carine Lucas 19 Example: Participant Extension ATM checkCard Consortium verifyAccount checkCard {verifyAccount} theATMtheCons ATM checkCard trActRequest Consortium verifyAccount processTrAct checkCard {verifyAccount} trActRequest{processTrAct} theATMtheCons { (ATM, { (trActRequest, {theCons.processTrAct}) }), (Consortium. { (processTrAct, {}) }) } Participant Extension Modifier Participant Extension Operators are defined by modifier, applicability and operator definitions and preserve well-formedness.

20. August 1997 Carine Lucas 20 Step 3: Estimating Impact of Changes Participant Refinement output {+gate.passOn} OutputServer accept isDestFor output send Packet handle Gateway (OutputServer) accept {packet.handle} isDestFor output {gate.passOn} send Visitorpacket (Packet) handle {self.action, server.send} Inconsistent Methods visitor packets will not get past gateways serverpacket accept {handle} handle {isDestFor, output, send} Participant Coarsening handle {-server.output}

21. August 1997 Carine Lucas 21 Rules for Conflict Detection Two operations m and n become inconsistent when » M 1 represents a participant coarsening of m on p dereferencing n on q; » M 2 represents a participant refinement or participant coarsening of m on p; These rules can be checked automatically. R base Base (reuse) Contract M2M2 M2M2 M1M1 R2R2 R1R1 Resulting (reuse) contract R result ?

22. August 1997 Carine Lucas 22 Different Kinds of Conflicts » Interface Conflicts » Dangling Reference Conflicts » Conflicts Concerning the Calling Structure » Other Conflicts There is a trade-off between including more information to detect more conflicts and applicability to more reuse contracts.

23. August 1997 Carine Lucas 23 Different Kinds of Rules Conflicts can be detected » By comparing modifiers » most conflicts handled here » Using the applicability rules » also requires base contract » Needing the base contract » e.g. unanticipated recursion » transitive closures

24. August 1997 Carine Lucas 24 Chains of Operators » No extra conflicts. » Some conflicts can be annihilated in chains. » Chains can introduce extra transitive closure conflicts. R base R’ M’ R1R1 M1M1 R2R2 M2M2... RnRn MnMn R’ M’ ?

25. August 1997 Carine Lucas 25 Combinations of Operators ATM checkCard trActRequest Consortium verifyAccount checkCard {verifyAccount} theATMtheCons ATM checkCard trActRequest Consortium verifyAccount processTrAct checkCard {verifyAccount} trActRequest{processTrAct} theATMtheCons Extending Refinement » Combined operators are defined by defining combined modifiers. » They automatically preserve well-formedness. » Some conflicts can be neglected due to meaning of the operator.

26. August 1997 Carine Lucas 26 Criteria for Reuse Revisited » Reuse contracts declare how a component can be reused and is reused. » They thus document the valid and relied on assumptions, enabling assessing change propagation. » Reuse contracts provide an explicit contract between component provider and reuser that: » allows disciplined, but non-coercive reuse; » provides a layered, selective white-box interface documenting structural dependencies; » offers a formal basis for change propagation.

27. August 1997 Carine Lucas 27 » Motivation » Problems with Reuse » Basic principles » Reuse Contracts » Step 1: Documenting Dependencies » Step 2: Documenting Reuse » Step 3: Rules for Change Propagation » Validation » Conclusion Overview

28. August 1997 Carine Lucas 28 UML: Static Structure Diagrams AirTime resolve: noSpace ATSPlanner deleteBlock: planAirtime: BlockDistribution delete placeSpot: {freePos} freePos at planner distr planner distr planAirtime:{resolve:} resolve:{placeSpot:} placeSpot:{noSpace} deleteBlock: {delete}

29. August 1997 Carine Lucas 29 Steps in Integration » Map items from reuse contracts to features in application area. » Add additional features from application area; » e.g. abstract and concrete methods. » also self and super sends. » Adapt existing model to cope with added features. » Introduce additional operators to cope with added features. » e.g. concretisation and abstraction. » specialisation. » Investigate how new operators influence conflicts » method capture after concretisation. » specialisation vs. participant refinement.

30. August 1997 Carine Lucas 30 Case Study: Air Time Sales » In co-operation with industrial partner. » Development of framework for air time sales. » Should be incorporated with large broadcast planning framework. » Design of two ATS strategies, plus combination; » Abstract generalisations; » Add functionalities and optimise. » Will be further elaborated on.

31. August 1997 Carine Lucas 31 Documenting Reuse AirTime resolve: {distr.placeSpot:} noSpace GRP_AirTime resolve: {distr.placeSpot:, planner.distrWithGRP } reschedule: noSpace BlockSpotSpace resolve: { distr.placeSpot: } validSol:in: { checkSol } checkSol noSpace Concretisation resolve: Extension validSol:in: {checkSol} checkSol Layered Concretisation resolve: {+planner.distrWithGRP:} Extension reschedule

32. August 1997 Carine Lucas 32 Change Propagation Rules participant extension participant refinement participant coarsening participant extension accidental method capture, unantici- pated recursion participant refinement no conflicts regular method capture, unantici- pated recursion participant coarsening no conflicts regular method capture, inconsistent methods inconsistent methods

33. August 1997 Carine Lucas 33 Change Propagation Original Air Time BlockSpotSpace Refinement of validSol:in: with checkSol GRP_Airtime Layered concretisation of resolve: and Extension by reschedule New Version Refinement of placeSpot: on Distribution with validSol:in: on at regular method capture no conflicts The tables signal problems, thus also suggesting solutions or alternative changes.

34. August 1997 Carine Lucas 34 Experiments (1) » Evolution and Incremental Development » Conflict Detection » Effort Estimation » Assistance in Refactoring » Documentation » Extraction » Assistance of Software Engineer » Layering of Design and of Class Libraries » Core vs. Peripheral Methods

35. August 1997 Carine Lucas 35 Extraction

36. August 1997 Carine Lucas 36 Experiments (2) » Enforcing Design » Compliance Checking » Design Patterns » Design Assessment » Well-formed Reuse Contracts » Assessments based on Operators » Existing Design Rules

37. August 1997 Carine Lucas 37 Compliance Checking public interface ComponentRC { public Dimension preferredSize() {}; public void layout() {};... } public interface ContainerExtRC expands ComponentRC { public void getLayout() {} } public interface ContainerRC refines ContainerExtRC { public void layout() {+ getLayout} } public class Component implements ComponentRC {... } public class Container extends Component implements ContainerRC {... }

38. August 1997 Carine Lucas 38 Design Assessment The Stream hierarchy is awkward with respect to the method next. 1 2 3

39. August 1997 Carine Lucas 39 Future Work » Formal Model » More generic operators, annihilation of conflicts,... » More information: state, order, branches,... » Scalability of the Approach » Apply this model to other formalisms, e.g., IDL, ADLs,... » Create other models for, e.g., state diagrams, use cases,... » Tool Support » More Elaborate Case Studies » Document and evaluate existing systems » Monitor and manage evolution of system » Software Process Studies

40. August 1997 Carine Lucas 40 Contributions » Analysis of important problem: » establishing a notation for disciplined reuse; » acknowledging the importance of evolution of reusable components. » Elaborate a general solution: » based on observations regarding impact analysis ; » based on information on structure and operational behaviour of a system. » Carry out experiments: » to prove usefulness and feasability of building tool support.

41. August 1997 Carine Lucas 41 Conclusion » This dissertation provides » a basic model for reuse contracts. » basic rules for change propagation. » a concretisation of this approach for class libraries and frameworks. » a number of experiments demonstrating its usefulness. » a discussion of possible tools to be built and possible other applications. » This dissertation establishes the foundations of a new methodology for disciplined reuse and a set of directives for further research efforts.

42. August 1997 Carine Lucas 42 Aposition Specialisation interfaces can be used to relieve the tension between covariance and contravariance in the static typing of dynamic inheritance.

43. August 1997 Carine Lucas 43 Typing Dynamic Inheritance: Issues » Subsumption: substitutability of subtypes for supertypes. » Not all object extensions are type correct. » Co-variance vs. contravariance. » Difficult to check vs. lack of flexibility. » Abstraction of common behaviour vs. substitutable is-a relationship.

44. August 1997 Carine Lucas 44 A Liberal Approach: Problems

45. August 1997 Carine Lucas 45 Specialisation Interfaces: Assignability vs. Extendibility This choice should be made by the programmer, not the type system.