Component Bas ed Des ign
Dr. Uwe Aßmann
P elab
L inköpings Univers itet
Dr. Uwe Aßmann
1
Contents
q
q
q
q
q
q
What is a component?
R equirements for compos ition s ys tems
His toric approaches
Architecture s ys tems and architecture-bas ed des ign
As pect-oriented s ys tems and des ign
Compos ition S ys tems
Dr. Uwe Aßmann
2
1
L iterature
q
q
q
q
q
q
q
q
C. S zypers ki. Component S oftware. B eyond object-oriented
computing. Addis on-Wes ley.
Journal S oftware - T ools and T echniques . S pecial E dition on
Componentware, 1998. S pringer.
R . Orfali, D. Harkey: Client/S erver programming with Java and
Corba. Wiley&S ons . E as y to read.
COR B A. Communications of the ACM, Oct. 1998. All Articles .
S ametinger: S oftware R eengineering with R eus able Components .
S pringer 1998.
Hofmeis ter et.al. S oftware Architecture with UML . Addis onWes ley.
(W. P ree: S oftware development with F rameworks . dpunkt-Verlag.)
(F . Griffel. Componentware. dpunkt-Verlag. In German. L ots of
material)
Dr. Uwe Aßmann
3
Motivation for Component Bas ed Development
q
q
q
q
q
¿
¿
¿
¿
Divide-and-conquer (Alexander the Great)
Well known in other dis ciplines
mechanical engineering DIN 2221
electrical engineering
architecture
Outs ourcing to component producers (components off the s helf,
COT S )
R eus e of partial s olutions : ins tead of new s olution
E as y configurability of the s ys tems
variants , vers ions , product families
Dr. Uwe Aßmann
4
2
Motivation: R eus e
'OAL COST
REDUCTION
Reuse rates
Time [m.m.]
# Developers
Costs per l.o.c. [DM]
Lines per m.m.
Savings [DM]
Savings
0%
81,5
8
70
165
-
25%
45
6
37
263
~ 400.000
~ 45%
50%
32
5
28
370
~ 560.000
~ 60%
From: C. Jones, The )MPACT OF 2EUSABLE -ODULES AND &UNCTIONS, in
0ROGRAMMING 0RODUCTIVITY, Mc Graw Hill, 1986
q
¿
¿
s ize of clas s libraries
JDK 1.1: ca 1,650 clas s es
JDK 1.2: ca 4,000 clas s es
Dr. Uwe Aßmann
5
Dr. Uwe Aßmann
6
Other Goals
q
q
q
¿
¿
¿
¿
¿
¿
¿
¿
¿
P roduct quality
quality improvement
effectivity by concentration to optimizations
reliability
prolongation life time
flexibilization
Improvements in the s oftware proces s
productivity
almos t prototype cons truction
s imulation of architectures
Documentation
clear s ys tem s tructures
3
Mas s -produced S oftware Components
q
q
q
¿
¿
¿
Garmis ch 68, NAT O conference on s oftware, defines the
terms
S oftware cris is
S oftware engineering
McIlroy:
every ripe indus try is bas ed on components , s ince thes e allow
to manage large s ys tems
¿
components s hould be produced in mas s es and compos ed to
s ys tems afterwards
¿
L ater McIlroy what with B ell L abs , and invented pipes , diff, join,
echo (UNIX).
Ž
P ipes are s till today the mos t employed component s ys tem!
Where are we today?
Dr. Uwe Aßmann
7
S ome “R eal” Component S ys tems
Lego
S quare s tones
Building plans
IC‘s
Hardware bus
How do they differ from
s oftware?
Dr. Uwe Aßmann
8
4
Grey B ox
Comp.
L anguage
Integrational S ys tems
Compos ition S ys tems
Compos ition
L anguage
Invas ive Compos ition
p-calculus
S ys tems with
Compos ition Operators
Compos ition
Operators
As pect S ys tems
As pect S eparation
lN-calculus
Hypers lices
S OP
As pect/J
Architecture as As pect
Darwin
Aes op
Clas s ical
Component S ys tems
S tandard Components
DCOM COR B A
Object-Oriented S ys tems
Objects as
R un-T ime Components
C++
Modules as CompileT ime Components
Modula
Architecture S ys tems
B lack B ox
Many integration
techiques
Uniform on XML
Compos ition
L anguage
B eans /E JB
Modular S ys tems
Java
S ather
Ada-85
C..
S oftware Compos ition
#OMPONENT -ODEL
#OMPOSITION 4ECHNIQUE
#OMPOSITION ,ANGUAGE
Dr. Uwe Aßmann
10
5
Des iderata for F lexible S oftware Compos ition
q
q
q
q
¿
¿
¿
¿
¿
¿
Component Model
How do components look like?
Interfaces , binding points , connection points
Compos ition T echnique
How are components plugged together, compos ed, merged,
applied?
Component L anguage
How are compos itions of large s ys tems des cribed?
T hous ands of components ?
How are s ys tem builds managed?
B e aware: this lis t is NOT complete!
Dr. Uwe Aßmann
11
Des iderata Component Model
q
¿
Modular exchange of components
Component s ecrets (information hiding): explicit s pecification of
interfaces (contact points , exchange points , binding points )
¿
¿
¿
q
q
¿
¿
S yntactic s ubs titutability (typing)
S emantic s ubs titutability (conformance, contracts )
T rans parency
Ž
Dis tribution, s ervice-identity, programming language, pers is tency
Ž
Migration (mobility)
P arameterization of components to their reus e context
Open implementation
property parameterization
S tandards
Dr. Uwe Aßmann
12
6
Des iderata Compos ition T echnique
q
¿
¿
q
q
q
q
¿
¿
¿
¿
¿
Connection and Adaptation
E xternal Adaptation: adapt the component interface to another
interface
Glueing: Generation of glue code for communication, s ynchronization,
dis tribution. Cons is ts of a s equence of adaptations
E xtens ion
B as e clas s extens ion
Integration
As pect s eparation (as pect compos ition)
E xchange of non-functional as pects
Multiple interfaces
S calability
In time and s ize
Meta-modeling
Dr. Uwe Aßmann
13
Des iderata Compos ition L anguage
q
q
q
¿
¿
¿
¿
P roduct quality
Variant cleannes s : cons is tent configurations
R obus tnes s : freedom of run-time exceptions
S oftware proces s s upport
B uild management automation
Meta-compos ition
Is the compos ition language component-bas ed, i.e., can it be
compos ed its elf?
Dr. Uwe Aßmann
14
7
Vis ions for Component S ys tems
S oftware Lego
S oftware IC’s (Brad Cox 90)
S oftware bus
Software bus
Dr. Uwe Aßmann
15
Definitions of Components
A s oftware component is a unit of compos ition
with contractually specified interfaces and
explicit context dependencies only.
A s oftware component
can be deployed independently and
is s ubject to composition by third parties.
E COOP Workshop WCOP 1997 S zyperski
! REUSABLE SOFTWARE COMPONENT IS A LOGICALLY COHESIVE
LOOSELY COUPLED MODULE THAT DENOTES A SINGLE ABSTRACTION
'RADY "OOCH
A software component is a static abstraction with plugs.
Nierstrasz/Dami
Dr. Uwe Aßmann
16
8
Definitions of Components
-ETA'ROUP /PEN$OC
3OFTWARE COMPONENTS ARE DEFINED AS PREFABRICATED PRETESTED SELF
CONTAINED REUSABLE SOFTWARE MODULES BUNDLES OF DATA AND
PROCEDURES THAT PERFORM SPECIFIC FUNCTIONS
S ametinger:
R eus able s oftware components are s elf-contained, clearly
identifyable pieces thas des cribe and/or perform s pecific
functions , have clear interfaces , appropriate documentation,
and a defined reus e s tatus .
Dr. Uwe Aßmann
17
Components are Compos able Units
A component is a unit for compos ition
q
q
q
¿
¿
¿
¿
¿
q
q
S tandardized interfaces as s ert s emantic features
s et/get-functions as properties of components
active component, if inher iting of R unnable
Dis tinguis h clas s es and object components
Deployment time: s tatic or dynamic
Components can be dynamic loaded or s ubs tituted
functional as pects and non-functional as pects mus t be dis tinguis hed (function
vs communication kind, configuration, repres entation, pers is tency, paralllis m,
etc.).
components with unknown functional as pects can be merged, if they fit to the
other as pects . F unctions can be queried
Components hide dis tribution by mars halling
F açade clas s es /objects dis tribute the functionality internally to other
components
Dr. Uwe Aßmann
18
9
His torical approaches to Components
Dr. Uwe Aßmann
19
Modules (a la Parnas )
We can attempt to define our modules “around” as s umptions which
are likely to change. One then des igns a module which “hides ” or
contains each one.
S uch modules have rather abs tract interfaces which are relatively
unlikely to change.
David P arnas
q
q
q
¿
¿
¿
Hence, every module hiof the an important des ign decis ion behind
a well-defined interface which does not change when the decis ion
changes .
Other features :
firm interfaces , s tatic binding
encaps ulation, principle of s ecrets (information hiding)
no dynamic allocatable units
Concept has penetrated almos t all programming languages
(Modula, Ada, Java, C++, S tandard ML , C#)
Dr. Uwe Aßmann
20
10
Modules
q
q
q
¿
¿
¿
¿
¿
¿
¿
¿
Component Model
S yntactic s ubs titutability/exchange ok
binding points : procedures (with parameters ) and global variables
no parametrization or external adaptation
trans parency ??
Compos ition T echnique
Connection by linking object files
no as pect s eparation (modules mix all as pects )
No extens ibility
Compos ition language
nothing
Dr. Uwe Aßmann
21
S hells and Pipes
q
q
q
¿
¿
¿
¿
¿
¿
UNIX s hells s tyle l offer the mos t us ed component paradigm:
Communication with B yte-s treams .
pars ing and linearizing the objects
E xtremely flexible, s imple
Compos ition technique: s treaming
Compos ition languages
C, s hell, tcl/tk, python…
B uild management language makefile
Vers ion management with s ccs rcs cvs
Dr. Uwe Aßmann
22
11
S hells and Pipes
q
q
q
Component model
¿
¿
binding points : pipes
trans parency: partly: pipes can communicate with s ockets
acros s computer boundaries
Compos ition T echnique
¿
adaptation: filter around other components . F ilter languages
s uch as s ed, awk, perl
¿
as pects no
Compos ition L anguage: Good!
Dr. Uwe Aßmann
23
Object-oriented Clas s S ys tems
q
q
q
q
¿
¿
¿
¿
¿
¿
¿
¿
¿
Objects :
ins tances of clas s es (modules ) with unique identity
objects have s tates / pers is tent s tate
encaps ulation of behavior and s tate
late binding of calls by s earch at run time
Component Model
binding points dynamic calls
no trans parency
Compos ition T echnique
adaptation by inheritance or Delegation
no as pect s eparation,
extens ibility by s ubclas s ing
Compos ition L anguage: none
Dr. Uwe Aßmann
24
12
O-O F rameworks
q
A framework
¿
determines the control flow of an application (Hollywood P rinciple:
“don’t call us , we call you”)
¿
cons is ts of a s et of template clas s es which can be parameterized by
hook clas s es (parameter clas s es)
F ormal
parameter
clas s
Actual
parameter clas s
T emplate
class
Hook
clas s
Dr. Uwe Aßmann
25
O-O F rameworks
q
q
q
Component Model
¿
binding points : Hot s pots to exchange the parameter clas s es
(s ets of polymorphic methods )
¿
¿
trans parency by delegation
parameterization by inheritance an s ubclas s es or delegation,
but not automatic
Compos ition T echnique
¿
¿
no s upport of glue code
no s upport of as pects , extens ions , s calability, meta-modeling
Compos tion language: ---
Dr. Uwe Aßmann
26
13
Commercial Component S ys tems (1s t Generation)
COR B A/DCOM/DOT -NE T /JavaB eans /E JB
q
q
q
Component Model
¿
¿
¿
binding points are s tandardized
Ž
IDL languages
Ž
s et/get properties
Ž
s tandard interfaces s uch as IUnknown, QueryInterface
no parameterization
trans parency more or les s ok
Compos ition T echnique
¿
external adaptation for dis tributed s ys tems (mars halling) and
mixed-language s ys tems (IDL )
¿
no as pect s eparation, extens ibility
Compos ition L anguage: NO
Dr. Uwe Aßmann
27
Components in Component S ys tems of 1s t
Generation
Software bus
q
q
q
Objects which can be plugged into a s oftware bus
Work with the B us and a s et of s tandardized interfaces
T hey form a component s ys tem (platform)
Dr. Uwe Aßmann
28
14
COR BA
http://www.corba.org
q
q
q
L anguage independent, dis tribution trans parent
interface definition language IDL
s ource code or binary
Client
Java
Client
C
S erver
C++
IDL S tub
IDL S tub
IDL
s keleton
Object adapter
Object R eques t B roker (OR B ), T rader, S ervices
Dr. Uwe Aßmann
29
(D)COM
http://www.activex.org
q
q
Micros oft’s model is s imilar to COR B A. perprietary
B inary s tandard
Client
VB as ic
Client
C++
S erver
C++
S erver
C++
COM s tub
COM s tub
COM s keleton
IDL
s keleton
Object adapter
Monikers , R egis try
Dr. Uwe Aßmann
30
15
Java Beans
http://www.javas oft.com
q
q
Java only, event-bas ed, trans parent dis tribution by remote
method invocation (R MI)
s ource code/bytecode-bas ed
B ean
Java
B ean
Java
B ean
Java
S erver
C++
IDL
s keleton
Object adapter
E vent InfoB us , R MI
Dr. Uwe Aßmann
31
Beans – S tandard Components in Java
S tandardized component, for better exchanga
R eflection
B eanInfo
S erialization
P ackaging
HT ML -Doku
E vents
E vent driven Infobus
Dr. Uwe Aßmann
32
16
E JB – S tandard Components
Client interface
E JB home
E JB object
Metadata
Containercomponentinterface
Handle
S ess ionBean
E ntityBean
Mes s ageBean
S erialization
Packaging
S ess ionContext
NamingContext
HT ML-Doku
T ransaction
Context
E JB -references
Dr. Uwe Aßmann
33
DOT -NE T
http://www.micros oft.com
q
q
q
q
L anguage independent, dis tribution trans parent
NO interface definition language IDL (at leas t for C#)
s ource code or bytecode MS IL
Common L anguage R untime CL R
Client
Java
Client
C#
S erver
C++
.net-CL R
.net-CL R
.net-CL R
MS IL intermediate language, CL R
Dr. Uwe Aßmann
34
17
Vis ions for a New Component Web
q
¿
A brows er is a components document is a bean is a page is a
component is a s hippable place
B rows er
Ž
Move of brows er functionalities by drag and drop: move of UR L s as active
objects into the brows er and the documents , e.g., as toolbars
Ž
E xtens ibility by new components
¿
Documents
Ž
vis ual move of active page parts , in-place editing of parts
¿
L oading pages corres ponds to drag-and-drop of components into
components
¿
¿
B uying as Drag-and-drop into container
T he Des ktop becomes brows er (as Container of active dis tributed
objects )
Dr. Uwe Aßmann
35
S hippable places
q
¿
¿
¿
A s hippable place is a vis ual ens emble of components
S hippable over the net (vis ible bean, B ohne, jar, E JB , ActiveX)
A mini world (pers onalized as des ktop, wearable, car tuning)
P ers is tent, communicated with OR B s
HT ML-pages
HT ML
HT T P
Applets
IIOP
CGI
OR B-HT T P
S erver
OR B
S hippable
Places
B usines s objects
data base
Lotus Notes
Dr. Uwe Aßmann
36
18
Architecture S ys tems
q
q
q
q
Unicon, ACME , Darwin
All feature an Architecture Des cription L anguage (ADL )
P orts abs tract interface points (as in L inda)
¿
¿
¿
¿
in(data)
out(data)
Components are black boxes
Components may be nes ted
S plit an application into:
¿
¿
Application-s pecific part (encaps ulated in components )
¿
B etter reus e s ince both dimens ions can be varied independently
Architecture and communication (in architectural des cription in
ADL )
Dr. Uwe Aßmann
37
Architecture S ys tems
P ort 1
Component
P ort
P ort
Component
P ort 2
Component
R ole
Connectors s plit off communication from components
Dr. Uwe Aßmann
38
19
Architecture can be exchanged
independently of components
R eus e of components and architectures is fundamentally improved
P ort 1
Component
P ort
P ort
Component
P ort 2
Component
Dr. Uwe Aßmann
39
Connectors as Abs tract Communication Bus es
S erver
component
P ort
Client
component
P ort
P ort
R ole
R ole
Connector
Dr. Uwe Aßmann
40
20
Ingredients of Architecture S ys tems
q
¿
¿
q
q
q
Architecture language (architectural des cription language, ADL )
ADL -compiler
XML -R eaders /Writers for ADL . XADL is a new s tandard exchange
language for ADL bas ed on XML
E ditors (graphic, textual)
Checker and Analyzers
S imulators
Dr. Uwe Aßmann
41
T he KWIC Problem
q
q
¿
E xample from UniCon dis tribution
" Keyword in Context" problem (KWIC)
T he K WIC problem is one of the 10 model problems of architecture
s ys tems [ModelP roblems ]
¿
Originally propos ed by P arnas to illus trate advantages of different
des igns [P arnas 72]
¿
F or a text, a K WIC algorithm produces a permuted index
Ž
every s entence is replicated and permuted in its words , i.e., the words are
s hifted from left to right.
Ž
every firs t word of a permutation is entered into an alphabetical index, the
permuted index.
Dr. Uwe Aßmann
42
21
T he KWIC Problem in Unicon
q
q
¿
¿
q
¿
¿
q
q
T he components of KWIC work in a pipe-and-filter s tyle
KWIC has ports
s tream input port input,
and two output ports output and error . T hey read text and s pit out the
permuted index
KWIC is a compound component KWIC (Components in Unicon
can be nes ted)
P L AYE R definitions define ports of outer components .
B IND s tatements connect ports from outer components to ports of
inner components .
US E S definitions create ins tances of components and connectors .
CONNE CT s tatements connect connectors to ports at their roles .
Dr. Uwe Aßmann
43
T he KWIC Problem in Unicon
q
q
¿
T his U NICON s cript is depicted o the next s lides
T extual
¿
¿
¿
graphical (in which form it is much eas ier to unders tand)
Components
T he component caps replicates the s entences as neces s ary.
T he s hifter permutes the generated s entences .
¿
q
Ž
¿
¿
q
T he r eq-data provides s ome data to the merge component which pipes the
generated data to the component s orter .
es s orts the s hifted s entences s o that they form a keyword-in-context index.
Only connectors in the s tyle of UNIX pipes are us ed
If other connection kinds can be introduces by only changing the type of
connectors in a US E S declaration.
T his means that communication kinds can be exchanged eas ily, als o for
dis tributed components .
Architecture s ys tems allow for s calable communication: binding
procedures can be exchanged eas ily!
Dr. Uwe Aßmann
44
22
K WIC
Caps
P
S hifter
Q
merge
input
S orter
output
R
error
req-data
Dr. Uwe Aßmann
45
COMPONE NT KWIC
/* T his is the interface of KWIC with in- and output ports */
INT E R F ACE IS T YPE F ilter
PLAYE R input IS S treamIn S IGNAT UR E ("line") POR T B INDING (s tdin)
E ND input
PLAYE R output IS S treamOut S IGNAT UR E ("line") POR T B INDING (s tdout)
E ND output
E ND INT E R F ACE
/* Here come the connections */
BIND
input
T O caps.input
IMPLE ME NT AT ION IS
CONNE
CT
caps.output
T O P.source
/* Here come the component definitions */
CONNE CT shifter.input T O P.s ink
US E S caps
INT E R F ACE upcas e
E ND caps
CONNE CT shifter.output T O Q.s ource
US E S s hifter
INT E R F ACE cs hift
E ND shifter
CONNE CT req-data.read T O R .source
US E S req-data INT E R F ACE const-data E ND req-data
CONNE CT merge.in1
T O R .s ink
US E S merge
INT E R F ACE converge
E ND merge
CONNE CT merge.in2
T O Q.sink
US E S s orter
INT E R F ACE s ort
E ND sorter
/* Als o, s yntactic s ugar is provided for complete
connections */
/* Here come the connector definitions */
E S T ABLIS H Unix-pipe WIT H
US E S P PR OT OCOL Unix-pipe E ND P
merge.output AS s ource
US E S Q PR OT OCOL Unix-pipe E ND Q
sorter.input AS sink
US E S R PR OT OCOL Unix-pipe E ND R
E ND Unix-pipe
BIND output T O sorter.output
E ND IMPLE ME NT AT ION
E ND KWIC
23
Aes op S tudio as Graphic E nvironment
Dr. Uwe Aßmann
47
Pipe-F ilter Vis ual in Aes op
Dr. Uwe Aßmann
48
24
What ADL Offer for the S oftware Proces s
q
q
q
q
¿
¿
¿
¿
¿
¿
¿
¿
¿
¿
Communication
client can unders tand the architecture graphics well
Architecture s tyles clas s ify the nature of a s ys tem in s imple terms (s imilar to
des ign patterns )
Des igns s upport
Model Connectors , ports , and roles als o in your object-oriented models !
R efinement of architectures (s tepwis e des ign, des ign to s everal levels )
Vis ual and textual views to the s oftware res p. the des ign
Validation: T ools for cons is tency of architectures
Are all ports bound? Do all protocols fit?
Does the architecture corres ponds to a certain s tyle ?
Or to a model architecture?
P arallelis m features as deadlocks , fairnes s , livenes s ,
Dead parts of the s ys tems
Implementation: Generation of large parts of the implementation (the
communications - and architecture parts )
Dr. Uwe Aßmann
49
What Can Be Generated
q
q
q
q
Glue- and adapter code from connectors and ADL -s pecifications
¿
Mapping of the protocols of the components to each other
¿
Generation of glue code from the connectors
S imulations of architectures (with dummy components ):
¿
the architecture can be created firs t
¿
And tes ted s tandalone
¿
R un time es timates are pos s ible (if run times of components are
known)
T es t cas es for architectures
Documentation (graphic s tructure diagrams )
Dr. Uwe Aßmann
50
25
Architecture S ys tems
q
Component model
B inding points :
¿
Ž
ports to which connectors are attached
Ž
explicit application of connectors per communication (in object-oriented
s ys tems communications are changed by inheritance)
Ž
q
q
the interfaces remain at run time
¿
K ind of the communication is trans parent
¿
no parameterization, except by inheritance
Compos ition technique
¿
glue code and external adaptation by connectors
¿
no as pect s eparation, no extens ibility
¿
S calability (dis tribution, binding time with dynamic architectures )
Compos ition language: An Architecture Des cription L anguage
(ADL ) is a s imple compos ition language!
Dr. Uwe Aßmann
51
#OM PONENTS
) NVASIVE
COM POSITION
"ASIC COM POSITION TECHNIQUE
#OM POSERS
3YSTEM CONSTRUCTED IN A
COM PONENT AND COM POSITION
BASED ARCHITECTURE
#OM POSITION RECIPE
26
As pect-oriented Programming (AOP)
q
q
q
[Kiczales et al: As pect-oriented programming. E COOP 1997,
L NCS , S pringer]
S eparate the plans for different as pects and weave them together
to an integrated s ys tem
E xchange the as pects independent of each other
water
data
structure
heating
Dr. Uwe Aßmann
53
Structure
)NTERFACES
0IPE 0LAN
,IGHT 0LAN
)NTEGRATED (OUSE
27
As pects of a Program
(Algorithm and Animation)
import java.io.*;
public clas s Hanoi {
public Hanoi() {
..
}
protected void compute( int n, S tring s , S tring t, S tring
h){
if(n > 1){
compute( n - 1, s, h, t );
}
if(n > 1){
compute( n - 1, h, t, s );
}
}
/** T he black code is the algorithmic aspect */
/* * T he red code is the animation as pect. */
import java.io.*;
public clas s Hanoi extends java.util.Obs ervable
implements java.util.Obs erver {
public Hanoi() {
addObserver( new PrintObs erver() );
}
protected void compute( int n, S tring s , S tring t, S tring
h){
if(n > 1){
compute( n - 1, s, h, t );
}
s etChanged();
notifyObservers ( new displayPack( s , t ) );
if(n > 1){
compute( n - 1, h, t, s );
}
}
Dr. Uwe Aßmann
55
As pect-oriented Programming (AOP)
q
¿
Component Model
Components and s pecial components (as pects ).
Ž
q
q
As pects are relative to components
¿
binding points : Join points at which as pects are weaved into
components
¿
parameterization: as pects form parts of components , I.e.,
parameterization by exchange of as pects
¿
¿
trans parency by as pect des cription languages
Architecture s ys tems appear to be s pecific as pect s ys tems :
Ž
¿
¿
T he as pects are application s pecific functionality and communication
Compos ition T echnique
external adaptation: weave glue code around components
as pect s eparation ok
Compos ition L anguage.. Well..
Dr. Uwe Aßmann
56
28
What As pects Offer for Des ign
q
q
¿
¿
¿
As pects s implify
S pecifications
UML diagrams
Not only implementations
Des ign with as pects ! (As pect oriented Des ign)
Dr. Uwe Aßmann
57
Compos ition S ys tems
E xemplified by Invas ive Compos ition
Dr. Uwe Aßmann
58
29
Invas ive S oftware Compos ition
#OMPONENT -ODEL
#OMPOSITION 4ECHNIQUE
0ROGRAM %LEMENT 3ETS
2EWRITING -ODIFICATION
"OXES
#OMPOSITION ,ANGUAGE
3TANDARD ,ANGUAGE
STATIC -ETAPROGRAMMING
Dr. Uwe Aßmann
59
Invas ive S oftware Compos ition
)NVASIVE #OMPOSITION
ADAPTS AND EXTENDS
BOX COMPONENTS
AT HOOKS
BY PROGRAM TRANSFORMATION
q
q
6IEWORIENTED DEVELOPMENT
!SPECTORIENTED DEVELOPMENT
Dr. Uwe Aßmann
60
30
Invas ive Compos ition as Program
T rans formations
#OMPOSER
Invasively transformed code
Dr. Uwe Aßmann
61
Invas ive Compos er
A Compos er is a program trans former of unbound to bound hooks
compos er : component with hooks
--> component with Code
T as ks of a compos er:
recognizing of hooks
T rans formation by Manipulation of hooks (B ind the hook, weave,
weaving)
Code generation
q
q
q
Dr. Uwe Aßmann
62
31
#OM PONENTS
3OFTWARE
) NTEGRATION
#OM POSITION ,ANGUAGE
3YSTEM CONSTRUCTED IN A
INTEGRATIONBASED ARCHITECTURE
#OM POSITION RECIPE
Invas ive Compos ition
q
Implicit hooks (default hooks ), e.g., for wrapping
Method m (){
Method.begin
Method.begin
abc..
cde..
Method m
Method.end
Method.end
return;
}
Dr. Uwe Aßmann
64
32
T rans formation of a Hook
Wrapping of a tes t-as pect
Method m (){
Method.begin
Method.begin
abc..
cde..
Method.end
Method.end
return;
}
Method m (){
print(„enter m“)
abc..
cde..
print(„exit m“)
return;
}
Dr. Uwe Aßmann
65
Declared Hooks
E .g., ports :
Method m (){
OUT port
portobj.out(d);
portobj.in(e);
IN port
portobj.out
Method m
portobj.in
}
Dr. Uwe Aßmann
66
33
T rans formations for Ports
m (){
/*** ports */
e = m(d);
m (){
OUT port
portobj.out(d);
portobj.in(e);
IN port
}
}
m (){
/*** ports */
setChanged(d);
notifyObservers(d);
listen_to(e);
}
Dr. Uwe Aßmann
67
What Compos ition S ys tems Offer for Des ign
q
q
¿
¿
¿
¿
¿
¿
Compos ition programs s implify
Architecture, s tructure
B uilds
decompos ition
Des ign s ys tems in two levels (Compos ition oriented Des ign)
B as ic components
How to compos e
Compos ition s tructure
Dr. Uwe Aßmann
68
34
#OMPOSITION ,ANGUAGE ,EVEL
#OMPOSITION
,ANGUAGE
#OMPOSITION
#OMPONENT
4ECHNIQUE
#OMPOSITION
-ODEL OF
FOR
,ANGUAGE FOR
#OMPOSITION
#OMPOSITION
#OMPOSITION
,ANGUAGE
2ECIPES
2ECIPES
#OMPOSITION 3YSTEM ,EVEL
#OMPOSITION
3YSTEM
#OMPONENT
-ODEL
#OMPOSITION
4ECHNIQUE
#OMPOSITION
2ECIPE
Invas ive Compos ition: Modularization
" As pects are jus t a new type of component
" Grey box components ins tead of black box ones
"
clean compos ition interfaces with hooks
"
the compos ition programs cros s the modularization according to welldefined rules
"
R es ulting in efficient s ys tems
"
s uperfluous interfaces are removed from the s ys tem
" no S tandards for application s pecific or bus ines s components yet
" P arameteris ation:
"
in the invas ive compos ition, in S OP , GenVoca, L ambdaN interfaces are
cros s ed and adaptation code is weaved into the component.
Dr. Uwe Aßmann
70
35
Invas ive Compos ition: Adaptation
" Adaptation: good!
" Glueing: good, compos ers are program generators
" As pect weaving
"Compos itions mechanis ms are better than AOP , s ince they s implify
weaving and reduce it to a s impler principle
"Companies may write their own weavers
"No s pecial languages .
" E xtens ions :
"Very good s ince hooks can be extended, and the s oundnes s criteria of
lambdaN s till apply
" Metamodelling s upported
" Not yet s calable to run time
Dr. Uwe Aßmann
71
At the T rans ition to the Compos ition Age
q
q
q
q
q
¿
XML will be the AS CII of the 21s t century
concrete s yntax will vanis h
We need compos ition, not components
Compos ition and component integration will s ubs titute
programming
B ecome a developer of compos ition techniqes !
B ecome a compos itional des igner!
Dr. Uwe Aßmann
72
36
Grey B ox
Comp.
L anguage
Integrational S ys tems
Compos ition S ys tems
Compos ition
L anguage
Invas ive Compos ition
p-calculus
S ys tems with
Compos ition Operators
Compos ition
Operators
As pect S ys tems
As pect S eparation
lN-calculus
Hypers lices
S OP
As pect/J
Architecture as As pect
Darwin
Aes op
Clas s ical
Component S ys tems
S tandard Components
DCOM COR B A
Object-Oriented S ys tems
Objects as
R un-T ime Components
C++
Modules as CompileT ime Components
Modula
Architecture S ys tems
B lack B ox
Many integration
techiques
Uniform on XML
Compos ition
L anguage
Modular S ys tems
B eans /E JB
Java
S ather
Ada-85
C..
37