Component-Based Software Engineering (CBSE) 10. Introductionst.inf.tu-dresden.de/files/teaching/ss15/cbse/slides/10-cbse-introduction.pdf · Mechanical engineering (e.g., German VDI

CBSE, © Prof. Uwe Aßmann 1

Component-Based Software Engineering (CBSE) 10. Introduction 1.  “Staying Power with Composition Systems 2.  Basics of Composition Systems 3.  Historic Approaches to Black-Box

Composition 4.  Gray-Box Composition 5.  Ubiquitous Component Models

1.  The Ladder of Composition Systems 6.  Importance of Composition Systems

Prof. Dr. Uwe Aßmann Technische Universität Dresden

Institut für Software- und Multimediatechnik

http://st.inf.tu-dresden.de 15-0.4, 10.04.15

Prof. U. Aßmann, CBSE 2

The Power of Components

http://upload.wikimedia.org/wikipedia/commons/thumb/1/13/Container_ship_Hanjin_Taipei.jpg/800px-Container_ship_Hanjin_Taipei.jpg

https://en.wikipedia.org/wiki/Container_ship


Goals

►  Understand how to reuse software ►  What is a composition system?

►  The difference of component-based and composition-based systems ►  The difference of component and composition systems ►  What is a composition operator? composition expression? composition

program? composition language?

►  Understand the difference between graybox and blackbox systems (variability vs. extensibility)

►  Understand the ladder of composition systems ►  Understand the criteria for comparison of composition systems


The Destructive Power of Ill-Used Components: The Ariane 5 Launcher Failure

June 4th 1996 Total failure of the Ariane 5 launcher on its maiden flight The following slides are from Ian Summerville, Software Engineering

http://www.astronews.com/news/artikel/2002/12/0212-009.shtml

Credit: DLR/Thilo Kranz (CC-BY 3.0) 2013 http://commons.wikimedia.org/wiki/File:Ariane_5ES_with_ATV_4_on_its_way_to_ELA-3.jpg


Ariane 5 Launcher Failure

■  Ariane 5 can carry a heavier payload than Ariane 4 ■  Ariane 5 has more thrust (Schub), launches steeper

►  37 seconds after a lift-off, the Ariane 5 launcher lost control ■  Incorrect control signals were sent to the engines ■  These swivelled so that unsustainable stresses were imposed on the rocket ■  It started to break up and self-destructed

►  The system failure was a software failure

Ian Summerville, Software Engineering


The Problem of Component Reuse

►  The attitude and trajectory of the rocket are measured by a computer-based inertial reference system ■  This transmits commands to the engines to maintain attitude and direction ■  The software failed and this system and the backup system shut down

►  Diagnostic commands were transmitted to the engines ■  ..which interpreted them as real data and which swivelled to an extreme position

►  Technically: Reuse Problem ■  Integer overflow failure occurred during converting a 64-bit floating point number

to a signed 16-bit integer ►  There was no exception handler ■  So the system exception management facilities shut down the software



Software Reuse Error

►  The erroneous software component (Ada-83) was reused from the Ariane 4 launch vehicle.

►  The computation that resulted in overflow was not used by Ariane 5. ►  Decisions were made in the development

■  Not to remove the facility as this could introduce new faults ■  Not to test for overflow exceptions because the processor was heavily loaded. ■  For dependability reasons, it was thought desirable to have some spare

processor capacity

►  Why not in Ariane 4? ►  Ariane 4 has a lower initial acceleration and build up of horizontal velocity than

Ariane 5 ■  The value of the variable on Ariane 4 could never reach a level that caused

overflow during the launch period.

■  That had been proved (proven component contract for Ariane 4)! ■  The contract was not re-proven for Ariane-5 ■  There was also no run-time check for contract violation in Ariane-5



Obligatory Reading

►  [ISC], Chapter 1, Chapter 2 ►  Douglas McIlroy's home page

http://cm.bell-labs.com/who/doug/ ►  [McIlroy] Douglas McIlroy. Mass Produced Software Components. In

P. Naur and B. Randell, "Software Engineering, Report on a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968", Scientific Affairs Division, NATO, Brussels, 1969, 138-155. http://cm.bell-labs.com/cm/cs/who/doug/components.txt


10.1 „Staying Power“ with Composition Systems

Staying Power [Cusomano, Gawer]


Platforms and Ecosystems

•  „Platforms, not only products“ (Buch „Staying Power“ Michael Cusumano)

•  Markets need market platforms •  With Vendor Lock-In

Platform

Complementors

Platform leader

Chip

Software Providers

Intel, Infineon, AMD


Plattform Leadership

•  Platform leadership und „platform wannabie“ •  Platform can be open or closed •  Platform can be for end users or for developers

App Store

App Providers

Apple, Intel, Google

AutoSAR

Module Providers

BMW, Bosch,...

Eclipse

Plugin Providers

IBM, Itemis, many

Genivi Multimedia Infotainment Platform

Component Providers

Genivi consortium


Software Platforms and Software Ecosystems

Software ecosystems are platforms plus complements (plugins) Interdependent companies and value creation [Gawer/Cusomano] describe 4 levels of software ecosystems:

•  Scope of the firm •  Modularity technology

•  Composition system •  Extensibility concept for complements (plugins) •  IPR strategy •  Interface openness

•  Relationship with external complementors •  Internal organization of the firm


Software Ecosystem

Modularity technlogoy

Scope Rules

Complements App Stores

Platform Leader

Complementors

Third party management

App Services

Software Platforms and Software Ecosystems

Value creation is shared between platform leader and complementor Companies want to be platform leader („platform wannabie“) Apple iPad, iPhone AppStores

Market Rules

Apps Apps Apps


Software Ecosystem

Component Model with plugin concept Plugin Tools

Uncertified App Store Certified App Store

Platform Leader Consortium

Plugin/App Provider

Platform Services

App Services

Apps Apps Apps

Consortial Software Ecosystems a la AutoSAR, GENIVI

Platforms can be owned by a consortium, a steering committee www.autosar.org, www.genivi.org, Android, ..


Software Ecosystems

Domain-independent platform Eclipse RCP, RAP

Platform Domain 1 Business Intelligence

Platform Domain 2 Modeling

Plugin/App Providers

Platform Domain 3 Automotive

Domain-specific platforms

Many more layers possible (platforms and ecosystems)

Layered Platforms and Ecosystems (Eclipse.org)

Eclipse is even layered


Generic Business Model for Software Ecosystems

Rolle Art des Produktes

Financial Physical Intangible Human

Creator Entrepreneur Manufacturer Inventor -

Distributor Financial trader

Wholesaler, Retailer

IP distributor -

Lessor Financial lessor

IP lessor Contractor

Broker Financial broker

IP broker HR broker

[Popp,Meyer; Wei05]


10.2. Basics of Composition Systems

Component-based software engineering is built on composition systems.

A composition system has a component model, a composition technique, and a

composition language.


Motivation for Component-Based Development

►  Development by “divide-and-conquer” (Alexander the Great) ■  Well known in other disciplines

.  Mechanical engineering (e.g., German VDI 2221)

.  Electrical engineering

.  Architecture

►  “Make, reuse or buy” decisions (reuse decisions): ►  Outsourcing to component producers (Components off the shelf, COTS)

►  Reuse of partial solutions ►  Easy configurability of the systems: variants, versions, product families

►  Scaling business by Software Ecosystems ►  Component models and composition systems are the technical basis for all

modern software ecosystems: Linux, Eclipse, AutoSAR, openHAB,…


Mass-produced Software Components

Yet this fragile analogy is belied when we seek for analogues of other tangible symbols of mass production. • There do not exist manufacturers of standard parts, much less catalogues of standard parts. • One may not order parts to individual specifications of size, ruggedness, speed, capacity, precision or character set.

In the phrase `mass production techniques,' my emphasis is on `techniques' and not on mass production plain. Of course mass production, in the sense of limitless replication of a prototype, is trivial for software.

But certain ideas from industrial technique I claim are relevant. • The idea of subassemblies carries over directly and is well exploited. • The idea of interchangeable parts corresponds roughly to our term `modularity,' and is fitfully respected. • The idea of machine tools has an analogue in assembly programs and compilers.

►  Mass Produced Software Components [McIlroy, Garmisch 68, NATO conference on software engineering]: ■  Every ripe industry is based on components, to manage large systems ■  Components should be produced in masses and composed to systems afterwards


Mass-produced Software Components

►  Later McIlroy was with Bell Labs, ■  ..and invented pipes, diff, join, echo (UNIX). ■  Pipes are still today the most employed component system!

►  Where are we today?


“Real” Component Systems

►  Lego ►  Square stones ►  Building plans ►  IC‘s ►  Hardware bus ►  How do they differ from software?


Definitions of Software Components

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 parties.

(ECOOP Workshop WCOP 1997 Szyperski)

A reusable software component is a •  logically cohesive, •  loosely coupled module •  that denotes a single abstraction. (Grady Booch)

A software component is a static abstraction with plugs. (Nierstrasz/Dami)


What is a Software Component?

►  A component is a container with ■  Hidden inner ■  Public outer interface, stating all dependencies explicitly

■  Example: a snippet component is a snippet with ■  Inner: content (most often code snippets/fragments) ■  Outer: variation points, extension points that are adapted during composition

►  Example: a class with provided and required interfaces ►  Inner: methods as usual

►  A component is a reusable unit for composition ►  A component underlies a component model

■  that fixes the abstraction level ■  that fixes the grain size (widget or OS?) ■  that fixes the time (static or runtime?)


What Is A Component-Based System?

►  A component-based system has the following divide-and-conquer feature: ■  A component-based system is a system in which a major relationship between the

components is tree-shaped or reducible. ■  See course Softwaretechnologie-II

►  Consequence: the entire system can be reduced to one abstract node ■  at least along the structuring relationship ►  Systems with layered relations (dag-like relations) are not necessarily component-

based. ■  Because they cannot be reduced

►  Because of the divide-and-conquer property, component-based development is attractive. ►  However, we have to choose the structuring relation and the composition model

►  Mainly, 2 types of component models are known ■  Modular decomposition (blackbox)

■  Separation of concerns (graybox)


Component Systems (Component Platforms)

for description of components

for compositions of components

Component Model Composition Technique

►  We call a technology in which component-based systems can be produced a component system or component platform.

►  A component system has


Composition Systems

Composition

Language for programming-in-the-

large and architecture


►  A composition system has


Classical Component Systems

Architecture Systems

Aspect Systems

View Systems

Darwin BPMN HRC

Aspect/J AOM

Invasive Composition Piccola Gloo

Standard Components Reflection

Architecture as Aspect Connectors

Aspect Separation Crosscutting

Composition Operators

Composition Language

Object-Oriented Systems C++ Java UML components

Objects as Run-Time Components

Modular Systems Modules as Compile- Time Components

Composition Filters Hyperspaces

Software Composition Systems

.NET CORBA Beans EJB ArchJava

The Ladder of Composition Systems

Shell scripts Modula Ada-85


Desiderata for Flexible Software Composition

►  Component Model: ■  How do components look like? ■  Secrets, interfaces, substitutability

►  Composition Technique ■  How are components plugged together, composed, merged, applied? ■  Composition time (Deployment, Connection, ...)

►  Composition Language ■  How are compositions of large systems described? ■  How are system builds managed?

►  Be aware: this list is NOT complete!


Desiderata Component Model

►  CM-M: Modularity ■  M1 Component interfaces and secrets

(information hiding): .  Explicit specification of interfaces

(contact points, exchange points, binding points, variation points, extension points)

.  Explicit specification of dependencies: Provided and required interfaces

.  Location, way of deployment

.  Component lifetime ■  M2 Semantic substitutability

(conformance, contracts) .  CM-M2.1 Syntactic substitutability

(typing) .  CM-M2.2 Functional contracts

(behavioral contracts) .  CM-M2.3 Quality contracts

■  M3 Content .  Component language metamodel

►  CM-P: Parameterization of components to their reuse context (variation interfaces) ■  P1: Variation Points ■  P1.1 Generic type parameters ■  P1.2 Generic program elements ■  P1.3 Property parameterization

►  CM-E: Extension Interfaces ►  E1: Extension points

►  CM-A: Adaptation Interfaces ►  CM-S: Standardization

■  S1 Open standards – or proprietary ones

■  S2 Standard components ■  S3 Standard services


Desiderata Composition Technique

►  CT-C: Connection and Adaptation ■  C1: Automatic Component Adaptation:

adapt the component interface to another interface

■  C2: Automatic Glueing: Generation of glue code for communication, synchronization, distribution. Consists of a sequence of adaptations

►  CT-E: Extensibility ■  E1: Base Class Extension: can base

classes be extended? .  E1.1 Generated factories: can

factories be generated .  E1.2 Generated access layers

■  E2: Views. Use-based extensions: Can a use of a component extend the component?

■  E3: Integrated Extensions. Can extensions be integrated?

►  CT-A: Aspect separation ■  AS1: Aspect weaving: Extension by

crosscutting views ■  AS2: Multiple interfaces of a

component ►  CT-S: Scalability (Composition time)

■  SC1: Binding time hiding ■  SC2: Binding technique hiding

►  CT-M: Metamodelling ■  MM1: Introspection and reflection

(metamodel). Can other components be introspected? The component itself?

■  MM2: Metaobject protocol: is the semantics of the component specified reflectively?

■  CT-I: Tool support for composition ■  Editors, checkers, validators


Desiderata Composition Language

►  CL-C: Product Consistency ■  Variant cleanness: consistent configurations

■  Robustness: absence of run-time exceptions

►  CL-P: Software Process Support ■  Build management automation

►  CL-M: Meta-composition ■  Is the composition language component-based, i.e., can it be composed itself?

■  Reuse of architectures

►  CL-A: Architectural styles (composition styles) ■  Constraints for the composition


10.3 Historical Approaches to Components


The Essence of the 60s-90s: LEGO Software with Black-Box Composition

►  Procedural systems, stream-based systems ►  Modular systems ►  Object-oriented technology ►  Component-based programming

■  CORBA, EJB, DCOM, COM+, .NET, OSGI

►  Architecture languages

Composition recipe

Connectors

Components

Component-based applications


Procedure Systems

►  Fortran, Algol, C ►  The procedure is the static component ►  The activation record the dynamic one ►  Component model is supported by almost all chips directly

■  jumpSubroutine -- return

Seite 34 Uwe Aßmann,

17.07.2003,

Caller

Callee

Linker


Procedures as Composition System



Content: binary code with symbols

Binding points: linker symbols procedures (with parameters) and global variables

Connection by linking object files

Program transformation on object files

Composition time: link-time, static


Modules (Information-Hiding-Based Design a la Parnas)

►  Every module hides the an important design decision behind a well-defined interface which does not change when the decision changes.

We can attempt to define our modules “around” assumptions which are likely to change. One then designs a module which “hides” or contains each one.

Such modules have rather abstract interfaces which are relatively unlikely to change.

Module

Module

Linker ■  Static binding of functional interfaces to each other

■  Concept has penetrated almost all programming languages (Modula, Ada, Java, C++, Standard ML, C#)


Linker

Bound procedure symbols, no glue code

A Linker is a Static Composition Operator

Provided

Required

►  Static linkers compose modules at link time ►  Dynamic linkers at run time


Modules as Composition System



Content: groups of procedures

Binding points: linker symbols procedures (with parameters) and global variables

Connection by linking object files

Program transformation on object files

Composition time: link-time, static


►  Communication can take place once or many times ►  By Calls (singular) or Streams (continuous)

►  UNIX shells offer a component model for streams ■  Extremely flexible, simple ■  Communication with byte streams, parsing and linearizing the objects

►  Component model ■  Content: unknown (depens on parsing), externally bytes ■  Binding points: stdin/stdout/stderr ports

■  More secrets: distribution, parallelism etc

►  Composition technique: manipulation of byte streams ■  Adaptation: filter around other components. Filter languages such as sed, awk, perl ■  Binding time: static, streams are connected

(via filters) during composition

►  Composition languages ■  C, shell, tcl/tk, python, perl… ■  Build management language makefile

UNIX Pipes and Filters (McIlroy)

stdin Filter

Filter

stdout

stderr

stdin

pipe

Prof. U. Aßmann, CBSE 40 Seite 40 Uwe Aßmann,

17.07.2003, sd&m-Konferenz 2003: Web Services

Shells and Pipes as Composition System



Content: unknown (due to parsing), externally bytes

Binding points: stdin/out ports

Secrets: distribution, parallelism

Adaptation: filter around other components

Filter languages such as sed, awk, perl

Binding time: static

C, shell, tcl/tk, python…

Build management language makefile

Version management with sccs rcs cvs


Communication

•  Black-box components communicate either •  Via calls (singular): à algebraic data types, induction •  Via streams (continuous) à coalgebraic data types, coinduction



Object-Oriented Systems

►  Two sorts of components: objects (runtime) and classes (compile time)

■  Objects are instances of classes (modules) with unique identity

■  Objects have runtime state

■  Late binding of calls by search at runtime

Caller Object

dispatch

Callee

Callee

Callee


Object-Oriented Systems

►  Component Model ■  Content: classes (code, static) and objects (values, dynamic)

■  Binding points: .  monomorphic calls (static calls) .  polymorpic calls (dynamically dispatched calls)

►  Composition Technique ■  Adaptation by inheritance or delegation

■  Extensibility by subclassing

►  Composition Language: none



Object-Orientation as Composition System



Content: binary files, objects

Binding points: static and polymorphic calls (dynamically dispatched calls)

Adaptation by inheritance or delegation

Extensibility by subclassing


►  [Pree] An object-oriented framework consists of a set of template classes which can be parameterized by hook classes (parameter classes)

►  Example: Eclipse (see DPF course)

►  This principle can be transferred to many other composition systems

Object-Oriented Systems: Frameworks

Hook class

Framework with Template Classes

Framework hook/ parameter

Actual parameter


O-O Frameworks

►  Component Model ■  Content: sets of classes with open binding points

■  Binding points:

■  Hot spots to exchange the parameter classes (sets of polymorphic methods)

■  Open roles

■  Variation points: 1 out-of n choice

■  Extension points: arbitrarily many extensions

►  Composition Technique ■  Same as OO

►  Compostion language ■  Same as OO


Commercial Component Systems (COTS, Components off the Shelf)

►  CORBA/DCOM/.NET/JavaBeans/EJB ►  Although different on the first sight, turn out to be rather similar

Software bus (mediator, broker, connector)

Caller Object

Callee (Server)


CORBA http://www.omg.org/corba

►  Language independent, distribution transparent ►  interface definition language IDL ►  source code or binary

Client Java

Server C++

Client C

IDL Stub IDL

skeleton IDL Stub

Object Request Broker (ORB), Trader, Services

Object adapter


(D)COM(+), ActiveX http://www.activex.org

►  Microsoft’s model is similar to CORBA. Proprietary ►  DCOM is a binary standard

Client VBasic

Server C++

Client C++

COM stub COM

skeleton COM stub

Monikers, Registry

Server C++

IDL skeleton

Object adapter


Java Enterprise Beans

►  Java only, event-based, transparent distribution by remote method invocation (RMI)

►  source code/bytecode-based

Bean Java

Bean Java

Bean Java

Event InfoBus, RMI

Server C++

IDL skeleton

Object adapter


.NET http://www.microsoft.com

►  Language independent, distribution transparent ►  NO interface definition language IDL (at least for C#) ►  source code or bytecode MSIL ►  Common Language Runtime CLR

Client Java

Server C++

Client C#

.net-CLR .net-CLR .net-CLR

CLR


COTS

►  Component Model ■  Content: binary components

■  Secrets: Distribution, implementation language

■  Binding points are standardized .  Described by IDL languages

.  set/get properties

.  standard interfaces such as IUnknown (QueryInterface)

►  Composition Technique ■  External adaptation for distributed systems (marshalling) and mixed-language

systems (IDL)

■  Dynamic call in CORBA

►  Composition Language ■  e.g., Visual Basic for COM



COTS as Composition System



Content: binary components

Binding points are standardized Described by IDL, Standard interfaces

Secrets: distribution, language

Adaptation for distributed systems (marshalling) and mixed-language systems

Dynamic call in CORBA

VisualBasic for COM



►  Unicon, ACME, Darwin, Reo (research languages) ■  feature an Architecture Description Language (ADL)

■  EAST-ADL, Artop are ADL in Embedded Software ■  BPEL, BPMN in Web Services ►  Split an application into:

■  Application-specific part (encapsulated in components) ■  Architecture and communication (in architectural description in ADL) ■  Better reuse since both dimensions can be varied independently


Connector

Port Interface

Role

Component Model in Architecture Systems

►  Ports abstract interface communication points ■  in(data), out(data) ■  Components may be nested

►  Connectors as special communication components ►  Coordinators as higher-level architectural styles


Architecture can be exchanged independently of components

Port 2

Port 1

Port Port Component

Component

Component

►  Reuse of components and architectures is fundamentally improved


The Composition Language: ADL

►  Architecture language (architectural description language, ADL) ■  ADL-compiler

■  XML-Readers/Writers for ADL. XADL is a new standard exchange language for ADL based on XML

►  Graphic editing of systems ►  Checking, analysing, simulating systems

■  Dummy tests

■  Deadlock checkers

■  Liveness checking


ACME Studio


Architecture Systems as Composition Systems



Source or binary components

Binding points: ports

Adaptation and glue code by connectors

Scaling by exchange of connectors

Architectural language


Web Services and their Languages as Specific ADL

■  Languages: BPEL, BPMN

►  Binding procedure is interpreted, not compiled

►  More flexible than binary connectors:

■  When interface changes, no recompilation and rebinding

■  Protocol-independent

Caller Object

Mediator

Callee (Server)

SOAP interpretation


Web Services as Composition System



Content: not important

Interface Definition Language WSDL

Binding points are described by XML

Binding procedure is interpretation of SOAP

Secrets: distribution, implementation language

Adaptation for distributed systems (marshalling) and mixed-language systems

Glue: SOAP, HTTP

UDDI, BPEL, BPMN


What the Composition Language Offers for the Software Process

►  Communication ■  Client can understand the architecture graphics well ■  Architecture styles classify the nature of a system in simple terms

(similar to design patterns) ►  Design support

■  Refinement of architectures (stepwise design, design to several levels) ■  Visual and textual views to the software resp. the design

►  Validation: Tools for consistency of architectures ■  Are all ports bound? Do all protocols fit? ■  Does the architecture corresponds to a certain style? Or to a model

architecture? ■  Parallelism features as deadlocks, fairness, liveness, ■  Dead parts of the systems

►  Implementation: Generation of large parts of the communications and architecture


Composition recipe

Connectors

Components

Component-based applications

Black-Box Composition


The Essence of Black-Box Composition

►  3 Problems in System construction ■  Variability ■  Extensibility ■  Adaptation

►  In “Design Patterns and Frameworks”, we learned about design patterns to tackle these problems

►  Black-box composition supports variability and adaptation ■  not extensibility




Aspect Systems

View Systems

Darwin BPMN HRC

Aspect/J AOM












.NET CORBA Beans EJB ArchJava




10.4 Gray-box Component Models


Grey-Box Component Models: The Development of the Last Years

►  View-based Programming ►  Component merge (integration) ►  Component extension

►  Aspect-oriented Programming ►  Views can cross-cut components ►  Component distribution

Gray-box composition merges design-time components to run-time components

Black-box composition leaves design-time components

untouched (1:1 relationship)


Structure Media plan

Light plan Water piple plan

Integrated house

Aspects in Architecture


Debugging aspect

Persistence aspect Algorithm

Debugging aspect Persistence aspect

Persistence aspect Debugging aspect

Weaver-Tool

Debugging aspect

Aspects in Software


Aspect Weavers Distribute Advice Components over Core Components

Distributor (Weaver)

►  Aspects are crosscutting ►  Hence, aspect functionality must

be distributed over the core ►  The distribution is controlled by

a crosscut graph Aspect

Core

Crosscut graph


Aspect Systems As Composition Systems



Core- and aspect components

Aspects are relative and crosscutting

Binding points: join points

Adaptation and glue code by weaving

Weaving is distribution

Weaving Language


10.4.1 Full-Fledged Composition Systems


Composition Systems

Component Model


Composition Expressions Composition Programs

Composition Technique Composition Operators

Black-boy: connect, adapt Gray-Box: extend, mixin, merge, weave


Composition Systems

►  All the following composition systems support full black-box and grey-box composition, as well as full-fledged composition languages: ►  Composition filters [Aksit,Bergmans] ►  Hyperspace Programming [Ossher et al., IBM] ►  Piccola [Nierstrasz et al., Berne] ►  Invasive software composition (ISC) [Aßmann] ►  Formal calculi

■  Lambda-N calculus [Dami] ■  Lambda-F calculus [Lumpe]


Client Library

Client Library

Blackbox connection with glue code

Blackbox Composition

Connectors are Composition Operators

Usually, connectors connect (glue) black-box components for communication


Client Library

Client Library

Blackbox connection with glue code

Client Library

Blackbox Composition

Invasive Composition

Connectors can be Grey-Box Composition Operators

Connectors can work invasively, i.e., adapt components inside

Grey-box (Invasive) Connection


Composers Generalize Connectors (ADL Component Model)

Components Composers Variation points Black-Box Components

Connectors, Invasive connectors Encapsulation operators

Ports


inherit

Composers Can Be Used For Inheritance

►  Extension can be used for inheritance (mixins)

►  inheritance := ■  copy first super document; ■  extend with second super

document;

■  Be aware: The composition system of object-oriented frameworks (course DPF) is only one of the possible ones


Composers Generalize Inheritance Operators (Classes as Components)

Components Composers Extension points Classes Mixin operators,

inheritance operators

Class member lists


Composers Generalize View-based Extensions

►  Symmetric view: Two components are merged ►  Asymmetric view: A core component is extended by a view

component

merge extend


Composers Generalize View Extensions

Components Composers Extension points Views Merge operators,

extend operators Open definitions


Composers Generalize Aspect Weavers

Distributor

►  Complex composers distribute aspect fragments over core fragments

►  Distributors extend the core ■  Distributors are more complex

operators, defined from basic ones ■  Distribution is steered by a crosscut

graph

Aspect

Core

Crosscut graph


Weavers Are Complex Distributors

Requirements aspect

Testing aspect

Core (Algorithm)

Op Op Op

Op

Op

Op Op

Testing

Architecture aspect

Architecture


Composers Generalize Aspect Weavers

Components Composers Extension points Core, advice groups

Weaver Join points


Comparison Table

Approach Components Composers Variation/Extension points

Modular systems Modules Static linking Dynamic linking

Linker symbols

Object-oriented systems

Classes Mixin inheritance operator, mixin layer operator, other inheritance operators

Class member lists

Objects Polymorphic dispatch Dynamic invocation Trading

Architecture systems Black-Box Components

Connectors, Invasive connectors Encapsulation operators

Ports

Generic systems Generic Fragments Binding Slots

View systems Views (fragments) Merge operators, extend operators Open definitions

Aspect systems Core, advice groups Weaver Join points

Full composition systems

All of the above Explicit crosscut specifications Slots and join points


Composition Languages in Composition Systems

►  Composition languages describe the structure of the system in-the-large (“programming in the large”) ►  Composition programs combine the basic composition operations of the

composition language

►  Composition languages can look quite different ►  Imperative or rule-based ■  Textual languages

■  Standard languages, such as Java ■  Domain-specific languages (DSL) such as Makefiles or ant-files

■  Graphic languages ■  Architectural description languages (ADL)

►  Composition languages enable us to describe large systems

Composition program size 1 System size 10


Composition Recipe


Grey-box Components

System Constructed with an Invasive Architecture

Invasive Software

Composition

Composition Process in Grey-Box Composition Systems


Conclusions for Composition Systems

►  Components have a composition interface with variation and extension points ■  Composition interface is different from functional interface ■  The composition is running usually before the execution of the system ■  From the composition interface, the functional interface is derived

►  System composition becomes a new step in system build

Composition

•  With composition interfaces

Deployment

•  With functional interfaces

Execution

•  With functional interfaces


10.5 UBIQUITUOUS COMPONENT MODELS


Steps in System Construction

►  We need different component models and composition systems on all levels of system construction

System composition (System generation, design-time composition)

System compilation (compilation-time composition)

Link-time composition

System execution Recomposition at checkpoints

Static time

Run time

System deployment (deployment-time composition)


10.5.1 The Ladder of Composition Systems


Component-based Systems

►  ... are produced by component systems or composition systems ►  ... have a central relationship that is tree-like or reducible ►  ... support a component model ►  ... allow for component composition with composition operators

■  ... and – in the large – with composition languages

►  Historically, component models and composition techniques have been pretty different ■  from compile time to run time

►  Blackbox composition supports variability and glueing ►  Graybox composition supports extensibility, views, aspects ►  Object-orientation is just one of the many composition systems which

have been defined




Aspect Systems

View Systems

Darwin BPMN

Aspect/J AOM












.NET CORBA Beans EJB




10.6. Why Composition Systems are Important

We will take up this topic again. See also the last chapter of the course.


What Can Be Done with Composition Systems?

Composition systems

Frameworks, layered frameworks

Product families (documents, software, models)

Staged architectures (web systems, complex product families)

Software ecosystems (app stores, third-party plugins)

Software ecosystems for CPS (certification)


Layered Frameworks

►  A layered framework is a framework structured into several layers containing components.

►  In a layered framework, products are composed out components of each layer ►  With a component model and composition technique that enables variability and

extensibility ►  With a composition language

►  Layered frameworks can be defined for any component model, not only object-oriented software

Layered Framworks are based on Composition Systems


Product Families (Variant Family, Product Lines)

►  A product family (line) is a consistently managed set of products ►  sharing a common platform (framework) and components, not necessarily

layered ►  With a component model and composition technique that enables variability and

extensibility ►  With a composition language

►  Consistent variation of component variants, while interfaces and contracts are invariant ►  Conformant replacement of components ►  Contract checking for all components of the system

Product Lines are based on Composition Systems


Adaptive Systems (Dynamic Variant Families)

►  Consistent variation of component variants at run-time (reconfiguration), while interfaces and contracts are invariant ►  Conformant replacement of components at run time ►  Dynamic contract negotiation: does the implementation of a new variant fit to a

contract?

►  Reconfiguration is controlled by a cost-utility function (CUF) to arrive at an optimal configuration with regard to a CUF ►  Reconfiguration can be based on multi-objective optimization (MOO)

►  Reconfiguration strategy is important

Adaptive Systems are based on Dynamic Composition Systems


CPS Composition Systems

Cyber-physical systems (CPS) are systems with a real-time representation of the real world in the cyberworld

•  They form systems in the internet of things and services. •  These need quality specifications (real-time, energy, safety, movements) and

need to be quality-verified.

Examples: Robot swarms, Car trains, Virtual factories A Multi-Quality-controlled composition system provides a

component model with quality contracts. •  Quality contracts describe quality features of components, such as real-time

behavior, energy consumption, safety behavior

Cyber-Physical Systems are based on Composition Systems with Quality Contracts


Smart Factory mit CPS

•  Embedded System: maschines, robots, presses, transport systems •  CPS: Autonomous control of the factory •  Self assembly of the products •  Autonomous control of logistics •  Pull of products instead of push


Smart Traffic/Transport/Logistics mit CPS

•  Embedded System: Railcabs are autonomous train cars (Paderborn)

•  CPS: Optimization of the German logistics


Smart Grid

•  Embedded System: Isolated measuring •  CPS: distributed control based on

Smart Metering •  Control of natural energy


The End

Documents

Component-Based Software Engineering (CBSE) 10. Introductionst.inf.tu-dresden.de/files/teaching/ss15/cbse/slides/10-cbse-introduction.pdf · Mechanical engineering (e.g., German VDI