Software Reuse - Ian Sommerville

Software Reuse©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Objectives●●●●●To explain the benefits of software reuse andsome reuse problemsTo discuss several different ways toimplement software reuseTo explain how reusable concepts can berepresented as patterns or embedded inprogram generatorsTo discuss COTS reuseTo describe the development of softwareproduct lines©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 2

Topics covered●●●●●The reuse landscapeDesign patternsGenerator based reuseApplication frameworksApplication system reuse©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 3

Reuse-based software engineering●●●Application system reuse• The whole of an application system may be reusedeither by incorporating it without change into othersystems (COTS reuse) or by developing applicationfamilies.Component reuse• Components of an application from sub-systems tosingle objects may be reused. Covered in Chapter 19.Object and function reuse• Software components that implement a single welldefinedobject or function may be reused.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 5

Reuse benefits 1Increased dependabilityReduced process riskEffective use of specialistsReused software, that has been tried and tested in working systems,should be m ore dependable than new software. The initial use of thesoftware reveals any design and implementation faults. These are thenfixed, thus reducing the number of failures when the software is reused.If software exists, there is less uncertainty in the costs of reusing thatsoftware than in the costs of development. This is an important factorfor project management as it reduces the margin of error in project costestimation. This is particularly true when relatively large softwarecomponents such as sub-systems are reused.Instead of application specialists doing the same work on differentprojects, these specialists can develop reusable software thatencapsulate their knowledge.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 6

Reuse benefits 2Standards complianceAccelerated developmentSome standards, such as user interface standards, can beimplemented as a set of standard reusable components. Forexample, if menus in a user interfaces are implemented usingreusable components, all applications present the same menuformats to users. The use of standard user interfaces improvesdependability as users are less likely to make mistakes whenpresented with a familiar interface.Bringing a system to market as early as possible is o ften moreimportant than overall development costs. Reusing software canspeed up system production because both development andvalidation time should be reduced.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 7

Reuse problems 1Increased maintenancecostsLack of tool supportNot-invented-heresyndromeIf the source code of a reused software system or component is n otavailable then maintenance costs may be increased as the reusedelements of the system may become increasingly incompatible withsystem changes.CASE toolsets may not support development with reuse. It may bedifficult or impossible to integrate these tools with a componentlibrary system. The software process assumed by these tools may nottake reuse into account.Some software engineers sometimes prefer to re-write components asthey believe that they can improve on the reusable component. This ispartly to do with trust and partly to do with the fact that writingoriginal software is s een as more challenging than reusing otherpeople’s software.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 8

Reuse problems 2Creating and maintaining acomponent libraryFinding, understanding andadapting reusable componentsPopulating a reusable component library and ensuring the softwaredevelopers can use this library can be expensive. Our current techniquesfor classifying, cataloguing and retrieving software components areimmature.Software components have to be discovered in a library, understood and,sometimes, adapted to work in a n ew environment. Engineers must bereasonably confident of finding a component in the library before they willmake routinely include a component search as part of their normaldevelopment process.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 9

The reuse landscape●●●Although reuse is often simply thought of asthe reuse of system components, there aremany different approaches to reuse that maybe used.Reuse is possible at a range of levels fromsimple functions to complete applicationsystems.The reuse landscape covers the range ofpossible reuse techniques.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 10

The reuse landscape©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 11

Reuse approaches 1Design patternsComponent-baseddevelopmentApplicationframeworksLegacy systemwrappingService-orientedsystemsGeneric abstractions that occur across applications arerepresented as design patterns that show abstract and concreteobjects and interactions.Systems are developed by integrating components(collections of objects) that conform to component-modelstandards. This is covered in Chapter 19.Collections of abstract and concrete classes that can beadapted and extended to create application systems.Legacy systems (see Chapter 2) that can be ‘wrapped’ bydefining a set of interfaces and providing access to theselegacy systems through these interfaces.Systems are developed by linking shared services that may beexternally provided.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 12

Reuse approaches 2Application productlinesCOTS integrationConfigurable verticalapplicationsProgram librariesProgram generatorsAspect-orientedsoftware developmentAn application type is generalised around a commonarchitecture so that it can be adapted in different ways fordifferent customers.Systems are developed by integrating existing applicationsystems.A generic system is designed so that it can be configured tothe needs of specific system customers.Class and function libraries implementing commonly-usedabstractions are available for reuse.A generator system embeds knowledge of a particular typesof application and can generate systems or system fragmentsin that domain.Shared components are woven into an application at differentplaces when the program is compiled.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 13

Reuse planning factors●●●●●●The development schedule for the software.The expected software lifetime.The background, skills and experience of thedevelopment team.The criticality of the software and its nonfunctionalrequirements.The application domain.The execution platform for the software.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 14

Concept reuse●●●●When you reuse program or design components,you have to follow the design decisions made bythe original developer of the component.This may limit the opportunities for reuse.However, a more abstract form of reuse is conceptreuse when a particular approach is described inan implementation independent way and animplementation is then developed.The two main approaches to concept reuse are:• Design patterns;• Generative programming.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 15

Design patterns●●●●A design pattern is a way of reusing abstractknowledge about a problem and its solution.A pattern is a description of the problem andthe essence of its solution.It should be sufficiently abstract to be reusedin different settings.Patterns often rely on object characteristicssuch as inheritance and polymorphism.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 16

Pattern elements●●●●Name• A meaningful pattern identifier.Problem description.Solution description.• Not a concrete design but a template for a designsolution that can be instantiated in different ways.Consequences• The results and trade-offs of applying the pattern.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 17

Multiple displays©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 18

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 areimpractical.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 19

The Observer pattern©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 20

Generator-based reuse●●●●Program generators involve the reuse ofstandard patterns and algorithms.These are embedded in the generator andparameterised by user commands. A programis then automatically generated.Generator-based reuse is possible whendomain abstractions and their mapping toexecutable code can be identified.A domain specific language is used tocompose and control these abstractions.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 21

Types of program generator●●●Types of program generator• Application generators for business data processing;• Parser and lexical analyser generators for languageprocessing;• Code generators in CASE tools.Generator-based reuse is very cost-effective but itsapplicability is limited to a relatively small number ofapplication domains.It is easier for end-users to develop programs usinggenerators compared to other component-basedapproaches to reuse.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 22

Reuse through program generation©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 23

Aspect-oriented development●●●Aspect-oriented development addresses a majorsoftware engineering problem - the separation ofconcerns.Concerns are often not simply associated withapplication functionality but are cross-cutting - e.g. allcomponents may monitor their own operation, allcomponents may have to maintain security, etc.Cross-cutting concerns are implemented as aspectsand are dynamically woven into a program. Theconcern code is reuse and the new system isgenerated by the aspect weaver.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 24

Aspect-oriented development©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 25

Application frameworks●●●Frameworks are a sub-system design madeup of a collection of abstract and concreteclasses and the interfaces between them.The sub-system is implemented by addingcomponents to fill in parts of the design and byinstantiating the abstract classes in theframework.Frameworks are moderately large entities thatcan be reused.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 26

Framework classes●●●System infrastructure frameworks• Support the development of system infrastructuressuch as communications, user interfaces andcompilers.Middleware integration frameworks• Standards and classes that support componentcommunication and information exchange.Enterprise application frameworks• Support the development of specific types ofapplication such as telecommunications orfinancial systems.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 27

Extending frameworks●●●Frameworks are generic and are extended to create amore specific application or sub-system.Extending the framework involves• Adding concrete classes that inherit operations fromabstract classes in the framework;• Adding methods that are called in response to eventsthat are recognised by the framework.Problem with frameworks is their complexity whichmeans that it takes a long time to use them effectively.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 28

Model-view controller●●●System infrastructure framework for GUIdesign.Allows for multiple presentations of an objectand separate interactions with thesepresentations.MVC framework involves the instantiation of anumber of patterns (as discussed earlier underconcept reuse).©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 29

Model-view-controller©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 30

Application system reuse●●Involves the reuse of entire applicationsystems either by configuring a systemfor an environment or by integratingtwo or more systems to create a newapplication.Two approaches covered here:• COTS product integration;• Product line development.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 31

COTS product reuse●●●●COTS - Commercial Off-The-Shelf systems.COTS systems are usually completeapplication systems that offer an API(Application Programming Interface).Building large systems by integrating COTSsystems is now a viable developmentstrategy for some types of system such as E-commerce systems.The key benefit is faster applicationdevelopment and, usually, lowerdevelopment costs.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 32

COTS design choices●●●Which COTS products offer the most appropriatefunctionality?• There may be several similar products that may beused.How will data be exchanged?• Individual products use their own data structures andformats.What features of the product will actually be used?• Most products have more functionality than is needed.You should try to deny access to unused functionality.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 33

E-procurement system©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 34

COTS products reused●●On the client, standard e-mail and webbrowsing programs are used.On the server, an e-commerce platform has tobe integrated with an existing ordering system.• This involves writing an adaptor so that they canexchange data.• An e-mail system is also integrated to generate e-mail for clients. This also requires an adaptor toreceive data from the ordering and invoicingsystem.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 35

COTS system integration problems●●●●Lack of control over functionality and performance• COTS systems may be less effective than they appearProblems with COTS system inter-operability• Different COTS systems may make differentassumptions that means integration is difficultNo control over system evolution• COTS vendors not system users control evolutionSupport from COTS vendors• COTS vendors may not offer support over the lifetimeof the product©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 36

Software product lines●●Software product lines or application families areapplications with generic functionality that can beadapted and configured for use in a specificcontext.Adaptation may involve:• Component and system configuration;• Adding new components to the system;• Selecting from a library of existing components;• Modifying components to meet new requirements.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 37

COTS product specialisation●●●●Platform specialisation• Different versions of the application are developed fordifferent platforms.Environment specialisation• Different versions of the application are created tohandle different operating environments e.g. differenttypes of communication equipment.Functional specialisation• Different versions of the application are created forcustomers with different requirements.Process specialisation• Different versions of the application are created tosupport different business processes.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 38

COTS configuration●●Deployment time configuration• A generic system is configured by embeddingknowledge of the customer’s requirements andbusiness processes. The software itself is notchanged.Design time configuration• A common generic code is adapted and changedaccording to the requirements of particularcustomers.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 39

ERP system organisation©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 40

ERP systems●●●An Enterprise Resource Planning (ERP)system is a generic system that supportscommon business processes such as orderingand invoicing, manufacturing, etc.These are very widely used in largecompanies - they represent probably the mostcommon form of software reuse.The generic core is adapted by includingmodules and by incorporating knowledge ofbusiness processes and rules.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 41

Design time configuration●●Software product lines that are configured atdesign time are instantiations of genericapplication architectures as discussed inChapter 13.Generic products usually emerge afterexperience with specific products.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 42

Product line architectures●●Architectures must be structured in such a wayto separate different sub-systems and to allowthem to be modified.The architecture should also separate entitiesand their descriptions and the higher levels inthe system access entities throughdescriptions rather than directly.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 43

A resource management system©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 44

Vehicle despatching●●A specialised resource management system where the aimis to allocate resources (vehicles) to handle incidents.Adaptations include:• At the UI level, there are components for operator displayand communications;• At the I/O management level, there are components thathandle authentication, reporting and route planning;• At the resource management level, there are components forvehicle location and despatch, managing vehicle status andincident logging;• The database includes equipment, vehicle and mapdatabases.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 45

A despatching system©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 46

Product instance development©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 47

Product instance development●●●●●Elicit stakeholder requirements• Use existing family member as a prototypeChoose closest-fit family member• Find the family member that best meets therequirementsRe-negotiate requirements• Adapt requirements as necessary to capabilities of thesoftwareAdapt existing system• Develop new modules and make changes for familymemberDeliver new family member• Document key features for further memberdevelopment©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 48

Key points●●●●Advantages of reuse are lower costs, faster softwaredevelopment and lower risks.Design patterns are high-level abstractions thatdocument successful design solutions.Program generators are also concerned with softwarereuse - the reusable concepts are embedded in agenerator system.Application frameworks are collections of concrete andabstract objects that are designed for reuse throughspecialisation.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 49

Key points●●●●COTS product reuse is concerned with the reuse oflarge, off-the-shelf systems.Problems with COTS reuse include lack of control overfunctionality, performance, and evolution and problemswith inter-operation.ERP systems are created by configuring a genericsystem with information about a customer’s business.Software product lines are related applicationsdeveloped around a common core of sharedfunctionality.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 50