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

Difference between revisions of "UML ITS Policy"

From HL7Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
==Summary==
 
==Summary==
  
−
The UML ITS is a technical infrastructure for making V3 wire formats easier to implement.  
+
The [[UML ITS]] is a technical infrastructure for making V3 wire formats easier to implement.  
  
 
  [[RBM]] <--'''Policies'''--> [[XUM]] [[Implementable Models]] (UML diagram <-> Schema)
 
  [[RBM]] <--'''Policies'''--> [[XUM]] [[Implementable Models]] (UML diagram <-> Schema)
Line 12: Line 12:
  
 
We must decide whether to:
 
We must decide whether to:
−
* [[flatten the instances]]
+
* flatten the instances
−
* [[Use business names in the instance]]
+
* Use business names in the instance
−
* [[Send fixed and default values]]
+
* Send fixed and default values
−
* [[Support By References and By Value]]
+
* Support By References and By Value
  
 
And we must also decide which kind of model(s) to create XUM's for. The [[XUM Creation Level]]
 
And we must also decide which kind of model(s) to create XUM's for. The [[XUM Creation Level]]
 
document considers this most important issue in depth.
 
document considers this most important issue in depth.
 +
 +
==Specific vs Generic==
 +
 +
==Flattening the Instances==
 +
 +
The instances are deeply nested, they follow the RIM grammar structure. This is sometimes more
 +
nested that than the real world problems, and this is often a problem for implementors, who
 +
don't fully appreciate the benefits of the RIM. And for those doing specific processing, this
 +
will probably always be the case - the global interoperability features of the RIM are not
 +
useful to them.
 +
 +
Initial the models suggests that 1..1 associations can be collapsed to save nesting of models.
 +
Advantages:
 +
* saves time and complexity in the messages
 +
Disadvantages:
 +
* prevents generic understanding of the messages
 +
* reduces reusability of code
 +
* cannot be consistent and maintain existing model boundaries
 +
* is a problem for InfrastructureRoot attributes, there is name clashes and scope clashes. Though the scope is clear in abstract, it's much more difficult in the implementation, which is what this is all about
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
The XML ITS includes a number of 'secret' transforms (actually, they are not secret, but they are exceedingly poorly documented). The UML ITS proposes to be extremely specific about the wire format, in the recognition that it's the wire format that users actually finally encounter and must master. It's goal is to be able to go to an implementer and offer them a "thing" they can use, an implementable model. The implementable model will be '''normative''' and will be published as UML and XML schema.
 +
 +
There may be a number of implementation decisions and transforms made between the [[RBM]] and the on-the-wire format. These are made before the UML and schema are built, and are explicit in them. These changes are discussed in [[UML ITS Policy]].
 +
 +
 +
The output of the ITS can be used for code generation. It will be tested with common tools. The XUM works with the commonly used tools, and it correctly specifies the wire format. It doesn't completely describe the validation rules for the message, no schema or UML model will be able to do that, because the HL7 models rely heavily on terminology.  A XUM consists of a pair of schemas and UML diagrams that specify the exact same wire format, implementers can code generate from them and exchange data. WYSIWYG: What you see in the schema or in the diagram, is exactly what goes on the wire.
 +
 +
There is existing work outside HL7 on the question of transforming from UML diagrams to an XML instance or a schema. The UML ITS is intended to leverage this work
 +
(One of the existing issues is that UML to XSD transform requires sequencing of the associations, which is a "bit of magic", but does need to be represented explicitly).
 +
 +
 +
 +
==Summary==
 +
 +
The '''UML ITS''' (Release 2 thereof) is a proposal by NHS CfH to ease the implementation burden for v3 artefacts. This is achieved by simplifying the on-the-wire format as well as using UML based models which can be used for code generation. Note that the proposal has not yet met the [[ITS Acceptance Factors]].
 +
 +
The intent of this page is to give a ''high level overview of the proposed new UML ITS''. Considerations, open questions, and comparisons with other approaches won't be described in any detail. See the [http://www.hl7.org/library/committees/inm/NewITS%2DSummaryProposals%5Fv0%2D6%2Edoc UML ITS Proposal v0.6] for a status report on the project that is driving the UML ITS.
 +
 +
==Summary==
 +
 +
The Goal of the new ITS is to be able to go to an implementer and offer them a "thing" they can use, an implementable model. The implementable models (the product of the transformation described by the ITS in the form of UML + schema) will be '''normative'''. The new ITS will include explicit transformations to address implementation concerns, e.g. to use an on the wire format that is as minimalistic as possible. The output of the ITS can be used for cde generation.
 +
 +
The UML ITS has 2 parts.
 +
* a technical infrastructure for making wire formats easier to implement. See [[UML ITS Technical]]
 +
* transformations applied to the V3 concepts from RBM to wire format to most suit implementors. See [[UML ITS Policy]]
 +
 +
The technical infrastructure applies whichever transformations are chosen to assist the implementers.
 +
 +
== History ==
 +
 +
The UML ITS is a non-linear development of the existing UML Object Definition, and solves a number of problems that
 +
were identified in the first release that prevent either further linear development, or implementation.
 +
 +
The work for the UML ITS is being sponsored by the UK CfH in the hope that the UML ITS can address a number
 +
of the implementation issues that the NHS has identified.
 +
 +
 +
== Other stuff ==
 +
 +
All the rest of the content of this page is to be moved to one of the 2 links above.
 +
 +
The Goal of the new ITS is to be able to go to an implementer and offer them a "thing" they can use, an implementable model. The implementable models (the product of the transformation described by the ITS in the form of UML + schema) will be '''normative'''. The new ITS will include explicit transformations to address implementation concerns, e.g. to use an on the wire format that is as minimalistic as possible. The output of the ITS can be used for cde generation.
 +
 +
[[RBM]] <---> [[XUM]] [[Implementable Models]] (UML diagram <-> Schema)
 +
 +
The UML ITS transforms a HL7 model to a a [[XUM]] (the implementable model, expressed both in terms of an implementable UML model as well as an implementable schema) and then to a message. The XUM works with the commonly used tools, and it correctly specifies the wire format. It doesn't completely describe the validation rules for the message, no schema or UML model will be able to do that, because the HL7 models rely heavily on terminology.  A XUM consists of a pair of schemas and UML diagrams that specify the exact same wire format, implementers can code generate from them and exchange data. WYSIWYG: What you see in the schema or in the diagram, is exactly what goes on the wire.
 +
 +
There is existing work outside HL7 on the question of transforming from UML diagrams to an XML instance or a schema. The UML ITS is intended to leverage this work
 +
(One of the existing issues is that UML to XSD transform requires sequencing of the associations, which is a "bit of magic", but does need to be represented explicitly.
 +
 +
The transformations that applied during the process from the [[RBM]]s to the wire format are done '''before''' we create the implementable model, so these transforms are made explicit, and there is no surprises for the implementer. The transformation from RBM to XUM is deterministic, so it will be possible to go back from UML to the RBM.
 +
 +
The transformation between the [[RBM]] and the implementable model could include optimizations of the model in order to address implementation concerns, e.g.
 +
*'''Sending of fixed and default values, especially structural codes.'''
 +
*'''Flatten RIM constructs''', e.g. telescope attributes of an associated class into other class,
 +
*'''Add business (or: local) names'''. e.g. for "effectoveTime"
 +
 +
These issues are discussed in [[optimising wire formats for users]]
 +
 +
The new UML ITS creates a model that only contains that which is needed on the wire. It contains less XML elements than the XML ITS. I doesn't follow RIM gramatical structure/grammar, they are not needed on the wire. This approach is possible because you can go back from the implementable model to the RBM.
 +
 +
Code generation based on flattened (UML-) implementable model.
 +
 +
==[[Serialization]] Details==
 +
 +
Which RBM do we use (RIM, DMIM, RMIM, MT, template?) for [[serialization]]. Same concept at every point. XML ITS uses MT. DMIM may be best level. fits best with SOA services model. There are arguments for RIM based serialization without using local names. Lots of different names makes implementation more difficult, e.g. dozens of xPaths to identify things in similar model, more need for documentation. If one chooses RIM, then all other models become "templates". Raises issue of assigning semantics to clone names again, many current models aren't deterministic.
 +
 +
Reading the instance with the definition. Need to consult the definition on order to understand the instance.
 +
 +
The relationship between the instance and the meaning indeterminant in the absence of the model.
 +
*RIM based, no need for any definition;
 +
*full fledged RBM-based serialization including all structured codes, no need for definition;
 +
*RBM-based serialization without structured codes, need to consult definition - current positition
 +
 +
==Related==
 +
 +
The proposal has associated proposals for related issues (that are not purely ITS-related, but are a prerequisite for the ITS to work). These are:
 +
*Datypes R2 Isues
 +
*nullFlavor cleanup. Cascading of associations which lead up to a class with an important attribute. Can be dealt with by making everyting mandatory BTW.
 +
*templateId
 +
*(general approach) Could be RBM -> Flattened Model -> apply any ITS
 +
*(XML ITS) create normative schema?
 +
*Sutructured attribute. Currently no need to be on the wire - requires that receiver has to know model in order to process the message. Generic processing requires that one knows the struc codes (e.g. Java SIG code), looking them up carries implementation /performance overhead. Want to have everything in the instance. Discussion in MnM.

Latest revision as of 05:41, 9 November 2006

Summary

The UML ITS is a technical infrastructure for making V3 wire formats easier to implement. 

RBM <--Policies--> XUM Implementable Models (UML diagram <-> Schema)

One of the important things about the XUM is that it makes the implicit transforms that happen between the RBM and the actual wire format explicit. Some of these transforms are required by the existing methodology, but a number of possible tranforms and policy decisions that might improve the implementation experience for some users have been identified.

We must decide whether to:

  • flatten the instances
  • Use business names in the instance
  • Send fixed and default values
  • Support By References and By Value

And we must also decide which kind of model(s) to create XUM's for. The XUM Creation Level document considers this most important issue in depth.

Specific vs Generic

Flattening the Instances

The instances are deeply nested, they follow the RIM grammar structure. This is sometimes more nested that than the real world problems, and this is often a problem for implementors, who don't fully appreciate the benefits of the RIM. And for those doing specific processing, this will probably always be the case - the global interoperability features of the RIM are not useful to them.

Initial the models suggests that 1..1 associations can be collapsed to save nesting of models. Advantages:

  • saves time and complexity in the messages

Disadvantages:

  • prevents generic understanding of the messages
  • reduces reusability of code
  • cannot be consistent and maintain existing model boundaries
  • is a problem for InfrastructureRoot attributes, there is name clashes and scope clashes. Though the scope is clear in abstract, it's much more difficult in the implementation, which is what this is all about








The XML ITS includes a number of 'secret' transforms (actually, they are not secret, but they are exceedingly poorly documented). The UML ITS proposes to be extremely specific about the wire format, in the recognition that it's the wire format that users actually finally encounter and must master. It's goal is to be able to go to an implementer and offer them a "thing" they can use, an implementable model. The implementable model will be normative and will be published as UML and XML schema.

There may be a number of implementation decisions and transforms made between the RBM and the on-the-wire format. These are made before the UML and schema are built, and are explicit in them. These changes are discussed in UML ITS Policy.


The output of the ITS can be used for code generation. It will be tested with common tools. The XUM works with the commonly used tools, and it correctly specifies the wire format. It doesn't completely describe the validation rules for the message, no schema or UML model will be able to do that, because the HL7 models rely heavily on terminology. A XUM consists of a pair of schemas and UML diagrams that specify the exact same wire format, implementers can code generate from them and exchange data. WYSIWYG: What you see in the schema or in the diagram, is exactly what goes on the wire.

There is existing work outside HL7 on the question of transforming from UML diagrams to an XML instance or a schema. The UML ITS is intended to leverage this work (One of the existing issues is that UML to XSD transform requires sequencing of the associations, which is a "bit of magic", but does need to be represented explicitly).


Summary

The UML ITS (Release 2 thereof) is a proposal by NHS CfH to ease the implementation burden for v3 artefacts. This is achieved by simplifying the on-the-wire format as well as using UML based models which can be used for code generation. Note that the proposal has not yet met the ITS Acceptance Factors.

The intent of this page is to give a high level overview of the proposed new UML ITS. Considerations, open questions, and comparisons with other approaches won't be described in any detail. See the UML ITS Proposal v0.6 for a status report on the project that is driving the UML ITS.

Summary

The Goal of the new ITS is to be able to go to an implementer and offer them a "thing" they can use, an implementable model. The implementable models (the product of the transformation described by the ITS in the form of UML + schema) will be normative. The new ITS will include explicit transformations to address implementation concerns, e.g. to use an on the wire format that is as minimalistic as possible. The output of the ITS can be used for cde generation.

The UML ITS has 2 parts.

  • a technical infrastructure for making wire formats easier to implement. See UML ITS Technical
  • transformations applied to the V3 concepts from RBM to wire format to most suit implementors. See UML ITS Policy

The technical infrastructure applies whichever transformations are chosen to assist the implementers.

History

The UML ITS is a non-linear development of the existing UML Object Definition, and solves a number of problems that were identified in the first release that prevent either further linear development, or implementation.

The work for the UML ITS is being sponsored by the UK CfH in the hope that the UML ITS can address a number of the implementation issues that the NHS has identified.


Other stuff

All the rest of the content of this page is to be moved to one of the 2 links above.

The Goal of the new ITS is to be able to go to an implementer and offer them a "thing" they can use, an implementable model. The implementable models (the product of the transformation described by the ITS in the form of UML + schema) will be normative. The new ITS will include explicit transformations to address implementation concerns, e.g. to use an on the wire format that is as minimalistic as possible. The output of the ITS can be used for cde generation. 

RBM <---> XUM Implementable Models (UML diagram <-> Schema)

The UML ITS transforms a HL7 model to a a XUM (the implementable model, expressed both in terms of an implementable UML model as well as an implementable schema) and then to a message. The XUM works with the commonly used tools, and it correctly specifies the wire format. It doesn't completely describe the validation rules for the message, no schema or UML model will be able to do that, because the HL7 models rely heavily on terminology. A XUM consists of a pair of schemas and UML diagrams that specify the exact same wire format, implementers can code generate from them and exchange data. WYSIWYG: What you see in the schema or in the diagram, is exactly what goes on the wire.

There is existing work outside HL7 on the question of transforming from UML diagrams to an XML instance or a schema. The UML ITS is intended to leverage this work (One of the existing issues is that UML to XSD transform requires sequencing of the associations, which is a "bit of magic", but does need to be represented explicitly.

The transformations that applied during the process from the RBMs to the wire format are done before we create the implementable model, so these transforms are made explicit, and there is no surprises for the implementer. The transformation from RBM to XUM is deterministic, so it will be possible to go back from UML to the RBM.

The transformation between the RBM and the implementable model could include optimizations of the model in order to address implementation concerns, e.g.

  • Sending of fixed and default values, especially structural codes.
  • Flatten RIM constructs, e.g. telescope attributes of an associated class into other class,
  • Add business (or: local) names. e.g. for "effectoveTime"

These issues are discussed in optimising wire formats for users

The new UML ITS creates a model that only contains that which is needed on the wire. It contains less XML elements than the XML ITS. I doesn't follow RIM gramatical structure/grammar, they are not needed on the wire. This approach is possible because you can go back from the implementable model to the RBM.

Code generation based on flattened (UML-) implementable model.

Serialization Details

Which RBM do we use (RIM, DMIM, RMIM, MT, template?) for serialization. Same concept at every point. XML ITS uses MT. DMIM may be best level. fits best with SOA services model. There are arguments for RIM based serialization without using local names. Lots of different names makes implementation more difficult, e.g. dozens of xPaths to identify things in similar model, more need for documentation. If one chooses RIM, then all other models become "templates". Raises issue of assigning semantics to clone names again, many current models aren't deterministic.

Reading the instance with the definition. Need to consult the definition on order to understand the instance.

The relationship between the instance and the meaning indeterminant in the absence of the model.

  • RIM based, no need for any definition;
  • full fledged RBM-based serialization including all structured codes, no need for definition;
  • RBM-based serialization without structured codes, need to consult definition - current positition

Related

The proposal has associated proposals for related issues (that are not purely ITS-related, but are a prerequisite for the ITS to work). These are:

  • Datypes R2 Isues
  • nullFlavor cleanup. Cascading of associations which lead up to a class with an important attribute. Can be dealt with by making everyting mandatory BTW.
  • templateId
  • (general approach) Could be RBM -> Flattened Model -> apply any ITS
  • (XML ITS) create normative schema?
  • Sutructured attribute. Currently no need to be on the wire - requires that receiver has to know model in order to process the message. Generic processing requires that one knows the struc codes (e.g. Java SIG code), looking them up carries implementation /performance overhead. Want to have everything in the instance. Discussion in MnM.
Retrieved from "https://wiki.hl7.org/w/index.php?title=UML_ITS_Policy&oldid=9795"