UDM An Infrastructure for Implementing DomainSpecific Modeling Languages

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 1829 B Vanderbilt University Nashville, TN 37235, USA

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

Model-Driven Architecture A Transformational Paradigm for Software 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 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 metamodel 3. Models undergo transformations during development that lead to executables Source: MDA Guide V 1. 0. 1 (www. omg. org)

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

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 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: : Assoc. Attr<utest: : C> dst() const; }; namespace utest { class A; class Rel; class B; class C; class C : public Object { public: class A : public Object { static Uml: : Class meta; public: C(); // + Other constructors static Uml: : Class meta; static C Create(. . . ); A(); // + Other constructors Udm: : Assoc. Attr<utest: : B> src() const; static A Create(. . . ); Udm: : Parent. Attr<utest: : A> parent() const; Udm: : Children. Attr<utest: : C> children() const; }; }

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

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 l Generic packages (like UDM) are essential if a large number of data models are used – l l l 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