UML Class Diagrams Reference

A class is a classifier which describes a set of objects that share the same

• features
• constraints
• semantics (meaning).

A class is shown as a solid-outline rectangle containing the class name, and optionally with compartments separated by horizontal lines containing features or other members of the classifier.

Utility is class that has only class scoped static attributes and operations. As such, utility class usually has no instances.

Abstract class was defined in UML 1.4.2 as class that can't be directly instantiated. No object may be a direct instance of an abstract class.

UML 2.4 mentions abstract class but provides no definition. We may assume that in UML 2.x abstract class does not have complete declaration and "typically" can not be instantiated.

The name of an abstract class is shown in italics.

A class or interface could be used as a namespace for various classifiers including other classes, interfaces, use cases, etc. This nesting of classifier limits the visibility of the classifier defined in the class to the scope of the namespace of the containing class or interface.

In obsolete UML 1.4.2 a declaring class and a class in its namespace may be shown connected by a line, with an "anchor" icon on the end connected to a declaring class (namespace). An anchor icon is a cross inside a circle.

UML 2.x specifications provide no explicit notation for the nesting by classes. Note, that UML's 1.4 "anchor" notation is still used in one example in UML 2.4.x for packages as an "alternative membership notation".

UML classes could be templated or bound.

The example to the left shows bound class Customers with substitution of the unconstrained parameter class T with class Customer and boundary parameter n with the integer value 24.

An interface is a classifier that declares of a set of coherent public features and obligations. An interface specifies a contract.

In UML 1.4 interface was formally equivalent to an abstract class with no attributes and no methods and only abstract operations.

An interface may be shown using a rectangle symbol with the keyword «interface» preceding the name.

The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.

Object is an instance of a class or an interface. Object is not a UML element by itself. Objects are rendered as instance specifications, usually on object diagrams.

Class instance (object) could have no name, be anonymous.

In some cases, class of the instance is unknown or not specified. When instance name is also not provided, the notation for such an anonymous instance of an unnamed classifier is simply underlined colon - :.

If an instance has some value, the value specification is shown either after an equal sign ('=') following the instance name, or without the equal sign below the name.

Slots are shown as structural features with the feature name followed by an equal sign ('=') and a value specification. Type (classifier) of the feature could be also shown.

A data type is a classifier - similar to a class - whose instances are identified only by their value.

A data type is shown using rectangle symbol with keyword «dataType».

A data type may contain attributes and operations to support the modeling of structured data types.

When data type is referenced by, e.g., as the type of a class attribute, it is shown simply as the name of the data type.

A primitive type is a data type which represents atomic data values, i.e. values having no parts or structure. A primitive data type may have precise semantics and operations defined outside of UML, for example, mathematically.

Standard UML primitive types include:

• Boolean,
• Integer,
• UnlimitedNatural,
• String.

A primitive type has the keyword «primitive» above or before the name of the primitive type.

An enumeration is a data type whose values are enumerated in the model as user-defined enumeration literals.

An enumeration may be shown using the classifier notation (a rectangle) with the keyword «enumeration». The name of the enumeration is placed in the upper compartment.

A list of enumeration literals may be placed, one to a line, in the bottom compartment. The attributes and operations compartments may be suppressed, and typically are suppressed if they would be empty.

A qualifier is a property which defines a partition of the set of associated instances with respect to an instance at the qualified end.

Qualifiers are used to model hash maps in Java, dictionaries in C#, index tables, etc. where fast access to linked object(s) is provided using qualifier as a hash key, search argument or index.

A qualifier is shown as a small rectangle attached to the end of an association between the final path segment and the symbol of the classifier that it connects to. The qualifier rectangle is part of the association, not part of the classifier. A qualifier may not be suppressed.

In the case in which the target multiplicity is 0..1, the qualifier value is unique with respect to the qualified object, and designates at most one associated object.

In the case of target multiplicity 0..*, the set of associated instances is partitioned into possibly empty subsets, each selected by a given qualifier instance.

UML 2.4 specification is gibberish explaining multiplicity of qualifier:

The multiplicity of a qualifier is given assuming that the qualifier value is supplied. The “raw” multiplicity without the qualifier is assumed to be 0..*. This is not fully general but it is almost always adequate, as a situation in which the raw multiplicity is 1 would best be modeled without a qualifier.

Operation is a behavioral feature of a classifier that specifies the name, type, parameters, and constraints for invoking an associated behavior.

When operation is shown in a diagram, the text should conform to the syntax defined in UML specification. Note, that UML 2.2 to 2.4 specifications seem to have wrong nesting for operation's properties, making presence of the properties dependent on the presence of return type. The syntax provided here is non-normative and different from the one in the UML 2.4 specification:

operation ::= [ visibility ]   signature   [ oper-properties ]

Visibility of the operation is optional, and if present, it should be one of:

visibility ::= '+' | '-'  | '#' | '~'

Signature of the operation has optional parameter list and return specification.

signature ::= name   '('   [ parameter-list ] ')'   [ ':' return-spec ]

Name is the name of the operation. Parameter-list is a list of parameters of the operation in the following format:

parameter-list ::= parameter   [   ','   parameter   ]*

parameter ::= [ direction   ]   parm-name ':' type-expression   [   '[' multiplicity ']'   ]   [ '=' default ]   [ parm-properties ]

Parm-name is the name of the parameter. Type-expression is an expression that specifies the type of the parameter. Multiplicity is the multiplicity of the parameter. Default is an expression that defines the value specification for the default value of the parameter. Parameter list can be suppressed.

Direction of parameter is described as one of:

direction ::=   'in' | 'out' | 'inout' | 'return'
and defaults to 'in' if omitted.

Optional parm-properties describe additional property values that apply to the parameter.

parm-properties ::= '{'  parm-property  [ ',' parm-property ]* '}'

Optional return specification is defined as:

return-spec ::= [ return-type ]  [ '[' multiplicity  ']' ]

Return type is the type of the result, if it was defined for the operation. Return specification also has optional multiplicity of the return type.

Properties of the operation are optional, and if present should follow the rule:

oper-properties ::= '{' oper-property   [   ',' oper-property ]*   '}'

oper-property ::=   'redefines' oper-name |  'query' | 'ordered' | 'unique' |  oper-constraint

Properties of operation describe operation in general or return parameter, and are defined as:

• redefines oper-name - operation redefines an inherited operation identified by oper-name;
• query - operation does not change the state of the system;
• ordered - the values of the return parameter are ordered;
• unique - the values returned by the parameter have no duplicates;
• oper-constraint - is a constraint that applies to the operation.

Abstract operation in UML 1.4.2 was defined as operation without implementation - "class does not implement the operation". Implementation had to be supplied by a descendant of the class.

Abstract operation in UML 1.4.2 was shown with its signature in italics or marked as {abstract}.

There is neither definition nor notion for abstract operation in UML 2.4.

Constraint could have an optional name, though usually it is anonymous. A constraint is shown as a text string in curly braces according to the syntax:

constraint ::= '{' [  name ':' ] boolean-expression '}'

For an element whose notation is a text string (such as a class attribute, etc.), the constraint string may follow the element text string in curly braces.

Multiplicity is a definition of an inclusive interval of non-negative integers to specify the allowable number of instances of described element.

Multiplicity could be described with the following non-normative syntax rules:
     multiplicity ::= multiplicity-range  [ '{' multiplicity-options '}' ]

Some typical examples of multiplicity bounds:

Multiplicity options could also specify of whether the values in an instantiation of the element should be unique and/or ordered:
     multiplicity-options ::=
         order-designator [ ','  uniqueness-designator ] |
         uniqueness-designator [ ','  order-designator ]
     order-designator ::= 'ordered' | 'unordered'
     uniqueness-designator ::= 'unique' | 'nonunique'

If multiplicity element is multivalued and specified as ordered, then the collection of values in an instantiation of this element is sequentially ordered. By default, collections are not ordered.

If multiplicity element is multivalued and specified as unique, then each value in the collection of values in an instantiation of this element must be unique. By default, each value in collection is unique.

Visibility allows to constrain the usage of a named element, either in namespaces or in access to the element. It is used with classes, packages, generalizations, element import, package import.

UML has the following types of visibility:

• public (+)
• package (~)
• protected (#)
• private (-)

If a named element is not owned by any namespace, then it does not have a visibility.

Association is a relationship between classifiers which is used to show that instances of classifiers could be either linked to each other or combined logically or physically into some aggregation.

It is normally drawn as a solid line connecting associated classifiers.

Binary association relates two typed instances. It is normally rendered as a solid line connecting two classifiers, or a solid line connecting a single classifier to itself (the two ends are distinct). The line may consist of one or more connected segments.

Composite aggregation (aka composition) is a "strong" form of aggregation.

Composition is depicted as binary association decorated with a filled black diamond at the aggregate (composite) end.

When composition is used in domain models, both whole/part relationship as well as event of composite "deletion" should be interpreted figuratively, not necessarily as physical containment and/or termination.

Multiplicity of the composite (whole) could be specified as 0..1 ("at most one") which means that part is allowed to be a "stand alone", not owned by any specific composite.

Dependency relationship is used on class diagrams to show usage dependency or abstraction.

A dependency is generally shown as a dashed arrow between two model elements. The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier). The arrow may be labeled with an optional stereotype and an optional name.

Usage is a dependency relationship in which one element (client) requires another element (or set of elements) (supplier) for its full implementation or operation.

For example, it could mean that some method(s) within a (client) class uses objects (e.g. parameters) of the another (supplier) class.

A usage dependency is shown as a dependency with a «use» keyword attached to it.

Create is a usage dependency denoting that the client classifier creates instances of the supplier classifier. It is denoted with the standard stereotype «create».

Create may relate an instance value to a constructor for a class, describing the single value returned by the constructor operation. The operation is the client, the created instance the supplier. The instance value may reference parameters declared by the operation.

The usage dependency from a classifier to an interface is shown by representing the interface by a half-circle or socket, labeled with the name of the interface, attached by a solid line to the classifier that requires this interface.