Model-Driven Development State of the Art - voelter · Model-Driven Development State of the Art...

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


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


Why Hardware Improves So ConsistentlyAdvances in hardware & networks stem largely from R&D on standardized & reusable APIs & protocols

x86 & Power PC chipsets TCP/IP


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


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


</CONFIGURATION_PASS>Gigabit EthernetGigabit

Ethernet

Build

Analyze


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


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


Key Challenges for Software Developers

LogicalLogicalViewView

PhysicalPhysicalViewView

DevelopmentDevelopmentViewView

ProcessProcessViewView

Use CaseUse CaseViewView

Developers & users of software face challenges in multiple dimensions

6



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




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


7



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)




(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


8


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




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



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 & analysis techniques for optimizing,

verifying, & automating the deployment & configuration process Gigabit Ethernet

10



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




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




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


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


Technology Evolution (2/4)Programming Languages

& Platforms

Level of Abstraction

C++/JavaClass LibrariesFrameworksComponents


Hardware

OperatingSystems

Model

Application CodeDomain Specific

FrameworkPlatform

Frameworks

Model

Generated CodeFramework

Pattern Language

Platform

Model


FrameworkPlatform

Frameworks

Model


Pattern Language

Platform

Model


FrameworkPlatform

Frameworks

Model


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



& Platforms


Saturation!!!!

Model


FrameworkPlatform

Frameworks

Model


Pattern Language

Platform

Model


FrameworkPlatform

Frameworks

Model


Pattern Language

Platform

Model


FrameworkPlatform

Frameworks

Model


Pattern Language

Platform

Model


FrameworkPlatform

Frameworks

Model


Pattern Language

Platform


Domain-specificmodeling languages

• ESML• PICML• Mathematic• Excel• MetamodelsManual

translation



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



& Platforms

Needs Automation

Needs Automation

Research is needed to automate DSLs & model translators


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



Hardware

OperatingSystems


26


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


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


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


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


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


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)


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


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


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


• 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-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


• 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


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


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


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


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


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


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


AC – MDD Concept Adoption

DomainArchitecture


Architecture


<<acmdsd>>Code

Snippet

GeneratedArtifact

<<acmdsd>>Skeleton

complements

<<acmdsd>>Template

Target


Target1..*

DSL<<acmdsd>>

DesignLanguage



FormalModel

<<acmdsd>>Design

The products to be created are usually complete applications,

not single components

23



DomainArchitecture


Architecture


<<acmdsd>>Code

Snippet

GeneratedArtifact

<<acmdsd>>Skeleton

complements

<<acmdsd>>Template

Target


Target1..*

DSL<<acmdsd>>

DesignLanguage



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



DomainArchitecture


Architecture


<<acmdsd>>Code

Snippet

GeneratedArtifact

<<acmdsd>>Skeleton

complements

<<acmdsd>>Template

Target


Target1..*

DSL<<acmdsd>>

DesignLanguage



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



DomainArchitecture


Architecture


<<acmdsd>>Code

Snippet

GeneratedArtifact

<<acmdsd>>Skeleton

complements

<<acmdsd>>Template

Target


Target1..*

DSL<<acmdsd>>

DesignLanguage



FormalModel

<<acmdsd>>Design

The DSL is also called design language

Often, UML profiles are used here, sometimes combined with additional textual specifications



DomainArchitecture


Architecture


<<acmdsd>>Code

Snippet

GeneratedArtifact

<<acmdsd>>Skeleton

complements

<<acmdsd>>Template

Target


Target1..*

DSL<<acmdsd>>

DesignLanguage



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



DomainArchitecture


Architecture


<<acmdsd>>Code

Snippet

GeneratedArtifact

<<acmdsd>>Skeleton

complements

<<acmdsd>>Template

Target


Target1..*

DSL<<acmdsd>>

DesignLanguage



FormalModel

<<acmdsd>>Design

The transformation does not aim at creating the complete application, but merely an implementation frameworkcontaining the architectural infrastructure code (skeleton)



DomainArchitecture


Architecture


<<acmdsd>>Code

Snippet

GeneratedArtifact

<<acmdsd>>Skeleton

complements

<<acmdsd>>Template

Target


Target1..*

DSL<<acmdsd>>

DesignLanguage



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


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


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



The IDE evaluates the checks in the recipe file & points to problems in the

manually written code




Checks that are ok are rendered in green (or

can be filtered out)


28



You can get more detailed information

on the checks executed




And a nice explaingtext that tells

developers what to do to fix the problem


29



You can reevaluatechecks at any time




A “quick fix” buttonwill be added till final

release of oAW 4


30


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


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


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


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


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


•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


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)


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


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


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


• 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


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


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


Pattern Language

Platform

Model

Application Code


PlatformFrameworks

Model


Pattern Language

Platform

Model

Application Code


PlatformFrameworks

Model


Pattern Language

Platform

Model

Application Code


PlatformFrameworks

Model


Pattern Language

Platform

36

71


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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(XMI)

ParserModel

(Object Graph)

ModelTrans-former


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




Model(XMI)

ParserModel

(Object Graph)

ModelTrans-former


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


46



Model(XMI)

ParserModel

(Object Graph)

ModelTrans-former


export

Generated Code

CodeGenerator

(may be repeated)

In a final step, code is generated from

the AST



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


M2M: One Metalevel Higher– Precondition:

Representing a class diagram of metalevel n as an object diagram of metalevel n+1


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–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;}


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


Transformations in Java: ExamplePerson

name: StringfirstName : StringbirthDate: Date

age(): int

PersonBean


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


age(): int

<<EJB::EntityBean>>

{transactions=tx.cmt, persistence=persistence.bmp.hibernate, interface=interfaces.remoteOnly}


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


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


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


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


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






• Summary


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






• Summary


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


• 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






• Summary

55


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


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


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






• Summary

57


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>


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






• Summary


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






• Summary


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


• 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






• Summary

61


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






• Summary

62


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



Interface

providedInterface

0..n

requiredInterface

0..n

Container

0..n

Component

Characteristic0..n


Operation1..n

Parameter

0..n

Type

retu

rnTy

pe

type

PrimitiveType

ComplexType

1 0..n

newVersionOf

1 0..n

newVersionOf



ProcessComponent

StateMachine State

1..n

Transition

fromto0..n 0..n


Interfaces have operations – they’re

defined as usual

63



Interface

providedInterface

0..n

requiredInterface

0..n

Container

0..n

Component

Characteristic0..n


Operation1..n

Parameter

0..n

Type

retu

rnTy

pe

type

PrimitiveType

ComplexType

1 0..n

newVersionOf

1 0..n

newVersionOf



ProcessComponent

StateMachine State

1..n

Transition

fromto0..n 0..n


Process Components are special kinds of

components



Interface

providedInterface

0..n

requiredInterface

0..n

Container

0..n

Component

Characteristic0..n


Operation1..n

Parameter

0..n

Type

retu

rnTy

pe

type

PrimitiveType

ComplexType

1 0..n

newVersionOf

1 0..n

newVersionOf



ProcessComponent

StateMachine State

1..n

Transition

fromto0..n 0..n


A process component’s process is described using a

state machine

64



Interface

providedInterface

0..n

requiredInterface

0..n

Container

0..n

Component

Characteristic0..n


Operation1..n

Parameter

0..n

Type

retu

rnTy

pe

type

PrimitiveType

ComplexType

1 0..n

newVersionOf

1 0..n

newVersionOf



ProcessComponent

StateMachine State

1..n

Transition

fromto0..n 0..n


And the triggers are special kinds

of operations



Interface

providedInterface

0..n

requiredInterface

0..n

Container

0..n

Component

Characteristic0..n


Operation1..n

Parameter

0..n

Type

retu

rnTy

pe

type

PrimitiveType

ComplexType

1 0..n

newVersionOf

1 0..n

newVersionOf



ProcessComponent

StateMachine State

1..n

Transition

fromto0..n 0..n


A container runs a number of components

65



Interface

providedInterface

0..n

requiredInterface

0..n

Container

0..n

Component

Characteristic0..n


Operation1..n

Parameter

0..n

Type

retu

rnTy

pe

type

PrimitiveType

ComplexType

1 0..n

newVersionOf

1 0..n

newVersionOf



ProcessComponent

StateMachine State

1..n

Transition

fromto0..n 0..n


Constraints are used to define

the semantics of versioning






• Summary

66


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






• Summary

67


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)



• 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



<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







<<entity>>Person




0..n


address-Store


Type Model


person

Composition Model defines named configurations of

component instances & the wiring among them

69







<<entity>>Person




0..n


address-Store


Type Model


person

System model deploysconfigurations onto systems& nodes Nodes define the

kind of system they represent



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



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



<<generate>>




.java



*

1

sm AProcess


<<tra

nsfo

rm>>

s1

s2

s3


attributes...

data

1

<<tra

nsfo

rm>>



They also model a trigger interface for

that component with no operations

• We also use cascading for the Process Components

71



<<generate>>




.java



*

1

sm AProcess


<<tra

nsfo

rm>>

s1

s2

s3


attributes...

data

1

<<tra

nsfo

rm>>



Developers then model the state machine for that process

component & associate it with the process component




<<generate>>




.java



*

1

sm AProcess


<<tra

nsfo

rm>>

s1

s2

s3


attributes...

data

1

<<tra

nsfo

rm>>



Using M2M, the operations are derived from the triggers used

in the state machine


72



<<generate>>




.java



*

1

sm AProcess


<<tra

nsfo

rm>>

s1

s2

s3


attributes...

data

1

<<tra

nsfo

rm>>



Using M2M, the Entitythat stores process

instances persistently is derived from the state

machine; then the Entity transformations kick in –

see before




<<generate>>




.java



*

1

sm AProcess


<<tra

nsfo

rm>>

s1

s2

s3


attributes...

data

1

<<tra

nsfo

rm>>



As usual, from components we

generate skeleton base classes


73



<<generate>>




.java



*

1

sm AProcess


<<tra

nsfo

rm>>

s1

s2

s3


attributes...

data

1

<<tra

nsfo

rm>>



Instead of letting developers implement the business logic manually, we generate an “Intermediate” class that contains the executable, & persistence-aware state

machine




<<generate>>




.java



*

1

sm AProcess


<<tra

nsfo

rm>>

s1

s2

s3


attributes...

data

1

<<tra

nsfo

rm>>



Finally, developers extend that intermediate

class & implement guard and action

operations manually by overriding abstract

methods


74






• Summary


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–Based Architecture Validation

• Another really important aspect in our example system is evolution of interfaces:

<<component>>SomeCompV1

<<interface>>SomeInterface

soSomething(int, ValueObject)


<<newVersionOf>><<interface>>

AnotherInterface

<<vo>>ValueObject


<<newVersionOf>>

<<interface>>SomeInterfaceV3

soSomething(int, ValueObjectV2)anAdditionalOperation()

<<newVersionOf>>

<<vo>>ValueObjectV3

<<newVersionOf>>

150


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


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


MDD Application Development with GME

•Application developers use modeling environments created w/MetaGME to build applications–Capture elements & dependencies visually

77


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


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




–Define static semantics via Object Constraint Language (OCL)




–Define static semantics via Object Constraint Language (OCL)

–Dynamic semantics implemented via model interpreters

79


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


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


Applications• Traditional methods of development have

been replaced by middleware layers to reuse architectures & code

• Viewed externally as Service-Oriented Architecture (SOA) Middleware


Hardware Devices

Domain-Specific Services

Common Services

Distribution Middleware

Infrastructure Middleware


Service-Oriented Architecture Middleware



Applications• Traditional methods of development have

been replaced by middleware layers to reuse architectures & code

• Viewed externally as Service-Oriented Architecture (SOA) Middleware


Hardware Devices


Common Services

Distribution Middleware

Infrastructure Middleware


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


81


Applications


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


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


Serialized Phasing is Common in Large-scale Systems


Leve

l of A

bstr

actio

n

Integration Surprises!!!

System integration & testing

Finished development


Complexities of Serialized Phasing


Leve

l of A

bstr

actio

n

Still in development

Ready for testingComplexities• System infrastructure cannot be

tested adequately until applications are done

83


Complexities of Serialized Phasing


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


Unresolved QoS Concerns with Serialized PhasingMeet QoS

requirements?

Key QoS concerns• Which D&C’s meet the QoS

requirements?


Leve

l of A

bstr

actio

n

84


Unresolved QoS Concerns with Serialized PhasingPerformance

metrics?


requirements? • What is the worse/average/best

time for various workloads?


Leve

l of A

bstr

actio

n


Unresolved QoS Concerns with Serialized Phasing

It is hard to address these concerns in processes that use serialized phasing


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?


Leve

l of A

bstr

actio

n

85


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


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


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


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


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


sensor 2

planner 1 planner 2

configuration

error recovery effector 1(main)

effector 2

sensor 1(main)

350ms deadline


Questions we would like to answer1. Can we meet the D&C &

performance requirements?

88


sensor 2

planner 1 planner 2

configuration


effector 2

sensor 1(main)



performance requirements?2. Are there multiple deployments that

meet the 350ms critical path deadline?• Which yields the most headroom


sensor 2

planner 1 planner 2

configuration


effector 2

sensor 1(main)


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?


89


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




3. Non-intrusive benchmarking & evaluation

4. Simplifying component behavior specification


Single-point of data collection?

Define behavior non-programmatically?


90


Customizing generic components?





5. Simplify component customization








5. Simplify component customization

6. Precise analysis of performance


End-to-end execution

Time critical


91


Challenge 1: Evaluating QoS Characteristics of Enterprise DRE Systems Early in Life-cycle

Leve

l of A

bstr

actio

n


• 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


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


Leve

l of A

bstr

actio

n

92


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


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


Emulate workloads, e.g., CPU, database & memory

Solution: Emulate Component Behavior & QoS Using Configurable CoWorkErs


Perform background workloads


94


Receive events from CoWorkErs



Send events to CoWorkErs


95


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


• CUTS environment is decoupled into two sections

– Emulation & benchmarking

Solution: Decouple Emulation & Benchmarking

Emulation

Benchmarking

96



– 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




– 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


97


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?


Solution: Use Domain–Specific Modeling Language to Program CoWorkEr Behavior

• Workload Modeling Language (WML)is used to define the behavior of CoWorkEr components

98


• 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



• Workload Modeling Language (WML)is used to define the behavior of CoWorkEr components


• 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


99


• Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components


• 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



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


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


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


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?


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


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



• General analysis shows users overall performance of each CoWorkEr

–e.g., transmisssion delay & processing

BMW General Time Data

CoWorkEr

Host

General analysis of actions


103





• Detailed analysis shows users the performance of an action in the respective CoWorkEr

–e.g., memory & CPU actions, event handling & etc






• 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


104


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


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


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


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


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)


• 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


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)


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


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



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


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


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


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


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


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


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


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


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–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


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


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


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


A Typical SOA Blueprint


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


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


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


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


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



Quality of Service Contractscan be defined using models –code to watchdog them can be

generated



Component-based Development, as well as

the assignment of service providers &

services comsumerscan be based on models

118



Glue code for the deployment to various execution platforms can

be generated automatically



The Mappings of the Service Messages/Calls

to communication infrastructures (web

services, Tibco, JMS, ) can be automatically

generated

119



The runtime repository can be populated from the data in the models


Metamodel for SOA/CBD Development• This metamodel describes

– component types & interfaces– operations & data structures (not shown) – component dependencies

120


Metamodel for SOA/CBD Development• This one describes component instances & their “wiring”


Metamodel for SOA/CBD Development• This final viewpoint associates component instances with nodes & containers for

deployment & glue code generation

121


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”


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


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








Note that it is often unrealistic to have one &

only one middleware because of varying non-functional requirements








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


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


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







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







•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







• 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


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


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)


• 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


Applying SCV to the Bold Stroke PLA•Commonalities describe the attributes that are common across all members of the PLA family•Common object-oriented frameworks & set of component types

• e.g., GPS, Airframe, Navigation, & Display components



Common Middleware 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


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



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







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


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


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


Board 2


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


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


Applying the Publisher-Subscriber Pattern to Bold Stroke

Board 1

VME

1553


Board 2


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


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


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


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



Applying the Broker Pattern to Bold Stroke

Board 1

VME

1553


Board 2


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







• 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







• 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








•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







• 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







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







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







•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








•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


137









•Large # of components can be tedious & error-prone to configure & deploy without proper integration tool support










•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


138







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



<CONFIGURATION_PASS><HOME>

<…> <COMPONENT><ID> <…></ID><EVENT_SUPPLIER><…events this









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


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






Avionics Mission Computing Modeling Languages

ArtifactGenerator







•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


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


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


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


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

Model-Driven Development State of the Art - voelter · Model-Driven Development State of the Art...

Documents

Transcript of Model-Driven Development State of the Art - voelter · Model-Driven Development State of the Art...