Documenting Reuse and Evolution with Reuse Contracts Carine Lucas August 1997

1. Documenting Reuse and Evolution with Reuse ContractsCarine LucasAugust 1997

2. Overview • Motivation • Problems with Reuse • Basic principles • Reuse Contracts • Step 1: Documenting Dependencies • Step 2: Documenting Reuse • Step 3: Rules for Change Propagation • Validation • Conclusion

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. Research Approach Research areas: • analysis of problems; • vocabulary and notation for disciplined reuse; • formal underpinnings; • tools and environments; • experimental validation; • process models.

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. 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. 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. 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. 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. Impact Analysis self m Changing an operation m x [ a.m ] m y [ b.x ] self m

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. Changing Assumptions gateway gateway assumes actually gets handle [if isDestFor then output] handle [ send action ] Support for change propagation based on documenting assumptions.

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. Overview • Motivation • Problems with Reuse • Basic principles • Reuse Contracts • Step 1: Documenting Dependencies • Step 2: Documenting Reuse • Step 3: Rules for Change Propagation • Validation • Conclusion

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

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

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

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. Example: Participant Extension checkCard {verifyAccount} ATM Consortium checkCard verifyAccount theATM theCons Participant Extension Modifier Participant Extension { (ATM, { (trActRequest, {theCons.processTrAct}) }), (Consortium. { (processTrAct, {}) }) } checkCard {verifyAccount} trActRequest{processTrAct} ATM Consortium checkCard trActRequest verifyAccount processTrAct theATM theCons Operators are defined by modifier, applicability and operator definitions and preserve well-formedness.

20. Step 3: Estimating Impact of Changes accept {handle} OutputServer accept isDestFor output send Packet handle server packet handle {isDestFor, output, send} Participant Refinement output {+gate.passOn} • Participant Coarsening • handle {-server.output} 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

21. R1 Rbase Base (reuse) Contract M1 ? M2 M2 R2 Rresult Resulting (reuse) contract Rules for Conflict Detection Two operationsm and n become inconsistent when • M1 represents a participant coarsening of m on p dereferencing n on q; • M2 represents a participant refinement or participant coarsening of m on p; These rules can be checked automatically.

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. 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. ... Rbase R1 R2 Rn ... M1 M2 Mn M’ M’ ? R’ R’ Chains of Operators • No extra conflicts. • Some conflicts can be annihilated in chains. • Chains can introduce extra transitive closure conflicts.

25. ATM checkCard {verifyAccount} Consortium checkCard trActRequest verifyAccount theATM theCons Extending Refinement checkCard {verifyAccount} trActRequest{processTrAct} ATM Consortium checkCard trActRequest verifyAccount processTrAct theATM theCons Combinations of Operators • 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. Criteria for Reuse Revisited • Reuse contracts declare how a componentcan 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, butnon-coercivereuse; • provides a layered, selective white-box interface documenting structural dependencies; • offers a formal basis for change propagation.

27. Overview • Motivation • Problems with Reuse • Basic principles • Reuse Contracts • Step 1: Documenting Dependencies • Step 2: Documenting Reuse • Step 3: Rules for Change Propagation • Validation • Conclusion

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

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. 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. AirTime resolve: {distr.placeSpot:} noSpace BlockSpotSpace GRP_AirTime resolve: { distr.placeSpot: } validSol:in: { checkSol } checkSol noSpace resolve: { distr.placeSpot:, planner.distrWithGRP } reschedule: noSpace Documenting Reuse Concretisation resolve: Extension validSol:in: {checkSol} checkSol Layered Concretisation resolve: {+planner.distrWithGRP:} Extension reschedule

32. 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 Change Propagation Rules

33. 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 Change Propagation The tables signal problems, thus also suggesting solutions or alternative changes.

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. Extraction

36. Experiments (2) • Enforcing Design • Compliance Checking • Design Patterns • Design Assessment • Well-formed Reuse Contracts • Assessments based on Operators • Existing Design Rules

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. Design Assessment The Stream hierarchy is awkward with respect to the method next. 1 2 3

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. 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. 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. Aposition Specialisation interfaces can be used to relieve the tension between covariance and contravariance in the static typing of dynamic inheritance.

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. A Liberal Approach: Problems

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