1. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 1 Chapters 18/19 Software Reuse / CBSE

2. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 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 understand what is meant by CBSE l To introduce application families as a route to reuse. l To describe design patterns as high-level abstractions that promote reuse.

3. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 3 Topics covered l The reuse landscape (introduction)  current practice  benefits  requirements  problems l Design Patterns l Component-Based SE (from Chap. 19)  characteristics  process  problems l Application Families

4. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 4 Topics / sections we will skip l 18.3 Generator-based reuse l 18.4 Application frameworks l 18.5.1 COTS product reuse l 19.1.1 Component models l 19.1.2 Component development for reuse l 19.3 Component composition

5. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 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.

6. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 6 Software reuse practice l Application System reuse – widely practised as software systems are implemented as application families. COTS reuse is also becoming increasingly common. l Component reuse – medium grain elements (usually between objects/functions and application systems) are reused in Component-Based Software Engineering (CBSE). Increasingly being adopted as a mainstream SE approach. l Object and 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.

7. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 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. (cont’d)

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

9. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 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.

10. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 10 General Reuse problems l Increased maintenance costs – especially if source code / documentation absent. (otherwise, could be much lower) l Lack of tool support – most 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. (cont’d)

11. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 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.

12. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 12 Topics covered l The reuse landscape (introduction)  current practice  benefits  requirements  problems l Design Patterns l Component-Based SE (from Chap. 19)  characteristics  process  problems l Application Families

13. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 13 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 a solution. l Should be sufficiently abstract to be reusable in different contexts. l Often utilize OO characteristics such as inheritance and polymorphism.

14. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 14 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)

15. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 15 Example: The Observer pattern

16. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 16 The Observer pattern l Name: Observer l Description: Separates the display of object state from the object itself allowing alternative displays. l Problem description: Used when multiple displays of state are needed. l Solution description: ( See UML description) l Consequences: Object optimizations to enhance the performance of a particular display are impractical.

17. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 17 The Observer pattern (cont’d) Observer super class (for alternative displays)Subject super class Specific subject sub-class Specific observer sub-class one to many

18. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 18 The Observer pattern (cont’d) l Concrete Subject  Has any number of observers  Provides an interface to attach and detach observer objects at run-time  Sends notification to its observers l Concrete Observer  Provides an update interface to receive signals from subject  Implements update operation

19. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 19 Topics covered l The reuse landscape (introduction)  current practice  benefits  requirements  problems l Design Patterns l Component-Based SE (from Chap. 19)  characteristics  process  problems l Application Families

20. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 20 Component-Based Software Engineering 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 are “medium grain” elements (usually between objects/functions and application systems)

21. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 21 Essentials of CBSE 1.Independent components that are completely specified by their interfaces  Clear separation between interface and implementation  One implementation can replace another without changing the system 2.Component standards that facilitate integration  Embodied in a component model - EJB (Enterprise Java Beans), COM+ (.NET model), CCM (Corba Component Model)  Define how interfaces should be specified and how components communicate (cont’d)

22. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 22 Essentials of CBSE (cont’d) 3.Middleware to support component integration  Component communications (e.g., CORBA) +  Resource allocation, transaction management, security, concurrency 4.A development process geared to CBSE (as opposed to a process geared to original software production)

23. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 23 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.

24. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 24 Example: Printing services component Printer Description Control Interface

25. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 25 Component characteristics l Standardized – must conform to some component model defining their interfaces, metadata, documentation, composition, and deployment. l Independent – it should be possible to compose and deploy components without having to use other specific components. l Composable – external interactions must take place through publicly defined interfaces. (cont’d)

26. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 26 Component characteristics (cont’d) l Deployable – must operate on a component platform that implements the component model. Component are usually in binary and do not have to be compiled. l Documented – syntax and (ideally) semantics of interfaces must be specified so potential users can decide if their needs will be met.

27. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 27 The CBSE process Identify candidate components Outline system requirements Modify requirements according to discovered components Further component search and Architectural design Compose components to create system design refinement

28. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 28 CBSE problems 1.Component trustworthiness – a component is a black-box program unit…  There may be undocumented failure modes  Non-functional behavior may not be as expected  Could be a Trojan horse containing malicious code 2.Component certification – should independent assessors certify trustworthiness?  Who would pay for this?  How would liability be handled? (cont’d)

29. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 29 CBSE problems (cont’d) 3.Emergent property prediction – when components are integrated, the resulting system may have undesirable properties that limit its use. 4.Requirements trade-offs – it is usually necessary to make compromises between ideal requirements and available components.  Largely an intuitive process…  Need a more structured, systematic trade-off analysis method to help designers select and configure components.

30. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 30 European Space Agency (ESA) Ariane launch failure l In 1996, the 1 st test flight of the Ariane 5 rocket ended in disaster when the rocket went out of control 37 seconds after take off. l The problem was due to a reused com- ponent from a previous version of the rocket (the Inertial Guidance System) that failed. l Assumptions made when the component was developed for Ariane 4 did not hold for Ariane 5.

31. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 31 Topics covered l The reuse landscape (introduction)  current practice  benefits  requirements  problems l Design Patterns l Component-Based SE (from Chap. 19)  characteristics  process  problems l Application Families

32. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 32 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.

33. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 33 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)

34. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 34 Family member development Use existing family member as prototype.

35. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 35 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 Design Patterns are high-level abstractions that document successful design solutions. Key points (cont’d)

36. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 36 l CBSE relies on black-box components with defined requires- and provides- interfaces. l Software components for reuse should be independent, reflect stable domain abstractions, and provide access to state through interface operations. l COTS product reuse is concerned with the reuse of large-scale, off-the-shelf systems. Key points (cont’d) (cont’d)

37. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 37 Key points (cont’d) l Application Families are related applications that have a common, domain-specific architecture.

38. ©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 38 Chapter 18 Software Reuse