1. Tempus Software Maintenance and Evolution JMSE-SM&E Unit 4: Software Reuse (Building Software From Reusable Components) Prof. Mohammad A. Mikki Gaza, Palestine, 5.8.2014

2. Joint Master in Software Engineering “Software Maintenance and Evolution” Course Unit 4 Software Reuse (Building Software From Reusable Components) Software Maintenance and Evolution 2 ( Source: Partially adapted from Ian Sommerville, Software Engineering, sixth Edition, Addison Wesley Publishing Company, 2000)

3. Joint Master in Software Engineering Introduction  Software engineering originally focused on development of software from scratch. But it is now recognized that to develop higher quality software, more quickly and at lower cost, we need to adopt a design process that is based on software reuse.  Current software systems are designed by composing existing components that have been used in other systems.  This unit introduces software reuse and describes approaches to system development based on system reuse. We first, define software reuse, we then present advantages and benefits of software reuse. Then, we present problems with software reuse. We also present requirements for reuse. Course Title 3

4. Joint Master in Software Engineering Introduction (Cont.)  The unit also discusses the software components that are reused which may be of radically different sizes such as application system reuse, component reuse, and object and function reuse.  The unit presents Key factors that you should consider when planning reuse.  Other covered topics in this unit include describing different approaches to reuse such as reuse patterns, program generators, application frameworks, software product lines, and commercial off-the-shelf application software systems (COTS) product reuse.  The unit finally presents Component-based software engineering (CBSE). Course Title 4

5. Joint Master in Software Engineering Course Title Objectives  Understand and have practical experience in the issues related to software resuse  Discuss the advantages and disadvantages of software reuse  Explain the software reuse problems  Discuss the characteristics of generic reusable components  Understand the concept of the different reuse approaches  Discus component-based software engineering (CBSE) 5

6. Joint Master in Software Engineering Course Title Intended Learning Outcomes (ILOs)  Understand and have practical experience in the issues related to software resuse  Discuss the advantages and disadvantages of software reuse  Explain the software reuse problems  Discuss the characteristics of generic reusable components  Understand the concept of different reuse approaches:  Discus component-based software engineering (CBSE) 6

7. Joint Master in Software Engineering Course Title List of Topics  The reuse landscape  Reuse Approaches  Reuse patterns  Program generators  Software product lines  Component-Based Development  Application frameworks  COTS product reuse  Component-based software engineering (CBSE) 7

8. Joint Master in Software Engineering  In most engineering disciplines, systems are designed by composition (building system out of components that have been used in other systems)  Software engineering has focused on custom development of components  To achieve better software quality, more quickly, at lower costs, software engineers are beginning to adopt systematic reuse as a design process.  we need to adopt a design process that is based on systematic reuse The Reuse Landscape

9. Joint Master in Software Engineering  Reuse-based software engineering is a software engineering strategy where the development process is geared to reusing existing software.  Reuse is Using a given piece of software to solve more than one problem  Software reuse is the process of implementing or updating software systems using existing software components. Course Title 9 The Reuse Landscape Definition

10. Joint Master in Software Engineering  When a developer reuses program or design components, he must follow the design decisions made by the original developer of the component.  This restricts the opportunities for reuse by new developer.  To counter this restriction, an abstract form of reuse is concept reuse when a particular approach is described in an implementation independent way and an implementation is then developed. The Reuse Landscape Concepts

11. Joint Master in Software Engineering Soft. Eng. II, Spring 02 Dr Driss Kettani, from I. Sommerville 11  Rather than reuse being considered after the software has been specified, the specification takes into account the existence of reusable components  This approach is used in the design of software systems and other non-software systems such as electronic, electrical and mechanical systems. The Reuse Landscape Concepts (Cont.)

12. Joint Master in Software Engineering Soft. Eng. II, Spring 02 Dr Driss Kettani, from I. Sommerville 12  Software reuse involves using components developed in some application in a different application  Software components are not automatically reusable.  They must be modified to make them usable across a range of applications  Software development for reuse is a development process which takes existing components and aims to generalize them for reuse across a range of applications The Reuse Landscape Concepts (Cont.)

13. Joint Master in Software Engineering Soft. Eng. II, Spring 02 Dr Driss Kettani, from I. Sommerville 13  Software application portability is a form of reuse where an entire application is reused on a different platform  Software application portability is achieved by developing according to standards and isolating software and hardware platform dependencies  Development with reuse must be based on a library of reusable components  Components must be generalized for reuse The Reuse Landscape Concepts (Cont.)

14. Joint Master in Software Engineering Soft. Eng. II, Spring 02 Dr Driss Kettani, from I. Sommerville 14 Software Reuse Process Software reuse process is composed of the following procedure/steps 1.Design software system architecture 2.Specify system components 3.Identify reusable components 4.Incorporate reusable components in development of new software systems

15. Joint Master in Software Engineering Benefits of Reuse Lower cost  Reusable components are developed once but used many times.  If software exists, the costs of reusing that software is only the cost of development

16. Joint Master in Software Engineering Faster software development  Reuse avoids custom development  Reuse speeds up delivery  Reuse avoids original development and hence speeds-up production  Reuse minimizes turnaround time and brings a system to market as early as possible which is often more important than overall development cost.  Reusing software can speed up system production because both development and validation time are reduced Benefits of Reuse (Cont.)

17. Joint Master in Software Engineering Lower risks  Reuse reduces management risk  Less uncertainty in development costs of new software  If software exists, there is more certainty in the cost of reusing that software than in the costs of development.  This reduces the margin of error in project cost estimation.  Risk is reduced more when relatively large software components such as sub-systems are reused. Benefits of Reuse (Cont.)

18. Joint Master in Software Engineering Higher reliability, quality, and dependability  Reusable components are tested in working systems  Software that uses reusable components should be more dependable than new software  Reused components have been tried and tested in working systems.  The initial use of the reusable software components reveals problems and faults. These are then fixed, thus reducing the number of failures when the software is reused. Benefits of Reuse (Cont.)

19. Joint Master in Software Engineering Effective use of specialists  Reuse components instead of people  Reuse helps minimize staff  Instead of application specialists doing the same work on different projects, these specialists can develop reusable software that encapsulate their knowledge. Benefits of Reuse (Cont.)

20. Joint Master in Software Engineering Standards compliance  Standards can be embodied in reusable components  Some standards, such as user interface standards, can be implemented as a set of standard reusable components.  The use of standard user interfaces improves dependability as users are less likely to make mistakes when presented with a familiar interface Benefits of Reuse (Cont.)

21. Joint Master in Software Engineering Requirements for Software Reuse  Need to find reusable components  The software developer who wants to reuse the reusable component must be confident that the components will be reliable and will behave as expected  The reusable components must be documented to support understanding and, possible future modification.  The components must have associated with costs of reuse

22. Joint Master in Software Engineering Reuse Problems Increased maintenance costs  Maintenance cost includes organizational, technical, process changes, cost of tools to support those changes, and the cost of training people on the new tools and changes.  It is difficult to quantify maintenance costs and benefits of development with reuse  If the source code of a reused software system or component is not available then maintenance costs may be increased as the reused elements of the system may become increasingly incompatible with system changes

23. Joint Master in Software Engineering Lack of tool support  CASE toolsets may not support development with reuse.  It is difficult or impossible to integrate these tools with a component library system.  The software process assumed by these tools does not take reuse into account Reuse Problems (Cont.)

24. Joint Master in Software Engineering “not invented here” syndrome  Some software engineers prefer to re-write components as they believe that they can improve the reusable component.  This is due to trust and to the fact that writing original software is seen as more challenging than reusing other people’s software Reuse Problems (Cont.)

25. Joint Master in Software Engineering Need to create and maintain a component library  Design of a reusable component library and ensuring the software developers can use this library can be expensive.  Current techniques for classifying, cataloguing and retrieving software components are immature Reuse Problems (Cont.)

26. Joint Master in Software Engineering Finding and adapting reusable components  Software components have to be discovered in a library, documented, understood and, adapted to work in a new environment.  Engineers must be reasonably confident of finding a component in the library before they will make a component search as part of their normal development process  The cost of finding suitable components is high Reuse Problems (Cont.)

27. Joint Master in Software Engineering Economics of Reuse  Quality -With each reuse, additional component defects are identified and removed which improves quality.  Productivity -Since less time is spent on creating plans, models, documents, code, and data, the same level of functionality can be delivered with less effort so productivity improves.

28. Joint Master in Software Engineering  Cost -Savings projected by estimating the cost of building the system from scratch and subtracting the costs associated with reuse and the actual cost of the software as delivered.  Cost analysis using structure points -can be computed based on historical data regarding the costs of maintaining, qualification, adaptation, and integrating each structure point. Economics of Reuse (Cont.)

29. Joint Master in Software Engineering  There are many different approaches to reuse that may be used.  Reuse is possible at a range of levels from simple functions to complete application systems.  The reuse landscape covers the range of possible reuse techniques. Course Title 29 Reused Components Size

30. Joint Master in Software Engineering Software units that are reused may be of radically different sizes such as:  Application System Reuse - reusing an entire application by incorporation of one application inside another (COTS reuse) - development of application families (e.g. MS Office)  Component Reuse -components (e.g. subsystems or single objects) of one application reused in another application  Function Reuse -reusing software components that implement a single well-defined function Reused Components Size (Cont.)

31. Joint Master in Software Engineering  A complete software application may be reused by -incorporating it without change into other systems (COTS reuse). COTS reuse is becoming increasingly common or -developing application families where it is widely practised as software systems are implemented as application families.  How to write application systems so that they may be ported from one platform to another  When the whole application is reused on a different machine it is referred to as program portability Application System Reuse

32. Joint Master in Software Engineering Application System Reuse Approaches  Two approaches -COTS product integration -Product line development

33. Joint Master in Software Engineering  Components of an application ranging from sub-systems to single objects may be reused.  Key to effective and widespread reuse through component- based software engineering.  It is still immature  The reusable component is a collection of functions or procedures in addition to their data structures Component Reuse

34. Joint Master in Software Engineering  Software components that implement a single well-defined object or function may be reused.  Common in some application domains (e.g. engineering) where domain-specific libraries of reusable functions have been established  The reusable component is a single function Function Reuse

35. Joint Master in Software Engineering Soft. Eng. II, Spring 02 Dr Driss Kettani, from I. Sommerville 35 Reuse Landscape The reuse landscape covers the range of possible reuse techniques.

36. Joint Master in Software Engineering Soft. Eng. II, Spring 02 Dr Driss Kettani, from I. Sommerville 36 Three Aspects of Reuse  Software development with reuse -How must software engineering processes evolve to incorporate reuse  Software development for reuse -How to design generic software components for reuse  Application system reuse -How to write application systems so that they may be readily ported from one platform to another

37. Joint Master in Software Engineering Concept Reuse  When you reuse program or design components, you have to follow the design decisions made by the original developer of the component.  This may limit the opportunities for reuse.  However, a more abstract form of reuse is concept reuse when a particular approach is described in an implementation independent way and an implementation is then developed.

38. Joint Master in Software Engineering Reuse Approaches  Reuse approaches are the possible ways of implementing software reuse  The two main approaches to software reuse are: -Design patterns: Generic abstractions that occur across applications are represented as design patterns that show abstract and concrete objects and interactions -Program generators: A generator system embeds knowledge of a particular type of application and can generate systems or system fragments in that domain

39. Joint Master in Software Engineering Other Reuse Approaches  Component-based development: Systems are developed by integrating components (collections of objects) that conform to component-model standards.  Component frameworks  Application frameworks: Collections of abstract and concrete classes that can be adapted and extended to create application systems  Legacy system wrapping: Legacy systems that can be ‘wrapped’ by defining a set of interfaces and providing access to these legacy systems through these interfaces.  Service-oriented systems: Systems are developed by linking shared services that may be externally provided

40. Joint Master in Software Engineering  Application product lines: An application type is generalised around a common architecture so that it can be adapted in different ways for different customers  COTS integration: Systems are developed by integrating existing application systems.  Configurable vertical applications: A generic system is designed so that it can be configured to the needs of specific system customers  Program libraries: Class and function libraries implementing commonly-used abstractions are available for reuse  Aspect-oriented software development:: Shared components are woven into an application at different places when the program is compiled Other Reuse Approaches (Cont.)

41. Joint Master in Software Engineering  Design patterns are generic abstractions that occur across applications are represented as design patterns that show abstract and concrete objects and interactions  They are high-level abstractions that document successful design solutions. Design Patterns

42. Joint Master in Software Engineering Design Pattern Properties  A design pattern is a way of reusing abstract knowledge about a problem and its solution.  A design pattern is a description of the problem and the essence of its solution.  A design pattern should be sufficiently abstract to be reused in different settings.  Design patterns often rely on object characteristics such as inheritance and polymorphism.

43. Joint Master in Software Engineering Design Pattern Elements  Name -The pattern identifier  Problem description  Solution description -Not a complete design but a template (interface) for a design solution that can be instantiated (creating the class) in different ways  Consequences -The results and trade-offs of applying the design pattern

44. Joint Master in Software Engineering Design patterns Example 1: Multiple Data Displays

45. Joint Master in Software Engineering  Name: Observer  Description: Separates the display of object state from the object itself  Problem description: Used when multiple displays of state are needed  Solution description: See next slide with UML description  Consequences: Optimisation to enhance display performance are impractical Design Patterns Example 2: Observer Pattern

46. Joint Master in Software Engineering Design Patterns Example 2: Observer Pattern (UML)

47. Joint Master in Software Engineering Program generators are concerned with software reuse where the reusable concepts are embedded in a generator system. A generator system embeds knowledge of a particular type of application and can generate systems or system fragments in that domain Program Generators

48. Joint Master in Software Engineering  Program generators involve the reuse of standard patterns and algorithms.  These standard patterns and algorithms are embedded in the generator and parameterised by user commands. A program is then automatically generated.  Generator-based reuse is possible when domain abstractions and their mapping to executable code can be identified.  A domain specific language is used to compose and control these abstractions. Program Generators Properties

49. Joint Master in Software Engineering  Application generators for business data processing  Parser and lexical analyser generators for language processing  Code generators in CASE tools  User interface design tools Types of Program Generators

50. Joint Master in Software Engineering Program Generator Reuse Procedure Application description Program generator Generated program Application description Database

51. Joint Master in Software Engineering  Advantages -Program generator reuse approach is cost effective -It is easier for end-users to develop programs using generators than through using other Component-Based Software Engineering (CBSE) techniques  Disadvantages -The applicability of generator reuse is limited to a small number of application domains Program Generators Advantages and Disadvantages

52. Joint Master in Software Engineering  In software product lines or application families approach an application type is generalised around a common architecture so that it can be adapted in different ways for different customers  Software product lines that are configured at design time are instantiations of generic application architectures  Software product lines are applications with generic functionality that can be adapted and configured for use in a specific context. Software Product Lines

53. Joint Master in Software Engineering  Software product lines are related applications developed around a common core of shared functionality. Software Product Lines Properties

54. Joint Master in Software Engineering Software Product Lines Adaptation Methods  Software product lines can be adapted and configured for use in a specific context.  Adaptation methods: -Component and system configuration -Adding new components to the system -Selecting from a library of existing components -Modifying components to meet new requirements

55. Joint Master in Software Engineering  Architectures must be modularly design, i.e., structured in such a way to separate different sub-systems and to allow them to be modified.  The architecture should also separate entities and their descriptions and the higher levels in the system access entities through descriptions rather than directly. Software Product Lines Architectures

56. Joint Master in Software Engineering  An application family is a set of related applications that has a common core or domain specific architecture  The common core of the application family is reused each time a new application is created  Each member of the family is specialized -platform specialization -configuration specialization -function specialization (based on differences in customer requirements) Software Product Lines Application Families

57. Joint Master in Software Engineering  Architectures must be structured into sub-systems to allow easy modification  Architectures should separate entities from their descriptions  Access to entities must come through their descriptions (interfaces) rather than by direct access Software Product Lines Application Family Architectures

58. Joint Master in Software Engineering Soft. Eng. II, Spring 02 Dr Driss Kettani, from I. Sommerville 58  In component-based development approach systems are developed by integrating components (collections of objects) that conform to component-model standards.  Components may constructed with the explicit goal to allow them to be generalized and reused Component-Based Development

59. Joint Master in Software Engineering Soft. Eng. II, Spring 02 Dr Driss Kettani, from I. Sommerville 59  Extra functionality may have to be added to a component to be made available for reuse  Unneeded functionality may be removed from a component to improve its performance or reduce its space requirements  In case that the original generalization decisions about reusable components may be incorrect, then implementation of some components may have to be modified. Component-Based Development Component Adaptation

60. Joint Master in Software Engineering  Central to reuse  Design for “plug and play”  Object oriented programming is suitable to reuse -Objects are often in reusable component form -Inheritance provides contexts for reuse  Development costs are higher for reusable components than application specific components  Generic components may be less space-efficient and have longer execution times than their application specific analogs Properties of Component-Based Development

61. Joint Master in Software Engineering  Need to give clear descriptions and classifications of components  Need to avoid over generalization  Need to determine component size or granularity  Tradeoff between reusability and usability -generic components can be highly reusable -reusable components are likely to be more complex and harder to use Requirements of Component-Based Development

62. Joint Master in Software Engineering Component-Based Development Procedure Analysis Architectural design  component qualification  component adaptation  component decomposition Components engineering Testing Iterative component update

63. Joint Master in Software Engineering  White-box Wrapping -Reuse with simple modifications of code -integration conflicts removed by making code-level modifications to the code  Grey-box Wrapping -used when component library provides an API that allows conflicts to be removed or hidden  Black-box Wrapping -requires the introduction of pre- and post-processing at the component interface to remove or hide conflicts Component-Based Development Techniques

64. Joint Master in Software Engineering  Application frameworks are collections of concrete and abstract objects that are designed for reuse through specialisation.  Frameworks are sub-system design containing a collection of abstract and concrete classes along with interfaces between each class  A sub-system is implemented by adding components to fill in missing design elements and by instantiating the abstract classes in the framework.  Frameworks are moderately large reusable entities Application Frameworks

65. Joint Master in Software Engineering  System infrastructure frameworks -support development of systems infrastructure elements such as user interfaces or compilers  Middleware integration frameworks -standards and classes that support component communication and information exchange  Enterprise application frameworks -support development of particular applications like telecommunications or financial systems Application Frameworks Classes

66. Joint Master in Software Engineering  Generic frameworks need to be extended to create specific applications or sub-systems  Frameworks can be extend by -defining concrete classes that inherit operations from abstract class ancestors -adding methods that will be called in response to events recognized by the framework Application Extending Frameworks

67. Joint Master in Software Engineering Application Frameworks- Family Member Development Procedure Get requirements Choose closet –fit family member Adapt existing system Deliver new family member

68. Joint Master in Software Engineering  Commercial Off-The-Shelf Systems (COTS) product reuse is concerned with the reuse of large, off-the-shelf systems.  COTS systems are usually complete application systems that offer an API (Application Programming Interface). COTS Product Reuse

69. Joint Master in Software Engineering  Faster application development  Lower development costs. COTS Product Reuse Benefits

70. Joint Master in Software Engineering  Building large systems by integrating COTS components is a viable development strategy for some types of systems such as E-commerce systems.  Enterprise resource planning (ERP) systems are created by configuring a generic system with information about a customer’s business. COTS Product Reuse Key Points

71. Joint Master in Software Engineering  Lack of developer control over functionality and performance  COTS systems may be less effective than they appear  Problems with component interoperability and integration as COTS vendors make different user assumptions  COTS vendors may not offer users any control over the evolutions of its components  Vendors may not offer support over the lifetime of a product built with COTS components COTS Product Reuse Integration Problems

72. Joint Master in Software Engineering  Which COTS products should be used? -There may be several similar products that may be used. -Some products offer more appropriate functionality  How will data be exchanged? -Different products use different data structures and formats.  What features of the COTS product will be used? -Most products have more functionality than is needed. -Developer should not allow access to unused functionality. COTS Product Reuse Design Choices

73. Joint Master in Software Engineering  Platform specialisation -Different versions of the application are developed for different platforms.  Environment specialisation -Different versions of the application are created to handle different operating environments e.g. different types of communication equipment.  Functional specialisation -Different versions of the application are created for customers with different requirements.  Process specialisation -Different versions of the application are created to support different business processes. COTS Product Reuse Specialisation

74. Joint Master in Software Engineering Component-Based Software Engineering Component-Based Software Engineering (CBSE) is an approach to software development that relies on reuse that relies on using components instead of objects.

75. Joint Master in Software Engineering Why Component-Based Software Engineering  CBSE emerged from the failure of object-oriented development to support reuse effectively  Objects (classes) are too specific and too detailed to support design for reuse work  Components are more abstract than classes and can be considered to be stand-alone service providers

76. Joint Master in Software Engineering Reusable components should be designed and built such that:  They are clearly defined  They are designed in open way  They have concise interface specifications  They have understandable documentation  They are designed with an eye towards future use Component-Based Software Engineering Requirements

77. Joint Master in Software Engineering Component-Based Software Engineering Requirements Based on Composition rather than construction  Are commercial off-the-shelf (COTS) components available to implement the requirement?  Are internally developed reusable components available to implement the requirement?  Are the interfaces for available components compatible within in the proposed system architecture? Component-Based Software Engineering Requirements

78. Joint Master in Software Engineering Component-Based Software Engineering Requirements Activities For those requirements that can be addressed with available components the following activities take place:  Component qualification: candidate components are identified based on services provided and means by which consumers access them  Component adaptation: candidate components are modified to meet the needs of the architecture or discarded  Component composition: architecture dictates the composition of the end product from the nature of the connections and coordination mechanisms  Component update: updating systems that include COTS is made more complicated by the fact that a COTS developer must be involved

79. Joint Master in Software Engineering  Functional abstractions -component implements a single function  Data abstractions -Component defines abstract data types or objects  Cluster abstractions -component from group of cooperating objects  System abstraction -component is a self-contained system  Casual groupings -component is part of a loosely related entities like declarations and functions Component-Based Software Engineering Component Abstractions

80. Joint Master in Software Engineering Component-Based Software Engineering Procedure system requirements eliciting Architectural design Define requirements based on composition rather than construction Remove/modify requirements that cannot be implemented with COTS or in-house components

81. Tempus Thank you for your attention.