Wednesday Jul 02, 2008

Model Driven Mural/MDM - NetBeans UML & Code Generation

Read this for background.

UML Class Diagram

Here's the UML example I will use for illustration purposes in the upcoming posts: it shows a composition of three classes representing a Patient. We'll revisit this diagram later once we know more about the MDM configuration.

There are a couple of noticeable things on this diagram:

  • The Patient class's stereotype is MDM_Root
  • One of the patient class's attribute is tagged as a primary key
  • Some of the attributes have tagged values like size or matchType
  • The classes Address and Phone are associated with the Patient class and this association is navigable.
I will explain the reasons for these additions to the model later on - for now the important thing to note is that the model contains this additional information to the basic class information.

Understanding NetBeans UML Code Generation

The first step on achieving Model Driven Development (MDD) bliss with Mural is to actually understand how the NetBeans template library and the UML module work.

Luckily somebody else already wrote an excellent article on the basics -NetBeans UML Custom Code Generation.

Let me just paraphrase the article before I'll add some additional points:

  • Templates used for code generation are Freemaker templates - so it's handy to have the link to the reference close by. There is also a Freemaker NetBeans Plug In referenced in the code generation tutorial.
  • There are a couple of NetBeans tools involved in the process the Template Manager, UML Options Panel (Templates tab) and UML Project Properties (Templates section). The article talks you through all these tools in detail.
    • Template Manager: add/manage template files used by different NetBeans Plug Ins. Here we will add our MDM templates.
    • UML Options Panel: here we will map our templates to a type of model component and UML stereotype
    • UML Project Properties: we will have to enable the templates we have created on a per project basis.
The article guides you through all the necessary steps to add a set of templates (EJB SLSB) to NetBeans. The interesting part here is that the way the templates are set up they are applied to classes with a certain stereotype. It looks like we will have to add our own steretype for MDM type elements. The sample templates are a bit more straightforward to understand than the templates shipped with the UML Plug In so this is a good starting point to gain an understanding how the code generation works.

Understanding the Source Data Model & Developing Templates

While the article makes a good job at describing the nuts and bolts of the tooling it doesn't actually explain how the EJB templates were developed in the first place. There are two areas one needs to know about in oder to understand and create templates:

  • Framemaker Scripting - hence the link above
  • Source Data Model - this is briefly described in the tutorial and the description mentions classInfo and modelElement

Knowing more about the latter will help tremendously in developing templates. Both classInfo and modelElement refer to the same UML object. They will contain the information from the model of the UML object (class, interface etc.) that code generation is run for. classInfo is an instance of class This class is actually an abstraction of the underlying UML model - it exposes a sub set of the available information that is deemed to be relevant for generating Java Code. It actually acts as a wrapper around another class that provides fine grained access to the underlying UML model.
Therefore every time one needs to access UML attributes like "tagged values" or "stereotype" or "primary key" one needs to get hold of an instance of the underlying fine grained class.
modelElement is just this - an instance of the underlying fine-grained class.

The same model applies to other elements like class attributes or methods. Here's a table of the most important classes. I have included links to the source code of these classes as this proved to be the best reference I could find (there is definitely no Javadoc for the simplified API and I couldn't locate a Javadoc for the fine-grained interfaces yet)

UML Type

 Fine Grained Representation

 Simplified Representation








Each of the Simplfied interfaces provides access to the underlying Fine Grained interface, e.g. ClassInfo offers a "getClassElement()" method just as MemberInfo provides a "getAttribute()" method.

Template Examples

Let's look at some template examples to see how these classes are used:

The example below renders some XML for the class that code generation is run on. I've highlighted how the classInfo itself is used, how the member variables/attributes of the class are accessed and how to get hold of the underlying object implementing IAttribute  to obtain Tagged Values that were added in the UML diagram.

<#list classInfo.getFieldsCodeGenSorted() as fieldInfo > 
    <#if fieldInfo.getAttribute().getTaggedValueByName("size")?? >

There are navigable relationships in our class diagram so here's an example how to follow these relationships (this is going to be important since all of the domain object model needs to be represented in MDM). All of the code below actually uses the fine-grained access to the UML model.

In the example we first obtain all relationships of the element then use the other end of the relationship to obtain information about the element/class that is associated with current element/class.

<#list modelElement.getAssociationEnds() as thisEnd > 
<#list thisEnd.getOtherEnd() as otherEnd > 
<#list otherEnd.getParticipant().getAttributes() as elem > 

Tuesday Jul 01, 2008

A Model Driven Approach to using Mural/MDM

Some Background

In the context of my work for the OeHF an interesting idea came up from the foundation partners. OeHF is about building an open source framework for Healthcare applications. The core of such a framework is a lot of patient related data from diverse sources like e.g. patient demographics, visit data, medical records.
All of these sources apply their own local patient identifier and patient specific data  - somehow all these bits of data need to be matched and merged. The framework therefore requires to have some kind of Single Patient View tieing together all of this information. Sounds like Mural is a very good fit for these requirements.

So we were discussing how we could integrate Mural/MDM into the architecture and the question came up if it is possible to drive Mural from UML diagrams. Since we don't want to pass MDM objects all around our application the idea is to model the business objects and then derive a mural application from the classes.
As a consequence there's a requirement for a  Single Patient View adapter implementing a domain object centric interface and mapping the domain objects into the mural data model.

That potentially means a lot of Java mappings on quite similar and possibly complex data structures (in the case of OeHF the data structures will be aligned to the HL7 data model). So avoiding to code and maintain these mappings manually became another motivating factor for looking into how model driven development could be applied to Mural/MDM.

The Road Ahead

In a nutshell we'll need to come up with a way of generating Java code and XML configuration files from a NetBeans UML model. Ideally the resulting artefacts should be propagated into the appropriate projects and integrating the build cycles of these projects would be another nice to have.

Here's what we'd need to find out and do in order to make this happen:

  • Understand the UML code generation mechanism
  • Understand the MDM configuration files and which of these can be generated from the model
  • Develop a sample UML model and define required conventions for additional MDM related information required by the configuration files
  • Implement templates for the configuration files
  • Design and implement a solution to also generate the Java mappings from object model to MDM and vice versa
  • Possibly integrate generated component into build processes of the relevant projects
I'll tackle all the points above in subsequent posts to the blog in some form of step by step guide. So please bear with me.


Swen, resident alien in the UK based part of a team at SUN called FAST


Top Tags
« July 2016