Table of Contents

MIWG Internal Wiki

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:

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

Quick Links

MIWG Meeting Minutes

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

Minutes from 2010: here

Minutes from 2011: here

Minutes from 2012: here

Minutes from 2013:

Terminology

Rules of Engagement

See also the testing process diagrams.

Reference Models
  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
Export (XMI Producer vendor role)
  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.
Import (XMI Consumer vendor role)
  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.
Success
  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.

Model Interchange Testing Guidelines -- General

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.)

Model Interchange Testing Guidelines -- Profiles

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

Test Case Repository CM

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'):

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:

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.

Test Planning and Deliverables

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.


Incremental Process:


Incremental Deliverables: