Chapters 18/19

1. Chapters 18/19 Software Reuse / CBSE

2. Objectives • To explain the benefits and some potential problems with software reuse. • To describe different types of reusable elements and processes for reuse. • To understand what is meant by CBSE • To introduce application families as a route to reuse. • To describe design patterns as high-level abstractions that promote reuse.

3. Topics covered • The reuse landscape (introduction) • current practice • benefits • requirements • problems • Design Patterns • Component-Based SE (from Chap. 19) • characteristics • process • problems • Application Families

4. Topics / sections we will skip • 18.3 Generator-based reuse • 18.4 Application frameworks • 18.5.1 COTS product reuse • 19.1.1 Component models • 19.1.2 Component development for reuse • 19.3 Component composition

5. Reuse-based software engineering • In mostengineering disciplines, systemsare routinely designed by composing elements that have been used in other systems. • This hasnot been true in SE, but to reduce risksand accelerate develop-ment, it is now recognized that we need to adopt design processes based on systematic reuse.

6. Software reuse practice • Application Systemreuse – widely practised as software systems are implemented as application families. COTS reuse is also becoming increasingly common. • Componentreuse– 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. • Object and functionreuse – libraries of reusable functions have been common for 40 years. • 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. Benefits of reuse • Increased reliability– when reused elements have been tried and tested in a variety of working systems. • Reduced process risk– less uncertainty of cost compared to new development. • More effective use of specialists – re-use elements instead of experts. (cont’d)

8. Benefits of reuse (cont.) • Standards compliance – when standards are embedded in reusable elements. • Accelerated development – reduced developmentandvalidation time. (usually…)

9. Requirements for design with reuse • Must be possible tofindappropriate reusable elements. • Must be confident that the elements will be reliable and will behave as specified. • Elements must be documented so that they can be understood and, when necessary, modified.

10. General Reuse problems • Increased maintenance costs – especially if source code / documentation absent.(otherwise, could be much lower) • Lack of tool support – most CASE toolsets do not support development with reuse. (Whatsupport could be provided?) • Not-invented-here syndrome – the resistance against using “someone else’s” code. (cont’d)

11. General Reuse problems (cont.) • Repositories of reusable elements – techniques for classifying, cataloguing, and retrieving elements are immature. • Difficulty of finding, understanding, and adapting reusable elements –this takes time.

12. Topics covered • The reuse landscape (introduction) • current practice • benefits • requirements • problems • Design Patterns • Component-Based SE (from Chap. 19) • characteristics • process • problems • Application Families

13. Design Patterns (Alexander, mid-70’s) • A way of reusing “accumulated knowledge and wisdom” about a problem and its solution. • A design pattern is a description of some problem and the “essence” of a solution. • Should be sufficiently abstract to be reusable in different contexts. • Often utilize OO characteristics such as inheritance and polymorphism.

14. Pattern elements (Gamma, ‘95) • Name: a meaningful pattern identifier • Problem description • Solution description: a template for a design solution that can be instantiated in different operational contexts (often illustrated graphically) • Consequences: the results and trade-offs of applying the pattern (analysis and experience)

15. Example: The Observer pattern

16. The Observer pattern • Name: Observer • Description: Separates the display of objectstate from the object itselfallowing alternative displays. • Problem description: Used when multiple displays of state are needed. • Solution description: (See UML description) • Consequences:Object optimizations to enhance the performance of a particular display are impractical.

17. The Observer pattern (cont’d) Subject super class Observer super class (for alternative displays) one to many Specific observer sub-class Specific subject sub-class

18. The Observer pattern (cont’d) • Concrete Subject • Has any number of observers • Provides an interface to attach and detach observer objects at run-time • Sends notification to its observers • Concrete Observer • Provides an update interface to receive signals from subject • Implements update operation

19. Topics covered • The reuse landscape (introduction) • current practice • benefits • requirements • problems • Design Patterns • Component-Based SE (from Chap. 19) • characteristics • process • problems • Application Families

20. Component-Based Software Engineering • Component-Based Software Engineering (CBSE) is a development approach based on systematic reuse. • CBSE emerged in the late 1990’s due to failure of OO development(alone) to lead to extensive reuse. • Components are designed to be general service providers. • A multi-level paradigm: components are “medium grain” elements (usually between objects/functions and application systems)

21. Essentials of CBSE • Independent components that are completely specified by their interfaces • Clear separation between interface and implementation • One implementation can replace another without changing the system • 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. Essentials of CBSE (cont’d) • Middleware to support component integration • Component communications (e.g., CORBA) + • Resource allocation, transaction management, security, concurrency • A development process geared to CBSE (as opposed to a process geared to original software production)

23. 2-part component interface • “Provides interface”– defines the services that areprovided by the component to other system elements. • “Requires interface”– defines the servicesthat must be made available to the component by other system elements in order to operate.

24. Example: Printing services component Printer Description Control Interface

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

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

27. The CBSE process Modify Outline Identify candidate requirements system according to discovered components requirements components Further component Compose Architectural components to search and design create system design refinement

28. CBSE problems • 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 • Component certification – should independent assessors certify trustworthiness? • Who would pay for this? • How would liability be handled? (cont’d)

29. CBSE problems (cont’d) • Emergent property prediction – when components are integrated, the resulting system may have undesirable properties that limit its use. • 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. European Space Agency (ESA) Ariane launch failure • In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster when the rocket went out of control 37 seconds after take off. • The problem was due to a reused com-ponent from a previous version of the rocket (the Inertial Guidance System) that failed. • Assumptions made when the component was developed for Ariane 4 did not hold for Ariane 5.

31. Topics covered • The reuse landscape (introduction) • current practice • benefits • requirements • problems • Design Patterns • Component-Based SE (from Chap. 19) • characteristics • process • problems • Application Families

32. Application Families • An application family or product line is a related set of applications that has a common, domain-specific architecture. • The common core of the application family is reused each time a new application is required. • Each specific application is specialized in some way.

33. Application Family specialization • Platform specialization – different versions of the application are developed for different platforms.(e.g., Windows, Sun OS, Linux) • Configuration specialization – different versions of the application are created to handle different peripheral devices.(I/O devices, etc.) • Functional specialization – different versions of the application are created for customers with different requirements. (e.g., Word users vs. PowerPoint users)

34. Family member development Use existing family member as prototype.

35. Key points • Design with reuse involves designing software around existing examples of good design and making use of existing software elements. • (Potential) advantages are lower costs, faster development, and lower risks. • Design Patterns are high-level abstractions that document successful design solutions. (cont’d)

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

37. Key points (cont’d) • Application Families are related applications that have a common, domain-specific architecture.

38. Chapter 18 Software Reuse