This wiki has undergone a migration to Confluence found Here
Difference between revisions of "MIF based code generation"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| 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. | + | Code generation is a process whereby the source code (in a particular programming language) is automatically generated. It is an example of [[MDD|Model Driven Software Design]]. 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 most [[RIMBAA]] applications. |
*An alternative code generation method is [[Schema based code generation]]. | *An alternative code generation method is [[Schema based code generation]]. | ||
| − | == | + | ==Analysis== |
The primary source for the code generation is 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 is the primary meta model format as used for HL7 version 3. | #'''[[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. | ||
| Line 11: | Line 11: | ||
===Overview=== | ===Overview=== | ||
| + | The figure below shows some of the functional programming units contained in RIMBAA applications. | ||
[[Image:Mif code gen.JPG]] | [[Image:Mif code gen.JPG]] | ||
| − | + | The programming units include: | |
| − | + | #Target Model: the payload message type of an interaction. | |
| − | *Lesson learned: Preserve all information in MIF into the framework, including documentation. | + | #*Could be either MIF or DSL |
| − | *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. | + | #*Lesson learned (Mohawk, MIF): Preserve all information in MIF into the framework, including documentation. |
| + | #*Lesson learned (Mohawk, DSL): 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. | ||
| + | #Vocabulary: vocabulary definitions and CTS services | ||
| + | #Datatypes: custom library with support for HL7 v3 datatypes R1 and/or R2. | ||
| + | #*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. | ||
| + | #*Reusable model components: common class models (e.g. CMETs, wrappers) | ||
===Code Re-use=== | ===Code Re-use=== | ||
| Line 25: | Line 31: | ||
===UML as an alternate format=== | ===UML as an alternate format=== | ||
| − | + | 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. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | All HL7 concepts can be expressed in UML because of 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. Two profiles are being used: | |
| + | #HDF profile | ||
| + | #RIM profile that allows the tracking of clones to the RIM and to store the class/type and moodCode which would a look redundant to an audience outside HL7. | ||
==Discussion== | ==Discussion== | ||
Revision as of 16:20, 3 March 2010
Contents
Summary
Code generation is a process whereby the source code (in a particular programming language) is automatically generated. It is an example of Model Driven Software Design. 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 most RIMBAA applications.
- An alternative code generation method is Schema based code generation.
Analysis
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 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.
- 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
The figure below shows some of the functional programming units contained in RIMBAA applications.
The programming units include:
- Target Model: the payload message type of an interaction.
- Could be either MIF or DSL
- Lesson learned (Mohawk, MIF): Preserve all information in MIF into the framework, including documentation.
- Lesson learned (Mohawk, DSL): 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.
- Vocabulary: vocabulary definitions and CTS services
- Datatypes: custom library with support for HL7 v3 datatypes R1 and/or R2.
- 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.
- Reusable model components: common class models (e.g. CMETs, wrappers)
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
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.
All HL7 concepts can be expressed in UML because of 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. Two profiles are being used:
- HDF profile
- RIM profile that allows the tracking of clones to the RIM and to store the class/type and moodCode which would a look redundant to an audience outside HL7.
