component models main characteristics
Download
Skip this Video
Download Presentation
Component Models - main characteristics

Loading in 2 Seconds...

play fullscreen
1 / 46

Component Models - main characteristics - PowerPoint PPT Presentation


  • 160 Views
  • Uploaded on

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. Challanges of Software Engineering.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Component Models - main characteristics' - armand


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
outline
Outline
  • Motivation and goals for using components in Software
  • Basic characteristics of component models
  • Classification of component models
  • Component models examples
challanges of software engineering
Challanges of Software Engineering
  • 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
Observations on the practice of SE
  • 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
a possible solution component based development
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
what is software component
What is software component?
  • Many definitions
  • Intuitive perception may be quite different at different levels (model, implementation, run-time)
  • 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

composition unit
Composition unit

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. –Clemens Szyperski

How much components fit together?

How much costs the glue code?

System

Glue code

Components

what is a contract

IBar

IFoo

IFoo2

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.

A component may provide/ implement several interfaces

what is an explicit context dependency
What is an explicit context dependency?

A software component is a unit of composition with contractuallyspecified 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?
what does it mean deployed independently
What does it mean deployed independently?

A software component is a unit of composition with contractuallyspecified interfacesand 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).
components and interfaces uml definition
Components and Interfaces - UML definition

Component – a set of interfaces

required (in-interfaces)

provided (out-interfaces)

Interface – set of operations

Operations – input and output

parameters of certain type

example specification of a com component
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;

};

};

CBSE – graduate course

semantic specification
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

CBSE – graduate course

example object constraint language ocl
Example: Object Constraint Language (OCL)

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

pre:

word <> “”

post:

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

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

pre:

word <> “”

post:

SUCCEEDED(result) implies words = [email protected]>including (word)

context SpellChecker

ISpellCheck::words = ICustomSpellCheck::words

CBSE – graduate course

finally components have attributes
Finally- components have attributes
  • Extra functional properties
    • Memory size
    • Requires CPU
    • Performance
      • Response time
      • Execution time
    • Quality attributes
      • Reliability
      • Avaliability

ICAT Sarajevo - 2007-10-29

different solutions

<<component>>

Client

<<component>>

Server

A

Output

ports

Input

ports

C1wcet1f1

C2wcet2f2

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

MS COM

OpenCom

OSGi PIN

PECOS

ROBOCOP

RUBUS

SaveCCM

SOFA 2.0

AUTOSAR

BIP

COMDES

CCA

Corba CM

EJBFractal

KOALA

KobrA

IdenticalItf

questions
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?

ICATSarajevo - 2007-10-29

definitions software component component model
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.
a classification framework for component model

A Classification framework for component model

Based on Ivica Crnkovic, Séverine Sentilles, Aneta Vulgarakis, and Michel

Chaudron. ”A Classification Framework for Component Models”. Accepted

to IEEE Transactions on Software Engineering (in the process of

revision).

motivation
Motivation
  • 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?
  • Goal:
    • Increase the understanding of the basic concepts of component models
    • Easier differentiate and group component models according to several characteristics
classification
Classification
  • (i) Commonalities,
  • (ii) Differences
  • Different approaches
    • Specification of Meta model
    • List of characteristics
    • Identification of categories and their characteristics
the classification framework dimensions 3 1
The Classification Framework - Dimensions 3+1

EFP

  • 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.
  • Construction. The construction dimension identifies (i) the component interface used for the interaction with other components and external environment, and (ii) the means of establishing interaction between the components(binding) and means for intercommunication (interactions).
  • 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.

construction

lifecycle

Domain A

Domain B

i lifecycle dimension
I. Lifecycle dimension

Component lifecycle

deployment

requirements

modelling

implementation

packaging

execution

  • Specification
  • Interface
  • Models
  • Meta data
  • Code
  • Source code
  • Executable code
  • Executable models
  • Storage
  • Repository
  • Package
  • Meta data

Installed

Files

Executable

code

Component forms in a component lifecycle

ii construction dimension
II. Construction dimension
  • Includes 3 parts:
    • Connection points i.e. interfaces
    • Mechanisms for establishing interaction i.e. binding
    • Communication i.e. interaction
1 interface

<<component>>

Client

1. Interface

C3

C1

C2

  • provided interface
  • Defines a set of actions that are understood by both the provider component and the user component
      • Provided interface- actions that the interface provides to the environment
      • Required interface – requires from the environment
  • Two types of interfaces:
      • Operation-based (e.g. method invocation)
      • Port-based (e.g. data passing)

C1

C3

  • required interface

C2

trigger2

trigger0

trigger3

trigger1

trigger2’

data1

trigger3’

trigger0’

trigger2’’

function0()

function1()

trigger1’

trigger3’’

function2()

  • operation-based
  • port-based
1 interface cont d

<<component>>

Client

<<component>>

Server

1. Interface (cont’d)

Interface specification (IDL, state charts, programming languages, etc.)

Dinstictive features

E.g. special types of ports, optional operations, …

Interface levels – compatability checking between interfaces i.e. contract

Syntatic level – type checking

Semantic level – value checking (pre- and post-conditions and invariants)

Behavior level – dynamic behavior of component services

Syntactic

Semantic

Behaviour

Interface levels

2 binding

Horizontal

<<component>>

Client

<<component>>

Server

<<component>>

Server

<<component>>

Client

<<component>>

Server

Vertical

2. Binding
  • Enables connection of components through their interfaces and interaction channels
  • Can an assembly, i.e. set of components mutually connected, be treated as a component itself?
2 binding cont d

<<component>>

Client

<<component>>

Server

<<component>>

Client

<<component>>

Server

<<Connector>>

In between

<<component>>

Server

2. Binding (cont’d)

Endogenous

client.x = server.y

Exogenous

a = server.y

client.x = a

  • Binding does not need to be one-to-one direct connection between two components
3 interaction

<<component>>

Client

<<component>>

Server

3. Interaction

Architectural style

(request-response, pipe-filter)

Communication type

(synchronous, asynchronous)

  • Components communicate with each other through different architectural (interaction) styles
    • E.g. pipe and filter, request-response, broadcast, blackboard, etc.
construction classification
Construction classification
  • Interface
    • operation-based/port-based
    • provides/requires
    • interface specification
    • distinctive features
    • interface level (syntactic, semantic, behaviour)
  • Binding
    • vertical, horizontal
    • endogenous, exogenous
  • Interaction
    • architectural style
    • communication type (synchronous/asynchronous)
iii extra functional properties dimension
III. Extra-functional properties dimension
  • Management of extra-functional properties
    • Does a component provide any support for management of extra-functional properties?
    • What are the mechanisms?
    • Which properties are managed?
  • Extra-functional properties specification
    • Does the component model contains means for specification of EFP properties?
    • Which properties?
  • Composition of extra-functional properties
    • P(C1 o C2) = P(C1) o P(C2)
    • What kind of composition is supported?
    • Which properties?
iv domains
IV. Domains
  • General-purpose:
      • Basic mechanisms for specification and composition of components
      • Provide no guidance, nor support for any specific architecture.
  • Specialized:
      • 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)
illustration of the classification framework use
Illustration of the Classification Framework use
  • List of 23 component models that have been classified according to the classification framework
    • AUTOSAR
    • BIP
    • BlueArX
    • COMDES II
    • CompoNETS
    • CCM
    • EJB
    • Fractal
    • Koala
    • KobrA
    • IEC 61131
    • JB
  • Microsoft COM
  • OpenCOM
  • OSGi
  • Palladio
  • Pecos
  • Pin
  • ProCom
  • Robocop
  • Rubus
  • SaveCCM
  • SOFA
conclusion
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
ad