model driven standards checklist

This checklist is taken from the MDS guidance document (OGC 23-040).

The identifiers of each test match those in the Abstract Test Suite of the document.

To use this checklist, copy it into a GitHub or Gitlab Issue.

- [ ] **Test 1.** Validate that the OGC document information used in the model-driven standard is completed and made available to the model-driven standard in the Metanorma AsciiDoc format.
- [ ] **Test 2.** Validate that the UML model used in the model-driven standard is completed and made available to the model-driven standard in the OMG XMI format.
- [ ] **Test 3.** Validate that the OGC document metadata used in the model-driven standard is completed and made available to the model-driven standard in the Metanorma AsciiDoc format
- [ ] **Test 4.** Check that the document shall provide suitable metadata for an OGC deliverable that describes an information model.
- [ ] **Test 5.** Check that the document shall integrate with the UML model via an OMG XMI file.
- [ ] **Test 6.** Check that the document shall specify the render conditions and configuration of the UML model.
- [ ] **Test 7.** Check that the document shall utilize methods provided in this document to create cross-references for document elements generated by the automated UML rendering process.
- [ ] **Test 8.** Check that the document shall encode its requirements in a manner compliant with the ModSpec.
- [ ] **Test 9.** Check that every UML package that serves as input to the MDS process is assigned a unique package name as in the EA “Name” property.
- [ ] **Test 10.** Check that every UML package that serves as input to the MDS process has its description encoded in the EA “Notes” pane in plain text.
- [ ] **Test 11.** Check that every UML package that serves as input to the MDS process is fully contained in the exported OMG XMI file, and does not depend on any external package not available to the MDS process, unless those external dependencies are configured in the MDS configuration file.
- [ ] **Test 12.** Check that every UML diagram that serves as input to the MDS process is assigned a unique name in the EA “Name” property, global to the scope of the MDS model.
- [ ] **Test 13.** Check that every UML diagram that serves as input to the MDS process has its description encoded in the EA “Notes” pane in plain text.
- [ ] **Test 14.** Check that every UML diagram that serves as input to the MDS process is encoded according to the “Class” diagram type in EA.
- [ ] **Test 15.** Check that every UML class that serves as input to the MDS process has its name encoded in the EA “Name” attribute in plain text.
- [ ] **Test 16.** Check that every UML class that serves as input to the MDS process has its description encoded in the EA “Notes” pane in plain text.
- [ ] **Test 17.** Check that every UML class that serves as input to the MDS process, that belongs to a particular stereotype, shall have its stereotype encoded in the EA model.
- [ ] **Test 18.** Check that every UML class that serves as input to the MDS process if is intended to be abstract shall encode its abstract status in the EA model.
- [ ] **Test 19.** Check that every UML class that serves as input to the MDS process that contain constraints shall have those constraints encoded in the OCL language with a corresponding description in plain text.
- [ ] **Test 20.** Check that every UML property that serves as input to the MDS process has its name encoded in the EA “Name” attribute in plain text.
- [ ] **Test 21.** Check that every UML property that serves as input to the MDS process has its description encoded in the EA “Notes” pane in plain text.
- [ ] **Test 22.** Check that every UML property that serves as input to the MDS process, that belongs to a particular stereotype, shall have its stereotype encoded in the EA model.
- [ ] **Test 23.** Check that every UML property that serves as input to the MDS process that has multiplicity requirements shall have its multiplicity requirements encoded in the Multiplicity attribute group, including the lower bound, upper bound, whether duplicates are allowed and whether the multiplicity is ordered.
- [ ] **Test 24.** Check that every UML property that serves as input to the MDS process shall be assigned a value type. If the value type of the property is meant to be abstract (to be implemented by a realization of the property), the UML Class “AbstractValueType” shall be used as its value type.
- [ ] **Test 25.** Check that every UML property that serves as input to the MDS process that contain constraints shall have those constraints encoded in the OCL language with a corresponding description in plain text.
- [ ] **Test 26.** Check that every UML data type that serves as input to the MDS process has its name encoded in the EA “Name” attribute in plain text.
- [ ] **Test 27.** Check that every UML data type that serves as input to the MDS process has its description encoded in the EA “Notes” pane in plain text.
- [ ] **Test 28.** Check that every UML enumeration that serves as input to the MDS process has its name encoded in the EA “Name” attribute in plain text.
- [ ] **Test 29.** Check that every UML enumeration that serves as input to the MDS process has its description encoded in the EA “Notes” pane in plain text.
- [ ] **Test 30.** Check that every UML enumeration value that serves as input to the MDS process has its name encoded in the EA “Name” attribute in plain text.
- [ ] **Test 31.** Check that every UML enumeration value that serves as input to the MDS process has its description encoded in the EA “Notes” pane in plain text.
- [ ] **Test 32.** Check that every UML enumeration value that serves as input to the MDS process, that has a particular value type, shall have its value type encoded in the EA model.
- [ ] **Test 33.** Check that every UML relationship that serves as input to the MDS process shall be fully specified in the EA model with directionality, type and name.
- [ ] **Test 34.** Check that every UML relationship that serves as input to the MDS process shall have be fully specified in the EA model: generalizations, dependencies, realizations, with their names.