Document 7123190
Download
Report
Transcript Document 7123190
Model-Driven Development (MDD)
State of the Art
OOP Conference, Monday, January 16th, 2005
Dr Douglas C Schmidt
[email protected]
www.dre.vanderbilt.edu/~schmidt
Institute for Software Integrated
Systems
Vanderbilt University Nashville,
Tennessee
Thomas Stahl
[email protected]
www.bmiag.de
b+m Informatik AG,
Chef-Architekt
Kiel, Germany
Markus Völter
[email protected]
www.voelter.de
Independent Consultant
for Software Engineering
& Technology
Heidenheim, Germany
What We Want You to Learn Today
• Key MDD concepts & what kinds of domains &
problems they address
• What are some popular MDD tools & how they work
• How MDD relates to other software tools &
(heterogeneous) platform technologies
• What types of projects are using MDD today & what
are their experiences
• What are the open issues in MDD R&D & adoption
• Where you can find more information
Model-Driven Development – State of the Art
2
Model-Driven Development:
State of the Art
3
CONTENTS
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
4
CONTENTS
The Road Ahead
CPU & network performance has increased by 3-8
orders of magnitude in past decades
10 Megahertz to
3+ Gigahertz
1,200 bits/sec to
10+ Gigabits/sec
Extrapolating these trends another decade or so yields
• ~100 Gigahertz desktops
• ~100 Gigabits/sec LANs
• ~100 Megabits/sec wireless
• ~10 Terabits/sec Internet backbone
Unfortunately, software quality &
productivity hasn’t improved as
rapidly or predictably as hardware
Model-Driven Development – State of the Art
5
Why Hardware Improves So Consistently
Advances in hardware & networks stem largely from
R&D on standardized & reusable APIs & protocols
x86 & Power PC chipsets
Model-Driven Development – State of the Art
TCP/IP
6
Why Software Fails to Improve as Consistently
In general, software has not been as standardized or reusable as hardware
F-15
A/V-8B
F/A-18
UCAV
Proprietary & Stovepiped Application & Infrastructure Software
Nav
Air
Frame
Nav
HUD
AP
FLIR
Air
Frame
GPS
IFF
IFF
Application
Software
Cyclic
Exec
Cyclic
Exec
FLIR
FLIR
HUD
Air
Frame
AP
Nav
AP
GPS
IFF
GPS
Air
Frame
Vx
Works
1553
VME
Link16
Application
Software
Vx
Works
1553
VME
Link16
Standard/COTS Hardware & Networks
Model-Driven Development – State of the Art
Nav
AP
Application
Software
1553
VME
Link16
HUD
7
GPS
HUD
FLIR
IFF
Application
Software
The Promise
• Develop standardize
technologies that:
1. Model
2. Analyze
3. Synthesize &
4. Provision
complex software
systems
<CONFIGURATION_PASS>
<HOME>
<…>
<COMPONENT>
<ID> <…></ID>
<EVENT_SUPPLIER>
<…events this
component supplies…>
</EVENT_SUPPLIER>
</COMPONENT>
</HOME>
</CONFIGURATION_PASS>
Gigabit
Ethernet
Analyz
e
Build
Model-Driven Development – State of the Art
8
The Reality
• Architects
(sometimes) use
UML to express
software designs
at a high-level
• Developers write
& evolve code
manually
static CORBA::Long
pid
_; receiver_
AVStreams
::streamQoS
the_
qos
;
#endif
}
static FILE *output_file = 0;
this->fill_
qos
( the_
qos);
ACE_
Cstring
Receiver::output_file_name (void) {
// File handle of the file into which received data is written
// Connect to the sender
return this->output_file_name_; }
quo::
ValueSC
_var actualFrameRate
;
this->connection_manager_connect_to_sender
qos
, use_
qos
_stream_, (the_
ACE_TRY_ENV);
intReceiver::is_output_file (void) {
// Poke this in order to send the measured
QuO
frame rate to
ACE_CHECK_RETURN (-1);
return this->is_output_file_; }
// destination port to sendlocalhost
mpeg data to on
CORBA::ORB_
varorb = TAO_AV_CORE::instance ()->orb();
intReceiver::spawn_viewer() {
static
intoutput_port = 8001;
// Connect
QuO
sto
ystem condition
actualFrameRate
to set
if( ACE_OS::access("/
dvdview
/src
/dvdview
", X_OK) != 0 ) {
// Instrumentation Helper
ACE_
CString
name_
cstr
("ActualFrameRate
_");
return -1; }
static
Instrumentor
*instrument = 0;
name_
cstr
+= this->sender_name_ + "_" + this->receiver_name_; ACE_Process process;
// Name of process
CosNaming
::NamingContext
_var nc
=NamingHelper
<CosNaming
::NamingContext
>::resolve_
init
ACE_Process_Options options;
static ACE_
CString
process_name_;
(CORBA::ORB::_duplicate(orbin()),
NameService
", 5, ACE_Time_Value(1,
"
optionscommand_line
0));
("%s
dvdview
/src
-z/dvdview
%d a",
", output_port);
"/
intReceiver_
StreamEndPoint
::get_callback
const
char
( flowname
* , TAO_AV_Callback
*&
callback) {
CosNaming
::Name name;
pid
_t viewer_
pid= ACE_OS::fork();
ACE_DECLARE_NEW_CORBA_ENV;
namelength(1);
pid
_t receiver_
pid= 0;
// Create & return the sender application
AVStreams
for callback
further
upcalls
to
name[0]id = CORBA::string_
dup
(name_
cstr
c_str
());
switch(viewer_
pid
){
int retval
= 0;
name[0]kind = CORBA::string_
dup
("");
case -1: /* error */ ACE_OS::exit(99); break;
callback = &this->callback_;
//QuO syscond
that should receive the measured frame rate
case 0: /* child */ processspawn(options); break;
RECEIVER::instance ()->connection_manager
flowname
);()connect_negotiator(this,
frame_rate_meter_set_
framerate
_sc(NamingHelper
<quo::
ValueSC
>::resolve_name(
nc
in(),
default: /* parent
pid=*/ACE_OS::fork();
receiver_
return
retval
;}
name, 15, ACE_Time_Value(1, 0)));
switch(receiver_
pid
){
Receiver_Callback::Receiver_Callback (void) : frame_count_ (1) { return 0; }
case -1: /* error */ ACE_OS::exit(98); break;
ACE_INET_
Addr _addr
inet
(output_port,
localhost
");
"
intReceiver::parse_
args
(i nt argc
, char
**argv
){
case 0: /* child */ break;
dvdview
_endpoint_open(
inet
_addr
); }
if(
argc
< 2 ){
default: break; }
intReceiver_Callback::receive_frame (ACE_Message_Block *frame, usage();
TAO_AV_frame_info * /*frame_info*/,
break; }
ACE_
const
Addr
&) {
return -1; }
int
status1, status2;
//Upcall
from AVStreams
the
when there is data to be received from the senderfor(
inti=0;argc
i <; i++) {
if( receiver_
pid!= 0) {
++frame_count_;
strcmp
if( (argv
[i], qos
"--") == 0)qos
use_
_stream_ = 1; }
ACE_OS::
waitpid
(viewer_
pid
, &status1, 0);
while (frame != 0) {
// Parse the command line arguments
ACE_OS::
waitpid
(receiver_
pid
, &status2, 0);
char
buf=* frame->rd_
ptr
();
ACE_Get_Opt
argc
, argv
opts
, "f:s:r:d:p:");
(
ACE_OS::exit(0); }
// Get the RTP fixed header
intc;
return 0; }
rtp
_hdr
_thdr
;
while ((c = opts ()) != -1) {
const
char * Receiver::name()
const
{
ACE_OS::
memcpy
(&
hdr
, buf
,sizeof
(rtp
_hdr
_t));
switch (c) {
return receiver_name_c_
str
(); }
// decode the RTP
endian
problems)
header (
case 'f': this->output_file_name_
optarg
; this->is_output_file_
= opts
= 1; break;intmain
int( argc
, char
**argv
){
rtp
_hdr
_t decoded_
rtp
_hdr
;
case 's': this->sender_name_
optarg
; break;
= opts
receiver_
pid
_ = (CORBA::Long)ACE_OS::
getpid
();
decode_
rtp
_hdr
(&
hdr
, &decoded_
rtp
_hdr
);
case 'r': this->receiver_name_
optarg
; break;= opts
process_name_
basename
= ACE::
(argv
[0]);
// Get the MPEG RTP header extension
case 'd': this->debug_level_
atoi
(opts
=optarg
ACE_OS::
); break;
ACE_DECLARE_NEW_CORBA_ENV;
rtp
_mpeg_
hdr
_t mpeg_
hdr
;
case 'p': output_port
atoi
(opts
=optarg
ACE_OS::
); break;
ACE_TRY {
ACE_OS::
memcpy
(&mpeg_
hdr
,buf+sizeof
(rtp
_hdr
_t),sizeof
(rtp
_mpeg_
hdr
_t));
default: ACE_ERROR_RETURN ((LM_ERROR, "Usage: receiver
// Initialize
-f filename"),
the ORB first
-1); } }
// extract the frame type from the RTP header extension
instrumentInstrumentor
= new(TAO_AV_CORE::instance ()->orb(), Instrument::domain_name,
CORBA::ORB_
varorb = CORBA::ORB_
init
(argc
,argv
, 0, ACE_TRY_ENV);
u_char frame_type
hdr
bf1=&mpeg_
0x07;
this->receiver_name_c_
str
());
ACE_TRY_CHECK;
RECEIVER::instance ()->time_frame (frame_type);
return 0; }
CORBA::Object_
var obj
= orb->resolve_initial_references
RootPOA
", ACE_TRY_ENV);
("
// strip rtp
offheaders
the
for sending
Connection_Manager &Receiver::connection_manager (void) { ACE_TRY_CHECK;
char *send_
buf= &
buf
[sizeof
(rtp
_hdr
_t) +
sizeof
(rtp
_mpeg_
hdr
_t) ];
return this->connection_manager_; }
// Get the
varPOA_
object fromvar
Object_
size_tlen
send_
= frame->length()
sizeof
(rtp
_hdr
-_t)sizeof
- (rtp
_mpeg_
hdr
_t);
void Receiver::usage() {
PortableServer
::POA_
varroot_
poa=PortableServer
::POA::_narrow
obj
in (), (
if (instrument && (frame_type == 1)) {
ACE_DEBUG((LM_DEBUG, "Usage:\n\n"));
ACE_TRY_CHECK;
Instrumentor
::MessageBody
body;
ACE_DEBUG((LM_DEBUG, " receiver -s [sender name] -r [receiver
PortableServer
::
name]\n"));
P OAManager
_var mgr
= root_
poa
->the_
POAManager
(ACE_TRY_ENV);
ACE_Time_Value
tv= ACE_OS::
gettimeofday
();
ACE_DEBUG((LM_DEBUG, "
-d [debug level] -f [file name]\n"));
ACE_TRY_CHECK;
bodyadd_string(Instrument::Name, RECEIVER::instance()->name());
ACE_DEBUG((LM_DEBUG, "
-p [output UDP port, default
mgr
->activate
is %d]\n",
(ACE_TRY_ENV);
output_port));
bodyadd_
ulong
(Instrument::
SequenceNumber
, decoded_
rtp
_hdr
seq
);
ACE_DEBUG((LM_DEBUG,
qos
]\n")); "}
[-ACE_TRY_CHECK;
bodyadd_double(Instrument::Timestamp,
rtp
_hdr
(CORBA::Double)decoded_
ts);
void Receiver::time_frame
intframe_type)
( {
// Initialize
AVStreams
thecomponents
bodyadd_double(Instrument::
ReceiveTime
, (CORBA::Double)((unsigned
tvmsec
()) ); long)
frame_rate_meter_time_frame (frame_type); }
TAO_AV_CORE::instance
init
(orbin (),poa
()->
root_
in (), ACE_TRY_ENV);
bodyadd_double(Instrument::
FrameTiming
, (CORBA::Double)(
tvmsec
() - decoded_
rtp
_hdr
ts) void
); Receiver::fill_
qos
(AVStreams
::streamQoS
&qos
){
ACE_TRY_CHECK;
bodyadd_string(Instrument::
ProcessName
, process_name_c_
str
());
#if 1 || defined(RESERVATION_CONTROL)
Receiver *receiver = RECEIVER::instance ();
bodyadd_long(Instrument::PID,
pid
_);
receiver_
qos
length(0);
int
args
(argc
,argv
);
=-1)receiver->parse_
instrument->send_event(Instrument::
ReceiverFrameStats
, body); }
#else
ifresult
(result ==
return -1;
if (output_file) {
CORBA::
ULong
bandwidth
1000000/8;
=
receiver->spawn_viewer();
// Write the received data to the file
CORBA::
ULong
peak_bandwidth =1100000/8;
if (receiver->is_output_file ()) {
int
result = ACE_OS::
fwrite
(send_
buf
, send_
len
, 1, output_file); }
qos
length (1);
// Make sure we have a valid <output_file>
dvdview
_endpoint_send
buf
, send_
(send_
len
);
qos
[0]QoSType
= CORBA::string_
dup("Data_Receiver");
output_file =
fopen
ACE_OS::
(receiver->output_file_name
str(), "w");()c_
frame = cont
frame->
(); }
if (output_file == 0)
qos
[0]QoSParams
length (10);
return 0; }
qos
[0]QoSParams
dup
ACE_ERROR_RETURN ((LM_DEBUG, "
[0]property_name = CORBA::string_
("Service_Type");
Receiver::Receiver (void)mmdevice
: debug_level_
_ (0),
output_file_name_
(0),
(), is_output_file_
qos
[0]QoSParams
(0), [0]property_value <<= (CORBA::Short) ACE_SERVICETYPE_CONTROLLEDLOAD;
receiver->output_file_name
str()), -1);
()c_
sender_name_ ("distributor"), receiver_name_
use_
qos
_stream_(0)
{} ("receiver"),
qos
[0]QoSParams
dup
else ACE_DEBUG ((LM_DEBUG, “
[1]property_name = CORBA::string_
("Token_Rate");
Receiver::~Receiver (void) {}
qos
[0]QoSParams
ULong
result = receiver->
init
(argc
,argv
, ACE_TRY_ENV);
[1]property_value <<=
)(CORBA::
bandwidth ;
intReceiver::
init
(i nt
, char
**,CORBA::Environment &ACE_TRY_ENV) { qos[0]QoSParams
[2]property_name = CORBA::string_
dup
("Token_Bucket_Size"); ACE_TRY_CHECK;
// Initialize the endpoint strategy
poa with the orb and
qos
[0]Qo
[2]property_value <<=
ULong
)(CORBA::
5000;
if (result != 0) return result;
intresult = this->reactive_strategy_
init(TAO_AV_CORE::instance ()->orb (),
qos
[0]QoSParams
[3]property_name
= CORBA::string_
dup
("Peak_Bandwidth");
orb->run (ACE_TRY_ENV);
S
TAO_AV_CORE::instance
poa());
()->
qos
[0]QoSParams
[3]property_value <<=
ULong
)(CORBA::
peak_bandwidth;
ACE_TRY_CHECK;
P
if (result != 0) return result;
qos
[0]QoSParams
[4]property_name
= CORBA::string_
dup
("Latency");
// Hack for now
a
// Initialize the connection manager
qos
[0]QoSParams
[4]property_value
<<=
ULong
)(CORBA::
0;
ACE_OS::sleep (1);
result = this->connection_manager_
init
(TAO_AV_CORE::instance ()->orb ()); qos
[0]QoSParams
[5]property_name
= CORBA::string_
dup
("Delay_Variation");
orb->destroy (ACE_TRY_ENV);
r
if (result != 0) return result;
qos
[0]QoSParams
[5]property_value <<=
ULong
)(CORBA::
0;
ACE_TRY_CHECK; }
a
// Register themmdevice
receiver
object with the ORB
ACE_CATCHANY {
qos
[0]QoSParams
[6]property_name
= CORBA::string_
dup
("Max_SDU_Size");
ACE_NEW_RETURN
mmdevice
_,(this->
TAO_
MMDevice
(&this->reactive_strategy_), -1);qos
[0]QoSParams
[6]property_value
<<=
ULong
)(CORBA::
368;
ACE_PRINT_EXCEPTION (,"receiver::
init
");
m
// Servant Reference Counting to manage lifetime
qos
[0]QoSParams
[7]property_name
= CORBA::string_
dup
("Minimum_Policed_Size");return -1; }
s
AVStreams
::MMDevice
_var mmdevice
= this->
mmdevice
_->_this (ACE_TRY_ENV);
qos
[0]QoSParams
[7]property_value <<=
ULong
)(CORBA::
368;
ACE_ENDTRY;
ACE_CHECK_RETURN (-1);
qos
[0]QoSParams
[8]property_name = CORBA::string_
dup
("TTL");
ACE_CHECK_RETURN (-1);
// Bind to sender
qos
[0]QoSParams
[8]property_value <<=
ULong
)(CORBA::
25;
ACE_OS::
fclose
(output_file);
this->connection_manager_bind_to_sender (this->sender_name_,
mmdevice
in (),
this->receiver_name_,
qos
[0]QoSParams
[9]property_name = CORBA::string_
dup
("Priority");
return 0; }
ACE_TRY_ENV);
qos
[0]QoSParams
[9]property_value <<=
ULong
)(CORBA::
1;
ACE_CHECK_RETURN (-1);
Model-Driven Development
– State of theto
Art be
We ought/need
able9 to do much better than this!
Sources of the Problems
Technical
Challenges
Inherent & accidental complexities
– More automated specification & synthesis of
• Broader range of target domain capabilities
• Model interpreters & transformations
• Static & dynamic quality of service (QoS) properties
– Round-trip engineering from models ↔ source
– Poor support for debugging at the model level
– Version control of models at the model level
Non-Technical
Challenges
Impediments of human nature
• Organizational, economic, administrative, political, &
psychological barriers
Ineffective technology transition strategies
• Disconnects between methodologies & production
software development realities
• Lack of incremental, integrated, & triaged transitions
www.cs.wustl.edu/~schmidt/reuse-lessons.html
Model-Driven Development
– State of the Art
10
Key Challenges for Software Developers
Developers & users of software face
challenges in multiple dimensions
Logical
View
Process
View
Use Case
View
Physical
View
Model-Driven Development – State of the Art
Development
View
11
Key Challenges for Software Developers
Determining units of abstraction
for system (de)composition,
reuse, & validation
Logical
View
Model-Driven Development – State of the Art
• Popular technologies & tools provide
inadequate support for
– Checking pre-/post-conditions & invariants
– Specifying & analyzing dependencies
– Expressing design intent more clearly
using domain concepts
12
Key Challenges for Software Developers
• Popular technologies & tools
provide inadequate support for
– Configuring & customizing
components for application
requirements & run-time
environments
– Automated mapping of
components onto nodes in
target environments
Physical
View
Integrating/deploying diverse new &
reusable application components in a
networked environment to ensure endto-end QoS requirements
Model-Driven Development – State of the Art
13
Key Challenges for Software Developers
• Popular technologies & tools
provide inadequate support for
– Identifying & reducing
performance & robustness
risks earlier in system lifecycle
Devising execution architectures, concurrency
models, & communication styles that ensure
multi-dimensional QoS & correctness of
new/reusable components
Process
View
– Satisfying multiple (often
conflicting) QoS demands
• e.g., secure, real-time,
reliable
– Satisfying QoS demands in
face of fluctuating/insufficient
resources
• e.g., mobile ad hoc
networks (MANETs)
Model-Driven Development – State of the Art
14
Key Challenges for Software Developers
• Popular technologies & tools
provide inadequate support for
avoiding “bloatware”, i.e.:
– Cyclic dependencies, which
make unit testing & reuse
hard
– Excessive link-time
dependencies, which bloat
the size of executables
– Excessive compile-time
dependencies, where small
changes trigger massive
recompiles
Development
View
(De)composing systems into
reusable modules (e.g., packages,
subsystems, libraries) that
achieve/preserve QoS properties
Model-Driven Development – State of the Art
15
Key Challenges for Software Developers
Capturing functional & QoS
requirements of systems &
reconciling them with other
views during evolution
Use Case
View
• Popular technologies & tools provide inadequate support for
– Ensuring semantic consistency & traceability between requirements &
software artifacts
– Visualizing software architectures from multiple views
Model-Driven Development – State of the Art
16
Promising Solution Approaches
Air
Frame
AP
Nav
Event
Channel
WTS
Replication
Service
Multi-faceted
Software
Development
Object Request Broker
GPS
IFF
FLIR
Cross-cutting Concerns
Synchronization
Persistence
Memory Management
Fault Tolerance
Model-driven
development
& domain-specific
languages
Middleware frameworks
that integrate multiple
QoS properties
Verification & validation
technologies, e.g., model
checking & static analysis
Formalizing best practices
& design expertise
Model-Driven
Development
– State bullet”
of the Art technology
There
is no
single “silver
17 that resolves all software problems!
Promising Solution Approaches
Devising composable
abstractions whose
interfaces & QoS properties
can be specified/analyzed
via metadata
…
Logical
View
• Components encapsulate “business” logic
• Components interact via ports
• Provided ports, e.g.,facets
• Required ports, e.g., receptacles
• Event sink & source ports
• Containers provide execution environment
Components/containers can also
• Communicate via a middleware bus &
• Reuse common middleware services
• Aspect-oriented techniques can help with
integration
Model-Driven Development – State of the Art
18
…
…
…
Container
Container
Middleware Bus
Replication
Security
A/V Streaming
Persistence
Scheduling
Notification
Load Balancing
Promising Solution Approaches
Physical
View
Model-driven development & analysis
techniques for optimizing, verifying, &
automating the deployment &
configuration process
Model-Driven Development – State of the Art
Gigabit Ethernet
19
Promising Solution Approaches
• Synthetic workload & emulated
components
• Replaced incrementally with
actual applications & components
Software execution modeling & emulation
techniques & tools; distributed continuous
quality assurance
Process
View
• Automate QA processes
EO
Build & Test Scoreboard
TBM
AAW
AAW
EG
Sched
AAW
EG
Kill
Eval
Illum
AAW
AAW
MG
AAW
Gigabit Ethernet
TMB
MG
Model-Driven Development – State of the Art
20
Promising Solution Approaches
• Packages view – shows element
tree defined by project's build
class path
• Type hierarchy view – shows the
sub- & super-type hierarchies
• Outline view – shows the structure
of a compilation unit or class file
• Browsing perspective – allows
navigating models using separate
views for projects, packages,
types & members
• Wizards for creating elements –
e.g., project, package, class,
interface
• Editors – syntax coloring, content
specific code assist, code resolve,
method level edit, import
assistance, quick fix & quick assist
Model-Driven Development – State of the Art
Development
View
Development environments that provide
multiple views & minimize dependencies
between large-scale software artifacts to
21 optimize development & test cycles
Promising Solution Approaches
Domain-Specific Modeling
Languages
Automated tracing of
(in)consistency between
requirement specifications &
associated software artifacts
Matlab
Matlab
Artifact
Code-Gen
Code-Gen
Generator
Use Case
View
if (inactiveInterval != -1) {
int thisInterval =
(int)(SystemcurrentTimeMillis() lastAccessed) / 1000;
• One way to automate tracing
between higher-level specifications
& lower-level implementations is to
leverage model-driven development
techniques & tools
if (thisInterval > inactiveInterval) {
invalidate();
ServerSessionManager ssm =
ServerSessionManagergetManager();
ssmremoveSession(this);
}
}
}
private long lastAccessedTime = creationTime;
/**
* Return the last time the client sent a request
associated with this
* session, as the number of milliseconds since
midnight, January 1, 1970
* GMT Actions that your application takes, such as
getting or setting
* a value associated with the session, do not affect
the access time
*/
public long getLastAccessedTime() {
Configuration
Specification
return (thislastAccessedTime);
}
thislastAccessedTime = time;
Code
Analysis Tool
Model-Driven Development – State of the Art
22
Technology Evolution (1/4)
Model-Driven Development (MDD)
Programming Languages
& Platforms
Model
Level of Abstraction
Generated
Model
Code
Platform
• State chart
• Data & process flow
Large
Semantic
Gap
Operating
Systems
Hardware
C/Fortran
Assembly
Machine code
Model-Driven Development – State of the Art
23
• Petri Nets
Technology Evolution (2/4)
Programming Languages
& Platforms
•New languages & platforms have
raised abstraction level significantly
•“Horizontal” platform reuse
alleviates the need to redevelop
common services
Level of Abstraction
Model
Application Code
Generated
ApplicationCode
Code
Framework
Domain
Specific
Pattern
Framework
Language
Platform
Platform
Frameworks
•There are two problems, however:
Components
Frameworks
C++/Java
Class Libraries
C/Fortran
Operating
Systems
Assembly
Machine code
Hardware
Model-Driven Development – State of the Art
•Platform complexity evolved faster
than 3rd-generation languages
•Much application/platform code still
(unnecessarily) written manually
•Particularly for D&C & QA aspects
24
Technology Evolution (3/4)
Programming Languages
& Platforms
Model-Driven Development (MDD)
Model
Level of Abstraction
Generated Code
Application
Code
Framework
Domain Specific
Pattern
Framework
Language
Platform
Platform
Frameworks
Manual
translation
Saturation!!!!
Components
Frameworks
C++/Java
Class Libraries
C/Fortran
Operating
Systems
Assembly
Machine code
Hardware
Model-Driven Development – State of the Art
Semi-automated
Domain-specific
modeling languages
• ESML
• PICML
• Mathematic
• Excel
• Metamodels
Domain-independent
modeling languages
• State Charts
• Interaction Diagrams
• Activity Diagrams
• OMG is evaluating MDD via MIC PSIG
• mic.omg.org
25
Technology Evolution (4/4)
Programming Languages
& Platforms
Model
Model-Driven Development (MDD)
Needs
Automation
Level of Abstraction
Generated Code
Application
Code
Platform
Platform
Frameworks
Needs
Automation
Domain-specific
modeling languages
• ESML
• PICML
• Mathematic
• Excel
• Metamodels
Domain-independent
modeling languages
• State Charts
• Interaction Diagrams
• Activity Diagrams
Saturation!!!!
Components
Frameworks
Needs Automation
C++/Java
Class Libraries
C/Fortran
Operating
Research is needed to automate
Systems
Assembly
DSLs & model translators
Machine code
Hardware
Model-Driven Development – State of the Art
26
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
27
CONTENTS
The MDD Blueprint
Typically you start with a
manually built application
ApplikationsApplikationsApplication
Modell
Modell
Model
Code of Application or
Reference Implementation
DSL
Transformations
& code that is
completely
individual to
the application
You analyze
separate
it with
respect to
analyse
Individual
Code
Schematic
Repetitive
Code
Code that is always
Schematic of
identical in applications
that Repetitive
kind
Generic
Code
Code
Code that has the same
structure/patterns in all
cases
Model-Driven Development – State of the Art
Handcrafted
Handcrafted
Individual
Code
Code
Code
28
uses
creates
Platform
The MDD Blueprint
Application Models describe the
repetitive aspects in an abstract
& concise way using a DomainCode of Application or
Specific Language
Reference Implementation
ApplikationsApplikationsApplication
Modell
Modell
Model
DSL
Transformations
Transformations create the
analyse
repetitive code from
the
separate
application models
Handcrafted
Handcrafted
Individual
Code
Code
Code
Individual
Code
Schematic
Repetitive
Code
Generic
Code
Platform
Schematic
Repetitive
Code
uses
creates
The generic, identical code
becomes the platform
Model-Driven Development – State of the Art
29
A UML-based Ontology for MDD
• Isn‘t OMG/MDA terminology sufficient?
– Useful as a basis, but perspectives of
domain engineering, product lines &
software system families missing or
weak
• What is an Ontology?
– Representation of knowledge: definition
of concepts & their relationships
• Why UML for that?
– Provides a popular & standardized
notation for concepts (classes) &
typical categories of relations
(Association, Composition, InstanceOf,
Realization, Uses, …)
– Allows for definition of specific
categories through profiling
Model-Driven Development – State of the Art
30
Domain, Model, & DSL
• A domain describes a bounded area of knowledge or interest
– It can be structured into various subdomains
• A metamodel is a formal representation of the concepts in that particular
(sub-)domain, as well as their relationships
– A metamodel is also called the abstract syntax (of a DSL)
Model-Driven Development – State of the Art
31
Domain, Model, & DSL
• A Domain-Specific Language (or DSL) comprises
– The metamodel (the concepts it represents)
– A concrete syntax to represent these concepts
– As well as the semantics of the concepts
• A DSL is sometimes called a domain-specific modeling language (DSML)
Model-Driven Development – State of the Art
32
Domain, Model, & DSL
• A formal model (or just “model”) built by the DSL
– Is an instance of its metamodel & respects the static semantics
– Uses the concrete syntax of the DSL
– & gets its meaning from the DSLs semantics
Model-Driven Development – State of the Art
33
Platform
• A platform supports a domain
• Platforms can be cascaded, i.e., they are based on top of each other (see
later)
• A platform consists of a number of building blocks
– these can be middleware, libraries, frameworks, components, or aspects
– as well as documentation & tests, of course
supports
Domain
Plattform
0..*
based on
<<abstract>>
Building
Block
{open}
Middleware
Library
Model-Driven Development – State of the Art
Framework
34
Component
Aspect
Product
• The finished product
contains the platform
• It consists of generated
artifacts, as well as nongenerated artifacts, i.e.,
manually implemented
artifacts
• Both of these types of
artifacts know about &
rely on the platform
Model-Driven Development – State of the Art
35
Transformation
• The product – specifically, the generated artifacts – must be built
– From the formal models describing the system,
– Using a number of different transformations
• A transformation always uses a formal model as its source, thus it relies
on the metamodel on which this formal model is built
Model-Driven Development – State of the Art
36
Transformation
• Model-to-Model Transformations also produce a formal model as the
output
• This is typically based on a different metamodel
• The transformation also relies this target metamodel
• The M2M step can be repeated any number of times in the context of
MDD, the models typically becoming more specific to the platform
Model-Driven Development – State of the Art
37
Transformation
• Finally, Model-to-Platform (or model-to-code) transformations use the
formal model to produce the generated artifacts
• These rely on & make use of the platform idioms (“patterns”)
• The Idioms, together with the generated artifacts have to realize the
semantics of the model
Model-Driven Development – State of the Art
38
Domain Architecture
• A domain architecture comprises
– The DSL(s)
– The platform
– The transformations needed to transform models built using the DSLs
into code that runs on the platform
Model-Driven Development – State of the Art
39
Domain Architecture
• A software system familiy can be implemented using such a domain
architecture
• In turn, a software system familiy can be used to support (or realize)
product lines
• A product line then consists of a number of the products built using the
software system family’s domain architecture
Model-Driven Development – State of the Art
40
MDA Terms
Meta
Meta Model
Abstract
Syntax
<<MDA>>
<<MDA>>
specified on
basis of
Formal
isModel
Object Facility
the OMG’s Meta Meta
Model XMI is based on top
of it, as is UML
Grafical
Syntax
<<MDA>>
Action
Semantics
MOF
Concrete
The
Meta
Syntax
Model2Model
Transformation
Semantics
<<MDA>>
QVT
Action Semantics can be
specific to
used to add additional
Platform
semantics & behaviour to
models
runs on
refines
PIM
<<MDA>>
PSM
Static
Semantics
<<MDA>>
OCL
Model-Driven Development – State of the Art
41
describes
relevant
concepts of
OCL can also add
<<MDA>>
Executable
semantics by defining
PDM
Model
constraints
<<MDA>>
<<MDA>>
UML Profile
Query/Views/Transformations is the
OMG’s M2M
standard
MDA Terms
Meta
Meta Model
Abstract
Syntax
Model2Model
Transformation
Semantics
MDA models are typically
<<MDA>>
(not mandatorily)
based on
<<MDA>>
Action
UML + Profiles
MOF
<<MDA>>
QVT
Semantics
Concrete
Syntax
specified on
basis of
specific to
Formal
Model
Platform
runs on
Grafical
Syntax
<<MDA>>
refines
PIM
<<MDA>>
PSM
<<MDA>>
Executable
Model
describes
relevant
concepts of
<<MDA>>
PDM
<<MDA>>
UML Profile
<<MDA>>
OMGOCL
distinguishes
between platform
specific & platform
independent models
Model-Driven Development – State of the Art
42
Static
Semantics
Platform Description
models are basically
metamodels of the
platform
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD &
Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
43
CONTENTS
Architecture – Centric (AC) Model – Driven
Development (MDD) Concept Adoption
<<acmdsd>>
Generative
Architecture
<<acmdsd>>
Code
Snippet
<<acmdsd>>
Domain
Architecture
Design
Language
The domain is architecturally motivated
<<acmdsd>>
Non-generated
Architecture-centric
e.g., architecture
for business
software
Artifact
Meta Model
or component infrastructure for embedded
systems
DSL
Meta Model
complements
<<acmdsd>>
Skeleton
Target
<<acmdsd>>
Template
Generated
Artifact
1..*
<<acmdsd>>
Design
Target
Model2Platform
Transformation
Model-Driven Development – State of the Art
44
Formal
Model
AC – MDD Concept Adoption
<<acmdsd>>
Generative
Architecture
<<acmdsd>>
Code
Snippet
<<acmdsd>>
Domain
Architecture
Design
Language
DSL
<<acmdsd>>
The products to be created are
Non-generated
Architecture-centric
Artifact
usually complete applications,
Meta Model
Meta Model
not single components
complements
<<acmdsd>>
Skeleton
Target
<<acmdsd>>
Template
Generated
Artifact
1..*
<<acmdsd>>
Design
Target
Model2Platform
Transformation
Model-Driven Development – State of the Art
45
Formal
Model
AC – MDD Concept Adoption
<<acmdsd>>
Generative
Architecture
<<acmdsd>>
Code
Snippet
complements
<<acmdsd>>
Skeleton
Target
<<acmdsd>>
Template
Domain
From the
Architecture
<<acmdsd>>
black boxDesign
view, usually
only single-step Language
model-to-platform
transformations exists
However, these can be
internally
<<acmdsd>>
Architecture-centric
structured,
serving
Meta Model
modularization purposes for
sequential execution of several
transformations
Non-generated
(white box)
Artifact
Generated
Artifact
1..*
<<acmdsd>>
Design
Target
Model2Platform
Transformation
Model-Driven Development – State of the Art
46
DSL
Meta Model
Formal
Model
AC – MDD Concept Adoption
<<acmdsd>>
Generative
Architecture
<<acmdsd>>
Code
Snippet
Domain
Architecture
The DSL’s metamodel therefore
contains architectural
concepts
<<acmdsd>>
that are as abstract
Design as possible i.e.,
Language
“component”
& not “EJB 3 stateless
session bean”
Non-generated
Artifact
DSL
<<acmdsd>>
Architecture-centric
Meta Model
Meta Model
complements
<<acmdsd>>
Skeleton
Target
<<acmdsd>>
Template
Generated
Artifact
1..*
<<acmdsd>>
Design
Target
Model2Platform
Transformation
Model-Driven Development – State of the Art
47
Formal
Model
AC – MDD Concept Adoption
<<acmdsd>>
Generative
Architecture
<<acmdsd>>
<<acmdsd>>
Domain
Architecture
Design
Language
The DSL is also called the design
language
Code
Snippet
Non-generated
profilesArtifact
are used
<<acmdsd>>
Often, UML
here, Architecture-centric
Meta Model
sometimes combined with additional
complements
textual specifications
<<acmdsd>>
Skeleton
Target
<<acmdsd>>
Template
Generated
Artifact
1..*
<<acmdsd>>
Design
Target
Model2Platform
Transformation
Model-Driven Development – State of the Art
48
DSL
Meta Model
Formal
Model
AC – MDD Concept Adoption
<<acmdsd>>
Generative
Architecture
<<acmdsd>>
Code
Snippet
complements
<<acmdsd>>
Skeleton
Target
<<acmdsd>>
Template
<<acmdsd>>
Domain
Architecture
Design
Language
<<acmdsd>>
Typically,
the model-to-platform
Non-generated
Architecture-centric
Artifact is a template that
transformation
Meta Model
shows great similarity to the
generated code & thus can easily
be extracted from a reference
Generated
<<acmdsd>>
implementation
Artifact
1..*
Design
Target
Model2Platform
Transformation
Model-Driven Development – State of the Art
49
DSL
Meta Model
Formal
Model
AC – MDD Concept Adoption
<<acmdsd>>
Generative
Architecture
<<acmdsd>>
Code
Snippet
The transformation
does not<<acmdsd>>
Domain
Design
aim atArchitecture
creating the completeLanguage
application, but merely an
implementation framework
containing the architectural
<<acmdsd>>
Non-generated
infrastructure
code (skeleton)
Architecture-centric
Artifact
DSL
Meta Model
Meta Model
complements
<<acmdsd>>
Skeleton
Target
<<acmdsd>>
Template
Generated
Artifact
1..*
<<acmdsd>>
Design
Target
Model2Platform
Transformation
Model-Driven Development – State of the Art
50
Formal
Model
AC – MDD Concept Adoption
<<acmdsd>>
Generative
Architecture
<<acmdsd>>
Code
Snippet
The non-generated, implementation code
(“business logic”) is manually implemented in
the target language (code<<acmdsd>>
snippet)
Domain
ForArchitecture
this purpose,
Design
the generated
skeleton may
Language
contain protected regions for supplementing the
application logic that will persist after iterative
regeneration
<<acmdsd>>
DSL
Non-generated
Architecture-centric
Meta Model
Artifactgenerated & non-generated code is
Alternatively,
Meta Model
integrated using suitable design patterns
complements
<<acmdsd>>
Skeleton
Target
<<acmdsd>>
Template
Generated
Artifact
1..*
<<acmdsd>>
Design
Target
Model2Platform
Transformation
Model-Driven Development – State of the Art
51
Formal
Model
Recipe F/W for Integrating Manually Written Code
• Recipe Frameworks help developers to write the “correct” manual
code by applying checks on the complete (manual & generated) code
Model-Driven Development – State of the Art
52
Recipe F/W for Integrating Manually Written Code
• Recipe Frameworks help developers to write the “correct” manual
code by applying checks on the complete (manual & generated) code
During code generation, a recipes file
is created by the generator The file is
then read by the IDE
Model-Driven Development – State of the Art
53
Recipe F/W for Integrating Manually Written Code
• Recipe Frameworks help developers to write the “correct” manual
code by applying checks on the complete (manual & generated) code
The IDE evaluates the
checks in the recipe file &
points to problems in the
manually written code
Model-Driven Development – State of the Art
54
Recipe F/W for Integrating Manually Written Code
• Recipe Frameworks help developers to write the “correct” manual
code by applying checks on the complete (manual & generated) code
Checks that are ok are
rendered in green (or
can be filtered out)
Model-Driven Development – State of the Art
55
Recipe F/W for Integrating Manually Written Code
• Recipe Frameworks help developers to write the “correct” manual
code by applying checks on the complete (manual & generated) code
You can get more
detailed information on
the checks executed
Model-Driven Development – State of the Art
56
Recipe F/W for Integrating Manually Written Code
• Recipe Frameworks help developers to write the “correct” manual
code by applying checks on the complete (manual & generated) code
& a nice explaing text
that tells developers
what to do to fix the
problem
Model-Driven Development – State of the Art
57
Recipe F/W for Integrating Manually Written Code
• Recipe Frameworks help developers to write the “correct” manual
code by applying checks on the complete (manual & generated) code
You can reevaluate
checks at any time
Model-Driven Development – State of the Art
58
Recipe F/W for Integrating Manually Written Code
• Recipe Frameworks help developers to write the “correct” manual
code by applying checks on the complete (manual & generated) code
A “quick fix” button
will be added till final
release of oAW 4
Model-Driven Development – State of the Art
59
Cascading MDD Using Platform Stacking
• The generated code of the lower layer serves as the platform for the
next higher level
• A sequence of generation steps is used, whereas each of the
generates code on which the next step builds
Model-Driven Development – State of the Art
60
Cascading MDD Using M2M
• Here the higher level models are transformed into lower-level models
that serve as input for the lower level generators Model-to-Model
Transformations are used
• Typically, higher level
models are more
specific to a certain
(sub-)domain
Model-Driven Development – State of the Art
61
Example for “Business Level” DSL
SomePlace: Generator
end11
T11: Transformer
link13
link14
220KV: Bus
transmissionLine1
link12
end21
20KV: Bus
SomeOtherPlace: SwitchingStation
link11
link21
B21-220KV: Bus
G11: GenerationElement
link22
T21: Transformer
link23
B22-10KV: Bus
link24
end22
Model-Driven Development – State of the Art
62
DYI vs 3rd Party Cartridges
• Do you build your own generator for your specific architecture?
– This is good, because it’s tailored to your architecture
• Or do you want to (re)use off-the-shelf cartridges for certain standard
technologies (such as J2EE, Hibernate, Spring)?
Conceptional
Architecture
Model
• You can do the best of both worlds:
– Define applications using your own metamodels
(architecture-centric, maybe funtional ones on top)
– Transform your models to input models for the off-theshelf cartridges on the lower levels
Generator
Cartridge
Specific
for the
Conceptional
architecture
Model suitable
for C2
Off-the-Shelf
Cartridge C2
Code generated
by C2
Manually
written code
Model suitable
for C3
Off-the-Shelf
Cartridge C3
Code generated
by C3
Project Specific
Code
Model-Driven Development – State of the Art
63
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the
Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
64
CONTENTS
Overview of Patterns
•Present solutions
to common
software problems
arising within a
certain context
•Help resolve
key software
design
forces
•Capture recurring structures &
dynamics among software
participants to facilitate reuse of
successful designs
•Generally codify expert
knowledge of design strategies,
constraints & “best practices”
•Flexibility
•Extensibility
•Dependability
•Predictability
•Scalability
•Efficiency
AbstractService
service
Client
Proxy
service
Service
1
1
service
The Proxy Pattern
Model-Driven
Development
of the Artmany
MDD tools
codify &– State
automate
65 by no means all) aspects of patterns
(but
Overview of Pattern Languages
Motivation
•Individual patterns &
pattern catalogs are
insufficient
•Software modeling methods
& tools largely just illustrate
what/how – not why –
systems are designed
Benefits of Pattern Languages
• Define a vocabulary for talking about software development problems
• Provide a process for the orderly resolution of these problems, eg:
• What are key problems to be resolved & in what order
• What alternatives exist for resolving a given problem
• How should mutual dependencies between the problems be handled
• How to resolve each individual problem most effectively in its context
• Help to generate & reuse software architectures
Model-Driven Development
State of the Art are
Pattern– languages
66 for DSLs & frameworks
crucial
Overview of Frameworks
Framework Characteristics
•Frameworks exhibit
“inversion of control” at
runtime via callbacks
•Frameworks provide
integrated domain-specific
structures & functionality
•Frameworks are
“semi-complete”
applications
Application-specific
functionality
Mission
Computing
Scientific
Visualization
E-commerce
GUI
Networking
Model-Driven Development – State of the Art
Database
67
Benefits of Frameworks
• Design reuse
• e.g., by guiding application
developers through the steps
necessary to ensure successful
creation & deployment of
software
AdminClient
Admin
Controllers
Admin
Views
Proxy
PickingClient
Picking
Controllers
Thin UI Clients
Broker
Picking
Views
Proxy
Broker
Distribution
Infrastructure
OS-Access
Layer
Component
Repository
Communication
Component
Configurator
Services
Broker
Broker
Scheduler/
ActivationList
Reactor
Service
Request
Logging
Handler
ThreadPool
Service
Request
Service
Request
WarehouseRepHalfX
Model-Driven Development – State of the Art
68
*
Concurrency
Infrastructure
Benefits of Frameworks
package orgapachetomcatsession;
• Design reuse
• e.g., by guiding application
developers through the steps
necessary to ensure successful
creation & deployment of
software
• Implementation reuse
• e.g., by amortizing software
lifecycle costs & leveraging
previous development &
optimization efforts
import
import
import
import
import
import
import
orgapachetomcatcore*;
orgapachetomcatutilStringManager;
javaio*;
javanet*;
javautil*;
javaxservlet*;
javaxservlethttp*;
/**
* Core implementation of a server session
*
* @author James Duncan Davidson [duncan@engsuncom]
* @author James Todd [gonzo@engsuncom]
*/
public class ServerSession {
private StringManager sm =
StringManagergetManager("orgapachetomcatsession");
private Hashtable values = new Hashtable();
private Hashtable appSessions = new Hashtable();
private String id;
private long creationTime = SystemcurrentTimeMillis();;
private long thisAccessTime = creationTime;
private int inactiveInterval = -1;
ServerSession(String id) {
thisid = id;
}
public String getId() {
return id;
}
public long getCreationTime() {
return creationTime;
}
public ApplicationSession getApplicationSession(Context context,
boolean create) {
ApplicationSession appSession =
(ApplicationSession)appSessionsget(context);
if (appSession == null && create) {
// XXX
// sync to ensure valid?
}
//
//
//
//
}
appSession = new ApplicationSession(id, this, context);
appSessionsput(context, appSession);
XXX
make sure that we haven't gone over the end of our
inactive interval -- if so, invalidate & create
a new appSession
return appSession;
void removeApplicationSession(Context context) {
appSessionsremove(context);
}
Model-Driven Development – State of the Art
69
Benefits of Frameworks
• Design reuse
• e.g., by guiding application
developers through the steps
necessary to ensure successful
creation & deployment of
software
• Implementation reuse
• e.g., by amortizing software
lifecycle costs & leveraging
previous development &
optimization efforts
• Validation reuse
• e.g., by amortizing the efforts of
validating application- &
platform-independent portions
of software, thereby enhancing
software reliability & scalability
Model-Driven Development – State of the Art
70
Summary of Pattern, Framework, & MDD Synergies
These technologies codify expertise of domain experts & developers
• Frameworks codify
expertise in the form of
reusable algorithms,
component & service
implementations, &
extensible architectures
• Patterns codify expertise in
the form of reusable
architecture design themes &
styles, which can be reused
event when algorithms,
components implementations,
or frameworks cannot
Application-specific
functionality
• MDD tools codify
expertise by automating
key aspects of pattern
languages & providing
developers with domainspecific modeling
languages to access the
powerful (& complex)
capabilities of frameworks
Model
Acceptor
Connecto
r
Stream
Component
Configurator
Generated
ApplicationCode
Code
Task
Reactor
Framework
Domain
Specific
Pattern
Framework
Language
Proactor
Platform
Platform
Frameworks
There Development
are now powerful
Model-Driven
– State of thefeedback
Art
loops
advancing these technologies
71
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD &
Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
72
CONTENTS
Motivation 1
• Why take a look at compiler construction?
• The core concepts of MDD generators are
the same as in compiler construction
C++ Program
– Formal Languages
– Transformation of formal artifacts on a
higher abstraction level into formal
artifacts on lower abstraction level
(i.e., raising the abstraction level for
programming)
– Modularity
• Compiler construction is a domain, which
is well understood
• We should be able to harvest some of the
experiences made there: Generators
ARE Compilers
Model-Driven Development – State of the Art
73
C++ Compiler
Internal Rep.
PPC
Opt.
MIPS
Opt.
88K
Opt.
PPC
MIPS
88K
Motivation 2
• So compiler construction might give
hints for MDD/A tool developers, but
why should “users” care about it?
• Construction criteria that have proven
good, are selection criteria too
• We can adopt a clear & unambiguous
terminology
• In the context of MDD we need
openness
Model
Model
– Adopting or creating own DSLs
– Adopting or creating own
Transformations
That means, the user (i.e., architect) is
involved & confronted to some
extent with the inner structure of
the compile process
Model-Driven Development – State of the Art
74
Generated
ApplicationCode
Code
Generated
Code
Platform
Platform
Platform
Frameworks
Compiler Construction Blue Print
Artifacts
Workflow
Meta-Artifacts
Program Text
Programming Language
(e.g., C++ Source-Code)
Concrete Syntax
(e.g., C++ or Java)
Compiler-Frontend
= Parser
Abstract Syntax
Abstract Syntax Tree
Checker
Optimizer
Static Semantics
(e.g., Declaration of
Variables)
Compiler-Backend
= Codegenerator
Dynamic Semantics
Generated Code
Runtime System
Model-Driven Development – State of the Art
75
Core Concept: Abstract Syntax
Responsibilities of Abstract Syntax
• Modularity of the compiler: Interface between Frontend & Backend
• Neutralisation of different Concrete Syntaxes (e.g., C & PASCAL)
• Pluggability for different backends (e.g., codegen for Intel/PC or Mainframe)
• Interface for modification of program structure (e.g., optimization)
Parser 1
Parser 2
Abstract Syntax
Modification
Codegen 2
Codegen 1
Model-Driven Development – State of the Art
76
Mapping of Concepts
Compiler Construction
(specific concepts)
Model-Driven Software Development
(general concepts)
Programming Language
Program (Source-Code)
Concrete textual syntax
Abstract Syntax
Static Semantics
Program Editor
Parser
Code Generation
Optimization
Runtime System
A kind of DSL
A kind of Model
A kind of concrete syntax
Part of Meta-Model
Modeling-Constraints
A kind of DSL Editor
Model-Reader
Model 2 Code Transformation
A kind of Model-2-Model Transformation
Platform
The plain compiler view on MDD is quite “code-generation centric” &
seems to focus textual languages, but in fact MDD takes advantage from
generalization & further abstraction of those concepts It‘s an evolution
Model-Driven Development – State of the Art
77
MDD from Another Perspective
So the task of creating a domain
architecture from the perspective of
compiler construction means:
DSL
DSL Parser
–Define a formal language with
concrete & abstract syntax & static
semantics (DSL)
Abstract Representation
Static
Semantic
Checker
–Implement a Parser for the DSL
–Implement the static semantics
M2MTransformation
–Implement Modifiers or
Transformations based on the
abstract syntax (M2M-Transformations)
Codegenerator
Transformations
–Implement a runtime system
(Platform)
–Implement one or more backends
(M2C-Transformations)
Model-Driven Development – State of the Art
78
Generated Code
Runtime System
How MDD Tools Can Help
Domain-Specific Modeling
Languages
Many of these tasks are supported by
generic tools or frameworks, eg:
– Generic DSLs with extension
mechanisms (e.g., UML)
– Parser- resp DSL-EditorGenerators
– AS-Modeling & Generation
(Metamodel Generators)
Matlab
Matlab
Artifact
Code-Gen
Code-Gen
Generator
– Constraint-Languages (e.g., OCL)
– M2M-Transformation-Languages
& Implementations/Interpreters
if (inactiveInterval != -1) {
int thisInterval =
(int)(SystemcurrentTimeMillis() lastAccessed) / 1000;
if (thisInterval > inactiveInterval) {
invalidate();
ServerSessionManager ssm =
ServerSessionManagergetManager();
ssmremoveSession(this);
}
}
}
private long lastAccessedTime = creationTime;
– M2C-Transformation-Languages &
Implementations/Interpreters
– Reusable Meta-Artifacts
(Cartridges)
Model-Driven Development – State of the Art
/**
* Return the last time the client sent a request
associated with this
* session, as the number of milliseconds since
midnight, January 1, 1970
* GMT Actions that your application takes, such as
getting or setting
* a value associated with the session, do not affect
the access time
*/
public long getLastAccessedTime() {
return (thislastAccessedTime);
}
thislastAccessedTime = time;
Code
Configuration
Specification
79
Analysis Tool
MDD Tool Blueprint
Architect‘s Input
Tool Support (Open Compiler)
DSL-Editor Generator
Generic DSL-Editor
Formal
Language and
Parser
Parser Generator
DSL-Profile
DSL-Grammar Spec
Metamodel
AS
Metamodel Generator
Constraint Engine
DSL-Model
Static Sematics
Constraints
M2M Transformations
M2M Engine
Backend
M2C Transformations
Template Engine
Runtime System
Model-Driven Development – State of the Art
80
MDSD-Platform
Example: openArchitectureWare (oAW)
oAW – brief introduction
• Open MDD-Framework (i.e., a framework that enables you to write
compilers/generators in the former sense)
• Open-source since 11/2002, contributed to the community by b+m
Informatik AG (www.bmiag.de)
• More on that later
Model-Driven Development – State of the Art
81
oAW – an Object–Oriented Compiler Framework
• Object-orientation is useful for compiler construction, because
– an Abstract Syntax naturally maps to an object-oriented implementation
(Meta Classes, Associations …)
– Unmaintainable switch/case statements on syntax element types can
be avoided in transformations by using polymorphism & late binding
– For usual compilers (C++, Pascal …), this is a view into the black box
From the viewpoint of the user the construction details of the compiler
are irrelevant
– Note that this does NOT hold in the MDD context, since
the AS/MM is plugged into the framework
So we are in need of an open compiler/generator framework
– Each Meta-Element has the responsibility to translate itself
– Polymorphism can be used at the meta level
Model-Driven Development – State of the Art
82
Object–Orientation in oAW
Model expressed via Concrete
Syntax (e.g., UML-Profile)
MetaModel / Abstract Syntax
(oAW: Implementation in Java)
Responsibilities (Object-Oriented)
Check: Every “EntityObject” must
have at least one “key”-Attribute
M2C-Template: Generate EJB-Home-Interface
M2C-Template: Generate Hibernate-Mapping
Helper/Property:
Return a full qualified
Java-Classname
• Some Responsibilities are implemented in Java (Properties, Checks), others
using oAW-Template language (M2C)
Model-Driven
– State of
• They areDevelopment
implemented
inthe
orArt
decorated
83 on
the respective Meta-Classes
openArchitectureWare – Blueprint
oAW - Workflow and Information Flow
Domain Architecture 1
<<uses>>
DSL
Metamodel
Implementation
Model Reader /
Parser
<<instanceof>>
Domain Architecture n
Model
Instantiated
Metamodel (1)
Constraints
M2MTransformationImplementation
Constraint Check
[error]
M2M-Transformation
DSL
Instantiated
Metamodel (n)
<<instanceof>>
Metamodel
Implementation
Constraints
M2CTransformationImplementation
Application
Hand written
Code
<<integra tes into>>
Constraint Check
[error]
Generated Code
<<relies on>>
M2C Transformation
(Template-Engine)
Platform n
Model-Driven Development – State of the Art
84
Platform n
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
85
CONTENTS
Why You Need M2M
• As explained earlier, cascading MDD requires model-to-model
transformations
Input Models
...
...
...
...
...
...
MDSDInfrastructure
Output Model
Model for Subdomain 1
Model for Subdomain 2
M2M/Code
Generator for SD 1
M2M/Code
Generator for SD 2
Programming Model (based on Arch-MM)
Code Generator for
Architectural MDSD Infrastructure
Code for Target Platform
Model-Driven Development – State of the Art
86
Modular, Automated Transformations
• To more easily reuse parts of a transformation, it is a good idea to
modularize a transformation
• Note that in contrast to the OMG, we do not recommend looking at,
changing, or marking the intermediate models
• They are merely a
standardized format
for exchanging data
among transformations
Bank /
OO
OO Metamodel
OO/
J2EE
BankingMetamodell
J2EE Metamodel
Bank /
Prozess
Process
Metamodel
BEA/
Java
J2EE/
IBM
J2EE/
BEA
• Example: Multi-Step
transformation from
a banking-specific
DSL to Java via J2EE
Process/
J2EE
WLS
Metamodel
Java
Metamodel
IBM/
Java
Model-Driven Development – State of the Art
87
WebSphere
Metamodel
Modular, Automated Transformations II
• Example cont’d:
Now consider a Call-Center application; only the first step needs to be
adapted
CC /
OO
OO Metamodel
...
CallCenter
Metamodel
...
CC /
Prozess
Process
Metamodel
...
• If both should be transformed to NET, only the backend needs to be
exchanged
OO Metamodel
OO/
.NET
.NET Metamodel
Process
Metamodel
Prozess/
.NET
Model-Driven Development – State of the Art
88
.NET/
C#
C# Metamodel
Transforming “in the Tool”
Model
(UML)
export
Developer builds
model using for
example a UML
tool
Parser
Model
(XMI)
openArchitectureWare
(may be repeated)
Model
(Object Graph)
Model
Transformer
Generated
Code
Modified Model
(Object Graph)
Code
Generator
Model-Driven Development – State of the Art
89
Transforming “in the Tool”
Model
(UML)
export
openArchitectureWare
(may be repeated)
Parser
Model
(XMI)
Model
(Object Graph)
The XMI produced byModel
the UML tool is parsed
Transby the generator tool former
–
& an AST is created in
memory
Generated
Code
Modified Model
(Object Graph)
Code
Generator
Model-Driven Development – State of the Art
90
Transforming “in the Tool”
Model
(UML)
export
Model
(XMI)
openArchitectureWare
(may be repeated)
Parser
Inside the generator,
Model
model-to-model
transformations are used to (Object Graph)
build new or modified ASTs
The intermediate ASTs
cannot be modified
interactively by the
developer
Generated
Code
Model
Transformer
Modified Model
(Object Graph)
Code
Generator
Model-Driven Development – State of the Art
91
Transforming “in the Tool”
Model
(UML)
export
openArchitectureWare
(may be repeated)
Parser
Model
(XMI)
Model
(Object Graph)
In a final step, code
is generated from
the AST
Generated
Code
Model
Transformer
Modified Model
(Object Graph)
Code
Generator
Model-Driven Development – State of the Art
92
External Model Markings (AO–Modeling)
• To allow the transformation of a source model into a target model (or to
generate code) it is sometimes necessary to provide “support”
information that is specific to the target meta model
– Example: Entity Bean vs Type Manager
• Adding these to the source model “pollutes” the source model with
concepts specific to the target model
• MDA proposes to add “model markings,” but this currently supported
only by a few tools
• Instead, we recommend keeping this information outside of the model
(e.g., in an XML file)
– The transformation engine would use this auxiliary information when
executing the transformations
This is an example of “aspect-oriented programming/modeling”
Model-Driven Development – State of the Art
93
M2M: One Metalevel Higher
– Precondition:
Representing a class diagram of metalevel n as an object diagram of
metalevel n+1
Model-Driven Development – State of the Art
94
Model–to–Model Transformations: QVT
• Most of the transformations built thus far have been constructed with Java
code
– If the metaclasses have a well-designed API (repository API) then this
“procedural transformations” does indeed work well
• However, more dedicated model transformation languages are
becoming available:
– e.g., ATL, MOLA, Wombat (oAW), etc
• The QVT standard is
becoming a reality
– It will be finalized by
the end of 2006
• QVT actually comprises
three languages:
Model-Driven Development – State of the Art
Relations
Language
defined
In terms of
Black Box
Mappings
Operation
Mappings
Language
Java
.NET
Core
Language
95
Model–to–Model Transformations: QVT Relational
top relation EntityKeyToTableKey {
checkonly domain alma entity:Entity {
key = entityKeyField:Field {}
};
}
enforce domain db table:Table {
key = tableKey:Key {}
relation PhysicalQuantityTypeToColumn {
};
pqName, pqUnit, fieldName : String;
when {
EntityToTable(entity, table); checkonly domain alma field:Field {
name = fieldName,
}
type = pq:PhysicalQuantityType {
where {
name = pqName,
KeyRecordToKeyColumns(entityKeyField,
unitstable);
= pqUnit
}
}
};
enforce domain db table:Table {
columns = column:Column {
name = prefix + fieldName + '_as_' +
pqName + '_in_' + pqUnit,
type = AlmaPhysicalQuantityTypeToDbType(pq)
}
};
primitive domain prefix:String;
}
Model-Driven Development – State of the Art
96
M2M–Transformations: QVT Operational
mapping DependentPart::part2table(in prefix : String) : Table
inherits fieldColumns {
var dpTableName := prefix + recordName;
name := dpTableName;
columns := mainColumns +
object Column {
name := ‘key_’ + dpTableName;
type := ‘INTEGER’;
inKey := true;
}
end { self.parts->map part2columns(result, dpTableName + ‘_’); }
}
query PrimitiveType::convertPrimitiveType() : String =
if self.name = "int" then 'INTEGER‘
else if self.name = "float" then 'FLOAT‘
else if self.name = "long" then 'BIGINT‘
else 'DOUBLE'
endif endif endif;
Model-Driven Development – State of the Art
97
name: String
firstName : String
birthDate: Date
Target
Person
Source
Transformations in Java: Example
<<interface>>
<<interface>>
PersonIF
EntityBean
age()
getName()/setName()
getFirstName()/setFirstName()
getBirthDate()/setBirthDate()
age(): int
<<logically implements>>
PersonBean
name: String
firstName : String
birthDate: Date
ejbActivate()/ejbPassivate()
ejbLoad()/ejbStore()
ejbCreate()/ejbDestroy()
age()
getName()/setName()
getFirstName()/setFirstName()
getBirthDate()/setBirthDate()
Person
age(): int
Target
Source
name: String
firstName : String
birthDate: Date
<<EJB::EntityBean>>
Person
{transactions=tx.cmt,
persistence=persistence.bmp.hibernate,
interface=interfaces.remoteOnly}
name: String
firstName : String
birthDate: Date
age(): int
Model-Driven Development – State of the Art
98
<<interface>>
PersonHomeIF
create()
Transformations in Java: Example Transformation
• With good metaclasses, this works acceptably well today
Model createEJBModel( Model source ) {
Model target = new Model();
foreach c:Class in sourceclasses {
ImplementationClass implClass = new ImplementationClass();
implClass.setName( c.getName()+"Bean" );
target.addClass( implClass );
Dependencies.define( implClass, c );
RemoteInterface ri = new RemoteInterface ();
// set name & add it to target model
HomeInterface hi = new HomeInterface ();
// set name & add it to target model
foreach o:Operation in c.operations {
// bidirectional, because of generated API
ri.addOperation( new Operation( o.clone() ) );
implClass.addOperation( new Operation( o.clone() ) );
}
}
return target;
}
Model-Driven Development – State of the Art
99
Graphical M2M: UMLX
in
class:
component:
UML::Class
CM::Component
1
Class
assocAttribute
UML::Attribute
name = $n
driver
<<UML::Class>>
Vehicle
*
AssociationEnd
thisSideEnd:
plate : String
type: String
UML::AssociationEnd
drive() : void
Person
name : String
otherSideEnd:
UML::AssociationEnd
roleName = $n
navigable = true
assoc:
<<CM::Component>>
<<CM::Component>>
UML::Association
Vehicle
Person
plate : String
type: String
driver : Person
name : String
drive() : void
Model-Driven Development – State of the Art
100
out
Many Means of Transformations
• Today, many means of transformations are used:
• ISIS GReAT
• Plain old Java
• Several partial QVT implementations
• Eclipse GMT ATL
• UMLX
• IBM MTF
• A paper by Czarnecki/Helsen gives a very good overview:
www.swen.uwaterloo.ca/~kczarnec/ECE750T7/czarnecki_helsen.pdf
Model-Driven Development – State of the Art
101
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process –
A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
102
CONTENTS
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
103
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
104
Phase 1: Elaborate!
• This first elaboration phase
should be handled by a small
team, before the architecture is
rolled out to the whole team
• We want to build an enterprise
system that contains various
subsystems such as customer
management, billing & catalogs
CRM
Billing
Catalogs
• In addition to managing the data
using a database, forms & the
like, we also have to manage the
associated long-running
business processes
• We will look at how we can
attack this problem below
Model-Driven Development – State of the Art
Database
105
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
106
Technology–Independent Architecture
• We decide that our system will be built from components
– Each component can provide a number of interfaces
– It can also use a number of interfaces (provided by other
components)
– Communication is synchronous, Communication is also restricted to
be local
– We design components to be stateless
• In addition to components, we also explicitly support business
processes
– These are modeled as a state machine
– Components can trigger the state machine by supplying events to
them
– Other components can be triggered by the state machine, resulting in
the invocation of certain operations
– Communication to/from processes is asynchronous, remote
communication is supported
Model-Driven Development – State of the Art
107
Technology–Independent Architecture
• We decide that our system will be built from components
– Each component can provide a number of interfaces
– It can also use a number of interfaces (provided by other
components)
– Communication is synchronous, Communication is also restricted to
be local
– •We
design
components
to be stateless
Use
well-known
architectural
styles & patterns here
• In addition to components, we also explicitly support business
• Typically these are best practices for architecting certain
processes
kinds of systems independent of a particular technology
– These are modeled as a state machine
• They provide a reasonable starting point for defining
– Components can trigger the state machine by supplying events to
(aspects of) your systems's architecture
them
– Other components can be triggered by the state machine, resulting in
the invocation of certain operations
– Communication to/from processes is asynchronous, remote
communication is supported
Model-Driven Development – State of the Art
108
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
109
Programming Model
• The programming model uses a simple Dependency Injection
approach à la Spring to define component dependencies on an
interface level
• An external XML file is responsible for configuring the instances
Model-Driven Development – State of the Art
110
Programming Model
• The following piece of code shows the implementation of a simple
example component (note the use of Java 5 annotations)
public @component class ExampleComponent
implements HelloWorld {
// provides HelloWorld
private IConsole console;
public @resource void setConsole( IConsole c ) {
this.console = c;
// setter for console
}
// component
public void sayHello( String s ) {
console.write( s );
}
}
• Processes engines are components like any other
• For triggers, they provide an interface w/ void operations
• They also define interfaces with the actions that those components can
implement that want to be notified of state changes
Model-Driven Development – State of the Art
111
Programming Model
• Process Component Implementation Example
public @process class SomeProcess
implements ISomeProcessTrigger {
private IHelloWorld resource;
public @resource void setResource( IHelloWorld w ) {
this.resource = w;
}
public @trigger void T1( int procID ) {
SomeProcessInstance i = loadProcess( procID );
if ( guardG1() ) {
// advance to another state…
}
}
public @trigger void T2( int procID ) {
SomeProcessInstance i = loadProcess( procID );
// …
resource.sayHello( "hello" );
}
}
Model-Driven Development – State of the Art
112
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
113
Technology Mapping
• For the remote communication between business processes we will use
web services
– From the interfaces such as IHelloWorld, we generate a WSDL
file, & the necessary endpoint implementation We use on of the
many available web service frameworks
• Spring will be used as long as no advanced load balancing &
transaction policies are required
<beans>
<bean id="proc" class="somePackage.SomeProcess">
<property name="resource"><ref bean="hello"/></property>
</bean>
<bean id="hello" class="somePackage.ExampleComponent">
<property name="console"><ref bean="cons"/></property>
</bean>
<bean id="cons" class="someFramework.StdOutConsole">
</beans>
• Once this becomes necessary, we will use Stateless Session EJBs
The necessary code to wrap our components inside beans is easy to
write
Model-Driven Development – State of the Art
114
Technology Mapping
• Persistence for the process
instances – like any other
persistent data – is managed using
Hibernate
Web Services,
a WSDL file is
generated
– To make this possible, we
create a data class for each
process
– Since this is a normal value
object, using Hibernate to make
it persistent is straight forward
Decide about standards
usage here, not earlier
But keep in mind: First solve
the problem, then look for a
standard – Not vice versa
Model-Driven Development – State of the Art
Hibernate
used for database
access
Use technology-specific
design patterns here
Use them as the basis for the
TECHNOLOGY MAPPING
115
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
116
Mock Platform
• Since we are already using a PROGRAMMING MODEL that resembles
Spring, we use the Spring container to run the application components
locally
• Stubbing out parts is easy based on Springs XML configuration file
• Since persistence is something that Hibernate takes care of for us, the
MOCK PLATFORM simply ignores the persistence aspect
Application
“business logic”
code
Model-Driven Development – State of the Art
117
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
118
Vertical Prototype
• The vertical prototype includes parts of the customer & billing systems
– For creating an invoice, the billing system uses normal interfaces to
query the customer subsystem for customer details
– The invoicing process is based on a long-running process
• A scalability test was executed & resulted in two problems:
– For short running processes, the repeated loading & saving of
persistent process state had become a problem
• A caching layer was added
– Second, web-service based communication with process
components was a problem
• Communication was changed to CORBA for remote cases that
were inside the company
Model-Driven Development – State of the Art
119
Vertical Prototype
• The vertical prototype includes parts of the customer & billing systems
– For creating an invoice, the billing system uses normal interfaces to
query the customer subsystem for customer details
– The invoicing process is based on a long-running process
• A scalability test was executed & resulted in two problems:
– For short running processes, the repeated loading & saving of
• Work on performance improvements here, not
persistent process state had become a problem
earlier
• A caching layer was added
• It is bad practice to optimize design for performance
fromweb-service
the beginning,
this oftenwith
destroys
– Second,
basedsince
communication
processgood
architectural
components
was a practice
problem
In certain domains,
there are
patterns
realize
• •Communication
was changed
to CORBA
for to
remote
cases that
certain
properties (such as stateless design for
were
insideQoS
the company
large-scale business systems)
• Don’t ignore these intentionally at the beginning!
Model-Driven Development – State of the Art
120
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
121
Phase 2: Iterate!
• Spring was intended for the production environment
• New requirements (versioning!) have made this infeasible
– Spring does not support two important features
1. Dynamic installation/de-installation of components &
2. isolations of components from each other(classloaders)
• Eclipse has been chosen as the new execution framework
– The PROGRAMMING MODEL did not change
– The TECHNOLOGY MAPPING, however, had to be adapted
Model-Driven Development – State of the Art
122
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
123
Architecture Metamodel
if a component B is a new version
of a component A, then B has to
have the same interfaces,
additional provided interfaces,
fewer required interfaces or new
version of interfaces of A
a new version of an interface has to
have the same return type and the
same parameters - or parameters
with subtypes.
newVersionOf
0..n
1
providedInterface
0..n
0..n
Component
Operation
Interface
1..n
requiredInterface
0..n
0..n
0..n
returnType
1
newVersionOf
Parameter
Container
Components can
provide & require
interfaces
Process
Component
Characteristic
type
0..n
Type
Container
Service
0..n
PrimitiveType
ComplexType
State
Machine
State
1..n
to
0..n
from
0..n
Transition
0..1
Model-Driven Development – State of the Art
124
Trigger
Operation
Architecture Metamodel
if a component B is a new version
of a component A, then B has to
have the same interfaces,
additional provided interfaces,
fewer required interfaces or new
version of interfaces of A
a new version of an interface has to
have the same return type and the
same parameters - or parameters
with subtypes.
newVersionOf
0..n
1
providedInterface
0..n
0..n
Component
Operation
Interface
1..n
requiredInterface
0..n
0..n
0..n
returnType
1
newVersionOf
Parameter
Container
Interfaces have
Characteristic
operations
– they’re
0..n
defined as usual
Process
Component
type
Type
Container
Service
0..n
PrimitiveType
ComplexType
State
Machine
State
1..n
to
0..n
from
0..n
Transition
0..1
Model-Driven Development – State of the Art
125
Trigger
Operation
Architecture Metamodel
if a component B is a new version
of a component A, then B has to
have the same interfaces,
additional provided interfaces,
fewer required interfaces or new
version of interfaces of A
a new version of an interface has to
have the same return type and the
same parameters - or parameters
with subtypes.
newVersionOf
0..n
1
providedInterface
0..n
0..n
Component
Operation
Interface
1..n
requiredInterface
0..n
0..n
0..n
returnType
1
newVersionOf
Parameter
Container
Characteristic
type
0..n
Type
Container
Process
Components
Service
0..n
are special kinds of
components
Process
Component
PrimitiveType
ComplexType
State
Machine
State
1..n
to
0..n
from
0..n
Transition
0..1
Model-Driven Development – State of the Art
126
Trigger
Operation
Architecture Metamodel
if a component B is a new version
of a component A, then B has to
have the same interfaces,
additional provided interfaces,
fewer required interfaces or new
version of interfaces of A
a new version of an interface has to
have the same return type and the
same parameters - or parameters
with subtypes.
newVersionOf
0..n
1
providedInterface
0..n
0..n
Component
Operation
Interface
1..n
requiredInterface
0..n
0..n
0..n
returnType
1
newVersionOf
Parameter
Container
Characteristic
type
0..n
A process component’s
Container
process
is described
Service
0..n
using a state machine
Process
Component
Type
PrimitiveType
ComplexType
State
Machine
State
1..n
to
0..n
from
0..n
Transition
0..1
Model-Driven Development – State of the Art
127
Trigger
Operation
Architecture Metamodel
if a component B is a new version
of a component A, then B has to
have the same interfaces,
additional provided interfaces,
fewer required interfaces or new
version of interfaces of A
a new version of an interface has to
have the same return type and the
same parameters - or parameters
with subtypes.
newVersionOf
0..n
1
providedInterface
0..n
0..n
Component
Operation
Interface
1..n
requiredInterface
0..n
0..n
0..n
returnType
1
newVersionOf
Parameter
Container
Characteristic
type
0..n
Type
Process
Component
Container
Service
0..n
State
Machine
PrimitiveType
& the
triggers are
ComplexType
special kinds of
operations
State
1..n
to
0..n
from
0..n
Transition
0..1
Model-Driven Development – State of the Art
128
Trigger
Operation
Architecture Metamodel
if a component B is a new version
of a component A, then B has to
have the same interfaces,
additional provided interfaces,
fewer required interfaces or new
version of interfaces of A
a new version of an interface has to
have the same return type and the
same parameters - or parameters
with subtypes.
newVersionOf
0..n
1
providedInterface
0..n
0..n
Component
Operation
Interface
1..n
requiredInterface
0..n
0..n
0..n
returnType
1
newVersionOf
Parameter
Container
Characteristic
type
0..n
A container runs
a number
of
Container
Service
components
0..n
Process
Component
Type
PrimitiveType
ComplexType
State
Machine
State
1..n
to
0..n
from
0..n
Transition
0..1
Model-Driven Development – State of the Art
129
Trigger
Operation
Architecture Metamodel
a new version of an interface has to
have the same return type and the
same parameters - or parameters
with subtypes.
newVersionOf
1
0..n
Constraints are
used to define
the semantics of
versioning
newVersionOf
1
providedInterface
0..n
0..n
Component
Operation
Interface
1..n
requiredInterface
0..n
0..n
0..n
returnType
if a component B is a new version
of a component A, then B has to
have the same interfaces,
additional provided interfaces,
fewer required interfaces or new
version of interfaces of A
Parameter
Container
Characteristic
type
0..n
Type
Process
Component
Container
Service
0..n
PrimitiveType
ComplexType
State
Machine
State
1..n
to
0..n
from
0..n
Transition
0..1
Model-Driven Development – State of the Art
130
Trigger
Operation
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
131
Glue Code Generation
• Our scenario has several useful locations for glue code generation
– We generate the Hibernate mapping files
– We generate the web service & CORBA adapters based on the
interfaces & data types that are used for communication The generator
uses reflection to obtain the necessary type information
– Finally, we generate the process interfaces from the state machine
implementations
• In the programming model, we use Java 5 annotations to mark up
those aspects that cannot be derived by using reflection alone
• Annotations can help a code generator to “know what to generate”
without making the programming model overly ugly
Model-Driven Development – State of the Art
132
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
133
DSL–based Programming Model
• We use DSLs for components, interfaces & dependencies
Describing this aspect in a model has two benefits:
– First, the GLUE CODE GENERATION can use a more
semantically rich model as its input &
– The model allows for very powerful MODEL-BASED
ARCHITECTURE VALIDATION (see below)
Model-Driven Development – State of the Art
134
DSL–based Programming Model
IConole
IHelloWorld
<<component>>
HelloWorld
{persistent}
<<component>>
StdOutConsole
• From these diagrams:
– We can generate a skeleton component class
– All the necessary interfaces
• Developers simply inherit from the generated skeleton & implement
the operations defined by the provided interfaces
<<interface>>
<<generate>>
SomeInterface.java
SomeInterface
<<component>>
<<generate>>
<<gen-code>>
Some
Component
Base.java
SomeComponent
Model-Driven Development – State of the Art
<<gen-code>>
135
<<man-code>>
SomeComponent.java
DSL–based Programming Model
Type Model
<<entity>>
<<component>>
person
AddressManager
Person
name: String
firstName: String
0..n
addressStore
<<valuetype>>
<<interface>>
AddressStore
Address
<<component>>
CustomerManager
addOrUpdateContact( p: Person) : void
addAddress( p: Person, a: Address) : void
getAddresses( p: Person ) : Address[]
street: String
zip: String
City: String
Composition Model
System Model
<configurations>
<configuration name="addressStuff">
<deployment name="am" type="AddressManager">
<wire name="personDAO" target="personDAO"/>
</deployment>
<deployment name="personDAO" type="PersonDAO"/>
</configuration>
<configuration name="customerStuff">
<deployment name="cm" type="CustomerManager">
<wire name="addressStore" target=":addressStuff:am"/>
</deployment>
</configuration>
<configuration name="test" includes="addressStuff, customerStuff"/>
</configurations>
<systems>
<system name="production">
<node name="server" type="spring" configuration="addressStuff"/>
<node name="client" type="eclipse" configuration="customerStuff"/>
<system>
<system name="test">
<node name="test" type="spring" configuration="test"/>
<system>
</systems>
Model-Driven Development – State of the Art
Type model defines
components (which are
instantiatable types), interfaces
& data types, as well as the
depdendencies among them
136
DSL–based Programming Model
Type Model
<<entity>>
<<component>>
AddressManager
person
Person
name: String
firstName: String
0..n
addressStore
<<component>>
CustomerManager
Composition Model<<valuetype>>
defines
Address
named configurations
of
addOrUpdateContact( p: Person) component
: void
street: String
instances
& the
addAddress( p: Person, a: Address) : void
zip: String
getAddresses( p: Person ) : Address[]
String
wiring amongCity:
them
<<interface>>
AddressStore
Composition Model
System Model
<configurations>
<configuration name="addressStuff">
<deployment name="am" type="AddressManager">
<wire name="personDAO" target="personDAO"/>
</deployment>
<deployment name="personDAO" type="PersonDAO"/>
</configuration>
<configuration name="customerStuff">
<deployment name="cm" type="CustomerManager">
<wire name="addressStore" target=":addressStuff:am"/>
</deployment>
</configuration>
<configuration name="test" includes="addressStuff, customerStuff"/>
</configurations>
<systems>
<system name="production">
<node name="server" type="spring" configuration="addressStuff"/>
<node name="client" type="eclipse" configuration="customerStuff"/>
<system>
<system name="test">
<node name="test" type="spring" configuration="test"/>
<system>
</systems>
Model-Driven Development – State of the Art
137
DSL–based Programming Model
Type Model
<<entity>>
<<component>>
AddressManager
person
Person
name: String
firstName: String
<<component>>
CustomerManager
System model deploys 0..n
<<valuetype>>
configurations onto systems
address<<interface>>
Store
AddressStore
& nodes Nodes define Address
the
addOrUpdateContact( p: Person) : void
street: String
kind of system they
addAddress( p: Person, a: Address) : void
zip: String
getAddresses( p: Person ) : Address[]
represent City: String
Composition Model
System Model
<configurations>
<configuration name="addressStuff">
<deployment name="am" type="AddressManager">
<wire name="personDAO" target="personDAO"/>
</deployment>
<deployment name="personDAO" type="PersonDAO"/>
</configuration>
<configuration name="customerStuff">
<deployment name="cm" type="CustomerManager">
<wire name="addressStore" target=":addressStuff:am"/>
</deployment>
</configuration>
<configuration name="test" includes="addressStuff, customerStuff"/>
</configurations>
<systems>
<system name="production">
<node name="server" type="spring" configuration="addressStuff"/>
<node name="client" type="eclipse" configuration="customerStuff"/>
<system>
<system name="test">
<node name="test" type="spring" configuration="test"/>
<system>
</systems>
Model-Driven Development – State of the Art
138
DSL–based Programming Model
• Using Cascaded MDD, we generate
– DAO Components for Entities from the Entities in the model
– An interface for the DAO component,
– As well as the implementation code for the DAO & the Entity itself
<<entity>>
<<interface>>
<<transform>>
SomeEntity
<<generate>>
<<gen-code>>
SomeEntityDAO.java
SomeEntityDAO
<<transform>>
<<component>>
<<generate>>
<<gen-code>>
SomeEntityDAOBase
.java
SomeEntityDAO
<<generate>>
<<generate>>
<<gen-code>>
SomeEntity.java
Model-Driven Development – State of the Art
139
<<gen-code>>
SomeEntityDAO.java
DSL–based Programming Model
• We also use cascading for the Process Components
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
*
<<trigger-interface>>
AProcessInterface
<<transform>>
s2
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
<<generate>>
1
<<gen-code>>
First, developers
model the process
component itself
AProcessBase
.java
<<gen-code>>
AProcessProcBase.java
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
Model-Driven Development – State of the Art
AProcessData.java
140
data
DSL–based Programming Model
• We also use cascading for the Process Components
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
*
<<trigger-interface>>
AProcessInterface
<<transform>>
s2
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
<<generate>>
1
<<gen-code>>
They also model a
trigger interface for that
component with no
operations
AProcessBase
.java
<<gen-code>>
AProcessProcBase.java
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
Model-Driven Development – State of the Art
AProcessData.java
141
data
DSL–based Programming Model
• We also use cascading for the Process Components
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
*
<<trigger-interface>>
AProcessInterface
<<transform>>
s2
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
<<gen-code>>
AProcessBase
.java
<<generate>>
Developers then model the state
1
<<gen-code>>
machine for that process data
AProcessProcBase.java
component & associate it with the
guard
operations... component
(abstract)
process
action methods... (abstract)
<<man-code>>
AProcess.java
Model-Driven Development – State of the Art
AProcessData.java
142
DSL–based Programming Model
• We also use cascading for the Process Components
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
*
<<trigger-interface>>
AProcessInterface
<<transform>>
s2
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
<<generate>>
1
<<gen-code>>
AProcessBase
.java
Using M2M, the
operations are derived
from the triggers used in
the state machine
<<gen-code>>
AProcessProcBase.java
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
Model-Driven Development – State of the Art
AProcessData.java
143
data
DSL–based Programming Model
• We also use cascading for the Process Components
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
*
<<trigger-interface>>
AProcessInterface
<<transform>>
s2
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
<<gen-code>>
AProcessBase
.java
Using M2M,
the Entity
AProcess<<generate>>
Data.java
that stores
process
1
instances persistently
is
<<gen-code>>
data
AProcessProcBase.java
derived from the state
machine; then the Entity
guard operations... (abstract)
action methods... (abstract)
transformations kick in –
see before
<<man-code>>
AProcess.java
Model-Driven Development – State of the Art
144
DSL–based Programming Model
• We also use cascading for the Process Components
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
*
<<trigger-interface>>
AProcessInterface
<<transform>>
s2
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
<<generate>>
1
<<gen-code>>
AProcessBase
.java
As usual, from components
we generate skeleton
base classes
<<gen-code>>
AProcessProcBase.java
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
Model-Driven Development – State of the Art
AProcessData.java
145
data
DSL–based Programming Model
• We also use cascading for the Process Components
sm AProcess
AProcess
1
s1
Instead of letting developers
implement the business logic
manually, we generate an
*
s3
“Intermediate” class that contains
<<trigger-interface>>
the executable, & persistenceAProcessInterface
aware state machine
<<transform>>
<<proc-component>>
<<transform>>
s2
operations...
<<gen-code>>
<<generate>>
AProcessData.java
1
<<gen-code>>
<<gen-code>>
AProcessProcBase.java
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
Model-Driven Development – State of the Art
attributes...
<<generate>>
<<generate>>
AProcessBase
.java
<<entity>>
AProcessData
146
data
DSL–based Programming Model
• We also use cascading for the Process Components
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
<<transform>>
s2
Finally,
developers extend
*
s3
that intermediate class &
<<trigger-interface>>
implement guard & action
AProcessInterface
operations manually by
operations...
<<generate>>
overriding abstract methods
<<gen-code>>
<<generate>>
AProcessData.java
1
<<gen-code>>
AProcessProcBase.java
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
Model-Driven Development – State of the Art
attributes...
<<generate>>
<<gen-code>>
AProcessBase
.java
<<entity>>
AProcessData
147
data
Architectural Case Study
• PHASE 1: Elaborate!
–
–
–
–
–
Technology-Independent Architecture
Programming Model
Technology Mapping
Mock Platform
Vertical Prototype
• PHASE 2: Iterate!
• PHASE 3: Automate!
–
–
–
–
Architecture Metamodel
Glue Code Generation
DSL-based Programming Model
Model-based Architecture Validation
• Summary
Model-Driven Development – State of the Art
148
Model–Based Architecture Validation
• We can use automated model checking to verify that
– For triggers in processes there is a component that calls the trigger
– Dependency management: It is easy to detect circular
dependencies among components
– Components are assigned to layers (app, service, base) &
dependencies are only allowed in certain directions
• The component signature generated from the model prevents
developers from creating dependencies to components that are not
described in the model
Model-Driven Development – State of the Art
149
Model–Based Architecture Validation
• Another really important aspect in our example system is evolution of
interfaces:
<<component>>
SomeCompV1
<<interface>>
SomeInterface
soSomething(int, ValueObject)
<<newVersionOf>>
<<vo>>
ValueObject
<<interface>>
AnotherInterface
<<component>>
SomeCompV2
<<newVersionOf>>
<<newVersionOf>>
<<newVersionOf>>
<<component>>
SomeCompV3
<<interface>>
SomeInterfaceV3
soSomething(int, ValueObjectV2)
anAdditionalOperation()
Model-Driven Development – State of the Art
150
<<vo>>
ValueObjectV3
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools:
GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
151
CONTENTS
Generic Modeling Environment (GME)
“Write Code That Writes Code That Writes Code!”
GME Architecture
Application
Developers
(Modelers)
Decorator
Decorator
COM GME Editor COM
Constraint
Browser
Manager
Add-On(s)
Translator(s)
COM
GModel
XML
GMeta
XML
MDD Tool
Developers
(Metamodelers)
CORE
XML
DB #1
Metamodel
UML / OCL
Paradigm Definition
ODBC
… XML … DB #n
Storage Options
Supports “correct-by-construction” of software systems
GME
is open-source:
www.isis.vanderbilt.edu/Projects/gme/default.htm
Model-Driven
Development
– State of the
Art
152
MDD Application Development with GME
•Application
developers use
modeling environments
created w/MetaGME to
build applications
–Capture elements &
dependencies
visually
Example DSL is the
“Platform-Independent
Component Modeling
Language” (PICML) tool
Model-Driven Development – State of the Art
153
MDD Application Development with GME
•Application
developers use
modeling environments
created w/MetaGME to
build applications
–Capture elements &
dependencies
visually
–Model interpreter
produces something
useful from the
models
<connection>
<name>compressionQosPredictor_qosLevels</name>
<internalEndpoint>
<portName>qosLevels</portName>
<instance xmi:idref="CompressionQosPredictor_F3C2CBE0-B2CE-46CC-B446F64D91B44E56"/>
</internalEndpoint>
<internalEndpoint>
<portName>compressionQosPredictor</portName>
<instance xmi:idref="LocalResourceManagerComponent_7EF8B77A-F5EA4D1A-942E-13AE7CFED30A"/>
</internalEndpoint>
</connection>
<connection>
<name>scalingQosPredictor_qosLevels</name>
<internalEndpoint>
<portName>qosLevels</portName>
<instance xmi:idref="ScaleQosPredictor_F3024A4F-F6E8-4B9A-BD56A2E802C33E32"/>
</internalEndpoint>
<internalEndpoint>
<portName>scalingQosPredictor</portName>
<instance xmi:idref="LocalResourceManagerComponent_7EF8B77A-F5EA4D1A-942E-13AE7CFED30A"/>
</internalEndpoint>
</connection>
•e.g., 3rd generation
code, simulations,
deployment
descriptions &
PICML generates XML descriptors
configurations
corresponding to OMG Deployment &
Model-Driven Development – State ofConfiguration
the Art
154
(D&C) specification
MDD Tool Development in GME
•Tool developers use
MetaGME to develop a
domain-specific
graphical modeling
environment
–Define syntax &
visualization of the
environment via
metamodeling
Model-Driven Development – State of the Art
155
MDD Tool Development in GME
•Tool developers use
MetaGME to develop a
domain-specific
graphical modeling
environment
–Define syntax &
visualization of the
environment via
metamodeling
–Define static
semantics via Object
Constraint Language
(OCL)
Model-Driven Development – State of the Art
156
MDD Tool Development in GME
•Tool developers use
MetaGME to develop a
domain-specific
graphical modeling
environment
–Define syntax &
visualization of the
environment via
metamodeling
–Define static
semantics via Object
Constraint Language
(OCL)
–Dynamic semantics
implemented via
model interpreters
Model-Driven Development – State of the Art
157
Applying GME to System Execution Modeling
System Execution Modeling Workflow
1. Compose scenarios to
exercise critical system
Model
paths/layers
Experiment
Experimenter
2. Associate performance
properties with scenarios &
assign properties to
components specific to
paths/layers
3. Configure workload generators
to run experiments, generate
path-/layer-specific
deployment plans, & measure
performance along critical
paths/layers
4. Feedback results into models
to verify if deployment plan &
configurations meet
performance
requirements
Model-Driven
Development
– State of the Art
Associate
QoS
Characteristics
1
2
Component Interaction
CoWorkEr
4
3
IDL
Feedback
Test bed
158
Synthesize
&
Execute
Script
files
Deployment
.cpp
Plan
Context: Service–Oriented Architectures
• Historically, distributed real-time &
embedded (DRE) systems were built
directly atop OS & protocols
Applications
Operating System &
Communication Protocols
Hardware Devices
Model-Driven Development – State of the Art
159
Context: Service–Oriented Architectures
Applications
Domain-Specific Services
Common Services
Service-Oriented
Architecture Middleware
Distribution Middleware
• Historically, distributed real-time &
embedded (DRE) systems were built
directly atop OS & protocols
• Traditional methods of development have
been replaced by middleware layers to
reuse architectures & code for enterprise
DRE systems
• Viewed externally as Service-Oriented
Architecture (SOA) Middleware
Infrastructure Middleware
Operating System &
Communication Protocols
Hardware Devices
Model-Driven
– State
the Art
Note: our Development
techniques
alsoofapply
160
to conventional
enterprise distributed systems
Context: Service–Oriented Architectures
Applications
Domain-Specific Services
Common Services
Multi-layer Resource
Manager (MLRM)
Distribution Middleware
Infrastructure Middleware
Operating System &
Communication Protocols
Hardware Devices
• Historically, distributed real-time &
embedded (DRE) systems were built
directly atop OS & protocols
• Traditional methods of development have
been replaced by middleware layers to
reuse architectures & code for enterprise
DRE systems
• Viewed externally as Service-Oriented
Architecture (SOA) Middleware
• e.g., DARPA Adaptive & Reflective
Management System (ARMS) program’s
Multi-layer Resource Manager (MLRM)
• MLRM leverages standards-based
SOA middleware to manage resources
for shipboard computing environments
Model-Driven Development
– State of the Art
161
dtsn.darpa.mil/ixodarpatech/ixo_FeatureDetail.asp?id=6
ARMS Multi–Layer Resource Manager (MLRM)
• ARMS MLRM architecture
includes
Applications
Domain-Specific Services
– Top domain layer
containing components
that interact with the ship
mission manager
– Middle resource pool
layer is an abstraction for
a set of computer nodes
managed by a pool
manager
– Bottom resource layer
managers the actual
resource computing
components, i.e., CPUs,
memory, networks, etc.
Model-Driven Development
– State of the Art
162
www.cs.wustl.edu/~schmidt/PDF/JSS-2006.pdf
Serialized Phasing is Common in Enterprise DRE Systems
System
infrastructure
components
developed first
Level of Abstraction
Application components
developed after infrastructure
is sufficiently mature
Development Timeline
Model-Driven Development – State of the Art
163
Serialized Phasing is Common in Enterprise DRE Systems
Level of Abstraction
System integration &
testing occurs only after
finishing application
development
Integration
Surprises!!!
Development Timeline
Model-Driven Development – State of the Art
164
Complexities of Serialized Phasing
Level of Abstraction
Still in development
Ready for testing
Complexities
• System infrastructure cannot be
tested adequately until applications
are done
Development Timeline
Model-Driven Development – State of the Art
165
Complexities of Serialized Phasing
Level of Abstraction
End-to-end
performance of
critical path?
System bottleneck?
Complexities
• System infrastructure cannot be
tested adequately until applications
are done
• Entire system must be deployed &
configured (D&C) properly to meet
QoS requirements
• Existing evaluation tools do not
support “what if” evaluation
Development Timeline
Model-Driven
Development
– State ofof
thecomponents
Art
166aren’t
Often, QoS
requirements
known until late in the lifecycle
Unresolved QoS Concerns with Serialized Phasing
Level of Abstraction
Meet QoS
requirements?
Key QoS concerns
• Which D&C’s meet the QoS
requirements?
Development Timeline
Model-Driven Development – State of the Art
167
Unresolved QoS Concerns with Serialized Phasing
Level of Abstraction
Performance
metrics?
Key QoS concerns
• Which D&C’s meet the QoS
requirements?
• What is the worse/average/best
time for various workloads?
Development Timeline
Model-Driven Development – State of the Art
168
Unresolved QoS Concerns with Serialized Phasing
Level of Abstraction
System
overload?
Key QoS concerns
• Which D&C’s meet the QoS
requirements?
• What is the worse/average/best
time for various workloads?
• How much workload can the system
handle until its end-to-end QoS
requirements are compromised?
Development Timeline
Model-Driven
Development
– Stateto
of the
Art
It can take
a long time
address
169concerns using serialized phasing!!
these
Promising Solution Approach: New Generation of
System Execution Modeling (SEM) Tools
Tools to validate design rules
• Help applications adhere to system
specifications at design-time
• “Correct-by-construction”
Ensure
Design
Conformance
Tools to ensure design conformance
• Help properly deploy & configure
applications to enforce system design
rules at run-time
Tools to conduct “what if” analysis
• Help analyze QoS concerns prior to
completing the entire system
Validate
Design
Rules
Conduct
“What If”
Analysis
• e.g., before system integration
phase
Model-Driven
– State
of the
Art
The
cycle Development
is repeated
when
developing
application & infrastructure components
170
Our Approach: Emulate Application Behavior via
QoS-enabled SOA Middleware & MDD Tools
Component Workload Emulator (CoWorker)
Utilization Test Suite Workflow (CUTS):
While creating target infrastructure
1. Use the PICML domain-specific
language (DSL) to define & validate
infrastructure specifications &
requirements
Validate
2. Use PICML & WML DSLs to emulate
Design
& validate application specifications &
Rules
requirements
3. Use CIAO & DAnCE middleware &
PICML DSL to generate D&C
metadata to ensure apps conform to
system specifications & requirements
4. Use BMW analysis tools to evaluate
& verify QoS performance
5. Redefine system D&C & repeat
Enable “application”
testing
Model-Driven
Development – State
of the to
Art evaluate
171target
Ensure
Design
Conformance
Conduct
“What If”
Analysis
infrastructure earlier in lifecycle
Motivation for Using Emulation
• Can use actual target infrastructure
• Rather than less precise
simulations that abstract out key
QoS properties
• Many artifacts can be used directly
in the final production system
• e.g., models of application
component relationships & D&C
plans
• Early feedback to developers,
architects & systems engineers
• Instead of waiting to complete
application components before
conducting performance
experiments
Model-Driven Development – State of the Art
172
Our SOA Middleware & MDD Tool Infrastructure
• System Design & Specification Tools
PICML & CIAO & DAnCE
• Define & validate system
specification & requirements
• System Assembly & Packaging Tools
• Compose implementation &
configuration information into
deployable assemblies
Ensure
Design
Conformance
Validate
Design
Rules
• System Deployment Tools
• Automates the deployment of system
components & assemblies to
component servers
Conduct
“What If”
Analysis
• Component Implementation
Framework
• Automates the implementation of
many system component features
Model-Driven
Development – State of the Art
www.dre.vanderbilt.edu/CIAO
CUTS & BMW
173
&
www.dre.vanderbilt.edu/cosmic
ARMS MLRM Case Study: SLICE Scenario (1/2)
sensor 1
(main)
error recovery
planner 1
sensor 2
planner 2
effector 1
(main)
configuration effector 2 (backup)
Component Interaction for SLICE Scenario
• Three hosts
• One database is shared between
all hosts (used largely offline)
D&C & Performance Requirements &
Constraints
• Critical path deadline is 350 ms
• Main sensor to main effector
through configuration
• To ensure availability, components in
critical paths should not be collocated
• Main sensor & main effector must be
deployed on separate hosts
Model-Driven Development – State of the Art
Example174
design
rules
ARMS MLRM Case Study: SLICE Scenario (2/2)
350ms deadline
sensor 1
(main)
planner 1
error recovery
effector 1
(main)
configuration
effector 2
planner 2
sensor 2
Some questions we’d like to answer
1. Can a particular D&C meet end-toend performance requirements?
Model-Driven Development – State of the Art
175
ARMS MLRM Case Study: SLICE Scenario (2/2)
sensor 1
(main)
planner 1
error recovery
effector 1
(main)
configuration
effector 2
planner 2
sensor 2
Some questions we’d like to answer
1. Can a particular D&C meet end-toend performance requirements?
2. Are there multiple deployments that
meet the 350ms critical path
deadline?
• e.g., which yields most headroom?
Model-Driven Development – State of the Art
176
ARMS MLRM Case Study: SLICE Scenario (2/2)
sensor 1
(main)
planner 1
error recovery
effector 1
(main)
configuration
effector 2
planner 2
sensor 2
Some questions we’d like to answer
1. Can a particular D&C meet end-toend performance requirements?
2. Are there multiple deployments that
meet the 350ms critical path
deadline?
• e.g., which yields most headroom?
3. Can we meet the 350ms critical path
deadline with all component deployed
on a single host?
Model-Driven Development – State of the Art
177
Representing SLICE Scenario in PICML
Conceptual model
error recovery
sensor 1
(main)
planner 1
sensor 2
effector 1
(main)
planner 2
configuration
effector 2
• Conceptual models
can be helpful at
certain design phases
• But they are also
imprecise & nonautomated
• PICML model
provides detailed
representation of
component properties
& interconnections
• They are also precise
& automated
PICML Model of SLICE Scenario
Model-Driven Development – State of the Art
178
Summary of CUTS Challenges
Emulate component behavior
Average- & worstcast latency & jitter
PICML Model of SLICE Scenario
Model-Driven Development – State of the Art
179
1. Evaluate QoS
characteristics of DRE
systems
2. Emulate QoS
characteristics of DRE
systems
Summary of CUTS Challenges
Single-point of
data collection
Define behavior
declaratively
PICML Model of SLICE Scenario
Model-Driven Development – State of the Art
180
1. Evaluate QoS
characteristics of DRE
systems
2. Emulate QoS
characteristics of DRE
systems
3. Non-intrusive
benchmarking &
evaluation
4. Simplifying component
behavior specification
Summary of CUTS Challenges
1. Evaluate QoS
characteristics of DRE
systems
2. Emulate QoS
characteristics of DRE
systems
3. Non-intrusive
benchmarking &
evaluation
4. Simplifying component
behavior specification
5. Simplify component
customization
Customizing generic
components?
PICML Model of SLICE Scenario
Model-Driven Development – State of the Art
181
Summary of CUTS Challenges
1. Evaluate QoS
characteristics of DRE
systems
2. Emulate QoS
characteristics of DRE
systems
3. Non-intrusive
benchmarking &
evaluation
4. Simplifying component
behavior specification
5. Simplify component
customization
6. Informative analysis of
performance
Time-critical end-to-end path
through operational string
PICML Model of SLICE Scenario
Model-Driven Development – State of the Art
182
Challenge 1: Evaluating QoS Characteristics of
Enterprise DRE Systems Early in Life-cycle
Level of
Abstraction
Context
• In phase 1 of ARMS, QoS
evaluation was not done until
application integration
–Prolonged project
development & QA
• In phase 2 of ARMS, MLRM is
implemented using Real-time
CCM (via CIAO & DAnCE)
• Software components &
challenges are similar in both
phases
Development Timeline
Model-Driven Development – State of the Art
183
Challenge 1: Evaluating QoS Characteristics of
Enterprise DRE Systems Early in Life-cycle
Level of
Abstraction
Context
• In phase 1 of ARMS, QoS
evaluation was not done until
application integration
–Prolonged project
development & QA
• In phase 2 of ARMS, MLRM is
implemented using Real-time
CCM (via CIAO & DAnCE)
• Software components &
challenges are similar in both
phases
Problem
• How to evaluate MLRM QoS
earlier in lifecycle?
–i.e., prior to integration
Development Timeline
Model-Driven Development – State of the Art
184
Solution: Evaluate Component QoS & Behavior
using Component–based Emulators
• System components are
represented as
Component Workload
Emulators (CoWorkErs)
CoWorkEr
• Each CoWorkEr is a CCM
assembly component
constructed from CCM
monolithic components
• Each CoWorkEr has an
optional database
–Can be local or remote
• CoWorkErs can be
interconnected to form
operational strings
–Basically a “work flow”
abstraction
Model-Driven Development – State of the Art
185
Challenge 2: Emulating Behavior & QoS of
Enterprise DRE Systems
Current
Test A
(ad
hoc)
Context
Test A
(ad
hoc)
Phase 1
Phase 2
Desired
• In phase 1 of ARMS, QoS evaluation
was not done until integration
• QoS testing was done using ad hoc
techniques
–e.g., creating non-reusable artifacts
& tests that do not fully exercise the
infrastructure
Problem
Test A
Phase 2
Test A
Phase N
Model-Driven Development – State of the Art
• How to emulate behavior & QoS in a
reusable manner to evaluate the
complete infrastructure & apply tests in
different contexts
186
Solution: Emulate Component Behavior & QoS
Using Configurable CoWorkErs
Emulate workloads, e.g.,
CPU, database & memory
Model-Driven Development – State of the Art
187
Solution: Emulate Component Behavior & QoS
Using Configurable CoWorkErs
Perform background
workloads
Model-Driven Development – State of the Art
188
Solution: Emulate Component Behavior & QoS
Using Configurable CoWorkErs
Receive events from CoWorkErs
Model-Driven Development – State of the Art
189
Solution: Emulate Component Behavior & QoS
Using Configurable CoWorkErs
Send events to CoWorkErs
Model-Driven Development – State of the Art
190
Challenge 3: Non-Intrusive Benchmarking & Evaluation
Context
• The SLICE scenario of MLRM is
composed of multiple
components deployed over
multiple nodes
• Each component, including
components in assemblies, must
be monitored & evaluated
Model-Driven Development – State of the Art
191
Challenge 3: Non-Intrusive Benchmarking & Evaluation
Context
Collects all the metrics for experiment
• The SLICE scenario of MLRM is
composed of multiple
components deployed over
multiple nodes
• Each component, including
components in assemblies, must
be monitored & evaluated
Problem
• Collecting data from each
component without interfering
with emulation
• Collecting data without unduly
perturbing operational
performance measures
Model-Driven Development – State of the Art
192
Solution: Decouple Emulation & Benchmarking
• CUTS environment is decoupled
into two sections
– Emulation & benchmarking
Emulation
Benchmarking
Model-Driven Development – State of the Art
193
Solution: Decouple Emulation & Benchmarking
• CUTS environment is decoupled
into two sections
– Emulation & benchmarking
• Data acquisition done in two
phases at lower priority than
emulation
1.BenchmarkAgent collects
performance metrics
2.BenchmarkAgent submits
data to
BenchmarkDataCollector at
user-defined intervals
Each CoWorkEr has
a BenchmarkAgent
Model-Driven Development – State of the Art
194
Solution: Decouple Emulation & Benchmarking
• CUTS environment is decoupled
into two sections
– Emulation & benchmarking
• Data acquisition done in two
phases at lower priority than
emulation
1.BenchmarkAgent collects
performance metrics
2.BenchmarkAgent submits
data to
BenchmarkDataCollector at
user-defined intervals
• BenchmarkDataCollector stores
performance metrics in database
for offline analysis
• Separate networks are used for
CoWorkEr communication &
data acquisition
Model-Driven Development – State of the Art
195
Challenge 4: Simplify Characterization of Workload
Context
• People developing & using the SLICE
scenario with CUTS come from
different disciplines
–e.g., software architects, software
developers, & systems engineers
use?
• Many CUTS users may not be familiar
with 3rd generation or configuration
languages
–e.g., C++ & Java or XML,
respectively
Problem
• Avoiding tedious & error-prone
manual programming of CoWorkEr
behavior using 3rd generation
languages or configuration files
Model-Driven
Development
– State of theCoWorkErs,
Art
196the
The harder
it is to program
less useful CUTS emulation is…
Solution: Use Domain–Specific Modeling Language
to Program CoWorkEr Behavior
• Workload Modeling Language (WML)
is used to define the behavior of
CoWorkEr components
Model-Driven Development – State of the Art
197
Solution: Use Domain–Specific Modeling Language
to Program CoWorkEr Behavior
• Workload Modeling Language (WML)
is used to define the behavior of
CoWorkEr components
Startup workload
• WML events represent different types
of workloads in CoWorkEr
Event-driven workload
Model-Driven Development – State of the Art
198
Solution: Use Domain–Specific Modeling Language
to Program CoWorkEr Behavior
• Workload Modeling Language (WML)
is used to define the behavior of
CoWorkEr components
• WML events represent different types
of workloads in CoWorkEr
• Actions can be attached to events &
specified in order of execution to
define “work sequences”
–Each action has attributes, e.g.,
number of repetitions, amount of
memory to allocate & etc
Attributes for CPUAction
Model-Driven Development – State of the Art
199
Workload string
Solution: Use Domain–Specific Modeling Language
to Program CoWorkEr Behavior
• Workload Modeling Language (WML)
is used to define the behavior of
CoWorkEr components
• WML events represent different types
of workloads in CoWorkEr
• Actions can be attached to events &
specified in order of execution to
define “work sequences”
–Each action has attributes, e.g.,
number of repetitions, amount of
memory to allocate & etc
• WML programs are translated into
XML characterization files
• Characterization specified in
CoWorkEr & used to configure its
behavior
Model-Driven Development – State of the Art
200
Challenge 5: Simplify Component Customization
Context
?
• By default a CoWorkEr can send &
receive every type of event
• The SLICE components are all
different, however, & do not
send/receive the same types of
events
–i.e., each contains a different
composition pertaining to its
specific workload(s)
Problem
• How can we customize CoWorkEr
components to enforce strong typechecking without requiring timeconsuming modification &
recompilation of components?
compilation
Model-Driven Development – State of the Art
201
Solution: Customize CoWorkErs at System Modeling Level
• Event sinks of a CoWorkEr
are delegated to the
respective event sources of
the EventHandler
• Events produced by the
EventProducer are delegated
to respective events sources
for a CoWorkEr
• Delegated event sources &
sinks can be removed from
CoWorkEr
Custom CoWorkEr
–Does not require
recompilation of
components
Event sources removed
Event sinks removed
Model-Driven
Development
– State of the
Artproperties
203of
This technique
leverages
key
CCM assemblies, i.e., virtual APIs
Challenge 6: Informative Analysis of QoS Performance
Too much workload?
Context
• There are many components in
SLICE & combinations in the
deployment of these components
Problem
• How can we assist users in
pinpointing problematic areas in
– Deployment & configuration
(D&C)?
Too many components
deployed on a node?
Model-Driven Development – State of the Art
204
Challenge 6: Informative Analysis of QoS Performance
Missed deadline
Model-Driven Development – State of the Art
Context
• There are many components in
SLICE & combinations in the
deployment of these components
Problem
• How can we assist users in
pinpointing problematic areas in
– Deployment & configuration
(D&C)?
– End-to-end QoS of missioncritical paths?
205
Solution: Present Metrics Graphically in Layers to
Support General & Detailed Information
• BenchmarkManagerWeb-interface
(BMW) analyzes & graphically
displays performance metrics
reads metrics
displays
BMW
Web service
Model-Driven Development – State of the Art
206
Solution: Present Metrics Graphically in Layers to
Support General & Detailed Information
• BenchmarkManagerWeb-interface
(BMW) analyzes & graphically
displays performance metrics
• General analysis shows users
overall performance of each
CoWorkEr
–e.g., transmisssion delay &
processing
General analysis of actions
BMW General Time Data
Host
CoWorkEr
Model-Driven Development – State of the Art
207
Solution: Present Metrics Graphically in Layers to
Support General & Detailed Information
• BenchmarkManagerWeb-interface
(BMW) analyzes & graphically
displays performance metrics
• General analysis shows users
overall performance of each
CoWorkEr
–e.g., transmisssion delay &
processing
• Detailed analysis shows users the
performance of an action in the
respective CoWorkEr
–e.g., memory & CPU actions,
event handling & etc
Model-Driven Development – State of the Art
208
Solution: Present Metrics Graphically in Layers to
Support General & Detailed Information
• BenchmarkManagerWeb-interface
(BMW) analyzes & graphically
displays performance metrics
• General analysis shows users
overall performance of each
CoWorkEr
–e.g., transmisssion delay &
processing
• Detailed analysis shows users the
performance of an action in the
respective CoWorkEr
–e.g., memory & CPU actions,
event handling & etc
• Critical paths show users end-toend performance of mission-critical
operational strings
Model-Driven Development – State of the Art
Green means end-to-end
deadline met
209
Applying CUTS to the SLICE Scenario
Using ISISLab as our target infrastructure in conjunction with CUTS
1.Use PICML to define & validate
infrastructure specifications &
requirements
Ensure
Design
Conformance
2.Use WML to define & validate
application specifications &
requirements
Validate
Design
Rules
3.Use DAnCE to deploy component
emulators on target infrastructure
Conduct
“What If”
Analysis
4.Use BMW to evaluate & verify QoS
performance
5.Redefine system D&C & repeat
www.dre.vanderbilt.edu/ISISlab/
Model-Driven Development – State of the Art
210
Defining Components of SLICE Scenario in PICML for CUTS
• Each component in
SLICE is defined as a
CoWorkEr
CoWorkEr
• The default CoWorkEr is
customized to handle
events specific to its
representative SLICE
component
• Each CoWorkEr is
assigned a unique userdefined ID number
• The benchmark data
submission rate is set to
15 seconds
Model-Driven Development – State of the Art
211
Customized
CoWorkEr
Defining Behavior of SLICE Scenario Components using WML
Effector 1 & Effector 2
Workload
performed every
second
CPU: 25 reps
PUBLISH: STATUS – SIZE 32
Workload
performed after
receipt of
command event
CPU: 25 reps
PUBLISH: STATUS - SIZE 256
Model-Driven Development – State of the Art
212
Recap of Questions We Wanted to Answer
1. Can we meet the D&C & performance
requirements?
2. Are there multiple deployments that meet
the 350ms critical path deadline?
• e.g., which yields most headroom?
3. Can we meet D&C & performance
requirements using a single host?
To answer these questions we ran 11 tests using different CoWorkEr D&C’s
Model-Driven Development – State of the Art
213
SLICE Scenario Results: Meeting D&C & QoS Requirements
Deployment Table
Test
9
Node 1
Node 2
Node 3
sensor 1 & planner 1 planner 2, configuration,
& effector 1
sensor 2, error recovery &
effector 2
Planner 2 takes the longest to
process workload
Critical Path Timing Information for Test 9
“What if” planner-2 is put on Node 3, which has no critical path components?
Model-Driven Development – State of the Art
214
SLICE Scenario Results: Meeting D&C & QoS Requirements
Deployment Table
Test
10
Node 1
Node 2
sensor 1 & planner 1 configuration & effector 1
Planner 2 takes the longest to
process workload
Node 3
planner 2, sensor 2, error
recovery & effector 2
Better performance
Critical path timing information for Test 10
Node 3 is “saturated” with non-critical path components, “what if” we
evenly distribute critical path workload on collocated components?
Model-Driven Development – State of the Art
215
SLICE Scenario Results: Meeting D&C & QoS Requirements
Deployment Table
Test
11
Node 1
sensor 1, planner 1
& configuration
Node 2
planner 2 & effector 1
Node 3
sensor 2, error recovery &
effector 2
Worst case passed
Critical path timing information for Test 11
We were able to answer the critical path & deployment questions
Model-Driven Development – State of the Art
216
SLICE Scenario Results: Meeting D&C & QoS Requirements
Deployment Table
Test
Node 1
Node 2
Node 3
9
sensor 1 & planner 1 planner 2, configuration,
& effector 1
Sensor 2, error re
recovery & effector 2
10
sensor 1 & planner 1 configuration & effector
1
planner 2, sensor 2, error
recovery & effector 2
11
sensor 1, planner 1
& configuration
sensor 2, error recovery &
effector 2
planner 2 & effector 1
• Test 11 meet the performance
requirements for worst execution
time
Deployment of Critical Path on Multiple Nodes
Completion
Time of Critical
Path (ms)
• Test 9, 10 & 11 meet the
performance requirements for the
average execution time of the
critical path
350
0
9
• We did not exhaustively test all
D&C’s, but that could be done also
Model-Driven Development – State of the Art
700
10
Test
Avg. Time
217
Worse Time
11
SLICE Scenario Results: Single Host Deployment
Deployment Table
Test
4
Node 1
Node 2
All components
Node 3
(nothing)
(nothing)
Deployment of Critical Path on Single Node
Critical Path
Completion
Time (ms)
Avg. Time
Worse Time
Test 4 had a average
time of 490 ms
1400
1050
700
350
0
4
Test Number
We were able to answer the question about deploying on a single node
Model-Driven Development – State of the Art
218
Overall Results of SLICE Scenario
Test 11 produced the best results
• Average case: 221 ms
• Worse case: 343 ms
Population size of 11 tests
Results of SLICE Scenario
Critical Path
Completion Time (ms)
• Only 4 of 11
deployments met
the 350 ms critical
path deadline for
average-case time
• Test 11 only test to
meet critical path
deadline for worstcase time
1400
1050
700
350
0
Model-Driven Development – State of the Art
1
2
3
4
5
6
7
Test Number
Avg. Time
219
Worse Time
8
9
10
11
Lessons Learned
• SOA middleware technologies
allowed us to leverage the behavior
& functionality of target architecture
for realistic emulations
• SOA technologies allowed us to
focus on the “business” logic of
CoWorkErs
–e.g., D&C handled by underlying
MDD & middleware technology
Model-Driven Development – State of the Art
220
Lessons Learned
Model-Driven Development – State of the Art
increased # of tests
Level of Abstraction
• SOA middleware technologies
allowed us to leverage the behavior
& functionality of target architecture
for realistic emulations
• SOA technologies allowed us to
focus on the “business” logic of
CoWorkErs
–e.g., D&C handled by underlying
MDD & middleware technology
• CUTS allowed us to test
deployments before full system
integration testing
• CUTS allowed us to rapidly test
deployments that would have take
much longer using ad hoc
techniques
–e.g., hand-coding the D&C of
components
Development Timeline
221
Summary
• We motivated the need for the
Component Workload Emulator
(CoWorkEr) Utilization Test Suite
(CUTS)
• We presented a large-scale DRE
system example that used CUTS to
evaluate component D&C before
complete integration
• We presented the design &
implementation of CUTS, along with
the design challenges we faced
• CUTS is being integrated into the
open-source CoSMIC MDD
toolchain
– www.dre.vanderbilt.edu/cosmic
www.cs.wustl.edu/~schmidt/PDF/CUTS.pdf
Model-Driven Development
– State of the Art
www.cs.wustl.edu/~schmidt/PDF/QoSPML-WML.pdf
222
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
223
CONTENTS
Modeling Frontends
• Frontends (parsers) are pluggable
• A large number of UML modeling tools
(Rose, MagicDraw, Enterprise Architect, Innovator,
Poseidon, XDE, …)
• MS Visio integration
• Simple parsing of XML files
• Integration with parser generators
(such as antlr, JavaCC)
• GEMS integration V4
(UVanderbilt/ISIS‘s Generic Eclipse Modeling System)
Model-Driven Development – State of the Art
224
Industry Standard Support
• Natively provides a Java-based Metametamodel
– with a UML-based metaclass generator that can optionally create
Hibernate-persistent metaclasses;
– constraints implemented in Java based on a nice library
• Can work with EMF-based models & metamodels
– provides workflow adapters for EMF-based transformation
tools (such as ATL) or editors (such as GMF)
• Can use Netbeans MDR as a metadata repository
Model-Driven Development – State of the Art
225
V4
Workflow Control
• ant-based plugin
framework
• Workflow Engine
<?xml version="10" encoding="windows-1252"?>
<workflow>
<property file="workflowproperties"/>
V4
– controls when which
processing step is executed
– parameterizable through
property files
• Cartridges
V4
modularized processing steps
(“macros”) including resources
such as temlplates, transformations, metaclasses
Model-Driven Development – State of the Art
<component id="xmiParser"
class="orgopemfXmiReader">
<modelFile value="${modelFile}"/>
<metaModelPackage value="dataDataPackage"/>
<outputSlot value="model"/>
</component>
<component id="dirCleaner"
class="orgopemmonDirectoryCleaner">
<directories value="${srcGenPath}"/>
</component>
<component id="generator"
class="orgoped2Generator">
<metaModel
class="orgopenarchiemfEmfMetaModel">
<metaModelPackage value="dataDataPackage"/>
</metaModel>
<expression value="modelget(0)"/>
<startDefine value="templates::Root::Root"/>
<outputStrategy
class="orgopenaroutputBeautifyingOutput">
<genPath value="${srcGenPath}/"/>
<srcPath value="${srcGenPath}/"/>
</outputStrategy>
</component>
</workflow>
226
V4
Cartridges
V4
• A cartridge is a self-sustained “piece of tool”
i.e., it comes with templates, transformations, workflow snippets,
metaclasses
• Real, Deep modularization
a cartridge can extend other cartridges by
– extending metaclasses
– overriding templates
– advising templates (before, after, around)
– providing new methods for existing metaclasses
Model-Driven Development – State of the Art
227
Code Generation
• powerful & elegant template language (XPand)
–
–
–
–
template modularization
template polymorphism
template overriding
AOP support for template
programming
– powerful expression
V4
language (OCL-Like)
• Advanced Eclipse Editor
(syntax coloring, find-references, code completion, static
error checks)
Model-Driven Development – State of the Art
228
Recipe Framework
• Checks manually written code for compliance with a
defined programming model
– Based on the
model, checks
are instantiated
– The IDE (Eclipse)
verifies the
checks &
provides quick
fixes
Model-Driven Development – State of the Art
229
Model–to–Model Transformation
• model transformation as well as modelenrichment/completion
• Java code can be used for transformations
very rich APIs & libraries are provided to make this easy
V4
• WOMBAT:
Textual, functional language
powerful collections support, same
expression language as in XPand
CREATE (#Book: {
title <- „XYZ",
numPages <- 1354
}
);
Can operate on all supported metametamodels
(EMF, MDR, oAW classic) & transform between them
• Integration with Industry-Standard M2M tools such as
ATL for EMF metamodels V4
Model-Driven Development – State of the Art
230
Status / Track Record / Future
• Version 3.1 is current
• Proven track record in various domains & project
contexts
– e.g., telcos, internet, enterprise, embedded realtime,
finance, …
• Version 4 will be released end of Jan, 2006
– Parts are already in use by some developers
– First milestone build Dec 15, 2005
• www.openarchitectureware.org
LIVE DEMO!
Model-Driven Development – State of the Art
231
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process
Modeling, & MDD
Product-line Architecture Case Study
Summary
232
CONTENTS
What is SOA?
• The whole concept of SOA is not really well defined today
• There are a number of ideas:
–SOA (at least in practice) means web services
–SOA means that everything is run through one middleware
infrastructure instead of many
–SOA means that IT is more business department-oriented
• Our view is that SOA is an architectural style to build scalable
(performance as well as size), maintainable & manageable systems
Model-Driven Development – State of the Art
233
A Typical SOA Blueprint
Model-Driven Development – State of the Art
234
SOA vs. Component-based Architecture
• A well-done component-based architecture with well-defined
interfaces & clearly cut component responsibilities can quite justifiable be
considered a SOA
–Components are a natural choice as the building blocks that provide &
consume services, specifically, since component platforms already
separate functionality from infrastructure!
–The industry currently defines a standard for Service-Component
Architectures [SCA]
Model-Driven Development – State of the Art
235
Characteristics of SOA’s
• Service interactions are often (though not always) message-oriented, or
document-centric
–Instead of defining rigidly typed interfaces, document structures
(schemas) are defined that serve as the basis for interactions
–This can make evolution of message structures & versioning much
simpler
• The interaction patterns, i.e., valid sequences of messages are defined
explicitly
–Interactions are often conversational, i.e., conversational session
state is kept “at both sides” of a service interaction
–This allows orchestration among services
–Usually, interactions are asynchronous
Model-Driven Development – State of the Art
236
Characteristics of SOA’s (cont’d)
• Quality of service aspects are addressed explicitly
–Service providers don’t just provide a certain services’ functionality,
they also provide the functionality with a defined service level (e.g.,
performance, reliability, etc)
• Service descriptions & characteristics are available at runtime
–Using service registries systems can be assembled dynamically
• Often, services are interoperable - they can be used by systems
implemented on various platforms
• Services should be designed to be coarse grained & encapsulate
functionality relevant from “business perspective” (although nobody can
say what this really means)
• Services are typically (but by no means exclusively) used by explicitly
modeled business processes
• They are secure, transactional, & manageable (like any good system)
Model-Driven Development – State of the Art
237
Relationship to MDD
• MDD is ideally suited to describe & develop SOA-based systems
The signatures & data structures
used in the service can be using
models
Model-Driven Development – State of the Art
238
Relationship to MDD
Theto
valid
interactions
• MDD is ideally suited
describe
& develop SOA-based systems
can be defined using
models (e.g., protocol
state machines)
Model-Driven Development – State of the Art
239
Relationship to MDD
• MDD is ideally suited to describe & develop SOA-based systems
Quality of Service Contracts
can be defined using models –
code to watchdog them can be
generated
Model-Driven Development – State of the Art
240
Relationship to MDD
Component-based
Development,
well as
• MDD
is ideallyas
suited
to describe & develop SOA-based systems
the assignment of service
providers & services
comsumers can be
based on models
Model-Driven Development – State of the Art
241
Relationship to MDD
• MDD is ideally suited to describe & develop SOA-based systems
Glue code for the
deployment to various
execution platforms can
be generated
automatically
Model-Driven Development – State of the Art
242
Relationship to MDD
• MDD is ideally suited to describe & develop SOA-based systems
The Mappings of the
Service Messages/Calls
to communication
infrastructures (web
services, Tibco, JMS, )
can be automatically
generated
Model-Driven Development – State of the Art
243
Relationship to MDD
• MDD is ideally suited to describe & develop SOA-based systems
The runtime repository
can be populated from
the data in the models
Model-Driven Development – State of the Art
244
Metamodel for SOA/CBD Development
• This metamodel describes
–component types & interfaces
–operations & data structures (not shown)
–component dependencies
Model-Driven Development – State of the Art
245
Metamodel for SOA/CBD Development
• This one describes component instances & their “wiring”
Model-Driven Development – State of the Art
246
Metamodel for SOA/CBD Development
• This final viewpoint associates component instances with nodes &
containers for deployment & glue code generation
Model-Driven Development – State of the Art
247
Metamodel for SOA/CBD Development
• Dependencies between viewpoint models are only allowed in the way
shown below in order to
– Be able to have several compositions per type model
– & several system models per composition
• This is important to be able to have several “systems”,
– Several deployed locally for testing, using only a subset of the defined
components,
– & “the real system”
Model-Driven Development – State of the Art
248
A Simple Metamodel for SOA – with CBD
• Here we define the
notion of a service
more extensively
Component
name
Provider
• Note how services
are connected to the
components defined
in the previous set
of metamodels
• Note that the SCA
standard uses the
same metaphors
Consumer
consumes
Provider
Consumer
p
provides
1..*
1..*
c
1..* 1..*
Service
0..1
*
Elementary
Service
Compound
Service
Oneway
Message
249
*
Message
*
name
Attribute
name
type
1..*
accepted
Message
– i.e., components, instances,
deployment, services
Model-Driven Development – State of the Art
Message
Flow
Control
Inbound
Message
Request
Message
Type
name
1..*
resp
Outbound
Message
Business Process Modeling & SOA
• BPM comes top down, SOA goes bottom up (driven by WS-technology)
• There is a non-empty intersection: Declaration of BPs, infrastructure
software (BPE, ESB)
– Approaches are not harmonized yet (e.g. BPEL vs. BPML/N)
• However, there are significant synergies – especially when using
separation of concerns
– BPM needs SOA but not the other way round
Business Processes & BPE
Service Interfaces &
Middleware (ESB)
Service Providing &
Consuming Components
Model-Driven Development – State of the Art
250
Business Process Modeling & SOA
• BPM comes top down, SOA goes bottom up (driven by WS-technology)
The business
processes
• There is a non-empty intersection: Declaration
of BPs,
infrastructure
are typically also
software (BPE, ESB)
modeled, as is their
– Approaches are not harmonized yetrelationship
(e.g. BPELtovs.
theBPML/N)
service
(interfaces)
theywhen
use using
• However, there are significant synergies
– especially
separation of concerns
– BPM needs SOA but not the other way round
Business Processes & BPE
Service Interfaces &
Middleware (ESB)
Service Providing &
Consuming Components
Model-Driven Development – State of the Art
251
Business Process Modeling & SOA
• BPM comes top down, SOA goes bottom up (driven by WS-technology)
• There
is that
a non-empty
Note
it is often intersection: Declaration of BPs, infrastructure
software
(BPE,
ESB)
unrealistic
to have
one &
one middleware
– only
Approaches
are not harmonized yet (e.g. BPEL vs. BPML/N)
because of varying non• However,
are significant synergies – especially when using
functionalthere
requirements
separation of concerns
– BPM needs SOA but not the other way round
Business Processes & BPE
Service Interfaces &
Middleware (ESB)
Service Providing &
Consuming Components
Model-Driven Development – State of the Art
252
Business Process Modeling & SOA
• BPM comes top down, SOA goes bottom up (driven by WS-technology)
• There is a non-empty intersection: Declaration of BPs, infrastructure
The important thing is that you
software (BPE, ESB). Approaches areare
notable
harmonized
yet (e.g. BPEL vs.
to map the same
BPML/N)
services to different
middleware
infrastructures
–
• However, there are significant synergies
– especially
when using
& use all of them from the
separation of concerns
business processes Again a
–BPM needs SOA but not the other way
round
reason
to use models!
Business Processes & BPE
Service Interfaces &
Middleware (ESB)
Service Providing &
Consuming Components
Model-Driven Development – State of the Art
253
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
254
CONTENTS
Case Study Example: Boeing Bold Stroke
Nav Sensors
Vehicle
Mgmt
Data Links
Mission
Computer
Radar
Expendable
Management
Expendables
• Avionics mission computing product-line
architecture for Boeing aircraft
Bold Stroke
Architecture
• DRE system with 100+ developers, 3,000+
software components, 3-5 million lines of C++
• Based on COTS hardware,
networks, operating
systems, languages, &
middleware
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
255
Applying COTS to Boeing Bold Stroke
COTS & standards-based middleware,
language, OS, network, & hardware
platforms
• Real-time CORBA middleware services
• ADAPTIVE Communication
Environment (ACE)
• C++/C & Real-time Java
• VxWorks operating system
• VME, 1553, & Link16
• PowerPC
Mission Computing Services
Middleware Infrastructure
Operating System
www.cs.wustl.edu/
~schmidt/TAO.html
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
256
Benefits of Using COTS
•Save a considerable amount of
time/effort compared with
handcrafting capabilities
•Leverage industry “best
practices” & patterns in prepackaged & ideally standardized
form
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
257
Limitations of Using COTS
• QoS of COTS components is not
always suitable for mission-critical
systems
• COTS technologies address some, but
not all, of the domain-specific
challenges associated with developing
mission-critical DRE systems
What we need is a reuse
technology for organizing
& automating key roles &
responsibilities in an
application domain
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
258
Motivation for Product-line Architectures (PLAs)
Nav
Air
Frame
HUD
AP
FLIR
Air
Frame
GPS
IFF
IFF
Cyclic
Exec
AP
Nav
Cyclic
Exec
F-15
Nav
HUD
HUD
Air
Frame
FLIR
AP
FLIR
GPS
IFF
GPS
Cyclic
Exec
Legacy DRE systems have
historically been:
• Stovepiped
• Proprietary
• Brittle & non-adaptive
• Expensive
• Vulnerable
Model-Driven Development – State of the Art
Consequence:
Small HW/SW
changes have big
(negative) impact
on DRE system
QoS & maintenance
259
HUD
AP
FLIR
Air
Frame
Cyclic
Exec
F/A-18
A/V-8B
GPS
Nav
IFF
UCAV
Motivation for Product-line Architectures (PLAs)
F/A 18
product
variant
A/V 8-B
product
variant
F-15
product
variant
Air
Frame
FLIR
HUD
AP
GPS
UCAV
product
variant
Nav
IFF
Domain-specific Services
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
OS & Network Protocols
Product-line
architecture
Hardware (CPU, Memory, I/O)
• Frameworks factors out many reusable general-purpose & domainspecific services from traditional DRE application responsibility
• Essential for product-line architectures (PLAs)
• Product-lines & frameworks offer many configuration opportunities
• e.g., component distribution & deployment, user interfaces & operating
systems, algorithms & data structures, etc
Model-Driven Development – State of the Art
260
Overview of Product-line Architectures (PLAs)
• PLA characteristics are
•Applying SCV to Bold Stroke
captured via Scope,
• Scope defines the domain & context of
Commonalities, &
the PLA
Variabilities (SCV) analysis
• Bold Stroke component architecture,
• This process can be applied
object-oriented application frameworks,
to identify commonalities &
& associated components, e.g., GPS,
variabilities in a domain to
Airframe, & Display
guide development of a PLA
Reusable Application
Components
Air
Frame
FLIR
HUD
Reusable Architecture
Framework
GPS
Nav
IFF
Domain-specific Services
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
OS & Network Protocols
Model-Driven Development – State of the Art
AP
261
Applying SCV to the Bold Stroke PLA
•Commonalities describe the attributes that are common across all
members of the PLA family
• Common object-oriented frameworks & set of component types
• e.g., GPS, Airframe, Navigation, & Display components
• Common middleware
infrastructure
• e.g., Real-time
CORBA & a variant
of Lightweight
CORBA Component
Model (CCM) called
Prism
GPS
Component
Display
Component
Airframe
Component
Bold Stroke Common Components
Domain-specific Services
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
OS & Network Protocols
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
Heads Up
Display
262
Applying SCV to the Bold Stroke PLA
•Variabilities describe the
attributes unique to the different
members of the family
GPS
Component
• Product-dependent component
implementations (GPS/INS)
• Product-dependent component
connections
• Product-dependent component
assemblies (e.g., different
weapons systems for different
customers/countries)
Display
Component
Airframe
Component
Heads Up
Display
Bold Stroke Common Components
GPS = 40 Hz
GPS = 20 Hz
Nav
Air
Frame
HUD
AP
FLIR
IFF
GPS
F/A 18 F
Nav
GPS=20Hz
Air
Frame
Air
Frame
HUD
AP
FLIR
GPS
IFF
AP
F 15K
Domain-specific Services
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
OS & Network Protocols
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
263
GPS
FLIR
HUD
• Different hardware, OS, &
network/bus configurations
Patterns & frameworks are
essential for developing
reusable PLAs
Nav
IFF
UCAV
Applying Patterns & Frameworks to Bold Stroke
Reusable object-oriented application
domain-specific middleware framework
•Configurable to variable infrastructure
configurations
•Supports systematic reuse of mission
computing functionality
•3-5 million lines of C++
•Based on many architecture & design
patterns
Patterns & frameworks
are also used
throughout COTS
software infrastructure
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
264
Legacy Avionics Architectures
Key System Characteristics
•Hard & soft real-time deadlines
•~20-40 Hz
•Low latency & jitter between
boards
•~100 usecs
•Periodic & aperiodic processing
•Complex dependencies
•Continuous platform upgrades
Avionics Mission
Computing Functions
•Weapons targeting
systems (WTS)
•Airframe & navigation
(Nav)
•Sensor control (GPS,
IFF, FLIR)
•Heads-up display
(HUD)
•Auto-pilot (AP)
Board 1
1553
VME
Board 2
Model-Driven Development – State of the Art
265
4: Mission
functions
perform
avionics
operations
3: Sensor
proxies
process data
& pass to
missions
functions
2: I/O via
interrupts
1: Sensors
generate
data
Legacy Avionics Architectures
Key System Characteristics
•Hard & soft real-time deadlines
•~20-40 Hz
•Low latency & jitter between
boards
•~100 usecs
•Periodic & aperiodic processing
•Complex dependencies
•Continuous platform upgrades
Limitations with Legacy Avionics
Architectures
•Stovepiped
•Proprietary
•Expensive
•Vulnerable
•Tightly coupled
•Hard to schedule
•Brittle & non-adaptive
Model-Driven Development – State of the Art
Nav
Air
Frame
WTS
AP
FLIR
GPS
IFF
4: Mission
functions
perform
avionics
operations
3: Sensor
proxies
process data
& pass to
missions
functions
Cyclic
Exec
2: I/O via
interrupts
Board 1
1553
VME
Board 2
266
1: Sensors
generate
data
Decoupling Avionics Components
Context
Problems
Solution
•I/O driven DRE
application
•Tightly coupled
components
•Complex
dependencies
•Hard to schedule
•Apply the PublisherSubscriber architectural
pattern to distribute periodic,
I/O-driven
data from a single point of
source to a collection of
consumers
Dynamics
•Expensive to
evolve
•Real-time
constraints
Structure
Publisher
produce
Event Channel
attachPublisher
detachPublisher
attachSubscriber
detachSubscriber
pushEvent
creates
*
Event
Subscriber
: Publisher
: Event Channel
: Subscriber
attachSubscriber
consume
produce
: Event
pushEvent
event
pushEvent
event
receives
consume
Filter
detachSubscriber
filterEvent
Model-Driven Development – State of the Art
267
Applying the Publisher-Subscriber Pattern to Bold Stroke
Bold Stroke uses the PublisherSubscriber pattern to decouple sensor
processing from mission computing
operations
Subscribers
HUD
Air
Frame
Nav
• Anonymous publisher & subscriber
relationships
• Group communication
• Asynchrony
4: Event Channel
pushes events
to
subscribers(s)
push(event)
Event
Channel
push(event)
Considerations for implementing the
Publisher-Subscriber pattern for
mission computing applications include:
• Event notification model
• Push control vs pull data interactions
• Scheduling & synchronization strategies
• e.g., priority-based dispatching &
preemption
• Event dependency management
• e.g.,filtering & correlation mechanisms
Model-Driven Development – State of the Art
WTS
GPS
IFF
FLIR
Publishers
3: Sensor
publishers
push events
to event
channel
2: I/O via interrupts
Board 1
1553
VME
Board 2
268
5: Subscribers
perform
avionics
operations
1: Sensors
generate
data
Ensuring Platform-neutral Inter-process Communication
Context
Problems
Solution
•Mission
•Applications need capabilities to:
computing
• Support remote communication
requires remote
• Provide location transparency
• Handle faults
IPC
•Stringent DRE
requirements
•Apply the Broker
architectural pattern
to provide platformneutral comms
• Manage end-to-end QoS
between mission
• Encapsulate low-level system details computing boards
Server Proxy
Client Proxy
marshal
unmarhal
receive_result
service_p
* calls
1
Client
Structure
*
1
Broker
message main_loop
exchange srv_registration
srv_lookup
xmit_message
manage_QoS
call_service_p
start_task
Model-Driven Development – State of the Art
269
1
*
message
exchange
marshal
unmarshal
dispatch
receive_request
* calls
1
Server
start_up
main_loop
service_i
Ensuring Platform-neutral Inter-process Communication
Context
Problems
Solution
•Mission
•Applications need capabilities to:
computing
• Support remote communication
requires remote
• Provide location transparency
• Handle faults
IPC
•Apply the Broker
architectural pattern
to provide platformneutral comms
• Manage end-to-end QoS
between mission
• Encapsulate low-level system details computing boards
•Stringent DRE
requirements
: Client
: Client Proxy
operation (params)
: Broker
: Server Proxy
: Server
register_service
connect
marshal
Dynamics
start_up
assigned
port
send_request
unmarshal
dispatch
operation (params)
result
marshal
receive_reply
unmarshal
result
Model-Driven Development – State of the Art
270
Applying the Broker Pattern to Bold Stroke
Bold Stroke uses the Broker pattern
to shield distributed applications
from environment heterogeneity,
e.g.,
Subscribers
HUD
Air
Frame
push(event)
•Programming languages
5: Event Channel
pushes events
to subscribers(s)
Event
Channel
•Operating systems
push(event)
•Networking protocols
•Hardware
WTS
Nav
GPS
IFF
FLIR
Publishers
2: I/O via interrupts
Board 1
1553
•e.g., latency, jitter, priority
preservation, dependability,
security, etc
Model-Driven Development – State of the Art
4: Sensor
publishers
push events
to event
channel
3: Broker
handles I/O
via upcalls
Broker
A key consideration for
implementing the Broker pattern
for mission computing applications
is QoS support
6: Subscribers
perform
avionics
operations
VME
Board 2
271
1: Sensors
generate
data
Benefits of Patterns
Subscribers
Nav
WTS
HUD
push(event)
Air Frame
• Improves development team
communication
Event
Channel
• Convey “best practices” intuitively
push(event)
GPS
• Enables reuse of software
architectures & designs
IFF
FLIR
Publishers
Broker
• Transcends language-centric
biases/myopia
• Abstracts away from many
unimportant details
Mission Computing Services
Middleware Infrastructure
www.cs.wustl.edu/
~schmidt/patterns.html
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
272
Limitations of Patterns
Subscribers
Nav
WTS
HUD
push(event)
Air Frame
Event
Channel
• Can be deceptively simple
push(event)
GPS
• Require significant tedious &
error-prone human effort to
handcraft pattern
implementations
IFF
FLIR
Publishers
Broker
• Leaves many important details
unresolved
We therefore need
more than just
patterns to achieve
systematic reuse
Mission Computing Services
Middleware Infrastructure
www.cs.wustl.edu/
~schmidt/patterns.html
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
273
Applying Frameworks to Bold Stroke
Application-specific functionality
Sensor
Management
Networking
Route
Planning
Real-time
Database
Framework benefits &
characteristics
Heads-up
Display
GUI
•Frameworks exhibit
“inversion of control” at
runtime via callbacks
•Frameworks
provide integrated
domain-specific
structures &
functionality
•Frameworks are
“semi- complete”
applications
Mission Computing Services
Middleware Infrastructure
Operating System
www.cs.wustl.edu/
~schmidt/ACE.html
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
274
Limitations of Frameworks
• Frameworks are powerful, but can be
hard to develop & use effectively
• Significant time required to evaluate
applicability & quality of a framework for a
particular domain
• Debugging is tricky due to inversion of
control
• V&V is tricky due to “late binding”
Mission Computing Services
Middleware Infrastructure
• May incur performance degradations due
to extra (unnecessary) levels of
indirection
We therefore need
something simpler than
frameworks to achieve
systematic reuse
Operating System
www.cs.wustl.edu/
~schmidt/PDF/Queue-04.pdf
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
275
Applying Component Middleware to Bold Stroke
Product-line component model
• Configurable for product-specific
functionality & execution environment
• Single component development policies
• Standard component packaging
mechanisms
• 3,000+ software components
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
276
Benefits of Component Middleware
• Creates a standard
“virtual boundary” around
application component
implementations that
interact only via welldefined interfaces
• Define standard
• Specify the infrastructure
container mechanisms needed to configure &
needed to execute
deploy components
components in generic throughout a distributed
component servers
system
…
…
…
…
Container
<ComponentAssemblyDescription id="a_HUDDisplay">
<connection>
<name>GPS-RateGen</name>
<internalEndPoint><portName>Refresh</portName><instance>a_GPS</
instance>
</internalEndPoint>
<internalEndPoint>
<portName>Pulse</portName><instance>a_RateGen</instance>
</internalEndPoint>
</connection>
<connection>
<name>NavDisplay-GPS</name>
<internalEndPoint><portName>Refresh</portName><instance>a_NavDi
splay</instance>
</internalEndPoint>
<internalEndPoint><portName>Ready</portName><instance>a_GPS</in
stance>
</internalEndPoint>
</connection>
</ComponentAssemblyDescription>
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
…
277
Limitations of Component Middleware
DRE Applications
Middleware
Services
•Limit to how much application
functionality can be refactored into
reusable COTS component
middleware
Middleware
Operating System
& Protocols
Hardware &
Networks
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
278
Limitations of Component Middleware
Load Balancer
FT CORBA
Workload &
Replicas
RT/DP CORBA + DRTSJ
Connections &
priority bands
RTOS + RT
Java
IntServ + Diffserv
CPU & memory
•Limit to how much application
functionality can be refactored into
reusable COTS component
middleware
•Middleware itself has become hard to
provision/use
Network latency
& bandwidth
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
279
Limitations of Component Middleware
•Limit to how much application
functionality can be refactored into
reusable COTS component
middleware
•Middleware itself has become hard to
provision/use
•Large # of components can be
tedious & error-prone to configure &
deploy without proper integration tool
support
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
280
Limitations of Component Middleware
RT-CORBA
Apps DRE
RT-CORBA
Services
RT-CORBA
J2ME
DRTSJ
Applications
Apps
Apps
Middleware
J2ME
Services
Services
Middleware
J2ME
DRTSJ
Services
DRTSJ
Operating System
& Protocols
Hardware &
Networks
•Limit to how much application
functionality can be refactored into
reusable COTS component
middleware
•Middleware itself has become hard to
provision/use
•Large # of components can be
tedious & error-prone to configure &
deploy without proper integration tool
support
• There are many
middleware technologies
to choose from
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
281
Applying MDD to Boeing Bold Stroke
Model-driven development
(MDD)
• Apply MDD tools to
• Model
• Analyze
• Synthesize
• Provision
<CONFIGURATION_PASS>
<HOME>
<…>
<COMPONENT>
<ID> <…></ID>
<EVENT_SUPPLIER>
<…events this
component supplies…>
</EVENT_SUPPLIER>
</COMPONENT>
</HOME>
</CONFIGURATION_PASS>
middleware & application
components
• Configure product-specific
component assembly &
deployment environments
• Model-based component
integration policies
Mission Computing Services
Middleware Infrastructure
Operating System
www.isis.vanderbilt.edu/
projects/mobies
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
282
Applying MDD to Boeing Bold Stroke
EMBEDDED PLATFORM MODEL
UML/Rose
ESML/GME
PICML/GME
PowerPC/
ACE+TAO/
BOLDSTROKE
APPLICATION MODELING TOOLS
Formal mission specs,
subsystem models, &
computational constraints
are combined into integrated
MDD tool chain & mapped to
execution platforms
Interaction is based on
mission-specific
ontologies & semantics
ARIES
TimeWeaver
TimeWiz
Cadena
ANALYSIS TOOLS
Stateflow
C/C++
Statecharts
SMV
Ptolemy
SPIN
Simulink
Real-time Java
XML
Mission Computing Services
Ptolemy
CODE GENERATORS
Middleware Infrastructure
Operating System
Networking Interfaces
www.rl.af.mil/tech/
programs/MoBIES/
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
283
Avionics Mission Computing
Modeling Languages
Benefits of MDD
• Increase expressivity
• e.g., linguistic support to better capture
design intent
• Increase precision
Artifact
Generator
• e.g., mathematical tools for cross-domain
modeling, synchronizing models, change
propagation across models, modeling
security & other QoS aspects
• Achieve reuse of domain semantics
• Generate code that’s more “platformindependent” (or not)!
• Support product-line
architecture development
& evolution
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
284
Limitations of MDD
Model & Component
Library
Applications
$
$
•Modeling technologies
are still maturing &
evolving
$
• i.e., non-standard
tools
Mission Computing Services
Middleware Infrastructure
•Magic (& magicians) are
still necessary for
success
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Model-Driven Development – State of the Art
285
Model-Driven Development:
State of the Art
Introduction & Motivation
Definition of Terms
Architecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDD
How Generators Work – MDD & Compiler Construction
Model-to-Model Transformations
An Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWare
SOA, Business Process Modeling, & MDD
Product-line Architecture Case Study
Summary
286
CONTENTS
Open MDD R&D Issues
• Accidental Complexities
• Inherent Complexities
• Round-trip engineering from
models ↔ source
• Capturing specificity of target domain
• Mismatched abstraction levels
for development vs debugging
• Tool chain vs monolithic tools
• Backward compatibility of
modeling tools
• Standard metamodeling
languages & tools
• Automated specification & synthesis of
• Model interpreters
• Model transformations
• Broader range of application
capabilities
• Static & dynamic QoS properties
• Migration & version control of models
• Scaling & performance
• Verification of the DSLs
Solutions require validation on large-scale, real-world systems
Model-Driven Development – State of the Art
287
Current Status & Available Tools
• Today’s MDD tools can be used productively – although sometimes
some “magic” is necessary
• Today’s problem is not really that we need better tools, per se, we
rather need more experience with existing tools!
• Standardization efforts are slowly coming to fruition: EMF/GMF, QVT,
MIC, etc.
Start today – it will make you more productive
• CoSMIC is available from
www.dre.vanderbilt.edu/cosmic
• GME is available from www.isis.vanderbilt.edu/Projects/gme/default.htm
• openArchitectureWare is available from
www.openarchitectureware.org
Model-Driven Development – State of the Art
288
What We Hope You Learned Today!
• Key MDD concepts & what kinds of domains &
problems they address
• What are some popular MDD tools & how they work
• How MDD relates to other software tools &
(heterogeneous) platform technologies
• What types of projects are using MDD today & what
are their experiences
• What are the open issues in MDD R&D & adoption
• Where you can find more information
Model-Driven Development – State of the Art
289
Some Advertisements
• For those, who speak (or rather read ;-)) german:
Stahl, Völter:
Modellgetriebene
Softwareentwicklung
Technik, Engineering, Management
dPunkt, 2005
www.mdsd-buch.de
• A very much updated English translation is
under way:
Model-Driven
Software Development,
Wiley, Q2 2006
www.mdsd-book.org
Model-Driven Development – State of the Art
290
Questions?
Model-Driven Development – State of the Art
291