This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "MIF based code generation"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
[[category:RIMBAA Issue]]  
 
[[category:RIMBAA Issue]]  
 
==Summary==
 
==Summary==
−
When it comes to code generation the best (most complete) code should be generated from the [[MIF]]. Code Generation tends to be a mechanism for the creation of [[RIMBAA]] applications.
+
When it comes to [[code generation]] the best (most complete) code should be generated from the [[MIF]]. Code Generation tends to be a mechanism for the creation of [[RIMBAA]] applications.
 
*An alternative code generation method is [[Schema based code generation]].
 
*An alternative code generation method is [[Schema based code generation]].
  
−
==Analysis==
+
==Details==
−
The primary source for the code generation is likely to be one of the options shown below:
+
The primary source for the code generation is one of the options shown below:
−
#'''MIF''' - the code generator has to be aware of the structure of the MIF
+
#'''[[MIF]]''' - the code generator has to be aware of the structure of the MIF. MIF is the primary meta model format as used for HL7 version 3.
−
#'''alternate model representation format''' - the code generator has to be aware of the alternate model representation format (e.g. UML, inclusive of a few extensions that are v3 specific, or EMF in Eclipse). The alternate model representation format is a transformation of the MIF.
+
#*See [[MIF]] for a more detailed description, as well as some notes on the current lack of a formal constraint language in HL7 v3.
 +
#'''alternate model representation format''' - the code generator has to be aware of the alternate model representation format (e.g. UML, inclusive of a few extensions that are v3 specific, EMF in Eclipse, OWL). The alternate model representation format is a transformation of the MIF.
  
 
===Overview===
 
===Overview===
Line 20: Line 21:
 
*Separating code for the wrappers from the code for the payload model. Wrapper models are shared by lost of interactions  
 
*Separating code for the wrappers from the code for the payload model. Wrapper models are shared by lost of interactions  
 
*Creating a separate library with code to support CMETs. The library could make use of the fact that CMETs have a spezialization hierarchy, i.e. CMETs with an identified flavour are a spezialization of identified-confirmable, which in turn is a psecialization of thye universal flavour of the CMET.
 
*Creating a separate library with code to support CMETs. The library could make use of the fact that CMETs have a spezialization hierarchy, i.e. CMETs with an identified flavour are a spezialization of identified-confirmable, which in turn is a psecialization of thye universal flavour of the CMET.
−
 
−
===Open Issues===
 
−
There are a number of open issues related to MIFs that may cause problems when using MIF based code generation:
 
−
#MIFs aren't stable nor normative. 
 
−
#Incompatible MIF versions (no guaranteed backwards compatibility, only guaranteed transformability -both ways). If one has a tool which supports a newer MIF version than the MIFs one has, one has to create new MIFs from the original HMDs. Effectively this turns HMD into the source of all truth, not MIF. MIF transform XSLTs can be found in the v3generator package on GForge, in the toolfiles directory.
 
−
#Lack of a formal constraints language: (e.g. [http://en.wikipedia.org/wiki/Object_Constraint_Language OCL], or [http://nrl.sourceforge.net/ NLR]). Constraints in R-MIM are phrased in human language, not in software processable terms.
 
−
#*Lloyd: Need tools to help people author and validate requirement; without that there's not a lot we can do.
 
−
#*Ravi: The SMD roadmap supports this (authoring and validating OCL constraints) and at the moment (February 2010) we have hooks to capture them. We are currently not persisting them for further validation.
 
−
#Currently there is no usable datatypes MIF file. A library to support the v3 datatypes has to be developed as a piece of custom code
 
  
 
===UML as an alternate format===
 
===UML as an alternate format===

Revision as of 12:54, 15 February 2010

Summary

When it comes to code generation the best (most complete) code should be generated from the MIF. Code Generation tends to be a mechanism for the creation of RIMBAA applications.

Details

The primary source for the code generation is one of the options shown below:

  1. MIF - the code generator has to be aware of the structure of the MIF. MIF is the primary meta model format as used for HL7 version 3.
    • See MIF for a more detailed description, as well as some notes on the current lack of a formal constraint language in HL7 v3.
  2. alternate model representation format - the code generator has to be aware of the alternate model representation format (e.g. UML, inclusive of a few extensions that are v3 specific, EMF in Eclipse, OWL). The alternate model representation format is a transformation of the MIF.

Overview

Mif code gen.JPG

  • Lesson learned: Preserve all information in MIF into the framework, including documentation.
  • Lesson learned: tried to only use business names, but had to switch back to pure RIM semantics. People couldn't understand the business names, no consistent use. Mixture of RIM terms and business names doesn't work. have to do either/or. Ann confirms that UK had similar experience. In other words: either use a DSL (ONLY) or use CIMs. Don't mix them.

Code Re-use

Re-use of code can be based on

  • Separating code for the wrappers from the code for the payload model. Wrapper models are shared by lost of interactions
  • Creating a separate library with code to support CMETs. The library could make use of the fact that CMETs have a spezialization hierarchy, i.e. CMETs with an identified flavour are a spezialization of identified-confirmable, which in turn is a psecialization of thye universal flavour of the CMET.

UML as an alternate format

Galen Mulrooney/Dave Carlson/Iona (all involved on behalf of the VA): These software components are being built as part of the Open Health Tools project, "Modeling Tools for Healthcare", which is an open-source project to produce tooling that can be used by Standards Development Organizations to produce and publish interoperability specifications (i.e., Messaging, Documents, SOA) using UML and other Open Standards-based platforms.

Anyone concerned that we cannot represent HL7 concepts in UML ignores the fact that UML can be extended using something called a "UML profile". When RIM.coremif is imported all the HL7-specific extensions are imported into stereotype properties. Nothing is lost. We are using two profiles:

  1. HDF profile based on the profile authored by Abdul Malik, if you recall, some time ago
  2. RIM profile that allows us to track clones to the RIM and to store the class/type and moodCode which would a look redundant to an audience outside HL7.

To install and use these profiles (along with the vocabulary and abstract datatypes) you need update Eclise-based UML 2 tool and install the HL7 plugin as specified in: RSM Quickstart.doc. IBM is providing free RSM licenses for those who need UML tools for HL7 standard development (DAM, DIM, etc.).

If you wish to learn more about the UML extensions and how they are represented as UML stereotypes, please take a look at: UML BOF Wiki.

The HL7 plugin will be maintained and improved by the Open Health Tools' Modeling Tools for Healthcare project.

We have imported RIM.coremif into UML and checked into SVN at: this directory (RIM.emx).

Discussion

Retrieved from "https://wiki.hl7.org/w/index.php?title=MIF_based_code_generation&oldid=32844"