3C Clear Clean Concise UML Back Contents
communityUML 2torial

5.4.1 Type (a further discussion)

This page is for those who for those who ask: Is it true that you guys aren't serious?

And for those interested in digging into the foundations of UML 2. Others may skip this page.

Q: What is a type?

A: A type is used for three purposes:

- to classify elements,
- as a shorthand used to specify an element and
- for type checking.

A model identifies a type by providing a name for the type, which is a one place predicate name.

Some types are left undefined in the model, used by the modeler as primitives, while other types are defined.

The definition of a type takes the form of a statement with two parts. Each part is a statement. The two parts are joined by the connective, 'means'.

The first part, the defined expression, contains the constant predicate name for the type, and applies that to exactly one variable name; the second part, the type specification, is an open statement with exactly the same variable free (with that variable free, and no other variable free).

Thus, the syntax of a type definition is:

<defined expression> means <type specification>

The type specification expresses the conditions that must hold for a model element to be of the type. The definition has the force that every occurrence of the type applied to some model element can be replaced, with no change of meaning, with an occurrence of the type specification, applied to the same model element.

There are examples at: www.community-ml.org/2torial/2torial-4.1.htm .

In OCL 2, the syntax of a type definition is:

<defined expression> :- <type specification>

That is to say:

Type ::= TypeName | PredicateName
PredicateDefinition ::= PredicateName ( {VariableName {',' VariableName}* }? ) ':-' OclExpression
TypeName ::= Name
PredicateName ::= Name

Q: What is the difference between a type, the specification of that type, and the extension of the type?

A: Types in a model have names. A type may also have a definition in the model. The definition of a type has two parts, the defined expression and the type specification. The defined expression gives the name for the type. The type specification defines the type.

Two type names are names for the same type (the two named types are identical) if, whenever a model element satisfies either one of those types, that model element must also satisfy the other type. This is called the identity criterion for types, which tells us what a type "is". As a primitive term in UML, the concept of type itself can have no definition, but only identity criteria and other modeling invariants that govern its use.

Two distinct type specifications specify the same type if any model element that satisfies one specification must also satisfy the other. For example, consider the type named equilateral triangle, with specification, 'a triangle with all sides equal in length', and the type named equiangular triangle, with specification 'a triangle with all angles equal'. These are the same type, since they must apply to the same sets of triangles. Similarly, 'maternal uncle' and 'male sibling of mother' are two specifications for the same type. This demonstrates that a type is something different from the specification of the type.

The extension of a type in a model is the model elements of that type. The extension of a type in the system modeled is all the things in the system that could be represented by model elements that are of that type.

Thus, we have identified two distinct but related entities, in addition to type, that are often of importance:

1. the type specification
2. the extension of the type

These related concepts are the ones that a modeler works with most often, the underlying concept of type is what ties the two together.

Taking a bottom up approach, consider what it is that two type checkers must have in common if they both return the same results for the same input. Type is the abstraction representing what all type checkers that always return the same results have in common.

Q: Well, what you have said so far in the 2torial may give some people a feel for what a type is, but I am not satisfied that you have given the concept an exact meaning unless you can give me a formal definition. Can you satisfy me at all?

A: As a primitive concept, type cannot be defined within UML, but a formal semantics can be provided for UML, in which the semantics of type is given. This can be done in one of two ways:

-using standard model theory, in terms of the set of all interpretations of a UML model (that is, using model theoretic assertions about this set and semantic mappings from the model to the interpretations); or

-using Skolem semantics, as assertions about all the consistent extensions of the UML model, that is, as assertions about sets of UML models, rather than assertions about a single model (Assertions about sets of all models are required to formally define type, because type is an intensional concept - one that depends on what is necessary, rather than an extensional one, that depends only on what is true in a given model.)

To construct a formal semantics for type, we start with the intuitive meaning, and construct a mathematical analog to this-that is, something that will behave as our intuitions suggests it should. The intuitive meaning of a type is that it is what is essential about the concept in every model that uses that type, and in every system that any model using that type can be used to describe.

In standard model theory, an interpretation I of the model is a pair consisting of a system S and an interpretation function i. [A true interpretation (or so-called "model" of the UML model - for those who have never before encountered this ass-backwards use of the word "model", just pretend we did't say it), is one in which all the statements in the UML model are true, using i as the mapping between model elements and phenonima or observations in S. ]

i(T) is how the concept represented by the type symbol 'T' applies to the system S. The concept T itself is how T applies to any system. Our goal is to define some set theoretic entity that captures this intuition. One standard way to do this is to construct the set of all extensions of T, as follows.

The extension of a type in an interpretation I is the set of all the things in the system to which the interpretation of the type apply. That is, the extension of a type T is the subset of phenonima p in S such that i(T) applies to p, [or, if one wishes to treat the system S as itself a set-theoretic structure, then the extension of T in S is the set i(T)].

Now, because the meaning of the concept is determined by how T is to be interpreted in all true intepretations of the model M, the type itself is mathematically modelled as the equivalence class of all the extensions of the type in every true interpretation of the model. An equivalence class is a class of all of which are equivelent with respect to some property. The property in question here is simply being an extension of T in a true interpretation of M.

For example, if we define the type, parallel processor, in a given model, then a model theoretic interpretation i of that type in one system S will be a property that applies only to the parallel processors in that system. The equivalence class is the class of all the sets of parallel processors that are the extensions of the type in any system correctly represented by the model.

In a Skolem semantics, the extensions of the type in models themselves are used to form the equivalence class. That is, we do not go outside the realm of UML models to systems, but merely consider sets of model elements themselves as extensions of the type.

We have here two very different meanings of 'extension.'

One is the meaning in the phrase, 'extension of a type,' as explained above. [This in turn has two subcases, the extension of the type as a set of model elements that the model says or logically implies are of that type, and the other being the extension of the type as a set of system elements that the model elements represent.]

The other meaning of 'extension' is that in the phrase, 'an extension of a UML model.' An extension of a model is a second model that contains all the statements of the first model, with one or more statements added. A consistent extension of a model is a second model that contains all the statements of the first model, with one or more statements added, all of which are logically consistent with the statements in the first model.

In each such consistent extension of the model, the extension of the type (two different meanings for 'extension') may be different. For example, one model may have only one model element that is a parallel processor, while another model may have two. But the meaning of the type, parallel processor, covers both models. This meaning of the type is mathematically explicated as the equivalence class of all the extensions of the type in every consistent extension of the model (again, two different meanings for 'extension').

This fancy footwork is necessary to avoid the naïve mistake, recognized by Aristotle, Abelard, Frege, Tarski, and many in between, of confusing a type and its specification. Understanding that types are about meaning, the natural first move is to identify the type and its specification-but, as we have shown, two different specifications can specify the same type. With this equivalence class approach, the type is shown to be what the specifications essentially say about the model and its interpretations, not the words they happen to use.

Using either of these two approaches, standard model theory or Skolem semantics, the equivalence classes defined by any two types will be identical only if the two types are identical, according to our intuitive identity criterion for types. In general, standard model theory and Skolem semantics give us a way to explicate necessity with set theory, and not resort to using necessity as a primitive concept, thus avoiding things like modal logics.

Note that, because types are model elements, the underlying logic of UML is a second order logic. However, by adopting a Henkin semantics (in which only named types exist) this logic is equivalent to a first order logic. Henkin semantics is consistent with both model theoretic semantics and Skolem semantics.

Q: How does subtyping relate to inheritance?

A: Inheritance is a relationship between definitions or specifications, including type specifications. One specification can inherit (reuse) expressions already used in another specification. Remember the generic example given earlier:

x is of type S means x is of type T and <...>

Although the definition of a subtype will often inherit from the definition of a supertype, it need not. That is to say, subtyping need not imply inheritance. For example, square is a subtype of parallelogram. But if parallelogram is given the definition "quadrilateral with all opposing sides parallel", and square is given the definition "quadrilateral with four equal sides and four equal angles," then the definition of square has not inherited from the definition of parallelogram. (Although both have inherited from the definition of quadrilateral).

Similarly, inheritance need not imply subtyping. For example, if the specification of a square includes the length of side1, the specification of a parallelogram can inherit from the specification of a square, and add the length of side2 and the size of angle1. So the type, parallelogram, inherits from the type, square, but is not a subtype of square.

Though we sometimes neglect this important distinction, it has been known since ancient times In the context of object-oriented langauges, this was discussed at length in 1990 by the good folks at Hewlett-Packard Laboratories.

William R. Cook, Walter Hill and Peter S. Canning, “Inheritance is not subtyping,” POPL '90, Proceedings of the seventeenth annual ACM symposium on Principles of Programming Languages, New York: ACM, 1990.
www.acm.org/pubs/contents/proceedings/plan/96709/

Q: Some people say inheritance should not be used except when there it also subtyping. Are you saying this?

A: This is really a question about methodology. UML 2 does not prescribe an answer.

In some circumstances, good practice requires that inheritance only be used from a supertype to a subtype.

However, the extension relationship between use cases is a use of non-subtyping inheritance that is accepted by many as a good practice.

Q: I've heard you use the term, 'incremental modification'. What do you mean by that?

A: Incremental modification is the process of starting with a specification and making one or more changes to produce another modification.

Inheritance is a particular kind of incremental modification.

www.community-ml.org/RM-ODP/Part2/9.html#9.21

Criteria for considering a change to be an incremental modification were carefully discussed in 1998 by two gentlemen at Brown.

Peter Wegner and Stanley B Zdonik, "Inheritance as an Incremental Modification Mechanism or What Like Is and Isn't Like," Proceedings of ECOOP'88 (Oslo, Norway, 1988), Berlin: Springer, 1988. LNCS 322

Back Contents

DA.gif (4367 bytes)