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

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.

As class is the most widely used classifier, there is no need to add the "class" keyword in guillemets («») above the class name. Class name should be centered and in bold face, with the first letter of class name capitalized (if the character set supports upper case).

Figure 3.6. Class Customer—details suppressed

Features of a class are attributes and operations.

When class is shown with three compartments, the middle compartment holds a list of attributes and the bottom compartment holds a list of operations. Attributes and operations should be left justified in plain face, with the first letter of the names in lower case.

Figure 3.7. Class Customer—analysis level details.

Characteristics represented by feature may be of the classifier’s instances considered individually (not static) or of the classifier itself (static). The same feature cannot be static in one context and non static in another.

With regard to static features, two alternative semantics are recognized. Static feature may have:

In accordance with this semantics, inheritance of values for static features is permitted but not required by UML 2.

Static features are underlined—but only the names. An ellipsis (...) as the final element of a list of features indicates that additional features exist but are not shown in that list.

Attributes of a class are represented by instances of property that are owned by the class. Some of these attributes may represent the navigable ends of binary associations.

Objects of a class must contain values for each attribute that is a member of that class, in accordance with the characteristics of the attribute, for example its type and multiplicity.

Additional compartments may be provided to show other details, such as constraints, or just to divide features.

A class in the UML could be used as a namespace for other classifiers including classes, interfaces, use cases, etc. Nested classifiers are visible only within the namespace of the containing class.

Abstract class. Abstract class exists only for other classes to inherit from and to support reuse of the features declared by it. No object may be a direct instance of an abstract class, although an object may be an indirect instance of one through a subclass that is nonabstract.

The name of an abstract class is shown in italics.

Figure 3.8. Class Product is an abstract class

An abstract classifier can also be shown using the keyword «abstract» before the name.

Standard Class Stereotypes. Standard UML class stereotypes include:

Figure 3.9. Math is utility class having static attributes and operations (underlined)

Nonstandard Class Stereotypes. There are several nonstandard but routinely used class stereotypes available in several UML tools including IBM Rational Software Architect (RSA) and Sparx Enterprise Architect:

These class stereotypes are part of the so-called Robustness Diagrams which are nonstandard diagrams that often act as bridge from use cases to other models. The stereotypes roughly correspond to the parts of the Model-View-Controller (MVC) design pattern, where Boundary represents View, Control is Controller, and Entity corresponds to the Model.

«Boundary» is a stereotyped class or object that represents some system boundary, e.g. a user interface screen, system interface or device interface object. It could be used in the analysis or conceptual phase of development to capture users or external systems interacting with the system under development. It is often used in sequence diagrams which demonstrate user interactions with the system.

Boundary is drawn as a circle connected with a short line to a vertical line to the left It could be also shown as a class with the «Boundary» stereotype.

«Control» is a stereotyped class or object that is used to model flow of control or some coordination in behavior. One or several control classes could describe use case realization. System controls represent the dynamics of the designed system and usually describe some "business logic".

Control is drawn as a circle with embedded arrow on the top. It could be also shown as a class with the «Control» stereotype.

«Entity» is a stereotyped class or object that represents some information or data, usually but not necessarily persistent.

Entity is drawn as a circle with line attached to the bottom of the circle. It could be also shown as a class with the «Entity» stereotype.

Business entities represent some "things", items, documents, or information handled, used or processed by business workers while they do business. Examples of business entities are Prescription at the doctor's office, Menu at the restaurant, Ticket at the airport.

System entities represent some information or data, usually but not necessarily persistent, which is processed by the system.

An interface is a classifier that declares of a set of coherent public features and obligations. An interface specifies a contract. Any instance of a classifier that realizes (implements) the interface must fulfill that contract and thus provides services described by contract.

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

Figure 3.10. Interface Entity

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.

Since interfaces are declarations, they are not instantiable. Instead, an interface specification is implemented by an instance of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to the interface specification.

Any given classifier may implement more than one interface. Interface may be implemented by a number of different classifiers.

An association between an interface and any other classifier implies that a conforming association must exist between any implementation of that interface and that other classifier. In particular, an association between interfaces implies that a conforming association must exist between implementations of the interfaces.

Interfaces realized by a classifier are its provided interfaces, and represent the obligations that instances of that classifier have to their clients. They describe the services that the instances of that classifier offer to their clients.

Interface participating in the interface realization dependency is shown as a circle or ball (also known as the "lollipop notation"), labeled with the name of the interface and attached by a solid line to the classifier that realizes this interface.

Figure 3.11. Interface ProductDetails is realized (implemented) by Product.

Required interface specifies services that a classifier needs in order to perform its function and fulfill its own obligations to its clients. It is specified by a usage dependency between the classifier and the corresponding interface.

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.

Figure 3.12. Interface Product is used (required) by Order.

It is often the case in practice that two or more interfaces are mutually coupled through application-specific dependencies. In such situations, each interface represents a specific role in a multi-party “protocol.” These types of protocol role couplings can be captured by associations between interfaces.

An interface in the UML could be used as a namespace for other classifiers including classes, interfaces, use cases, etc. Nested classifiers are visible only within the namespace of the containing interface.

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

A typical use of data types would be to represent value types from business domain, primitive types or structured types of a programming language. For example, date/time, gender, currency, address could be defined as data types. All copies of an instance of a data type and any instances of that data type with the same value are considered to be equal instances.

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

Figure 3.13. DateTime data type

A data type may contain attributes and operations to support the modeling of structured data types. Instances of a structured data type are considered to be equal if the structure is the same and the values of the corresponding attributes are equal.

Figure 3.14. Structured data type Address

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.

Figure 3.15. Attributes of the Product contains an attribute of data type Money.

Primitive 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:

Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.

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

Figure 3.16. Primitive data type PersonalName.

Enumeration. 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 compartment listing the attributes for the enumeration is placed below the name compartment. A compartment listing the operations for the enumeration is placed below the attribute 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.

Figure 3.17. Enumeration CurrencyType.

A property is a structural feature which could represent

Here, we will only deal with attributes. A property owned by a classifier represents an attribute of the classifier. Context of the attribute is the owning classifier.

As a structural feature, property represents some named part of the structure of a classifier. For example, Product class could have name, description, unit price, etc. as its properties.

Figure 3.18. Attributes of the Product class are Name, Description and UnitPrice

When instance of a classifier is created, each non-static property becomes a part of the state of that instance, and is implemented by some mapping of the name of the property to a specific value or values that the state of the instance is composed of. Values of each property have specific type and are allocated in the slots of the instance or associated with that instance.

The general syntax for properties is shown below:

property ::= [ visibility ] ['/'] property-name [ ':' property-type ] [ '[' multiplicity ']' ] [ '=' default-value ] [ property-modifiers ]
visibility ::= '+' | '~' | '#' | '-'
property-modifiers ::= '{' property-modifier [ ',' property-modifier ] * '}'
property-modifier ::= 'id' | 'readOnly' | 'ordered' | ( 'seq' | 'sequence' ) | 'unique' | 'nonunique' | 'union' | 'redefines' property-name | 'subsets' property-name | property-constraint

Optional visibility is the visibility of the property. Note, that there is no default visibility. Also, visibility may be suppressed from being displayed on a diagram, even if it has some value in the model (e.g. stored by UML tool). So, if visibility is not shown on a diagram, it was either not specified or suppressed.

Forward slash '/' means that the property is derived. UML 2.x provides some lazy definition of derived property—property is derived when its value or values can be computed from other information.

The property-type is the type of the property represented by the name of classifier (in case of an attribute this is the attribute type).

Property could have multiplicity. The multiplicity bounds constrain the size of the collection of property values. By default the maximum bound is 1. Multiplicity is a definition of cardinality—i.e. number of elements—of some collection of elements by providing an inclusive interval of non-negative integers to specify the allowable number of instances of described element. Multiplicity interval has some lower bound and (possibly infinite) upper bound:

multiplicity-range ::= [ lower-bound '..' ] upper-bound
lower-bound ::= natural-value-specification
upper-bound ::= natural-value-specification | '*'

Lower and upper bounds could be natural constants or constant expressions evaluated to natural (non negative) number. Upper bound could be also specified as asterisk ('*') which denotes unlimited number of elements. Upper bound should be greater than or equal to the lower bound. If the multiplicity is associated with an element whose notation is a text string (such as a class attribute), the multiplicity range is placed within square brackets as part of that text string (as it can be seen in next to the Subtitle and Author attributes of class Book). This means that a book instance might or might not have a subtitle (optional attribute) and it has at least one author but it is possible that a book has multiple authors (without an upper bound).

Figure 3.19. Attribute multiplicities

Some typical examples of multiplicity:

The default-value option is an expression for the default value or values of the property.

Property may have optional modifiers:

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.

UML specification categorizes association as semantic relationship. Association could be used on different types of UML structure diagrams:

The various kinds of association relationships are shown in the following figure:

Figure 3.20. Association relationship overview diagram [UML-DIAGRAMS.ORG]

An association is usually drawn as a solid line connecting two classifiers or a single classifier to itself. Name of the association can be shown somewhere near the middle of the association line but not too close to any of the ends of the line. Each end of the line could be decorated with the name of the association end.

Association end is a connection between the line depicting an association and the icon depicting the connected classifier. Name of the association end may be placed near the end of the line. The association end name is commonly referred to as role name. The role name is optional and suppressible.

The idea of the role is that the same classifier can play the same or different roles in other associations. For example, Customer could be the purchaser of some Orders but he/she can be a reviewer of them if this customer is a responsible person for checking orders on behalf of a company when disposing bulk orders..

Figure 3.21. Association between Customer and Order with association ends is placed by and places.

Navigability. End property of association is navigable from the opposite end(s) of association if instances of the classifier at this end of the link can be accessed efficiently at runtime from instances at the other ends of the link.

UML specification does not dictate how efficient this access should be or any specific mechanism to achieve the efficiency. It is implementation specific.

Notation:

Figure 3.22. Both ends of association have unspecified navigability [UML-DIAGRAMS.ORG]

Figure 3.23. A2 has unspecified navigability while B2 is navigable from A2 [UML-DIAGRAMS.ORG]

Figure 3.24. A3 is not navigable from B3 while B3 has unspecified navigability [UML-DIAGRAMS.ORG]

Figure 3.25. A4 is not navigable from B4 while B4 is navigable from A4 [UML-DIAGRAMS.ORG]

Figure 3.26. A5 is navigable from B5 and B5 is navigable from A5 [UML-DIAGRAMS.ORG]

Figure 3.27. A6 is not navigable from B6 and B6 is not navigable from A6 [UML-DIAGRAMS.ORG]

Arity. Each association has specific arity as it could relate two or more items.

Shared and Composite Aggregation. Aggregation is a binary association representing some whole/part relationship. Aggregation type could be either:

Association Class. An association may be refined to have its own set of features; that is, features that do not belong to any of the connected classifiers but rather to the association itself. Such an association is called an association class. It is both an association, connecting a set of classifiers and a class, and as such could have features and might be included in other associations.

An association class can be seen as an association that also has class properties, or as a class that also has association properties.

An association class is shown as a class symbol attached to the association path by a dashed line. The association path and the association class symbol represent the same underlying model element, which has a single name. The association name may be placed on the path, in the class symbol, or on both, but they must be the same name.

Figure 3.30. Association class ProductSelection with details suppressed