design with reuse l building software from reusable …scharff/cs389/ref/ch14cs389.pdfl building...

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1

Design with Reuse

l Building software fromreusable components.


Objectives

l To explain the benefits of software reuse andsome reuse problems

l To describe different types of reusablecomponent and processes for reuse

l To introduce application families as a route toreuse

l To describe design patterns as high-levelabstractions that promote reuse


Topics covered

l Component-based development

l Application families

l Design patterns


Software reuse

l In most engineering disciplines, systems aredesigned by composing existing components thathave been used in other systems

l Software engineering has been more focused onoriginal development but it is now recognisedthat to achieve better software, more quickly andat lower cost, we need to adopt a design processthat is based on systematic reuse


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) orby 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


Reuse practice

l Application system reuse• Widely practised as software systems are implemented as

application families. COTS reuse is becoming increasinglycommon

l Component reuse• Now seen as the key to effective and widespread reuse through

component-based software engineering. However, it is stillrelatively immature

l Function reuse• Common in some application domains (e.g. engineering) where

domain-specific libraries of reusable functions have beenestablished


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


Requirements for design with reuse

l It must be possible to find appropriate reusablecomponents

l The reuser of the component must be confidentthat the components will be reliable and willbehave as specified

l The components must be documented so that theycan be understood and, where appropriate,modified


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


Generator-based reuse

l Program generators involve the reuse ofstandard patterns and algorithms

l These are embedded in the generator andparameterised by user commands. A program isthen automatically generated

l Generator-based reuse is possible when domainabstractions and their mapping to executable codecan be identified

l A domain specific language is used to composeand control these abstractions


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 butits applicability is limited to a relatively smallnumber of application domains

l It is easier for end-users to develop programsusing generators compared to other component-based approaches to reuse


Reuse through program generation

Program generator Generated programApplicationdescription

Application domainknowledge Database


Component-based development

l Component-based software engineering (CBSE)is an approach to software development thatrelies on reuse

l It emerged from the failure of object-orienteddevelopment to support effective reuse. Singleobject classes are too detailed and specific

l Components are more abstract than object classesand can be considered to be stand-alone serviceproviders


Components

l Components provide a service without regard towhere the component is executing or itsprogramming 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 arethrough the published interface

l Components can range in size from simplefunctions to entire application systems


Component interfaces

Component Provides interfaceRequires interface


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


Printing services component

Provides interfaceRequires interface

Print

PrintService

GetQueue

Remove

Transfer

Register

Unregister

GetPDfile

PrinterInt


Component abstractionsl 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


CBSE processes

l Component-based development can be integratedinto a standard software process by incorporatinga reuse activity in the process

l However, in reuse-driven development, thesystem requirements are modified to reflect thecomponents that are available

l CBSE usually involves a prototyping or anincremental development process withcomponents being ‘glued together’ using ascripting language


An opportunistic reuse process

Designsystem

aachitecture

Specifycomponents

Search forreusable

components

Incorporatediscoveredcomponents


Development with reuse

Search forreusable

components

Outlinesystem

requirements

Modify requirementsaccording todiscoveredcomponents

Search forreusable

components

Architecturaldesign

Specify systemcomponents

based on reusablecomponents


CBSE problems

l Component incompatibilities may mean that costand schedule savings are less then expected

l Finding and understanding components

l Managing evolution as requirements change insituations where it may be impossible to changethe system components


Application frameworks

l Frameworks are a sub-system design made up ofa collection of abstract and concrete classes andthe interfaces between them

l The sub-system is implemented by addingcomponents to fill in parts of the design and byinstantiating the abstract classes in the framework

l Frameworks are moderately large entities that canbe reused


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


Extending frameworks

l Frameworks are generic and are extended tocreate 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 arerecognised by the framework

l Problem with frameworks is their complexity andthe time it takes to use them effectively


Model-view controller

l System infrastructure framework for GUI design

l Allows for multiple presentations of an objectand separate interactions with these presentations

l MVC framework involves the instantiation of anumber of patterns (discussed later)


Model-view controller

Model state

Model methods

Controller state

Controller methods

View state

View methods

User inputsview modification

messages

Model editsModel queries

and updates


COTS product reuse

l COTS - Commercial Off-The-Shelf systems

l COTS systems are usually complete applicationsystems that offer an API (ApplicationProgramming Interface)

l Building large systems by integrating COTSsystems is now a viable development strategy forsome types of system such as E-commercesystems


COTS system integration problems

l Lack of control over functionality andperformance• 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


Component development for reuse

l Components for reuse may be speciallyconstructed 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 andusability.• The more general the interface, the greater the reusability but it

is then more complex and hence less usable


Reusable components

l The development cost of reusable components ishigher than the cost of specific equivalents. Thisextra reusability enhancement cost should be anorganization rather than a project cost

l Generic components may be lessspace-efficient and may have longer executiontimes than their specific equivalents


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


Reusability enhancement process

Namegeneralization

Operationgeneralization

Exceptiongeneralization

Componentcertification

Reusablecomponent

Initialcomponent


Application families

l An application family or product line is a relatedset of applications that has a common, domain-specific architecture

l The common core of the application family isreused each time a new application is required

l Each specific application is specialised in someway


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


A resource management system

Resource database

Resource desc. Screen spec. Report spec.

Add Delete Query Browse Admin Report

User access Program access


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


Application family architectures

l Architectures must be structured in such a way toseparate different sub-systems and to allow themto be modified

l The architecture should also separate entities andtheir descriptions and the higher levels in thesystem access entities through descriptions ratherthan directly


A library system

Library holdings database

Resource desc. Screen spec. Report spec.

Add Delete Query Browse Admin Report

Library user access

Issue Return Users


Library system

l The resources being managed are the books in thelibrary

l Additional domain-specific functionality (issue,borrow, etc.) must be added for this application


Family member development

Elicitstakeholderrequirements

Choose closest-fit familymember Deliver new

family member

Re-negotiaterequirements

Adapt existingsystem


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


Design patterns

l A design pattern is a way of reusing abstractknowledge about a problem and its solution

l A pattern is a description of the problem and theessence of its solution

l It should be sufficiently abstract to be reused indifferent settings

l Patterns often rely on object characteristics suchas inheritance and polymorphism


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


Multiple displays

Subject

A: 40B: 25C: 15D: 20

Observer 1 Observer 2

0

50

25

A B C D

A

B

C

D


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


The Observer pattern

Subject Observer

Attach (Observer)Detach (Observer)Notify ()

Update ()

ConcreteSubject

GetState ()

subjectState

ConcreteObserver

Update ()

observerState

return subjectState

for all o in observers o -> Update ()

observerState = subject -> GetState ()


l Design with reuse involves designing softwarearound good design and existing components

l Advantages are lower costs, faster softwaredevelopment and lower risks

l Component-based software engineering relies onblack-box components with defined requires andprovides interfaces

l COTS product reuse is concerned with the reuseof large, off-the-shelf systems

Key points


Key points

l Software components for reuse should beindependent, should reflect stable domainabstractions and should provide access to statethrough interface operations

l Application families are related applicationsdeveloped around a common core

l Design patterns are high-level abstractions thatdocument successful design solutions

design with reuse l building software from reusable …scharff/cs389/ref/ch14cs389.pdfl building...

Documents