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

Briefing from the March 26 Jacksonville meeting here.

• 03 May 2010
• 10 May 2010
• 17 May 2010
• 24 May 2010
• 07 June 2010
• 14 June 2010
• 21 June 2010
• 28 June 2010
• 12 July 2010
• 19 July 2010
• 02 Aug 2010
• 09 Aug 2010
• 16 Aug 2010
• 23 Aug 2010
• 30 Aug 2010

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
  • Test Case 9
• SysML 1.2 - UML 2.3 - XMI 2.1
  • Test Case 10
  • Test Case 11

• 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 accommodate 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. To adapt Eclipse-based modeling tools to provide limited support for UML2.3 and SysML1.2 for MIWG purposes, see: MIWG-readme.txt in SVN

The following testing guidelines are related specifically to the interchange of profile models and their application in user models:

1. The names of stereotypes from the standard profiles in the XMI should have initial upper case letters. In general, the names of stereotypes in the XMI should be the same as the names of the stereotype element in the applied profile model, regardless of whether an initial upper or lower case letter is used in the graphical notation of the applying model. (This is consistent with the resolution of UML Issue 14092 in UML 2.4. It is, however, different than the previous consensus MIWG guideline to use initial lower case names in the XMI.)
2. The URI for the standard profiles have the form “http://www.omg.org/spec/UML/<version>/StandardProfileL2.xmi” (and similarly for StandardProfileL3), per the recommended convention in the UML specification (note, in particular, the ”.xmi” extension).
3. If a profile has a serialized nsPrefix tag, then that should be used as the namespace prefix for a serialized application of the profile. If a serialized profile does not have such a tag, then the namespace prefix for an application of the profile should be the same as the profile name (e.g., “StandardProfileL2”), per the recommended convention in the UML specification. Note that the name of the profile model element is not necessarily the same as the name of the XMI file that contains the profile (which is the last segment of the profile URI for the profile). In this case, it is the profile model element name that should be used for the prefix.
4. For SysML 1.2:
   1. xmlns:sysml=“http://www.omg.org/spec/SysML/20100301/SysML-profile” (i.e. defined by the nsPrefix and nsURI in http://www.omg.org/spec/SysML/20100301/SysML-profile.uml)
   2. the profileApplication will use the actual file, i.e. href=“http://www.omg.org/spec/SysML/20100301/SysML-profile.uml#_0”
   3. types defined in the profile will use the actual file, e.g. href = “http://www.omg.org/spec/SysML/20100301/SysML-profile.uml#VerdictKind”
   4. Text and Id properties of «Requirement» will use an initial upper letter as defined in http://www.omg.org/spec/SysML/20100301/SysML-profile.uml

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 - complete
  • Test Case 9 - Interactions
• Release 8 - Start SysML
  • Test Case 10 - Simple SysML Structure (bdd's and ibd's)
• Release 9
  • Test Case 11 - Requirements
• Release 10
  • Test Case 12 - Activity Swim Lanes
  • Test Case 13 - Additional UML functionality (instances)
• Release 11
  • Test Case 14 - Additional UML functionality (TBD)
  • Test Case 15 - Parametrics
• Release 12
  • Test Case 16 - Additional UML functionality (TBD)
  • Test Case 17 - Allocations
• Release 13+ - Start UPDM
• Release ?
  • Rerun Test Cases 1-6 with UML 2.2
• Release ?
  • Test Case ? - Composite Test Case (NATO Reference Model)

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 and record test results
• Review results and identify issues
• Fix and retest
• Propose resolutions
• Ensure all artifacts and test results are under version control

Incremental Deliverables:

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

Recording Test Results:
Vendors should insert a row in the interchange matrix each time they complete an export or an import. This yields lots of rows in the table for each test case. For example: in test case #1 we can see the following for just one vendor:

• A row that indicates the results obtained when they attempted to read the valid.xmi file.
• A row that indicates the results obtained when they submitted their export to the validator.
• A row that indicates the results obtained when a second vendor attempted to read the first vendor's export file.
• A row that indicates the results obtained when a third vendor attempted to read the first vendor's export file.
• etc.

At this time we have 6 participating vendors. This means that for test case #1 each vendor could have 7 rows in the table (the results from 5 other vendors plus the valid.xmi plus the validator). The total number of rows in the table for test case #1 is 43 (6 vendors times 7 rows/vendor + 1 row for what happened when the valid.xmi file was submitted to the validator).

Vendors should fill out column “A” through “I”. Column “J” is not necessary. Column “J” contains a formula that attempts to automatically compute whether the data in that row is stale. The data in a row is stale if the results were obtained using an old version of the exporting tool or an old version of the importing tool.