Transcription
Component-based softwareengineering Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 1
Objectives To explain that CBSE is concerned withdeveloping standardised components andcomposing these into applicationsTo describe components and componentmodelsTo show the principal activities in the CBSEprocessTo discuss approaches to componentcomposition and problems that may arise Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 2
Topics covered Components and component modelsThe CBSE processComponent composition Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 3
Component-based development Component-based software engineering(CBSE) is an approach to softwaredevelopment that relies on software reuse.It emerged from the failure of object-orienteddevelopment to support effective reuse.Single object classes are too detailed andspecific.Components are more abstract than objectclasses and can be considered to be standalone service providers. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 4
CBSE essentials Independent components specified by theirinterfaces.Component standards to facilitatecomponent integration.Middleware that provides support forcomponent inter-operability.A development process that is geared toreuse. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 5
CBSE and design principles Apart from the benefits of reuse, CBSE isbased on sound software engineering designprinciples: Components are independent so do notinterfere with each other;Component implementations are hidden;Communication is through well-definedinterfaces;Component platforms are shared and reducedevelopment costs. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 6
CBSE problems Component trustworthiness - how can a componentwith no available source code be trusted?Component certification - who will certify the qualityof components?Emergent property prediction - how can theemergent properties of component compositions bepredicted?Requirements trade-offs - how do we do trade-offanalysis between the features of one componentand another? Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 7
Components Components provide a service withoutregard to where the component is executingor its programming language A component is an independent executableentity that can be made up of one or moreexecutable objects;The component interface is published and allinteractions are through the published interface; Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 8
Component definitions Councill and Heinmann: A software component is a software element thatconforms to a component model and can beindependently deployed and composed withoutmodification according to a composition standard.Szyperski: A software component is a unit of composition withcontractually specified interfaces and explicit contextdependencies only. A software component can bedeployed independently and is subject to composition bythird-parties. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 9
Component as a service provider The component is an independent,executable entity. It does not have to becompiled before it is used with othercomponents.The services offered by a component aremade available through an interface and allcomponent interactions take place throughthat interface. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 10
Component characteristics 1StandardisedComponent standardisation means that a component that isused in a CBSE process has to conform to some standardisedcomponent model. This model may define componentinterfaces, component meta-data, documentation, compositionand deployment.IndependentA component should be independent – it should be possible tocompose and deploy it without having to use other specificcomponents. In situations where the component needsexternally provided services, these should be explicitly set outin a ‘requires’ interface specification.ComposableFor a component to be composable, all external interactionsmust take place through publicly defined interfaces. Inaddition, it must provide external access to information aboutitself such as its methods and attributes. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 11
Component characteristics 2DeployableTo be deployable, a component has to be self-contained andmust be able to operate as a stand-alone entity on somecomponent platform that implements the component model.This usually means that the component is a binary componentthat does not have to be compiled before it is deployed.DocumentedComponents have to be fully documented so that potentialusers of the component can decide whether or not they meettheir needs. The syntax and, ideally, the semantics of allcomponent interfaces have to be specified. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 12
Component interfaces Provides interface Defines the services that are provided by thecomponent to other components.Requires interface Defines the services that specifies whatservices must be made available for thecomponent to execute as specified. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 13
Component interfaces Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 14
A data collector component Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 15
Components and objects Components are deployable entities.Components do not define types.Component implementations are opaque.Components are language-independent.Components are standardised. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 16
Component models A component model is a definition of standards forcomponent implementation, documentation anddeployment.Examples of component models EJB model (Enterprise Java Beans)COM model (.NET model)Corba Component ModelThe component model specifies how interfacesshould be defined and the elements that should beincluded in an interface definition. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 17
Elements of a component model Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 18
Middleware support Component models are the basis for middlewarethat provides support for executing components.Component model implementations provide: Platform services that allow components writtenaccording to the model to communicate;Horizontal services that are application-independentservices used by different components.To use services provided by a model, componentsare deployed in a container. This is a set ofinterfaces used to access the serviceimplementations. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 19
Component model services Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 20
Component development for reuse Components developed for a specificapplication usually have to be generalised tomake them reusable.A component is most likely to be reusable if itassociated with a stable domain abstraction(business object).For example, in a hospital stable domainabstractions are associated with thefundamental purpose - nurses, patients,treatments, etc. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 21
Component development for reuse Components for reuse may be specially constructed bygeneralising existing components.Component reusability Should reflect stable domain abstractions;Should hide state representation;Should be as independent as possible;Should publish exceptions through the componentinterface.There is a trade-off between reusability and usability The more general the interface, the greater the reusabilitybut it is then more complex and hence less usable. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 22
Changes for reusability Remove application-specific methods.Change names to make them general.Add methods to broaden coverage.Make exception handling consistent.Add a configuration interface for componentadaptation.Integrate required components to reducedependencies. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 23
Legacy system components Existing legacy systems that fulfil a usefulbusiness function can be re-packaged ascomponents for reuse.This involves writing a wrapper componentthat implements provides and requiresinterfaces then accesses the legacy system.Although costly, this can be much lessexpensive than rewriting the legacy system. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 24
Reusable components The development cost of reusablecomponents may be higher than the cost ofspecific equivalents. This extra reusabilityenhancement cost should be an organizationrather than a project cost.Generic components may be lessspace-efficient and may have longerexecution times than their specificequivalents. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 25
The CBSE process When reusing components, it is essential tomake trade-offs between ideal requirementsand the services actually provided byavailable components.This involves: Developing outline requirements;Searching for components then modifyingrequirements according to availablefunctionality.Searching again to find if there are bettercomponents that meet the revisedrequirements. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 26
The CBSE process Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 27
The component identification process Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 28
Component identification issues Trust. You need to be able to trust the supplier of acomponent. At best, an untrusted component maynot operate as advertised; at worst, it can breachyour security.Requirements. Different groups of components willsatisfy different requirements.Validation. The component specification may not be detailed enoughto allow comprehensive tests to be developed.Components may have unwanted functionality. How canyou test this will not interfere with your application? Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 29
Ariane launcher failure In 1996, the 1st test flight of the Ariane 5 rocketended in disaster when the launcher went out ofcontrol 37 seconds after take off.The problem was due to a reused component from aprevious version of the launcher (the InertialNavigation System) that failed because assumptionsmade when that component was developed did nothold for Ariane 5.The functionality that failed in this component wasnot required in Ariane 5. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 30
Component composition The process of assembling components tocreate a system.Composition involves integratingcomponents with each other and with thecomponent infrastructure.Normally you have to write ‘glue code’ tointegrate components. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 31
Types of composition Sequential composition where the composedcomponents are executed in sequence. Thisinvolves composing the provides interfaces of eachcomponent.Hierarchical composition where one component callson the services of another. The provides interface ofone component is composed with the requiresinterface of another.Additive composition where the interfaces of twocomponents are put together to create a newcomponent. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 32
Types of composition Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 33
Interface incompatibility Parameter incompatibility where operationshave the same name but are of differenttypes.Operation incompatibility where the namesof operations in the composed interfaces aredifferent.Operation incompleteness where theprovides interface of one component is asubset of the requires interface of another. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 34
Incompatible components Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 35
Adaptor components Address the problem of componentincompatibility by reconciling the interfacesof the components that are composed.Different types of adaptor are requireddepending on the type of composition.An addressFinder and a mapper componentmay be composed through an adaptor thatstrips the postal code from an address andpasses this to the mapper component. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 36
Composition through an adaptor The component postCodeStripper is theadaptor that facilitates the sequentialcomposition of addressFinder and mappercomponents.address addressFinder.location (phonenumber) ;postCode postCodeStripper.getPostCode (address) ;mapper.displayMap(postCode, 10000) Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 37
Adaptor for data collector Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 38
Interface semantics You have to rely on componentdocumentation to decide if interfaces that aresyntactically compatible are actuallycompatible.Consider an interface for a PhotoLibrarycomponent:public void addItem (Identifier pid ; Photograph p; CatalogEntry photodesc) ;public Photograph retrieve (Identifier pid) ;public CatalogEntry catEntry (Identifier pid) ; Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 39
Photo library composition Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 40
Photo Library documentation“This method adds a photograph to the library andassociates the photograph identifier and cataloguedescriptor with the photograph.”“what happens if the photograph identifier is alreadyassociated with a photograph in the library?”“is the photograph descriptor associated with thecatalogue entry as well as the photograph i.e. if I deletethe photograph, do I also delete the catalogueinformation?” Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 41
The Object Constraint Language The Object Constraint Language (OCL) hasbeen designed to define constraints that areassociated with UML models.It is based around the notion of pre and postcondition specification - similar to theapproach used in Z as described in Chapter10. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 42
Formal description of photo library-- The context keyword names the component to which the conditions applycontext addItem-- The preconditions specify what must be true before execution of addItempre:PhotoLibrary.libSize() 0PhotoLibrary.retrieve(pid) null-- The postconditions specify what is true after executionpost: libSize () libSize()@pre 1PhotoLibrary.retrieve(pid) pPhotoLibrary.catEntry(pid) photodesccontext deletepre: PhotoLibrary.retrieve(pid) null ;post: PhotoLibrary.retrieve(pid) nullPhotoLibrary.catEntry(pid) () libSize()@pre - 1 Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 43
Photo library conditions As specified, the OCL associated with the PhotoLibrary component states that: There must not be a photograph in the library with thesame identifier as the photograph to be entered;The library must exist - assume that creating a libraryadds a single item to it;Each new entry increases the size of the library by 1;If you retrieve using the same identifier then you get backthe photo that you added;If you look up the catalogue using that identifier, then youget back the catalogue entry that you made. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 44
Composition trade-offs When composing components, you may findconflicts between functional and non-functionalrequirements, and conflicts between the need forrapid delivery and system evolution.You need to make decisions such as: What composition of components is effective fordelivering the functional requirements?What composition of components allows for futurechange?What will be the emergent properties of the composedsystem? Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 45
Data collection and report generation Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 46
Key points CBSE is a reuse-based approach to defining andimplementing loosely coupled components intosystems.A component is a software unit whose functionalityand dependencies are completely defined by itsinterfaces.A component model defines a set of standards thatcomponent providers and composers should follow.During the CBSE process, the processes ofrequirements engineering and system design areinterleaved. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 47
Key points Component composition is the process of‘wiring’ components together to create asystem.When composing reusable components, younormally have to write adaptors to reconciledifferent component interfaces.When choosing compositions, you have toconsider required functionality, nonfunctional requirements and systemevolution. Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19Slide 48
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 2 Objectives To explain that CBSE is concerned with developing standardised components and composing these into applications To describe components and component models To show the principal activities in the CBSE process To discuss approaches to component composition and problems that may arise
