Upload
lamliem
View
221
Download
0
Embed Size (px)
Citation preview
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
Prof. U. Aßmann, CBSE 3
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
Prof. U. Aßmann, CBSE 4
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
Prof. U. Aßmann, CBSE 5
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
Prof. U. Aßmann, CBSE 6
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
Ian Summerville, Software Engineering
Prof. U. Aßmann, CBSE 7
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
Ian Summerville, Software Engineering
Prof. U. Aßmann, CBSE 8
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
CBSE, © Prof. Uwe Aßmann 9
10.1 „Staying Power“ with Composition Systems
Staying Power [Cusomano, Gawer]
Prof. U. Aßmann, CBSE 10
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
Prof. U. Aßmann, CBSE 11
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
Prof. U. Aßmann, CBSE 12
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
Prof. U. Aßmann, CBSE 13
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
Prof. U. Aßmann, CBSE 14
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, ..
Prof. U. Aßmann, CBSE 15
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
Prof. U. Aßmann, CBSE 16
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]
CBSE, © Prof. Uwe Aßmann 17
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.
Prof. U. Aßmann, CBSE 18
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,…
Prof. U. Aßmann, CBSE 19
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
Prof. U. Aßmann, CBSE 20
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?
Prof. U. Aßmann, CBSE 21
“Real” Component Systems
► Lego ► Square stones ► Building plans ► IC‘s ► Hardware bus ► How do they differ from software?
Prof. U. Aßmann, CBSE 22
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)
Prof. U. Aßmann, CBSE 23
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?)
Prof. U. Aßmann, CBSE 24
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)
Prof. U. Aßmann, CBSE 25
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
Prof. U. Aßmann, CBSE 26
Composition Systems
Composition
Language for programming-in-the-
large and architecture
Component Model Composition Technique
► A composition system has
Prof. U. Aßmann, CBSE 27
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
Prof. U. Aßmann, CBSE 28
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!
Prof. U. Aßmann, CBSE 29
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
Prof. U. Aßmann, CBSE 30
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
Prof. U. Aßmann, CBSE 31
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
Prof. U. Aßmann, CBSE 33
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
Prof. U. Aßmann, CBSE 34
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
Prof. U. Aßmann, CBSE 35
Procedures as Composition System
Component Model Composition Technique
Composition Language
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
Prof. U. Aßmann, CBSE 36
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#)
Prof. U. Aßmann, CBSE 37
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
Prof. U. Aßmann, CBSE 38
Modules as Composition System
Component Model Composition Technique
Composition Language
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
Prof. U. Aßmann, CBSE 39
► 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
Component Model Composition Technique
Composition Language
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
Prof. U. Aßmann, CBSE 41
Communication
• Black-box components communicate either • Via calls (singular): à algebraic data types, induction • Via streams (continuous) à coalgebraic data types, coinduction
Prof. U. Aßmann, CBSE 42 Seite 42 Uwe Aßmann,
17.07.2003, sd&m-Konferenz 2003: Web Services
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
Prof. U. Aßmann, CBSE 43
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
Prof. U. Aßmann, CBSE 44 Seite 44 Uwe Aßmann,
17.07.2003, sd&m-Konferenz 2003: Web Services
Object-Orientation as Composition System
Component Model Composition Technique
Composition Language
Content: binary files, objects
Binding points: static and polymorphic calls (dynamically dispatched calls)
Adaptation by inheritance or delegation
Extensibility by subclassing
Prof. U. Aßmann, CBSE 45
► [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
Prof. U. Aßmann, CBSE 46
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
Prof. U. Aßmann, CBSE 47
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)
Prof. U. Aßmann, CBSE 48
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
Prof. U. Aßmann, CBSE 49
(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
Prof. U. Aßmann, CBSE 50
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
Prof. U. Aßmann, CBSE 51
.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
Prof. U. Aßmann, CBSE 52
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
Prof. U. Aßmann, CBSE 53 Seite 53 Uwe Aßmann,
17.07.2003, sd&m-Konferenz 2003: Web Services
COTS as Composition System
Component Model Composition Technique
Composition Language
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
Prof. U. Aßmann, CBSE 54
Architecture Systems
► 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
Prof. U. Aßmann, CBSE 55
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
Prof. U. Aßmann, CBSE 56
Architecture can be exchanged independently of components
Port 2
Port 1
Port Port Component
Component
Component
► Reuse of components and architectures is fundamentally improved
Prof. U. Aßmann, CBSE 57
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
Prof. U. Aßmann, CBSE 59
Architecture Systems as Composition Systems
Component Model Composition Technique
Composition Language
Source or binary components
Binding points: ports
Adaptation and glue code by connectors
Scaling by exchange of connectors
Architectural language
Prof. U. Aßmann, CBSE 60
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
Prof. U. Aßmann, CBSE 61
Web Services as Composition System
Component Model Composition Technique
Composition Language
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
Prof. U. Aßmann, CBSE 62
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
Prof. U. Aßmann, CBSE 63
Composition recipe
Connectors
Components
Component-based applications
Black-Box Composition
Prof. U. Aßmann, CBSE 64
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
Prof. U. Aßmann, CBSE 65
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
Prof. U. Aßmann, CBSE 67
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)
Prof. U. Aßmann, CBSE 68
Structure Media plan
Light plan Water piple plan
Integrated house
Aspects in Architecture
Prof. U. Aßmann, CBSE 69
Debugging aspect
Persistence aspect Algorithm
Debugging aspect Persistence aspect
Persistence aspect Debugging aspect
Weaver-Tool
Debugging aspect
Aspects in Software
Prof. U. Aßmann, CBSE 70
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
Prof. U. Aßmann, CBSE 71
Aspect Systems As Composition Systems
Component Model Composition Technique
Composition Language
Core- and aspect components
Aspects are relative and crosscutting
Binding points: join points
Adaptation and glue code by weaving
Weaving is distribution
Weaving Language
Prof. U. Aßmann, CBSE 73
Composition Systems
Component Model
Composition Language
Composition Expressions Composition Programs
Composition Technique Composition Operators
Black-boy: connect, adapt Gray-Box: extend, mixin, merge, weave
Prof. U. Aßmann, CBSE 74
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]
Prof. U. Aßmann, CBSE 75
Client Library
Client Library
Blackbox connection with glue code
Blackbox Composition
Connectors are Composition Operators
Usually, connectors connect (glue) black-box components for communication
Prof. U. Aßmann, CBSE 76
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
Prof. U. Aßmann, CBSE 77
Composers Generalize Connectors (ADL Component Model)
Components Composers Variation points Black-Box Components
Connectors, Invasive connectors Encapsulation operators
Ports
Prof. U. Aßmann, CBSE 78
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
Prof. U. Aßmann, CBSE 79
Composers Generalize Inheritance Operators (Classes as Components)
Components Composers Extension points Classes Mixin operators,
inheritance operators
Class member lists
Prof. U. Aßmann, CBSE 80
Composers Generalize View-based Extensions
► Symmetric view: Two components are merged ► Asymmetric view: A core component is extended by a view
component
merge extend
Prof. U. Aßmann, CBSE 81
Composers Generalize View Extensions
Components Composers Extension points Views Merge operators,
extend operators Open definitions
Prof. U. Aßmann, CBSE 82
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
Prof. U. Aßmann, CBSE 83
Weavers Are Complex Distributors
Requirements aspect
Testing aspect
Core (Algorithm)
Op Op Op
Op
Op
Op Op
Testing
Architecture aspect
Architecture
Prof. U. Aßmann, CBSE 84
Composers Generalize Aspect Weavers
Components Composers Extension points Core, advice groups
Weaver Join points
Prof. U. Aßmann, CBSE 85
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
Prof. U. Aßmann, CBSE 86
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
Prof. U. Aßmann, CBSE 87
Composition Recipe
Composition Operators
Grey-box Components
System Constructed with an Invasive Architecture
Invasive Software
Composition
Composition Process in Grey-Box Composition Systems
Prof. U. Aßmann, CBSE 88
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
Prof. U. Aßmann, CBSE 90
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)
Prof. U. Aßmann, CBSE 92
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
Prof. U. Aßmann, CBSE 93
Classical Component Systems
Architecture Systems
Aspect Systems
View Systems
Darwin BPMN
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
The Ladder of Composition Systems
Shell scripts Modula Ada-85
CBSE, © Prof. Uwe Aßmann 94
10.6. Why Composition Systems are Important
We will take up this topic again. See also the last chapter of the course.
Prof. U. Aßmann, CBSE 95
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)
Prof. U. Aßmann, CBSE 96
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
Prof. U. Aßmann, CBSE 97
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
Prof. U. Aßmann, CBSE 98
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
Prof. U. Aßmann, CBSE 99
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
Prof. U. Aßmann, CBSE 100
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
Prof. U. Aßmann, CBSE 101
Smart Traffic/Transport/Logistics mit CPS
• Embedded System: Railcabs are autonomous train cars (Paderborn)
• CPS: Optimization of the German logistics
Prof. U. Aßmann, CBSE 102
Smart Grid
• Embedded System: Isolated measuring • CPS: distributed control based on
Smart Metering • Control of natural energy