1. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Component and Framework Reuse Dr. Tom Mens Programming Technology Lab Vrije Universiteit Brussel Course OOSE.RC EMOOSE 1999-2000

2. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Goals  Teach about families of related applications (application families)  Teach two basic forms of reuse: component and framework reuse  Teach how to deal with commonalities and variabilities  Teach about the iterative process of building components and frameworks

3. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Definitions  a component is a system building block defined by its external interface  a system is a set of communicating components fitting together to realise a certain functionality (i.e., end user services)  systems are engineered, well-documented workproducts  an application system is a system delivered outside of the developer organization to offer a coherent set of services to an end user

4. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Application Families  An application system family is a set of application systems with common features  application systems in a family share certain foundations or are interoperable in some way  application system suite: applications that are intended to work together  e.g., Office Suite  application system variants: share a common foundation  e.g., different OS, different hardware

5. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Components are the Units of Reuse  A component is a type, class or any other workproduct that has been specifically designed to be reusable  classes, collaborations, use cases, models,...  Designed, packaged and documented to be reusable  components have an external interface  Different reuse mechanisms imply different components  inheritance => class (source code level)  copy&modify reuse => anything  CORBA => class (executable level)

6. February, 2000Programming Technology Lab, Vrije Universiteit Brussel  Reuse is class centered  Application calls library  Difficult to reuse application logic  Logic is spread among different classes Reuse of Components in Isolation Button Number Complex Application Logic of Calculator Application

7. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Component Systems  A component system is a system product that offers a set of reusable features.  Features are implemented as related and interconnected sets of components of various types, associated packages and descriptive documents. > LAN Logical View AddressableNode AbstractAddress ActivePacket Packet Forwarding AddressableNode ActivePacket Destination Checking AddressableNode AbstractAddress

8. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Frameworks are Component Systems  An application framework is a reusable and customisable design for a set of components  typically, classes are components  consists of abstract and concrete classes  emphasises on collaboration between classes  A framework is not necessarily a working application  abstract classes and methods must be “filled in” with concrete ones first  the places where the framework must be “filled in” are called the hot spots

9. February, 2000Programming Technology Lab, Vrije Universiteit Brussel LAN Framework Addressable Node Active Packet Address PostScript Printer ASCII Printer Hot Spots 3Collaboration contracts 3Templates Counting Packet Broadcast- Packet

10. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Kinds of Frameworks  Application Frameworks  MacApp  Visualworks  OpenDoc  Domain-Specific Frameworks  ET++ Swapsmanager (financial world)  Intermedia (hypermedia)  OSEFA (manufacturing systems)  Closer to us  Whats’On (television broadcast planning)  ApplFLab (application building)  Conduits (OO Course)

11. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Range of Component Systems  Classes are used in isolation  Application calls library  No template solution (no hot spots)  Framework as a whole is reused  Framework calls application  Template solution Class LibraryFramework

12. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Components need to be Specialised before Reuse  Specialisation can be dealt with ‘pro-actively’  what are the foreseen (anticipated) customisations?  use different mechanisms to deal with foreseen customisations  parameterised classes (e.g. C++ templates)  application configuration (e.g. Microsoft Word)  abstract classes and collaboration contracts  Specialisation that must be dealt with ‘after-the-facts’  not all customisations can be foreseen !  use different mechanisms to deal with unforeseen customisations  inheritance of concrete classes  scripting  abstract classes and collaboration contracts

13. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Foreseen Specialisations: Features  Different application systems and component systems can be distinguished from similar systems on the basis of the functionality, services and many other features they offer.  In general, any distinguishing characteristic can be a feature - “a difference that makes a difference”

14. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Foreseen Specialisations: Domain Analysis  Scope the domain  Analyse the domain  gather domain knowledge  generalise from existing applications  find things that are given different names but are really the same  parameterise to eliminate differences  break large things into small things so that similar components can be found  Model commonalities and variabilities  analise the commonalities and variabilities of the different applications in terms of features

15. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Domain Engineering Domain Analysis Domain Design Domain Implementation OOA OOD classification OOP polymorphism 3 Variation points 3 Facades 3 Roles 3 Collaboration Contracts 3 Design Patterns 3 Abstract classes 3 Frameworks

16. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Application Engineering Domain Analysis Domain Design Domain Implementation Domain Engineering Application Engineering Application Analysis Application Design Application Implementation  application in the family

17. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Unforeseen Specializations: Refactoring  Refactoring (or restructuring) is a reorganisation of a system to improve reuse  A refactoring is behavior preserving transformation  A refactoring has a precondition  Some refactorings are based on invariants  Refactoring into object-oriented frameworks  iteratively turning an OO application into a framework

18. February, 2000Programming Technology Lab, Vrije Universiteit Brussel References  William F. Opdyke. Refactoring object-oriented frameworks. PhD Dissertation, University of Illinois at Urbana-Champaign, 1992.  Ralph E. Johnson, William F. Opdyke: Refactoring and Aggregation, 1993.  William F. Opdyke, Ralph E. Johnson: Creating abstract superclasses by refactoring. Proc. ACM Computer Science Conference, pp. 66-73, ACM Press, 1993.  Don Roberts, John Brant, Ralph E. Johnson. A refactoring tool for Smalltalk. TAPOS Journal 3(4): 253-263, 1997.  Martin Fowler. Refactoring: improving the design of existing programs. Addison-Wesley, 1999.

19. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Generalisations Require Concrete Cases  Abstract classes and frameworks are generalisations  People think concretely, not abstractly  Abstractions are found bottom up, by examining concrete examples first  Generalisation proceeds by:  finding things that are given different names but are really the same (and thus renaming them)  parameterising to eliminate differences  breaking large things into small things so that similar components can be found à Refactoring

20. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Low-Level Refactorings (1)  Creating a program entity  create empty class  define a new class with no instance variables, nor methods  create instance variable  add an unreferenced instance variable to a class  create method  add a method to a class that either is unreferenced or is identical to an already inherited method  Deleting a program entity  delete unreferenced class  delete unreferenced instance variable  delete methods  delete a set of methods; either each method is redundant, or the only references to it are by other methods that are also being deleted

21. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Low-Level Refactorings (2)  Changing a program entity  change class name  the precondition ensures distinct class names  change variable name  the name change is reflected throughout its scope  change method name  change the name of a method and any corresponding methods defined in subclasses, and any corresponding message sends  change type (C++)  change the type of a set of (pointer) variables and functions (i.e. change the types of the variables and return types of the functions)  change access control mode  change the access control mode (‘private’, ‘protected’, ‘public’) of a member variable or function

22. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Exercise  Try to find as much other low-level (behaviour-preserving) refactorings for changing a program entity yourself.

23. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Low-Level Refactorings (3)  Changing a program entity (cont’d)  add method argument  add a new argument to the definition of a method in its class (and subclasses that override it). In each method invocation, add an argument which is a dynamically created instance  delete method argument  delete an argument from the definition of a method in its class (and subclasses that override it). In each method invocation, the argument is removed  reorder method arguments  reorder the arguments in a method definition in its class (and subclasses that override it) and in all invocations of that method  convert instance variable to pointer (C++)

24. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Low-Level Refactorings (4)  Changing a program entity (cont’d)  add method body  add a method body to an existing method (signature)  delete method body  delete a method body from an existing method (making it a signature only)  convert variable references to method invocations  convert all references to V to invocations of its (existing!) accessor method. Convert all assignments to V to invocations of its (existing!) mutator method  replace expressions with method invocation  replace a list of expressions in a method with an invocation to a method that behaves the same as the list of expressions

25. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Low-Level Refactorings (5)  Moving an instance variable  move instance variable to superclass  move instance variable V to class C from all subclasses where it is defined  move instance variable to subclasses  move an instance variable from its current containing class to each of its immediate subclasses  Composite refactorings  abstract access to instance variable  abstract access to an instance variable by defining accessor and mutator methods, and replacing all variable references with invocations of these methods  inline method invocation  replace method invocation with body of invoked method  convert code segment to method  define new method with unique name, whose body is equivalent to an expression list of an existing method. Replace that expression list in the method with an invocation of the new method

26. February, 2000Programming Technology Lab, Vrije Universiteit Brussel High-level Refactorings: Abstraction concrete class A concrete class B concrete class A abstract class X abstraction

27. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Abstraction: Refactor to Generalise  Creating an Abstract Superclass  Create a common superclass  Make method signatures compatible  Add method signatures to the superclass  Make method bodies compatible  Make instance variables compatible  Move instance variables to the superclass  Migrate common code to the abstract superclass PrintServer print:Boolean FileServer save OutputServer output PrintServerFileServer

28. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Refactor to Specialise  Motivation :  improve framework design by decomposing a large, complex class into several smaller classes  the complex class usually embodies both a general abstraction and several different concrete cases that are candidates for specialisation  Specialise a class by adding subclasses corresponding to the conditions in a conditional expression:  choose a conditional whose conditions suggest subclasses (this depends on the desired abstraction)  for each condition, create a subclass with a class invariant that matches the condition  copy the body of the condition to each subclass, and in each class simplify the conditional based on the invariant that is true for the subclass  specialize some (or all) expressions that create instances of the superclass

29. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Refactor to Specialise: Example Disk... copyDisk formatDisk... Disk Management for MSDOS Disk disktype... copyDisk formatDisk Disk Management for MSDOS+MAC formatDisk self diskType = #MSDOS ifTrue: [.. code1..]. self diskType = #MAC ifTrue: [.. code2..]. Disk... copyDisk formatDisk... Disk Management for MSDOS+MAC Class Invariant MSDOSDisk... copyDisk formatDisk... MACDisk... copyDisk formatDisk...

30. February, 2000Programming Technology Lab, Vrije Universiteit Brussel High-level Refactorings: Factorisation abstract class A factorisation method m1 method m2 abstract class A method m1 concrete class X method m2

31. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Refactor to Capture Aggregations & Components  Motivation :  Inheritance is a powerful technique, but in modelling the relationships among classes it is sometimes overused and incorrectly used. Aggregations are another tool for modelling these relationships.  Several refactorings regarding aggregations :  qualify an instance variable as a component  move instance variables/methods from an aggregate class to the class of one of its components  move instance variables/methods from a component class to the aggregate classes that contain components which are instances of the component class  convert a relationship, modelled using inheritance, into an aggregation and vice versa

32. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Example: Convert Inheritance into Aggregation Matrix MatrixRepresentation TwoDimArraySparseMatrix rep TwoDimArray

33. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Evolutionary transformations  A refactoring is a transformation that preserves the behaviour of a software artifact  An evolutionary transformation changes the behaviour of a software artifact  Each transformation can be decomposed into a (number of) refactoring(s) and a (number of) evolutionary transformation(s)

34. February, 2000Programming Technology Lab, Vrije Universiteit Brussel Exercise 1.Give at least three different “pure” evolutionary transformations 2.Give at least three transformations that change the behaviour of a software artifact, and decompose them into a refactoring part and a evolutionary part.