Class Diagrams

Class diagram is UML structure diagram which shows structure of the designed system at the level of classes and interfaces, shows their features, constraints and relationships - associations, generalizations, dependencies, etc.

Class

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).

Class is shown as solid-outline rectangle containing the class name.

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.

Middle compartment holds attributes and the bottom one holds operations - analysis.

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:

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.

Middle compartment holds attributes and the bottom one holds operations - implementation.

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.

Attributes or operations may be grouped by 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.

Abstract Class

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.

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.

Abstract class has class name in italics.

Class SearchRequest is abstract class

An abstract classifier can also be shown using the keyword {abstract} after or below the name.

Standard Class Stereotypes

Standard UML class stereotypes include:

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.

«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.

«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.

«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.

Utility class Math has static attributes and operations underlined.

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 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.

«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 UML has standard «Entity» stereotype 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.

Template class Array and bound class Customers.

Interface

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.

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.

Interface shown as a rectangle with the keyword interface.

Interface SiteSearch

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.

Interface shown as a rectangle with compartments.

Interface Pageable

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, labeled with the name of the interface and attached by a solid line to the classifier that realizes this interface.

Interface realization dependency from a classifier to an interface.

Interface SiteSearch is realized (implemented) by SearchService.

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.

Usage dependency from a classifier to an interface.

Interface SiteSearch is used (required) by SearchController.

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.

Object

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 - anonymous.

Anonymous instance of the Customer class.

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

Class instance (object) could have no associated classifier.

Instance newPatient of the unnamed or unknown class.

Interface instance (object) could have both name and associated classifier.

Instance checkAcct of the Account interface.

Class instance (object) could have instance name, class and namespace (package) specified.

Class instance (object) could have a name, class and namespace (package) specified.

Instance front-facing-cam of the Camera class
from android.hardware package.

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.

Instance value is shown either after an equal sign or below the instance name.

Instance orderPaid of the Date class
has value July 31, 2011 3:00 pm.

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.

Slots are shown with the feature name followed by an equal sign and a value.

Instance newPatient of the Patient class
has slots with values specified.

Data Type

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».

Data type shown as rectangle symbol with keyword dataType - DateTime.

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.

Structured data type shown with atributes - Address.

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.

Attributes of the Patient class are of data types Name, Gender, DateTime, Address and Visit.

Attributes of the Patient class are of data types Name, Gender, DateTime, Address and Visit.

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.

Primitive data type Weight.

Primitive data type Weight.

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.

Enumeration AccountType.

Enumeration AccountType.

Operation

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

Operation is invoked on an instance of the classifier for which the operation is a feature. If operation is marked as isQuery, execution of the operation leaves the state of the system unchanged, no side effects may occur. The default value is false, so operation is assumed to have side effects and change state of the system.

Operation in UML can have at most one return parameter. Operation may raise an exception during its invocation.

An operation may be redefined in a specialization of the featured classifier. This redefinition may specialize the types of the owned parameters, add new preconditions or postconditions, add new raised exceptions, or otherwise refine the specification of the operation.

When operation is shown in a diagram, the text should conform to the syntax defined in UML specification. Note, that UML 2.2 to UML 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 UML 2.4 specification:
     operation ::= [ visibility ]   signature   [ oper-properties ]

Visibility of the operation is optional, and if present, it should be one of:
     visibility ::=   '+'   |   '-'   |   '#'   |   '~'

Visibility of the operation could be public, proected, package, or private.

Operation executeQuery is public, isPoolable - protected,
getQueryTimeout - with package visibility, and
clearWarnings is private.

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.

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

File has two static operations - create and slashify. Create has two parameters and returns File.
Slashify is private operation. Operation listFiles returns array of files.
Operations getName and listFiles either have no parameters or parameters were 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 ]*   '}'

Return specification if present 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.

Direction of parameter could be in, out, inout, or return.

Operation setDaemon has one input parameter, while single parameter of changeName
is both input and output parameter. Static enumerate returns integer result
while also having output parameter - array of threads.
Operation isDaemon is shown with return type parameter.
It is presentation option equivalent to returning operation result as: +isDaemon(): Boolean.

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:

Properties of the operation could be redefines, query, ordered, unique.

Operation check redefines inherited operation status from the superclass.
Operation getPublicKey does not change the state of the system.
Operation getCerts returns ordered array of Certificates without duplicates.

Abstract 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 a notion for the abstract operation in UML 2.4.

Next  Property

blog comments powered by Disqus