Welcome to the model interchange wiki. The purpose of this wiki is to help coordinate the activities of the Model Interchange Working Group (MIWG). The goal of the MIWG is to improve the interoperability of MOF/XMI-based tools. Our initial focus is on model interchange among UML, SysML, and UPDM -capable tools.

You can join the MIWG:

• We have an email exploder. To join, send a request to juergen@omg.org.
• We have regular telecons. These are announced on the email exploder.

• OMG Announces Model Interoperability Working Group, July 8, 2009
• OMG Conducts Model Interoperability Demonstration at Long Beach CA, December 7, 2009

• NIST UML/SysML Validator Tools
• Test Case SVN repository (requires login)
• Bugzilla (requires login) Bugzilla Guidelines
• Vendor Interchange Capability Matrix (requires login)
• UML 2.1.2 to UML 2.2 Migration Guide (from Eclipse UML Project)
• Some useful XSLT scripts

The contents of the current test suite release are listed below. The contents of past releases can be found here.

• UML 2.1.1 - XMI 2.1
  • Test Case 1 (Revision 1)
  • Test Case 2
  • Test Case 3 (Revision 1)
  • Test Case 4
  • Test Case 5
  • Test Case 6
• UML 2.2 - XMI 2.1
  • Test Case 7
  • Test Case 8

• Tool Interoperability: the ability of tools to interchange models and interpret them in a consistent manner.
• Test Case: an input artifact and the expected output based on specified test criteria that is used to verify an exchange. For the interchange test case, the “input artifacts” include the Reference Diagram and Reference XMI, and the “expected output based on specified test criteria” includes the Diagram generated by the Producer Tool compared to the Reference Diagram, and the XMI exported by the Producer Tool compared to the Reference XMI.
• Reference Model: the combination of a Reference Diagram and the corresponding Reference XMI used as input artifacts for the Interchange Test Cases.
• Reference Diagram: a diagram conforming to an OMG standard notation used for verifying model interchange (refer to Model Interchange Testing Guidelines below for additional clarification).
• Reference XMI: validated XMI corresponding to a Reference Diagram used for verifying model interchange. (refer to Model Interchange Testing Guidelines below for additional clarification).
• Producer Tool: the vendor that generates a model and exports its XMI.
• Consumer Tool: the vendor that imports a model by interpreting its XMI.
• Test Suite: a set of related test cases.
• Release: a stable version of the test suite with its own branch in the SVN repository (refer to the Test Case Repository CM section below).

See also the testing process diagrams.

1. Each reference model shall have a unique name and version
   1. The 'master' reference model will be a fully annotated diagram
   2. An associated XMI file may also be provided for 'information' only

1. Once the reference model diagram has been agreed and posted each 'Producer Vendor' can then recreate the reference model diagram in their tool(s).
2. Then each vendor will then generate (or save as) XMI.
   1. The results of these exports are public within this Model Interchange group
   2. 'Producer Vendor' will validate their XMI output with NIST's Validator tool. (If you have difficulty interpreting the results of that testing, you can ping Peter Denno.)
3. The XMI files and diagram screenshots will be placed in the configuration managed pool (relating to the specification 'Reference Model')
   1. Each XMI file will include vendor identification
   2. The files will have unique names and include the name of the reference model (and version) from which they were generated.

1. 'Consumer Vendors' can (at any time) visit the XMI pool and download files to import (or use)
2. They will import (or open) the selected XMI file and attempt to reproduce the appropriate reference model diagram
3. The results of these tests will have two parts
   1. The results that relate to failures in the import functionality will remain optionally private to the 'Consumer Vendor'
   2. The results that relate to errors and omissions in the XMI file will be passed back to the group.
4. On completion of the test, the 'Consumer Vendor' will post a screenshot file of the resultant diagram in the configuration management system, linking it to the relevant XMI that was used for the import. Any issues encountered during the import will be captured as notes on the diagram.

1. Once a vendor is happy with its private testing, they can publish their final set of export and/or import results to the full working group. The vendors XMI import and export tool(s) should be generally available to their customer bases (i.e. not internal Alphas).
2. Once 4 or more vendors have shown 100% success importing and exporting XMI for a particular reference model version, the results may be shared publicly, by the OMG
3. Further successful vendors (in addition to the minimum quorum of 4) will also be publicised by the OMG.
4. All public notification will clearly state the relevant reference model and version.

The following guidelines do not necessarily reflect constraints imposed by the XMI specification, but are used for the purposes of the model interchange testing:

1. The reference diagram will conform to the applicable UML or UML profile standard notation. In those cases where the tool that produces the diagram does not support the notation, the diagram image will be edited to reflect the standard.
2. Since some of the information in the XMI may not be contained on the diagram, notes will be added to the diagram to document the additional information and assumptions. A note is used rather than a comment since a note will not appear in the XMI.
3. The type names on a diagram refer to the standard primitive types from the AuxiliaryConstructs::PrimitiveTypes package in the UML Superstructure. A note should be included on the Reference Diagram to reflect this.
4. Default multiplicities will be 1..1
5. A conformant XMI file can contain diagram information, as long as it is enclosed in a XMI extension element. A consumer tool can ignore this information.
6. Inclusion of additional elements in XMI will not be disallowed, but may result in responsiblity in consumer issues being allocated to the producer tool that generated the additional elements. (additional elements is relative to the test case)
7. A model will be used as the root element for the reference model, although this is not required of valid xmi. The model will be named “Test Case X”, and a package will be contained within the model to further contain the model elements. A variant test case may include a package as the root element for the reference model to accomodate those tools that do not support model.
8. Lower and upper default values (i.e. 1) of multiplicities are not to be serialized
9. Default visibility is public for each packageable element.
10. There is no default visibility for properties. Unless a visibility is specifically set, nothing should be serialized.
11. Ownership of association ends will be shown on the diagram
12. Use the Exporter tag in the XMI file to capture tool version
13. Use lower case for stereotypes in the XMI (including the stereotypes from the standard profiles).
14. The URI for the standard profiles have the form “http://schema.omg.org/spec/UML/2.1.1/StandardProfileL2.xmi” (and similarly for StandardProfileL3 and other UML versions), per the recommended convention in the UML specification (note, in particular, the ”.xmi” extension).
15. The namespace prefix for an applied profile should be the same as the profile name (e.g., “StandardProfileL2”), per the recommended convention in the UML specification.

The following is the draft recommended practice for file naming in the test case repository. (And yes, the names below begin literally with 'our'):

• Tests/
  • UMLu-XMIx/ – where u us a UML version number (e.g., 2.1.1) and x is and XMI version number (e.g., 2.1)
    • Test-Case-N/ – where N is a number (1,2,3…) naming the exercise
      • diagram.png – the test case diagram
      • valid.xmi – valid XMI for the test case
      • Submissions/ – A directory for vendor upload of results of Test-Case-N.
        • toolnameX/ – A directory for results from vendor's tool. Put version info in the name (e.g. toolnameX = UMLFoo3).
          • our-diagram.png – Screen shot of vendor's implementation of diagram.png
          • our-export.xmi – Vendor's XMI corresponding to his implementation of diagram.png
          • our-import-toolnameZ.png – Screen shot of diagram from reading toolnameZ's our-export.xmi
          • our-reexport-toolnameZ.xmi – Vendor's XMI from reading toolnameZ's our-export.xmi (optional)

The only version information in the names of the files here is for UML, XMI and the vendor's product. The toolNameX directory contains all the deliverables concerning Test-Case-N from the vendor owning toolnameX. Versioning of these files is handled by the CM system itself.

The latest version of the test suites reside in the SVN repository under trunk/tests. Periodically, the current version of all the tests will be declared an official “release”. At this point, the trunk revision of the entire tests directory will be branched in SVN. The directories for release R will reside in the SVN repository under branches/Release-R/Tests, with the subdirectory structure under tests as given above.

When making submissions, vendors should observe the following:

• A vendor may test against the tests residing in SVN under the trunk. All such submissions should be committed to SVN under the appropriate trunk directory for each test and tool (e.g., trunk/Tests/UMLu-XMIx/Test-Case-N/Submissions/toolnameX). Note, however, that test diagram and valid XMI files under the trunk are considered “under development” and are subject to change. Changes to tests may break prior vendor submissions, which will then need to be resubmitted.

• Once an official release is declared, vendors may submit test results under the branch for that release. All such submissions should be committed to SVN under the appropriate branch directory for each test and tool (e.g., branches/Release-R/Tests/UMLu-XMIx/Test-Case-N/Submissions/toolnameX). A vendor may update their submissions to any official release at any time, to reflect updates to or new versions of their tools. The test diagram and valid XMI files under an official release are considered “stable” and should not normally change. However, it may occasionally be necessary to update a release in order to correct a serious defect discovered after the release was branched. In this case, vendors will be advised to resubmit their tests to the release branch once it has been updated in SVN. (Such defect corrections may also be merged back into the branches for later releases and the trunk, as appropriate.)

Vendors should not normally make changes to files on branch releases outside of the appropriate submission directories for their tools. The creation of release branches, under direction of the MIWG, will be done by Ed Seidewitz, and any questions on branches and related CM should be directed to him.

Incremental Plan: The model interchange testing plan will include the following incremental capabilities. It is expected to take 3-4 weeks to complete a test case once we achieve a cadence. It is also expected that there will be more than one test case per unit of functionality outlined below, based on the level of complexity.

• Release 1 - complete
  • Test Case 1 - Simple Class Model
• Release 2 - complete
  • Test Case 2 - Advanced Class Model
• Release 3 - complete
  • Test Case 3 - Definition and Application of Profile
• Release 4 - complete
  • Test Case 4 - Simple Activity Model (part of fUML subset - executable)
• Release 5 - complete
  • Test Case 5 - Advanced Activity Model (part of fUML subset - executable)
  • Test Case 6 - Composite Structure
• Release 6 (transition from UML 2.1.1 to UML 2.2)
  • Test Case 7 - State Machines
  • Test Case 8 - Use Cases
• Release 7
  • Test Case 9 - Interactions
  • Test Case 10 - Collaborations
• Release 8
  • Rerun Test Cases 1-6 with UML 2.2
• Release 9
  • Test Case 11 - Composite Test Case (NATO Reference Model)
• Release 10 - Start SysML
  • Test Case 12 - Activity Swim Lanes
  • Test Case 13 - SysML Structure (bdd's and ibd's)
• Release 11
  • Test Case 14 - Additional UML functionality (instances)
  • Test Case 15 - Requirements
• Release 12
  • Test Case 14 - Additional UML functionality (TBD)
  • Test Case 15 - Parametrics
• Release 13
  • Test Case 14 - Additional UML functionality (TBD)
  • Test Case 15 - Allocations
• Release 14+ - Start UPDM

Incremental Process:

• Establish baseline specifications for increment
• Define/validate test cases
• Build reference model
• Inspect model
• Define test procedure (roundtrip, linear testing from one vendor to another, etc)
• Execute test procedure
• Review results and identify issues
• Fix and retest
• Propose resolutions
• Ensure all artifacts are under version control

Incremental Deliverables:

• Test cases
• Test results
• Interchange issues
• Proposed resolutions
• Interchange/interoperability demonstrations