Lectures Software Engineering - Chapter 14: Design with Reuse

49 trang hoanguyen 3860

Download

Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 14: Design with Reuse", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

lectures_software_engineering_chapter_14_design_with_reuse.ppt

Nội dung text: Lectures Software Engineering - Chapter 14: Design with Reuse

Design with Reuse l Building software from reusable components. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1
Objectives l To explain the benefits of software reuse and some reuse problems l To describe different types of reusable component 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 14 Slide 2
Topics covered l Component-based development l Application families l Design patterns ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 3
Software reuse l In most engineering disciplines, systems are designed by composing existing components that have been used in other systems l Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, we need to adopt a design process that is based on systematic reuse ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 4
Reuse-based software engineering l Application system reuse • The whole of an application system may be reused either by incorporating it without change into other systems (COTS reuse) or by developing application families l Component reuse • Components of an application from sub-systems to single objects may be reused l Function reuse • Software components that implement a single well-defined function may be reused ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 5
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. However, it is still relatively immature l Function reuse • Common in some application domains (e.g. engineering) where domain-specific libraries of reusable functions have been established ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 6
Benefits of reuse l Increased reliability • Components exercised in working systems l Reduced process risk • Less uncertainty in development costs l Effective use of specialists • Reuse components instead of people l Standards compliance • Embed standards in reusable components l Accelerated development • Avoid original development and hence speed-up production ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 7
Requirements for design with reuse l It must be possible to find appropriate reusable components l The reuser of the component must be confident that the components will be reliable and will behave as specified l The components must be documented so that they can be understood and, where appropriate, modified ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 8
Reuse problems l Increased maintenance costs l Lack of tool support l Not-invented-here syndrome l Maintaining a component library l Finding and adapting reusable components ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 9
Generator-based reuse l Program generators involve the reuse of standard patterns and algorithms l These are embedded in the generator and parameterised by user commands. A program is then automatically generated l Generator-based reuse is possible when domain abstractions and their mapping to executable code can be identified l A domain specific language is used to compose and control these abstractions ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 10
Types of program generator l Types of program generator • Application generators for business data processing • Parser and lexical analyser generators for language processing • Code generators in CASE tools l Generator-based reuse is very cost-effective but its applicability is limited to a relatively small number of application domains l It is easier for end-users to develop programs using generators compared to other component- based approaches to reuse ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 11
Component-based development l Component-based software engineering (CBSE) is an approach to software development that relies on reuse l It emerged from the failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific l Components are more abstract than object classes and can be considered to be stand-alone service providers ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 13
Components l 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 l Components can range in size from simple functions to entire application systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 14
Component interfaces l Provides interface • Defines the services that are provided by the component to other components l Requires interface • Defines the services that specifies what services must be made available for the component to execute as specified ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 16
Component abstractions l Functional abstraction • The component implements a single function such as a mathematical function l Casual groupings • The component is a collection of loosely related entities that might be data declarations, functions, etc. l Data abstractions • The component represents a data abstraction or class in an object-oriented language l Cluster abstractions • The component is a group of related classes that work together l System abstraction • The component is an entire self-contained system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 18
CBSE processes l Component-based development can be integrated into a standard software process by incorporating a reuse activity in the process l However, in reuse-driven development, the system requirements are modified to reflect the components that are available l CBSE usually involves a prototyping or an incremental development process with components being ‘glued together’ using a scripting language ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 19
CBSE problems l Component incompatibilities may mean that cost and schedule savings are less then expected l Finding and understanding components l Managing evolution as requirements change in situations where it may be impossible to change the system components ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 22
Application frameworks l Frameworks are a sub-system design made up of a collection of abstract and concrete classes and the interfaces between them l The sub-system is implemented by adding components to fill in parts of the design and by instantiating the abstract classes in the framework l Frameworks are moderately large entities that can be reused ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 23
Framework classes l System infrastructure frameworks • Support the development of system infrastructures such as communications, user interfaces and compilers l Middleware integration frameworks • Standards and classes that support component communication and information exchange l Enterprise application frameworks • Support the development of specific types of application such as telecommunications or financial systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 24
Extending frameworks l Frameworks are generic and are extended to create a more specific application or sub-system l 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 l Problem with frameworks is their complexity and the time it takes to use them effectively ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 25
Model-view controller l System infrastructure framework for GUI design l Allows for multiple presentations of an object and separate interactions with these presentations l MVC framework involves the instantiation of a number of patterns (discussed later) ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 26
COTS product reuse l COTS - Commercial Off-The-Shelf systems l COTS systems are usually complete application systems that offer an API (Application Programming Interface) l Building large systems by integrating COTS systems is now a viable development strategy for some types of system such as E-commerce systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 28
COTS system integration problems l Lack of control over functionality and performance • COTS systems may be less effective than they appear l Problems with COTS system inter-operability • Different COTS systems may make different assumptions that means integration is difficult l No control over system evolution • COTS vendors not system users control evolution l Support from COTS vendors • COTS vendors may not offer support over the lifetime of the product ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 29
Component development for reuse l Components for reuse may be specially constructed by generalising existing components l Component reusability • Should reflect stable domain abstractions • Should hide state representation • Should be as independent as possible • Should publish exceptions through the component interface l There is a trade-off between reusability and usability. • The more general the interface, the greater the reusability but it is then more complex and hence less usable ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 30
Reusable components l The development cost of reusable components is higher than the cost of specific equivalents. This extra reusability enhancement cost should be an organization rather than a project cost l Generic components may be less space-efficient and may have longer execution times than their specific equivalents ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 31
Reusability enhancement l Name generalisation • Names in a component may be modified so that they are not a direct reflection of a specific application entity l Operation generalisation • Operations may be added to provide extra functionality and application specific operations may be removed l Exception generalisation • Application specific exceptions are removed and exception management added to increase the robustness of the component l Component certification • Component is certified as reusable ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 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 specialised in some way ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 34
Application family specialisation l Platform specialisation • Different versions of the application are developed for different platforms l Configuration specialisation • Different versions of the application are created to handle different peripheral devices l Functional specialisation • Different versions of the application are created for customers with different requirements ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 35
Inventory management systems l Resource database • Maintains details of the things that are being managed l I/O descriptions • Describes the structures in the resource database and input and output formats that are used l Query level • Provides functions implementing queries over the resources l Access interfaces • A user interface and an application programming interface ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 37
Application family architectures l Architectures must be structured in such a way to separate different sub-systems and to allow them to be modified l The architecture should also separate entities and their descriptions and the higher levels in the system access entities through descriptions rather than directly ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 38
Library system l The resources being managed are the books in the library l Additional domain-specific functionality (issue, borrow, etc.) must be added for this application ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 40
Family member development l Elicit stakeholder requirements • Use existing family member as a prototype l Choose closest-fit family member • Find the family member that best meets the requirements l Re-negotiate requirements • Adapt requirements as necessary to capabilities of the software l Adapt existing system • Develop new modules and make changes for family member l Deliver new family member • Document key features for further member development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 42
Design patterns l A design pattern is a way of reusing abstract knowledge about a problem and its solution l A pattern is a description of the problem and the essence of its solution l It should be sufficiently abstract to be reused in different settings l Patterns often rely on object characteristics such as inheritance and polymorphism ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 43
Pattern elements l Name • A meaningful pattern identifier l Problem description l Solution description • Not a concrete design but a template for a design solution that can be instantiated in different ways l Consequences • The results and trade-offs of applying the pattern ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 44
The Observer pattern 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 slide with UML description l Consequences • Optimisations to enhance display performance are impractical ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 46
Key points l Design with reuse involves designing software around good design and existing components l Advantages are lower costs, faster software development and lower risks l Component-based software engineering relies on black-box components with defined requires and provides interfaces l COTS product reuse is concerned with the reuse of large, off-the-shelf systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 48
Key points l Software components for reuse should be independent, should reflect stable domain abstractions and should provide access to state through interface operations l Application families are related applications developed around a common core l Design patterns are high-level abstractions that document successful design solutions ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 49