CIS224 Software Projects: Software Engineering and Research Methods

1. CIS224Software Projects: Software Engineering and Research Methods David Meredith d.meredith@gold.ac.uk www.titanmusic.com/teaching/cis224-2006-7.html Lecture 10 Reuse, Components, Patterns and Collaborations (Based on Stevens and Pooley, 2006, Chapter 18, Fowler 2004, Chapter 15)

2. Introduction • Reuse covers any situation in which work done for one project is used to help another • We address the following questions: • What can be reused and how? • Why reuse? • Why is reuse hard? • Which components are genuinely reusable? • What about building your own components? • What difference does object orientation make to reuse?

3. What can be reused? • The following can be reused • Architecture (including frameworks) • Code (particularly, components) • Designs or parts of a design (such as patterns) • Documentation • Tests • Other labour-saving techniques usually not considered to be reuse. For example, • Training a developer in a language for a project and then using him/her in another project • Tools that can be used to assist with several projects (e.g., test harnesses, IDEs, debuggers)

4. How is reuse carried out? • Cut and paste! • Changes in the original don’t get propagated to the copies • Component reuse just about only area where reuse involves more than just cut-and-paste • Reuse of class libraries in languages such as Java has grown rapidly over the past decade

5. What is a component really? • Defined component to be a reusable, replaceable module that is a coherent abstraction with a well-defined interface and low coupling with the rest of the system • This is a fairly broad definition • Rational’s definition: a component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces • “replaceable” here means replaceable at runtime • Stevens and Pooley mean replaceable at maintenance time • More in line with definition of component in UML 2 • Component only replaceable within a particular architecture

6. Why reuse? • Developers’ time saved • Using a pre-existing component saves on analysis, design, reviews, documentation and testing • If good solution developed once, then less experienced developers can benefit from special expertise of component developer • Products can be more reliable because of ‘cumulative debugging’ • Speeds up development • Promotes component-based development which can lead to more reliable and more easily maintained designs

7. Why is reuse hard? • Finding the right component for the job is often not easy – particularly if there are many components to choose from • May be tempted to adapt user requirements in order to use existing components • Component may not work properly • Even if source is available, may be harder to debug than your own code • Component may not be well-documented • Makes it hard to learn how to use the component • May need to import things you don’t need to satisfy component’s context dependencies • Leads to “software bloat”

8. Which components are reusable? • Component needs to be just general enough • Larger the interface, longer it takes to learn how to use it • More common for interface to be too large and complex than for it to be too small and simple • Component needs to be properly documented • Specify interfaces and context dependencies • Can provide use case diagram showing tasks that component supports • Component must be especially thoroughly tested • Developer of module may not be around to repair module when bug found by client developer • Component may be used in lots of different environments so must be robust to changes provided that context dependencies are satisfied and required interfaces are provided

9. What about building your own components? • Making a reusable component is usually harder and takes longer than making a module for one-off use • Have to make the component more robust to changes in the environment in which it will be used • Implies more thorough testing • Have to document the component more thoroughly so that it can be maintained by someone other than the developer • No guarantee that a component that is designed to be reused actually will be • Long-established tradition in software that people prefer to build new things than use what already exists • Leads to immense amount of duplication of effort and “reinvention” • Must change culture so that people are encouraged to look hard for existing components that do the job before trying to build them themselves • Using components is easier, cheaper and more reliable than building them • Benefits of component-based development arise from using components, not from building them

10. When can component-building be done? • In a commercial environment where goal is to develop and market a product, hard to find extra time required to make component reusable • Company has to adopt culture of investing time and manpower into making the modules it makes reusable • Need to convince people that, in the mid-to-long term, this makes good economic sense

11. What difference does object-orientation make? • Object-orientation encourages high cohesion/low coupling style of programming which promotes reusability • OO analysis focuses on determining suitable classes of domain objects which probably do not need to change very much over time and so can therefore be reused in different applications in the domain • Domain objects tend to recur in different contexts and so make good reuse candidates • In OO, a class can be reused as the base class of a new more specialized subclass • Can adopt the “Open-Closed Rule”: develop classes that are coherent and encapsulated (closed) and extensible through specialization (open) • However, inheritance not always a good thing • Creates strong coupling – subclass depends on base class • Does not reduce amount of testing required on new subclass

12. Design patterns • A pattern is a named, well-defined, good solution to a problem that is common within a particular context • Concept of a design pattern originally developed in architecture by Alexander, Ishikawa, & Silverstein (1977) in their book, A Pattern Language, (OUP) • Alexander et al. proposed 253 patterns, each solving a common problem in architecture, construction and urban planning • e.g., “Teenager’s Cottage” • Aims to solve problem that a teenager and his/her family need to be mutually supportive, whilst teenager becomes more independent • Static architecture that keeps teenager in a child’s bedroom does not satisfy needs of family and teenager • Solution is to have a “teenager’s cottage” which is strongly attached to main home but has its own entrance. • Alexander describes several variant solutions with diagrams • Discusses objections such as that cottage becomes useless after teenager has grown up • Possibly solved by using cottage as an office or study • A very similar situation arises in software engineering • Certain basic design problems recur again and again • Instead of solving same problem again and again from scratch, accumulate knowledge of best solutions and reuse these solutions • Allows novices to learn by example and become experts more quickly • Allows you to build the best, known solution straight away without having to find it yourself by perhaps constructing many suboptimal solutions

13. Design patterns • Patterns document, at a suitable level of abstraction, designs that are effective, thoroughly tested and well understood • Not only good for novices – also good for experienced developers • Having a clearly understood, named solutions to common problems • Makes it easier to discuss designs • Allows for more structured research programmes that aim to improve the solutions • Helps us to have a clear idea of what the state of the art is • Pattern should achieve just the right level of abstraction • Too abstract – hard to implement, platitudinous • Too concrete – not applicable in a wide range of situations

14. Format of a pattern catalogue • Certain information should be provided for each pattern: • Name (and possibily aliases) • Abstract – brief description of pattern in about 3 sentences • Context – brief description of the class of situations in which the pattern can be applied • Problem that pattern solves; usually describes conflicting forces to be satisfied, requirements and constraints • Solution – explanatory text, models, CRC cards, etc. • Variants and related patterns – including patterns used in this pattern, variant solutions • Examples of implementations of the pattern • Consequences of using the pattern • Books on patterns • Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software.Addison-Wesley. • Buschmann, F., Henney, K. and Schmidt, D. (2007). Pattern-oriented Software Architecture: On Patterns and Pattern Languages. Wiley.

15. An example pattern: Façade • Name Façade • Abstract Façade defines a clean, high-level interface to a component, hiding its structure to make it easier to use • Context Building easy-to-use components • Problem If a component consists of many related classes, developer must understand much about structure of component in order to use it. Changes in structure of component may also necessitate changes in its clients. • Solution Add Façade class which provides single, unified interface to component. All messages to the component are received by the Façade class which forwards the messages to the appropriate classes within the component. No class within the component depends on the Façade class. All classes apart from Façade class should be hidden inside the component. • Consequences Clients don’t depend on structure of component. Structure of component can be changed without necessitating changes elsewhere in the system provided that Façade class is not changed.

16. Collaborations • Patterns can be represented in UML using collaborations • Collaboration describes structure of collaborating elements (roles) which collectively accomplish a particular task • Collaboration at top left represents the roles that have to be played by objects in a typical auction • Whole collaboration enclosed in dashed ellipse • Each square box represents a role (not a class – note non-capitalized names) • Diagram at bottom left shows use or occurrence of the Auction collaboration in the particular case of a house auction • An object of the Bid class fulfils the role of offer in the Auction collaboration • Objects of the Party class fulfil the roles of buyer and seller in the Auction collaboration • Object of class House fulfils role of lot in Auction collaboration • Links between collaboration icon and classes that realize roles in collaboration are called role bindings

17. Representing patterns by collaborations • An OO system that uses a pattern will contain a family of objects that are bound to the roles in the pattern • e.g., component that uses Façade pattern will contain object bound to façade role • facade object receives messages sent to the component and forwards them to the appropriate subsystem classes within component • Subsystem classes navigable from the façade class but not vice versa • Pattern represented by collaboration • Application of a pattern in a particular system represented by collaboration use • e.g., if other library systems need to access library system, could provide access to information on Books and Journals held by library via a façade class, Library, associated with the Book and Journal classes within the Library system

18. Summary • What can be reused? • Architecture, code, patterns, documentation, tests • How is reuse carried out? • Cut and paste, components, class libraries • What is a component? • Reusable, replaceable, coherent module with good interface and low coupling • Why reuse? • Saves development time, improves reliability and maintainability • Why is reuse hard? • Sometimes hard to find appropriate, reliable component • What makes a component reusable? • Just general enough, properly documented, thoroughly tested • Always use components if you can rather than build them yourself • What difference does OO make to reuse? • OO encourages high cohesion/low coupling programming style • OO encourages modelling stable domain objects • inheritance allows adoption of "Open-Closed" Rule • Patterns • Named, well-defined solution to a common problem • Avoids reinvention of best solutions • Using collaborations to represent patterns in UML