Toward The Next [ Next [ Next … ] ] Generation of Meta-Modeling Tools

Toward The Next [ Next [ Next … ] ] Generation ofMeta-Modeling Tools

Eric Engstrom ([email protected])

David Oglesby ([email protected])

Kirk Schloegel ([email protected])

Honeywell LaboratoriesHoneywell International, Inc

Honeywell LaboratoriesOOPSLA 2002

Workshop on DSVLs 2

The “Development” Problem Current system development is high-

risk Very complex Multiple domains Ambiguous requirements Subject to rapid change Building atop ever-more expansive APIs

The middleware trend only complicates this Meta-programming promises the same


Workshop on DSVLs 3

“Tools” to the rescue Common Mantra:

“Let’s use a tool to do ___ for us.”

Build models of systems, fostering: Higher-level descriptions Rapid understanding and evolution Separation of concerns Generation of code and documentation

Caveat: Fool + Tool == Fool


Workshop on DSVLs 4

DomainModel

ModelGUIs

DomainModel

Analysis

DomainModel

Auto Doc

DomainModel

Auto CodeDomainModel

Auto Test

DomainModel

Model-Based Development


Workshop on DSVLs 5

Model Based Development Options Two options:

Use a generic tool/language “applicable” for any domain

e.g. UML, SDL, IDEF, etc

OR Use an application or domain-specific tool

Often limited domain Sometimes lacking a large user-base Yeilding NO COTS!


Workshop on DSVLs 6

Generic Tool Option A “Development” Solution

“Got Models”? Sure!

Often lack clear semantics Without clear semantics, cannot realize

full benefit of Model-Based Development Impose our own semantics

Effectively ad-hoc Often lacking much tool support


Workshop on DSVLs 7

Semantics Issue #2

Anything in a model that does not directly relate to “code” can be and will be misinterpreted.


Workshop on DSVLs 8

Domain-Specific Option (aka DSVL) Mantra Becomes:

“Let’s build our own tool to do ____ for us.”

DSVLs are inherently Model-Based Well suited to our domain Clear semantics Address platform/API issues Auto-generate code


Workshop on DSVLs 9

The “DSVL Development” Problem Building DSVLs suffers from the same

problems as any development effort: Often complex Multiple domains (aka “Aspects”) Ambiguous requirements Subject to rapid change

PLUS: Reinvented infrastructure Lacking clear development methodology


Workshop on DSVLs 10

The DSVL Solution : Meta-Models If DSVLs are so great, how about we

come up with a DSVL for DSVLs? Capture the “essense” of a DSVL Provide infrastructure for strong modeling

semantics Encourage a Model-Based view Support linkages to external tools Codify the generation of code/artifacts



DSVL & Meta-Modeling Perspective Meta-Models can be seen as as DSVL

for DSVLs Examples of tools for this include:

DOME (Honeywell) GME (Vanderbilt University) MetaEdit (MetaCASE)

All allow user to: Specify logical boxes & arrows diagrams Provide code/artifact generation support



Meta-Modeling for DSVLs Issues

Multi-Domain/Multi-Aspect Modeling

COTS Tool Integration

Complete Code / Artifact Generation

Model Reuse



Multi-Domain/-Aspect Modeling Complex systems involve more than

one domain, needing to… capture the cross-domain components of

systems retain domain specific tooling support generate artifacts across domains /

aspects



Pattern Services

Quality-of-Service Analyses

Event Analyses

Multi-Aspect Modeling Example

SoftwareModel

Archetypes“Patterns”

ThreadModel

EventModel

Service /Contract

Model

HardwareModel

ResourceModel

Data FlowModel



Multi-Aspect Modeling Ideas Build larger domain meta-models

Combine all meta-models into one “Union” Model Lose some domain-specificity Evolution of domain meta-models difficult

Build “Type-System” view of meta-models HARD and potentially overly complicated

Build layered, interacting meta-models Represent cross-cutting information Allow new aspects of whole “System Meta-

Model” to be added dynamically







Model Reuse



COTS Tool Integration Companies have large investments in

commercial tools (e.g. Rose) $$$$ (licenses and training) Portfolio of work

DSVLs need to leverage this investment to be accepted share information in both directions cooperative code generation

allow parts of system to be specified in COTS tools



COTS Tool Integration Ideas Build a generic model repository

All tools must store into that

Use common interchange formats XML/XMI?

Use APIs for peer to peer? CORBA? COM? SOAP?

OMG’s MDA?







Model Reuse



Code / Artifact Generation Biggest hurdle to developing DSVLs

Reuse Can generators (or parts of generators) be

shared or reused? Automation

e.g. code generator generators

How to cope with COTS tools and multiple domain systems? Share responsibility with COTS



TypeInference

TypeInference

procedure Foo(A:some_type) isbegin A:=1; B:=2; Lib.Invert(A,B); for I in 1..B loop Lib.Prefrobulate(A,B); end loop;end Foo;generated

artifact

templates and outputsare also models

Flow AnalysisFlow Analysis Template Selection

Template Selection

Template Interpretation

Template Interpretation

Example Transformation “Process”

Meta-Model(s)Meta-Model(s) Artifact Template(s)

Artifact Template(s)



Code / Artifact Generation Ideas Graph Rewriting

Capture input and output “patterns” Search and completion issues Q: Is this easy enough for acceptance?

XML / XSLT Use XML Schemas as Meta Models XML XML via XSLT is transformation Code or documentation is just another

output of an XSLT transform Q: Is XSLT sufficient?







Model Reuse



Model Reuse DSVLs move system design to models

Just as we reuse code,we need to reuse [ portions of ] models

Reuse within a domain Model library containing parts of models

Reuse across domains Model library with hooks into different

domains? Via model transformations?



Archetypes: Model-Based Patterns

Model reuse Flexibility Extensible code

generation Explicitly modeled

structure

Application-LevelQoS Parameters sending

object

receivingobject

Max. comm. error prob.: ?Timeliness at recv: ?Sustained rate: ?Safety Impact: ?

monitored comm. channel

translate

application QoS

watchdogthread

error-handlingobject

notify

Example: Publish/Subscribe Pattern with Watchdog as an Archetype:



Conclusions Meta-Models are like DSVL for DSVLs DSVLs then include generic support

for generation and integration Meta-DSVL toolkits still suffer from

Lack of interaction among DSVLs Poor integration with COTS tools Difficulty of creating code generators Limited of reuse of models and model

elements



Resources / References DOME:

http://www.htc.honeywell.com/dome GME:

http://www.isis.vanderbilt.edu/projects/gme MetaEdit:

http://www.metacase.com

OOPSLA Domain Specific Visualization Workshop (2002): http://www.cis.uab.edu/info/OOPSLA-DSVL2

Meta-Modeling Resources: http://www.metamodel.com

Toward The Next [ Next [ Next … ] ] Generation of Meta-Modeling Tools

Documents

Transcript of Toward The Next [ Next [ Next … ] ] Generation of Meta-Modeling Tools