Derived Static Model Designer Architecture

Introduction

This page contains "desirements" for defining an Eclipse-based architecture for a static model designer (hereinafter the "EMD" ) whose contents are derived from the HL7 RIM and/or a static model that is, in turn, derived from the RIM. This information is intended to be the basis for an architecture outline being requested of an Eclipse-knowledgeable advisor to help guide Tooling strategy for HL7.

Premises

The following are the base assumptions made by the author.

1. Model Interchange Format (MIF 2.2) SHOULD be the source and output format for:
   • the "base content" (RIM, vocabulary and data types) used as reference for and to configure the designer;

   • the static model from which the new model is being derived (if the derivation is not directly from the RIM); and

   • the model being designed.

2. All "elements" defined in the MIF Schema SHOULD be represented as "classes" in the software, although "flattening" of the class structure may be used to reduce the class count, and "collection" classes may be added to aggregate such things as all of the coded concepts in a code system.

3. The ability to use EMF to generate code structures based on MIF 2.2 schema generations was demonstrated in a trial documented as Eclipse Code Generation for HL7 Applications. Therefore the expectation is that such a MIF-schema-generated eCore model will lie at the center of a the future architecture and will use the EMF persistence mechanisms to write and read MIF instances.

4. If the designer is editing an extant model in a MIF source file and if there is content in that file that is not directly altered by the designer, the designer must nonetheless retain the unused information in order that it can be properly persisted in the "output file" after the file is edited. Phrased another way, editing SHALL NOT result in the loss of any data unless the editor elects to delete that data.

5. The graphic representation of static models, including the representation of HL7 Profile property values as part of the text rendering of an attribute in the graphic, was agreed in the HL7 Modeling and Methodology Work Group and documented on the Wiki. The future editor will be expected to comply with these rules.

   See particularly the simple UML flavor of the representation and note that the addition of property information on the attribute lines of each class may require wrapping individual attribute text lines.

6. The MIF schemas provide for the capture of graphic layout information for the diagrams of such an architecture, and the designer SHOULD use the graphic elements of MIF instances to persist the graphic diagram.

   HL7 would like to understand the relative impact of this requirement on the overall development effort.

7. The designer SHOULD offer options for deriving from the base model. For example:
   • Provide for selection amongst the classes of the "derived from" model when adding a class dropping on the new diagram;

   • Populate the initial values for elements such as an attribute's data type or an association's cardinality as being the values asserted in the "derived from" model;

   • Enforce the rules for derivation (such as no new attributes may be added to any class), etc.

Preferences and Specific "Challenges" for the Designer

The following list contains selected preferences that HL7 has for behavior of the designer along with consideration of editing and data entry paradigms.

1. Experience suggests that when models are derived directly from the RIM, a "drag-and-drop" graphic editor is most effective; the selection of attributes within a dropped class occurs within a pop-up editor that manages detail for the dropped class.

2. When the designer is being used to constrain a previously derived model, a tabular model editor may be a more effective editing paradigm, with each class appearing in the table along with its attributes and associative properties.

3. HL7 has defined a set of Formal Naming rules wherein the names of selected derived classes SHOULD be determined algorithmically based upon values of selected attributes in that class.

   (As a consequence, changing the code constraint of a class may require invocation of the naming algorithms to rename that class, and the class name may also affect other classes because class names may be part of association end names.)

4. Given a set of defined rules (such as "attributes SHALL NOT be added to a derived class") the designer SHALL have a validation suite to document where such rules have been violated, if any.

5. For general maintenance and analysis of existing models, it SHOULD be possible to use the validator (immediately above) to validate a set of derived models in "batch mode".

6. In some circumstances, the designer will be expected to enforce such derivation rules by refusing to accept an invalid change, while in other circumstances it should warn of the violation but allow the invalid content to e captured.

   It is desired that each validation check be configurable as to whether that check will be "enforced" or simply "warned".

Engagement of Consultant

In the course of engaging a consultant to advise on the Eclipse-based Model Designer (EMD) HL7 will provide:

• Access to HL7 artifacts (MIF Schemas, NHS Static Model Designer, HL7 RMIM Designer in Visio)
• Links to content on SVN
• Consultation with auther of this document, as needed
• Availability of knowledgeable "toolsmith) to provide a mini-overview and Q/A on GoToMeeting, as needed

Questions HL7 would like answered

Please consider the following questions and assessments, and provide a brief paragraph explaining the rationale for any that are unrealistic, high risk, or in some other way outside of our original assumptions.

1. In regards To Structure/Architecture
   1. Is he expectation that the tools can be primarily based on the HL7 MIF schemas unrealistic?
      1. Does it overly constrain what can be easily done?

      2. Does it preclude re-use of too much that is currently in EMF?

      3. Would it be better to assume a UML solution with an HL7 Profile and then transform the source and result files to our format?

   2. What is the impact on a MIF-EMF-based solution of changes to the MIF schemas?
      1. Can minor changes in MIF be implemented with alterations only in the affected class?

      2. If MIF schema changes include simple extensions (new attributes in an existing element, or new elements) and the changes are optional (minimum multiplicity of 0) will the "updated" tool be able to reliably read (consume) source files based on the older schemas?

   3. To what extent can the graphic editor be implemented as code changes or extensions to an existing open source Eclipse graphic capability?

   4. If there is an existing open source Eclipse graphic editor, how would one map (or transform) from the eCore model of the MIF-based editor to the eCore model that underlies the graphic editor?

   5. Are the existing graphic elements of MIF 2.2 sufficient to persist the graphic data of a model? (There is an implicit assumption that it may be necessary to map or transform the MIF-stored graphic data into a different format or "class structure".)

2. Assess the "Risk", "Cost", and "Likelihood of Success" of various features. For the following "requirements", please rate the Risk, Cost, and Likelihood of Success for meeting each requirement. Evaluate on a scale of 0 to 5. With 0 being minimal cost, risk or likelihood, and 5 being highly risky, very expensive, or certain to succeed. Please evaluate:
   1. Meet the requirement to use MIF-based XML files as the PRIMARY persistence mechanism for the model definition and content, without including graphics.

   2. Meet the requirement to persist model graphic data in MIF format only.

   3. Meet the requirement for a "graphic editor" that allows selection and "opening" of a class, where opening presupposes the appearance of a class editor that lists, and provides control over, the attributes and properties of that class.

   4. Meet the requirement to accept updated RIM and Vocabulary (controlling data used to configure the editor) without having to change the tool. (So long as the RIM change does not require additional class elements in the implementation.)

   5. Meet the requirement to validate to HL7 rules for model derivation from another static model.

   6. Meet the requirement to enforce selected validation rules

   7. Meet an as-yet-undocumented requirement to be able to export the resulting model as a fully-conformant XMI (OMG UML) format, with the inclusion of an HL7 UML profile for that content.