110 likes | 275 Views
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.
E N D
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 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)
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”
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
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; };
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
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
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