Class
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.
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).
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.
Class SearchService - 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:
- different values for different featuring classifiers, or
- the same value for all featuring classifiers.
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.
Class SearchService - implementation level details.
The createEngine is static operation
Attributes or operations may be grouped by visibility. A visibility keyword or symbol in this case can be given once for multiple features with the same visibility.
Class SearchService - attributes and operations grouped by visibility
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.
In UML 2.5 class became structured, encapsulated, and behaviored by extending encapsulated classifier and behaviored classifier. Because of this, any class may have some internal structure and ports.
Library Services is structured class encapsulated through searchPort port.
The nesting of classifiers defined within the scope of the structured class limits the visibility of the classifiers to the scope of the namespace of the containing structured class and thus supports encapsulation (information hiding) through ports.
Structured class Online Shopping with Shopping port and internal structure.
Abstract Class
UML 2.4 mentions abstract class but provides no definition. We can probably relate definition of abstract classifier to abstract class. We may assume that in UML 2.x abstract class does not have complete declaration and "typically" can not be instantiated. An abstract class is intended to be used by other classifiers (e.g., as the target of generalization generalization relationships).
UML 2.4 provides no explanation of the "incomplete class declaration" and whether it is related to the concept of abstract operation - which was also present in UML 1.4.2 and is absent in UML 2.x.
Attempting to create an instance of an abstract class is undefined - some languages may make this action illegal, others may create a partial instance for testing purposes.
The name of an abstract class is shown in italics.
Class SearchRequest is abstract class
An abstract classifier can also be shown using the keyword {abstract} after or below the name.
Revisions
Abstract class was defined in UML 1.4.2 as class that can't be directly instantiated. 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.
Standard Class Stereotypes
There are several standard UML stereotypes that apply to classes:
| Name | Description |
|---|---|
| «Auxiliary» |
Auxiliary is class that supports another more central or fundamental class,
typically by implementing secondary logic or control flow.
The class that the auxiliary supports may be defined either explicitly using
a focus class
or implicitly by
a dependency relationship.
Auxiliary classes are typically used for specifying the secondary business logic or control flow of components during design phase. |
| «Focus» |
Focus is class that defines the core logic or control flow for one or more
supporting classes. The supporting classes may be defined either explicitly using
auxiliary classes
or implicitly by
dependency relationships.
Focus classes are typically used for specifying the core business logic or control flow of components during design phase. |
| «ImplementationClass» |
The implementation of a class in some programming language (e.g., C++, Smalltalk, Java)
in which an instance may not have more than one class.
This is in contrast to UML class, for which an instance may have multiple classes at one time and may gain or lose classes over time, and an object may dynamically have multiple classes. An implementation class may realize a number of different types. The physical attributes and associations of the implementation class do not have to be the same as those of any classifier it realizes and the implementation class may provide methods for its operations in terms of its physical attributes and associations. |
| «Metaclass» | A class whose instances are also classes. |
| «Type» |
Type is class that specifies a domain of objects together with the operations
applicable to the objects, without defining the physical implementation of those objects.
Type may have attributes and associations. Behavioral specifications for type operations may be expressed using, for example, activity diagrams. An object may have at most one implementation class, however it may conform to multiple different types. |
| «Utility» |
Utility is class that has only class scoped
static attributes and operations.
As such, utility class usually has no instances.
Math is utility class - having static attributes and operations (underlined) |
Note, that naming convention for stereotypes and applied stereotypes was changed in UML 2.4.1 to have the first letter in upper case. You will still see stereotypes in lower case, e.g. «focus», «type», everywhere as it will take some time to switch to the new notation.
There are several nonstandard but routinely used class stereotypes available in several UML tools including IBM Rational Software Architect (RSA) and Sparx Enterprise Architect: «Boundary», «Control», «Entity».
These class stereotypes are part of the Analysis Profile in RSA which is applied by default with the Analysis Model template. 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.
| Name | Description |
|---|---|
| «Boundary» |
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» |
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. Note, that UML has standard «Focus» stereotype applicable to classes which could be used for specifying the core business logic or control flow of components during design. |
| «Entity» |
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. Note, that in UML 1.4.2 stereotype «entity» represented a passive class, i.e. class whose objects do not initiate interactions on their own. UML 2.0 updated «Entity» standard stereotype to be applicable to components and representing a business concept of a persistent information. |
Class Template
UML classes could be templated or bound.
The example below shows template class Array with two formal template parameters. The first template parameter T is an unconstrained class template parameter. The second template parameter n is an integer expression template parameter.
Template binding for the bound class Customers substitutes the unconstrained class T with class Customer and boundary n with integer value 24. Thus, the bound class Customers is an Array of 24 objects of Customer class.
Template class Array and bound class Customers.
