Unified Modeling Language

Unified Modeling Language (UML) is a standardized general-purpose modeling

language in the field of software engineering. The standard is managed, and was created by,
the Object Management Group.

UML includes a set of graphic notation techniques to create visual models of software-
intensive systems.

Overview

The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and
document the artifacts of an object-oriented software intensive system under development.
[1]
UML offers a standard way to visualize a system's architectural blueprints, including
elements such as:

 actors
 business processes
 (logical) components
 activities
 programming language statements
 database schemas, and
 reusable software components.[2]

UML combines techniques from data modeling (entity relationship diagrams), business
modeling (work flows), object modeling, and component modeling. It can be used with all
processes, throughout thesoftware development life cycle, and across different
implementation technologies.[3] UML has synthesized the notations of the Booch method,
the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by
fusing them into a single, common and widely usable modeling language. UML aims to be a
standard modeling language which can model concurrent and distributed systems. UML is a
de facto industry standard, and is evolving under the auspices of the Object Management
Group (OMG).

UML models may be automatically transformed to other representations (e.g. Java) by means
of QVT-like transformation languages, supported by the OMG. UML is extensible, offering
the following mechanisms for customization: profiles and stereotype.

Unified Modeling Language topics

Software Development Methods

UML is not a development method by itself,[4] however, it was designed to be compatible

with the leading object-oriented software development methods of its time (for
example OMT, Booch method,Objectory). Since UML has evolved, some of these methods
have been recast to take advantage of the new notations (for example OMT), and new
methods have been created based on UML. The best known is IBM Rational Unified
Process (RUP). There are many other UML-based methods like Abstraction
Method, Dynamic Systems Development Method, and others, to achieve different objectives.

Modeling

It is very important to distinguish between the UML model and the set of diagrams of a
system. A diagram is a partial graphic representation of a system's model. The model also
contains documentation that drive the model elements and diagrams (such as written use
cases).

UML diagrams represent two different views of a system model[5]:

 Static (or structural) view: emphasizes the static structure of the

system using objects, attributes, operations and relationships. The
structural view includes class diagrams and composite structure
diagrams.
 Dynamic (or behavioral) view: emphasizes the dynamic behavior of
the system by showing collaborations among objects and changes
to the internal states of objects. This view includes sequence
diagrams, activity diagrams and state machine diagrams.

UML models can be exchanged among UML tools by using the XMI interchange format.

Diagrams overview

UML 2.2 has 14 types of diagrams divided into two categories.[6] Seven diagram types
represent structural information, and the other seven represent general types of behavior,
including four that represent different aspects of interactions. These diagrams can be
categorized hierarchically as shown in the following class diagram:

UML does not restrict UML element types to a certain diagram type. In general, every UML
element may appear on almost all types of diagrams; this flexibility has been partially
restricted in UML 2.0. UMLprofiles may define additional diagram types or extend existing
diagrams with additional notations.

In keeping with the tradition of engineering drawings, a comment or note explaining usage,
constraint, or intent is allowed in a UML diagram.
Structure diagrams

Structure diagrams emphasize the things that must be present in the system being modeled.
Since structure diagrams represent the structure they are used extensively in documenting

the architecture of software systems.

Structure diagrams

Structure diagrams emphasize the things that must be present in the system being modeled.
Since structure diagrams represent the structure they are used extensively in documenting
the architecture of software systems.

 Class diagram: describes the structure of a system by showing the

system's classes, their attributes, and the relationships among the
classes.
 Component diagram: describes how a software system is split up
into components and shows the dependencies among these
components.
 Composite structure diagram: describes the internal structure of a
class and the collaborations that this structure makes possible.
 Deployment diagram: describes the hardware used in system
implementations and the execution environments and artifacts
deployed on the hardware.
 Object diagram: shows a complete or partial view of the structure of
a modeled system at a specific time.
 Package diagram: describes how a system is split up into logical
groupings by showing the dependencies among these groupings.
  Profile diagram: operates at the metamodel level to show
stereotypes as classes with the <<stereotype>> stereotype, and
profiles as packages with the <<profile>> stereotype. The
extension relation (solid line with closed, filled arrowhead) indicates
what metamodel element a given stereotype is extending.

Behaviour diagrams

Behavior diagrams emphasize what must happen in the system being modeled. Since
behavior diagrams illustrate the behavior of a system, they are used extensively to describe
the functionality of software systems.

 Activity diagram: describes the business and operational step-by-

step workflows of components in a system. An activity diagram
shows the overall flow of control.
 UML state machine diagram: describes the states and state
transitions of the system.
 Use case diagram: describes the functionality provided by a system
in terms of actors, their goals represented as use cases, and any
dependencies among those use cases.

Interaction diagrams

Interaction diagrams, a subset of behaviour diagrams, emphasize the flow of control and data
among the things in the system being modeled:

 Communication diagram: shows the interactions between objects or

parts in terms of sequenced messages. They represent a
combination of information taken from Class, Sequence, and Use
Case Diagrams describing both the static structure and dynamic
behavior of a system.
 Interaction overview diagram: provides an overview in which the
nodes represent interaction diagrams.
 Sequence diagram: shows how objects communicate with each
other in terms of a sequence of messages. Also indicates the
lifespans of objects relative to those messages.
 Timing diagrams: are a specific type of interaction diagram, where
the focus is on timing constraints.
 he Protocol State Machine is a sub-variant of the State Machine. It may be used to
model network communication protocols.

Meta modelling
  The Object Management Group (OMG) has developed a metamodeling architecture to
define the Unified Modeling Language (UML), called the Meta-Object
Facility (MOF). The Meta-Object Facility is a standard for model-driven engineering,
designed as a four-layered architecture, as shown in the image at right. It provides a
meta-meta model at the top layer, called the M3 layer. This M3-model is the language
used by Meta-Object Facility to build metamodels, called M2-models. The most
prominent example of a Layer 2 Meta-Object Facility model is the UML metamodel,
the model that describes the UML itself. These M2-models describe elements of the
M1-layer, and thus M1-models. These would be, for example, models written in
UML. The last layer is the M0-layer or data layer. It is used to describe runtime
instance of the system.
 Beyond the M3-model, the Meta-Object Facility describes the means to create and
manipulate models and metamodels by definingCORBA interfaces that describe those
operations. Because of the similarities between the Meta-Object Facility M3-model
and UML structure models, Meta-Object Facility metamodels are usually modeled as
UML class diagrams. A supporting standard of the Meta-Object Facility is XMI,
which defines an XML-based exchange format for models on the M3-, M2-, or M1-
Layer.

Criticisms
 Although UML is a widely recognized and used modeling standard, it is frequently
criticized for the following:
 Standards bloat

 Bertrand Meyer, in a satirical essay framed as a student's request

for a grade change, apparently criticized UML as of 1997 for being
unrelated to object-oriented software development; a disclaimer
was added later pointing out that his company nevertheless
supports UML.[7] Ivar Jacobson, a co-architect of UML, said that
objections to UML 2.0's size were valid enough to consider the
application of intelligent agents to the problem.[8] It contains many
diagrams and constructs that are redundant or infrequently used.

 Problems in learning and adopting

 The problems cited in this section make learning and adopting UML
problematic, especially when required of engineers lacking the
prerequisite skills.[9] In practice, people often draw diagrams with
the symbols provided by their CASE tool, but without the meanings
those symbols are intended to provide.

 Linguistic incoherence

 The extremely poor writing of the UML standards themselves --

assumed to be the consequence of having been written by a non-
native English speaker -- seriously reduces their normative value. In
 this respect the standards have been widely cited, and indeed
pilloried, as prime examples of unintelligible geekspeak.

 Capabilities of UML and implementation language mismatch

 As with any notational system, UML is able to represent some

systems more concisely or efficiently than others. Thus a developer
gravitates toward solutions that reside at the intersection of the
capabilities of UML and the implementation language. This problem
is particularly pronounced if the implementation language does not
adhere to orthodox object-oriented doctrine, as the intersection set
between UML and implementation language may be that much
smaller.

 Dysfunctional interchange format

 While the XMI (XML Metadata Interchange) standard is designed to

facilitate the interchange of UML models, it has been largely
ineffective in the practical interchange of UML 2.x models[citation needed].
This interoperability ineffectiveness is attributable to two reasons.
Firstly, XMI 2.x is large and complex in its own right, since it
purports to address a technical problem more ambitious than
exchanging UML 2.x models. In particular, it attempts to provide a
mechanism for facilitating the exchange of any arbitrary modeling
language defined by the OMG's Meta-Object Facility(MOF). Secondly,
the UML 2.x Diagram Interchange specification lacks sufficient detail
to facilitate reliable interchange of UML 2.x notations between
modeling tools. Since UML is a visual modeling language, this
shortcoming is substantial for modelers who don't want to redraw
their diagrams.[10]

History

Before UML 1.x

After Rational Software Corporation hired James Rumbaugh from General Electric in 1994,
the company became the source for the two most popularobject-oriented modeling
approaches of the day: Rumbaugh's Object-modeling technique (OMT), which was better
for object-oriented analysis(OOA), and Grady Booch's Booch method, which was better
for object-oriented design (OOD). They were soon assisted in their efforts by Ivar Jacobson,
the creator of the object-oriented software engineering (OOSE) method. Jacobson joined
Rational in 1995, after his company, Objectory AB[12], was acquired by Rational. The three
methodologists were collectively referred to as the Three Amigos, since they were well
known to argue frequently with each other regarding methodological practices.
In 1996 Rational concluded that the abundance of modeling languages was slowing the
adoption of object technology, so repositioning the work on a unified method, they tasked the
Three Amigos with the development of a non-proprietary Unified Modeling Language.
Representatives of competing object technology companies were consulted
during OOPSLA '96; they chose boxes for representing classes over Grady Booch's Booch
method's notation that used cloud symbols.

Under the technical leadership of the Three Amigos, an international consortium called
the UML Partners was organized in 1996 to complete theUnified Modeling Language
(UML) specification, and propose it as a response to the OMG RFP. The UML Partners'
UML 1.0 specification draft was proposed to the OMG in January 1997. During the same
month the UML Partners formed a Semantics Task Force, chaired by Cris Kobryn and
administered by Ed Eykholt, to finalize the semantics of the specification and integrate it with
other standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in
August 1997 and adopted by the OMG in November 1997.[13]

UML 1.x

As a modeling notation, the influence of the OMT notation dominates (e. g., using rectangles
for classes and objects). Though the Booch "cloud" notation was dropped, the Booch
capability to specify lower-level design detail was embraced. The use case notation from
Objectory and the component notation from Booch were integrated with the rest of the
notation, but the semantic integration was relatively weak in UML 1.1, and was not really
fixed until the UML 2.0 major revision.

Concepts from many other OO methods were also loosely integrated with UML with the
intent that UML would support all OO methods. Many others also contributed, with their
approaches flavouring the many models of the day, including: Tony Wasserman and Peter
Pircher with the "Object-Oriented Structured Design (OOSD)" notation (not a method), Ray
Buhr's "Systems Design with Ada", Archie Bowen's use case and timing analysis, Paul
Ward's data analysis and David Harel's "Statecharts"; as the group tried to ensure broad
coverage in the real-time systems domain. As a result, UML is useful in a variety of
engineering problems, from single process, single user applications to concurrent, distributed
systems, making UML rich but also large.

The Unified Modeling Language is an international standard:ISO/IEC 19501:2005

Information technology — Open Distributed Processing — Unified Modeling Language
(UML) Version 1.4.2

UML 2.x

UML has matured significantly since UML 1.1. Several minor revisions (UML 1.3, 1.4, and
1.5) fixed shortcomings and bugs with the first version of UML, followed by the UML 2.0
major revision that was adopted by the OMG in 2005[14].
Although UML 2.1 was never released as a formal specification, versions 2.1.1 and 2.1.2
appeared in 2007, followed by UML 2.2 in February 2009. UML 2.3 was formally released in
May 2010[15].

There are four parts to the UML 2.x specification:

1. The Superstructure that defines the notation and semantics for

diagrams and their model elements;
2. the Infrastructure that defines the core metamodel on which the
Superstructure is based;
3. the Object Constraint Language (OCL) for defining rules for model
elements;
4. and the UML Diagram Interchange that defines how UML 2 diagram
layouts are exchanged.

The current versions of these standards follow: UML Superstructure version 2.3, UML
Infrastructure version 2.3, OCL version 2.2, and UML Diagram Interchange version 1.0[16].

Although many UML tools support some of the new features of UML 2.x, the OMG provides
no test suite to objectively test compliance with its specifications.

Activity diagram
 UML 1.x Activity diagram for a guided brainstorming process

Activity diagrams are graphical representations of workflows of stepwise activities and

actions with support for choice, iteration and concurrency.[1] In the Unified Modeling
Language, activity diagrams can be used to describe the business and operational step-by-
step workflows of components in a system. An activity diagram shows the overall flow of
control.

Construction

Activity diagrams are constructed from a limited repertoire of shapes, connected with arrows.
The most important shape types:

 rounded rectangles represent activities;

 diamonds represent decisions;
 bars represent the start (split) or end (join) of concurrent activities;
 a black circle represents the start (initial state) of the workflow;
 an encircled black circle represents the end (final state).

Arrows run from the start towards the end and represent the order in which activities happen.

Hence they can be regarded as a form of flowchart. Typical flowchart techniques lack
constructs for expressing concurrency. However, the join and split symbols in activity
diagrams only resolve this for simple cases; the meaning of the model is not clear when they
are arbitrarily combined with decisions or loops.
While in UML 1.x, activity diagrams were a specialized form of state diagrams, in UML 2.x,
the activity diagrams were reformalized to be based on Petri net-like semantics, increasing
the scope of situations that can be modeled using activity diagrams. These changes cause
many UML 1.x activity diagrams to be interpreted differently in UML 2.x

Applications

In SysML the activity diagram has been extended to indicate flows among steps that convey
physical matter (e.g., gasoline) or energy (e.g., torque, pressure). Additional changes allow
the diagram to better support continuous behaviors and continuous data flows.

Alternatives

In UML 1.x, an alternative to activity diagrams is the UML State diagram, in which states
can be used to represent activities (namely the state of that activity being performed), and
transitions represent the start or completion of activities.

This mapping of activity diagram features to state diagram were formalized in UML 1.x,
leaving activity diagrams little more that the use of state machines to capture behavior and
partially concurrent behavior within a work flow.

Despite the (small) advantages of using UML 1.x activity diagram over state machines, such
as the ability to cover the behaviors of collaborating elements, while state machines are
limited to a single element, many modelers remained using state diagrams. State machines
were attractive to use as the states may also represent conditions that hold before or after the
activities. Activity diagrams and state diagram had similar abilities to express concurrency,
though the run-to-completion (RTC) semantics of State machines limited the expressiveness
of the concurrency.

Perhaps the most important reason why state machines were more popular in UML 1.x over
activity diagrams was that the tool vendors were slow to implement robust activity diagram
capabilities.

With UML 2.x, the foundation of activity diagram changed from being based on state-
machine semantics to now being based on Petri net semantics. This vastly expand the number
of circumstances where activity diagrams are more appropriate to capture the paths of work
flow in a system. Now with the advent of robust activity diagram implementations, activity
diagrams are now generally used more than state machine diagrams.

Use case diagram

 UML Use Cases for a Simple Restaurant Model

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral
diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical
overview of the functionality provided by a system in terms of actors, their goals (represented
as use cases), and any dependencies between those use cases.

The main purpose of a use case diagram is to show what system functions are performed for
which actor. Roles of the actors in the system can be depicted.

Overview

Use Case diagrams are formally included in two modeling languages defined by the OMG:
the Unified Modeling Language (UML) and the Systems Modeling Language (SysML).

Diagram building blocks

Interaction among actors is not shown on the use case diagram. If this interaction is essential
to a coherent description of the desired behavior, perhaps the system or use case boundaries
should be re-examined. Alternatively, interaction among actors can be part of the
assumptions used in the use case.

Actor Generalization

One popular relationship between Actors is Generalization/Specialization. This is useful in

defining overlapping roles between actors. The notation is a solid line ending in a hollow
triangle drawn from the specialized to the more general actor.[1][2][3]

Use Case Relationships

Three relationships among use cases are used often in practice.

Include

In one form of interaction, a given use case may include another. "Include is a Directed
Relationship between two use cases, implying that the behavior of the included use case is
inserted into the behavior of the including use case"[4].

The first use case often depends on the outcome of the included use case. This is useful for
extracting truly common behaviors from multiple use cases into a single description. The
notation is a dashed arrow from the including to the included use case, with the label
"«include»". This usage resembles a macro expansion where the included use case behavior
is placed inline in the base use case behavior. There are no parameters or return values. To
specify the location in a flow of events in which the base use case includes the behavior of
another, you simply write include followed by the name of use case you want to include, as in
the following flow for track order.

Extend

In another form of interaction, a given use case (the extension) may extend another. This
relationship indicates that the behavior of the extension use case may be inserted in the
extended use case under some conditions[1]. The notation is a dashed arrow from the
extension to the extended use case, with the label "«extend»". The notes or constraints may
be associated with this relationship to illustrate the conditions under which this behavior will
be executed.

Modelers use the «extend» relationship to indicate use cases that are "optional" to the base
use case. Depending on the modeler's approach "optional" may mean "potentially not
executed with the base use case" or it may mean "not required to achieve the base use case
goal".

Generalization

In the third form of relationship among use cases, a generalization/specialization relationship

exists. A given use case may have common behaviors, requirements, constraints, and
assumptions with a more general use case. In this case, describe them once, and deal with it
in the same way, describing any differences in the specialized cases. The notation is a solid
line ending in a hollow triangle drawn from the specialized to the more general use case
(following the standard generalization notation).

Sequence diagram

A sequence diagram in Unified Modeling Language (UML) is a kind of interaction

diagram that shows how processes operate with one another and in what order. It is a
construct of a Message Sequence Chart.

Sequence diagrams are sometimes called event diagrams, event scenarios, and timing
diagrams.[1]

Overview

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects
that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in
the order in which they occur. This allows the specification of simple runtime scenarios in a
graphical manner.

For instance, the UML 1.x diagram on the right describes the sequences of messages of a
(simple) restaurant system. This diagram represents a Patron ordering food and wine,
drinking wine then eating the food, and finally paying for the food. The dotted lines
extending downwards indicate the timeline. Time flows from top to bottom. The arrows
represent messages (stimuli) from an actor or object to other objects. For example, the Patron
sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls.

The UML 2.0 Sequence Diagram supports similar notation to the UML 1.x Sequence
Diagram with added support for modeling variations to the standard flow of events.
Diagram building blocks

If the lifeline is that of an object, it demonstrates a role. Note that leaving the instance name
blank can represent anonymous and unnamed instances.

In order to display interaction, messages are used. These are horizontal arrows with the
message name written above them. Solid arrows with full heads are synchronous calls, solid
arrows with stick heads are asynchronous calls and dashed arrows with stick heads are return
messages. This definition is true as of UML 2, considerably different from UML 1.x.

Activation boxes, or method-call boxes, are opaque rectangles drawn on top of lifelines to
represent that processes are being performed in response to the message
(ExecutionSpecifications in UML).

Objects calling methods on themselves use messages and add new activation boxes on top of
any others to indicate a further level of processing.

When an object is destroyed (removed from memory), an X is drawn on top of the lifeline,
and the dashed line ceases to be drawn below it (this is not the case in the first example
though). It should be the result of a message, either from the object itself, or another.

A message sent from outside the diagram can be represented by a message originating from a
filled-in circle (found message in UML) or from a border of sequence diagram (gate in
UML).

UML 2 has introduced significant improvements to the capabilities of sequence diagrams.

Most of these improvements are based on the idea of interaction fragments[2] which represent
smaller pieces of an enclosing interaction. Multiple interaction fragments are combined to
create a variety of combined fragments[3], which are then used to model interactions that
include parallelism, conditional branches, optional interactions.

Usage and limitations

Some systems have simple dynamic behavior that can be expressed in terms of specific
sequences of messages between a small, fixed number of objects or processes. In such cases
sequence diagrams can completely specify the system's behavior. Often, behavior is more
complex, e.g. when the set of communicating objects is large or highly variable, when there
are many branch points (e.g. exceptions), when there are complex iterations, or
synchronization issues such as resource contention. In such cases, sequence diagrams cannot
completely describe the system's behavior, but they can specify typical use cases for the
system, small details in its behavior, and simplified overviews of its behavior.

Deployment diagram
A deployment diagram in the Unified Modeling Language models the physical deployment
of artifacts on nodes.[1] To describe a web site, for example, a deployment diagram would
show what hardware components ("nodes") exist (e.g. a web server, an application server,
and a database server), what software components ("artifacts") run on each node (e.g. web
application, database), and how the different pieces are connected (e.g. JDBC, REST, RMI).

The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles
within the boxes. Nodes may have subnodes, which appear as nested boxes. A single node in
a deployment diagram may conceptually represent multiple physical nodes, such as a cluster
of database servers.

Component diagram
In the Unified Modeling Language, a component diagram depicts how components are
wired together to form larger components and or software systems. Components diagrams are
used to illustrate the structure of arbitrarily complex systems.

Overview

Components are wired together by using an assembly connector to connect the

required interface of one component with the provided interface of another component. This
illustrates the service consumer - service provider relationship between the two components.

An assembly connector is a "connector between two components that defines that one
component provides the services that another component requires. An assembly connector is
a connector that is defined from a required interface or port to a provided interface or port."[1]

When using a component diagram to show the internal structure of a component, the
provided and required interfaces of the encompassing component can delegate to the
corresponding interfaces of the contained components.

A delegation connector is a "connector that links the external contract of a component (as
specified by its ports) to the internal realization of that behavior by the component’s parts."[1]

Package diagram
A package diagram in the Unified Modeling Language depicts the dependencies between
the packages that make up a model.

Overview

In addition to the standard UML Dependency relationship, there are two

special types of dependencies defined between packages:

 package import
 package merge

A package import is "a relationship between an importing namespace and a package,

indicating that the importing namespace adds the names of the members of the package to its
own namespace." [1] By default, an unlabeled dependency between two packages is
interpreted as a package import relationship.

A package merge is "a directed relationship between two packages, that indicates that the
contents of the two packages are to be combined. It is very similar to Generalization in the
sense that the source element conceptually adds the characteristics of the target element to its
own characteristics resulting in an element that combines the characteristics of both"[2]

Usage

Package diagrams can use packages containing use cases to illustrate the functionality of a
software system.

Package diagrams can use packages that represent the different layers of a software system to
illustrate the layered architecture of a software system. The dependencies between these
packages can be adorned with labels / stereotypes to indicate the communication mechanism
between the layers.

Class diagram

Hierarchy of UML 2.0 Diagrams, shown as a class diagram. The individual classes
are represented just with one section, but they often contain up to three
sections.
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, and the relationships between the classes.

Overview

The class diagram is the main building block in object oriented modelling. They are being 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 statical relations between those objects. With
detailed modeling, the classes of the conceptual design are often split in 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 diagramsObject
role modeling can be used if you just want to model the classes and their relationships.[1]

Members

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

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.[2]:
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.

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:

Instance Level Relationships

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.

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.

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.

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. It is represented with a solid diamond shape.

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.

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

Class Level Relationships

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

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

General Relationship

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

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.

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

No instances, or one instance

0..1
(optional, may)

1 Exactly one instance

0..* or * Zero or more instances

1..* One or more instances (at least one)

1..3, 6,
Mixed instances
9..*
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.

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 typically identified by each actor–use-case pair on the system's use-case
diagram.

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.

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

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.