Component-Based Software Engineering

Main issues: assemble systems out of (reusable) components compatibility of components

LEGO analogy

Set of building blocks in different shapes and colors Can be combined in different ways Composition through small stubs in one and corresponding holes in another building block
LEGO blocks are generic and easily composable LEGO can be combined with LEGO, not with Meccano
SE, CBSE, Hans van Vliet, 2008 2

Why CBSE?

CBSE increases quality, especially evolvability and maintainability

CBSE increases productivity

CBSE shortens development time

SE, CBSE, Hans van Vliet, 2008

Component model

Defines the types of building block, and the recipe for putting them together
More precisely, a component model defines standards for:
Properties individual components must satisfy Methods and mechanisms for composing components

Consequently, a component has to conform to some component model

SE, CBSE, Hans van Vliet, 2008 4

A software component:

Implements some functionality

Has explicit dependencies through provides and required interfaces Communicates through its interfaces only

Has structure and behavior that conforms to a component model

SE, CBSE, Hans van Vliet, 2008

A component technology

Is the implementation of a component model, by means of:

Standards and guidelines for the implementation and execution of software components Executable software that supports the implementation, assembly, deployment, execution of components

Examples: EJB, COM+, .NET, CORBA

SE, CBSE, Hans van Vliet, 2008

Component forms

Component goes through different stages: development, packaging, distribution, deployment, execution Across these stages, components are represented in different forms:
During development: UML, e.g. When packaging: in a .zip file, e.g. In the execution stage: blocks of code and data

SE, CBSE, Hans van Vliet, 2008

Characterization of component forms

SE, CBSE, Hans van Vliet, 2008

Component forms in different stages

SE, CBSE, Hans van Vliet, 2008

Component specification vs component interface

Specification describes properties to be realized: realization contract Interface describes how components interact: usage contract
Different in scope as well: specification is about the component as a whole, while an interface might be about part of a component only

SE, CBSE, Hans van Vliet, 2008

10

Hiding of component internals

Black box: only specification is known Glass box: internals may be inspected, but not changed Grey box: part of the internals may be inspected, limited modification is allowed While box: component is open to inspection and modification

SE, CBSE, Hans van Vliet, 2008

11

Managing quality in CBSE

Who manages the quality: the component, or the execution platform

Scope of management: per-collaboration, or system-wide

SE, CBSE, Hans van Vliet, 2008

12

Quality management in CBSE

SE, CBSE, Hans van Vliet, 2008

13

Managing quality in CBSE

Approach A: left to the designers (e.g. when integrating COTS components) Approach B: model provides standardized facilities for managing qualities Approach C: component only addresses functionality, quality in surrounding container Approach D: similar to C, but container interacts with platform on quality issues

SE, CBSE, Hans van Vliet, 2008

14

Common features of component models

Infrastructure mechanisms, for binding, execution, etc Instantiation Binding (design time, compile time, ) Mechanisms for communication between components Discovery of components Announcement of component capabilities (interfaces) Development support Language independence Platform independence Analysis support Support for upgrading and extension Support for quality properties

SE, CBSE, Hans van Vliet, 2008

15

Development process in CBSE

Two separate development processes:

Development of components Development of systems out of components

Separate process to assess components

SE, CBSE, Hans van Vliet, 2008

16

CBSE system development process

Requirements: also considers availability of components (like in COTS) Analysis and design: very similar to what we normally do Implementation: less coding, focus on selection of components, provision of glue code Integration: largely automated Testing: verification of components is necessary Release: as in classical approaches Maintenance: replace components
SE, CBSE, Hans van Vliet, 2008 17

Component assessment

Find components Verify components Store components in repository

SE, CBSE, Hans van Vliet, 2008

18

Component development process

Components are intended for reuse

Managing requirements is more difficult More effort required to develop reusable components More effort in documentation for consumers

SE, CBSE, Hans van Vliet, 2008

19

Component development process

Requirements: combination of top-down (from system) and bottom-up (generality) Analysis and design: generality is an issue, assumptions about system (use) must be made Implementation: largely determined by component technology Testing: extensive (no assumptions of usage!), and well-documented Release: not only executables, also metadata

SE, CBSE, Hans van Vliet, 2008

20

Component maintenance

Who is responsible: producer or consumer? Blame analysis: relation between manifestation of a fault and its cause, e.g.
Component A requires more CPU time As a consequence, B does not complete in time As required by C, so C issues a time-out error to its user Analysis: goes from C to B to A to input of A Who does the analysis, if producers of A,B,C are different?

SE, CBSE, Hans van Vliet, 2008

21

Architecture and CBSE

Architecture-driven: top-down: components are identified as part of an architectural design

Product line: family of similar products, with 1 architecture

COTS-based: bottom-up, architecture is secondary to components found

SE, CBSE, Hans van Vliet, 2008

22

Summary

To enable composition, components must be compatible: achieved by component model

Separation of development process for components from that of assembling systems out of components Architectural plan organizes how components fit together and meet quality requirements

SE, CBSE, Hans van Vliet, 2008

23