1.1.  OGC Standards

The development of OGC standards is the primary driver behind this best practice document. Standards are developed by the OGC community whose membership hails from a variety of backgrounds including industry, academia, defense, and government. The standards definition process is work completed in response to a domain need to standardize data and interactions. Much of the actual work of creating a standard is completed from within the SWGs and DWGs through voluntary contributions from the membership. Additionally, standards are developed somewhat independently of each other; there are governing documents in the form the Abstract Specification Topics that should be referenced during the standards definition process, although this is not always the case.

Defining standards often includes the use of models to describe data and interface structures, as these are the two main aspects to be standardized. The models are usually UML Class Diagrams for describing structure although it is recognized that other modeling languages are more suitable for describing different aspects of a standard. Semantic definitions and relationships are used regularly to provide relationship information between standards, for example, a feature in one standard should represent the same information as a feature in a different standard. Although the structure of a feature can adequately be described using UML, semantic meaning between elements of a standard may better be represented in a language built for semantic description.

The state of existing models within OGC standards varies in quality, scope, approach and utility. This is largely due to the independence of approaches to OGC standard development, but also the variety of challenges that the standards are designed to address.

1.2.  UML

Unified Modeling Language (2.5.1) is an Object Management Group (OMG) and later International Organization for Standardization (ISO) standard with history stretching back over 20 years. It was primarily designed to describe the structure and the behavior of programs, systems, and data models. UML consists of 14 diagrams, half representing structure and half representing behavior with a few of these including interaction elements. Although UML is suited to modeling the entire suite of system behavior, the paper is only interested with the aspects of UML that assist with the OGC’s UML modeling aspirations, this is the Class Diagram. Please note that unless explicitly stated, from this point forwards this paper uses the term UML to refer to UML Class diagrams.

1.3.  Model levels & terms

When creating models using UML, the way the modeling artifacts are represented depends on several factors:

• Model purpose

• Level of detail

• Value proposition & utility

One such way of organizing types of models is to describe the abstraction from the real-world artifact. This hierarchy has crossover with other concepts such as level of detail, generalization and purpose, but the driving factor is understanding how closely the model represents an instance of the model. The levels are as follows:

• Conceptual

• Logical

• Physical

These are levels of data model first described in [7].

1.4.  Model Driven Architecture (MDA)

MDA has its own terminology that is similar to the model levels mentioned above, these concepts are referenced from the OMG MDA Guide Revision 2.0:

• Platform Independent Model (PIM)

• Platform Specific Model (PSM)

In general, the PIM is closer to the business concepts and requirements, whereas the PSM is closer to the technology.

1.5.  UML model technology agnosticism

Conceptual UML models should capture all of the information required to express a standard in multiple target technologies, this argument can vary in strength depending on the model purpose. Extreme examples of this principle refer to MDA, where the model will be required to capture a lot of information to generate the target technologies to a conceptual model that just contains the relationships between internal and external dependencies and packages.

Technology agnosticism is achievable and has many examples in the OGC and elsewhere, however, being completely approach independent is more challenging as the fundamental concepts and assumptions may be different. A typical example of this is a relational database, where creating a data model for a relational database approach can be quite easily abstracted from a database technology; the concepts of primary keys, foreign keys, 1st and 3rd normal form are well-known. However, it may not necessarily be possible to represent the same concept in a NoSQL or Graph or triplestore structure as the fundamentals are different.

1.6.  Out of scope

There are several topics that are of peripheral interest to the OGC and UML modeling but are not covered as they are outside of the scope of the paper. The out-of-scope elements include:

• Platform or technology dependent requirements — UML is the focus of the paper and technologies such as MDA are mentioned, however, specifics of potential target technologies are not in scope.

• Other modeling languages beyond UML — There are many languages and modeling paradigms that can be used to do conceptual modeling, however, the focus of this paper is UML.

• Best practice and use of Model Driven Architecture (MDA).

• Use of UML to create implementations of overarching standards through class specialization as it is inherently tied to machine readability and the MDA process — the actual details of UML model construction beyond being correct and consistent are not discussed.

• Specific recommendations for existing standards, this type of work should be done by the relevant Domain Working Group (DWG) or Standards Working Group (SWG) using this Best Practice as a reference.

1.7.  Best practice criteria

The criteria for best practice is multi-faceted, although it has an overarching motivation to provide value to standards implementers. Overall, OGC UML models should fulfill the following criteria, OGC UML models should be;

• Correct in terms of their construction and adherence to OMG Unified Modeling Language 2.5.1.

• Used consistently across the OGC; a representation of a concept or class should be consistent across all of the standards that use it.

• Add value to the standard in which a model sits; this could be as an informative set of diagrams or a normative model.

3.1.  Terms and definitions

3.1.1. Concept Model

Implementation independent representation of the nouns that are important for an organization, domain or industry.

3.1.2. Conceptual Model

model that defines concepts of a universe of discourse (Source: ISO 19101)

3.1.3. Logical Model

A data model of a problem domain that is presented independently of the of a particular database management product or storage technology.

3.1.4. Physical Model

A database or technology specific implementation of the logical model.

3.1.5. Platform Independent Model

A model of a software system or business system that is independent of the specific technological platform used to implement it.

3.1.6. Platform Specific Model

A model of a software system or business system that is linked to a specific technological platform.

3.1.7. Model Driven Architecture

A software design approach for the development of software systems. It provides the guidelines for the structuring of the specifications that are expressed as models.

3.2.  Abbreviated terms

PIM

Platform Independent Model

PSM

Platform Specific Model

UML

Unified Modeling Language

4.1.  UML to GML Pilots

This section provides an overview of the history of the application schema and transformation work completed over the last 20 years. The detailed information can be found in the Engineering Reports for the different initiatives. The full list of documents numbers 18 at time of writing which shows the legacy of this work within the OGC; it was supported by the OGC and Testbed (OWS) initiative from the very beginning. The Testbeds span from the OGC Web Services Testbed-2 (OWS-2) in 2004, all the way to UML-to-GML Application Schema Pilot 2020 (UGAS-2020), which is described in a later section.

The OWS-2 Application Schema Development Discussion Paper provides an introduction to ShapeChange within the OGC with the goal of creating application schemas for NGA data [2]. The initial process is defined to create ISO 19109 Application Schemas in UML with the explicit requirement for them to be machine readable and therefore transformable by the ShapeChange software into GML representations. The process for generating the application schemas was successful, although it was recognized that the time taken to generate the application schemas via the UML process was quite lengthy and it was more efficient to make changes manually or via an XML schema editor if time was precious.

The OGC Web Services (OWS) 3 UGAS Tool Discussion Paper provides an overview of ShapeChange and its installation, use and maintenance [3]. It is the first time in the OGC that ShapeChange is presented as a tool that can provide an Application Schema output.

4.2.  UGAS 2020 Pilot

The UML to GML Pilot 2020 (UGAS 2020) was a multifaceted piece of work that sought to derive methodologies for transformation activities enabling interoperability of data exchange [4]. One aspect of interest in this piece of work was the transformation of UML to JSON schema via an encoding rule. Schema encoding and conversion rules describe how UML models can be converted using the rules into an encoding of choice, the ER provides GeoJSON and JSON as two such examples. Some of the encoding rules described could potentially be generalized beyond JSON type schemas. For example, the Section on inheritance is useful due to the rules suggested, but also because inheritance as a concept is key to UML modeling in general. Another reason to consider inheritance is because JSON schemas do not support inheritance directly and therefore workarounds are described to utilize UML modeling for non-object oriented output schemas. This section reviews some of the pertinent decisions made in the Pilot that have possibilities for transference to the general case and therefore best practices. This section is not a critique on the decisions made during the UGAS Pilot — it is used to provide knowledge transfer into the Best Practices.

To summarize, the inheritance aspects of the UGAS 2020 Pilot include the concepts of generalization and specialization. These two types of inheritance relationships are handled by using the JSON schema keyword “allOf”, this inherits the properties of the generalized class into the specialized class. This approach begs the question of how types or functions may be overridden, if a use case for that relationship cannot be found. An additional observation is that the practice of specialization offers limited value in the way it is used. This is due to the lack of support for simple sub-typing of complex types (arrays for example). The authors describe a complex methodology for enabling this feature, at least within a single schema, however, they correctly point out the challenge of enabling this. A secondary concern for this approach is the value offered.

The use of enumerations in JSON is good example of a UML → JSON match as both support the concept of enumerations and are used in the same way. Code lists are slightly different in that the representation of a code list in XML, for example, maps well to code lists in UML. However, code lists in JSON schemas are different in that they rely on a linked object to achieve the desired effect; a code list in UML/XML is a list of shorthand codes that have a lookup to a more descriptive version of the code with peripheral, linked information. In the JSON version, the ER describes the use of a linked object, but it is not clear how the code lists capture the information attached to the code.

Basic types are described in UML by using a set of generalization relationships, each type inheriting from its subtype. Although this approach provides the desired output schema, it is a rather verbose way of describing type information. This is a feature of how JSON does its pseudo-inheritance, as described above.

4.3.  OGC Testbed-16 OpenAPI

OGC Testbed-16 saw the use of UML Class Diagrams to model interface specifications [1]. The OGC is currently moving away from the WxS (WFS, WMS etc.) suite of standards based on XML and towards the OpenAPI specification which uses JSON and YAML. The OpenAPI specification differs from XML because OpenAPI is an interface standard. UML class diagrams are inherently OO and can be represented in XML documents, therefore compromises are made to ensure that all of the information is captured within the models — capturing all of the information is required as the UML model was fed into an MDA pipeline and automatically transformed into a JSON representation of an OpenAPI interface.

The approach to utilizing UML was derived using the following principles:

1. Pragmatism over idealism. The project required delivery of implementable artifacts without stipulating a particular approach.

2. Use of specialization to enforce rules within the transformation process. The OpenAPI specification describes rules at the Object level, these objects were realized as classes in the metamodel and rules were written in the transformation software to detect meta-classes and transform accordingly.

3. Appreciation of the transformation tool’s capabilities prior to model design. ShapeChange was used within Testbed-17 and one of the considerations is that ShapeChange does not recognize methods in UML classes out of the box. Therefore, all of the OpenAPI object properties were captured as data items regardless of whether that was appropriate.

There are several differences between interfaces and data models, although they are both structured: an interface definition has far more flexibility in how it is realized. If a data model is relational, then it will follow certain rules, such as the inclusion of primary and foreign keys. Contrarily, an interface model has no such constraint and could vary wildly. This has implications for best practice in that, although UML models may be logical and technology independent, they are likely to be approach dependent.

4.4.  Conceptual Modeling Discussion Paper

UML modeling within the OGC applies variable approaches. One of the objectives of this Best Practice is to standardize the use of UML across the OGC. There is a discussion paper within OGC (21-041r2) that was written to explore the possibility of a group within OGC to assist with UML modeling in a standardized way across the OGC [5]. The paper re-visited some of the discussions on conceptual modeling within the OGC, the focus was not specifically on UML, but conceptual modeling more widely — it just so happens that the majority of conceptual modeling within the OGC is UML. There are multiple criticisms leveled at some of the conceptual modeling that exists within the OGC, the contents of the paper will not be repeated here. Briefly, the main points included:

• There is an identified need for conceptual modeling within the OGC, although the scope and remit is not clear.

• Conceptual Modeling across the OGC is inconsistent.

• Some standards have missing or incorrect conceptual models.

• Conceptual models are occasionally normative, but usually supportive.

The Discussion Paper provides much of the material that drives the need for this Best Practice and is recommended reading as a companion to this work.

4.5.  Lessons learned

Representations of different types of output schema (JSON, XML, etc.) lend themselves to modeling in UML to different degrees. One of the more challenging aspects of JSON representations is best described using indentations as an indicator of a new class in a UML model. This was the approach adopted in Testbed-16 and is somewhat reflected in the UGAS 2020 Pilot. In very complex UML models, such as those that represent OpenAPI interfaces, the number of classes and specialization relationships can become very large and difficult to maintain. An example below is one of the Paths views from the Testbed-16 OpenAPI thread.

Figure 1 — Paths OpenAPI representation in UML.

The use of UML as the de facto language for modeling is not an appropriate assumption. The previous work described in this section, specifically the UGAS 2020 pilot, notes that RDF and SHACL offer better semantic descriptions of relationships. Therefore, the UML best practices should also include some description of relevance of UML as a modeling language and a call for other types of modeling practice.

A lesson learned from the OpenAPI work and the UGAS 2020 work is that adoption of MDA processes requires a lot of upfront work when working with a new encoding, standard or transformation. In the examples given, the MDA process seems to follow the following broad steps:

1. Create a strategy for building a UML model. Translation of domain knowledge into a UML model is not a defined process and a strategy has to be adopted to ensure consistency and correctness. This is not only critical for model readability, but it is also required for simple transformation practices from the UML model into the target technology.

2. Ensure all information is captured within the UML model to an appropriate level of detail. In addition to creating a correct and consistent model, the model must capture all of the information required to derive the target technology output somewhere, otherwise it will have to be injected at another time which increases complexity to the already complex process.

3. Create encoding rules to ensure a consistent and correct transformation. Even with all of the information captured in a consistent and correct way, encoding rules have to be created to define how the model is going to get from its UML representation (described in a Sparx Enterprise Architect Project or XMI) into the target representation.

4. Implement the encoding rules. Implementation is required to actually perform the transformation. In addition to the normal testing required for development projects, several different models will likely have to be pushed through the transformation technology to ensure that it is implemented correctly and generic.

5. Maintain the models and transformation software. Target technologies are not static and have version uplifts, depending on requirements it is likely that the models and transformation technology will have to be maintained to ensure compliance with target versions of different technologies. Additionally, the process has to be followed for each new transformation required.

Overall, the projects described highlight attempts to utilize UML models and downstream technologies to add value to some or all of the standards definition process. Creating the UML model is not a straightforward process, neither is utilizing the transformation technologies once the UML model has been created.

This section again considers the value of UML modeling in different circumstances, it may be that UML modeling is not appropriate in all situations if it offers no value to the overall product. Additionally, the value threshold seems to increase as the complexity of the UML target technologies approach increases; if a UML model maps 1:1 with a target technology, it may be that an MDA process is suitable, as the threshold for implementing it is not very high. However, if a UML model is representing a suite of target technologies over a complex domain, then the value threshold for MDA is a lot higher because the time investment to create it also high.

4.6.  Discussion

Uptake, utilization and quality of UML models is variable across the OGC. Additionally, the concept of value is rarely considered explicitly with models sometimes added as an afterthought without a maintenance and governance structure in place. There are examples of models within OGC standards that are normative and therefore the source of truth, should there be a conflict between the model and supporting documentation. There are also models that are utilized as part of an MDA pipeline and schemas as derived directly from the model. However, the most common use of UML models within OGC standards is for illustration of concepts within standards as documents. It is not suggested that this use changes, as MDA can be more of a burden to developers than the supposed value added by following the process. Descriptions of the best practices will therefore not mandate or assume any downstream use of UML models and will consider them to be standalone artifacts that offer value in their own right.

Referencing the Table of Standards in the previous section: many standard definition processes attempt to use modeling within the standard, but this modeling varies from very high-level, conceptual models to low-level encoding models for transformation. There are a few examples of modeling being used to generate multiple outputs from a single model, this is evident in CityGML, which is also used to generate CityJSON, and OWS Context which provide both an XML and JSON encoding. Generating multiple encodings from UML models is utilization of MDA applied to its full potential. However, this is not expected to become a normative process within OGC.

In summary, the OGC utilizes UML modeling for description of concepts, modeling data, and in MDA pipelines. The quality of the modeling varies throughout the OGC and has somewhat fallen out of favor recently with the utilization of JSON encodings that can be created and implemented very quickly.

5.1.  Modeling Purpose

Consideration should be given to modeling purpose. Modeling is a difficult, complex and often time-consuming job, therefore the following should be understood:

• The value proposition of the work — why is a model being included?

• How the Standard fits into the overall suite of OGC standards, including concept reuse.

• The skills required for the standard development and generation.

• Whether the model is normative in describing the standard.

As mentioned in the previous section, creating models of OpenAPI levels of complexity, as seen in Testbed-16, is a labor-intensive process. Therefore, any modeling work undertaken should have a purpose and add value or do work that the other aspects of a standard documentation do not. Likewise, it is prudent to streamline the work required of a standard; communication of the relevant aspects of a standard should be described in the text or in the model, but not both: there should be no need to describe it multiple times. Adopting this approach will reduce the likelihood of repetition and conflict between different aspects of a standard document.

Perhaps an outcome of this work is the creation of an OGC model repository to harmonize and maintain all of the models through the OGC in a formal manner.

5.1.1.  Communication & Diagram

UML is an effective communication method for describing data and interface structure. This Best Practice is focused almost entirely on UML Class diagrams, therefore this section is concerned with class diagrams used for communication purposes. UML class diagrams used solely for communicative purposes have several advantages, such as:

• Well-defined relationships between classes

• Ability to fix field values

• Stereotypes

• Multiplicity

• Qualifiers

Additionally, UML is a well-known standard with a standardized graphical user interface, making it ideal for diagrams. Another aspect of UML that has been useful for diagramming is the specialization → generalization relationship, which essentially allows the capture of class type and name. This mechanism was utilized in OGC Testbed-16 OpenAPI thread to describe OGC API — Features Part 1: Core in terms of its OpenAPI meta-classes.

Figure 2 — Use of Specialization Relationship to describe OGC API Class types.

In summary, UML Class models can, as a minimum, be used for creating diagrams to represent a standard. However, if the diagram is complete, correct and consistent, and built in modeling software then it is highly recommended that the model artifacts be supplied for completeness.

5.2.  UML Class Diagrams

UML class diagrams remain a popular approach to describing the structure of artifacts. Initially class diagrams were used for code stub generation through MDA, this has somewhat fallen out of favor due to the complexity of the process and the overall utility of the outputs. Although still used for describing structure, class diagrams are more likely to be implemented in data modeling specifically for databases and more recently, modeling of interfaces definitions.

UML class diagrams assume object orientation, although other paradigms are supported with standard interpretation. OO is a popular paradigm for programming and data models; relational databases are implemented in many use cases. However, modern interchange and interface description formats such as JSON and YAML are not object oriented, therefore the design of models with a JSON target require some interpretation. A fuller explanation of utilizing XML to create JSON schemas is in the UGAS 2020 Pilot Engineering Report.

6.1.  UML diagramming

7.1.  Correctness

UML models need to be correct in terms of OMG UML 2017 standard. The implications for producing an incorrect model include the following:

• The model is likely to be misunderstood or not understood at all.

• UML is an abstraction from the things we are trying to represent, therefore misrepresenting it simply introduces further levels of error.

• Having incorrect UML will likely violate many of the other principles

Perhaps a solution to the correctness issue is to have the user indicate that their modeling is based upon OMG UML 2017 or if the notation has been partially used to illustrate an object, concept or relationship only. An additional aspect of modeling is that semantics cannot be ignored and may encroach on a model that was originally intended for MDA or other engineering purposes. This is to be expected, but the author should at least note whether this is the full explanation, or the model is stored alongside another semantic model using the appropriate notation such as OWL.

7.2.  Consistency

OGC Standards tend to reference other external documents such as standards from the ISO/TC 211 committee. An additional consideration is that the reuse of concepts, classes and relationships happens across the OGC in different standards, although some of this use should be captured in the Abstract Specification topics. Regardless of their usage or otherwise, one should be able to take an internal or external concept or class and reuse it with impunity — this can only be accomplished if the object is reused consistently across the OGC.

Depending on the requirement or individual model, there is not necessarily a connection to an outside organization or model. Therefore, the dependencies for a UML model should be clearly indicated on the model. There may be a looser relationship between external models and the model in question, these relationships should be documented as well and may be labeled as inspired by or an equivalent.

7.3.  FAIRness

The FAIR principles are as follows:

• Findable

• Accessible

• Interoperable

• Reusable

Whether models are findable or accessible will largely depend on how well a model conforms to the first two principles. These principles will also feed into the practice to make models accessible via sharing them along with the other artifacts that come with a standard. ISO TC/211 already adopts this practice and it should also be adopted by the OGC. In the defense of newer standards, there are a lot more UML models available than in older standards so the practice of making models findable and accessible appears to be increasing.

7.4.  Value

Value is an ethereal concept with many meanings, what is value? In this instance, value is about doing work — i.e what work does a UML model do for us? If a model is normative, then it can do all of the work, as there is nothing else required to describe a standard. The value added by a UML model should also be proportional to the time and effort required to build it and to use it. There are some immediate values that this practice can offer:

• It avoids recreating something that has already been created — new standards do not have to be defined from scratch.

• Coalescence of multiple standards (or models) is a lot easier if the models conform to the mentioned principles. This adds value to the standards definition process in general as reuse of concepts should ensure a more rapid standard development cycle. One such recent example of this is OGC API — Records, the draft of which was available quickly after inception because it reuses the base structure of OGC API — Features.

8.1.  Practice 1: UML models should follow OMG UML 2.5.1 Standard ratified in 2017.

A minimum requirement for UML models within the OGC is that they are correct in terms of the standard. Although obvious, this has not always been observed. This practice is also about fitness for purpose of the UML modeling tool set, for example, UML class diagrams are very good at describing structure, but not designed for describing process, for example.

Another consideration for using UML models is the use of stereotypes as there are many standard stereotypes included within the 2.5.1 standard, there are also many in addition to this in ISO/TC 211 that should be re-used where possible. Further discussion on stereotypes can be found in OGC Testbed-17 Model Driven Standards ER.

8.2.  Practice 2: OGC Conceptual Models should be represented as UML Class diagrams

It is often taken for granted when talking about conceptual modeling that the term “UML” refers to class diagrams, as in the case of this Best Practice paper. UML class diagrams are designed to describe structure, which is suited to the OGC’s conceptual modeling use cases.

8.3.  Practice 3: OGC Conceptual Models should be platform independent

Going forward, the OGC is supporting different target technologies. As mentioned previously, mapping for model to technology was 1:1, that is, in the web services (or GetCapabilities) era, all of the output technologies and descriptions were in XML. However, since the move to OpenAPI and more generally, a resource-based approach, there is the potential for multiple technologies derived or represented from the same model.

There are some assumptions and things to consider regarding this practice. UML Class diagrams are a standard and as such look to enforce rules regarding appropriate use — UML itself is a language and all descriptions must fit within the language, therefore, true platform independence is constrained by the use of a modeling language.

8.4.  Practice 4: OGC Conceptual Models should use concepts consistently across standards

UML modeling is not suitable for describing the relationships between concepts in the same way that a semantic language is, however, the concepts in use need to be represented within a UML model in order to make them usable. The semantic descriptions of concepts can be described elsewhere, however, when concepts are used and reused throughout the OGC, they should be done consistently.

8.5.  Practice 5: OGC Standards should contain a UML model at least at the conceptual level of detail

OGC Standards should contain a UML model describing the structure of any interfaces or data models, unless doing so violates Practice 6 or is otherwise inappropriate. A model that shows the logical class and relationships between them should be the bare minimum for a standard in order to at least show the use and reuse of top level concepts across the standards. This approach provides a frame of reference for newcomers to the standard as well as allowing the standards designers and implementers to understand where any standard fits in with the existing and emerging suite of OGC standards.

8.6.  Practice 6: UML models for OGC standard should add value

There are many reasons to create a model for a standard and the appropriateness of a modeling approach will largely depend on the standard in question. Regardless of the containing standard, UML models should do work or add value that is not otherwise done by artifacts within the documented standard. As mentioned throughout this Best Practice paper, UML models may be used to simply diagram an approach, alternatively they may be used in an MDA pipeline. Both of these approaches, as well as many more, are acceptable reasons to include a model within a standard document.

8.7.  Practice 7: UML models should describe structure and in the engineering process

UML modeling is designed for engineering and description of structure, there are other languages such as OWL that are designed to describe concepts. Therefore, we should not be using UML to describe concepts when there are better tools available to us. The OGC approach to modeling in general should be covered in further Best Practice papers. Structure is a key aspect of standards and concepts should be represented in the structure as objects, attributes or methods, the semantic meaning of the concepts should be covered elsewhere.

8.8.  Practice 8: Modeling artifacts should be provided in full.

The recent move to using version control seems to enable provision of modeling and other artifacts such as schemas whilst enabling version control and provenance of changes. Although this practice is more prevalent, it is not mandated and modeling artifacts can be lost. Full modeling files and data should be supplied along with the working version of the standard. Following this process is especially important when considering change requests and if the model is normative. In the case of a normative model, any change requests to normative aspects of the document should be led by the model and the supporting text updated accordingly.

Achieving this has been challenging for the OGC, with few discussions on collaboration and version control on models. This is changing through the Conceptual Modeling sub-group of the Architecture DWG and the OGC’s potential move to collaboration technologies such as Sparx Cloud.

8.9.  Practice 9: UML models should at least be consistent with supporting text, but ideally normative

UML modeling is a powerful tool and done correctly can remove ambiguity associated with the textual and diagrammatic explanations of standards. Additionally, if a model is normative then it is the central location where changes can be made.

8.10.  Practice 10: UML modeling tooling should produce interoperable artifacts

There is now a large repository of UML modeling tools both open source and proprietary. The actual choice of modeling software should be up to the modeler, however, the following should be considered:

• Is your chosen tool a modeling tool or does it just produce diagrams?

• Does your chosen modeling tool produce an interoperable output, for example XMI 1.0?

• How well does your chosen tool follow the standard? Does it allow you to create illegal classes or relationships and do you have to do out of bounds work to ensure compliance?

• If you are looking to implement MDA or some other form of transformation, does your chosen tool have support with a downstream tool? For example, Sparx Enterprise Architect works very well with Interactive Instruments ShapeChange software using the native format. Therefore, the coupling of these tools makes sense.

Overall, this practice is designed to stop vendor lock-in on different tooling and to encourage as much knowledgeable participation as possible through not restricting the tools.

8.11.  Practice 11: UML can be used for modeling semantics, although there are other technologies that may be appropriate

There are examples of semantic modeling in UML as relationships can be labeled accordingly to show semantic meaning. ISO/TC 211 requires semantic information to be included in any submitted UML models, therefore there are examples of producing semantic meaning in this way. However, there are tools such as SKOS, RDF and OWL that are designed to do semantic modeling and therefore may be a better choice depending on the use case.

8.12.  Practice 12: UML models should be machine readable

The MDA process is not mandated as many SWG leads and other implementers have issues with its efficiency, reliability and overall goals. However, there is a recent push within the OGC, along with the long-running UGAS work to re-look at MDA. The requirements for a model to be suitable for MDA include consistency, correctness and value, however they additionally require the models produced to be machine readable. Therefore machine readability of UML models should be prioritized when creating UML models to ensure interoperability with future endeavors and work with that standard. The models should be available in XMI format, in addition to the format of the UML Editor used to create the model.

9.1.  Future Work