UDM An Infrastructure for Implementing Domain-Specific Modeling Languages

1. UDM An Infrastructure for Implementing Domain-Specific Modeling Languages Endre Magyari, Arpad Bakay, Andras Lang, Tamas Paka, Attila Vizhanyo, Aditya Agarwal, and Gabor Karsai Institute for Software-Integrated Systems PO.Box 1829B Vanderbilt University Nashville, TN 37235, USA

2. Overview • Domain-Specific MDA • Model-driven Development + Tool Integration • UDM: Unified Data Model • Framework architecture • Metamodeling, generator, back-ends • Capabilities • Metaprogrammability, multiple backends, reflection • Lessons learned

3. Model-Driven ArchitectureA Transformational Paradigm for Software Development • Development process: • Platform Independent Model: a view of the system from a platform independent viewpoint • Platform Specific Model: a view of the system from a platform-specific viewpoint • Key points: • Relevant issue: platform-independence • Platform Specific information is used • Transformations are models • MDA in a Domain-Specific context: • Models are not accidental but essential to system development • Models are expressed in modeling languages which are, in turn, defined in terms of a meta-model • Models undergo transformations during development that lead to executables Source: MDA Guide V 1.0.1 (www.omg.org)

4. Domain-Specific MDADomain-Specific MDA - Model-Integrated Computing Metamodeling Tool Integration Analysis Metamodels Domain models Translation Domain-specific modeling Synthesis & Generation Model-Model Transformations Execution Need: uniform, configurable “data layer”

5. The UDM Framework Metamodeling of data: UML class diagrams Backends: Generic object implementation API Code Generator: Builds C++ “handle” classes Constraint checker: OCL evaluator Reflection: Meta-objects

6. UDM: Metamodeling and generation class Rel : public Object { public: static Uml::Class meta; Rel() // + Other constructors static Rel Create(...); }; class B : public A { public: static Uml::Class meta; B(); // + Other constructors static B Create(...); Udm::AssocAttr<utest::C> dst() const; }; class C : public Object { public: static Uml::Class meta; C(); // + Other constructors static C Create(...); Udm::AssocAttr<utest::B> src() const; Udm::ParentAttr<utest::A> parent() const; }; } namespace utest { class A; class Rel; class B; class C; class A : public Object { public: static Uml::Class meta; A(); // + Other constructors static A Create(...); Udm::ChildrenAttr<utest::C> children() const; };

7. UDM: Backends GEN DTD METAMODEL UDM BACK-END METADATA DOM XML • C++ API: • Classes • Attributes • Associations • … Custom Interface GME GME MEM FILE Uniform Interface CORBA NETWORK

8. UDM: Capabilities • Metaprogrammability: • Data structures are fully defined by the (meta)model • Consistency rules define well-formedness • Multiple backends: • DOM/XML: Data is persisted as XML files • GME/MGA: Direct access to model databases • MEM: Fast/simple objects + binary files • CORBA/NET: Compact network format for data exchange • Reflection: • All UDM Objects have a “meta” attribute pointing to a “meta” objects (instance of Uml::Class or Uml::Assoc…) • The Uml metamodel is always included • APIs are available for discovery and generic operations

9. UDM: UML meta-metamodel

10. Lessons learned • Generic packages (like UDM) are essential if a large number of data models are used • Example: tool integration framework • Performance penalty is acceptable • Uniform access means no change when switching backends (XML, GME, CORBA, etc.) • Generic text interface (parsers and unparsers) are also feasible and useful • Consistency checking of data structures (via OCL) offers new ways for ensuring data integrity • Generic (internal) APIs allow generic tools