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

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

Model-Driven Architecture A 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: 1.Relevant issue: platform-independence 2.Platform Specific information is used 3.Transformations are models Source: MDA Guide V ( MDA in a Domain-Specific context: 1.Models are not accidental but essential to system development 2.Models are expressed in modeling languages which are, in turn, defined in terms of a meta- model 3.Models undergo transformations during development that lead to executables

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

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

UDM: Metamodeling and generation 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 children() const; }; 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 dst() const; }; class C : public Object { public: static Uml::Class meta; C(); // + Other constructors static C Create(...); Udm::AssocAttr src() const; Udm::ParentAttr parent() const; }; }

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

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

UDM: UML meta-metamodel

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