component models - main characteristics ivica crnkovic

49
Component Models - main characteristics Ivica Crnkovic

Upload: junior-lamb

Post on 18-Jan-2016

219 views

Category:

Documents


0 download

TRANSCRIPT

Component Models- main characteristics

Ivica Crnkovic

Outline

• Motivation and goals for using components in Software

• Basic characteristics of component models

• Classification of component models

• Component models examples

21 Apr 2023 2

Challanges of Software Engineering

Page 3, April 21, 2023

• The size & complexity of software increases rapidly

• Single products become part of product families

• Software is upgraded after deployment

• Time-to marked must decrease significntely

• The costs of (software) products must be reduced

Observations on the practice of SE

Page 4, April 21, 2023

• About 80% of software development deals with changing of existing software

• “It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to changes”

• Darwin

• We need methods that will– Easy incorporate changes– Adaptations– Be able to fast response to the new requirements

Page 5, April 21, 2023

A possible solution: Component-based Development

• Idea:– Build software systems from pre-existing

components (like building cars from existing components)

– Building components that can be reused in different applications

– Separate development of components from development of systems

Page 6, April 21, 2023

• 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.”

Bass L., Clements P., and Kazman R., Software Architecture in Practice,

C1

C4

C2

C5C3

Systems and components – Software Achitectures

21 Apr 2023 7

What is component?• The component case

– Many definitions– Some acknowledge ones:

• software component is a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

Szyperski

• A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard

Heineman and Councill

– Intuitive perception may be quite different at different levels (model, implementation, run-time)

Page 8, April 21, 2023

Composition unitA software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. –Clemens Szyperski

How much components fit together?

How much costs the glue code?

ComponentsGlue code

System

Page 9, April 21, 2023

What is a contract?A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party.

• Contract - A specification attached to an interface that mutually binds the clients and providers of the components.– Functional Aspects (API)– Pre- and post-conditions for the operations specified by API.

A component may provide/ implement several interfaces

IBar

IFoo

IFoo2

Page 10, April 21, 2023

What is an explicit context dependency?

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party.

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

components are required?

Do existing component models have support for declaring the dependencies?

Is it possible to verify if the environment comply with the context required?

Page 11, April 21, 2023

A software component is a unit of composition with contractually specified

interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to 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 not affect other parts of the system?

What does it mean deployed independently?

Page 13, April 21, 2023

Components 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)provided (out-interfaces)

Interface – set of operationsOperations – input and output parameters of certain type

Page 14, CBSE – graduate

course

Example: Specification of a COM component

interface ISpellCheck : IUnknown{

HRESULT check([in] BSTR *word, [out] bool *correct);};

interface ICustomSpellCheck : IUnknown{

HRESULT add([in] BSTR *word);HRESULT remove([in] BSTR *word);

};

library SpellCheckerLib{

coclass SpellChecker{

[default] interface ISpellCheck; interface ICustomSpellCheck;

};};

Page 15, CBSE – graduate

course

Semantic Specification

• Extension of syntactic specification• A state model is associated with each interface• Operations have pre- and post-conditions

– pre: state * in-parameters -> bool– post: state * state * in-parameters * out-parameters -> bool

• Invariants on an interface’s state model– state -> bool

• Intra-interface conditions for components– state1 * state2 * … -> bool

Page 16, CBSE – graduate

course

Example: UML Component Specification

check(in word : String, out correct : Boolean) : HRESULT

«interface type»ISpellCheck String

1

words

*

add(in word : String) : HRESULTremove(in word : String) : HRESULT

«interface type»ICustomSpellCheck

1

words

*

String

«comp spec»SpellChecker

ISpellCheck

ICustomSpellCheck

Page 17, CBSE – graduate

course

Example: Object Constraint Language (OCL)

context ISpellCheck::check(in word : String, out correct : Boolean) : HRESULTpre:

word <> “”post:

SUCCEEDED(result) implies correct = words->includes(word)

context ICustomSpellCheck::add(in word : String) : HRESULTpre:

word <> “”post:

SUCCEEDED(result) implies words = words@pre->including (word)

context SpellCheckerISpellCheck::words = ICustomSpellCheck::words

Page 18, April 21, 2023

Contractually specified interfaces in a UML metamodel

Interface

Component

*

in-interfaces*

*

out-interfaces

*

State

1 *

Constraint

*

*

* 1

Invariant

1

*

1

*

Operation

*

*

Parameter

1

*

PreCondition

* 1

PostCondition

1 *

1

*

InParameter OutParameter

*

*

*

*

*

*

*

2

Finally- components have attributes

• Extra functional properties– Memory size– Requires CPU– …– Performance

• Response time• Execution time

– Quality attributes• Reliability• Avaliability

21 Apr 2023 19ICAT Sarajevo - 2007-10-29

Components and properties

21 Apr 2023 20

21 Apr 2023 21

Different solutions

• A plethora of CB models (with many different characteristics)

<<component>>

Client

<<component>>

ServerIdenticalItf

C1wcet1f1

A

C2wcet2f2

Inputports

Outputports

AUTOSARBIPCOMDESCCACorba CMEJBFractalKOALAKobrA

MS COMOpenComOSGi PINPECOSROBOCOPRUBUSSaveCCMSOFA 2.0

21 Apr 2023 ICATSarajevo - 2007-10-29 22

Questions– What is common to component models?

– It is possible to identify common principles and common features?

– Is it possible to utilize/instantiate these principles for particular component models in particular domains?

21 Apr 2023 23

Definitions: Software Component – Component Model

Definition: • A Software Component is a software building block that conforms to

a component model. • A Component Model defines standards for

– (i) properties that individual components must satisfy and – (ii) methods, and possibly mechanisms, for composing components.

Classification• (i) Commonalities, (ii) Differences

• Different approaches– Specification of Meta model

– List of characteristics

– Identification of categories and their characteristics

• Component SpecificationC = <{Interfaces}, {Properties}>

• Component Composition:

C = C1 C2

Interaction (Interface composition): I(C) = I(C1) I(C2)

Property composition: Pi(C) = Pi(C1) Pi(C2)• Component Lifecycle

21 Apr 2023 24

21 Apr 2023 25

The Classification Framework - Categories

• Lifecycle. The lifecycle dimension identifies the support provided (explicitly or implicitly) by the component model, in certain points of a lifecycle of components or component-based systems.

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

• Extra-Functional Properties. The extra-functional properties dimension identifies specifications and support that includes the provision of property values and means for their composition.

• Domains. This dimension shows in which application and business domains component models are used.

lifecycle

EFP

Domain A Domain B

The component-based development process

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Verify

Store

System Development

Component Assessment

Component Development

Select

Find

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Verify

Store

System Development

Component Assessment

Component Development

Select

Find

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Verify

Store

System Development

Component Assessment

Component Development

Select

Find

The Component lifecycle

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Verify

Store

System Development

Component Assessment

Component Development

Select

Find

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Verify

Store

System Development

Component Assessment

Component Development

Select

Find

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Requirements

Design

Test

Release

Maintenance

Implementation

Integration

Verify

Store

System Development

Component Assessment

Component Development

Select

Find

Component lifecycle

21 Apr 2023 ICAT Sarajevo - 2007-10-29 28

Component lifecyclerequirementsrequirements

modellingmodelling

implementationimplementation

packagingpackaging

deploymentdeployment

ExecutionExecutionSpecification• Interface• Models• Meta data

Specification• Interface• Models• Meta data

Code• Source code• Executable code• Executable models

Code• Source code• Executable code• Executable models

Storage• Repository• Package• Meta data

Storage• Repository• Package• Meta data

InstalledFilesInstalledFiles

ExecutablecodeExecutablecode

Component forms

Constructs – components Interactions

• Specification of– Interface

– Composition (interaction)

21 Apr 2023 30

<<component>>

Client

<<component>>

Client

<<component>>

Server

Double role of Interface

Constructs – Interface Specification

Categories

• Levels– - Syntactic

-Semantic- Behavioral

• Specification language

• Distinquish– Provide

– Require

• Interface type– Operation-based

– Port-based

21 Apr 2023 31

<<component>>

Client

<<component>>

Client

<<component>>

Client

21 Apr 2023 32

Constructs – compositions (I)

<<component>>

Client

Architectural style

(client-server, pipe-filter)

Communication type

(synchronous, asynchronous)

<<component>>

Server

21 Apr 2023 33

Constructs compositions (II)

<<component>>

Client

<<component>>

Server

Exogenous

<<component>>

Client

<<component>>

Server

<<Connector>>In between

<<component>>

Server

Endogenous

C1.x = C2.y

a = C2.yC1.x = a

21 Apr 2023 34

Constructs compositions (III)Composition

Horizontal<<component>>

Client

<<component>>

Server

<<component>>Server

Vertical

<<component>>

Client

<<component>>

Server

Constructs classification

• Interface– operation-based/port-based– provides/requires

– The interface level (syntactic, semantic, behaviour)

– distinctive features

• Connections– Architectural Style– Communication type (synchronous/asynchronous)– Binding type

• Endogenous, Exogenous• Vertical, horisontal

21 Apr 2023 35

21 Apr 2023 36

Extra-Functional Properties

• Management of extra-functional properties– Does a component provide any support for extra-functional

properties?– What are the mechanisms?– Which properties are managed?

• Composition of extra-functional properties– P(C1 o C2) = P(C1) o P(C2)– What kind of composition is supported?– Which properties?

Component Execution Platform

component component

EFP Management EFP Management

Component Execution Platform

EFP Management

component component

Component Execution Platform

component

EFP Management

EFP Management EFP Management

component

Component Execution Platform

component

EFP Management EFP Management

component

EFP Managed systemwideEFP Managed per collaboration

Exogenous EFPmanagement

Endogenous EFPmanagement

A B

C D

Component Execution Platform

component component

EFP Management EFP Management

Component Execution Platform

EFP ManagementEFP Management

component component

Component Execution Platform

component

EFP ManagementEFP Management

EFP ManagementEFP Management EFP ManagementEFP Management

component

Component Execution Platform

component

EFP ManagementEFP Management EFP ManagementEFP Management

component

EFP Managed systemwideEFP Managed per collaboration

Exogenous EFPmanagement

Endogenous EFPmanagement

A B

C D

Management of EFP

EPF – composition types (I)

1. Directly composable properties.

2. Architecture-related properties

3. Derived properties.

4. Usage-depended properties.

5. System environment context properties.

21 Apr 2023 38

EPF – composition types (II)

1. Directly composable properties. A property of an assembly is a function of, and only of, the same property of the components involved.

– P(A) = f(P(C1),…P(Ci),…,P(Cn))

2. Architecture-related properties. A property of an assembly is a function of the same property of the components and of the software architecture.

– P(A) = f(SA, …P(Ci)…), i=1…n

– SA = software architecture

21 Apr 2023 39

EPF – composition types (III)3 Derived properties. A property of an assembly depends on several

different properties of the components. – P(A) = f(SA, …Pi(Cj)…), i=1…m, j=1…n– Pi = component properties– Cj = components

4 Usage-depended properties. A property of an assembly is determined by its usage profile. – P(A,U) = f(SA, …Pi(Cj,U)…), i=1…m, j=1…n – U = Usage profile

5 System environment context properties. A property is determined by other properties and by the state of the system environment.– P(S,U,X) = f(SA, …Pi(Cj,U,X)…), i=1…m, j=1…n – S= system, X = system context

21 Apr 2023 40

21 Apr 2023 41

DomainsApplications and business domain of the Component Models

• General-purpose:– Basic mechanisms for the production and the composition of

components – Provide no guidance, nor support for any specific architecture.

• Specialised:– Specific application domains

(i.e. consumer electronics, automotive, …)

• Generative:– Instantiation of particular component models– Provide common principles and some common parts of technologies

(for example modelling)– Other parts are specific (for example different implementations)

21 Apr 2023 42

21 Apr 2023 43

Illustration of the Classification Framework use

• Survey of 20 component models

• Selection of documentation for each component model– Satisfies criteria– Disponibility the definition (Interfaces, composition)

– Some points in the table have been subject our interpretation.

21 Apr 2023 44

Chosen component models

• AUTOSAR

• BIP

• COMDES

• Common Component Architecture (CCA)

• CompoNETS

• CORBA Component Model (CCM)

• The Entreprise JavaBeans (EJB

• Fractal

• The K-Component Model

• KobrA

• Koala

• PIN

• Microsoft Component Object Model (COM)

• OpenCOM • The Open Services Gateway

Initiative (OSGi) • Palladio• Pin • Robocop • Rubus • SaveCCM

21 Apr 2023 45

Lifecycle table Component

ModelsModelling Implementation Packaging Deployment

AUTOSAR N/A C Non-formal specification of container At compilation

BIPA 3-layered representation: behavior, interaction,

and priorityBIP Language N/A At compilation

BlueArX N/A C N/A At compilation

CCM N/A Language independentDeployment Unit archive

(JARs, DLLs)At run-time

COMDES II ADL-like language C N/A At compilation

CompoNETS Behavour modeling (Petri Nets) Language independentDeployment Unit archive

(JARs, DLLs)At run-time

EJB N/A Java EJB-Jar files At run-time

FractalADL-like language

(Fractal ADL, Fractal IDL), Annotations (Fractlet)

Java (in Julia, Aokell)C/C++ (in Think)

.Net lang. (in FracNet)File system based repository At run-time

KOALA ADL-like languages (IDL,CDL and DDL) C File system based repository At compilation

KobrA UML Profile Language independent N/A N/A

IEC 61131Function Block Diagram (FBD)

Ladder Diagram (LD)Sequential Function Chart (SFC)

Structured Text (ST)Instruction List (IL)

N/A At compilation

IEC 61499 Function Block Diagram (FBD) Language independent N/A At compilation

JavaBeans N/A Java Jar packages At compilation

MS COM N/A OO languages DLLAt compilation and at run-

timeOpenCOM N/A OO languages DLL At run-time

OSGi N/A Java Jar-files (bundles)At run-time and at

compilationPalladio UML profile Java N/A At run-timePECOS ADL-like language (CoCo) C++ and Java Jar packages or DLL At compilation

Pin ADL-like language (CCL) C DLL At compilationProCom ADL-like language, timed automata C File system based repository At compilation

ROBOCOP ADL-like language, resource management model C and C++ Structures in zip filesAt compilation and at run-

timeRUBUS Rubus Design Language C File system based repository At compilation

SaveCCM ADL-like (SaveComp), timed automata C File system based repository At compilationSOFA 2.0 Meta-model based specification language Java Repository At run-time

21 Apr 2023 46

Lifecycle table Component

ModelsModelling Implementation Packaging Deployment

AUTOSAR N/A CN/A

At compilation

BIP

A 3-layered representation:

behavior, interaction and priority

Source code, implementation in

BIP languageN/A

At compilation

CCM

Abstract model:OMG-IDL,

Programming model: CIDL

Language independent.

Deployment Unit archive

(JARs, DLLs)At run-time

Fractal

ADL-like language (Fractal ADL, Fractal

IDL), Annotations (Fractlet)

Julia, Aokell(Java)Think(C/C++)FracNet(.Net)

File system based repository

At run-time

KOALAADL-like languages

(IDL,CDL and DDL)C

File system based repository

At compilation

EJB N/A Java binary code EJB-Jar files At run-time

21 Apr 2023 47

Constructs table - Interface

ComponentModels

Interface type

Distinction of

Provides / Requires

Distinctive featuresInterface Language

Interface Levels

(Syntactic,Semantic,

Behaviour)

AUTOSAROperation-

basedPort-based

Yes AUTOSAR Interface* C header files Syntactic

BIP Port-based No Complete interfaces,Incomplete interfaces

BIP LanguageSyntacticSemanticBehaviour

BlueArX Port-based Yes N/A C Syntactic

CCMOperation-

basedPort-based

YesFacets and receptaclesEvent sinks and event

sources

CORBA IDL, CIDL Syntactic

COMDES II Port-based Yes N/AC header filesState charts diagrams

SyntacticBehaviour

CompoNETS

Operation-based

Port-basedYes

Facets and receptaclesEvent sinks and event

sources

CORBA IDL, CIDL,

Petri netsSyntacticBehaviour

EJB Operation-based No N/A

Java Programming Language + Annotations

Syntactic

Fractal Operation-based Yes Component Interface,

Control Interface

IDL, Fractal ADL, or Java or

C, Behavioural

Protocol

SyntacticBehaviour

KOALA Operation-based Yes Diversity Interface,

Optional InterfaceIDL, CDL Syntactic

21 Apr 2023 48

Constructs table - interactionCOMPONENT

MODELSINTERACTION

STYLESCOMMUNICATION

TYPE

BINDING TYPE

EXOGENOUS HIERARCHICAL

AUTOSAR Request response, Messages passing

Synchronous, Asynchronous No Delegation

BIPTriggering

Rendez-vous, Broadcast

Synchronous, Asynchronous No Delegation

BlueArX Pipe&filter Synchronous No Delegation

CCM Request response, Triggering

Synchronous, Asynchronous No No

COMDES II Pipe&filter Synchronous No No

CompoNETS Request response Synchronous, Asynchronous No No

EJB Request response Synchronous, Asynchronous No No

Fractal Multiple interaction styles

Synchronous, Asynchronous Yes Delegation,

Aggregation

KOALA Request response Synchronous No Delegation, Aggregation

21 Apr 2023 49

EFPComponent

ModelsManagement of EFP Properties specification

Composition and analysis support

BlueArX Endogenous per collaboration (A) Resource usage, Timing properties N/A

EJB 3.0 Exogenous system wide (D) N/A N/A

Fractal Exogenous per collaboration (C)Ability to add properties (by adding

“property” controllers)N/A

KOALA Endogenous system wide (B) Resource usage Compile time checks of resources

KobrA Endogenous per collaboration (A) N/A N/A

Palladio Endogenous system wide (B) Performance properties specification Performance properties

PECOS Endogenous system wide (B)Timing properties, generic

specification of other propertiesN/A

Pin Exogenous system wide (D) Analytic interface, timing propertiesDifferent EFP composition theories, example latency

ProCom Endogenous system wide (B) Timing and resources Timing and resources at design

and compile time

Robocop Endogenous system wide (B)Memory consumption, Timing

properties, reliability, ability to add other properties

Memory consumption and timing properties at deployment

Rubus Endogenous system wide (B) Timing Timing properties at design time

SaveCCM Endogenous system wide (B)Timing properties, generic

specification of other propertiesTiming properties at design time

SOFA 2.0 Endogenous system wide (B) Behavioural (protocols) Composition at design

21 Apr 2023 50

Domains

21 Apr 2023 51

Conclusion• From the results we can recognize some recurrent patterns such as

– general-purpose component models utilize client-server style

– Specialized domains (mostly embedded systems) pipe & filter is the predominate style.

– Composition of extra-functional properties is rather scarce.

– Behaviour & Semantic rarely supported

– Almost never repository