UML types and instances

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.

The Unified Modelling Language (UML) started by incorporating best practices from object-oriented programming and architectural description languages.

A stated objective is now to provide system architects with tools for modelling business and similar processes.

However, UML terms are still somewhat oriented towards relations between the elements of object-oriented software systems.

This paper explains why this work does not follow UML.

In OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, section 6.3 introduces 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)

“Instance”

UML has two meanings for “instance”:

· one narrower – and instance of a classifer

· one broader – an instance of a type in UML

This work uses the term “instance” to describe any thing that embodies any type.

“Classifier”

UML may appear to uses the word “classifier” in a sense similar to “type” in this work

“A classifier is a classification of instances, it describes a set of instances that have features in common.”

But UML has a narrower meaning for “instance”, so this work favours the word type over classifier.

“Class”

UML uses the term “class” for a particular kind of type – related to structural objects only – not behavioural ones.

Others use the term class to mean a set or a collection, rather than a descriptive type.

This work favours the word type over class, except with reference to an object-oriented programming (OOP) context.

“Manifestation”

UML arranges some of its relations in a type hierarchy.

Dependency relation - changes to one related element can cause changes in the other

Abstraction [a dependency relation] between elements that represent the same concept at different levels of abstraction

Manifestation [an abstraction relation] in which one element manifests/includes a specific implementation for, the features of another

Realisation [an abstraction relation] that exists between two model elements when one of them must implement the behaviour that the other specifies.

Implementation [a realisation relation] that specifies that the realizing classifier must conform to the contract that the provided interface specifies

Manifestation has a very software-engineering specific meaning in UML, but stepping back from that, it is the best fit to the type-instance relationship, which:

is a two-way dependency – since a change to either type or instance can break the relation

is an abstraction – since the type represents the concept of an instance at a higher level of abstraction

is a manifestation - since instances manifest features or rules declared in the type

may also be a realisation – if instances realize or implement behaviour that the type specifies

may also be an implementation - if instances must conform to a contract that the type specifies.

And within a model, a type-instance relation is an association – a structural relationship that connects an instance to a type.

The IBM web site summarises UML relations in the table below.

Relationship type	Description
Abstraction	An abstraction relationship is a dependency between model elements that represent the same concept at different levels of abstraction or from different viewpoints. You can add abstraction relationships to a model in several diagrams, including use case, class, and component diagrams.
Aggregation	An aggregation relationship depicts a classifier as a part of, or as subordinate to, another classifier.
Association	An association relationship is a structural relationship between two model elements that shows that objects of one classifier (actor, use case, class, interface, node, or component) connect and can navigate to objects of another classifier. Even in bidirectional relationships, an association connects two classifiers, the primary (supplier) and secondary (client).
Binding	A binding relationship is a dependency relationship that assigns values to template parameters and generates a new model element from the template.
Communication path	A communication path is a type of association between nodes in a deployment diagram that shows how the nodes exchange messages and signals.
Composition	A composition relationship represents a whole–part relationship and is a type of aggregation. A composition relationship specifies that the lifetime of the part classifier is dependent on the lifetime of the whole classifier.
Control flow	A control flow is a type of activity edge that models the movement of control from one activity node to another.
Dependency	A dependency relationship indicates that changes to one model element (the supplier or independent model element) can cause changes in another model element (the client or dependent model element). The supplier model element is independent because a change in the client does not affect it. The client model element depends on the supplier because a change to the supplier affects the client.
Deploy	A deploy relationship shows the specific component that an instance of a single node uses. In a UML model, a deploy relationship typically appears in deployment diagrams.
Directed association	A directed association relationship is an association that is navigable in only one direction and in which the control flows from one classifier to another (E.g. from an actor to a use case). Only one of the association ends specifies navigability.
Extend	An extend relationship between use cases indicates that one use case, the extended use case, can extend another use case, the base use case. An extend relationship has the option of using the extended use case.
Generalization	A generalization relationship indicates that a specialized (child) model element is based on a general (parent) model element. Although the parent model element can have one or more children, and any child model element can have one or more parents, typically a single parent has multiple children. In UML 2.0, several classes can constitute a generalization set of another class. Generalization relationships appear in class, component, and use case diagrams.
Implementation	An implementation relationship is a specialized type of realization relationship between a classifier and a provided interface. The implementation relationship specifies that the realizing classifier must conform to the contract that the provided interface specifies.
Include	An include relationship between use cases specifies that an including (or base) use case requires the behavior from another use case (the included use case). In an include relationship, a use case must use the included use case.
Manifestation	A manifestation relationship shows which model elements, such as components or classes, are manifested in an artifact. The artifact manifests, or includes, a specific implementation for, the features of one or several physical software components.
Note attachment	A note attachment relationship connects a note or text box to a connector or shape. A note attachment indicates that the note or text box contains information that is relevant to the attached connector or shape.
Object flow	An object flow is a type of activity edge that models the flow of objects and data from one activity node to another.
Realization	A realization relationship exists between two model elements when one of them must realize, or implement, the behavior that the other specifies. The model element that specifies the behavior is the supplier, and the model element that implements the behavior is the client. In UML 2.0, this relationship is normally used to specify those elements that realize or implement the behavior of a component.
Usage	A usage relationship is a dependency relationship in which one model element requires the presence of another model element (or set of model elements) for its full implementation or operation. The model element that requires the presence of another model element is the client, and the model element whose presence is required is the supplier. Although a usage relationship indicates an ongoing requirement, it also indicates that the connection between the two model elements is not always meaningful or present.

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 07/01/2016 13:07

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org