UML Core Elements Reference

Notation Description
Element

Element is the abstract root UML metaclass, it has no superclass in the hierarchy of UML elements. It
UML Element has no notation.
is the superclass for all metaclasses in the UML infrastructure library.

Some subclasses of UML Element

Ownership

UML element has a composition relationship to itself to support the capability for elements to own
other elements.
 Thus, each UML element could be owner of other elements as defined by composition relationship.
Note, that any UML element may not directly or indirectly own itself.

Each UML element has composition to itself - it could

own other elements.

Namespace

Namespace is an abstract named element that could contain (or own) a set of named elements. In
Namespace has no notation in its own right. other words, namespace is a container for named elements.

Some subclasses of the namespace are: package, classifier, behavioral feature, state, region.
 Namespace is an abstract named element and a container for named elements.

Instance

instance-specification-name ::=  [labels]  Instance is some system entity, concrete manifestation (implementation) of an abstraction. Abstraction
[instance-name] ':' [composite-type-names] could be represented by one or more classifiers or no classifiers at all.
labels ::=  '«' label [ ',' label ]* '»' UML 2.4 provides neither syntax BNF rules nor even verbal rules for instance names. I made up some
label ::=  keyword | stereotype BNF shown to the left.
instance-name ::= identifier Instance specification is rendered with its name underlined. In some cases, when it is obvious that
composite-type-names ::=  composite-type- diagram shows an instance, it is allowed not to use underlining.
name [ ',' composite-type-name ]*
composite-type-name ::= 
namespace [ '::' namespace ]*
namespace ::= identifier

An instance specification uses the same notation as classifier. Name is shown as an underlined
concatenation of the instance name (if any), a colon (':') and classifier name(s). In some cases, when it
is obvious that diagram shows an instance, it is allowed not to use underlining.

Names are optional both for instance specifications and for UML classifiers.
Anonymous instance of the Customer class.

In some cases, classifier 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 - :.

Instance newPatient of the unnamed or unknown

class.

Instance could have stereotype, instance name, and classifier specified.

Instance app-srv-37 of the Sun Fire X4150 Server

stereotyped as device.

Instance could have instance name, class and namespace (e.g. 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 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.

Instance newPatient of the Patient class

has slots with values specified.

Association

Association is a relationship between classifiers which is used to show that instances of classifiers
could be either linked to each other or combined logically or physically into some aggregation.

An association is usually drawn as a solid line connecting two classifiers or a single classifier to itself.
Name of the association can be shown somewhere near the middle of the association line but not too
Association Wrote between Professor and Book
close to any of the ends of the line. Each end of the line could be decorated with the name of the
with association ends author and textbook.
association end.
 Association relationship overview diagram

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

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 relating three classifiers.

Aggregation
Aggregation (aka shared aggregation) is shown as binary association decorated with a hollow
diamond as a terminal adornment at the aggregate end of the association line.

Search Service has a Query Builder using shared

aggregation

Composite Aggregation (Composition)

Composite aggregation (aka composition) is a "strong" form of aggregation. Composition

requirements/features listed in UML specification are:
it is a whole/part relationship,
it is binary association,
part could be included in at most one composite (whole) at a time,
Folder could contain many files, while each File has
if a composite (whole) is deleted, all of its composite parts are "normally" deleted with it.
exactly one Folder parent. If Folder is deleted, all
contained Files are deleted as well. Composition is depicted as binary association decorated with a filled black diamond at the aggregate
(composite) end.

When composition is used in domain models, both whole/part relationship as well as event of
composite "deletion" should be interpreted figuratively, not necessarily as physical containment and/or
termination.

Hospital has 1 or more Departments, and each

Department belongs to exactly one Hospital.
If Hospital is closed, so are all of its Departments.

Multiplicity of the composite (whole) could be specified as 0..1 ("at most one") which means that part is
allowed to be a "stand alone", not owned by any specific composite.

Each Department has some Staff, and each Staff

could be a member of one Department (or none). If
Department is closed, its Staff is relieved (but
excluding the "stand alone" Staff).

Ownership of Association End

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.

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 Navigability
No adornment on the end of an association means unspecified navigability.

Both ends of association have unspecified

navigability.

Navigable end is indicated by an open arrowhead on the end of an association.

A2 has unspecified navigability while B2 is

navigable from A2.

Not navigable end is indicated with a small x on the end of an association.

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.

Link

Link is an instance of an association.

It is rendered using the same notation as for an association. Solid line connects instances rather than
classifiers. Name of the link could be shown underlined though it is not required. End names (roles)
Link Wrote between instance p of Professor playing and navigation arrows can be shown.
author role
and instance b of Book in the textbook role.

Dependency

Dependency signifies a supplier / client relationship between model elements where the modification
of the supplier may impact the client model elements. A dependency implies the semantics of the client
is not complete without the supplier.

A dependency is generally shown as a dashed arrow between two model elements. The model element
Data Access depends on Connection Pool 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.
 Dependency relationship overview diagram

Usage

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

For example, it could mean that some method(s) within a (client) class uses objects (e.g. parameters)
Search Controller uses Search Engine. of the another (supplier) class.

A usage dependency is shown as a dependency with a «use» keyword attached to it.

 Abstraction

Abstraction is a dependency relationship that 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.

An abstraction relationship is shown as a dependency arrow from the client at the tail to the the supplier
at the arrowhead, with the «abstraction» keyword or some other predefined stereotype name attached
to. In general, client depends on supplier, and it is a common convention in the OOAD for the
abstraction relationship to have the more abstract element as supplier.

Customer from Domain is abstraction for

CustomerInfo from DataTransfer. (Common
convention example - the more abstract element as
supplier.)

UML modeler may decide that for some domain or task it is more appropriate to show a more abstract
element dependent on the more specific element.

Customer from Domain is abstraction for

CustomerInfo from DataTransfer. (Reverse notation
example - the less abstract element as supplier.)

Noticed a spelling error? Select the text using the mouse and press Ctrl + Enter.

Follow @uml_diagrams
Like 2.4K Share             by Kirill Fakhroutdinov