Model Driven Engineering for QoS Model Driven Engineering for QoS Management inManagement in

Distributed Real-time & Embedded Distributed Real-time & Embedded SystemsSystems

Dr. Aniruddha S. Gokhale a.gokhale@vanderbilt.eduAssistant Professor, EECS

Vanderbilt University Nashville, Tennessee

Institute for Software Integrated

Systems

Presented at Avaya LabsApril 14th, 2006

2

DOC Group Research

<CONFIGURATION_PASS><HOME> <…>

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

supplies…></EVENT_SUPPLIER></COMPONENT></HOME>

</CONFIGURATION_PASS>

<CONFIGURATION_PASS><HOME> <…>

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

supplies…></EVENT_SUPPLIER></COMPONENT></HOME>

</CONFIGURATION_PASS>

Benchmarking

Weaver

Synthesis

FunctionalModel

SystemicModel

Analysis

Domain

Access Resources

Assembler

Assembler

Planner

Domain Administrator

Specifies

CreatesComponent

ResourceRequirements

Impl Impl Impl

Properties

COMPONENT REPOSITORY

QoS Specs

Configurations

Dependencies

Developer

CreatesComponent Assembly

ComponentComponent

ComponentComponent

Creates Packager

Repository Administrator

Component Packages

Configures

Desktop Printer Laptop computer

Ethernet Bridge

Firewall

Creates

Executor

Deployment PlanUses

Deploys

www.dre.vanderbilt.edu

• CoSMIC - Modeling Deployment & Configuration (D&C) crosscutting concerns

• CIAO – QoS-enabled component middleware

• DAnCE – Deployment And Configuration Engine

Plan Analyzers

XML to IDL

LISP to IDL

2D Bin packing

path

Priority Sched .

path

Plan Managers

2D Bin packing

Priority Sched .

Output Adapters

To DAnCE

To OpenCCM

Applications that fetch XML or LISP and call appropriate plug -ins

R-F

F-R F-R

F-R

R-F

F-R. Line source is a Facet and Line destination is a Receptacle

R-F. Line source is a Receptacle and Line destination is a Facet

R-F

• RACE – Resource and Control Engine

3

Notion of Enterprise Distributed Real-time & Embedded (DRE)

Systems

Real-time & embedded systems• Deeply embedded• Resource constrained• Fixed and often static

operational modes and environments

The Past

Distributed real-time & embedded (DRE) systems• Network-centric & larger-scale “systems of systems”• Composable from COTS components• QoS requirements a mix of enterprise & real-time • Dynamic operational modes and environment

The Future

4

•Components encapsulate application “business” logic

•Components interact via ports•Provided interfaces, e.g.,facets•Required connection points, e.g., receptacles

•Event sinks & sources•Attributes

•Containers provide execution environment for components with common operating requirements

•Components/containers can also•Communicate via a middleware bus and

•Reuse common middleware services

SecurityReplication NotificationPersistence

SchedulingA/V Streaming Load Balancing

…

Container

… …

Middleware Bus

Container

…

Technology Enablers: Component Middleware

“Write Code That Reuses Code”

5

Key challenges in the solution space

• Enormous accidental & inherent complexities

• Continuous evolution & change• Highly heterogeneous platform, language, & tool environments

New Demands on DRE Systems

Key challenges in the problem space• Network-centric, dynamic, very large-scale “systems of systems”

• Stringent simultaneous quality of service (QoS) demands

• Highly diverse & complex problem domains

Mapping problem artifacts to solution artifacts is very problematic

6

Promising Solution: Model Driven Engineering (MDE)

• Develop, validate, & standardize generative software technologies that:1. Model2. Analyze3. Synthesize &4. Provision

multiple layers of middleware & application components that require simultaneous control of multiple quality of service properties end-to-end

• Specialization is essential for inter-/intra-layer optimization & advanced product-line architectures

Middleware

MiddlewareServices

DRE Applications

Operating Sys& Protocols

Hardware & Networks

<CONFIGURATION_PASS> <HOME> <…>

<COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>

Goal is not to replace programmers per se – it is to provide higher-level domain-specific languages for middleware/application developers & users

7

MDE Tool Developer (Metamodeler)

Application Developers (Modelers)

Technology Enabler: Generic Modeling Environment (GME)

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

Goal: Correct-by-construction DRE systems

8

Specification & Implementation• Defining, partitioning, & implementing appln functionality as standalone components

Assembly & Packaging • Bundling a suite of software binary modules & metadata representing app components

Installation• Populating a repository with packages required by app

Configuration• Configuring packages with appropriate parameters to satisfy functional & systemic requirements of an application without constraining to physical resources

Planning• Making deployment decisions to identify nodes in target environment where packages will be deployed

Preparation• Moving binaries to identified entities of target environment

Launching• Triggering installed binaries & bringing appln to ready state

QoS Assurance & Adaptation• Runtime (re)configuration & resource management to maintain end-to-end QoS

OMG Deployment & Configuration (D&C)

specification (ptc/05-01-07)

DRE Lifecycle Stages Affecting QoS

9

Our MDE Solution: CoSMIC

Component

ResourceRequirements

Impl

Impl

Impl

Properties

Component Assembler

Component Assembly

Component Component

Component Component

Component Package

Component Assembly

Component Component

Component Component

Component Assembly

Component Component

Component Component

(1) d

evel

ops

(2) assembles

(3) packages

(4) c

onfig

ures

(6) deployment

Assembly

DeploymentApplication

Assembly

Assembly

CoSMIC

(8) reconfiguration &

replanning

Analysis & Benchmarking

packaging

asse

mbl

y

specification

configuration

plan

ning

feedback

(7) analysis & benchmarking

(IDM

L &

PICM

L)

(PICML)

(PICML)

(OCM

L,QoS

ML)

(Cadena & BGML)

DAnCE Framework

(5) planning

Component Developer

RACE Framework

),...,( 21 nxxxfy

Deployment Planner

Component Packager

Component Configurator

Systemanalyzer

ComponentDeployer

(9) design

feedback

• CoSMIC tools e.g., PICML used to model application components• Captures the data model of the OMG D&C specification• Synthesis of static deployment plans for DRE applications• New capabilities being added for QoS provisioning (real-time, fault tolerance)

CoSMIC can be downloaded at www.dre.vanderbilt.edu/cosmic

10

Nav Sensors

ExpendableManagement

Data LinksMissionComputer

VehicleMgmt

Expendables

• Avionics mission computing product-line architecture for Boeing aircraft, e.g., F-18 E/F, 15E, Harrier, UCAV

• DRE system with 100+ developers, 3,000+ software components, 3-5 million lines of C++ code

• Based on COTS hardware, networks, operating systems, & middleware

• Used as Open Experimentation Platform (OEP) for DARPA IXO PCES, MoBIES, SEC, MICA programs

Bold Stroke Architecture

Hardware (CPU, Memory, I/O)

Networking Interfaces

Operating System

Middleware Infrastructure

Mission Computing Services

Radar

DRE System Example: Boeing Bold Stroke

11

(I) The Packaging Aspect

•Application components are bundled together into assemblies

•Several different assemblies tailored towards delivering different end-to-end QoS and/or using different algorithms can be part of the package •e.g., large-scale DRE systems require 100s-1,000s of components

•Packages describing the components & assemblies can be scripted via XML descriptors

TIMER20Hz

GPS NAV DISP

12

Packaging Aspect Problems (1/2)

RT EventChannel

Ad hoc techniques for ensuring component syntactic & semantic compatibility

Distribution & deployment done in ad hoc manner

Ad hoc means to determine event notification support

13

Packaging Aspect Problems (2/2)

<!– Associate components with impls --><componentfiles> <componentfile id=“RateGenerator"> <fileinarchive name=“HouseRateGen.csd"/> </componentfile>

<componentfile id=“HiResGPS"> <fileinarchive name=“aGPS.csd"/> </componentfile>

<componentfile id=“cockpitDisplay"> <fileinarchive name=“navDisplay-if.csd"/> </componentfile>

</componentfiles>

XML file in excess of 3,000 lines, even for medium sized scenarios

Existing practices involve handcrafting XML descriptors

Modifications to the assemblies requires modifying XML file

14

• Platform-Independent Component Modeling Language (PICML)

• Developed in Generic Modeling Environment (GME)

• Core of Component Synthesis using Model-Integrated Computing (CoSMIC) toolchain

• Capture elements & dependencies visually

• Define “static semantics” using Object Constraint Language (OCL)

• Define “dynamic semantics” via model interpreters • Also used for generating domain

specific meta-data • “Correct-by-construction”

Assembly Meta-Model

Component Assembler

Component Development

Component Deployment

AssemblyConstraints

ComponentPackager

Package Meta-Model

Component

ResourceRequirements

Impl Impl Impl

PropertiesComponent Assembly

ComponentComponent

ComponentComponent

PackageConstraints

Component Package

Component Assembly Component Assembly

CoSMIC MDE Solution for Packaging Aspect

TIMER20Hz

GPS NAV DISPAIRFRAME

15

InterfaceDesign

ComponentDesign

ComponentImplementation

ComponentPackaging

ApplicationAssembly

SystemDeployment

Interface IDLDefinitions

Stubs&

Skeletons

ObjectImplementations

RunningApplications

ComponentIDL

Definitions

IDLCompiler

CIDLCompiler

ComponentCIDL

Definitions

Servants,Executors,Contexts

LanguageTools

ComponentDLLs

Component &Home Properties

ComponentInterface

Descriptors(.ccd)

PackagingTools

ComponentPackages

(*.cpk)

Component &Home Properties

ComponentPackage

Descriptors(.cpd)

DeploymentTools

ImplementationArtifact

Descriptors(.iad)

DeploymentPlan

Descriptor(.cdp)

ComponentDomain

Descriptor(.cdd)

AssemblyTools

ComponentImplementation

Descriptor(*.cid)

Example Metadata Generated by PICML

• Component Interface Descriptor (.ccd) • Describes the interface, ports, properties of a single component

• Implementation Artifact Descriptor (.iad)• Describes the implementation artifacts (e.g., DLLs, OS, etc.) of

one component• Component Package Descriptor (.cpd)

• Describes multiple alternative implementations of a single component

• Package Configuration Descriptor (.pcd)• Describes a configuration of a component package

• Top-level Package Descriptor (package.tpd)• Describes the top-level component package in a package

(.cpk)• Component Implementation Descriptor (.cid)

• Describes a specific implementation of a component interface• Implementation can be either monolithic- or assembly-based• Contains sub-component instantiations in case of assembly

based implementations• Contains inter-connection information between components

• Component Packages (.cpk)• A component package can contain a single component• A component package can also contain an assembly Based on OMG (D&C)

specification (ptc/03-06-03)

16

Example Output from PICML

<!–-Component Implementation Descriptor(.cid) associates components with impl. artifacts--> <Deployment:ComponentImplementationDescription> <label>GPS Implementation</label> <UUID>154cf3cd-1770-4e92-b19b-8c2c921fea38</UUID> <implements href="GPS.ccd"/> <monolithicImpl> <primaryArtifact> <name>GPS Implementation artifacts</name> <referencedArtifact href="GPS.iad"/> </primaryArtifact> </monolithicImpl></Deployment:ComponentImplementationDescription>

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

• Describes a specific implementation of a component interface

• Contains inter-connection information between components

A Component Implementation Descriptor (*.cid) file

17

(II) The Multilayer Configuration Aspect

Configuration of components & assemblies

Configuration of component containers

Configuration of the middleware bus

Configuration of component server

Configuration of event notifiers

•Component-based software must be configurable at many levels•e.g., application components & containers, component servers, & middleware services & infrastructure

18

Challenge: The M/W Bus Configuration

Component middleware is characterized by a large configuration space that maps known variations in the application requirements

space to known variations in the middleware solution space

Hook for the concurrency strategy

Hook for the request demuxing strategy

Hook for marshaling strategy

Hook for the connection management strategy

Hook for the underlying transport strategy

Hook for the event demuxing strategy

19

server object management middleware

Challenge: Configuring Container Policies

•Existing techniques for metadata configurations rely on ad hoc manual configurations e.g., CORBA server-side programming

Determine the server object management policies

Determine right buffer sizes

Determine thread pool sizes; how are they shared; number of lanes and their priorities; if borrowing is enabled

Determine various middleware policies for server objects e.g., security, lifetime, replication

•This “glue code” is traditionally handcrafted

Ensure semantic compatibility among chosen configurations

Determine end-to-end priority propagation model to use

20

CoSMIC MDE Solutions for Configuration Aspect

Approach:•Develop an Options Configuration Modeling Language (OCML) using GME

•OCML is used by•Middleware developer to design the configuration model

•Application developer to configure the middleware for a specific application

•OCML metamodel is platform-independent

•OCML models are platform-specific

21

Applying OCML to CIAO+TAO

•Configuration space •Constraints

•Middleware developers specify

22

Applying OCML to CIAO+TAO•Middleware developers specify

•Configuration space •Constraints

•Application developers provide a model of desired options & their values, e.g.,•Middleware network resources

•Concurrency & connection management strategies

•Constraint checker flags incompatible options

23

Applying OCML to CIAO+TAO•Middleware developers specify

•Configuration space •Constraints

•Application developers provide a model of desired options & their values, e.g.,•Middleware network resources•Concurrency & connection management strategies

•Constraint checker flags incompatible options

•Synthesizes XML descriptors for middleware configuration

•Generates documentation for the middleware configuration

•Validates the configurations

24

(III) Deployment Planning Aspect

Determine current resource allocations on target platforms

Select the appropriate package to deploy on selected target

Select appropriate target platform to deploy packages

Component integrators must make appropriate deployment decisions, including identifying the entities (e.g., CPUs) of the target environment where the packages will be deployed

25

Planning Aspect Problems

How do you determine current resource allocations?

How do you ensure that the selected targets will deliver required QoS

TIMER20Hz

GPS NAV DISPAIRFRAME

How do you correlate QoS requirements of packages to resource needs

How to ensure a particular deployment configuration maximizes QoS

26

Example: Fault Tolerance Planning

• CoSMIC (PICML) enhancements to represent failover units and replication groups

• capture requirements, such as replication degrees, heartbeat intervals, importance, replication style, state synchronization mechanisms

FOU and requirements

27

Modeling Shared Risk for FT Planning

• Model shared risk group elements in a system e.g., ship comprising regions, data centers, shelves, racks and blades

• Generative programming to synthesize deployment plans for FOUs that minimize shared risk (e.g., co-failure probability)

system wide risk hierarchy

28

(IV) Quality Assurance & QoS Validation Aspect

Existing Quality Assurance Processes:• Auto-build scoreboard systems

• e.g. Mozilla’s Tinderbox• Error reporting based on prepackaged

installation tests• e.g. GNU GCC and ACE & TAO

• Online crash reporting• e.g. Netscape’s QFA and Microsoft’s

Watson• Shortcomings: inadequate, opaque,

inefficient and inflexible QA processes• Scope: Generally restricted to

functional testing and often incomplete• Documentation: No knowledge of what

has or hasn’t undergone QA• Control: Developers have no control

over the QA processes• Adaptation: Can’t learning from the

earlier test results

Persistent Challenges •Scale

• Massive configuration & optimization space

•Time to market pressure• Rapid updates, frequent

releases•Heterogeneity

• Scattered resources & distributed developers

•Incomplete information• Unobservable usage context

Emerging Opportunities•Leverage remote computing resources and network ubiquity for distributed, continuous QA

29

CoSMIC MDE Solution for QA Aspect

BGML Workflow1. End-user composes the scenario in the BGML

modeling paradigm2. Associate QoS properties with this scenario, such

as latency, jitter, or thruput3. Synthesize the appropriate test code to run the

experiment & measure the QoS4. Feedback metrics into models to verify if system

meets appropriate QoS at design time

Component Interaction

Experimenter

BGML

ModelExperimet

AssociateQoS

Characteristics

Synthesize&

ExecuteFeedback

Test bed

1 2

34

IDL .cpp

Scriptfiles

Approach:•Develop an Benchmark Generation Modeling Language (BGML) w/GME

•BGML provides a model-based toolsuite to empirically evaluate & refine deployment configurations to maximize application QoS

•Use in conjunction with OCML

30

Resolving Planning Challenges with BGML (1/2)

Example Scenario• Navigation Display – displays

GPS position updates• GPS Component – generates

periodic position updates• Airframe Component –

processes input from the GPS component and feeds to Navigation display

• Trigger Component – generates periodic refresh rates

Goal• Determine the configuration

settings for the individual components to achieve the QoS required for this scenario

Step1: Model component Interaction using BGML

Step2: Configure each component, associating the appropriate IDL interfaces

31

Step3: Associate operations with the component ports

Step4: Associate QoS metrics to measure in the scenario

• BGML tool allows actual composition of the target interaction scenario, auto-generates benchmarking code

• Each configuration option can then be tested to identify the configuration that maximizes the QoS for the scenario

• These empirically refined configurations can be reused across applications that have similar/same application domains

• These configurations can be viewed as Configuration & Customization (C&C) patterns

void start_time_probe (){ if (!timer_count) test_start = ACE_OS::gethrtime ();

start_timer_probe = ACE_OS::gethrtime ();}

void stop_time_probe (){ finish_timer_probe = ACE_OS::gethrtime (); history.sample (finish_timer_probe - start_timer_probe);

if (++ timer_count == niterations) { test_end = ACE_OS::gethrtime (); ACE_DEBUG ((LM_DEBUG, "test finished\n")); ACE_Throughput_Stats::dump_throughput ("Total", gsf, test_end - test_start, stats.samples_count ()); }}

Resolving Planning Challenges with BGML (2/2)

34

(V) Adaptation & Resource Management Aspect

QoSSystemic Path

Operating System

Middleware

SysCondition

Mechanism & PropertiesManager

Applications

Operating System

CONTEXT

Appln Server Appln ServerStatic configuration

Need to provide runtime QoS adaptation along functional path

Made feasible using adaptive & reflective middleware

Global, dynamic resource management

35

RACE Control ArchitectureStatic Inputs• Resource (CPU)

utilization set-point<arms:CPUset-

point> 0.8</arms:CPUset-

point>• End-to-end deadlines

<arms:deadline units="ms">800

</arms:deadline>Dynamic Inputs• Current CPU utilization• End-to-end execution

time

RACEController

Resource Utilization (average, per component,

and per host)

String QoS Information

Target Manager

CPU Monitors

Resource Utilization

RACE Control Agent

StringControl Agents

QoS Manager

String QoS Monitors

QoS Information

OS Control Agent

36

RACEController

Resource Utilization (average, per component,

and per host)

String QoS Information

Target Manager

CPU Monitors

Resource Utilization

RACE Control Agent

StringControl Agents

QoS Manager

String QoS Monitors

QoS Information

OS Control Agent

RACE Control ArchitectureProcessing• RACE Controller

• Reallocates resources to meet control objectives

• RACE Control Agent• Maps resource

reallocation to OS/string specific parameters

• Uses OS & string control agents to modify OS/string parameters

37

CUTS Environment for Emulating DRE Systems• Component Workload Emulator

(CoWorkEr) Utilization Test Suite (CUTS) consists of a test network of CoWorkEr nodes

• Outside the test network is a Benchmark Data Collector (BDC) for collecting test metrics

• Makeup & functionality of a CoWorkEr• CCM assembly constructed from CCM

monolithic components• Can perform CPU operations, database

operations & memory allocations & deallocations

• Can perform background workloads• Can send/receive events to/from other

CoWorkErs to form application strings

38

CoWorkEr Behavioral Modeling in CUTS

• I/O Automata used to model behavior using state transitions and actions• WML integrates into I/O automata at the action level• Extends semantics of binding between worker and its actions

39

Measuring the Performance of Components

Time to transmit an event is measured

Time to process an event is measured

Critical paths can be selected & evaluated to determine if end-to-end QoS deadlines are meet

All data is collected by the Benchmark Data Collector (BDC) & stored in a database for offline

evaluation

40

CUTS BMW Utility

• Dynamic updates of test runs• Enables viewing of collected data and metrics

41

CUTS BMW: Observable Metrics

• Test selection based on critical path• Metrics include best, average, worst case timings

42

Observing RACE Control Behavior

• Demonstrates increased load due to “hog string”• Web enabled application of RACE to control QoS

43

F-15productvariant

A/V 8-Bproductvariant

F/A 18productvariant UCAV

productvariant

Product-line architecture

(VI) Optimizations for Product-line Architectures

•PLAs define a framework of components that adhere to a common architectural style with a clean separation of commonalities and appropriate provisions for incorporating variations

•Middleware factors out many reusable general-purpose & domain-specific services from traditional DRE application responsibility

AirFrame

APNav

HUD GPS

IFF

FLIR

Hardware (CPU, Memory, I/O)OS & Network Protocols

Host Infrastructure MiddlewareDistribution Middleware

Common Middleware ServicesDomain-specific Services

Standards middleware is a key technology candidate for supporting and sustaining vision of software product-lines

44

Technology Gaps in Middleware for PLAs

• PLAs have very “focused but crosscutting” requirements of underlying middleware infrastructure• Optimized for the platform• Lean footprint• Efficient configuration & deployment• Support run-time adaptations &

reconfigurations• Standards middleware development &

optimizations philosophy catered to maintaining “generality, wide applicability, portability & reusability”• OS, compiler and hardware independent• e.g., CORBA, J2EE. .NET

• These technology gaps are hindering PLA progress => adverse economic and societal consequences• e.g. shortcomings of pre-postulated

middleware [Jacobsen 04]

Need to tailor and optimize standards middleware for PLAs while continuing to provide standards compliance, portability and flexibility

45

Container

ClientOBJREF

in argsoperation()out args +

return

IDLSTUBS

ORBINTERFACE

IDLSKEL

Object Adapter

ORB CORE GIOP/IIOP/ESIOPS

Component(Servant)

Services

ProtocolInterface

ComponentInterface

ServicesInterface

DIIDSI

Middleware Specialization Catalog

•Domain-specific language (DSL) tools & process for automating the specializations

Specification-imposed specializations• Layer-folding• Constant propagation• Memoization

Framework specializations• Aspect Weaving

techniques• Bridge Reactor• Template method

Protocol• Strategy Messaging,

Wait, Demultiplexing

Deployment platform specializations• Unroll copy loops • Use emulated exceptions• Leverage zero-copy

data transfer buffers

•Development of reusable specialization patterns

•Identifying specialization points in middleware where patterns are applicable

46

Challenge: Lack of Application Context• Missed middleware

optimization opportunities

• Without application context

• Every invocation performs check for locality

• Middleware glue code for both code paths present in all use cases

• Impossible for middleware (alone) to predict application usage

Node Application

Container

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

CH

Receptacle

Facet

Event Sink

Event SourceComponent Home

Component Assembly

Component Remote InvocationCollocated Invocation

Creates

Cannot be solved by operating solely at middleware level!

47

Approach: Supply Application Context w/Models

• Build a global assembly optimizer framework

• Use models to capture & derive application context

• Explicit, e.g., radar & sensor are collocated (user-specified)

• Implicit, e.g., radar & sensor are deployed onto the same node

• Example• Detect components

internal to an assembly• Eliminate overhead of

• Multiple Homes

Node Application

Container

Factory

CHCH

CH

CH

CH

CH

Receptacle

Facet

Event Sink

Event Source

Component Home

Component Assembly

Component Remote InvocationOptimized Invocation

Creates

CH CHCH

48

Workflow MetaModel Domain Specific Workflow Model

Workflow Model Interpreter

Graph Transformation Tool

Inputs to Graph Meta Model Inputs to Graph Execution Engine

Output Modeling Framework

Meta Model DSMs

• Hierarchical

• Enterprise communications applications analysis

• Supports generative programming. Partial views may be useful and can be directly used for for interactive dialog generation tools

• Static Analysis/Constraint checking.

• Validation of a communications application for a specific domain/end user devices

Communications Applications Modeling Environment

50

Research Impact & Future WorkCurrent progress stems from years of iteration, refinement, & successful use

Year1970 2010

Internet

RPC

Micro-kernels

CORBA & DCOM

Real-time (RT)CORBA

Component Models (EJB)

CORBA ComponentModel (CCM)

RT/CCM

DCE

CoSMIC

Long-term Research Directions•High confidence, geographically distributed DRE systems

•Grid applications•Large enterprise systems•Greater focus on platform-independent models

•Heterogeneous systems

Model drivenmiddleware Shape the standards e.g.,

OMG’s Model Driven Architecture (MDA) for DRE systems

Advanced MDE

ACE+TAO

2000 2005

51

Concluding Remarks•Model-Driven Engineering (MDE) is an important emerging generative technology paradigm that addresses key lifecycle challenges of DRE middleware & applications

•OMG PSIG on Model Integrated Computing

•CoSMIC MDE tools are based on the Generic Modeling Environment (GME)•CoSMIC is available from www.dre.vanderbilt.edu/cosmic•GME is available from www.isis.vanderbilt.edu/Projects/gme/default.htm

www.omg.org/news/meetings/tc/agendas/mic.htm

Many hard R&D problems with model-driven engineering remain unresolved!!

EXTRA SLIDES