cosc 4406 software engineering

44
1 COSC 4406 COSC 4406 Software Engineering Software Engineering Haibin Zhu, Ph.D. Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada, ON P1B 8L7, Canada, [email protected] , , http://www.nipissingu.ca/faculty/haibinz http://www.nipissingu.ca/faculty/haibinz

Upload: connie

Post on 20-Jan-2016

34 views

Category:

Documents


0 download

DESCRIPTION

COSC 4406 Software Engineering. Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada, [email protected] , http://www.nipissingu.ca/faculty/haibinz. Lecture 17 Component-Based Software Engineering Ref. Chap. 30. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: COSC 4406 Software Engineering

1

COSC 4406COSC 4406

Software Software EngineeringEngineering

Haibin Zhu, Ph.D.Haibin Zhu, Ph.D.Dept. of Computer Science and mathematics, Nipissing University, Dept. of Computer Science and mathematics, Nipissing University,

100 College Dr., North Bay, ON P1B 8L7, Canada, 100 College Dr., North Bay, ON P1B 8L7, Canada, [email protected], http://www.nipissingu.ca/faculty/haibinz, http://www.nipissingu.ca/faculty/haibinz

Page 2: COSC 4406 Software Engineering

2

Lecture 17Lecture 17Component-BasedComponent-Based

Software Software EngineeringEngineeringRef. Chap. 30Ref. Chap. 30

Page 3: COSC 4406 Software Engineering

3

The Idea of ReuseThe Idea of Reuse The initial idea of component-based The initial idea of component-based

development is learning from the hardware development is learning from the hardware industry to reuse hardware components such as industry to reuse hardware components such as integrated circuits (IC), large-scale integrated integrated circuits (IC), large-scale integrated circuit (LSI), very large scale integrated circuits circuit (LSI), very large scale integrated circuits (VLSI), chips, chip-sets, boards, etc (VLSI), chips, chip-sets, boards, etc

Reusing hardware components is well accepted, Reusing hardware components is well accepted, because in hardware engineering, to because in hardware engineering, to understand a component is much easier than to understand a component is much easier than to make it. make it.

It is impossible for application developers to It is impossible for application developers to develop hardware components such as chips develop hardware components such as chips and boards.and boards.

Page 4: COSC 4406 Software Engineering

4

The Key QuestionsThe Key Questions

When faced with the possibility of reuse, the When faced with the possibility of reuse, the software team asks:software team asks: Are commercial off-the-shelf (COTS) components Are commercial off-the-shelf (COTS) components

available to implement the requirement?available to implement the requirement? Are internally-developed reusable components available Are internally-developed reusable components available

to implement the requirement?to implement the requirement? Are the interfaces for available components compatible Are the interfaces for available components compatible

within the architecture of the system to be built?within the architecture of the system to be built? At the same time, they are faced with the At the same time, they are faced with the

following impediments to reuse ...following impediments to reuse ...

Page 5: COSC 4406 Software Engineering

5

Impediments to ReuseImpediments to Reuse Few companies and organizations have anything that Few companies and organizations have anything that

even slightly resembles a comprehensive software even slightly resembles a comprehensive software reusability plan. reusability plan.

Although an increasing number of software vendors Although an increasing number of software vendors currently sell tools or components that provide direct currently sell tools or components that provide direct assistance for software reuse, the majority of software assistance for software reuse, the majority of software developers do not use them. developers do not use them.

Relatively little training is available to help software Relatively little training is available to help software engineers and managers understand and apply reuse.engineers and managers understand and apply reuse.

Many software practitioners continue to believe that Many software practitioners continue to believe that reuse is “more trouble than it’s worth.” reuse is “more trouble than it’s worth.”

Many companies continue to encourage of software Many companies continue to encourage of software development methodologies which do not facilitate reuse development methodologies which do not facilitate reuse

Few companies provide an incentives to produce Few companies provide an incentives to produce reusable program components.reusable program components.

Page 6: COSC 4406 Software Engineering

6

ComponentsComponents

Components provide a service without regard to Components provide a service without regard to where the component is executing or its where the component is executing or its programming languageprogramming language A component is an independent executable entity that A component is an independent executable entity that

can be made up of one or more executable objects;can be made up of one or more executable objects; The component interface is published and all The component interface is published and all

interactions are through the published interface;interactions are through the published interface;

Page 7: COSC 4406 Software Engineering

7

Component-based Component-based developmentdevelopment

Component-based software engineering (CBSE) Component-based software engineering (CBSE) is an approach to software development that is an approach to software development that relies on software reuse.relies on software reuse.

Components are more abstract than object Components are more abstract than object classes and can be considered to be stand-alone classes and can be considered to be stand-alone service providers.service providers.

Page 8: COSC 4406 Software Engineering

8

CBSE essentialsCBSE essentials

Independent componentsIndependent components specified by their specified by their interfaces.interfaces.

Component standardsComponent standards to facilitate component to facilitate component integration.integration.

MiddlewareMiddleware that provides support for that provides support for component inter-operability.component inter-operability.

A development processA development process that is geared to reuse. that is geared to reuse.

Page 9: COSC 4406 Software Engineering

9

CBSE and design principlesCBSE and design principles

Apart from the benefits of reuse, CBSE is based Apart from the benefits of reuse, CBSE is based on sound software engineering design on sound software engineering design principles:principles: Components are independent so do not interfere with Components are independent so do not interfere with

each other;each other; Component implementations are hidden;Component implementations are hidden; Communication is through well-defined interfaces;Communication is through well-defined interfaces; Component platforms are shared and reduce Component platforms are shared and reduce

development costs.development costs.

Page 10: COSC 4406 Software Engineering

10

Component as a service Component as a service providerprovider

The component is an independent, executable The component is an independent, executable entity. It does not have to be compiled before it entity. It does not have to be compiled before it is used with other components.is used with other components.

The services offered by a component are made The services offered by a component are made available through an interface and all available through an interface and all component interactions take place through that component interactions take place through that interface.interface.

Page 11: COSC 4406 Software Engineering

11

Component characteristics 1Component characteristics 1

Standardised Component standardisation means that a component that is used in a CBSE process has to conform to some standardised component model. This model may define component interfaces, component meta-data, documentation, composition and deployment.

Independent A component should be independent – it should be possible to compose and deploy it without having to use other specific components. In situations where the component needs externally provided services, these should be explicitly set out in a “requires” interface specification.

Composable For a component to be composable, all external interactions must take place through publicly defined interfaces. In addition, it must provide external access to information about itself such as its methods and attributes.

Page 12: COSC 4406 Software Engineering

12

Component characteristics 2Component characteristics 2

Deployable To 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.

Documented Components 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.

Page 13: COSC 4406 Software Engineering

13

Component interfacesComponent interfaces

Provides interfaceProvides interface Defines the services that are provided by the Defines the services that are provided by the

component to other components.component to other components. Requires interfaceRequires interface

Defines the services that specifies what services Defines the services that specifies what services must be made available for the component to execute must be made available for the component to execute as specified.as specified.

Page 14: COSC 4406 Software Engineering

14

Component interfacesComponent interfaces

Provides interfaceRequires interface

ComponentDefines the servicesfrom the component’senvironment that ituses

Defines the servicesthat are providedby the componentto other components

Page 15: COSC 4406 Software Engineering

15

A data collector componentA data collector component

Provides interfaceRequires interface

Data collector

addSensorremoveSensorstartSensor

stopSensor

testSensor

listAllreport

initialise

sensorManagement

sensorData

Page 16: COSC 4406 Software Engineering

16

Components and objectsComponents and objects

Components are deployable entities.Components are deployable entities. Components do not define types.Components do not define types. Component implementations are opaque.Component implementations are opaque. Components are language-independent.Components are language-independent. Components are standardised.Components are standardised.

Page 17: COSC 4406 Software Engineering

17

Component modelsComponent models

A component model is a definition of standards for A component model is a definition of standards for component implementation, documentation and component implementation, documentation and deployment.deployment.

Examples of component modelsExamples of component models EJB model (Enterprise Java Beans)EJB model (Enterprise Java Beans) COM+ model (.NET model)COM+ model (.NET model) Corba Component ModelCorba Component Model

The component model specifies how interfaces should be The component model specifies how interfaces should be defined and the elements that should be included in an defined and the elements that should be included in an interface definition.interface definition.

Page 18: COSC 4406 Software Engineering

18

Elements of a component Elements of a component modelmodel

Component model

InterfacesUsage

informationDeployment

and use

Interfacedefinition

Specificinterfaces

Composition

Namingconvention

Meta-dataaccess

Customisation

Packaging

Documentation

Evolutionsupport

Page 19: COSC 4406 Software Engineering

19

Middleware supportMiddleware support

Component models are the basis for middleware that Component models are the basis for middleware that provides support for executing components.provides support for executing components.

Component model implementations provide:Component model implementations provide: Platform services that allow components written according Platform services that allow components written according

to the model to communicate;to the model to communicate; Horizontal services that are application-independent Horizontal services that are application-independent

services used by different components.services used by different components. To use services provided by a model, components are To use services provided by a model, components are

deployed in a deployed in a containercontainer. . This is a set of interfaces used to This is a set of interfaces used to access the service implementations.access the service implementations.

Page 20: COSC 4406 Software Engineering

20

Component model servicesComponent model services

Platform services

AddressingInterfacedefinition

Componentcommunications

Exceptionmanagement

Horizontal services

Security

Transactionmanagement

Concurrency

Componentmanagement

Persistence

Resourcemanagement

Page 21: COSC 4406 Software Engineering

21

Component development for reuseComponent development for reuse

Components developed for a specific application Components developed for a specific application usually have to be generalised to make them usually have to be generalised to make them reusable.reusable.

A component is most likely to be reusable if it A component is most likely to be reusable if it associated with a stable domain abstraction associated with a stable domain abstraction (business object). (business object).

For example, in a hospital stable domain For example, in a hospital stable domain abstractions are associated with the abstractions are associated with the fundamental purpose - nurses, patients, fundamental purpose - nurses, patients, treatments, etc.treatments, etc.

Page 22: COSC 4406 Software Engineering

22

Component development for Component development for reusereuse

Components for reuse may be specially constructed by Components for reuse may be specially constructed by generalising existing components.generalising existing components.

Component reusabilityComponent reusability Should reflect stable domain abstractions;Should reflect stable domain abstractions; Should hide state representation;Should hide state representation; Should be as independent as possible;Should be as independent as possible; Should publish exceptions through the component Should publish exceptions through the component

interface.interface. There is a trade-off between reusability and usabilityThere is a trade-off between reusability and usability

The more general the interface, the greater the The more general the interface, the greater the reusability but it is then more complex and hence less reusability but it is then more complex and hence less usable.usable.

Page 23: COSC 4406 Software Engineering

23

Changes for reusabilityChanges for reusability

Remove application-specific methods.Remove application-specific methods. Change names to make them general.Change names to make them general. Add methods to broaden coverage.Add methods to broaden coverage. Make exception handling consistent.Make exception handling consistent. Add a configuration interface for component Add a configuration interface for component

adaptation.adaptation. Integrate required components to reduce Integrate required components to reduce

dependencies.dependencies.

Page 24: COSC 4406 Software Engineering

24

Reusable componentsReusable components The development cost of reusable components The development cost of reusable components

may be higher than the cost of specific may be higher than the cost of specific equivalents. This extra reusability enhancement equivalents. This extra reusability enhancement cost should be an organization rather than a cost should be an organization rather than a project cost.project cost.

Generic components may be less Generic components may be less space-efficient and may have longer execution space-efficient and may have longer execution times than their specific equivalents.times than their specific equivalents.

Page 25: COSC 4406 Software Engineering

25

The CBSE processThe CBSE process

When reusing components, it is essential to When reusing components, it is essential to make trade-offs between ideal requirements make trade-offs between ideal requirements and the services actually provided by and the services actually provided by available components.available components.

This involves:This involves: Developing outline requirements;Developing outline requirements; Searching for components then modifying Searching for components then modifying

requirements according to available requirements according to available functionality.functionality.

Searching again to find if there are better Searching again to find if there are better components that meet the revised components that meet the revised requirements.requirements.

Page 26: COSC 4406 Software Engineering

26

The CBSE processThe CBSE process

Identify candidatecomponents

Outlinesystem

requirements

Modifyrequirements

according to discoveredcomponents

Identify candidatecomponents

Architecturaldesign

Composecomponents tocreate system

Page 27: COSC 4406 Software Engineering

27

The component identification The component identification processprocess

Componentselection

Componentsearch

Componentvalidation

Page 28: COSC 4406 Software Engineering

28

Component identification Component identification issuesissues

TrustTrust. You need to be able to trust the supplier of a . You need to be able to trust the supplier of a component. At best, an untrusted component may not component. At best, an untrusted component may not operate as advertised; at worst, it can breach your operate as advertised; at worst, it can breach your security.security.

RequirementsRequirements. Different groups of components will satisfy . Different groups of components will satisfy different requirements.different requirements.

ValidationValidation. . The component specification may not be detailed enough to The component specification may not be detailed enough to

allow comprehensive tests to be developed.allow comprehensive tests to be developed. Components may have unwanted functionality. How can Components may have unwanted functionality. How can

you test this will not interfere with your application?you test this will not interfere with your application?

Page 29: COSC 4406 Software Engineering

29

Identifying Reusable Identifying Reusable ComponentsComponents

• • Is component functionality required on future Is component functionality required on future implementations?implementations?• • How common is the component's function within the domain?How common is the component's function within the domain?• • Is there duplication of the component's function within the Is there duplication of the component's function within the domain?domain?• • Is the component hardware-dependent?Is the component hardware-dependent?• • Does the hardware remain unchanged between Does the hardware remain unchanged between implementations?implementations?• • Can the hardware specifics be removed to another Can the hardware specifics be removed to another component?component?• • Is the design optimized enough for the next implementation?Is the design optimized enough for the next implementation?• • Can we parameterize a non-reusable component so that it Can we parameterize a non-reusable component so that it becomes reusable?becomes reusable?• • Is the component reusable in many implementations with only Is the component reusable in many implementations with only minor changes?minor changes?• • Is reuse through modification feasible?Is reuse through modification feasible?• • Can a non-reusable component be decomposed to yield Can a non-reusable component be decomposed to yield reusable components?reusable components?• • How valid is component decomposition for reuse?How valid is component decomposition for reuse?

Page 30: COSC 4406 Software Engineering

30

Ariane launcher failureAriane launcher failure

In 1996, the 1st test flight of the Ariane 5 rocket ended in In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster when the launcher went out of control 37 disaster when the launcher went out of control 37 seconds after take off.seconds after take off.

The problem was due to a reused component from a The problem was due to a reused component from a previous version of the launcher (the Inertial Navigation previous version of the launcher (the Inertial Navigation System) that failed because assumptions made when that System) that failed because assumptions made when that component was developed did not hold for Ariane 5.component was developed did not hold for Ariane 5.

The functionality that failed in this component was not The functionality that failed in this component was not required in Ariane 5.required in Ariane 5.

Page 31: COSC 4406 Software Engineering

31

QualificationQualification

Before a component can be used, you must consider:Before a component can be used, you must consider:

• • application programming interface (API)application programming interface (API)• • development and integration tools required by the development and integration tools required by the componentcomponent• • run-time requirements including resource usage (e.g., run-time requirements including resource usage (e.g., memory or storage), timing or speed, and network protocolmemory or storage), timing or speed, and network protocol• • service requirements including operating system service requirements including operating system interfaces and support from other componentsinterfaces and support from other components• • security features including access controls and security features including access controls and authentication protocolauthentication protocol• • embedded design assumptions including the use of embedded design assumptions including the use of specific numerical or non-numerical algorithmsspecific numerical or non-numerical algorithms• • exception handlingexception handling

Page 32: COSC 4406 Software Engineering

32

AdaptationAdaptationThe implication of “easy integration” is: The implication of “easy integration” is:

(1) that consistent methods of resource (1) that consistent methods of resource management have been implemented for management have been implemented for all components in the library; all components in the library;

(2) that common activities such as data (2) that common activities such as data management exist for all components, and management exist for all components, and

(3) that interfaces within the architecture (3) that interfaces within the architecture and with the external environment have and with the external environment have been implemented in a consistent manner. been implemented in a consistent manner.

Page 33: COSC 4406 Software Engineering

33

Component compositionComponent composition

The process of assembling components to create The process of assembling components to create a system.a system.

Composition involves integrating components Composition involves integrating components with each other and with the component with each other and with the component infrastructure.infrastructure.

Normally you have to write ‘glue code’ to Normally you have to write ‘glue code’ to integrate components.integrate components.

Page 34: COSC 4406 Software Engineering

34

Types of compositionTypes of composition

Sequential compositionSequential composition where the composed components where the composed components are executed in sequence. This involves composing the are executed in sequence. This involves composing the provides interfaces of each component.provides interfaces of each component.

Hierarchical compositionHierarchical composition where one component calls on where one component calls on the services of another. The provides interface of one the services of another. The provides interface of one component is composed with the requires interface of component is composed with the requires interface of another.another.

Additive compositionAdditive composition where the interfaces of two where the interfaces of two components are put together to create a new component.components are put together to create a new component.

Page 35: COSC 4406 Software Engineering

35

Types of compositionTypes of composition

(a)

A A

B B

A B

(b) (c)

Page 36: COSC 4406 Software Engineering

36

Interface incompatibilityInterface incompatibility

Parameter incompatibilityParameter incompatibility where operations where operations have the same name but are of different types.have the same name but are of different types.

Operation incompatibilityOperation incompatibility where the names of where the names of operations in the composed interfaces are operations in the composed interfaces are different.different.

Operation incompletenessOperation incompleteness where the provides where the provides interface of one component is a subset of the interface of one component is a subset of the requires interface of another.requires interface of another.

Page 37: COSC 4406 Software Engineering

37

OMG/ CORBAOMG/ CORBA The Object Management Group has published a common object request

broker architecture (OMG/CORBA). An object request broker (ORB) provides services that enable reusable

components (objects) to communicate with other components, regardless of their location within a system.

Integration of CORBA components (without modification) within a system is assured if an interface definition language (IDL) interface is created for every component.

Objects within the client application request one or more services from the ORB server. Requests are made via an IDL or dynamically at run time.

An interface repository contains all necessary information about the service’s request and response formats.

Page 38: COSC 4406 Software Engineering

38

Microsoft COMMicrosoft COM

The component object model (COM) provides a specification for using components produced by various vendors within a single application running under the Windows operating system.

COM encompasses two elements: COM interfaces (implemented as COM objects) a set of mechanisms for registering and passing messages between

COM interfaces.

Page 39: COSC 4406 Software Engineering

39

Sun JavaBeansSun JavaBeans

The JavaBeans component system is a portable, platform independent CBSE infrastructure developed using the Java programming language.

The JavaBeans component system encompasses a set of tools, called the Bean Development Kit (BDK), that allows developers to analyze how existing Beans (components) work customize their behavior and appearance establish mechanisms for coordination and communication develop custom Beans for use in a specific application test and evaluate Bean behavior.

Page 40: COSC 4406 Software Engineering

40

The Reuse EnvironmentThe Reuse Environment

A component database capable of storing software components and the classification information necessary to retrieve them.

A library management system that provides access to the database.

A software component retrieval system (e.g., an object request broker) that enables a client application to retrieve components and services from the library server.

CBSE tools that support the integration of reused components into a new design or implementation.

Page 41: COSC 4406 Software Engineering

41

Reuse EconomicsReuse Economics Quality:

0.9 defects per KLOC for reused code 4.1 defects per KLOC for newly developed code For a project with 68% of reused code, we get 2.0 defects per KLOC and

obtain 51% improvement.

Productivity: 30 ~ 50% reused can result in productivity improvements in the 25~40%

range.

Cost: net cost saving = Cs - Cr - Cd

Cs: the cost of the project if it were developed from scratch

Cr: the sum of the cost associated with reuse

Cd: the actual cost of the software delivered

Page 42: COSC 4406 Software Engineering

42

CBSE problemsCBSE problems

Component trustworthinessComponent trustworthiness - how can a component - how can a component with no available source code be trusted?with no available source code be trusted?

Component certificationComponent certification - who will certify the - who will certify the quality of components?quality of components?

Emergent property predictionEmergent property prediction - how can the - how can the emergent properties of component compositions be emergent properties of component compositions be predicted?predicted?

Requirements trade-offsRequirements trade-offs - how do we do trade-off - how do we do trade-off analysis between the features of one component analysis between the features of one component and another?and another?

Page 43: COSC 4406 Software Engineering

43

The Difficulties of ComponentsThe Difficulties of Components

It is possible for application developers to develop It is possible for application developers to develop software components such as a program segment, a software components such as a program segment, a function, or even a class.function, or even a class.

In the software industry, a software component either In the software industry, a software component either is too simple or has too complicated specifications. is too simple or has too complicated specifications. If it is too simple, the programmers believe that they can If it is too simple, the programmers believe that they can

make it by themselves. make it by themselves. If the specifications are too complex, the situation is that, If the specifications are too complex, the situation is that,

after understanding the component’s specification, the after understanding the component’s specification, the programmers believe that they can make a better one by programmers believe that they can make a better one by themselves.themselves.

The key difficulty is to make specifications much simpler than the The key difficulty is to make specifications much simpler than the implementation logic.implementation logic.

Page 44: COSC 4406 Software Engineering

44

SummarySummary

Origin of Software Component Origin of Software Component Component-Based DevelopmentComponent-Based Development

IdentificationIdentification AdaptationAdaptation CompositionComposition Standard examplesStandard examples

Reuse environmentReuse environment Economics of CBSEEconomics of CBSE Difficulty of reusable componentsDifficulty of reusable components