Component models main characteristics
This presentation is the property of its rightful owner.
Sponsored Links
1 / 46

Component Models - main characteristics PowerPoint PPT Presentation


  • 111 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Component Models - main characteristics

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


Component models main characteristics

Component Models- main characteristics

Ivica Crnkovic


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 = words@pre->including (word)

    context SpellChecker

    ISpellCheck::words = ICustomSpellCheck::words

    CBSE – graduate course


    Contractually specified interfaces in a uml metamodel

    Contractually specified interfaces in a UML metamodel


    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


    Components and properties

    Components and properties


    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


    The component based development process

    The component-based development process


    The component lifecycle

    The Component lifecycle


    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?


    Management of efp

    Management of EFP


    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


    Lifecycle table

    Lifecycle table


    Lifecycle table1

    Lifecycle table


    Constructs table interface

    Constructs table - Interface


    Constructs table interaction

    Constructs table – interaction


    Component models main characteristics

    EFP


    Domains

    Domains


    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


  • Login