This is the front page of the portion of the MIWG Wiki intended for internal use by the MIWG.

If you are an OMG member interested in the interchange of models based on OMG standards, you can join the MIWG:

• We have an email exploder. To join, send a request to juergen@omg.org.
• The UML MIWG is part of the Model Interchange SIG, which traditionally meets on Monday morning during OMG meeting weeks.
• We are not having regular telecons at this time.

Release 15 has now been made public as the current MIWG test suite.

• Model Interchange Wiki Public Start Page
• Release History
• NIST UML/SysML Validator Tools
• Test Case SVN repository (requires OMG login)
• Bugzilla (requires login) Bugzilla Guidelines
• Vendor Interchange Capability Matrix (requires OMG login)
• UML 2.1.2 to UML 2.2 Migration Guide (from Eclipse UML Project)
• Some useful XSLT scripts
• Old Roadmap

• Testcase Authoring HowTo 101 (TBD - advice for the forgetful staff of Vendor companies on how to design a diagram-centric testcase)
• Vendor Testcase Result HowTo 101 (TBD - advice for the forgetful staff of Vendor companies on how to submit the XMI for a particular testcase result)

Briefing from the March 26, 2010, Jacksonville meeting here.

Minutes from 2010: here

Minutes from 2011: here

Minutes from 2012: here

Minutes from 2013:

• 07 Jan 2013
• 14 Jan 2013 Plaintext
• 21 Jan 2013
• 28 Jan 2013
• 04 Feb 2013
• 11 Feb 2013
• 25 Feb 2013
• 04 Mar 2013
• 11 Mar 2013
• 06 May 2013
• 22 Jul 2013
• 29 Jul 2013
• 16 Sep 2013

• 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 responsibility 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
14. For UML 2.3, StructuredActivityNodes (including instances of the subclasses ConditionalNode, LoopNode, SequenceNode and ExpansionRegion) owned by an Activity should be serialized under the node property of that Activity, not the group property. (Note that the update made in UML 2.4.1/MOF 2.4.1/XMI 2.4.1 results in such StructuredActivityNodes being serialized under the Activity::structuredNode property, but this property is marked as derived in UML 2.3 and so would not normally be serialized at all.)

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 (for UML 2.3) “http://www.omg.org/spec/UML/20090901/StandardProfileL2.xmi” (and similarly for StandardProfileL3), per the recommended convention in the UML specification (note, in particular, the “.xmi” extension). For UML 2.4.1, the URI is similar but does _not_ include the “.xmi” extension: “http://www.omg.org/spec/UML/20110701/StandardProfileL2”.
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 internal MIWG test suite repository is found at https://dev.enterprisecomponent.com/repository/repos/OMG-Model-Interchange. Login is required. To obtain an account, contact Ed Seidewitz.

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) - complete
  • Test Case 7 - State Machines
  • Test Case 8 - Use Cases
• Release 7 - complete
  • Test Case 9 - Interactions
• Release 8 (start SysML) - complete
  • Test Case 10 - Simple SysML Structure (bdd's and ibd's)
• Release 9 - complete
  • Test Case 11 - Requirements
• Release 10 - complete
  • Test Case 12 - Activity Swim Lanes
  • Test Case 13 - Instance Specifications
• Release 11 - complete
  • Test Case 14 - Parametrics (including Value Types with Units)
  • Test Case 15 - Structured Activity Nodes
  • Test Case 16 - Allocations
• Release 12 - complete
  • Update to UML 2.3
• Release 13 - current
  • Test Case 17a - Service Architecture (SoaML 1.0)
  • Test Case 17b - Collaborations (UML 2.3)
  • Test Case 18 - OV-2 Performer (UPDM 2.0)
  • Test Case 19 - Simple Federation (UML 2.3)
  • Test Case 20 - CV-1 Architectural Description (UPDM 2.0)
• Release 14 - planned
  • Test Case 21 - CV-2 Capability Taxonomy (UPDM 2.0)
  • Test Case 22 - CV-4 Capability Dependencies (UPDM 2.0)
  • Test Case 23 - Components and Component Realization (UML 2.3)
  • Test Case 24 - Components: Ball and Socket Notation (UML 2.3)
  • Test Case 25 - Deployments (UML 2.3)
• Release 15 - under consideration
  • Test Case 26 - Classifier Templates (UML 2.3)

• 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