Upload
duonghanh
View
221
Download
0
Embed Size (px)
Citation preview
1
ModelModel--Driven DevelopmentDriven DevelopmentState of the ArtState of the Art
OOP Conference, Monday, January 16OOP Conference, Monday, January 16thth, 2005, 2005
Dr Douglas C Schmidt [email protected]
www.dre.vanderbilt.edu/~schmidtInstitute for Software Integrated
SystemsVanderbilt University Nashville,
Tennessee
Markus Völter [email protected]
www.voelter.deIndependent Consultantfor Software Engineering
and TechnologyHeidenheim, Germany
Thomas [email protected]
www.bmiag.deb+m Informatik AG,
Chef-ArchitektKiel, Germany
2
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
2
3
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Model-Driven Development – State of the Art 4
CPU & network performance has increased by 3-8 orders of magnitude in past decades
1,200 bits/sec to 10+ Gigabits/sec
The Road Ahead
Extrapolating these trends another decade or so yields• ~100 Gigahertz desktops• ~100 Gigabits/sec LANs• ~100 Megabits/sec wireless• ~10 Terabits/sec Internet backbone
10 Megahertz to 3+ Gigahertz
Unfortunately, software quality & productivity hasn’t improved as
rapidly or predictably as hardware –especially for distributed real-time &
embedded (DRE) systems
3
Model-Driven Development – State of the Art 5
Why Hardware Improves So ConsistentlyAdvances in hardware & networks stem largely from R&D on standardized & reusable APIs & protocols
x86 & Power PC chipsets TCP/IP
Model-Driven Development – State of the Art 6
ApplicationSoftware
ApplicationSoftware
ApplicationSoftware
ApplicationSoftware
Why Software Fails to Improve as ConsistentlyIn general, software has not been as standardized or reusable as hardware
F-15 A/V-8B F/A-18
AirFrame
GPS
FLIR
GPS
FLIR
AP
Nav HUD
IFF
Cyclic Exec
AirFrame AP
Nav HUD
GPSIFF
FLIR
Cyclic Exec
AirFrame
VxWorks
AP Nav
HUD
IFF AirFrame
AP
Nav HUDGPS
IFF
FLIR
VxWorks
UCAV
1553VME
Link16
1553VME
Link16
1553VME
Link16
Standard/COTS Hardware & Networks
Proprietary & Stovepiped Application & Infrastructure Software
4
Model-Driven Development – State of the Art 7
The Promise
•Develop standardize technologies that:1. Model2. Analyze3. Synthesize &4. Provision
complex software systems <CONFIGURATION_PASS>
<HOME><…>
<COMPONENT><ID> <…></ID><EVENT_SUPPLIER><…events this
component supplies…></EVENT_SUPPLIER></COMPONENT></HOME>
</CONFIGURATION_PASS>
<CONFIGURATION_PASS><HOME><…>
<COMPONENT><ID> <…></ID><EVENT_SUPPLIER><…events this
component supplies…></EVENT_SUPPLIER></COMPONENT></HOME>
</CONFIGURATION_PASS>Gigabit EthernetGigabit
Ethernet
Build
Analyze
Model-Driven Development – State of the Art 8
static CORBA::Long receiver_pid_;static FILE *output_file = 0;// File handle of the file into which received data is writtenquo::ValueSC_var actualFrameRate;// Poke this in order to send the measured frame rate toQuO// destination port to send mpeg data to onlocalhoststaticintoutput_port = 8001;// Instrumentation HelperstaticInstrumentor*instrument = 0;// Name of processstatic ACE_CStringprocess_name_;intReceiver_StreamEndPoint::get_callback (constchar *flowname, TAO_AV_Callback*&callback) {
ACE_DECLARE_NEW_CORBA_ENV;// Create and return the sender application callback toAVStreamsfor furtherupcallsint retval= 0;callback = &this->callback_;RECEIVER::instance ()->connection_manager ()connect_negotiator(this,flowname);returnretval; }
Receiver_Callback::Receiver_Callback (void) : frame_count_ (1) {ACE_INET_Addr inet_addr(output_port, "localhost");dvdview_endpoint_open(inet_addr); }
intReceiver_Callback::receive_frame (ACE_Message_Block *frame, TAO_AV_frame_info * /*frame_info*/,constACE_Addr&) {
//Upcallfrom theAVStreamswhen there is data to be received from the sender++frame_count_;while (frame != 0) {
char *buf= frame->rd_ptr();// Get the RTP fixed headerrtp_hdr_thdr;ACE_OS::memcpy(&hdr, buf,sizeof(rtp_hdr_t));// decode the RTP header (endianproblems)rtp_hdr_t decoded_rtp_hdr;decode_rtp_hdr(&hdr, &decoded_rtp_hdr);// Get the MPEG RTP header extensionrtp_mpeg_hdr_t mpeg_hdr;ACE_OS::memcpy(&mpeg_hdr,buf+sizeof(rtp_hdr_t),sizeof(rtp_mpeg_hdr_t));// extract the frame type from the RTP header extensionu_char frame_type = mpeg_hdrbf1 & 0x07;RECEIVER::instance ()->time_frame (frame_type);// strip off thertpheaders for sendingchar *send_buf= &buf[sizeof(rtp_hdr_t) +sizeof(rtp_mpeg_hdr_t) ];size_t send_len= frame->length() -sizeof(rtp_hdr_t) -sizeof(rtp_mpeg_hdr_t);if (instrument && (frame_type == 1)) {
Instrumentor::MessageBodybody;ACE_Time_Valuetv= ACE_OS::gettimeofday();bodyadd_string(Instrument::Name, RECEIVER::instance()->name());bodyadd_ulong(Instrument::SequenceNumber, decoded_rtp_hdrseq);bodyadd_double(Instrument::Timestamp, (CORBA::Double)decoded_rtp_hdrts);bodyadd_double(Instrument::ReceiveTime, (CORBA::Double)((unsigned long)tvmsec()) );
bodyadd_double(Instrument::FrameTiming, (CORBA::Double)(tvmsec() - decoded_rtp_hdrts) );bodyadd_string(Instrument::ProcessName, process_name_c_str());bodyadd_long(Instrument::PID, receiver_pid_);instrument->send_event(Instrument::ReceiverFrameStats, body); }if (output_file) {// Write the received data to the fileintresult = ACE_OS::fwrite(send_buf, send_len, 1, output_file); }
dvdview_endpoint_send (send_buf, send_len);frame = frame->cont(); }
return 0; }Receiver::Receiver (void) : debug_level_ (0),mmdevice_ (0),output_file_name_ (), is_output_file_ (0),
sender_name_ ("distributor"), receiver_name_ ("receiver"), use_qos_stream_(0) {}Receiver::~Receiver (void) {}intReceiver::init(int, char**,CORBA::Environment &ACE_TRY_ENV) {// Initialize the endpoint strategy with the orb andpoaintresult = this->reactive_strategy_init(TAO_AV_CORE::instance ()->orb (),
TAO_AV_CORE::instance ()->poa());if (result != 0) return result;// Initialize the connection managerresult = this->connection_manager_init(TAO_AV_CORE::instance ()->orb ());if (result != 0) return result;// Register the receivermmdeviceobject with the ORBACE_NEW_RETURN (this->mmdevice_, TAO_MMDevice(&this->reactive_strategy_), -1);// Servant Reference Counting to manage lifetimeAVStreams::MMDevice_var mmdevice= this->mmdevice_->_this (ACE_TRY_ENV);ACE_CHECK_RETURN (-1);// Bind to senderthis->connection_manager_bind_to_sender (this->sender_name_, this->receiver_name_,mmdevicein (),
ACE_TRY_ENV);ACE_CHECK_RETURN (-1);
AVStreams::streamQoSthe_qos;this->fill_qos( the_qos); // Connect to the senderthis->connection_manager_connect_to_sender (the_qos, use_qos_stream_, ACE_TRY_ENV);ACE_CHECK_RETURN (-1);CORBA::ORB_varorb = TAO_AV_CORE::instance ()->orb();// Connect toQuOsystem condition to setactualFrameRateACE_CStringname_cstr("ActualFrameRate_");name_cstr+= this->sender_name_ + "_" + this->receiver_name_;CosNaming::NamingContext_var nc=NamingHelper<CosNaming::NamingContext>::resolve_init
(CORBA::ORB::_duplicate(orbin()), "NameService", 5, ACE_Time_Value(1, 0));CosNaming::Name name;namelength(1);name[0]id = CORBA::string_dup(name_cstrc_str());name[0]kind = CORBA::string_dup("");//QuO syscondthat should receive the measured frame rateframe_rate_meter_set_framerate_sc(NamingHelper<quo::ValueSC>::resolve_name(ncin(),
name, 15, ACE_Time_Value(1, 0)));return 0; }
intReceiver::parse_args(int argc, char**argv) {if(argc< 2 ){
usage();return -1; }
for(inti=0; i <argc; i++) {if(strcmp(argv[i], "--qos") == 0) use_qos_stream_ = 1; }
// Parse the command line argumentsACE_Get_Opt opts (argc,argv, "f:s:r:d:p:");intc;while ((c = opts ()) != -1) {
switch (c) {case 'f': this->output_file_name_ = optsoptarg; this->is_output_file_ = 1; break;case 's': this->sender_name_ = optsoptarg; break;case 'r': this->receiver_name_ = optsoptarg; break;
case 'd': this->debug_level_ = ACE_OS::atoi(optsoptarg); break;case 'p': output_port = ACE_OS::atoi(optsoptarg); break;default: ACE_ERROR_RETURN ((LM_ERROR, "Usage: receiver -f filename"), -1); } }
instrument = newInstrumentor(TAO_AV_CORE::instance ()->orb(), Instrument::domain_name,this->receiver_name_c_str());
return 0; }Connection_Manager &Receiver::connection_manager (void) { return this->connection_manager_; }
void Receiver::usage() {ACE_DEBUG((LM_DEBUG, "Usage:\n\n"));ACE_DEBUG((LM_DEBUG, " receiver -s [sender name] -r [receiver name]\n"));ACE_DEBUG((LM_DEBUG, " -d [debug level] -f [file name]\n"));ACE_DEBUG((LM_DEBUG, " -p [output UDP port, default is %d]\n", output_port));ACE_DEBUG((LM_DEBUG, " [--qos]\n")); }
void Receiver::time_frame (intframe_type) {frame_rate_meter_time_frame (frame_type); }
void Receiver::fill_qos(AVStreams::streamQoS&qos) {#if 1 || defined(RESERVATION_CONTROL)qoslength(0);
#elseCORBA::ULongbandwidth =1000000/8;CORBA::ULongpeak_bandwidth =1100000/8;qoslength (1);qos[0]QoSType= CORBA::string_dup("Data_Receiver");qos[0]QoSParamslength (10);qos[0]QoSParams[0]property_name = CORBA::string_dup("Service_Type");qos[0]QoSParams[0]property_value <<= (CORBA::Short) ACE_SERVICETYPE_CONTROLLEDLOAD;qos[0]QoSParams[1]property_name = CORBA::string_dup("Token_Rate");qos[0]QoSParams[1]property_value <<= (CORBA::ULong) bandwidth ;qos[0]QoSParams[2]property_name = CORBA::string_dup("Token_Bucket_Size");qos[0]Qo
SParams
[2]property_value <<= (CORBA::ULong) 5000;qos[0]QoSParams[3]property_name = CORBA::string_dup("Peak_Bandwidth");qos[0]QoSParams[3]property_value <<= (CORBA::ULong) peak_bandwidth;qos[0]QoSParams[4]property_name = CORBA::string_dup("Latency");qos[0]QoSParams[4]property_value <<= (CORBA::ULong) 0;qos[0]QoSParams[5]property_name = CORBA::string_dup("Delay_Variation");qos[0]QoSParams[5]property_value <<= (CORBA::ULong) 0;qos[0]QoSParams[6]property_name = CORBA::string_dup("Max_SDU_Size");qos[0]QoSParams[6]property_value <<= (CORBA::ULong) 368;qos[0]QoSParams[7]property_name = CORBA::string_dup("Minimum_Policed_Size");qos[0]QoSParams[7]property_value <<= (CORBA::ULong) 368;qos[0]QoSParams[8]property_name = CORBA::string_dup("TTL");qos[0]QoSParams[8]property_value <<= (CORBA::ULong) 25;qos[0]QoSParams[9]property_name = CORBA::string_dup("Priority");qos[0]QoSParams[9]property_value <<= (CORBA::ULong) 1;
#endif}ACE_CstringReceiver::output_file_name (void) {return this->output_file_name_; }
intReceiver::is_output_file (void) {return this->is_output_file_; }
intReceiver::spawn_viewer() {if( ACE_OS::access("/dvdview/src/dvdview", X_OK) != 0 ) {
return -1; }ACE_Process process;ACE_Process_Options options;optionscommand_line ("%s -z %d a", "/dvdview/src/dvdview", output_port);pid_t viewer_pid= ACE_OS::fork();pid_t receiver_pid= 0;switch(viewer_pid) {
case -1: /* error */ ACE_OS::exit(99); break;case 0: /* child */ processspawn(options); break;default: /* parent */ receiver_pid= ACE_OS::fork();
switch(receiver_pid){case -1: /* error */ ACE_OS::exit(98); break;case 0: /* child */ break;default: break; }
break; }intstatus1, status2;if( receiver_pid!= 0) {
ACE_OS::waitpid(viewer_pid, &status1, 0);ACE_OS::waitpid(receiver_pid, &status2, 0);ACE_OS::exit(0); }
return 0; }constchar * Receiver::name()const{return receiver_name_c_str(); }
intmain (int argc, char**argv) {receiver_pid_ = (CORBA::Long)ACE_OS::getpid();process_name_ = ACE::basename(argv[0]);ACE_DECLARE_NEW_CORBA_ENV;ACE_TRY {
// Initialize the ORB firstCORBA::ORB_varorb = CORBA::ORB_init(argc,argv, 0, ACE_TRY_ENV);ACE_TRY_CHECK;CORBA::Object_var obj= orb->resolve_initial_references ("RootPOA", ACE_TRY_ENV);ACE_TRY_CHECK;// Get the POA_varobject from Object_varPortableServer::POA_varroot_poa=PortableServer::POA::_narrow (objin (), ACE_TRY_CHECK;PortableServer::POAManager_var mgr= root_poa->the_POAManager(ACE_TRY_ENV);ACE_TRY_CHECK;mgr->activate (ACE_TRY_ENV);ACE_TRY_CHECK;// Initialize theAVStreamscomponentsTAO_AV_CORE::instance ()->init(orbin (), root_poain (), ACE_TRY_ENV);ACE_TRY_CHECK;Receiver *receiver = RECEIVER::instance ();intresult = receiver->parse_args(argc,argv);if (result == -1) return -1;receiver->spawn_viewer(); if (receiver->is_output_file ()) {// Make sure we have a valid <output_file>output_file = ACE_OS::fopen(receiver->output_file_name ()c_str(), "w");if (output_file == 0)
ACE_ERROR_RETURN ((LM_DEBUG, "receiver->output_file_name ()c_str()), -1);
else ACE_DEBUG ((LM_DEBUG, “result = receiver->init(argc,argv, ACE_TRY_ENV);ACE_TRY_CHECK;if (result != 0) return result;orb->run (ACE_TRY_ENV);ACE_TRY_CHECK;// Hack for nowACE_OS::sleep (1);orb->destroy (ACE_TRY_ENV);ACE_TRY_CHECK; }
ACE_CATCHANY {ACE_PRINT_EXCEPTION (,"receiver::init");return -1; }
ACE_ENDTRY;ACE_CHECK_RETURN (-1);ACE_OS::fclose(output_file);return 0; }
The Reality
• Architects (sometimes) use UML to express software designs at a high-level
• Developers write & evolve code manually
We ought/need to be able to do much better than this!
5
Model-Driven Development – State of the Art 9
Impediments of human nature• Organizational, economic, administrative, political, &
psychological barriersIneffective technology transition strategies• Disconnects between methodologies & production
software development realities• Lack of incremental, integrated, & triaged transitions
Non-Technical Challenges
Technical Challenges
Sources of the ProblemsInherent & 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
www.cs.wustl.edu/~schmidt/reuse-lessons.html
Model-Driven Development – State of the Art 10
Key Challenges for Software Developers
LogicalLogicalViewView
PhysicalPhysicalViewView
DevelopmentDevelopmentViewView
ProcessProcessViewView
Use CaseUse CaseViewView
Developers & users of software face challenges in multiple dimensions
6
Model-Driven Development – State of the Art 11
LogicalLogicalViewView
Determining units of abstraction for system (de)composition,
reuse, & validation
• Popular technologies & tools provide inadequate support for
– Checking pre-/post-conditions & invariants
– Specifying & analyzing dependencies
– Expressing design intent more clearly using domain concepts
Key Challenges for Software Developers
Model-Driven Development – State of the Art 12
PhysicalPhysicalViewView
Integrating/deploying diverse new & reusable application components in a networked environment to ensure
end-to-end QoS requirements
• 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
Key Challenges for Software Developers
7
Model-Driven Development – State of the Art 13
ProcessProcessViewView
Devising execution architectures, concurrency models, & communication styles
that ensure multi-dimensional QoS & correctness of new/reusable components
• Popular technologies & tools provide inadequate support for
– Identifying & reducing performance & robustness risks earlier in system lifecycle
– 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)
Key Challenges for Software Developers
Model-Driven Development – State of the Art 14
DevelopmentDevelopmentViewView
(De)composing systems into reusable modules (e.g., packages,
subsystems, libraries) that achieve/preserve QoS properties
• Popular technologies & tools provide inadequate support for avoiding
– 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
Key Challenges for Software Developers
8
Model-Driven Development – State of the Art 15
Capturing functional & QoS requirements of systems & reconciling them with other
views during evolution
• Popular technologies & tools provide inadequate support for– Ensuring semantic consistency & traceability between requirements &
software artifacts– Visualizing software architectures from multiple views
Use CaseUse CaseViewView
Key Challenges for Software Developers
Model-Driven Development – State of the Art 16
Promising Solution Approaches
Model-based analysis, generation, &integration & domain-specific languages
Verification & validation technologies, e.g., model checking & static analysis
Component middleware & frameworks that integrate
real-time, fault-tolerance, & security properties
GPS IFF FLIR
Object Request Broker
AirFrame
AP Nav WTS
Event Channel
ReplicationService
SynchronizationPersistence
Fault ToleranceMemory Management
Cross-cutting Concerns
Multi-faceted SoftwareDevelopment
Formalizing best practices & design expertise
9
Model-Driven Development – State of the Art 17
LogicalLogicalViewView
Promising Solution ApproachesDevising composable abstractions whose
interfaces & QoS properties can be specified/analyzed
via metadata
•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
SecurityReplication NotificationPersistence
SchedulingA/V Streaming Load Balancing
…
Container
… …
Middleware Bus
Container
…
Model-Driven Development – State of the Art 18
Promising Solution Approaches
PhysicalPhysicalViewView
Model-driven development & analysis techniques for optimizing,
verifying, & automating the deployment & configuration process Gigabit Ethernet
10
Model-Driven Development – State of the Art 19
ProcessProcessViewView
Promising Solution ApproachesSoftware architecture execution
modeling/simulation techniques & tools; distributed continuous quality assurance
KillEval
Sched
EO
Illum
AAWEG
AAWAAWTBMEG
AAWAAWAAWMG
TMBMG
• Synthetic workload & simulated components
• Replaced incrementally with actual applications & components
Gigabit Ethernet
Build & Test Scoreboard
• Automate the QA process
Model-Driven Development – State of the Art 20
DevelopmentDevelopmentViewView
Promising Solution Approaches
Development environments that provide multiple views & minimize dependencies between large-scale software artifacts to
optimize development & test cycles
• Packages view – shows element tree defined by project's build class path
• Type hierarchy view – shows the sub- & supertype hierarchies
• Outline view – shows the structure of a compilation unit or class file
• Browsing perspecitve – 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
11
Model-Driven Development – State of the Art 21
Use CaseUse CaseViewView
Promising Solution Approaches
Automated tracing of (in)consistency between
requirement specifications & associated software artifacts
MatlabCode-GenMatlab
Code-Gen
Domain-Specific Modeling Languages
ArtifactGenerator
if (inactiveInterval != -1) {int thisInterval =
(int)(SystemcurrentTimeMillis() -lastAccessed) / 1000;
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() {
return (thislastAccessedTime);
}
thislastAccessedTime = time;
ConfigurationSpecification
Analysis Tool
Code
• One way to automate tracing between higher-level specifications & lower-level implementations is to leverage model-driven development techniques & tools
Model-Driven Development – State of the Art 22
Technology Evolution (1/4)Level of A
bstraction
Programming Languages & Platforms
Model-Driven Development (MDD)
• State chart
• Data & process flow
• Petri NetsTransla
tion
Large Semantic Gap
Transla
tion
Transla
tion
CodeCodeCodeCodeCodeCodeModelModel
ModelModelModelModelModel
GeneratedCode
Model
Platform
Machine codeAssemblyC/Fortran
Hardware
OperatingSystems
12
Model-Driven Development – State of the Art 23
Technology Evolution (2/4)Programming Languages
& Platforms
Level of Abstraction
C++/JavaClass LibrariesFrameworksComponents
Machine codeAssemblyC/Fortran
Hardware
OperatingSystems
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Domain SpecificFrameworkPlatform
Frameworks
FrameworkPattern Language
Platform
Application Code
•New languages & platforms have raised abstraction level significantly•“Horizontal” platform reuse alleviates the need to redevelop common services
•There are two problems, however:•Platform complexity evolved faster than 3rd-generation languages
•Much application/platform code still (unnecessarily) written manually•Particularly for D&C & QA aspects
Model-Driven Development – State of the Art 24
Technology Evolution (3/4)Programming Languages
& Platforms
Level of Abstraction
Saturation!!!!
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model-Driven Development (MDD)
Domain-specificmodeling languages
• ESML• PICML• Mathematic• Excel• MetamodelsManual
translation
C++/JavaClass LibrariesFrameworksComponents
Machine codeAssemblyC/Fortran
Hardware
OperatingSystems
Semi-automated
Domain-independent modeling languages
• State Charts• Interaction Diagrams• Activity Diagrams
• OMG is evaluating MDD via MIC PSIG• mic.omg.org
13
Model-Driven Development – State of the Art 25
Technology Evolution (4/4)Programming Languages
& Platforms
Needs Automation
Needs Automation
Research is needed to automate DSLs & model translators
Level of Abstraction
Saturation!!!!
PlatformFrameworks
Application Code
Model
Platform
Generated Code
Model
PlatformFrameworks
Application Code
Model
Platform
Generated Code
Model
PlatformFrameworks
Application Code
Model
Platform
Generated Code
Model
PlatformFrameworks
Application Code
Model
Platform
Generated Code
Model
Domain-specific modeling languages
• ESML• PICML• Mathematic• Excel• MetamodelsNeeds
Automation
Domain-independent modeling languages
• State Charts• Interaction Diagrams• Activity Diagrams
C++/JavaClass LibrariesFrameworksComponents
Machine codeAssemblyC/Fortran
Hardware
OperatingSystems
Model-Driven Development (MDD)
26
CONTENTSModel-Driven Development:State of the Art
Introduction & Motivation
Definition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
14
Model-Driven Development – State of the Art 27
The MDD Blueprint
Applikations-Modell
Applikations-Modell
HandcraftedCode
HandcraftedCode
Code of Application orReference Implementation
analyse separate
Platform
IndividualCode
ApplicationModel
DSL
Trans-formations
uses creates
GenericCode
IndividualCode
SchematicRepetitive
Code
SchematicRepetitive
Code
Typically you start with a manually built application
You analyse it with respect to
Code that is always identical in applications of
that kind
Code that has the same structure/patterns in all
cases
And code that is completely individual to
the application
Model-Driven Development – State of the Art 28
The MDD Blueprint
Applikations-Modell
Applikations-Modell
HandcraftedCode
HandcraftedCode
Code of Application orReference Implementation
analyse separate
Platform
IndividualCode
ApplicationModel
DSL
Trans-formations
uses creates
GenericCode
IndividualCode
SchematicRepetitive
Code
SchematicRepetitive
Code
The generic, identical code becomes the platform
Application Models describe the repetitive aspects in an
abstract & concise way using a Domain-Specific Language
Transformations create the repetitive code from the application models
15
Model-Driven Development – State of the Art 29
A UML based Ontology for MDD
• Isn‘t the OMG/MDA terminology sufficient ?–Useful as a basis, but perspectives of
domain engineering, product lines & software system families missing orweak
• What is an Ontology ?–Representation of knowlegde: definition
of concepts & their relationships• Why UML for that ?
–Provides a popular & standardizednotation for concepts (classes) & typicalcategories of relations (Association, Composition, InstanceOf, Realization, Uses, …)
–Allows for definition of specificcategories 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)
16
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 and respects the static semantics–Uses the concrete syntax of the DSL–And gets its meaning from the DSLs semantics
17
Model-Driven Development – State of the Art 33
Platform
Domain
0..*based on
Plattformsupports
<<abstract>>Building
Block
Framework Component AspectLibraryMiddleware
{open}
• A platform supports a domain Platforms can be cascaded, i.e., they arebased 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 and tests, of course
Model-Driven Development – State of the Art 34
Transformation• The finished product
contains the platform• It consists of generated
artifacts, as as well as non-generated, i.e., manually implementedartifacts
• Both of these types of artifacts know about & rely on the platform
18
Model-Driven Development – State of the Art 35
• 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 relieson the metamodel on which this formal model is built
Transformation
Model-Driven Development – State of the Art 36
• 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
Transformation
19
Model-Driven Development – State of the Art 37
• 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
Transformation
Model-Driven Development – State of the Art 38
Domain Architecture• A domain architecture comprises
– the DSL(s), – the platform–as well as all the transformations needed to transform models built using
the DSLs into code that runs on the platform
20
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
<<MDA>>MOF
MetaMeta Model
<<MDA>>Action
Semantics
AbstractSyntax Semantics Model2Model
Transformation
<<MDA>>QVT
ConcreteSyntax
GraficalSyntax
<<MDA>>UML Profile <<MDA>>
OCLStatic
Semantics
FormalModel
specified onbasis of
<<MDA>>PIM
<<MDA>>PSM
<<MDA>>Executable
Model
refines
Platformspecific to
runs on
<<MDA>>PDM
describesrelevant
concepts of
The Meta Object Facility is the OMG’s Meta MetaModel XMI is based on
top of it, as is UML
Action Semantics can be used to add additional
semantics & behaviourto models
Query/Views/Trans-formations is the
OMG’s M2M standard
OCL can also add semantics by defining
constraints
21
Model-Driven Development – State of the Art 41
MDA Terms
<<MDA>>MOF
MetaMeta Model
<<MDA>>Action
Semantics
AbstractSyntax Semantics Model2Model
Transformation
<<MDA>>QVT
ConcreteSyntax
GraficalSyntax
<<MDA>>UML Profile <<MDA>>
OCLStatic
Semantics
FormalModel
specified onbasis of
<<MDA>>PIM
<<MDA>>PSM
<<MDA>>Executable
Model
refines
Platformspecific to
runs on
<<MDA>>PDM
describesrelevant
concepts of
MDA models are typically (not mandatorily) based
on UML + Profiles
OMG distinguishes between platform
specific & platform independent models
Platform Description models are basically metamodels of the
platform
42
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of Terms
Architecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
22
Model-Driven Development – State of the Art 43
Architecture – Centric (AC) Model – DrivenDevelopment (MDD) Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The domain is architecturally motivatede.g., architecture for business software
or component infrastructure for embedded systems
Model-Driven Development – State of the Art 44
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The products to be created are usually complete applications,
not single components
23
Model-Driven Development – State of the Art 45
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
From the black box view, usually only single-step model-to-platform transformations exists
However, these can be internally (white box) structured, serving modularization purposes for sequential execution of several transformations
Model-Driven Development – State of the Art 46
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The DSL’s metamodel therefore contains architectural conceptsthat are as abstract as possible i.e., “component” & not “EJB 3 stateless session bean”
24
Model-Driven Development – State of the Art 47
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The DSL is also called design language
Often, UML profiles are used here, sometimes combined with additional textual specifications
Model-Driven Development – State of the Art 48
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
Typically, the model-to-platform transformation is a template that shows great similarity to the generated code & thus can easily be extracted from a reference implementation
25
Model-Driven Development – State of the Art 49
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The transformation does not aim at creating the complete application, but merely an implementation frameworkcontaining the architectural infrastructure code (skeleton)
Model-Driven Development – State of the Art 50
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The non-generated, implementation code (“business logic”) is manually implemented in the target language (code snippet)
For this purpose, the generated skeleton may contain protected regions for supplementing the application logic that will persist after iterative regeneration
Alternatively, generated & non-generated code is integrated using suitable design patterns
26
Model-Driven Development – State of the Art 51
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
During code generation, a recipes file is created by the generator The
file is then read by the IDE
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
27
Model-Driven Development – State of the Art 53
Recipe F/W for Integrating Manually Written Code
The IDE evaluates the checks in the recipe file & points to problems in the
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 54
Recipe F/W for Integrating Manually Written Code
Checks that are ok are rendered in green (or
can be filtered out)
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
28
Model-Driven Development – State of the Art 55
Recipe F/W for Integrating Manually Written Code
You can get more detailed information
on the checks executed
• 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 56
Recipe F/W for Integrating Manually Written Code
And a nice explaingtext that tells
developers what to do to fix the problem
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
29
Model-Driven Development – State of the Art 57
Recipe F/W for Integrating Manually Written Code
You can reevaluatechecks at any time
• 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 58
Recipe F/W for Integrating Manually Written Code
A “quick fix” buttonwill be added till final
release of oAW 4
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
30
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
31
Model-Driven Development – State of the Art 61
Example for “Business Level” DSL
SomePlace: Generator
G11: GenerationElement
20KV: Bus
link11
T11: Transformer
link12
220KV: Buslink13 end11
link14
SomeOtherPlace: SwitchingStation
end21
transmissionLine1
B21-220KV: Bus
link21
B22-10KV: Bus
T21: Transformer
link22
link23
link24
end22
Model-Driven Development – State of the Art 62
DYI vs 3rd Party Cartridges
ConceptionalArchitecture
Model
Generator
Cartridge Specificfor the
Conceptionalarchitecture
Model suitable for C2
Model suitablefor C3
Off-the-ShelfCartridge C2
Off-the-ShelfCartridge C3
Code generated by C2
Code generated by C3
Project SpecificCode
Manually written code
• 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)?
• 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-the-
shelf cartridges on the lower levels
32
63
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Model-Driven Development – State of the Art 64
•Present solutionsto common software problemsarising within a certain context
Overview of Patterns
•Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs
The Proxy Pattern
1 1Proxy
service
Service
service
AbstractService
service
Client
•Help resolve key software design forces
•Flexibility•Extensibility•Dependability•Predictability•Scalability•Efficiency
•Generally codify expert knowledge of design strategies, constraints & “best practices”
MDD tools codify & automate many (but by no means all) aspects of patterns
33
Model-Driven Development – State of the Art 65
Overview of Pattern LanguagesMotivation•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
Pattern languages are crucial for domain-specific languages (DSLs)
Model-Driven Development – State of the Art 66
Overview of FrameworksFramework Characteristics
Application-specific functionality
•Frameworks exhibit “inversion of control” at runtime via callbacks
Networking Database
GUI
•Frameworks provide integrated domain-specific structures & functionality
Mission Computing E-commerce
ScientificVisualization
•Frameworks are “semi-complete” applications
34
Model-Driven Development – State of the Art 67
Benefits of Frameworks
CommunicationServices
OS-AccessLayer
BrokerComponentRepository
ComponentConfigurator
Proxy Proxy
Broker
AdminControllers
AdminViews
AdminClientPicking
ControllersPickingViews
PickingClient
Broker
LoggingHandlerThreadPool
*
Reactor
Broker
Scheduler/ActivationList
ServiceRequest
ServiceRequest
ServiceRequest
WarehouseRepHalfX
DistributionInfrastructure
ConcurrencyInfrastructure
Thin UI Clients
• Design reuse• e.g., by guiding application
developers through the steps necessary to ensure successful creation & deployment of software
Model-Driven Development – State of the Art 68
package orgapachetomcatsession;
import orgapachetomcatcore*;import orgapachetomcatutilStringManager;import javaio*;import javanet*;import javautil*;import javaxservlet*;import 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);
}
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
35
Model-Driven Development – State of the Art 69
• 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
Benefits of Frameworks
Model-Driven Development – State of the Art 70
Summary of Pattern, Framework, & MDD SynergiesThese technologies codify expertise of domain experts & developers
• Patterns codify expertise in the form of reusable architecture design themes & styles, which can be reused event when algorithms, components implementations, or frameworks cannot
• Frameworks codify expertise in the form of reusable algorithms, component implementations, & extensible architectures
Application-specific functionality
Acceptor Connecto
rComponentConfigurator
Stream
Reactor Proactor
Task
There are now powerful feedback loops advancing these technologies
• MDD tools codify expertise by automating key aspects of pattern languages & providing developers with domain-specific modeling languages to access the powerful (& complex) capabilities of frameworks
Model
Application Code
Domain SpecificFramework
PlatformFrameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application Code
Domain SpecificFramework
PlatformFrameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application Code
Domain SpecificFramework
PlatformFrameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application Code
Domain SpecificFramework
PlatformFrameworks
Model
Generated CodeFramework
Pattern Language
Platform
36
71
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDD
How Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Model-Driven Development – State of the Art 72
Motivation 1
• Why taking a look at compilerconstruction?
• The core concepts of MDD generators arethe same as in compiler construction
–Formal Languages–Transformation of formal artifacts on a
higher abstraction level into formal artifacts on lower abstraction level(i.e., raising the abstraction level forprogramming)
–Modularity• Compiler construction is a domain, which
is well understood. We should be able to harvest some of the experiences madethere: Generators ARE Compilers
C++ Compiler
Internal Rep.
PPCOpt.
MIPSOpt.
88KOpt.
PPC MIPS 88K
C++ Program
37
Model-Driven Development – State of the Art 73
Motivation 2
• So compiler construction might givehints for MDD/A tool developers, butwhy should “users” care about it?
• Construction criteria that have provengood, are selection criteria too
• We can adopt a clear & unambiguousterminology
• In the context of MDD we needopenness
–Adopting or creating own DSLs–Adopting or creating own
TransformationsThat means, the user (i.e., architect) is
involved & confronted to someextent with the inner structure of the compile process
Platform
Frameworks
Application Code
Model
Platform
Generated Code
Model
Platform
Frameworks
Application Code
Model
Platform
Generated Code
Model
Platform
Frameworks
Application Code
Model
Platform
Generated Code
Model
Platform
Frameworks
Application Code
Model
Platform
Generated Code
Model
Model-Driven Development – State of the Art 74
Compiler Construction Blue Print
Program Text
(e.g., C++ Source-Code)
Compiler-Frontend
= Parser
Programming Language
Concrete Syntax
(e.g., C++ or Java)
Abstract Syntax
Compiler-Backend
= Codegenerator
Artifacts Meta-ArtifactsWorkflow
Static Semantics
(e.g., Declaration of Variables)
Abstract Syntax Tree
Generated Code
Optimizer
Checker
Dynamic Semantics
Runtime System
38
Model-Driven Development – State of the Art 75
Core Concept: Abstract SyntaxResponsibilities of Abstract Syntax
• Modularity of the compiler: Interface between Frontend & Backend
• Neutralisation of different Concrete Syntaxes (e.g., C and PASCAL)
• Pluggability for different backends (e.g., codegen for Intel/PC or Mainframe)
• Interface for modification of program structure (e.g., optimization)
Abstract Syntax
Parser 1Parser 2
Codegen 1Codegen 2
Modification
Model-Driven Development – State of the Art 76
Mapping of ConceptsModel-Driven Software Development(general concepts)
Compiler Construction(specific concepts)
Programming LanguageProgram (Source-Code)Concrete textual SyntaxAbstract SyntaxStatic SemanticsProgram Editor ParserCode GenerationOptimizationRuntime System
A kind of Modeling LanguageA kind of ModelA kind of DSLPart of Meta-ModelModeling-ConstraintsA kind of DSL EditorModel-ReaderModel 2 Code TransformationA kind of Model-2-Model TransformationPlatform
The plain compiler view on MDD is quite “code-generation centric” & seems to focus textual languages, but in fact MDD takes advantage fromgeneralization & further abstraction of those concepts It‘s an evolution
39
Model-Driven Development – State of the Art 77
MDD from Another PerspectiveSo the task of creating a domainarchitecture from the perspective of compiler construction means:
–Define a formal language withconcrete & abstract syntax & staticsemantics (DSL)
–Implement a Parser for the DSL
–Implement the static semantics
–Implement Modifiers orTransformations based on the abstract syntax (M2M-Transformations)
–Implement a runtime system(Platform)
–Implement one or more backends(M2C-Transformations)
DSL
DSL Parser
Codegenerator Transformations
Abstract Representation
Generated Code
M2M-Transformation
Static SemanticChecker
Runtime System
Model-Driven Development – State of the Art 78
How MDD Tools Can HelpMany of these tasks are supported bygeneric tools or frameworks, eg:
–Generic DSLs with extensionmechanisms (e.g., UML)
–Parser- resp DSL-Editor-Generators
–AS-Modeling & Generation (Metamodel Generators)
–Constraint-Languages (e.g., OCL)
–M2M-Transformation-Languages & Implementations/Interpreters
–M2C-Transformation-Languages & Implementations/Interpreters
–Reusable Meta-Artifacts(Cartridges)
MatlabCode-GenMatlab
Code-Gen
Domain-Specific Modeling Languages
ArtifactGenerator
if (inactiveInterval != -1) {int thisInterval =
(int)(SystemcurrentTimeMillis() -lastAccessed) / 1000;
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() {
return (thislastAccessedTime);
}
thislastAccessedTime = time;
ConfigurationSpecification Analysis Tool
Code
40
Model-Driven Development – State of the Art 79
MDD Tool Blueprint
DSL-Editor Generator
Generic DSL-Editor
Tool Support (Open Compiler) Architect‘s Input
Parser Generator
Template Engine
M2M Engine
Metamodel Generator
Constraint Engine
DSL-Model
DSL-Profile
DSL-Grammar Spec
Metamodel
Constraints
M2M Transformations
M2C Transformations
MDSD-Platform
Formal
Language and
Parser
AS
Static Sematics
Runtime System
Backend
Model-Driven Development – State of the Art 80
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
41
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-orientedimplementation (Meta Classes, Associations …)
– Unmaintainable switch/case statements on syntax element types canbe avoided in transformations by using polymorphism and 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 compilerare irrelevant
– Note that this does NOT hold in the MDD-context, sincethe AS/MM is plugged into the frameworkSo 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 oAWModel expressed via Concrete Syntax
(e.g., UML-Profile)
MetaModel / Abstract Syntax
(oAW: Implementation in Java)
Check: Every „EntityObject“ must
have at least one „key“-Attribute
Responsibilities (Object-Oriented)
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 the oAW-Templatelanguage (M2C) They are implemented in or decorated on the respective Meta-Classes
42
Model-Driven Development – State of the Art 83
openArchitectureWare – BlueprintDomain Architecture 1 ApplicationoAW - Workflow and Information Flow
M2M-Transformation
Model
Hand written Code
Generated Code
Metamodel Implementation
M2M-Transformation-Implementation
Domain Architecture n
M2C-Transformation-Implementation
DSL
DSL
Instantiated Metamodel (1)
<<instanceof>>Constraints
Metamodel Implementation
Constraints
Instantiated Metamodel (n)
<<instanceof>>
<<relies on>>
<<integra tes into>>
Platform nPlatform n
<<uses>>
[error]
[error]
M2C Transformation(Template-Engine)
Constraint Check
Constraint Check
Model Reader /Parser
84
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler Construction
Model-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
43
Model-Driven Development – State of the Art 85
Why You Need M2M
MDSD-Infrastructure
Input Models
Output Model
Code Generator forArchitectural MDSD Infrastructure
Code for Target Platform
Programming Model (based on Arch-MM)
M2M/CodeGenerator for SD 1
Model for Subdomain 1
M2M/CodeGenerator for SD 2
Model for Subdomain 2
...
...
...
...
...
...
• As explained before, cascading MDD requires model-to-model transformations
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 dataamong transformations
• Example: Multi-Step transformation from a banking-specific DSL to Java via J2EE
Banking-Metamodell
Bank /OO OO Metamodel
J2EE MetamodelProcess
MetamodelBank /Prozess
OO/J2EE
Process/J2EE
WLSMetamodel
WebSphereMetamodel
J2EE/B
EA
J2EE/IB
M
JavaMetamodel
BEA/Java
IBM/Java
44
Model-Driven Development – State of the Art 87
Modular, Automated Transformations II• Example cont’d:
Now consider a Call-Center application; only the first step needs to be adapted
• If both should be transformed to NET, only the backend needs to be exchanged
CallCenterMetamodel
CC /OO OO Metamodel
ProcessMetamodel
CC /Prozess
...
...
...
OO Metamodel
ProcessMetamodel
OO/.NET
Prozess/.NET
.NET Metamodel .NET/C# C# Metamodel
Model-Driven Development – State of the Art 88
Transforming “in the Tool”
openArchitectureWareModel(UML)
Model(XMI)
ParserModel
(Object Graph)
ModelTrans-former
Modified Model(Object Graph)
export
Generated Code
CodeGenerator
(may be repeated)
Developer builds model using for example a UML
tool
45
Model-Driven Development – State of the Art 89
openArchitectureWareModel(UML)
Model(XMI)
ParserModel
(Object Graph)
ModelTrans-former
Modified Model(Object Graph)
export
Generated Code
CodeGenerator
(may be repeated)
The XMI produced by the UML tool is parsedby the generator tool –& an AST is created
in memory
Transforming “in the Tool”
Model-Driven Development – State of the Art 90
openArchitectureWareModel(UML)
Model(XMI)
ParserModel
(Object Graph)
ModelTrans-former
Modified Model(Object Graph)
export
Generated Code
CodeGenerator
(may be repeated)Inside the generator,model-to-model
transformations are used to build new or modified ASTs
The intermediate ASTscannot be modifiedinteractively by the
developer
Transforming “in the Tool”
46
Model-Driven Development – State of the Art 91
openArchitectureWareModel(UML)
Model(XMI)
ParserModel
(Object Graph)
ModelTrans-former
Modified Model(Object Graph)
export
Generated Code
CodeGenerator
(may be repeated)
In a final step, code is generated from
the AST
Transforming “in the Tool”
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 well by very 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”
47
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 I have built by now have been constructed with Java code– If the metaclasses have a well-designed API (repository API) then
this „procedural transformations“ do indeed work well
• However, more & more dedicated model transformation languagesbecome available:– ATL, MOLA, Wombat (oAW), etc
• The QVT standard isbecoming a reality Itwill be finalized bythe end of 2006
• QVT actually comprises three languages:
RelationsLanguage
CoreLanguage
definedIn terms of
Black BoxMappings
OperationMappingsLanguage
Java
.NET
48
Model-Driven Development – State of the Art 95
Model–to–Model Transformations: QVT Relationaltop relation EntityKeyToTableKey {
checkonly domain alma entity:Entity {key = entityKeyField:Field {}
};
enforce domain db table:Table {key = tableKey:Key {}
};
when {EntityToTable(entity, table);
}
where {KeyRecordToKeyColumns(entityKeyField, table);
}
}
relation PhysicalQuantityTypeToColumn {
pqName, pqUnit, fieldName : String;
checkonly domain alma field:Field {name = fieldName,type = pq:PhysicalQuantityType {name = pqName,units = 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 { selfparts->map part2columns(result, dpTableName + ‘_’); }
}
query PrimitiveType::convertPrimitiveType() : String =
if selfname = "int" then 'INTEGER‘else if selfname = "float" then 'FLOAT‘else if selfname = "long" then 'BIGINT‘else 'DOUBLE'
endif endif endif;
49
Model-Driven Development – State of the Art 97
Transformations in Java: ExamplePerson
name: StringfirstName : StringbirthDate: Date
age(): int
PersonBean
name: StringfirstName : StringbirthDate: Date
ejbActivate()/ejbPassivate()ejbLoad()/ejbStore()ejbCreate()/ejbDestroy()age()getName()/setName()getFirstName()/setFirstName()getBirthDate()/setBirthDate()
<<interface>>
EntityBean<<interface>>
PersonIFage()getName()/setName()getFirstName()/setFirstName()getBirthDate()/setBirthDate()
<<logically implements>>
<<interface>>
PersonHomeIFcreate()
Sour
ce
Targ
et
Personname: StringfirstName : StringbirthDate: Date
age(): int
Sour
ce
Targ
et Person
name: StringfirstName : StringbirthDate: Date
age(): int
<<EJB::EntityBean>>
{transactions=tx.cmt, persistence=persistence.bmp.hibernate, interface=interfaces.remoteOnly}
Model-Driven Development – State of the Art 98
Transformations in Java: Example Transformation
Model createEJBModel( Model source ) {Model target = new Model();foreach c:Class in sourceclasses {
ImplementationClass implClass = new ImplementationClass();implClasssetName( cgetName()+"Bean" );targetaddClass( implClass ); Dependenciesdefine( implClass, c );RemoteInterface ri = new RemoteInterface ();// set name & add it to target modelHomeInterface hi = new HomeInterface ();// set name & add it to target modelforeach o:Operation in coperations {
// bidirectional, because of generated APIriaddOperation( new Operation( oclone() ) );implClassaddOperation( new Operation( oclone() ) );
}}return target;
}
• With good metaclasses, this works acceptably today
50
Model-Driven Development – State of the Art 99
Graphical M2M: UMLX
class:UML::Class
*
1
AssociationEnd
Class
in component:CM::Component
out
otherSideEnd:UML::AssociationEnd
roleName = $nnavigable = true
assocAttributeUML::Attribute
name = $n
thisSideEnd:UML::AssociationEnd
assoc:UML::Association
<<UML::Class>>Vehicle
plate : Stringtype: String
Personname : String
drive() : void
driver
<<CM::Component>>Person
name : String
<<CM::Component>>Vehicle
plate : Stringtype: Stringdriver : Person
drive() : void
Model-Driven Development – State of the Art 100
Many Means of Transformations• Today, many means of transformations are used:
• Plain old Java• Eclipse GMT ATL• IBM MTF
• A paper by Czarnecki/Helsen gives a very good overview:www.swen.uwaterloo.ca/~kczarnec/ECE750T7/czarnecki_helsen.pdf
• ISIS GReAT• Several partial QVT implementations• UMLX
51
101
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model Transformations
An Architectural Process –A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Model-Driven Development – State of the Art 102
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
52
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 behandled by a small team, before the architecture is rolled out to the team as a whole
• We want to build an enterprise systemthat contains various subsystems such as customer management, billing & catalogs
• In addition to managing the data using a database, forms & the like, we also have to manage the associated long-runningbusiness processes
• We will look at how we can attack thisproblem below
53
Model-Driven Development – State of the Art 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 businessprocesses
– 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
54
Model-Driven Development – State of the Art 107
• 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 businessprocesses
– 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
Technology–Independent Architecture
Use the well-known architectural styles & patternshere Typically these are best practices for architectingcertain kinds of systems independent of a particulartechnology They provide a reasonable starting point fordefining (aspects of) your systems's architecture
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
55
Model-Driven Development – State of the Art 109
Programming Model
• The programming model uses a simple DependencyInjection approach à la Spring to define componentdependencies on an interface level
• An external XML file takes care of the configuration of 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 how we use Java 5 annotations
• 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
public @component class ExampleComponentimplements HelloWorld { // provides HelloWorld
private IConsole console;
public @resource void setConsole( IConsole c ) { thisconsole = c; // setter for console
} // component
public void sayHello( String s ) { consolewrite( s );
}
}
56
Model-Driven Development – State of the Art 111
Programming Model
public @process class SomeProcessimplements ISomeProcessTrigger {
private IHelloWorld resource;
public @resource void setResource( IHelloWorld w ) {thisresource = 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 );// …resourcesayHello( "hello" );
}
}
• Process Component Implementation Example
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
57
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 a no advanced load balancing & transaction policies are required
• Once this becomes necessary, we will use Stateless Session EJBsThe necessary code to wrap our components inside beans is easy to write
<beans><bean id="proc" class="somePackageSomeProcess">
<property name="resource"><ref bean="hello"/></property></bean><bean id="hello" class="somePackageExampleComponent">
<property name="console"><ref bean="cons"/></property></bean><bean id="cons" class="someframeworkStdOutConsole">
</beans>
Model-Driven Development – State of the Art 114
Technology Mapping
• Persistence for the process instances – like any other persistent data – is managed using Hibernate
–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 usagehere, not earlier
But keep in mind: First solve the problem Then look for a standard Not vice versa
Use technology-specific Design Patterns here
Use them as the basis for the TECHNOLOGY MAPPING
Web Services,a WSDL file is
generated
Hibernateused for database
access
58
Model-Driven Development – State of the Art 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
59
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 layerwas 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
60
Model-Driven Development – State of the Art 119
• 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 layerwas 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
Vertical Prototype
Work on performance improvements here, not earlier
It is bad practice to optimize design for performance from the beginning, since this often destroys good architectural practice
In certain domains, there are patterns to realize certain QoS properties (such as stateless design for large-scale business systems) You shouldn'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
61
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: Dynamic
installation/de-installation of components, – & 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
62
Model-Driven Development – State of the Art 123
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
Components can provide & require
interfaces
Model-Driven Development – State of the Art 124
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
Interfaces have operations – they’re
defined as usual
63
Model-Driven Development – State of the Art 125
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
Process Components are special kinds of
components
Model-Driven Development – State of the Art 126
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
A process component’s process is described using a
state machine
64
Model-Driven Development – State of the Art 127
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
And the triggers are special kinds
of operations
Model-Driven Development – State of the Art 128
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
A container runs a number of components
65
Model-Driven Development – State of the Art 129
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
Constraints are used to define
the semantics of versioning
Model-Driven Development – State of the Art 130
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
66
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 upthose 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
67
Model-Driven Development – State of the Art 133
DSL–based Programming Model
• We use DSLs for components, interfaces & dependenciesDescribing 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
• 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
<<component>>StdOutConsole
<<component>>HelloWorld
IHelloWorldIConole
{persistent}
<<component>>SomeComponent
<<generate>><<man-code>>
SomeCompo-nent.java
<<interface>>SomeInterface
<<gen-code>>Some-
Interface.java
<<generate>>
<<gen-code>>Some
ComponentBase.java
68
Model-Driven Development – State of the Art 135
DSL–based Programming 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>
<<component>>AddressManager
<<interface>>AddressStore
addOrUpdateContact( p: Person) : voidaddAddress( p: Person, a: Address) : voidgetAddresses( p: Person ) : Address[]
<<entity>>Person
name: StringfirstName: String
<<valuetype>>Address
street: Stringzip: StringCity: String
0..n
<<component>>CustomerManager
address-Store
<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>
Type Model
Composition Model System Model
person
Type model defines components (which are
instantiatable types), interfaces & data types, as well as the depdendencies
among them
Model-Driven Development – State of the Art 136
DSL–based Programming 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>
<<component>>AddressManager
<<interface>>AddressStore
addOrUpdateContact( p: Person) : voidaddAddress( p: Person, a: Address) : voidgetAddresses( p: Person ) : Address[]
<<entity>>Person
name: StringfirstName: String
<<valuetype>>Address
street: Stringzip: StringCity: String
0..n
<<component>>CustomerManager
address-Store
<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>
Type Model
Composition Model System Model
person
Composition Model defines named configurations of
component instances & the wiring among them
69
Model-Driven Development – State of the Art 137
DSL–based Programming 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>
<<component>>AddressManager
<<interface>>AddressStore
addOrUpdateContact( p: Person) : voidaddAddress( p: Person, a: Address) : voidgetAddresses( p: Person ) : Address[]
<<entity>>Person
name: StringfirstName: String
<<valuetype>>Address
street: Stringzip: StringCity: String
0..n
<<component>>CustomerManager
address-Store
<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>
Type Model
Composition Model System Model
person
System model deploysconfigurations onto systems& nodes Nodes define the
kind of system they represent
Model-Driven Development – State of the Art 138
DSL–based Programming Model
<<gen-code>>SomeEntity.java
<<entity>>SomeEntity
<<generate>>
<<interface>>SomeEntityDAO
<<transform>><<generate>> <<gen-code>>
SomeEntity-DAO.java
<<component>>SomeEntityDAO
<<transform>><<generate>> <<gen-code>>
SomeEntity-DAOBase
.java
<<gen-code>>SomeEntity-
DAO.java
<<generate>>
• 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
70
Model-Driven Development – State of the Art 139
DSL–based Programming Model
<<generate>>
<<gen-code>>AProcess-Data.java
<<proc-component>>AProcess
<<gen-code>>AProcessBase
.java
<<gen-code>>AProcessProcBase.java
<<trigger-interface>>AProcessInterface
*
1
sm AProcess
<<entity>>AProcessData
<<tra
nsfo
rm>>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<tra
nsfo
rm>>
guard operations... (abstract)action methods... (abstract)
<<man-code>>AProcess.java
• We also use cascading for the Process ComponentsFirst, developers
model the process component itself
Model-Driven Development – State of the Art 140
DSL–based Programming Model
<<generate>>
<<gen-code>>AProcess-Data.java
<<proc-component>>AProcess
<<gen-code>>AProcessBase
.java
<<gen-code>>AProcessProcBase.java
<<trigger-interface>>AProcessInterface
*
1
sm AProcess
<<entity>>AProcessData
<<tra
nsfo
rm>>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<tra
nsfo
rm>>
guard operations... (abstract)action methods... (abstract)
<<man-code>>AProcess.java
They also model a trigger interface for
that component with no operations
• We also use cascading for the Process Components
71
Model-Driven Development – State of the Art 141
DSL–based Programming Model
<<generate>>
<<gen-code>>AProcess-Data.java
<<proc-component>>AProcess
<<gen-code>>AProcessBase
.java
<<gen-code>>AProcessProcBase.java
<<trigger-interface>>AProcessInterface
*
1
sm AProcess
<<entity>>AProcessData
<<tra
nsfo
rm>>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<tra
nsfo
rm>>
guard operations... (abstract)action methods... (abstract)
<<man-code>>AProcess.java
Developers then model the state machine for that process
component & associate it with the process component
• We also use cascading for the Process Components
Model-Driven Development – State of the Art 142
DSL–based Programming Model
<<generate>>
<<gen-code>>AProcess-Data.java
<<proc-component>>AProcess
<<gen-code>>AProcessBase
.java
<<gen-code>>AProcessProcBase.java
<<trigger-interface>>AProcessInterface
*
1
sm AProcess
<<entity>>AProcessData
<<tra
nsfo
rm>>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<tra
nsfo
rm>>
guard operations... (abstract)action methods... (abstract)
<<man-code>>AProcess.java
Using M2M, the operations are derived from the triggers used
in the state machine
• We also use cascading for the Process Components
72
Model-Driven Development – State of the Art 143
DSL–based Programming Model
<<generate>>
<<gen-code>>AProcess-Data.java
<<proc-component>>AProcess
<<gen-code>>AProcessBase
.java
<<gen-code>>AProcessProcBase.java
<<trigger-interface>>AProcessInterface
*
1
sm AProcess
<<entity>>AProcessData
<<tra
nsfo
rm>>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<tra
nsfo
rm>>
guard operations... (abstract)action methods... (abstract)
<<man-code>>AProcess.java
Using M2M, the Entitythat stores process
instances persistently is derived from the state
machine; then the Entity transformations kick in –
see before
• We also use cascading for the Process Components
Model-Driven Development – State of the Art 144
DSL–based Programming Model
<<generate>>
<<gen-code>>AProcess-Data.java
<<proc-component>>AProcess
<<gen-code>>AProcessBase
.java
<<gen-code>>AProcessProcBase.java
<<trigger-interface>>AProcessInterface
*
1
sm AProcess
<<entity>>AProcessData
<<tra
nsfo
rm>>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<tra
nsfo
rm>>
guard operations... (abstract)action methods... (abstract)
<<man-code>>AProcess.java
As usual, from components we
generate skeleton base classes
• We also use cascading for the Process Components
73
Model-Driven Development – State of the Art 145
DSL–based Programming Model
<<generate>>
<<gen-code>>AProcess-Data.java
<<proc-component>>AProcess
<<gen-code>>AProcessBase
.java
<<gen-code>>AProcessProcBase.java
<<trigger-interface>>AProcessInterface
*
1
sm AProcess
<<entity>>AProcessData
<<tra
nsfo
rm>>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<tra
nsfo
rm>>
guard operations... (abstract)action methods... (abstract)
<<man-code>>AProcess.java
Instead of letting developers implement the business logic manually, we generate an “Intermediate” class that contains the executable, & persistence-aware state
machine
• We also use cascading for the Process Components
Model-Driven Development – State of the Art 146
DSL–based Programming Model
<<generate>>
<<gen-code>>AProcess-Data.java
<<proc-component>>AProcess
<<gen-code>>AProcessBase
.java
<<gen-code>>AProcessProcBase.java
<<trigger-interface>>AProcessInterface
*
1
sm AProcess
<<entity>>AProcessData
<<tra
nsfo
rm>>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<tra
nsfo
rm>>
guard operations... (abstract)action methods... (abstract)
<<man-code>>AProcess.java
Finally, developers extend that intermediate
class & implement guard and action
operations manually by overriding abstract
methods
• We also use cascading for the Process Components
74
Model-Driven Development – State of the Art 147
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
• It is checked 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 notdescribed in the model
75
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)
<<component>>SomeCompV2
<<newVersionOf>><<interface>>
AnotherInterface
<<vo>>ValueObject
<<component>>SomeCompV3
<<newVersionOf>>
<<interface>>SomeInterfaceV3
soSomething(int, ValueObjectV2)anAdditionalOperation()
<<newVersionOf>>
<<vo>>ValueObjectV3
<<newVersionOf>>
150
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
76
Model-Driven Development – State of the Art 151
MDD Tool Developers (Metamodelers)
Application Developers (Modelers)
Generic Modeling Environment (GME)
GME is open-source: www.isis.vanderbilt.edu/Projects/gme/default.htm
“Write Code That Writes Code That Writes Code!”
Decorator Decorator
GModel GMeta
CORE
MetamodelXML
Paradigm Definition
Storage Options… DB #nDB #1 XML …
UML / OCL
COM
COMCOM
XML
XML
ODBC
ConstraintManagerBrowser
Translator(s)Add-On(s)
GME Editor
GME Architecture
Supports “correct-by-construction” of software systems
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
77
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•e.g., 3rd generation code, simulations, deployment descriptions & configurations
<connection> <name>compressionQosPredictor_qosLevels</name> <internalEndpoint> <portName>qosLevels</portName> <instance xmi:idref="CompressionQosPredictor_F3C2CBE0-B2CE-46CC-B446-F64D91B44E56"/> </internalEndpoint> <internalEndpoint> <portName>compressionQosPredictor</portName> <instance xmi:idref="LocalResourceManagerComponent_7EF8B77A-F5EA-4D1A-942E-13AE7CFED30A"/> </internalEndpoint> </connection> <connection> <name>scalingQosPredictor_qosLevels</name> <internalEndpoint> <portName>qosLevels</portName> <instance xmi:idref="ScaleQosPredictor_F3024A4F-F6E8-4B9A-BD56-A2E802C33E32"/> </internalEndpoint> <internalEndpoint> <portName>scalingQosPredictor</portName> <instance xmi:idref="LocalResourceManagerComponent_7EF8B77A-F5EA-4D1A-942E-13AE7CFED30A"/> </internalEndpoint> </connection>
imainccur
out
CropQosket[ CropQosket ]
qos
CroppingQosPredictor[ CroppingQosPredictor ]
polresinccomscacro
imaoutcroscacom
difcpu
LocalResourceManagerComponent[ LocalResourceManagerComponent ]
imainccur
out
CompressQosket[ CompressQosket ]
imasen out
Sender[ Sender ]
qos
CompressionQosPredictor[ CompressionQosPredictor ]
qos
ScaleQosPredictor[ ScaleQosPredictor ]
imainccur
out
ScaleQosket[ ScaleQosket ]
cpu
CPUBrokerComponent[ CPUBrokerComponent ]
inc out
LocalReceiver[ LocalReceiver ]
PolicyChangeEvt
ResourceAllocationEvt
ImageGenerationEvt
imainccur
out
DiffServQosket[ Dif fServQosket ]
delegatesTo
delegatesTo
emit
invoke
invoke
invokeinvoke
invoke
emit emit emitinvoke
invokeinvoke
emit
delegatesTo
Model-Driven Development – State of the Art 154
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
78
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
79
Model-Driven Development – State of the Art 157
Applying GME to System Execution ModelingSystem Execution Modeling Workflow
1 2
34
1. Compose scenarios to exercise critical system paths/layers
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 158
Motivation: Service–Oriented Architectures
• Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols
Operating System & Communication Protocols
Hardware Devices
Applications
80
Model-Driven Development – State of the Art 159
Applications• Traditional methods of development have
been replaced by middleware layers to reuse architectures & code
• Viewed externally as Service-Oriented Architecture (SOA) Middleware
Operating System & Communication Protocols
Hardware Devices
Domain-Specific Services
Common Services
Distribution Middleware
Infrastructure Middleware
• Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols
Service-Oriented Architecture Middleware
Motivation: Service–Oriented Architectures
Model-Driven Development – State of the Art 160
Applications• Traditional methods of development have
been replaced by middleware layers to reuse architectures & code
• Viewed externally as Service-Oriented Architecture (SOA) Middleware
Operating System & Communication Protocols
Hardware Devices
Domain-Specific Services
Common Services
Distribution Middleware
Infrastructure Middleware
• Historically, distributed real-time & embedded (DRE) systems were built directly atop OS & protocols
Multi-layer Resource Manager (MLRM)
• e.g., DARPA Adaptive & Reflective Management System (ARMS) program’sMulti-layer Resource Manager (MLRM)
• MLRM leverages standards-based SOA middleware to manage computing & communication resources for shipboard computing environments
Motivation: Service–Oriented Architectures
81
Model-Driven Development – State of the Art 161
Applications
Domain-Specific Services
ARMS Multi–Layer Resource Manager (MLRM)• Domain-specific layered
architecture includes
–Top domain layercontains components that interact with the mission manager of TSCE
–Middle resource pool layer is an abstraction for a set of computer nodes managed by a pool manager
–Bottom resource layercontains the actual resource computing components
Model-Driven Development – State of the Art 162
Serialized Phasing is Common in Large-scale Systems
Application components developed after
infrastructure is mature
Development Timeline
Leve
l of A
bstr
actio
n
System infrastructure components
developed first
82
Model-Driven Development – State of the Art 163
Serialized Phasing is Common in Large-scale Systems
Development Timeline
Leve
l of A
bstr
actio
n
Integration Surprises!!!
System integration & testing
Finished development
Model-Driven Development – State of the Art 164
Complexities of Serialized Phasing
Development Timeline
Leve
l of A
bstr
actio
n
Still in development
Ready for testingComplexities• System infrastructure cannot be
tested adequately until applications are done
83
Model-Driven Development – State of the Art 165
Complexities of Serialized Phasing
Development Timeline
Leve
l of A
bstr
actio
n
Overall performance?
Complexities• System infrastructure cannot be
tested adequately until applications are done
• Entire system must be deployed & configured properly to meet QoS requirements
• Existing evaluation tools do not support “what if” evaluation
Model-Driven Development – State of the Art 166
Unresolved QoS Concerns with Serialized PhasingMeet QoS
requirements?
Key QoS concerns• Which D&C’s meet the QoS
requirements?
Development Timeline
Leve
l of A
bstr
actio
n
84
Model-Driven Development – State of the Art 167
Unresolved QoS Concerns with Serialized PhasingPerformance
metrics?
Key QoS concerns• Which D&C’s meet the QoS
requirements? • What is the worse/average/best
time for various workloads?
Development Timeline
Leve
l of A
bstr
actio
n
Model-Driven Development – State of the Art 168
Unresolved QoS Concerns with Serialized Phasing
It is hard to address these concerns in processes that use serialized phasing
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 QoS requirements are compromised?
System overload?
Development Timeline
Leve
l of A
bstr
actio
n
85
Model-Driven Development – State of the Art 169
Promising Solution Approach: New Generation of System Execution Modeling (SEM) Tools
Validate Design Rules• System will adhere to system
design specifications• “Correct-by-construction”
Validate Design Conformance• System will be properly
deployed & configured to resemble system design rules
Conduct “What If” Analysis• QoS concerns can be analyzed
prior to completing the entire system
• e.g., before system integration phase
The cycle is repeated when developing application & infrastructure components
Model-Driven Development – State of the Art 170
Our Approach: Emulate Application Behavior via QoS-enabled SOA Middleware & MDD Tools
While creating target infrastructure 1. Use a domain-specific language
(DSL) to define & validate infrastructure specifications & requirements
2. Use DSL to define & validate application specifications & requirements
3. Use middleware & MDD tools generate D&C metadata so system conforms to its specifications & requirements
4. Use analysis tools to evaluate & verify QoS performance
5. Redefine system D&C & repeat
Enable testing on target infrastructure early in development lifecycle
Component Workload Emulator (CoWorker) Utilization Test Suite Workflow (CUTS):
86
Model-Driven Development – State of the Art 171
Motivation for Using Emulation
• Can use actual target infrastructure
• Rather than imprecise simulations
• Many artifacts can be used directly in the final production system
• e.g., models of application component D&C plans
• Early feedback to developers, architects & systems engineers
• Instead of waiting for 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
• Define & validate system specification & requirements
• System Assembly & Packaging Tools• Compose implementation &
configuration information into deployable assemblies
• System Deployment Tools • Automates the deployment of system
components & assemblies to component servers
• Component Implementation Framework• Automates the implementation of
many system component features
PICML
www.dre.vanderbilt.edu/CIAO & www.dre.vanderbilt.edu/cosmic
& CIAO & DAnCE
CUTS
87
Model-Driven Development – State of the Art 173
ARMS MLRM Case Study: SLICE Scenario (1/2)
D&C & Performance Requirements• Critical path deadline is 350 ms
• main sensor to main effector through configuration
• Components in the critical paths must be deployed across all 3 hosts
• Main sensor & effector must be deployed on separate hosts
• Three hosts• One database is shared between
all hosts
sensor 2
sensor 1(main)
planner 1 planner 2
configuration
error recovery
effector 2
effector 1(main)
Component Interaction for SLICE Scenario
Model-Driven Development – State of the Art 174
sensor 2
planner 1 planner 2
configuration
error recovery effector 1(main)
effector 2
sensor 1(main)
350ms deadline
ARMS MLRM Case Study: SLICE Scenario (2/2)
Questions we would like to answer1. Can we meet the D&C &
performance requirements?
88
Model-Driven Development – State of the Art 175
sensor 2
planner 1 planner 2
configuration
error recovery effector 1(main)
effector 2
sensor 1(main)
ARMS MLRM Case Study: SLICE Scenario (2/2)
Questions we would like to answer1. Can we meet the D&C &
performance requirements?2. Are there multiple deployments that
meet the 350ms critical path deadline?• Which yields the most headroom
Model-Driven Development – State of the Art 176
sensor 2
planner 1 planner 2
configuration
error recovery effector 1(main)
effector 2
sensor 1(main)
Questions we would like to answer1. Can we meet the D&C &
performance requirements?2. Are there multiple deployments that
meet the 350ms critical path deadline?• Which yields the most headroom
3. Can we meet the 350ms critical path deadline with all component deployed on a single host?
ARMS MLRM Case Study: SLICE Scenario (2/2)
89
Model-Driven Development – State of the Art 177
Summary of CUTS Challenges
Emulate its behavior?
1. Evaluate QoS characteristics of DRE systems
2. Emulate QoS characteristics of DRE systems
PICML Model of SLICE Scenario
Model-Driven Development – State of the Art 178
1. Evaluate QoS characteristics of DRE systems
2. Emulate QoS characteristics of DRE systems
3. Non-intrusive benchmarking & evaluation
4. Simplifying component behavior specification
PICML Model of SLICE Scenario
Single-point of data collection?
Define behavior non-programmatically?
Summary of CUTS Challenges
90
Model-Driven Development – State of the Art 179
Customizing generic components?
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
PICML Model of SLICE Scenario
Summary of CUTS Challenges
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
5. Simplify component customization
6. Precise analysis of performance
PICML Model of SLICE Scenario
End-to-end execution
Time critical
Summary of CUTS Challenges
91
Model-Driven Development – State of the Art 181
Challenge 1: Evaluating QoS Characteristics of Enterprise DRE Systems Early in Life-cycle
Leve
l of A
bstr
actio
n
Development Timeline
• Context• In phase 2 of ARMS, MLRM is
implemented using Real-time CCM (via CIAO & DAnCE)
• In phase 1 of ARMS, QoS evaluation was not done until integration
–Prolonged project development
• Software components & challenges are similar in both phases
Model-Driven Development – State of the Art 182
Challenge 1: Evaluating QoS Characteristics of Enterprise DRE Systems Early in Life-cycle
Context• In phase 2 of ARMS, MLRM is
implemented using Real-time CCM (via CIAO & DAnCE)
• In phase 1 of ARMS, QoS evaluation was not done until integration
–Prolonged project development
• Software components & challenges are similar in both phases
Problem• Evaluate MLRM QoS earlier in
development process –e.g., prior to integration
Development Timeline
Leve
l of A
bstr
actio
n
92
Model-Driven Development – State of the Art 183
CoWorkEr
Solution: Evaluate Component QoS & Behavior using Component–based Emulators
• System components are represented as Component Workload Emulators (CoWorkErs)
• 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
Model-Driven Development – State of the Art 184
Challenge 2: Emulating Behavior & QoS of Enterprise DRE Systems
Context• In phase 1 of ARMS, QoS evaluation
was not done until integration• QoS test was done using ad hoc
techniques–e.g., creating non-reusable artifacts
& tests that do not fully exercise the infrastructure
Problem• Emulating behavior & QoS in a reusable
manner so we can easily exercise the complete infrastructure, & apply to other contexts
Test A Test A
Phase 2 Phase N
Desired
Test A (ad hoc)
Test A (ad hoc)
Phase 1 Phase 2
Current
93
Model-Driven Development – State of the Art 185
Emulate workloads, e.g., CPU, database & memory
Solution: Emulate Component Behavior & QoS Using Configurable CoWorkErs
Model-Driven Development – State of the Art 186
Perform background workloads
Solution: Emulate Component Behavior & QoS Using Configurable CoWorkErs
94
Model-Driven Development – State of the Art 187
Receive events from CoWorkErs
Solution: Emulate Component Behavior & QoS Using Configurable CoWorkErs
Model-Driven Development – State of the Art 188
Send events to CoWorkErs
Solution: Emulate Component Behavior & QoS Using Configurable CoWorkErs
95
Model-Driven Development – State of the Art 189
Challenge 3: Non-Intrusive Benchmarking & EvaluationContext• The SLICE scenario of MLRM is
composed of multiple components deployed over multiple nodes
• Each component, including components in assemblies, must be evaluated
Problem• Collecting data from each
component without interfering emulation
• Collecting data within skewing the performance metrics
Collects all the metrics for experiment
Model-Driven Development – State of the Art 190
• CUTS environment is decoupled into two sections
– Emulation & benchmarking
Solution: Decouple Emulation & Benchmarking
Emulation
Benchmarking
96
Model-Driven Development – State of the Art 191
• CUTS environment is decoupled into two sections
– Emulation & benchmarking• Data acquisition is done in 2
phases & at lower priorities than emulation
1.BenchmarkAgent collects performance metrics
2.BenchmarkAgent submits data to the BenchmarkDataCollector at user-defined intervals
Each CoWorkEr has a BenchmarkAgent
Solution: Decouple Emulation & Benchmarking
Model-Driven Development – State of the Art 192
• CUTS environment is decoupled into two sections
– Emulation & benchmarking• Data acquisition is done in 2
phases & at lower priorities than emulation
1.BenchmarkAgent collects performance metrics
2.BenchmarkAgent submits data to the BenchmarkDataCollector at user-defined intervals
• BenchmarkDataCollector stores performance metrics in database for offline analysis
Solution: Decouple Emulation & Benchmarking
97
Model-Driven Development – State of the Art 193
Challenge 4: Simplify Characterization of WorkloadContext• Persons implementing the SLICE
scenario come from different disciplines
–e.g., software architects, developers, & systems engineers
• CUTS users may not be familiar with 3rd generation or configuration languages
–e.g., C++ & Java or XML, respectively
Problem• Providing alternative methods to
programming CoWorkEr behavior & creating dense configuration files
use?
Model-Driven Development – State of the Art 194
Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior
• Workload Modeling Language (WML)is used to define the behavior of CoWorkEr components
98
Model-Driven Development – State of the Art 195
• Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components
• WML events represent different types of workloads in CoWorkEr
Startup workload
Event-driven workload
Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior
Model-Driven Development – State of the Art 196
• Workload Modeling Language (WML)is used to define the behavior of CoWorkEr components
• WML events represent different types of workloads in CoWorkEr
• Actions are attached to events & specified in order of execution to define workload strings
–Each action has attributes, e.g., number of repetitions, amount of memory to allocate & etc
Attributes for CPUAction
Workload string
Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior
99
Model-Driven Development – State of the Art 197
• Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components
• WML events represent different types of workloads in CoWorkEr
• Actions are attached to events & specified in order of execution to define workload strings
–Each action has attributes, e.g., number of repetitions, amount of memory to allocate & etc
• WML is interpreted to XML characterization files
• Characterization specified in CoWorkEr
Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior
Model-Driven Development – State of the Art 198
Challenge 5: Simplify Component Customization
Context• Default CoWorkEr can send &
receive every type of event• The SLICE components are each
different & all do not send/receive the same types of events
–Each contains a different composition
Problem• How can we customize CoWorkEr
components without requiring modification & recompilation of components?compilation
?
100
Model-Driven Development – State of the Art 199
Default CoWorkEr
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
Model-Driven Development – State of the Art 200
Custom CoWorkEr
• Event sinks of a CoWorkErare 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
–Does not require recompilation of components
Event sources removed
Event sinks removed
Solution: Customize CoWorkErs at System Modeling Level
101
Model-Driven Development – State of the Art 201
Challenge 6: Precise Analysis of QoS Performance
Context• There are many components in
SLICE & combinations in the D&C configuration these components
Problem• How can we assist users in
pinpointing problematic areas in – D&C?
Too much workload?
Too many components?
Model-Driven Development – State of the Art 202
Context• There are many components in
SLICE & combinations in the D&C configuration these components
Problem• How can we assist users in
pinpointing problematic areas in – D&C?– End-to-end QoS of mission-
critical paths?
Challenge 6: Precise Analysis of QoS PerformanceMissed deadline
102
Model-Driven Development – State of the Art 203
Solution: Present Metrics Graphically in Layers to Support General & Detailed Analysis
• BenchmarkManagerWeb-interface(BMW) analyzes & graphically displays performance metrics
BMW
reads metrics
displays
Web service
Model-Driven Development – State of the Art 204
• BenchmarkManagerWeb-interface(BMW) analyzes & graphically displays performance metrics
• General analysis shows users overall performance of each CoWorkEr
–e.g., transmisssion delay & processing
BMW General Time Data
CoWorkEr
Host
General analysis of actions
Solution: Present Metrics Graphically in Layers to Support General & Detailed Analysis
103
Model-Driven Development – State of the Art 205
• 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
Solution: Present Metrics Graphically in Layers to Support General & Detailed Analysis
Model-Driven Development – State of the Art 206
• 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-to-end performance of mission-critical operational strings
Green means end-to-end deadline met
Solution: Present Metrics Graphically in Layers to Support General & Detailed Analysis
104
Model-Driven Development – State of the Art 207
Applying CUTS to the SLICE ScenarioUsing ISISLab as our target
infrastructure
1. Use PICML to define & validate infrastructure specifications & requirements
2. Use WML to define & validate application specifications & requirements
3. Use DAnCE to deploy component emulators on target infrastructure
4. Use CUTS to evaluate & verify QoS performance
5. Redefine system D&C & repeat
Model-Driven Development – State of the Art 208
Defining Components of SLICE Scenario in PICML for CUTS• Each component in
SLICE is defined as a CoWorkEr
• The default CoWorkEr is customized to handle events specific to its representative SLICE component
• Each CoWorkEr is assigned a unique user-defined ID number
• The benchmark data submission rate is set to 15 seconds
CoWorkErcustomized CoWorkEr
105
Model-Driven Development – State of the Art 209
Defining Behavior of SLICE Scenario Components using WML
CPU: 25 repsPUBLISH: STATUS - SIZE 256
Workload performed after receipt of command event
CPU: 25 repsPUBLISH: STATUS – SIZE 32
Workload performed every second
Effector 1 & Effector 2
Model-Driven Development – State of the Art 210
Overall Results of SLICE Scenario
Test 11 produced the best results• Average case: 221 ms• Worse case: 343 ms
Results of SLICE Scenario
0
350
700
1050
1400
1 2 3 4 5 6 7 8 9 10 11Test Number
Crit
ical
Pat
h C
ompl
etio
n Ti
me
(ms)
Avg. Time Worse Time
• Only 4 of 11 deployments met the 350 ms critical path deadline for average time
• Test 11 only test to meet critical path deadline for worse time
Population size of 11 tests
106
Model-Driven Development – State of the Art 211
SLICE Scenario Results: Meeting D&C & QoS Requirements
11
10
9Test
Deployment TableNode 3Node 2Node 1
sensor 2, error recovery & effector 2
planner 2 & effector 1sensor 1, planner 1 & configuration
planner 2, sensor 2, error recovery & effector 2
configuration & effector 1
sensor 1 & planner 1
Sensor 2, error re recovery & effector 2
planner 2, configuration, & effector 1
sensor 1 & planner 1
Deployment of Critical Path on Multiple Nodes
0
350
700
9 10 11
Test
Com
plet
ion
Tim
e of
Crit
ical
Path
(ms)
Avg. Time Worse Time
• Test 9 meet the critical path QoS requirement, but did not meet the deployment requirement
• Tests 10 & 11 meet both the critical path QoS & deployment requirements
We were able to answer the critical path & deployment questions
Model-Driven Development – State of the Art 212
SLICE Scenario Results: Single Host Deployment
Deployment of Critical Path on Single Node
0350700
10501400
4 5 6Test Number
Crit
ical
Pat
h C
ompl
etio
n Ti
me
(ms)
Avg. Time Worse Time
6
5
4
Test
Deployment Table
Node 3Node 2Node 1
(nothing)All components not in the critical path
All component in the critical path
(nothing)Error recoveryAll components, excluding error recovery
(nothing)(nothing)All components
Test 6 had a average time of 323 ms
We were able to answer the question about deploying on a single node
107
Model-Driven Development – State of the Art 213
Summary of Lessons Learned• SOA middleware technologies
allowed leveraging the behavior & functionality of target architecture for more “realistic” emulations
• SOA technologies allowed us to focus on the “business” logic of CoWorkErs
–D&C handled by the underlying MDD & middleware technology
Model-Driven Development – State of the Art 214
Development Timeline
Leve
l of A
bstr
actio
n
Summary of Lessons Learned• SOA middleware technologies
allowed leveraging the behavior & functionality of target architecture for more “realistic” emulations
• SOA technologies allowed us to focus on the “business” logic of CoWorkErs
–D&C handled by the underlying MDD & middleware technology
• CUTS allowed us to test deployments before full system integration testing
• CUTS allowed us to rapidly test deployments, which would have take longer using ad hoc techniques
–e.g., hand-coding the deployment & configuration of components
increased # of tests
108
Model-Driven Development – State of the Art 215
Summary• We motivated the need for the
Component Workload Emulator (CoWorkEr) Utilization Test Suite (CUTS)
• We presented an DRE system example that used CUTS to evaluate deployments before complete integration
• We presented the design & implementation of CUTS, along with the R&D challenges we faced
www.cs.wustl.edu/~schmidt/PDF/CUTS.pdfwww.cs.wustl.edu/~schmidt/PDF/QoSPML-WML.pdf
216
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
109
Model-Driven Development – State of the Art 217
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
(UVanderbilt/ISIS‘s Generic Eclipse Modeling System)
V4
Model-Driven Development – State of the Art 218
Industry Standard Support
V4
• 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
110
Model-Driven Development – State of the Art 219
Workflow Control
• ant-based pluginframework
• Workflow Engine– controls when which
processing step is exe-cuted
– parameterizable throughproperty files
• Cartridgesmodularized processing steps(“macros”) including resourcessuch as temlplates, transfor-mations, metaclasses
<?xml version="10" encoding="windows-1252"?><workflow><property file="workflowproperties"/>
<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">
<metaModelclass="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>
V4
V4
V4
Model-Driven Development – State of the Art 220
Cartridges V4
• A cartridge is a self-sustained “piece of tool”i.e., it comes with templates, transformations, workflow snippets, metaclasses
• Real, Deep modularizationa cartridge can extend other cartridges by– extending metaclasses– overriding templates– advising templates (before, after, around)– providing new methods for existing metaclasses
111
Model-Driven Development – State of the Art 221
Code Generation
• powerful & elegant template language (XPand)– template modularization– template polymorphism– template overriding– AOP support for template
programming– powerful expression
language (OCL-Like)
• Advanced Eclipse Editor(syntax coloring, find-references, code completion, staticerror checks)
V4
Model-Driven Development – State of the Art 222
Recipe Framework
• Checks manually written code for compliance with a defined programming model– Based on the
model, checksare instantiated
– The IDE (Eclipse) verifies the checks & provides quick fixes
112
Model-Driven Development – State of the Art 223
Model–to–Model Transformation
V4
• model transformation as well as model-enrichment/completion
• Java code can be used for transformationsvery rich APIs & libraries are provided to make this easy
• WOMBAT: Textual, functional languagepowerful collections support, sameexpression language as in XPand
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
CREATE (#Book: {title <- „XYZ",numPages <- 1354
});
V4
Model-Driven Development – State of the Art 224
Status / Track Record / Future
• Version 3.1 is current
• Proven track record in various domains & projectcontextstelcos, 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!
113
225
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWare
SOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Model-Driven Development – State of the Art 226
What is SOA?• The whole concept of SOA is not really well defined today. There are a
couple 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
• Rather, SOA is an architectural style to build scalable (performance as well as size), maintainable & managable systems
114
Model-Driven Development – State of the Art 227
A Typical SOA Blueprint
Model-Driven Development – State of the Art 228
SOA vs. Component – Based Architecture• A well-done component-based architecture with well-defined
interfaces & clearly cut component responsibilities can quite justifiable be considered 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]
115
Model-Driven Development – State of the Art 229
Characteristics of SOAs• Service interactions are typically (though not mandatorily) 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 explicitly defined
–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 230
Characteristics of SOAs II• Quality of service aspects are explictly addressed
–Service providers do not just provide a certain services’ functionality, they provide the functionality with a define service level (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)
116
Model-Driven Development – State of the Art 231
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
The signatures & data structures used in the service
can be using models
Model-Driven Development – State of the Art 232
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systemsThe valid interactions
can be defined using models (e.g., protocol
state machines)
117
Model-Driven Development – State of the Art 233
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
Quality of Service Contractscan be defined using models –code to watchdog them can be
generated
Model-Driven Development – State of the Art 234
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
Component-based Development, as well as
the assignment of service providers &
services comsumerscan be based on models
118
Model-Driven Development – State of the Art 235
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
Glue code for the deployment to various execution platforms can
be generated automatically
Model-Driven Development – State of the Art 236
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
The Mappings of the Service Messages/Calls
to communication infrastructures (web
services, Tibco, JMS, ) can be automatically
generated
119
Model-Driven Development – State of the Art 237
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
The runtime repository can be populated from the data in the models
Model-Driven Development – State of the Art 238
Metamodel for SOA/CBD Development• This metamodel describes
– component types & interfaces– operations & data structures (not shown) – component dependencies
120
Model-Driven Development – State of the Art 239
Metamodel for SOA/CBD Development• This one describes component instances & their “wiring”
Model-Driven Development – State of the Art 240
Metamodel for SOA/CBD Development• This final viewpoint associates component instances with nodes & containers for
deployment & glue code generation
121
Model-Driven Development – State of the Art 241
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– And 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,– And “the real system”
Model-Driven Development – State of the Art 242
A Simple Metamodel for SOA – with CBD
Service
Message
name
Type
name
Attribute
name
*
type
RequestMessage
OnewayMessage
OutboundMessage
1..*
MessageFlow
Control
*
*ElementaryService
resp
InboundMessageaccepted
Message
1..*Compound
Service
Component
name
Provider Consumer
0..1
1..*1..*
1..*
providesconsumes p
c
1..*
ProviderConsumer
• Here we define thenotion of a servicemore extensively
• Note how servicesare connected to thecomponents definedin the previous setof metamodels
• Note that the SCA standard uses the same metaphors: components, instances, deployment, services
122
Model-Driven Development – State of the Art 243
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 244
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
The business processes are typically
also modeled, as is their relationship to the service
(interfaces) they use
123
Model-Driven Development – State of the Art 245
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
Note that it is often unrealistic to have one &
only one middleware because of varying non-functional requirements
Model-Driven Development – State of the Art 246
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
The important thing is that you are able to map the same
services to different middleware infrastructures –
& use all of them from the business processes Again a
reason to use models!
124
247
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDD
Product-line Architecture Case StudySummary
Model-Driven Development – State of the Art 248
Nav Sensors
ExpendableManagement
Data LinksMissionComputer
VehicleMgmt
Expendables
•Avionics mission computing product-line architecture for Boeing aircraft
•DRE system with 100+ developers, 3,000+ software components, 3-5 million lines of C++
•Based on COTS hardware, networks, operating systems, languages, & middleware
Bold Stroke Architecture
Radar
Case Study Example: Boeing Bold Stroke
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
125
Model-Driven Development – State of the Art 249
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
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
www.cs.wustl.edu/~schmidt/TAO.html
Applying COTS to Boeing Bold Stroke
Model-Driven Development – State of the Art 250
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
•Save a considerable amount of time/effort compared with handcrafting capabilities
•Leverage industry “best practices” & patterns in pre-packaged & ideally standardized form
Benefits of Using COTS
126
Model-Driven Development – State of the Art 251
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
• QoS of COTS components is not always suitable for mission-critical systems
• COTS technologies address some, but not all, of the domain-specificchallenges associated with developing mission-critical DRE systems
Limitations of Using COTS
What we need is a reuse technology for organizing & automating key roles &
responsibilities in an application domain
Model-Driven Development – State of the Art 252
AirFrame
GPS
FLIR
Legacy DRE systems have historically been:• Stovepiped• Proprietary • Brittle & non-adaptive• Expensive• Vulnerable
Consequence: Small HW/SW changes have big (negative) impact on DRE system QoS & maintenance
GPS
FLIRAP
Nav HUD
IFF
Cyclic Exec
F-15
AirFrame
APNav HUD
GPSIFF
FLIR
Cyclic Exec
A/V-8B
AirFrame
Cyclic Exec
AP
Nav HUD
IFF
F/A-18
AirFrame
AP
Nav HUDGPS
IFF
FLIR
Cyclic Exec UCAV
Motivation for Product-line Architectures (PLAs)
127
Model-Driven Development – State of the Art 253
F-15productvariant
A/V 8-Bproductvariant
F/A 18productvariant UCAV
productvariant
Product-line architecture
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)OS & Network ProtocolsOS & Network Protocols
Host Infrastructure MiddlewareHost Infrastructure MiddlewareDistribution MiddlewareDistribution Middleware
Common Middleware ServicesCommon Middleware Services
• Frameworks factors out many reusable general-purpose & domain-specific 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
AirFrame
APNav
HUD GPS
IFF
FLIR
Domain-specific ServicesDomain-specific Services
Motivation for Product-line Architectures (PLAs)
Model-Driven Development – State of the Art 254
• PLA characteristics are captured via Scope, Commonalities, & Variabilities (SCV) analysis• This process can be applied
to identify commonalities & variabilities in a domain to guide development of a PLA
•Applying SCV to Bold Stroke• Scope defines the domain & context of
the PLA• Bold Stroke component architecture,
object-oriented application frameworks, & associated components, e.g., GPS, Airframe, & Display
OS & Network ProtocolsOS & Network ProtocolsHost Infrastructure MiddlewareHost Infrastructure Middleware
Distribution MiddlewareDistribution Middleware
Common Middleware ServicesCommon Middleware ServicesDomain-specific ServicesDomain-specific Services
AirFrame
APNav
HUD GPS
IFF
FLIR
Overview of Product-line Architectures (PLAs)
Reusable Architecture Framework
Reusable Application Components
128
Model-Driven Development – State of the Art 255
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
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)OS & Network ProtocolsOS & Network Protocols
Host Infrastructure MiddlewareHost Infrastructure MiddlewareDistribution MiddlewareDistribution Middleware
Common Middleware ServicesCommon Middleware Services
Domain-specific ServicesDomain-specific Services
•Common middleware infrastructure• e.g., Real-time
CORBA & a variant of Lightweight CORBA Component Model (CCM) called Prism
Model-Driven Development – State of the Art 256
GPSComponent
DisplayComponent
AirframeComponent
Heads UpDisplay
GPS = 20 HzGPS = 40 Hz GPS=20Hz
Bold Stroke Common Components
Air AirFrame
AP
Nav HUD
GPS IFF
FLIRAP
Nav HUD
GPS IFF
FLIR
AirFrame
AP
Nav
HUD
GPS
IFF
FLIR
F/A 18 F F 15K UCAV
Frame APNavHUD
GPSIFF
FLIR
•Variabilities describe the attributes unique to the different members of the family
•Product-dependent component implementations (GPS/INS)
•Product-dependent component connections
•Product-dependent component assemblies (e.g., different weapons systems for different customers/countries)
•Different hardware, OS, & network/bus configurations
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)OS & Network ProtocolsOS & Network Protocols
Host Infrastructure MiddlewareHost Infrastructure MiddlewareDistribution MiddlewareDistribution Middleware
Common Middleware ServicesCommon Middleware ServicesDomain-specific ServicesDomain-specific Services
Patterns & frameworks are essential for developing
reusable PLAs
Applying SCV to the Bold Stroke PLA
129
Model-Driven Development – State of the Art 257
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
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
Applying Patterns & Frameworks to Bold Stroke
Patterns & frameworks are also used
throughout COTS software infrastructure
Model-Driven Development – State of the Art 258
Legacy Avionics Architectures
Board 1
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
3: Sensor proxies process data & pass to missionsfunctions
4: Mission functions perform avionics operations
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)
130
Model-Driven Development – State of the Art 259
Legacy Avionics ArchitecturesKey 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
Board 1
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
3: Sensor proxies process data & pass to missionsfunctions
4: Mission functions perform avionics operations
Limitations with Legacy Avionics Architectures•Stovepiped•Proprietary•Expensive•Vulnerable•Tightly coupled•Hard to schedule•Brittle & non-adaptive
AirFrame
AP
Nav WTS
GPS IFF
FLIR
Cyclic Exec
Model-Driven Development – State of the Art 260
Decoupling Avionics Components
•Apply the Publisher-Subscriber architectural pattern to distribute periodic, I/O-drivendata from a single point of source to a collection of consumers
•Tightly coupled components
•Hard to schedule•Expensive to evolve
•I/O driven DRE application
•Complex dependencies
•Real-time constraints
SolutionProblemsContext
Event*
Subscriber
consume
creates receives
Event ChannelattachPublisherdetachPublisherattachSubscriberdetachSubscriberpushEvent
Filter
filterEvent
Publisher
produce
Structure
attachSubscriberproduce
pushEventevent
eventpushEvent
consume
detachSubscriber
: Event
: Subscriber: Event Channel: Publisher
Dynamics
131
Model-Driven Development – State of the Art 261
Applying the Publisher-Subscriber Pattern to Bold Stroke
Board 1
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
4: Event Channel pushes events to subscribers(s)
5: Subscribers perform avionics operations
GPS IFF FLIR
HUD
Nav
WTSAir
Frame
Publishers
Subscribers
push(event)
push(event)
Event Channel
3: Sensor publishers push events to event channel
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
Bold Stroke uses the Publisher-Subscriber pattern to decouple sensor processing from mission computing operations• Anonymous publisher & subscriber relationships
• Group communication• Asynchrony
Model-Driven Development – State of the Art 262
Ensuring Platform-neutral Inter-process Communication
•Apply the Brokerarchitectural pattern to provide platform-neutral commsbetween mission computing boards
•Applications need capabilities to:• Support remote communication• Provide location transparency• Handle faults• Manage end-to-end QoS• Encapsulate low-level system details
•Mission computing requires remote IPC
•Stringent DRE requirements
SolutionProblemsContext
messageexchange
messageexchange
*
marshalunmarhalreceive_resultservice_p
Client Proxy
calls*
*
call_service_pstart_task
Client1
marshalunmarshaldispatchreceive_request
Server Proxy
calls*
start_upmain_loopservice_i
Server1
1
main_loopsrv_registrationsrv_lookupxmit_messagemanage_QoS
Broker1
Structure
132
Model-Driven Development – State of the Art 263
operation (params) connect
send_requestmarshal
unmarshaldispatch
operation (params)
resultmarshalreceive_reply
unmarshalresult
start_upregister_serviceassignedport
Dynamics
: Broker: Client Proxy : Server Proxy: Client : Server
Ensuring Platform-neutral Inter-process Communication
•Apply the Brokerarchitectural pattern to provide platform-neutral commsbetween mission computing boards
•Applications need capabilities to:• Support remote communication• Provide location transparency• Handle faults• Manage end-to-end QoS• Encapsulate low-level system details
•Mission computing requires remote IPC
•Stringent DRE requirements
SolutionProblemsContext
Model-Driven Development – State of the Art 264
Applying the Broker Pattern to Bold Stroke
Board 1
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
5: Event Channel pushes events to subscribers(s)
6: Subscribers perform avionics operations
GPS IFF FLIR
HUD Nav WTS Air Frame
Publishers
Subscribers
push(event)
push(event)
Event Channel
4: Sensor publishers push events to event channel
Bold Stroke uses the Broker pattern to shield distributed applications from environment heterogeneity, e.g.,•Programming languages•Operating systems•Networking protocols•Hardware
3: Brokerhandles I/O via upcalls
BrokerA key consideration for implementing the Broker pattern for mission computing applications is QoS support
•e.g., latency, jitter, priority preservation, dependability, security, etc
133
Model-Driven Development – State of the Art 265
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
• Enables reuse of software architectures & designs
• Improves development team communication
• Convey “best practices” intuitively • Transcends language-centric
biases/myopia• Abstracts away from many
unimportant details
Benefits of Patterns
GPS IFF FLIR
HUDNav WTS Air
Frame
Publishers
Subscribers
push(event)
push(event) Event Channel
Broker
www.cs.wustl.edu/~schmidt/patterns.html
Model-Driven Development – State of the Art 266
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
• Require significant tedious & error-prone human effort to handcraft pattern implementations
• Can be deceptively simple
• Leaves many important details unresolved
Limitations of Patterns
GPS IFF FLIR
HUDNav WTS Air
Frame
Publishers
Subscribers
push(event)
push(event) Event Channel
Broker
www.cs.wustl.edu/~schmidt/patterns.html
We therefore need more than just
patterns to achieve systematic reuse
134
Model-Driven Development – State of the Art 267
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
Application-specific functionality
•Frameworks exhibit “inversion of control” at runtime via callbacks
Networking Real-timeDatabase
GUI
•Frameworks provide integrated domain-specific structures & functionality
Sensor Management
Route Planning Heads-up
Display
•Frameworks are “semi- complete” applications
Framework benefits & characteristics
www.cs.wustl.edu/~schmidt/ACE.html
Applying Frameworks to Bold Stroke
Model-Driven Development – State of the Art 268
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
• 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”• May incur performance degradations due
to extra (unnecessary) levels of indirection
Limitations of Frameworks
www.cs.wustl.edu/~schmidt/PDF/Queue-04.pdf
We therefore need something simpler than frameworks to achieve
systematic reuse
135
Model-Driven Development – State of the Art 269
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
Product-line component model
• Configurable for product-specific functionality & execution environment
• Single component development policies
• Standard component packaging mechanisms
• 3,000+ software components
Applying Component Middleware to Bold Stroke
Model-Driven Development – State of the Art 270
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
Benefits of Component Middleware•Creates a standard “virtual boundary” around application component implementations that interact only via well-defined interfaces
•Define standard container mechanisms needed to execute components in generic component servers
•Specify the infrastructure needed to configure & deploy components throughout a distributed system
<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_NavDisplay</instance>
</internalEndPoint><internalEndPoint><portName>Ready</portName><instance>a_GPS</instance>
</internalEndPoint></connection>
</ComponentAssemblyDescription>
Container
……
…
…
…
136
Model-Driven Development – State of the Art 271
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
•Limit to how much application functionality can be refactored into reusable COTS component middleware
Middleware
MiddlewareServices
DRE Applications
Operating System& Protocols
Hardware & Networks
Limitations of Component Middleware
Model-Driven Development – State of the Art 272
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
•Limit to how much application functionality can be refactored into reusable COTS component middleware
•Middleware itself has become hard to provision/use
IntServ + Diffserv
RTOS + RT Java
RT/DP CORBA + DRTSJ
Load BalancerFT CORBA
Network latency & bandwidth
Workload & Replicas
CPU & memory
Connections & priority bands
Limitations of Component Middleware
137
Model-Driven Development – State of the Art 273
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
•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
Limitations of Component Middleware
Model-Driven Development – State of the Art 274
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
•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
Middleware
MiddlewareServices
DRE Applications
Operating System& Protocols
Hardware & Networks
RT-CORBA
RT-CORBAServices
RT-CORBAApps
J2ME
J2MEServices
J2MEApps
DRTSJ
DRTSJServices
DRTSJApps
Limitations of Component Middleware
138
Model-Driven Development – State of the Art 275
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
Model-driven development (MDD)• Apply MDD tools to
• Model
• Analyze
• Synthesize
• Provision
middleware & application components
• Configure product-specific component assembly & deployment environments
• Model-based component integration policies
Applying MDD to Boeing Bold Stroke
www.isis.vanderbilt.edu/projects/mobies
<CONFIGURATION_PASS><HOME>
<…> <COMPONENT><ID> <…></ID><EVENT_SUPPLIER><…events this
component supplies…></EVENT_SUPPLIER></COMPONENT></HOME>
</CONFIGURATION_PASS>
<CONFIGURATION_PASS><HOME>
<…> <COMPONENT><ID> <…></ID><EVENT_SUPPLIER><…events this
component supplies…></EVENT_SUPPLIER></COMPONENT></HOME>
</CONFIGURATION_PASS>
Model-Driven Development – State of the Art 276
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
ANALYSIS TOOLS
CODE GENERATORS
Stateflow
Real-time Java
Statecharts
Ptolemy
C/C++
SMV
SPIN
Simulink
XML Ptolemy
APPLICATION MODELING TOOLS
EMBEDDED PLATFORM MODEL
Interaction is based on mission-specific
ontologies & semantics
Formal mission specs, subsystem models, &
computational constraints are combined into integrated MDD tool chain & mapped to
execution platforms
UML/RoseESML/GME
PICML/GME
ARIESTimeWeaver
TimeWizCadena
PowerPC/ACE+TAO/BOLD-STROKE
Applying MDD to Boeing Bold Stroke
www.rl.af.mil/tech/programs/MoBIES/
139
Model-Driven Development – State of the Art 277
Benefits of MDD• Increase expressivity
• e.g., linguistic support to better capture design intent
• Increase precision • 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 “platform-
independent” (or not)!• Support product-line
architecture development & evolution
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
Avionics Mission Computing Modeling Languages
ArtifactGenerator
Model-Driven Development – State of the Art 278
Hardware (CPU, Memory, I/O)Hardware (CPU, Memory, I/O)
Networking InterfacesNetworking Interfaces
Operating SystemOperating System
Middleware InfrastructureMiddleware Infrastructure
Mission Computing ServicesMission Computing Services
•Modeling technologies are still maturing & evolving
• i.e., non-standard tools
•Magic (& magicians) are still necessary for success
Model & Component Library
ApplicationsApplications
$ $ $
Limitations of MDD
140
279
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case Study
Summary
Model-Driven Development – State of the Art 280
Open MDD R&D Issues• Inherent Complexities• Capturing specificity of target domain
• 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
• Accidental Complexities• Round-trip engineering from
models ↔ source
• Mismatched abstraction levels for development vs debugging
• Tool chain vs monolithic tools
• Backward compatibility of modeling tools
• Standard metamodeling languages & tools
141
Model-Driven Development – State of the Art 281
Positive Development
• Today’s tools can be used productively – although sometimes some “magic” is necessary
• Today’s problem is not really that we need better tools, we rather need more experience!
• Standardization efforts are slowly coming to fruition: EMF, QVT, MIC
• CoSMIC is available from www.dre.vanderbilt.edu/cosmic
• GME is available from www.isis.vanderbilt.edu/Projects/gme/default.htm
• openArchitectureWare is available fromwww.openarchitectureware.org
Start today – it will make you more productive
Model-Driven Development – State of the Art 282
Some Advertisements ☺
• For those, who speak(or rather, read ;-)) german:
Stahl, Völter:
Modellgetriebene SoftwareentwicklungTechnik, Engineering, Management
dPunkt, 2005
www.mdsd-buch.de
• A very much updated English translation isunder way:Model-DrivenSoftware Development, Wiley, Q2 2006
www.mdsd-book.org