1 / 67

Software Reuse

Software Reuse. Objectives. To explain the benefits of software reuse and some reuse problems To give an overview of the software reuse landscape To introduce component-based software engineering. Topics covered. The reuse landscape Design patterns Generator based reuse

alva
Download Presentation

Software Reuse

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Reuse

  2. Objectives • To explain the benefits of software reuse and some reuse problems • To give an overview of the software reuse landscape • To introduce component-based software engineering

  3. Topics covered • The reuse landscape • Design patterns • Generator based reuse • Application frameworks • Application system reuse • Component-based software engineering

  4. Software reuse • In most engineering disciplines, systems are designed by composing existing reusable components. • Software engineering has been more focused on custom development. • To achieve better software, more quickly and at lower cost, we need to adopt a design process that is based on systematic software reuse.

  5. Reuse benefits 1

  6. Reuse benefits 2

  7. Barriers to widespread reuse

  8. Barriers to widespread reuse

  9. Ariane launcher failure In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster when the launcher went out of control 37 seconds after take off. Photos from: Wikipedia and http://www3.imperial.ac.uk/spat/research/space_missions/cluster/history

  10. Ariane launcher failure • The problem was due to a reused component from Ariane 4. • Component failed because assumptions made for Ariane 4 did not hold for Ariane 5. • Floating point to integer conversion of thrust value caused overflow and triggered an unhandled exception that shut down the Inertial Navigation System. • The value stored in Ariane 4 was never large enough to cause overflow. • The functionality that failed in this component was not required in Ariane 5.

  11. The reuse landscape • Although reuse is often simply thought of as the reuse of system components, 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.

  12. The reuse landscape

  13. Reuse approaches 1

  14. Reuse approaches 2

  15. Topics covered • The reuse landscape • Design patterns • Generator based reuse • Application frameworks • Application system reuse • Component-based software engineering

  16. 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. • The two main approaches to concept reuse are: • Design patterns; • Generative programming.

  17. Design patterns • A design pattern is a way of reusing abstract knowledge about a problem and its solution. • A pattern is a description of the problem and the essence of its solution. • It should be sufficiently abstract to be reused in different settings. • Patterns often rely on object characteristics such as inheritance and polymorphism.

  18. Pattern elements • Name • A meaningful pattern identifier. • Problem description. • Solution description. • Not a concrete design but a template for a design solution that can be instantiated in different ways. • Consequences • The results and trade-offs of applying the pattern.

  19. Multiple displays

  20. The Observer pattern • 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 slide with UML description. • Consequences • Optimisations to enhance display performance are impractical.

  21. The Observer pattern

  22. Other examples • Structural Patterns • Focus: How objects are composed to form larger structures • Examples: composite, adapter, bridge, proxy • Behavioral Patterns • Focus: Algorithms and the assignment of responsibilities to objects • Examples: command, observer, strategy • Creational Patterns • Focus: Creation of complex objects • Examples: abstract factory, builder

  23. Topics covered • The reuse landscape • Design patterns • Generator based reuse • Application frameworks • Application system reuse • Component-based software engineering

  24. Generator-based reuse • Program generators involve the reuse of standard patterns and algorithms. • These 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.

  25. Examples of program generators • Examples • Application generators for business data processing; • Parser and lexical analyser generators for language processing; • Code generators in CASE tools. • Generator-based reuse is very cost-effective but its applicability is limited to a relatively small number of application domains. • It is easier for end-users to develop programs using generators compared to other component-based approaches to reuse.

  26. A pplica tion Pr o g r am gener a tor Gener a ted pr o g r am description A pplica tion domain Da ta base kno wledge Reuse through program generation

  27. Aspect-oriented development • Aspect-oriented programming can be seen as another example of generative programming • Aspect-oriented development addresses a major software engineering problem - the separation of concerns. • Crosscutting concerns – functionality that cuts across multiple components, e.g., logging, security checking, etc. • Cross-cutting concerns are implemented as reusable aspects. • The new system is generated by an aspect weaver.

  28. Aspect-oriented development

  29. Topics covered • The reuse landscape • Design patterns • Generator based reuse • Application frameworks • Application system reuse • Component-based software engineering

  30. Application frameworks • Frameworks are (incomplete) sub-system designs made up of a collection of abstract and concrete classes and the interfaces between them. • Frameworks are moderately large entities that can be reused.

  31. Examples of frameworks • System infrastructure frameworks • Support the development of system infrastructures such as communications, user interfaces and compilers. • Most generic. • Example: Java Swing • Middleware integration frameworks • Standards and classes that support component communication and information exchange. • Example: Enterprise Java Beans • Enterprise application frameworks • Support the development of specific types of application such as telecommunications or financial systems. • Most domain-specific.

  32. Extending frameworks • Extending the framework involves • Adding concrete classes that inherit operations from abstract classes in the framework; • Adding methods that are called in response to events that are recognised by the framework. • Problem with frameworks is their complexity which means that it takes a long time to use them effectively.

  33. Topics covered • The reuse landscape • Design patterns • Generator based reuse • Application frameworks • Application system reuse • Component-based software engineering

  34. Application system reuse • Involves the reuse of entire application systems either by configuring a system for an environment or by integrating two or more systems to create a new application. • Two types: • COTS product integration; • Product line development.

  35. Topics covered • The reuse landscape • Design patterns • Generator based reuse • Application frameworks • Application system reuse • Component-based software engineering

  36. Component-based software engineering (CBSE) • Components and component models • The CBSE process • Component composition • Interface specification

  37. CBSE essentials • Independent components specified by their interfaces. • Component standards to facilitate component integration. • Middleware that provides support for component inter-operability. • A development process that is geared to reuse.

  38. CBSE and design principles • Apart from the benefits of reuse, CBSE is based on sound software engineering design principles: • Components are independent so do not interfere with each other; • Component implementations are hidden; • Communication is through well-defined interfaces; • Component platforms are shared and reduce development costs.

  39. CBSE problems • Component trustworthiness - how can a component with no available source code be trusted? • Component certification - who will certify the quality of components? • Emergent property prediction - how can the emergent properties of component compositions be predicted? • Requirements trade-offs - how do we do trade-off analysis between the features of one component and another?

  40. Components • Components provide a service without regard to where the component is executing or its programming language • A component is an independent executable entity that can be made up of one or more executable objects; • The component interface is published and all interactions are through the published interface; • Components are more abstract than object classes and can be considered to be stand-alone service providers.

  41. Component interfaces • Provides interface • Defines the services that are provided by the component to other components. • Requires interface • Defines the services that specifies what services must be made available for the component to execute as specified.

  42. Requires interface Provides interface Defines the services Defines the services that are provided from the component’s Component by the component environment that it to other components uses Component interfaces

  43. A data collector component

  44. Issues with reusable components • Higher cost of developing reusable components. • This extra cost should be an organization rather than a project cost. • Performance issues. • Generic components may be less space-efficient and may have longer execution times than their specific equivalents.

  45. Component-based software engineering (CBSE) • Components and component models • The CBSE process • Component composition • Interface specification

  46. The CBSE process • When reusing components, it is essential to make trade-offs between ideal requirements and the services actually provided by available components. • This involves: • Developing outline requirements; • Searching for components then modifying requirements according to available functionality. • Searching again to find if there are better components that meet the revised requirements.

  47. The CBSE process

  48. The component identification process

  49. Component identification issues • Trust. You need to be able to trust the supplier of a component. At best, an untrusted component may not operate as advertised; at worst, it can breach your security. • Requirements. Different groups of components will satisfy different requirements. • Validation. • The component specification may not be detailed enough to allow comprehensive tests to be developed. • Components may have unwanted functionality. How can you test this will not interfere with your application?

  50. Component-based software engineering (CBSE) • Components and component models • The CBSE process • Component composition • Interface specification

More Related