Toward The Next [ Next [ Next … ] ] Generation of Meta-Modeling Tools Eric Engstrom David Oglesby Kirk Schloegel Honeywell Laboratories Honeywell International, Inc

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs2 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs3 “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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs4 Domain Model GUIs Domain Model Analysis Domain Model Auto Doc Domain Model Auto Code Domain Model Auto Test Domain Model Model-Based Development

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs5 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!

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs6 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs7 Semantics Issue #2 Anything in a model that does not directly relate to “code” can be and will be misinterpreted.

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs8 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs9 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs10 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs11 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs12 Meta-Modeling for DSVLs Issues  Multi-Domain/Multi-Aspect Modeling  COTS Tool Integration  Complete Code / Artifact Generation  Model Reuse

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs13 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs14 Pattern Services Quality-of-Service Analyses Event Analyses Multi-Aspect Modeling Example Software Model Archetypes “Patterns” Thread Model Event Model Service / Contract Model Hardware Model Resource Model Data Flow Model

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs15 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs16 Meta-Modeling for DSVLs Issues  Multi-Domain/Multi-Aspect Modeling  COTS Tool Integration  Complete Code / Artifact Generation  Model Reuse

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs17 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs18 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?

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs19 Meta-Modeling for DSVLs Issues  Multi-Domain/Multi-Aspect Modeling  COTS Tool Integration  Complete Code / Artifact Generation  Model Reuse

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs20 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs21 Type Inference Type Inference procedure Foo(A:some_type) is begin 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 outputs are also models Flow Analysis Template Selection Template Interpretation Example Transformation “Process” Meta-Model(s) Artifact Template(s)

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs22 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?

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs23 Meta-Modeling for DSVLs Issues  Multi-Domain/Multi-Aspect Modeling  COTS Tool Integration  Complete Code / Artifact Generation  Model Reuse

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs24 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?

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs25 Archetypes: Model-Based Patterns  Model reuse  Flexibility  Extensible code generation  Explicitly modeled structure Application-Level QoS Parameters sending object receiving object Max. comm. error prob.: ? Timeliness at recv: ? Sustained rate: ? Safety Impact: ? monitored comm. channel translate application QoS watchdog thread error-handling object notify Example: Publish/Subscribe Pattern with Watchdog as an Archetype:

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs26 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

Honeywell Laboratories OOPSLA 2002 Workshop on DSVLs27 Resources / References  DOME:  GME:  MetaEdit:  OOPSLA Domain Specific Visualization Workshop (2002):  Meta-Modeling Resources: