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.

You can find some class diagram examples here:

 Design Pattern - Abstract Factory

 Library Domain Model
 Domain Model - Hospital Management
 Domain Model - DICOM Model of the Real World

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

o features
o constraints
o 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:

o different values for different featuring classifiers, or

o the same value for all featuring classifiers.

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

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

Standard Class Stereotypes

Standard class stereotypes include:

 «focus»
 «auxiliary»
 «type»
 «utility»

«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.
Math is utility class - having static attributes and operations (underlined)

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

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

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 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 Patient class are of data types Name, Gender, DateTime and Address.

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:

 Boolean,
 Integer,
 UnlimitedNatural,
 String.

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.

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.
Property
A property is a structural feature which could represent an attribute of a classifier or an attribute
of association.

Property represents a declared state of one or more instances in terms of a named relationship to
a value or values.

When instantiated, property represents a value or collection of values associated with an

instance of one (or in the case of a ternary or higher-order association, more than one) type. This
set of classifiers is called the context for the property. In the case of an attribute the context is
the owning classifier. In the case of an association end the context is the set of types at the other
end or ends of the association.

Syntax for properties is provided below. Note, that some specializations of property may also
have additional notational forms.

property ::= [ visibility ]  ['/']   prop-name   [ ':' prop-type ]   [ '[' multiplicity ']' ]   [ '=' default ]  
[ prop-modifiers ]

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

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

Forward slash '/' means that the property is derived. UML 2.3 provides weird definition for
derived property - property is derived when "its value or values can be computed from other
information".

The prop-type is the type of the property represented by the name of classifier.

Property could have multiplicity. The multiplicity bounds constrain the size of the collection of
property values. By default the maximum bound is 1.

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

Property may have optional modifiers, and if present those should follow the rules:

prop-modifiers ::= '{' prop-modifier   [   ','   prop-modifier ] *   '}'

prop-modifier ::=   'readOnly'   |   'union'   |   'ordered'   |   'unique'   |   'nonunique'   |   prop-
constraint   |
                'redefines'   prop-name   |   'subsets'   prop-name

Classifier Attribute
A property owned by a classifier represents an attribute of the classifier. Context of the
attribute is the owning classifier.

UML specification very vaguely describes ownership of attribute as some relationship when the
value or values related to the instance of the classifier are being held in the slots of the instance.

Slot is UML element which specifies that an instance has a value or values for a specific
structural feature. UML specification also says that a slot gives the value or values of a structural
feature of the instance. An instance can have one slot per structural feature of its classifiers,
including inherited features.

In programming we would call this kind of mapping as memory slots or storage. In plain
English, attributes of classifier are stored in slots of the classifier.

Classifier attribute may also represent an association end when this association end is owned by
the classifier.

Ownership of association ends by an associated classifier may be indicated graphically by a

small filled circle (aka dot). The dot is drawn at the point where line meets the classifier. It
could be interpreted as showing that the model includes a property of the type represented by the
classifier touched by the dot. This property is owned by the classifier at the other end.

Association end query is owned by classifier QueryBuilder and association end qbuilder is
owned by association Builds itself

Association Attribute

When a property is an association end, the value or values of the property are related to the
instance or instances at the other end(s) of the association.

A property owned by an association represents an attribute of the association. In the case of an

association end context is the set of types at the other end or ends of the association.

Association end could be owned either by

 end classifier, or
 association itself.

Association ends of associations with more than two ends must be owned by the association.
UML standard does not mandate the use of explicit end-ownership notation, but defines a
default. When dot notation is not used in binary association, association ends are assumed to be
owned by association.

Qualifier

A property may have other properties (attributes) that serve as qualifiers. A qualifier is a
property which defines a partition of the set of associated instances with respect to an instance at
the qualified end. (And probably more appropriate name for qualifier would be selector or key.)

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 qualified classifier also called the
source. This qualifier rectangle is part of the association, not part of the classifier. UML does not
allow qualifier to be suppressed.

One or several attributes of the qualifier are drawn within the qualifier box, one to a line.
Qualifier attributes have the same notation as classifier attributes, except that initial values are
not used in this case.

UML allows having a qualifier on each end of a single association.

Multiplicity of Target

Given a qualified object and a qualifier instance, the number of objects at the target end of the
association is constrained by the declared multiplicity of the target.

Target multiplicity should allow 0 ("no results") if the domain of the qualifier is large or infinite,
e.g. number, long string, date. It can be exactly 1 for qualifiers of enumerated or restricted
domain.

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

Given a company and a social security number (SSN) at most one employee could be found

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.
Given a library and author name none to many books could be found

Target multiplicity should allow 0 if the domain of the qualifier is large or infinite, e.g. number,
long string, date.

Multiplicity of Qualifier

UML 2.3 specification (p.130) is mumbo jumbo 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.

Given chessboard and specific rank and file we'll locate exactly 1 square.
UML specification provides no lucid explanation of what multiplicity 1 means for qualifier.

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 both UML 2.2 and 2.3 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.3
specification:
     operation ::= [ visibility ]   signature   [ oper-properties ]

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

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

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.

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.

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:

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

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 notion for abstract operation in UML 2.3.

Constraint
A constraint is a packageable element representing condition, restriction or assertion related
to some of the semantics of an element (that owns the constraint).

Some kinds of constraints are predefined in UML, and constraint element allows to introduce
user defined conditions and restrictions.

Constraint is a condition (a Boolean expression) which must evaluate to a Boolean value - true
or false. Constraint must be satisfied (i.e. evaluated to true) by a correct design of the system.

In general there are many possible kinds of owners for a Constraint. Owning element must have
access to the constrained elements to verify constraint. The owner of the constraint will
determine when the constraint is evaluated. For example, Operation can have pre-condition
and/or a post-condition constraints.

Constraints are commonly unnamed (anonymous), though constraint may have an optional name.

OCL is a constraint language predefined in UML but UML specification does not restrict
languages which could be used to describe constraints. If some tool is used to draw UML
diagrams, it could be any constraint language supported by that tool.

Some examples of constraint languages are:

 OCL
 Java
 some machine readable language
 natural language

A constraint is shown as a text string in curly braces according to the following BNF:
       <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.
Bank account attribute constraints - non empty owner and positive balance

For a constraint that applies to a single element (such as a Class or an association path), the
constraint string may be placed near the symbol for the element, preferably near the name, if any.
A UML tool must make it possible to determine the constrained element.

For a Constraint that applies to two elements (such as two classes or two associations), the
constraint may be shown as a dashed line between the elements labeled by the constraint string
in curly braces.

Account owner is either Person or Corporation, {xor} is predefined UML constraint

If the constraint is shown as a dashed line between two elements, then an arrowhead may be
placed on one end. The direction of the arrow is relevant information within the constraint. The
element at the tail of the arrow is mapped to the first position and the element at the head of the
arrow is mapped to the second position in the constrainedElements collection.

For three or more paths of the same kind (such as generalization paths or association paths), the
constraint may be attached to a dashed line crossing all of the paths.

The constraint string may be placed in a note symbol and attached to each of the symbols for the
constrained elements by a dashed line.
Bank account constraints - non empty owner and positive balance

Multiplicity
Multiplicity is a definition of an inclusive interval of non-negative integers to specify the
allowable number of instances of described element. Multiplicity begins with some lower bound
and ends with a (possibly infinite) upper bound. Multiplicity also includes specifications of
whether the values in an instantiation of the element must be unique and/or ordered.

Multiplicity could be described with the following non-normative syntax rules:

     multiplicity ::= multiplicity-range  [ '{' multiplicity-options '}' ]

If the multiplicity is associated with an element whose notation is a text string (such as a class
attribute), the multiplicity string is placed within square brackets as part of that text string. If the
multiplicity is associated with an element that appears as a symbol (such as use case or class), the
multiplicity string is displayed without square brackets.

Multiplicity specifies allowable number of instances of described element:

     multiplicity-range ::= [ lower-bound '..' ] upper-bound
     lower-bound ::= non-negative-integer
     upper-bound ::= non-negative-integer | '*'

Lower and upper bounds could be integer constant or constant expression evaluated to non
negative integer. Upper bound should be greater than or equal to the lower bound.

Multiplicity of Players for Soccer Team class

Some typical examples of multiplicity bounds:

0 Collection must be empty

1 Exactly one instance
5 Exactly 5 instances
* Zero or more instances
0..1 No instances or one instance
1..1 Exactly one instance
0..* Zero or more instances
1..* At least one instance
m..n At least m but no more than n instances

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.

Customer has none to many purchases. Purchases are ordered and each one is unique (by default)

Data Source could have a Logger and has ordered pool of min to max Connections. Each
Connection is unique (by default)

Visibility
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

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

A public element is visible to all elements that can access the contents of the namespace that
owns it. Public visibility is represented by '+' literal.

A package element is owned by a namespace that is not a package, and is visible to elements
that are in the same package as its owning namespace. Only named elements that are not owned
by packages can be marked as having package visibility. Any element marked as having package
visibility is visible to all elements within the nearest enclosing package (given that other owning
elements have proper visibility). Outside the nearest enclosing package, an element marked as
having package visibility is not visible. Package visibility is represented by '~' literal.

A protected element is visible to elements that have a generalization relationship to the

namespace that owns it. Protected visibility is represented by '#' literal.

A private element is only visible inside the namespace that owns it. Private visibility is
represented by '-' literal.

Operation executeQuery is public, isPoolable - protected, getQueryTimeout - with package

visibility, and clearWarnings is private.

If some named element appears to have multiple visibilities, for example, by being imported
multiple times, public visibility overrides private visibility. If an element is imported twice into
the same namespace, once using a public import and another time using a private import,
resulting visibility is public.

Association
Association is semantic relationship between classifiers used to show that some instances of
classifiers could be either linked to each other or combined logically or physically into some
aggregation. Association has at least two ends represented by properties (end properties).

Link is an instance of an association. It is a tuple with one value for each end of the association,
where each value is an instance of the type of the end.

An association end is the connection between the line depicting an association and the icon
depicting the connected classifier.
Associations are specified using several presumably orthogonal - according to UML 2.2 specs -
concepts, i.e. concepts independently defined and used, each with their own notation:

 arity
 aggregation
 end ownership
 navigability

Association relationship overview diagram

Arity

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

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.

A small solid triangle could be placed next to or in place of the name of binary association
(drawn as a solid line) to show the order of the ends of the association. The arrow points along
the line in the direction of the last end in the order of the association ends. This notation also
indicates that the association is to be read from the first end to the last end.
Order of the ends and reading: Car - was designed in - Year

UML® 2.2 specification clarifies that this arrow is used for documentation purposes only and
has no general semantic interpretation. This is kind of odd clarification as UML diagrams are
in fact used mostly for documentation purposes but even more important, this arrow according to
the UML spec defines the order of association ends - which actually does belong to semantics.

Any association may be drawn as a diamond (larger than a terminator on a line) with a solid line
for each association end connecting the diamond to the classifier that is the end’s type. N-ary
association with more than two ends can only be drawn this way.

Ternary association Design relates three classifiers

Shared and Composite Aggregation

Aggregation is a binary association representing some whole/part relationship. Aggregation

type could be either:

 shared aggregation (aka aggregation), or

 composite aggregation (aka composition)

Aggregation

Aggregation (Shared aggregation) is a weak form of aggregation when part instance is

independent of the composite:

 the same (shared) part could be included in several composites, and

 if composite is deleted, shared parts may still exist.

Shared aggregation is shown as binary association decorated with a hollow diamond as a

terminal adornment at the aggregate end of the association line. The diamond should be
noticeably smaller than the diamond notation for N-ary associations.
Search Service has a Query Builder using shared aggregation

Composition

Composition (Composite aggregation) is a strong form of aggregation that requires that:

 a part instance to be included in at most one composite at a time, and

 if a composite is deleted, all of its composite parts are normally deleted with it.

Note, that a part can (where allowed) be removed from a composite before the composite is
deleted, and thus not be deleted as part of the composite.

Composite aggregation is depicted as binary associations decorated with a filled in black

diamond at the aggregate end.

Table has a Row using composite aggregation (aka composition)

Note, in UML 2.2 the order and way in which part instances are created in a composite is not
defined.

Association End Ownership

An association end is the connection between the line depicting an association and the icon
(often a box) depicting the connected classifier. A name string may be placed near the end of the
line to show the name of the association end. The name is optional and suppressible.

Association end could be owned either by

 end classifier, or
 association itself

Association ends of associations with more than two ends must be owned by the association.

Ownership of association ends by an associated classifier may be indicated graphically by a

small filled circle (aka dot). The dot is drawn at the point where line meets the classifier. It
could be interpreted as showing that the model includes a property of the type represented by the
classifier touched by the dot. This property is owned by the classifier at the other end.
Association end query is owned by classifier QueryBuilder and association end qbuilder is
owned by association Builds itself

The "ownership" dot may be used in combination with the other graphic line-path notations for
properties of associations and association ends. These include aggregation type and navigability.

UML 2.2 standard does not mandate the use of explicit end-ownership notation, but defines a
notation which shall apply in models where such use is elected. The dot notation must be applied
at the level of complete associations or higher, so that the absence of the dot signifies
ownership by the association. In other words, in binary associations the dot will be omitted
only for the ends which are not owned by a classifier.

Attribute notation can be used for an association end owned by a class, because an association
end owned by a class is also an attribute. This notation may be used in conjunction with the line
arrow notation to make it perfectly clear that the attribute is also an association end.

Association end qb is an attribute of SearchService class and is owned by the class

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.

Navigability

UML® 2.2 specification [UML 2.2 - Superstructure] provides a weird definition of navigability:

An end property of association that is:

 owned by an end class, or that is

 a navigable owned end of the association [itself]
indicates that the association is navigable from the opposite ends; otherwise, the association is
not navigable from the opposite ends.

This definition is odd because it makes navigability strongly dependent on ownership, while
these are assumed to be orthogonal concepts; some examples in UML 2.2 specs show end
properties owned by a class as not navigable, which contradicts to the definition above; and
navigability is defined using "navigable owned end of the association".

Let's stick with another semantical explanation from UML 2.2: Navigability of some association
end means that instances of classifiers participating in links at that end at runtime can be
accessed efficiently from instances participating in the links at the other ends of the association.
The precise mechanism by which such access is achieved is implementation specific.

If an end is not navigable, access from the other ends is either not possible at all or is still
possible but not guaranteed to be efficient.

Deprecated navigability convention:

 non-navigable ends were assumed to be owned by the association

 navigable ends were assumed to be owned by the classifier at the opposite end.

Notation:

 navigable end is indicated by an open arrowhead on the end of an association

 not navigable end is indicated with a small x on the end of an association
 no adornment on the end of an association means unspecified navigability

Both ends of association have unspecified navigability.

A2 has unspecified navigability while B2 is navigable from A2.

A3 is not navigable from B3 while B3 has unspecified navigability.

A4 is not navigable from B4 while B4 is navigable from A4.

A5 is navigable from B5 and B5 is navigable from A5.

A6 is not navigable from B6 and B6 is not navigable from A6.

A visibility symbol can be added as an adornment on a navigable end to show the end’s visibility
as an attribute of the featuring classifier.

Generalization
A generalization is a binary taxonomic (i.e. related to classification) directed relationship
between a more general classifier (superclass) and a more specific classifier (subclass).

Each instance of the specific classifier is also an indirect instance of the general classifier.
Because of this, generalization relationship is also informally called "Is A" relationship.

Generalization is owned by the specific classifier.

A generalization is shown as a line with a hollow triangle as an arrowhead between the symbols
representing the involved classifiers. The arrowhead points to the symbol representing the
general classifier. This notation is referred to as the "separate target style."

Checking, Savings, and Credit Accounts are generalized by Account

Generalization relationships that reference the same general classifier can also be connected
together in the "shared target style."

Checking, Savings, and Credit Accounts are generalized by Account

Inheritance

UML 2.3 standard provides no definition for inheritance. In OOAD inheritance is usually
defined as a mechanism by which more specific classes (called subclasses or derived classes)
incorporate structure and behavior of more general classes (called superclasses or base classes).

UML standard says that with generalization specializing classifier inherits features of the more
general classifier.

Also, any constraint applying to instances of the general classifier also applies to instances of the
specific classifier.

Multiple Inheritance

Multiple inheritance is implicitly allowed by UML standard, while the standard provides no
definition of what it is.

Classifier in UML can have zero, one or many generalization relationships to more general
classifiers. In OOAD multiple inheritance refers to the ability of a class to inherit behaviors and
features from more than one superclass.
Multiple inheritance for Consultant Manager and Permanent Manager - both inherit from two
classes

The origin of multiple inheritance could be in orthogonal taxonomies combined together. For
example, the diagram above combines two different classifications of employees - one is based
on whether employee is permanent or temporary, and another one is based on the position
employee holds.

Though UML standard implicitly allows multiple inheritance, it provides no explicit resolutions
or recommendations for well known issues and ambiguities, such as the diamond problem.
Diamond problem example - Button inherits 2 implementations of equals()

In the multiple inheritance diamond problem example above Button class inherits two different
implementations of equals() while it has no own implementation of the operation. When
button.equals() is called, it is unknown which implementation - from Rectangle or from
Clickable - will be used.

UML profiles allow to specialize the semantics of generalization. For example, in the Java
language profile, generalization of classes should be restricted to single inheritance.

Dependency
Dependency relationship is used to show that some element or a set of elements depends on other
model element(s), and on class diagrams is usually represented by usage dependency or
abstraction.

A dependency is rendered as a dashed arrow between elements. The 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.

Data Access depends on Connection Pool

It is possible to have a set of elements for the client or supplier. In this case, one or more arrows
with their tails on the clients are connected to the tails of one or more arrows with their heads on
the suppliers. A small dot can be placed on the junction if desired. A note on the dependency
should be attached at the junction point.

Usage

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

The usage dependency does not specify how the client uses the supplier other than the fact that
the supplier is used by the definition or implementation of the client. 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.

Search Controller uses Search Engine

Create

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

Data Source creates Connection

Create could also specify that the designated feature creates an instance of the classifier to which
the feature is attached. This dependency may be promoted to the classifier containing the feature.

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.

Account constructor creates new instance of Account

Instantiate is another usage dependency among classifiers indicating that operations on the
client create instances of the supplier. It is denoted with the standard stereotype «instantiate».

It is not very clear why UML 2.3 standard has both «create» and «instantiate».

Call

Call is a usage dependency that specifies that the source operation invokes the target operation.
This dependency may connect a source operation to any target operation that is within the scope
including, but not limited to, operations of the enclosing classifier and operations of other visible
classifiers.

Call is denoted with the standard stereotype «call» whose source is an operation and whose
target is also an operation.

This relationship may also be applied to the class containing an operation, with the meaning that
there exists an operation in the class to which the dependency applies.

Send
Send is a usage dependency whose source is an operation and whose target is a signal,
specifying that the source sends the target signal.

Send is denoted with the standard stereotype «send».

Required Interface

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.

Interface SiteSearch is used (required) by SearchController.

If interface is represented using the rectangle notation, interface usage dependency is denoted
with dependency arrow. The classifier at the tail of the arrow uses (requires) the interface at the
head of the arrow.

Interface SiteSearch is used (required) by SearchController.

Abstraction

Abstraction is a dependency relationship which relates two elements or sets of elements (called
client and supplier) representing the same concept but at different levels of abstraction or from
different viewpoints.

For example, an analysis level class (supplier) might be split into one or several design level
classes (clients). It is also possible to have more than one supplier element.

Depending on the specific stereotype of abstraction, mapping between supplier and client may
be formal or informal, and it may be unidirectional or bidirectional.

An abstraction relationship is shown as a dependency with an «abstraction» keyword attached

to it or the specific predefined stereotype name.
Realization

Realization is a specialized abstraction relationship between two sets of model elements, one
representing a specification (the supplier) and the other represents an implementation of the
latter (the client).

The meaning of "implementation" is not strictly defined in UML Specification. It implies a more
refined or elaborate form in respect to a certain modeling context.

Realization can be used to model stepwise refinement, optimizations, transformations, templates,

model synthesis, framework composition, etc.

A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that
corresponds to the realized element (the supplier).

Specializations of realization relationship are interface realization and substitution.

Interface Realization

Interface realization is a specialized realization relationship between a Classifier and an

Interface. This relationship signifies that the realizing classifier conforms to the contract
specified by the interface.

A classifier that implements an interface specifies instances that are conforming to the interface
and to any of its ancestors. A classifier may implement one or several interfaces.

The set of interfaces implemented by the classifier are its provided interfaces. Provided
interfaces describe the set of services the classifier offers to its clients.

A classifier implementing an interface supports the set of features owned by the interface. In
addition to supporting the features, a classifier must comply with the constraints owned by the
interface.

An interface realization relationship between a classifier and an interface implies that the
classifier supports the set of features owned by the interface, and any of its parent interfaces.

For behavioral features, the implementing classifier will have an operation or reception for every
operation or reception, respectively, defined by the interface.

For properties, the realizing classifier will provide functionality that maintains the state
represented by the property. While such may be done by direct mapping to a property of the
realizing classifier, it may also be supported by the state machine of the classifier or by a pair of
operations that support the retrieval of the state information and an operation that changes the
state information.
The interface realization dependency from a classifier to an interface is shown by representing
the interface by 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 SiteSearch is realized (implemented) by SearchService.

If interface is represented using the rectangle notation, interface realization dependency is

denoted with interface realization arrow. The classifier at the tail of the arrow implements the
interface at the head of the arrow.

Interface SiteSearch is realized (implemented) by SearchService.

Overview
The class diagram is the main building block in object oriented modelling. It is used both for
general conceptual modelling of the systematics of the application, and for detailed modelling
translating the models into programming code. The classes in a class diagram represent both the
main objects and or interactions in the application and the objects to be programmed. In the class
diagram these classes are represented with boxes which contain three parts: [1]

A class with three sections.

 The upper part holds the name of the class

 The middle part contains the attributes of the class
 The bottom part gives the methods or operations the class can take or undertake
In the system design of a system, a number of classes are identified and grouped together in a
class diagram which helps to determine the static relations between those objects. With detailed
modeling, the classes of the conceptual design are often split into a number of subclasses.

In order to further describe the behavior of systems, these class diagrams can be complemented
by state diagram or UML state machine. Also instead of class diagrams Object role modeling can
be used if you just want to model the classes and their relationships.[1]

[edit] Members
UML provides mechanisms to represent class members, such as attributes and methods, and
additional information about them.

[edit] Visibility

To specify the visibility of a class member (i.e., any attribute or method) there are the following
notations that must be placed before the member's name:

+ Public
# Protected
- Private
~ Package

[edit] Scope

The UML specifies two types of scope for members: instance and classifier.[2] In the case of
instance members, the scope is a specific instance. For attributes, it means that its value can vary
between instances. For methods, it means that its invocation affects the instance state, in other
words, affects the instance attributes. Otherwise, in the classifier member, the scope is the class.
For attributes, it means that its value is equal for all instances. For methods, it means that its
invocation does not affect the instance state. Classifier members are commonly recognized as
"static" in many programming languages. To indicate that a member has the classifier scope, its
name must be underlined.Otherwise, as default, the instance scope is considered.

[edit] Relationships
A relationship is a general term covering the specific types of logical connections found on class
and object diagrams. UML shows the following relationships:

[edit] Instance Level Relationships

[edit] External links

A Link is the basic relationship among objects. It is represented as a line connecting two or more
object boxes. It can be shown on an object diagram or class diagram. A link is an instance of an
association. In other words, it creates a relationship between two classes.
[edit] Association

Class diagram example of association between two classes

An Association represents a family of links. Binary associations (with two ends) are normally
represented as a line, with each end connected to a class box. Higher order associations can be
drawn with more than two ends. In such cases, the ends are connected to a central diamond.

An association can be named, and the ends of an association can be adorned with role names,
ownership indicators, multiplicity, visibility, and other properties. There are five different types
of association. Bi-directional and uni-directional associations are the most common ones. For
instance, a flight class is associated with a plane class bi-directionally. Associations can only be
shown on class diagrams. Association represents the static relationship shared among the objects
of two classes. Example: "department offers courses", is an association relation.

[edit] Aggregation

Class diagram showing Aggregation between two classes

Aggregation is a variant of the "has a" or association relationship; aggregation is more specific
than association. It is an association that represents a part-whole or part-of relationship. As a type
of association, an aggregation can be named and have the same adornments that an association
can. However, an aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other classes, but where the
contained classes do not have a strong life cycle dependency on the container—essentially, if the
container is destroyed, its contents are not.

In UML, it is graphically represented as a hollow diamond shape on the containing class end of
the tree of lines that connect contained class(es) to the containing class.

[edit] Composition
Class diagram showing Composition between two classes at top and Aggregation between two
classes at bottom

Composition is a stronger variant of the "owns a" or association relationship; composition is

more specific than aggregation.

Composition usually has a strong life cycle dependency between instances of the container class
and instances of the contained class(es): If the container is destroyed, normally every instance
that it contains is destroyed as well. Note that a part can (where allowed) be removed from a
composite before the composite is deleted, and thus not be deleted as part of the composite.

The UML graphical representation of a composition relationship is a filled diamond shape on the
containing class end of the tree of lines that connect contained class(es) to the containing class.

[edit] Differences between Composition and Aggregation

When attempting to represent real-world whole-part relationships, e.g., an engine is part of a car,
the composition relationship is most appropriate. However, when representing a software or
database relationship, e.g., car model engine ENG01 is part of a car model CM01, an aggregation
relationship is best, as the engine, ENG01 may be also part of a different car model. Thus the
aggregation relationship is often called "catalog" containment to distinguish it from
composition's "physical" containment.

The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must
belong to only one whole; the part may have any multiplicity. For example, consider University
and Department classes. A department belongs to only one university, so University has
multiplicity 1 in the relationship. A university can (and will likely) have multiple departments, so
Department has multiplicity 1..*.

[edit] Class Level Relationships

[edit] Generalization

Class diagram showing generalization between one superclass and two subclasses

The Generalization relationship indicates that one of the two related classes (the subtype) is
considered to be a specialized form of the other (the super type) and supertype is considered as
'Generalization' of subtype. In practice, this means that any instance of the subtype is also an
instance of the supertype. An exemplary tree of generalizations of this form is found in binomial
nomenclature: human beings are a subtype of simian, which are a subtype of mammal, and so on.
The relationship is most easily understood by the phrase 'an A is a B' (a human is a mammal, a
mammal is an animal).

The UML graphical representation of a Generalization is a hollow triangle shape on the

supertype end of the line (or tree of lines) that connects it to one or more subtypes.

The generalization relationship is also known as the inheritance or "is a" relationship.

The supertype in the generalization relationship is also known as the "parent", superclass, base
class, or base type.

The subtype in the specialization relationship is also known as the "child", subclass, derived
class, derived type, inheriting class, or inheriting type.

Note that this relationship bears no resemblance to the biological parent/child relationship: the
use of these terms is extremely common, but can be misleading.

 Generalization-Specialization relationship

A is a type of B
E. g. "an oak is a type of tree", "an automobile is a type of vehicle"

Generalization can only be shown on class diagrams and on Use case diagrams.

[edit] Realization

In UML modeling, a realization relationship is a relationship between two model elements, in

which one model element (the client) realizes (implements or executes) the behavior that the
other model element (the supplier) specifies. A realization is indicated by a dashed line with an
unfilled arrowhead towards the supplier.

Realizations can only be shown on class or component diagrams.

A realization is a relationship between classes, interfaces, components, and packages that

connects a client element with a supplier element. A realization relationship between classes and
interfaces and between components and interfaces shows that the class realizes the operations
offered by the interface.

[edit] General Relationship

Class diagram showing dependency between "Car" class and "Wheel" class

[edit] Dependency

Dependency is a weaker form of relationship which indicates that one class depends on another
because it uses it at some point of time. Dependency exists if a class is a parameter variable or
local variable of a method of another class.

[edit] Multiplicity

The association relationship indicates that (at least) one of the two related classes makes
reference to the other. In contrast with the generalization relationship, this is most easily
understood through the phrase 'A has a B' (a mother cat has kittens, kittens have a mother cat).

The UML representation of an association is a line with an optional arrowhead indicating the
role of the object(s) in the relationship, and an optional notation at each end indicating the
multiplicity of instances of that entity (the number of objects that participate in the association).

Common multiplicities are:...

0..1 No instances, or one instance (optional, may)

1 Exactly one instance
0..* or * Zero or more instances
1..* One or more instances (at least one)

[edit] Analysis Stereotypes

In the early stages of a project's technical analysis, class diagrams can be used to produce early
conceptual models of the system. Classes at this stage often take the form of boundaries, controls
and entities and rarely survive into the design without heavy changes.
[edit] Boundaries

Boundary classes handle the communication between actors and the system's internal
components. They might be user interfaces, system interfaces or device interfaces (for example).
They are identified by each actor–use-case pair on the system's use-case diagram, with one and
only one boundary class existing for each pair.

They are drawn as circles with a short line to the left attached to a vertical line the same height as
the circle (as though it is attached to the side of the use-case system boundary). Alternatively,
they can be drawn as normal classes with the «boundary» stereotype notation above the class
name.

[edit] Entities

Entity classes model the information handled by the system, and sometimes the behaviour
associated with the information. They should not be identified as database tables or other data-
stores.

They are drawn as circles with a short line attached to the bottom of the circle. Alternatively,
they can be drawn as normal classes with the «entity» stereotype notation above the class name

[edit] Controls

Control classes handle the flow of control for a use-case and can therefore be seen as co-
ordinating representation classes. These do not do everything in the use case, but co-ordinate
with other classes that can do the work for them.