3C Clear Clean Concise UML
Previous Contents Next
communityUML 2torial
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. This name is something that can be used in a model to specify or classify model elements. 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, connected by 'means'.
The first part, the defined expression, simply asserts that the type describes some arbitrary model element. The second part, the type specification, is a more complex statement about that same arbitrary model element. 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.
For example:
Type definition: x is persistent means when the system recovers from a crash, x is restored with the same data that was encapsulated by x upon completion of the last transaction, before that crash, which involved x.
Application of type: The object, myFoo, is persistent.
Substitution: When the system recovers from a crash, the object, myFoo, is restored with the same data that was encapsulated by the object, myFoo, upon completion of the last transaction, before that crash, which involved the object, myFoo.
To determine if some element is of a certain type, we take the type specification and replace the variable name with the name of that element. The result is a statement about that element. If the statement is true, that element is of that type.
For example (model inspection):
Application of type: The object, myFoo, is persistent.
Test: Examine the model to determine whether myFoo is designed so that its data may be restored. If myFoo is an instance of class, Foo, determine whether that class specifies a suitable persistence mechanism. If not, determine if some other mechanism in the model ensures the persistence of myFoo.
Another example (type checking):Type definition: int x means x is of an IntegralType or x is an instance of class Integer.
Application of type:
class Foo {
void set (int i);
}Test: Wherever, in the model, there appears an invocation of the operation, set, on some object of type Foo, determine the object that is the value of the expression given by the model as the argument to set. Compare the type of that object with int. That is, determine if that object is of an IntegralType or that object is an instance of class Integer.
Another test: Wherever, in the program text that is intended to conform to the model, there appears an invocation of the method, set, on a variable of a reference type determined by prior compiler analysis to be type Foo, determine the type of the expression supplied as argument to set. Compare that type with int according to the rules of The Java Language Specification.
Types are also used during testing:
For example (testing):
Application of type: The object, myFoo, is persistent.
Test: Start the system. Record the data encapsulated by the object in the system that is represented in the model by myFoo. Perform a transaction involving the object represented by myFoo, which changes that data. Record the data encapsulated by the object represented by myFoo after that transaction. Pull the plug. Recover. Record the data encapsulated by the object represented by myFoo. Compare that data with the data recorded after after the transaction and before pulling the plug.
An element that is of a type, is also said to 'satisfy' the type, or to be an 'instance
of' the type. An element of type, T, may be called 'a T '.
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.
Q: That tells me what a type is used for, not what a type is.
A: As with a number of fundamental concepts in UML 2, type does not have an explicit definition. Instead, the meaning of type is given by its use in the modeling invariants and in other definitions.
Follow this tutorial and you will see what a type is.
Or, if you like, read the definitions and modeling invariants of the 3C submission and learn the meaning of type from its use.
Or, let me tell you what a type is, without attempting
to provide a definition.
A type is a bin into which things are sorted (classify): "These are the objects
that need to be safely stored so that they can be recovered if the system crashes."
A type is a quick way to specify something (shorthand): "Make this object a
persistent entity bean."
A type is a way to catch errors (checking): "The model checker found a type
mismatch: a persistent object is expected, but a transient object is supplied in this
sequence diagram."
Q: I'd like to use types in my models. But, you say a type is defined by a statement. I don't want to be writing statements; I want to make drawings, and sometimes enter data in property sheets.
A: The type specification may, of course, be made using the drawing and property sheet capabilities of a modeling tool. For example, a UML class defines an object type.
Q: How does UML 2 type relate to the OMG concept, type?
A: Very similar. In the OMG object model "a type is an identifiable entity with an associated predicate (a single-argument mathematical function with a Boolean result) defined over entities." [OMG Object Model formal/2001-12-35 Chapter 1 ] In CORBA, object types are used for type checking (by IDL compilers and by ORBs), to specify an element, such as a parameter (in the IDL text), and to classify objects (in the interface repository).
UML 2 does not mention a single argument mathematical function. Instead it specifies that the definition of a type is a statement that contains exactly one variable name in the first part of the definition, and has that same variable name also in the second part of the definition. A formal semantics for UML 2, however, would say that the interpretation of a type in a system was a single argument mathematical function that mapped entities in the system (that can be represented by model elements) to a Boolean value.
UML 2 CORBA
one variable single argument
statement predicate
The CORBA object models says "An entity satisfies a type if the predicate is true for that entity."
UML 2 says that the definition of a type determines the
conditions that must hold for an element to be of that type.
"To determine if some element is of a certain type, we take the statement in the
second part of the definition of the type and replace the variable name with the name of
that element. The result is a statement about that element. If the statement is true, that
element is of that type. An element is said to ... 'satisfy' the type..."
UML 2 CORBA
statement predicate
satisfy satisfy
is true result is: true
The second part of the definition of a UML 2 type is, in fact, a predicate, but we have
here two meanings of 'predicate.' In the CORBA object model, 'predicate' has a technical
meaning particular to computer science: a function with a result of true or false.
In UML 2 'predicate' has its ordinary dictionary meaning: one of the two basic
constituents of a sentence.
The similarity of type in UML 2 to type in the CORBA object model is the result of this UML 2 design principle:
"Improve the architectural alignment [of UML] with
the CORBA Object Model." [3C submission Part 0]
(That was not a requirement of the RFP, but to us it is very important, only right, and
polite to the plumbers. (Without whom there would be no CORBA and no OMG.))
Q: What is a subtype?
A: A subtype is a type in relationship to another type. S is a subtype of T if every element of type S must also be of type T. Subtyping is therefore transitive and reflexive. Subtyping is also asymmetric among non-identical types, so is a partial order.
A subtype may be defined in terms of a supertype by adding to the definition of the supertype, or using the supertype in the definition of the subtype.
If T is a type and S is a subtype defined in terms of T, then the definition of S may be written:
x is of type S means x is of type T and <...>
where <...> is some statement that includes the variable, x.
However, not all subtypes are defined in terms of a supertype. The relationship between type definitions is, like all relationships between definitions, an inheritance (reuse of language) relationship, and not a relationship among the types themselves.
Q: What about the idea that any object that satisfies a subtype also satisfies the supertype?
A: That idea is right there. 'x is of type T' is a part of:
x is of type S means that x is of type T and <...>
Q: How does subtyping relate to inheritance?
A: We'll discuss that when we get to inheritance.
[If you can't wait, see the 3C submission 6.8.13 and 6.8.14. There'll be more
in the 2torial.]
Q: How does UML 2 type relate to the UML 1 concept, type.
A: In the UML 1 Semantics section, type is a stereotype of class; that is, any class marked with the stereotype, «type» is an object type. These are distinguished from implementation classes, marked with the stereotype, «implementation». UML 1 also has data types, which are types for data values.
In UML 2, a type may be defined for any kind of model element.
A UML 2 type is very much like a UML 1 classifier. But in UML 2, types are the basic mechanism for permitting the definition of implementations (for example, UML implementation classes), and these also can be used to produce any kind of model element, not only objects. In other words, types come first, as an undefined concept, and permit us to derive type specifications and implementations as defined concepts.
Q: How are names for the types of different model elements related to the names for those model elements themselves?
A: The UML 1 Notation Guide section takes a wider view than the Semantics section; the semantics section limits types to classifiers. The Notation Guide section says: "...the type-instance dichotomy is usually modeled by two paired modeling elements... : Class-Object, Association-Link, Parameter-Value, Operation-Invocation, and so on."
In UML 2, instead of having a pair of different names for type and instance, the same name is used for both: object and object type, association and association type, and so on.
This parallels what all other natural and mathematical languages do. For example, in English, there is not one word for a dog, and another entirely different word for the type, Dog - say, Hund. In fact, we would hardly ever need to say "dog instance" at all. We usually talk of the things, and only mark specially when we talk of the type.
"I believe the dog is also woman's best friend." (type)
"The dog is a canine mammal; the cat is a feline." (subtype)
"A dog would provide companionship." (typical unidentified object)
"Puss is her best friend." (named object)
"No, no; Puss is a dog." (named object, instance of a type)
"Uh, the dog ate my submission." (specific unnamed object)
Similarly, 'a number', in arithmetic, refers to some arbitrary number (an "instance") . Mathematicians have not elected to use some entirely different word, such as 'numero', to refer to the type, Number. There is an obvious reason for this general practice, in that types are used mostly as predicates to apply to instances. This benefit can be obtained for UML simply by not deviating from normal language usage.
Q: You talk a lot about specifying UML, exactly. But your submission is all just English. Is it true, what they say: that you guys aren't serious?
A: Please see the further discussion of type.
Q: I am interested in digging into the foundations of UML 2. Please tell me about how you support your notion of type.
A: Please see the further discussion of type.
Previous Contents Next RunningExample
The OMG
mark, ‘UML,’ is a trademark of
Object Management Group, Inc. (OMG).
During development of this web site, please send
comments to Joaquin Miller. mailto:joaquin@acm.org
Copyright © 2000 Financial Systems Architects