"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Some UML issues

Contents

Related pages



What are we modelling?

aka Don't Muddle yer Models

UML can be used to model many things.

The viewpoint from which you're modelling is important, particularly being aware of when you're modelling the problem (or requirements) vs modelling the solution.

UML classes are often used to represent things "in the real world". The designation of UML as a "conceptual schema language" (ISO 19103) in the context of models of "features" (ISO 19109) is based on this assumption.

UML might also be used to model a document. If the UML profile described above is used, then a UML class-diagram can act as the "schema" for a set of GML instance documents.

Using (different) UML class diagrams for more than one level of abstraction - in this case for modelling both the real world and an XML document - is a common pattern in software design.

The "conceptual model" captures what you think is a model of the real world, or at least the "design model" or "requirements", but often cannot be implemented directly. An "implementation model" or "physical model" is developed, preferably starting with a clone of the conceptual model prior to actual implementation, but often reversed out of the actual implementation. It is important to distinguish between these different abstractions (and possibly an intermediate "logical" level as well), and to recognise that distinct UML models will usually be required.
  • In the ideal (but rare and usually simple) case the implementation model and conceptual models are identical
  • In some cases the implementation model is an improvement on the initial conceptual model, so the implementation experience leads to a revision of the conceptual model. This is a good thing .
  • In most cases the implementation model will have more detail completed.
  • It is often the case that the implementation platform is not capable of capturing all of the capabilities provided by the modelling language (for example: XML is a static data encoding, so cannot represent class operations dynamically) so the implementation model is constrained relative to the conceptual model - for example using a "profile" of the modelling language.
  • It is a warning sign if you can't recognise that an implementation model descends from a conceptual model - the most likely cause is changes in thinking not fed back to the conceptual model.

Are the stereotypes redundant?

Stereotypes, tagged values, and constraints are the standard extensibility points in UML. Stereotypes allow the UML meta-model to be augmented. Tagged values provide a location for implementation-specific details. Constraints augment the standard model capabilities.

In most cases class-stereotypes are a shorthand for inheritance (through specialization or realization) of properties from 'standard' parent classes. Hence, when the complete class-inheritance hierarchy is present in a model then the stereotypes <<Type>> and <<FeatureType>> are partially redundant: the fact that classes with these stereotypes are descended from gml:AbstractGMLType and gml:AbstractFeatureType is explicit in the model. In this case the stereotypes
  1. provide consistency with other models and modelling environments, where the stereotype is the only way that this information is available
  2. enforces the presence of the tagged values required in code generation.

Note that the stereotypes are required for a UML model that is conformant with ISO 19103.

UML as an XML Schema

A UML class diagram shows a set of relationships between classes.

Inheritance relationships represent information at the model level. These correspond to element substitution-group relationships (and their supporting type-derivation relationships) which appear in XML Schema documents, but are not directly apparent in XML instance documents.

On the other hand, UML class associations represent (potential) relationships between instances of the classes involved. These appear as content (sub-elements, attributes) of elements in XMl instance documents, as constrained by content-models (types) in XML Schema documents.

An XML document has a tree structure, so can only represent a subset or cross-section of the graph structure of the class-associations in a typical UML class-diagram. Using the rules for mapping between UML and GML, a GML document representing a Feature or Object may be modelled as follows:
  • locate the class representing the Feature or Object of interest in the UML class diagram - this is your starting point
  • create an XML element with this name - this may be the root element of an XML document
  • add sub-elements with the names of
    • class-attributes and
    • rolenames on associations navigable from this class
  • insert content in these sub-elements, having the form of either
    • simpleContent, in the case of class attributes whose type is a primitive type
    • complexContent, corresponding to the structure of the type of class attributes whose type is not a primitive type, or to the structure of the target class of a navigable association
    • a xlink:href attribute, whose value is a URI-reference that identifies a suitable resource, which may be a GML Object, Geometry or Feature, etc. (follwoing the GmlProperty pattern).

Note that
  1. XML has essentially only one structuring component - the <element>; hence, there is no structural distinction made in a GML document between elements corresponding to UML class attributes and UML associations
  2. XML attributes are used in GML only for second-order information, such as links to a coordinate reference system or unit-of-measure, which qualifies the primary information, and to carry links to information out-of-line
  3. there is generally no semantic distinction made between property values represented in-line, or provided as the target of a reference.
  4. a single UML class diagram may describe the structure of several different GML elements that may occur in various ways in instance documents; each XML element representing a GML Feature or Object corresponds to the tree subset or cross-section that is rooted at a class representing the Feature or Object of interest

Note that a UML model of an XML document does not support automatic document validation, but a UML class diagram will often be easier for a general reader to understand than a W3C XML Schema document. If UML is used in this way, the WXS might be kept in the background, as a "necessary evil" used for validation, but not playing the primary role in document design.


Refactored from SchemaFormalization -- SimonCox - 15 Jan 2009

 
Topic revision: r5 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).