10.3 The UML Specification and Metamodel

System models, like fashion models, depend on "body language" to convey the ineffable, but they rely on standard postures and gestures to get the point across. Semantics define the standard postures and gestures for a modeling language (and notational style is the graphic equivalent of body language).

The UML formalizes the semantics of modeling in its Specification document. The language is based on a model itself, a metamodel, that is consistent with the object-oriented paradigm that gave it birth. The metamodel defines the connection between a system and its representation in UML models, and the architecture of the language.

The metamodel defines modeling language architecture in a way that reflects standard object-oriented constructs; for example, a modeling language is an instance of the metamodel. Recursively, a model then "define(s) a language that describes an information domain" (Rational Software Organization 1999, 2 5). In effect, each set of models of a system is a dialect of the modeling language, in which the basic rules are set by the language, but the actual realization is a product of the forces at work within the development environment.

The UML Specification fleshes out the metamodel, and comprises a very detailed understanding of models and their essential elements, one that is important to understand to be able to get the most benefit out of using the UML as a language.

In the UML, a system is packaged into one or more models, each reflecting a perspective on the system in a way that is useful for users rather than fitting some prescribed theoretical framework. In turn, models are made up of model elements. And, as mentioned earlier, models represent either the external reality of aspects of the real world or the internal reality of a constructed reality a software system.

UML models are not diagrams and pictures. Although models and model elements represent the system they refer to, they are distinct from the graphical presentation used to communicate their meaning symbolically. The following is from the UML Specification:

model

An abstraction of a physical system, with a certain purpose.

See: physical system.

physical system

1. The subject of a model.

2. A collection of connected physical units, which can include software, hardware, and people that are organized to accomplish a specific purpose. A physical system can be described by one or more models, possibly from different viewpoints. (Rational Software Corporation 1999)

The original Greek meaning of symbol (symballein) was "to bring or throw or put together" (Illich 1996, 31) a collectively understood token or mark. Symbol took on the notion of sign, with the implications of some real connection to an external reality, much later.

The ancient Greeks got all hung up about whether art should be matching(copying the real world) or making (inventing one). Modeling faces a similar controversy: should we use objects to denote abstractions in the domain, or does this imply an implementation that is premature? The schizophrenic etymology of symbol is partly at fault.

UML diagrams combine symbols as tokens with symbols as signs, but in a way that magically reverses the history of symbols. The real world is presented through tokens of a collective understanding, attempts to match things out there; the constructed, imagined world is embodied in signs. As modelers, we can know the real world only as shadows, but we know our constructions in an intimate and unique way because we make them. The trick is to juggle the two when we build models to communicate and express our understanding, something that the UML makes uniquely possible.

The graphical presentation of a model is defined by the notation standards of the UML. The UML mandates notational standards to ensure semantic consistency in the use of models to represent and communicate. The UML Specification describes the UML notation as "[a]human-readable notation for representing OA&D models an elegant graphic syntax for consistently expressing the UML's rich semantics an essential part of OA&D modeling and the UML" (Rational Software Corporation 1999, xi).

Various presentation elements are used to communicate the meaning of a model. Each model element has one or more alternative presentation elements that the modeler can use in depicting views of the model. Presentation elements are packaged by means of diagrams, which are themselves a type of model element.

A diagram is a specific instance of model information. Diagrams provide succinct views of aspects of the model that are practical and meaningful for a particular purpose. Each presents a subset of information about a particular model at a point in time.

The model itself provides the overall view that defines the landscape from the perspective of the viewer. Within a model, each diagram shows information useful for a purpose, but (usually) not all the information available. The UML allows the suppression or omission of many diagram elements to facilitate visual clarity or to emphasize a specific aspect of a model. So, a particular UML diagram may or may not show all there is to see about the model elements being presented.

Because the graphical syntax of the UML is so flexible and limited in its constraining effect, the UML rules governing syntactical correctness are not expressions of some theoretical perspective, but are practical and sensible instead. In fact, rather than talking about correctness, the UML talks about "well- formedness," a soft-edged concept that allows for precise rules applied with discrimination.

For example, vendors are "expected to apply some discretion about how strictly the well-formed rules are enforced. Tools should be able to report on well-formedness violations, but not necessarily force all models to be well formed. Incomplete models are common during certain phases of the development lifecycle, so they should be permitted" (Rational Software Corporation 1999, xvi). At any rate, well-formedness is a matter of semantics rather than syntax, and the UML Specification seems especially muddled about what well-formedness is, although each ModelElement does come with a set of rules.