Lecture Building reliable component-based systems - Chapter 5: Component-based development process

Lecture Building reliable component-based systems - Chapter 5: Component-based development process. This chapter presents the following content: Software process models, component-based development, component-based software lifecycle.

Trang 1

Building Reliable Componentbased Systems

Chapter 5 ComponentBased Development Process

Chapter 5 Component-Based Development Process

Trang 2

Trang 3

Purpose

This chapter:

Describes the component-based software lifecycle

Provides an overview of generic software engineering processes

Motivates the need for specific processes when developing components and when building systems or applications from components

Describe these processes, reviewing their procedures

Trang 4

Software Process Models

Generic lifecycle activities

The Sequential Model

Evolutionary Development

Unified Process

Trang 5

Generic lifecycle activities

Disposal

Trang 6

The Sequential Model

De ve lopm

ent

Analysis

Design Implementation

Integration

Test

Trang 7

Evolutionary Development

Develop a system gradually in many repetitive stages:

Increasing the knowledge of the system requirements and system functionality in each stage

exposing the results to user comments

This can be achieved by using:

The Iterative ModelThe Incremental ModelThe Prototyping Model

Trang 8

The Iterative Model

De velopm

ent

Analysis

Integration

Test

Trang 9

The Incremental Model

Increment 1 2 n

Analysis

Integration

Test

De ve lopm

ent

Trang 10

The Prototyping Model

Analysis

Integration

Test

De velopm

ent

Develop prototype Test prototype

Trang 11

Trang 12

Unified Process continued

Trang 13

Unified Process Illustrated

Inception Elaboration Construction Transition Requirements

Phases

Iterations

Trang 14

Component-based Development

Reuse Approach

Separation of Development Processes

Component-based Development (CBD) – The Consumer Perspective

Component Development (CD) – The Producer

Perspective

Trang 15

Reuse Approach

The reuse approach makes the following assumptions:

All experience can be reused

Reuse typically requires some modification of objects being reused

Reuse must be integrated into the specific software development

Analysis is necessary to determine when, and if, reuse

is appropriate

Trang 16

Selection of one of these, and, if required,

Its modification to translate x k to x’ which is as close to x

as possible

Trang 17

Trang 18

Separation of Development Processes

Component development System development with components

System development with components

Focuses on the identification of reusable entities and relations between them, beginning from the system requirements and from the availability of components already existing

Trang 19

Component Guidelines

Components are built to be used and reused in many

applications and should thus be:

Well specifiedEasy to understandSufficiently generalEasy to adapt

Easy to deliver and deploy Easy to replace

Trang 20

CBD – The Consumer Perspective

Typically a component consumer selects a component and then uses it in a software system.

The component lifecycle must be considered in relation

to the lifecycle of the system as a whole

Trang 21

The Consumer Perspective Continued

Will the component be compatible with newer versions

of the surrounding systems and applications?

Trang 22

CD – The Producer Perspective

The producer of a component must take into

consideration:

The business goalComponent functionalityMaintenance policy

The type of application and system in which the component will be used

The requirements of the systemThe life expectancy of relevant systems

Trang 23

Additional Considerations

The maintenance requirements of components and

systems are not necessarily compatible

The component’s maintenance requirements should be synchronous with those of the system in which they are

to be incorporated

Trang 24

Disposal

Disposal of Component-based Systems generally takes place due to two different factors:

DissatisfactionObsolescence

Trang 25

Disposal: Dissatisfaction

Initiated by consumers when they conclude that:

The component no longer provides the support of the system it was intended to provide or;

That the system no longer needs the component

Trang 26

Disposal: Obsolescence

When a component becomes obsolete and the producer ceases component maintenance and operation support This is likely to occur when:

A new, more effective component with the same, similar

or extended functionality is found

The producer is not able to continue with support or maintenance

Trang 27

Disposal: Considerations

Both producer and consumer should arrive at a

compromise with respect to the lifecycles of their

different products

The consumer should always have in mind an

alternative solution, such as:

The replacement of the component with another developed internally or by another producers

Trang 28

Component-Based Software Lifecycle

Development With Components

Requirements Analysis and Definition

Component Selection and Evaluation

System Design

System Implementation

System Integration

Verification and Validation

System Operation Support and Maintenance

System Development Process

Trang 29

Development With Components

Emphasis is placed on the reuse of pre-existing

components, rather than on the implementation of the

Trang 30

The three analysis tasks:

Capture the system requirements and define the system boundaries

Define the system architecture to permit component collaboration

Define component requirements to permit the selection

or development of the required components

The approach is:

optimistic and an idealized view of the process

It assumes that the component requirements can be precisely defined and that it is possible to find

components

Trang 31

Analysis and Definition Continued

Not finding a component which exactly satisfies the

requirements necessitates the development of a new

component

The process of design and even requirements

engineering will be combined with component selection and the evaluation process

Trang 32

Component Selection and Evaluation

The components selected must therefore be evaluated:

TechnicallyNon-technically

Trang 33

Technical and Non-technical Evaluation

Technical aspects of evaluation include

IntegrationValidation Verification

Examples of non-technical issues include:

The marketing position of the component supplierMaintenance support provided

Alternative solutions, etc

Trang 34

Evaluation Methods

Procurement-oriented requirements engineering:

1. Identify several component candidates

2. Investigate these

3. Reject those not compliant with the main requirements

4. Continue with the evaluation of the reduced number of candidate components

5. If necessary refine the requirements, and repeat the

evaluation process

Trang 35

Evaluation Methods Continued

One scenario is to:

1. Search for an internally developed component

2. If none suitable is found, continue by searching for an external component

Criteria which may favor the selection of an external

component :

Time-to-marketProduction and maintenance costs,Quality

Trang 36

Evaluation of the Assembly

It is necessary to evaluate the assembly; evaluation of the individual components is not sufficient

This implies that an investigation of the integration procedure may be a part of an evaluation

Trang 37

Trang 38

System Design: Evolutionary Approach

Component selection procedure:

Selection of component candidates, followed by;

Consideration of the feasibility of different combinations

of these

Evolutionary approach:

To find the most appropriate and feasible combination of the component candidates In this way the results of the design activity may be less predictable

Trang 39

System Implementation

Implementation by coding can be reduced to the

creation of the “glue-code” and to component

Trang 40

Trang 41

Emerging properties

An important fact is that it is not possible to discover all the effects of a component until the integration is

performed

Trang 42

Verification and Validation

Expressed by Boehm

Validation: are we building the right product ?Verification: Are we building the product right ?

Component Validation and Verification

After a component is selected it should be tested to check that it functions in accordance with its

specification

We should also note that the component validation is strongly related to system validation

Trang 43

System Verification and Validation

System verification and validation process is similar to the processes for non-component-based systems

The difference is that the implications of the processes may be different – new component requirements may

emerge and it may happen that the selected

components cannot meet the new requirements

Trang 44

System Operation Support and Maintenance

Components exist even at run-time, making it possible

Trang 45

Operation and Support: Considerations

Maintenance procedures can be more complicated as it

is not necessarily clear who:

Is supporting the system

The system vendor is

The component vendors are

Components can be used by several other components introducing version incompatibilities

The same problem may appear when we install a

component package.

Trang 46

Inconsistent Component Integration

Product P Version V1

Component A Version V1

Component A Version V2

Component B Version V1 Component B Version V2

Product P Version V2

Trang 47

System Development Process

Consists of parallel tracks in which:

The basic architecture and its environment is being developed and managed concurrently with both the development of applications consisting of components and the evaluation of the actual components

Trang 48

Component-based Development Process

De ve lopm

ent

Analysis

Integration

Test

Ev alu ation

Find

Select

Adapt Integrate

Test

Trang 49

Component Development

Requirements must be

captured analyzed defined

The component must be

designed implemented verified

validateddelivered

Trang 50

Component Development Considerations

Components are built to be part of something else, thus:

There is greater difficulty in managing requirements;

Greater efforts are needed to develop reusable units;

A precise component specification is required

Trang 51

The development of reusable components would be

easier if requirements remained constant during the

time of component and system development

As a result of new requirements for the systems old or new requirements for the components will emerge

The more reusable a component is, the more demands are placed on it

Trang 52

Accumulated Component Requirements

Product P2 Product P1 Component

Accumulated Requirements

Trang 53

Designing for Reusability

For a component to be reusable, it must be designed in

a more general way than a component tailored for a

unique situation

Components intended to be reused requires

adaptability This will increase the size and complexity

of the components

Định dạng
Số trang	56
Dung lượng	447,87 KB