Class diagram

In software engineering, a class diagram in

the Unified Modeling Language (UML) is a
type of static structure diagram that
describes the structure of a system by
showing the system's classes, their
attributes, operations (or methods), and
the relationships among objects.
 Hierarchy of UML 2.5 Diagrams, shown as a class diagram. The
individual classes are represented just with one compartment, but they
often contain up to three compartments.

The class diagram is the main building

block of object-oriented modeling. It is
used for general conceptual modeling of
the structure of the application, and for
detailed modeling, translating the models
into programming code. Class diagrams
can also be used for data modeling.[1] The
classes in a class diagram represent both
the main elements, interactions in the
application, and the classes to be
programmed.

In the diagram, classes are represented

with boxes that contain three
compartments:

The top compartment contains the

name of the class. It is printed in bold
and centered, and the first letter is
capitalized.
The middle compartment contains the
attributes of the class. They are left-
aligned and the first letter is lowercase.
The bottom compartment contains the
operations the class can execute. They
 are also left-aligned and the first letter is
lowercase.

A class with three compartments.

In the design of a system, a number of

classes are identified and grouped
together in a class diagram that helps to
determine the static relations between
them. In detailed modeling, the classes of
the conceptual design are often split into
subclasses.[2]

In order to further describe the behavior of

systems, these class diagrams can be
complemented by a state diagram or UML
state machine.[3]

Members
UML provides mechanisms to represent
class members, such as attributes and
methods, and additional information about
them like constructors.

Visibility

To specify the visibility of a class member

(i.e. any attribute or method), these
notations must be placed before the
members' name:[4]
 + Public
- Private
# Protected
~ Package

A derived property is a property whose

value (or values) is produced or computed
from other information, for example, by
using values of other properties.

A derived property is shown with its name

preceded by a forward slash '/'. [5]
Scope

The UML specifies two types of scope for

members: instance and class, and the
latter is represented by underlined
names.[6]

Instance members are scoped to a

specific instance.
Attribute values may vary between
instances
Method invocation may affect the
instance's state (i.e. change
instance's attributes)
Class members are commonly
recognized as "static" in many
 programming languages. The scope end
is the class itself.
Attribute values are equal for all
instances
Method invocation does not affect
the classifier's state

To indicate a classifier scope for a

member, its name must be underlined.
Otherwise, instance scope is assumed by
default.
Relationships

UML relations notation

A relationship is a general term covering

the specific types of logical connections
found on class and object diagrams. UML
defines the following relationships:
Instance-level relationships

Dependency

A dependency is a type of association

where there is a semantic connection
between dependent and independent
model elements.[7] It exists between two
elements if changes to the definition of
one element (the server or target) may
cause changes to the other (the client or
source). This association is uni-directional.
A dependency is displayed as a dashed
line with an open arrow that points from
the client to the supplier.
Association

Class diagram example of association between two

classes

An association represents a family of

structural links. A binary association is
represented as a solid line between two
classes. A reflexive association is a binary
association between the class and itself.
An association between more than two
classes is represented as a diamond
connected with a solid line to each of the
associated classes. An association
between three classes is a ternary
association. An association between more
classes is called an n-ary association.
An association can be named, and the
ends of an association can be adorned
with role names, aggregation indicators,
multiplicity, visibility, navigability and other
properties. The dot notation for example
allows to represent with a little dot on the
side of one class that the association end
is owned by the other side.[8]

There are three types of association:

simple association, shared aggregation,
composite aggregation (composition). An
association can be navigable in one or
more directions. The navigability does not
have to be explicitly specified. An open-
headed arrow on the side of a class
documents that the class can be reached
efficiently at run-time from the opposite
side. A unidirectional navigation is shown
with a little cross on the association line
on the side of the class that cannot be
reached. For instance, a flight class is
associated with a plane class bi-
directionally.

Aggregation

Class diagram showing Aggregation between two

classes. Here, a Professor 'has a' class to teach.

Aggregation is a variant of the "has a"

association relationship; aggregation is
more specific than association. It is an
association that represents a part-whole
or part-of relationship. As shown in the
image, a Professor 'has a' class to teach.
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; it must be a binary
association. Furthermore, there is hardly a
difference between aggregations and
associations during implementation, and
the diagram may skip aggregation
relations altogether.[9]

Aggregation can occur when a class is a

collection or container of other classes,
but the contained classes do not have a
strong lifecycle dependency on the
container. The contents of the container
still exist when the container is destroyed.

In UML, it is graphically represented as a

hollow diamond shape on the containing
class with a single line that connects it to
the contained class. The aggregate is
semantically an extended object that is
treated as a unit in many operations,
although physically it is made of several
lesser objects.
Composition

Two class diagrams. The diagram on

top shows Composition between two
classes: A Car has exactly one
Carburetor, and a Carburetor is a part
of one Car. Carburetors cannot exist
as separate parts, detached from a
specific car. The diagram on bottom
shows Aggregation between two
classes: A Pond has zero or more
Ducks, and a Duck has at most one
Pond (at a time). Duck can exist
separately from a Pond, e.g. it can live
near a lake. When we destroy a Pond
we usually do not kill all the Ducks.

The composite aggregation (colloquially

called composition) relationship is a
stronger form of aggregation where the
aggregate controls the lifecycle of the
elements it aggregates. The graphical
representation is a filled diamond shape on
the containing class end of the line that
connect contained class(es) to the
containing class.

Differences between Composition and

Aggregation

Composition relationship
1. When attempting to represent real-
world whole-part relationships, e.g. an
engine is a part of a car.
2. When the container is destroyed, the
contents are also destroyed, e.g. a
university and its departments.

Aggregation relationship
1. When representing a software or
database relationship, e.g. car model
 engine ENG01 is part of a car model
CM01, as the engine, ENG01, maybe
also part of a different car model.[10]
2. When the container is destroyed, the
contents are usually not destroyed, e.g.
a professor has students; when the
professor leaves the university the
students do not leave along with the
professor.

Thus the aggregation relationship is often

"catalog" containment to distinguish it
from composition's "physical"
containment. UML 2 does not specify any
semantic for the aggregation compared to
the simple association.
Class-level relationships

Generalization/Inheritance

Class diagram showing generalization between the

superclass Person and the two subclasses S tudent
and Professor

It indicates that one of the two related

classes (the subclass) is considered to be
a specialized form of the other (the super
type) and the superclass is considered a
Generalization of the subclass. In practice,
this means that any instance of the
subtype is also an instance of the
superclass. An exemplary tree of
generalizations of this form is found in
biological classification: humans are a
subclass of simian, which is a subclass 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 superclass end of the line (or tree
of lines) that connects it to one or more
subtypes.

symbolic of realization
(subclass) _______▻
 (superclass)

The generalization relationship is also

known as the inheritance or "is a"
relationship.

The superclass (base class) 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.

A is a type of B
For example, "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.

Realization/Implementation

In UML modelling, 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.

The UML graphical representation of a

Realization is a hollow triangle shape on
the interface end of the dashed line (or tree
of lines) that connects it to one or more
implementers. A plain arrow head is used
on the interface end of the dashed line that
connects it to its users. In component
diagrams, the ball-and-socket graphic
convention is used (implementors expose
a ball or lollipop, whereas users show a
socket). 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/components
and interfaces shows that the
class/component realizes the operations
offered by the interface.

symbolic of realization
(implementer) -------▻
(interface)
General relationship

Class diagram showing dependency between "Car"

class and "Wheel" class (An even clearer example
would be "Car depends on Wheel", because Car
already aggregates (and not just uses ) Wheel)

Dependency

Dependency can be a weaker form of bond

that indicates that one class depends on
another because it uses it at some point in
time. One class depends on another if the
independent class is a parameter variable
or local variable of a method of the
dependent class. Sometimes the
relationship between two classes is very
weak. They are not implemented with
member variables at all. Rather they might
be implemented as member function
arguments.

Multiplicity

This association relationship indicates that

(at least) one of the two related classes
make reference to the other. This
relationship is usually described as "A has
a B" (a mother cat has kittens, kittens have
a mother cat).

The UML representation of an association

is a line connecting the two associated
classes. At each end of the line there is
optional notation. For example, we can
indicate, using an arrowhead that the
pointy end is visible from the arrow tail. We
can indicate ownership by the placement
of a ball, the role the elements of that end
play by supplying a name for the role, and
the multiplicity of instances of that entity
(the range of number of objects that
participate in the association from the
perspective of the other end).

0 No inst ances (rare)

0..1 No inst ances, or one inst ance

1 Exact ly one inst ance

1..1 Exact ly one inst ance

0..* Zero or more inst ances

* Zero or more inst ances

1..* One or more inst ances

Analysis stereotypes

Entities

Entity classes model long-lived

information handled by the system, and
sometimes the behavior 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.

See also
Executable UML
List of UML tools
Object-oriented modeling
Dependency (UML)
Related diagrams

Domain model
Entity–relationship model
 Object diagram

References
1. Sparks, Geoffrey. "Database Modeling in
UML" (http://www.methodsandtools.com/a
rchive/archive.php?id=9) . Retrieved
8 September 2011.

2. Flatt, Amelie; Langner, Arne; Leps, Olof

(2022), "Phase I: Mapping Legal Concepts
to Technical Objects" (https://link.springer.c
om/10.1007/978-3-031-14132-4_3) ,
Model-Driven Development of Akoma
Ntoso Application Profiles, Cham: Springer
International Publishing, pp. 13–17,
doi:10.1007/978-3-031-14132-4_3 (https://
doi.org/10.1007%2F978-3-031-14132-4_
 3) , ISBN 978-3-031-14131-7, retrieved
2023-01-07

3. Scott W. Ambler (2009) UML 2 Class

Diagrams (http://www.agilemodeling.com/
artifacts/classDiagram.htm) . Webdoc
2003-2009. Accessed Dec 2, 2009

4. UML Reference Card, Version 2.1.2 (http://

www.holub.com/goodies/uml/) , Holub
Associates, August 2007, retrieved
12 March 2011

5. "UML derived property is property which

value is produced or computed from other
information, for example, by using other
properties" (https://www.uml-diagrams.or
g/derived-property.html) . www.uml-
diagrams.org. Retrieved 2019-01-24.
6. OMG Unified Modeling Language (OMG
UML) Superstructure (http://www.omg.org/
spec/UML/2.3/Superstructure/PDF/) ,
Version 2.3: May 2010. Retrieved 23
September 2010.

7. Fowler (2003) UML Distilled: A Brief Guide

to the Standard Object Modeling Language

8. Selic, Bran (2013-04-18). "Getting it right on

the dot" (https://www.omg.org/ocup-2/doc
uments/getting_it_right_on_the_dot.pdf)
(PDF). www.omg.org. Object Management
Group. Retrieved 2023-11-26.

9. "UML Tutorial part 1: class diagrams" (http

s://web.archive.org/web/2007010314143
8/http://www.objectmentor.com/resource
s/articles/umlClassDiagrams.pdf) (PDF).
Archived from the original (http://www.obje
 ctmentor.com/resources/articles/umlClass
Diagrams.pdf) (PDF) on 2007-01-03.
Retrieved 2015-07-18.

10. Goodwin, David. "Modelling and Simulation,

p. 26" (http://www2.warwick.ac.uk/fac/sci/
physics/research/condensedmatt/imr_cdt/
students/david_goodwin/teaching/modellin
g/l3_objectorientation.pdf) (PDF). The
University of Warwick. Retrieved
28 November 2015.

External links
Introduction to UML 2 Wikimedia
Commons
Class Diagrams (http://
has media
www.agilemodeling.co related to
Class
diagram.
 m/artifacts/classDiagram.htm)
UML 2 Class Diagram Guidelines (http://
www.agilemodeling.com/style/classDia
gram.htm)
IBM Class diagram Introduction (http://w
ww.ibm.com/developerworks/rational/li
brary/content/RationalEdge/sep04/bel
l/)
OMG UML 2.2 specification documents
(http://www.omg.org/spec/UML/2.2/)
UML 2 Class Diagrams (http://www.uml-
diagrams.org/class-diagrams.html)

Retrieved from
"https://en.wikipedia.org/w/index.php?
title=Class_diagram&oldid=1187264970"

This page was last edited on 28 November 2023,

at 05:10 (UTC). •
Content is available under CC BY-SA 4.0 unless
otherwise noted.