1

Introduction to Component-Based Software Engineering

Gentilmente cedido porIvica Crnkovic

Mälardalen UniversityDepartment of Computer Science, Sweden

2

The size & complexity of software increases rapidly Single products become part of product families Software is updated after deployment Demands of decreasing time to market Costs of software development increasing

Problems of software development

3

Observations of the practice of software engineering

About 80% of software development deals with changing (adaptation,improvement) of existing software

Time to market is an important completive advantage: Importance of incorporation of new innovations quickly

System should be built to facilitate changes Easy removal and addition of functionality

Systems should be built to facilitate reuse Easy integration of existing functions

Requirements: Provision of approach, technologies to facilitate

Reuse, easy update and modification of software

2

4

Answer: Component-basedDevelopment

Idea: Separate development of components from development of systems

Build software systems from pre-existing components (like buildingcars from existing components)

Building components that can be reused in different applications

Component-based Software engineering - supporting all aspects ofactivities in lifecyle of components and component-based systems

5

Component-based software systems

6

Software Component Definition (I)

Szyperski (Component Software beyond OO programming) A software component is

a unit of composition with contractually specified interfaces and explicit context dependencies only.

A software component can be deployed independently it is subject to composition by third party.

Szyperski

3

Page 7,

Composition unitComposition unitA software component is a unit of composition with contractuallyspecified interfaces and explicit context dependencies only. Asoftware component can be deployed independently and is subjectto composition by third party. –Clemens Szyperski

How much do components fit together?How much does it cost the glue code?

ComponentsGlue code

System

Page 8,

What is a contract?What is a contract?A software component is a unit of composition with contractuallyspecified interfaces and explicit context dependencies only. Asoftware component can be deployed independently and is subjectto composition by third party.

Contract - A specification attached to an interface that mutuallybinds the clients and providers of the components. Functional Aspects (API) Pre- and post-conditions for the operations specified by API. Non functional aspects (different constrains, environment

requirements, etc.)

A component may provide/ implement several interfaces

IBar

IFoo

IFoo2

Page 9,

What is an explicit context dependency?What is an explicit context dependency?A software component is a unit of composition withcontractually specified interfaces and explicit contextdependencies only. A software component can be deployedindependently and is subject to composition by third party.

Context dependencies - Specification of the deploymentenvironment and run-time environment Example: Which tools, platforms, resources or other

components are required?

Do existing component models have support for declaring thedependencies?

Is it possible to verify if the environment comply with the contextrequired?

4

Page 10,

A software component is a unit of composition with contractuallyspecified interfaces and explicit context dependencies only. Asoftware component can be deployed independently and is subjectto composition by third party.

Late binding - dependencies are resolved at load or run-time. Replacing of a component independent of the client (main

application) if the contract is not broken. Delegation - interaction with a weak coupling (for example no

inheritance).

Which problems can occur in relation to late binding?How can we guarantee that a replacement of a component will notaffect other parts of the system?

What does it mean deployed independently?What does it mean deployed independently?

Page 11,

Example: Interface description: (M)IDLExample: Interface description: (M)IDL(Microsoft) Interface Definition Language

[

uuid(00112233-ABBA-ABBA-ABBA-BADBADBADBAD),object

]interface IAddressList {

HRESULT addAddress ([in] name, [in] address);HRESULT deleteAddress ([in] name, [in] address);

}

language independent interface specification can be compiled into language dependent code skeletons

Page 12,

Components and Interfaces - UML definitionComponents and Interfaces - UML definition

Component

Interface

Operation

*

in-interfaces*

*

*

Name

1

1

1 1

1

1

Parameter

1

*

Type

1 *

OutParameterInParameter

InOutParameter

*

out-interfaces

*

Component – a set of interfacesrequired (in-interfaces, the “socket”))provided (out-interfaces, the“lollipop”

Interface – set of operationsOperations – input and output parameters of

certain type

5

Page 13,

Contractually specified interfaces in a UML Contractually specified interfaces in a UML metamodelmetamodel

Interface

Component

*

in-interfaces*

*

out-interfaces

*

State

1 *

Constraint

*

*

* 1

Invariant

1

*

1

*

Operation

*

*

Parameter

1

*

PreCondition

* 1

PostCondition

1 *

1

*

InParameter OutParameter

*

*

*

*

*

*

*

2

Page 14,

Component specificationComponent specification

Components are described bytheir interfaces

(A black box character)

glass boxglass box

black boxblack box

white boxwhite box

grey boxgrey box

15

Another definition

A software component is a software element that confirms a component model can be independently deployed composed without modification according to a

composition standard. A component model defines specific interaction and

composition standards.

G. Heineman, W. Councel, Component-based software engineering, putting thepieces together, Addoson Wesley, 2001

G. Heineman

6

16

Variety of component models

The generalized definition allows different component models In different domains there are different requirements and

constraints Different interactions (architectural styles) Different extra-functional properties Different integration and deployment policies

17

Main principles: (1)Reusability

Reusing components in differentsystems

The desire to reuse a componentposes few technical constraints. Similar systems architecture Good documentation

(component specification…) a well-organized reuse

process ….

C1

C1 C2

C3 C4

Application A1

C1 C5

C6 C7

Application A2

18

Main principles: (2) Substitutability

Alternative implementations of acomponent may be used.

The system should meet itsrequirements irrespective of whichcomponent is used.

Substitution principles Function level Non-functional level

Added technical challenges Design-time: precise definition

of interfaces & specification Run-time: replacement

mechanism

C1 C2

C3 C4

Application A1

C1´ C2

C3 C4

Application A1

7

19

Main principles: (3)Extensibility

Comes in two flavors: Extending system functionality by adding

components that are part of a system Extending system functionality by

increasing the functionality of individualcomponents

Added technical challenges: Design-time: extensible architecture Run-time: mechanism for discovering

new functionality

C1 C2 C3

C1 C2 C4 C3

C1 C2 C3

C1 C2+C4

C3

20

C1

Main principles: (4)Composability

Composition of components P(c1 o c2) =P(c1) o P(c2) ??

Composition of functions Composition of extra-functional properties

Many challenges How to reason about a system composed

from components? Different type of properties Different principles of compositions

C2

assembly

C

21

Compositional Reasoning

Calculating properties of a system bycombining properties of its constituents(components)

Compositional reasoning: Function If P(C) of program C is a

function from input to output (pipe &filter)then the composition is modeled as afunctional composition:

If S = C1 o C2Then P(S) = P(C1) o P(C2)

C1 C2assemblyC

P(C1) P(C2)

8

22

Predictable assembly

Functional composition is not always possible Question with extra-functional properties

Example: dynamic memory usage M If S = C1 o C2

then what is the composition M(S) =M(C1) o M(C2)

M is not defined only by properties M(Ci), butalso on properties of the platform “schedulingpolicy for example”

Information supplied with C1 is not enough

C1 C2assemblyC

P(C1) P(C2)

Platform

Predictable assembly = ability to predict properties of an assembly from properties of the involved components

23

CBSE Terminology

To make the things easier we need first some definitions...

Software Component Component-based systems Component specification Component composition Component and sytsems properties

24

Summary CBSE – basic definitions

The basis is the Component Components can be assembled according

to the rules specified by the componentmodel

Components are assembled through theirinterfaces

A Component Composition is theprocess of assembling components to forman assembly, a larger component or anapplication

Component are performing in the contextof a component framework

All parts conform to the component model A component technology is a concrete

implementation of a component model

c1 c2

Middleware

Run-time systemframework

Component Model

9

25

Component Technology

Component Framework

Platform

Components

Repository

Supporting Tool

26

Component models classifications

Lifecycle. The lifecycle dimension identifies thesupport provided (explicitly or implicitly) by thecomponent model, in certain points of a lifecycle ofcomponents or component-based systems.

Constructs. The constructs dimension identifies (i)the component interface used for the interaction withother components and external environment, and (ii)the means of component binding and communication.

Extra-Functional Properties. The extra-functionalproperties dimension identifies specifications andsupport that includes the provision of property valuesand means for their composition.

Domains. This dimension shows in which applicationand business domains component models are used.

lifecycle

constructs

EFP

Domain A Domain B

27

Classifications

Lifecycle Modeling Implementation Packaging Deployment

Constructs Interface types Interface specification

language Interface Level (signature,

contract-based, semantics) Interaction

EFP General support for properties Properties specification Composition support

Domain Specific General-purpose

10

28

Some of component models

AUTOSAR BIP CCM Fractal KOALA EJB MS COM

MS .NET OSGi PIN PECOS ROBOCOP RUBUS SaveCCM SOFA 2.0 ….

<<component>>Client

<<component>>Server

IdenticalItf

C1wcet1f1

A

C2wcet2f2

Inputports

Outputports System

Sub 1 Sub 2

Page 29,

Component-based software developmentComponent-based software developmentprocessprocess

Page 30,

Time to Market Time to Market –– ““ClassicalClassical”” Development Process? Development Process?

Requirements

Specification

Design

Implementation

Test

Product LifecycleProblems:Problems:••Time To MarketTime To Market••High CostsHigh Costs••Meeting deadlinesMeeting deadlines••VisibilityVisibility

Operation & Maintenance

TIMETIME

11

Page 31,

Development processDevelopment process COTS and outsourcing require different development

processes

Requirements

Specification

Design

Implementation

Test

Find & Select

Adapt

Deploy

Page 32,

Development process Development process –– emphasize reuse emphasize reuse

Managing COTS in the early stage of the developmentprocess

Requirements

Specification

Design

Implementation

Test

Deploy

Find & Select

Adapt

Test

Page 33,

CBDCBD –– separation of development processes separation of development processes

Requirements

Specification

Design

Implementation

Test

Deploy

Find & Select

Adapt

Test

ApplicationApplicationdevelopmentdevelopment

ComponentComponentdevelopmentdevelopment

Operation &Maintenance

12

Page 34,

Types of component-based developmentTypes of component-based development

Internal components as structural entities Reusable components developed in-house COTS (commercial off the shelf) components

Page 35,

Software Architecture and SoftwareSoftware Architecture and SoftwareComponentsComponents

36

Software Architecture and components

Architecture Specification Structure specification Set of interface specification

Systeminterface

System

InterfaceModul

Interface

Modul

InterfaceModul

13

Page 37,

Software ArchitectureSoftware Architecture

L. Bass, P. Clements, R. Kazman, Software Architecture In Practice

The software architecture of a program or computing

system is the structure or structures of the system, which

comprise software components [and connectors], the

externally visible properties of those components [and

connectors] and the relationships among them.”

Page 38,

Two Tier ArchitectureTwo Tier Architecture

Database

Tier Boundary

Presentation--------------Business

Logic

DatabaseDriver

Data Layer

Presentation / Business Layer

Presentation--------------Business

Logic

Page 39,

N-Tier ArchitectureN-Tier Architecture

Database

Tier Boundary

BusinessLogic

DatabaseDriver

BusinessLogic

BusinessLogic

PresentationLogic

Data Layer

Business Layer

Tier BoundaryPresentation Layer

14

Page 40,

N-Tier Architecture - and ComponentsN-Tier Architecture - and Components

Database

Tier Boundary

BusinessLogic

DatabaseDriver

BusinessLogic

BusinessLogic

PresentationLogic

Data Layer

Business Layer

Tier BoundaryPresentation Layer

componentcomponent

componentcomponent

componentcomponent

componentcomponent

41

Distributed Software Components

Hardware

Input/output drivers

Middleware

ECU ECUECU

Applications

Component 1 Component 2

ECU

Page 42,

Aspects of Software ArchitectureAspects of Software Architecture

Connector

RolePort

Attachment

(sub)System

Architectural Component

Representation

Elements and Form (UniCon notation)

15

Page 43,

Different architecture view in different phasesDifferent architecture view in different phases

Phase I System architecture - Decomposition of the system

<<subsystem>>ComAIComA

<<subsystem>>ComBIComB

<<subsystem>>ComCIComC

ConceptualArchitecture

Page 44,

System Design System Design –– Phase 2 Phase 2

Implementation Architecture - Component Identification

<<imp>>ComAIComA

<<imp>>ComBIComB

<<imp>>ComCIComC<<imp>>

SysXISysX<<imp>>

ComYIComY

ImplementationArchitecture

Page 45,

System Design System Design –– Phase 3 Phase 3

Deployment architecture

:ComB:SysX :ComC

:ComA

DeploymentArchitecture

:ComB

Server

DataServer

16

46

Example: Component-based embedded systems

Vehicle mechanics

ECU

Sensor ActuatorSensor

ECU

Sensor ActuatorSensor

ECU

Sensor ActuatorSensor

gateway(CAN) BUS

brake injection

Infotaiment

ECU – Electronic Control Unit

47

sensors

The architectural design challenge

Vehicle

actuators

Engine Control Local brake Control Transmission ……… Localcontrol

Vehicle stability

Cruise control Antispin Global

(complex) functions

Hardware

Input/output drivers

MiddlewareECU ECU ECU

Applications

SOFTWARE COMPONENTS

Collision detection

How to keep efficiency, predictability and reusability?

Artigos para Discussão• Ivica Crnkovic - Component Based Development Process

and Component Life Cycle, 27th International Conference onInformation Technology Interfaces, IEEE, Caretat, Croatia,2005.

• W. Emmerich. Distributed Component Technologies andTheir Software Engineering Implications. In Proc. of the 24thICSE, Orlando, Florida, pages 537-546. ACM Press, May2002.