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

1. Toward The Next [ Next[ Next … ] ] Generation ofMeta-Modeling Tools Eric Engstrom (eric.engstrom@honeywell.com) David Oglesby (david.oglesby@honeywell.com) Kirk Schloegel (kirk.schloegel@honeywell.com) Honeywell LaboratoriesHoneywell International, Inc

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 OOPSLA 2002Workshop 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 OOPSLA 2002Workshop on DSVLs

4. Auto Doc Model GUIs Domain Model Domain Model Domain Model Domain Model Domain Model Domain Model Auto Code Analysis Auto Test Model-Based Development OOPSLA 2002Workshop 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! OOPSLA 2002Workshop 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 OOPSLA 2002Workshop on DSVLs

7. Semantics Issue #2 Anything in a model that does not directly relate to “code” can be and will be misinterpreted. OOPSLA 2002Workshop 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 OOPSLA 2002Workshop 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 OOPSLA 2002Workshop 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 OOPSLA 2002Workshop on DSVLs

11. 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 OOPSLA 2002Workshop on DSVLs

12. Meta-Modeling for DSVLs Issues • Multi-Domain/Multi-Aspect Modeling • COTS Tool Integration • Complete Code / Artifact Generation • Model Reuse OOPSLA 2002Workshop on DSVLs

13. 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 OOPSLA 2002Workshop on DSVLs

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

15. 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 OOPSLA 2002Workshop on DSVLs

16. Meta-Modeling for DSVLs Issues • Multi-Domain/Multi-Aspect Modeling • COTS Tool Integration • Complete Code / Artifact Generation • Model Reuse OOPSLA 2002Workshop on DSVLs

17. 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 OOPSLA 2002Workshop on DSVLs

18. 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? OOPSLA 2002Workshop on DSVLs

19. Meta-Modeling for DSVLs Issues • Multi-Domain/Multi-Aspect Modeling • COTS Tool Integration • Complete Code / Artifact Generation • Model Reuse OOPSLA 2002Workshop on DSVLs

20. 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 OOPSLA 2002Workshop on DSVLs

21. Example Transformation “Process” Meta-Model(s) Artifact Template(s) Flow Analysis Type Inference Template Selection Template Interpretation templates and outputs are also models 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 OOPSLA 2002Workshop on DSVLs

22. 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? OOPSLA 2002Workshop on DSVLs

23. Meta-Modeling for DSVLs Issues • Multi-Domain/Multi-Aspect Modeling • COTS Tool Integration • Complete Code / Artifact Generation • Model Reuse OOPSLA 2002Workshop on DSVLs

24. 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? OOPSLA 2002Workshop on DSVLs

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

26. 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 OOPSLA 2002Workshop on DSVLs

27. 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 OOPSLA 2002Workshop on DSVLs