The ModSpec Model - Part 2: UML

All symbols used in this document are either:

The normative provisions in this standard are denoted by the URI namespace

https://www.opengis.net/spec/modspec/1.1/

All requirements that appear in this document are denoted by partial URIs which are relative to the namespace shown above.

For the sake of brevity, the use of “req” in a requirement URI denotes:

https://www.opengis.net/spec/modspec/1.1/

An example might be:

/req/core/crs

All conformance tests that appear in this document are denoted by partial URIs which are relative to the namespace shown above.

For the sake of brevity, the use of “conf” in a requirement URI denotes:

https://www.opengis.net/spec/modspec/1.1/

The same convention is used for permissions (per) and recommendations (rec).

In this document the following abbreviations and acronyms are used or introduced:

Each normative statement in the ModSpec Part 2 - UML Standard is stated in one and only one place, in a standard format, and with an unique label, such as REQ001, REC001, or PER001. A requirement, recommendation, or permission may be repeated for clarification. The statement with the unique label is considered the official statement of the normative requirement or recommendation.

In this document, all requirements are associated with tests specified in the test suite in [annex-A]. The reference to the requirement in the test case is done by a requirements label Recommendations are not tested although they still are documented using a standard template and have unique identifiers.

Requirements classes are separated into their own clauses and named, and specified according to inheritance (direct dependencies). The Conformance test classes in the test suite are similarly named to establish an explicit and link between requirements classes and conformance test classes.

In informative sections, the use of the word "will" implies that something is an implication of a requirement. The "will" statements are not requirements but explain the consequence of requirements.

The ModSpec defines a "requirement" of a standard as an atomic testable criterion. See the formal definition of requirement in [term-requirement]

If the organizing mechanism for the data model used in the standard is an object model, then the mapping from parts of the model to the requirements classes should follow the logical mechanism described here.

The terminology used here is common to all versions of the UML standard, and may be applied to any such version.

First, by the requirements above, the extension relationship of this conformance test class to the core will be made explicit.

Any conformant UML extension will comply with the ModSpec Core requirements class.

Assuming all legitimate direct package dependencies are included in the UML model, the conformance/requirements class associated to a package \$A\$ will directly reference the conformance/requirements class associated to another package \$B\$, if and only if \$A\$ is dependent on \$B\$. Indirect dependencies will be dealt with as the conformance classes cascade.

This clause uses UML terminology, but other object modeling languages and, if needed, the object code itself can be mapped to a UML model.

Other dependencies (indirect) will arise from the transitive closure of the above direct dependencies. That means if \$A\$ depends on \$B\$, and \$B\$ depends on \$C\$ then \$A\$ depends on \$C\$. Since these indirect dependencies will show up in the cascade of included conformance tests based solely on the direct dependencies, we can ignore them for effects on structure.

Since a package can consist solely of other packages, there is always the capability to define in UML a single package that will correspond to a particular requirements class and its associated conformance class.

The class definitions are the "requirements" of a UML expressed standard. Therefore, the logical consequence of the above is to organize requirements classes based on leaf packages.

If a requirement uses or refers to elements of more than one package, then one of the packages will be called the source of the requirement, and the other targets. The requirement with the same source package will always be associated with the same requirements module and/or class.

This is actually a derived requirement and is repeated here for emphasis.

This dependency of requirements classes will be consistent with the usual mechanism for describing the source and target of dependencies between packages. By Clause [req-22] in the Core, only classes in the source requirements class will be affected by the requirement.

In UML, source and target dependency relations are defined in such a way that the source of the relation is dependent on the target of the relation.

This means that the dependency graph of the UML packages parallels in some sense the extension diagram of the requirements/conformance classes. If all leaf packages of the model are moved into "requirements class packages" containing their corresponding modeling packages the model then satisfies the following recommendation:

Each requirements class in a conformant standard should be associated to one and only one UML package (which may contain sub-packages for a finer level of structure). If the core requirements class contains only recommendations, it may be an exception to this.

For example, if two classes have a two-way navigable association, then these two classes must be (transitively) in the same conformance requirements class package.

The hierarchical structure of a UML model is based on UML classes, residing in UML packages. UML packages can then reside in larger UML packages. Although there is nothing to demand it, it is a common practice to move all classes down the hierarchy to leaf packages. Leaf packages are those that contain only classes (that is, contain no smaller subpackages). Classes can act as packages in the sense that a UML class can contain a locally defined class whose scope is the class itself. For our purposes, we will consider a class and its contained local classes to all be in the package of the original class.

An implementation passing the UML conformance test class shall first pass the core conformance test class.

To be conformant to this UML conformance class, UML shall be used to express the object model, either as the core mechanism of the standard or as a normative adjunct to formally explain the standard in a model.

A UML model shall have an explicit dependency graph for the leaf packages and external packages used by the standard consistent with the way their classifiers use those of other packages.

A UML leaf package shall be associated directly to only one requirements class.

Each requirements class shall be associated to a unique package in the model and include either directly or by a dependency any requirement associated to any of its subpackages.

A requirements class shall be associated to some number of complete leaf packages and all classes and constraints in those packages.

Classes that are common to all requirements classes shall be in a package associated to the core conformance/requirements class.

In the UML model, if a "source" package is dependent on a "target" package then their requirements class shall be equal or the source package’s class shall be an extension of the target package’s class.

If one leaf package is dependent on another leaf package, then the requirements class of the first shall be the same or an extension of the requirements class of the second.

If two packages have a two-way dependency (a "co-dependency"), they shall be associated to the same requirements class.

The UML model shall segregate all classes into leaf packages.