| Previous | UML Classes | Table of Contents | UML Packages | Next |
A large number of UML metaclasses can be arranged into 4 levels with metasemantic relationships among the metaclasses in the
different levels that transcend different semantic categories (e.g., classifiers, events, behaviors). We have tried (with
incomplete success) to provide a consistent naming pattern across the various categories to place elements into levels and
emphasize metarelationships among related elements in different levels. The following 4 levels are important:
Type level – Represents generic types of entities in models, such as classes, states, activities, events, etc. These are the
most common constituents of models because models are primarily about making generic specifications.
Instance level – These are the things that models represent at runtime. They don’t appear in models directly (except very
occasionally as detailed examples), but they are necessary to explain the semantics of what models mean. These classes do
not appear at all in the UML2 metamodel or in UML models, but they underlie the meaning of models. We provide a brief runtime
metamodel in the Common Behavior chapter, but we do not formally define the semantics of UML using the runtime metamodel.
Such a formal definition would be a major amount of work.
Value specifications – A realization of UML2, compared to UML, is that values can be specified at various levels of precision.
The specification of a value is not necessarily an instance; it might be a large set of possible instances consistent with
certain conditions. What appears in models is usually not instances (individual values) but specifications of values that
may or may not be limited to a single value. In any case, models contain specifications of values, not values themselves,
which are runtime entities.
Individual appearances of a type within a context – These are roles within a generic, reusable context. When their context
is instantiated, they are also bound to contained instances, but as model elements they are reusable structural parts of their
context; they are not instances themselves. A realization of UML2 was that the things called instances in UML1 were mostly
roles: they map to instances in an instance of their container, but they are model elements, not instances, because they are
generic and can be used many times to generate many different instances.
We have established the following naming patterns:
Types : Instances : Values : Uses
Classifier, Class : Instance, Object : InstanceSpecification : Part, Role, Attribute, XXXUse (e.g., CollaborationUse )
Event : Occurrence : OccurrenceSpecification : various (e.g., Trigger)
Behavior : Execution : ExecutionSpecification : various (e.g., ActivityNode, State), XXXUse (e.g., InteractionUse )
The appearances category has too wide a variety of elements to reduce to a single pattern, although the form XXXUse is suggested
for simple cases where an appearance of an element is contained in a definition of the same kind of element.
In particular, the word event has been used inconsistently in the past to mean both type and instance. The word event now
means the type and the word occurrence means the instance. When necessary, the phrases event type (for event) and event occurrence
(for occurrence) may be used. Note that this is consistent with the frequent English usage an event occurs = the occurrence
of an event of a given type; so to describe a runtime situation, one could say event X occurs or an occurrence of event X
depending on which form is more convenient in a sentence. It is redundant and incorrect to say an event occurrence occurs.