05 chapterWC3 1

Chapter 5 Component-Based Development Process
Building Reliable Component-based Systems

Chapter 5 - Component-Based Development Process
Page 1
Overview
Software Process Models Component-based Development Component-Based Software Lifecycle
Summary

Page 2
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.

Page 3
Software Process Models

Generic lifecycle activities The Sequential Model Evolutionary Development
Unified Process

Page 4
Generic lifecycle activities

Activities

Requirements analysis and system specification System and software design
Implementation and unit testing

Integration, system verification and validation Operation support and Maintenance Disposal

Page 5
The Sequential Model
Analysis
Design Implementation Integration
Test

Page 6
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. The Iterative Model The Incremental Model The Prototyping Model
This can be achieved by using:


Page 7
The Iterative Model
Analysis Design Implementation Integration Test

Page 8
The Incremental Model

Increment 1 2...n Analysis Design Implementation Integration Test

Page 9
The Prototyping Model

Test prototype
Analysis
Design
Implementation Integration Test Develop prototype

Page 10
Unified Process
Inception
The first phase in which the system is described in a formalized way, providing a base for further development. The phase in which the system architecture is defined and created.
Elaboration

Page 11
Unified Process continued

Construction
The development of completely new products, with reuse capabilities. The work of delivering the product to the customer.
Transition

Page 12
Unified Process Illustrated

Phases Inception Requirements Analysis Design Implementation Test Iter #1 Iter #2 ------------Iter #n An iteration in the elaboration phase Elaboration Construction Transition
Iterations
Page 13
Component-based Development
Reuse Approach Separation of Development Processes Component-based Development (CBD) The Consumer Perspective Component Development (CD) The Producer Perspective

Page 14
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.

Page 15
Reuse
For given requirements r for an object x, we propose the reuse of the already existing object xk. The reuse procedure includes:

Identification of a set of objects x1 , x2 xm as candidates, Selection of one of these, and, if required, Its modification to translate xk to x which is as close to x as possible.

Page 16
Reuse continued
The object x can be of any type:

A system architecture An overall design
A design pattern
An infrastructure Different types of components or services.

Page 17
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.

Page 18
Component Guidelines
Components are built to be used and reused in many applications and should thus be:

Well specified Easy to understand Sufficiently general Easy to adapt Easy to deliver and deploy Easy to replace

Page 19
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.

Page 20
The Consumer Perspective Continued

Common considerations:

Will the component producer be able to deliver a new component version when this is required? How will changes in a component in the system affect the behavior of another component? Will the component be compatible with newer versions of the surrounding systems and applications?

Page 21
CD The Producer Perspective

The producer of a component must take into consideration:

The business goal Component functionality Maintenance policy The type of application and system in which the component will be used
The requirements of the system

The life expectancy of relevant systems

Page 22
Additional Considerations
The maintenance requirements of components and systems are not necessarily compatible.
The components maintenance requirements should be synchronous with those of the system in which they are to be incorporated.

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

Dissatisfaction Obsolescence

Page 24
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.

Page 25
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.

Page 26
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.

Page 27
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

Page 28
Development With Components

Emphasis is placed on the reuse of pre-existing components, rather than on the implementation of the system designed. First
Find reusable units which will meet the requirements specified and will be compliant with the system design. Determine the amount of extra effort required to use reusable units instead of units dedicated to a particular purpose.
Second

Page 29
Requirements Analysis and Definition

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. 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
Page 30
The approach is:

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.

Page 31
Component Selection and Evaluation

The components selected must therefore be evaluated:

Technically Non-technically

Page 32
Technical and Non-technical Evaluation

Technical aspects of evaluation include

Integration Validation
Verification
The marketing position of the component supplier Maintenance support provided Alternative solutions, etc
Examples of non-technical issues include:


Page 33
Evaluation Methods
Procurement-oriented requirements engineering:
1. 2.
Identify several component candidates. Investigate these.
3.
4. 5.
Reject those not compliant with the main requirements.

Continue with the evaluation of the reduced number of candidate components. If necessary refine the requirements, and repeat the evaluation process.

Page 34
Evaluation Methods Continued

One scenario is to:
1. 2.
Search for an internally developed component. If none suitable is found, continue by searching for an external component.
Criteria which may favor the selection of an external component :
Time-to-market
Production and maintenance costs,

Quality

Page 35
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.

Page 36
System Design
System specification and definition of the system architecture

The initial architecture will be a result of both the overall requirements and the choice of component model. Many decisions related to the system design will be a consequence of the component model selected.

Page 37
System Design: Evolutionary Approach

Component selection procedure:

Selection of component candidates, followed by; Consideration of the feasibility of different combinations of these. 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.
Evolutionary approach:

Page 38
System Implementation
Implementation by coding can be reduced to the creation of the glue-code and to component adaptation.

This effort is usually less than 50% of the total development effort. Effort per line of glue-code is about three times the effort per line of the applications code.
It may still be necessary to design and implement some components.

Page 39
System Integration
Integration
Is the composition of the implemented and selected components to constitute the software system.
There are several other aspects to be taken into consideration, namely:

Component adaptation; Reconfigurations of assemblies;
Emerging properties of assemblies integrated into the system.

Page 40
Integration Considerations
Component adaptation
In many cases a component must be adjusted to system requirements. Different assemblies (or composite components) can include common basic components. for re-configuring assemblies must exist. An important fact is that it is not possible to discover all the effects of a component until the integration is performed.
Reconfigurations of assemblies
Emerging properties

Page 41
Verification and Validation

Expressed by Boehm

Validation: are we building the right product ? Verification: Are we building the product right ? After a component is selected it should be tested to check that it functions in accordance with its specification.
Component Validation and Verification
We should also note that the component validation is strongly related to system validation.

Page 42
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.

Page 43
System Operation Support and Maintenance

Components exist even at run-time, making it possible to:

Improve and maintain the system by updating or adding new components to the system. Improve the system quicker and more flexibly.

Page 44
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.

Page 45
Inconsistent Component Integration

Product P Version V1 Product P Version V2
Component A Version V1
Component A Version V2
Component B Version V1
Component B Version V2

Page 46
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.

Page 47
Component-based Development Process
Find
Select Adapt Integrate Test
Analysis
Design Implementation Integration Test
Component evaluation
System Development

Page 48
Component Development
Requirements must be

captured analyzed
defined
designed implemented verified validated delivered
Page 49
The component must be

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

Page 50
Requirements Analysis and Definition

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.

Page 51
Accumulated Component Requirements

Accumulated Requirements Component
Product P1
Product P2
t-0
t-1

Page 52
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

Page 53
Component Specification
It is important that the component be clearly and properly specified. The consumer must be able to understand the component specification.

Page 54
Summary
In a component-based development process we distinguish development of components from development of systems using components:

Component development process: Is focused on building reusable units. System development process: Concentrates on the reuse of components, their evaluation and integration.
These processes are often performed independently of each other.

Page 55
Summary Continued
To achieve a proper balance between the independence of and collaboration between the processes remains a challenge for researchers and practitioners

Page 56

05 chapterWC3 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

05 chapterWC3 1

Uploaded by

Copyright:

Available Formats

Chapter 5 Component-Based Development Process

Building Reliable Component-based Systems

Building Reliable Component-based Systems

Building Reliable Component-based Systems

Software Process Models

Building Reliable Component-based Systems

Generic lifecycle activities

Requirements analysis and system specification System and software design

Implementation and unit testing

Building Reliable Component-based Systems

The Sequential Model

Building Reliable Component-based Systems

This can be achieved by using:

Building Reliable Component-based Systems

The Iterative Model

Analysis Design Implementation Integration Test

Building Reliable Component-based Systems

The Incremental Model

Building Reliable Component-based Systems

The Prototyping Model

Building Reliable Component-based Systems

Building Reliable Component-based Systems

Unified Process continued

Building Reliable Component-based Systems

Unified Process Illustrated

Building Reliable Component-based Systems

Building Reliable Component-based Systems

Building Reliable Component-based Systems

A system architecture An overall design

Building Reliable Component-based Systems

Separation of Development Processes

System development with components

Building Reliable Component-based Systems

Building Reliable Component-based Systems

CBD The Consumer Perspective

Building Reliable Component-based Systems

The Consumer Perspective Continued

Building Reliable Component-based Systems

CD The Producer Perspective

The requirements of the system

Building Reliable Component-based Systems

Building Reliable Component-based Systems

Building Reliable Component-based Systems

Building Reliable Component-based Systems

Building Reliable Component-based Systems

Building Reliable Component-based Systems

Component-Based Software Lifecycle

Building Reliable Component-based Systems

Development With Components

Building Reliable Component-based Systems

Requirements Analysis and Definition

The approach is:

Analysis and Definition Continued

Building Reliable Component-based Systems

Component Selection and Evaluation

Building Reliable Component-based Systems

Technical and Non-technical Evaluation

Examples of non-technical issues include:

Building Reliable Component-based Systems

Identify several component candidates. Investigate these.

Reject those not compliant with the main requirements.

Building Reliable Component-based Systems

Evaluation Methods Continued