©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 1 Chapter 14 Design with Reuse

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 2 Objectives l To explain the benefits and some potential problems with software reuse. l To describe different types of reusable elements and processes for reuse. l To introduce application families as a route to reuse. l To describe design patterns as high-level abstractions that promote reuse.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 3 Topics covered l Component-based development l Application families l Design patterns

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 4 Topics / sections we will skip l Generator-based reuse (pp ) l – (pp )  Application frameworks  COTS product reuse  Component development for reuse

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 5 Reuse-based software engineering l In most engineering disciplines, systems are routinely designed by composing elements that have been used in other systems. l This has not been true in SE, but to reduce risks and accelerate develop- ment, it is now recognized that we need to adopt design processes based on systematic reuse. (whether opportunistic or reuse-driven)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 6 Software reuse practice l Application system reuse – widely practised as software systems are implemented as application families. COTS reuse is becoming increasingly common. l Component reuse – now seen as the key to effective and widespread reuse through Component-Based Software Engineering (CBSE). However, it is still relatively immature. l Function reuse – libraries of reusable functions have been common for 40 years. l Design Pattern reuse – a way of reusing “accumulated knowledge and wisdom” about a problem and its solution. Closely tied to OO design principles. Requires relatively sophisticated design skills, so use is limited.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 7 Benefits of reuse l Increased reliability – when reused elements have been tried and tested in a variety of working systems. l Reduced process risk – less uncertainty of cost compared to new development. l More effective use of specialists – re-use elements instead of experts.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 8 Benefits of reuse (cont.) l Standards compliance – when standards are embedded in reusable elements. l Accelerated development – reduced development and validation time. (usually…)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 9 Requirements for design with reuse l Must be possible to find appropriate reusable elements. l Must be confident that the elements will be reliable and will behave as specified. l Elements must be documented so that they can be understood and, when necessary, modified.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 10 General Reuse problems l Increased maintenance costs – especially if source code / documentation absent. (otherwise, could be much lower) l Lack of tool support – CASE toolsets do not support development with reuse. (What support could be provided?) l Not-invented-here syndrome – the resistance against using “someone else’s” code.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 11 General Reuse problems (cont.) l Repositories of reusable elements – techniques for classifying, cataloguing, and retrieving elements are immature. l Difficulty of finding, understanding, and adapting reusable elements – this takes time.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 12 Component-based development l Component-Based Software Engineering (CBSE) is a development approach based on systematic reuse. l CBSE emerged in the late 1990’s due to failure of OO development (alone) to lead to extensive reuse. l Components are designed to be general service providers. l A multi-level paradigm: “components” may implement a single function or an entire system.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 13 Critical characteristics of a reusable component l An independent executable entity: source code is typically not available so the component is not compiled with other system elements. l All interactions are through a published (2-part) interface – internal state is never exposed. What are some of the practical effects of these characteristics?

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 14 2-part component interface l “Provides interface” – defines the services that are provided by the component to other system elements. l “Requires interface” – defines the services that must be made available to the component by other system elements in order to operate.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 15 2-part component interface

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 16 Printing services component Printer Description Control Interface How does this compare to a “normal object” interface?

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 17 Component abstraction levels l Functional abstraction – implements a single function (e.g., square root) l Casual groupings – loosely related entities such as data declarations and functions l Data abstractions – a data abstraction or object class l Cluster abstractions – related object classes that work together l System abstraction – an entire, self-contained system (e.g., MS Excel)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 18 CBSE processes l Component-based reuse may be opportunistic, or it may drive the development process. l In reuse-driven development, system requirements are modified to reflect the available components. l CBSE often involves an evolutionary development process with components being “glued together” using a scripting language. (e.g., Unix shell, Visual Basic, TCL/TK)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 19 An opportunistic reuse process the “we might get lucky” approach Developed in Brooklyn?

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 20 Reuse-driven development

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 21 CBSE problems l Component incompatibilities: may mean that cost and schedule savings are less than expected. (at best…) l Managing evolution as requirements change: source code is typically not available. (“waiting for the next release”) Plus the general reuse problems discussed previously, such as finding and understanding components, poor tool support, etc.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 22 Application families l An application family or product line is a related set of applications that has a common, domain-specific architecture. l The common core of the application family is reused each time a new application is required. l Each specific application is specialized in some way.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 23 Application family specialization l Platform specialization – different versions of the application are developed for different platforms. (e.g., Windows, Sun OS, Linux) l Configuration specialization – different versions of the application are created to handle different peripheral devices. (I/O devices, etc.) l Functional specialization – different versions of the application are created for customers with different requirements. (e.g., Word users vs. PowerPoint users)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 24 Family member development Use existing family member as prototype.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 25 Design patterns (Alexander, mid-70’s) l A way of reusing “accumulated knowledge and wisdom” about a problem and its solution. l A design pattern is a description of some problem and the essence of its solution. l Should be sufficiently abstract to be reusable in different contexts. l Often utilize OO characteristics such as inheritance and polymorphism.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 26 Pattern elements (Gamma, ‘95) l Name: a meaningful pattern identifier l Problem description l Solution description: a template for a design solution that can be instantiated in different operational contexts (often illustrated graphically) l Consequences: the results and trade-offs of applying the pattern (analysis and experience)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 27 The Observer pattern (Details: p. 323) l Name: Observer l Description: Separates the display of object state from the object itself. l Problem description: Used when multiple displays of state are needed. l Solution description: See UML description l Consequences: Optimizations to enhance (individual) display performance are impractical.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 28 Multiple displays

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 29 The Observer pattern Observer attribute super class Subject super class Specific subject sub-class Specific observer sub-class

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 30 l Design with reuse involves designing software around existing examples of good design and making use of existing software elements. l (Potential) advantages are lower costs, faster development, and lower risks. l CBSE relies on black-box components with defined requires- and provides- interfaces. Key points

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 31 l Software components for reuse should be independent, reflect stable domain abstractions, and provide access to state through interface operations (only?). l COTS product reuse is concerned with the reuse of large-scale, off-the-shelf systems. Key points but general/flexible

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 32 Key points l Application families are related applications that have a common, domain-specific architecture. l Design patterns are high-level abstractions that document successful design solutions.