UML

Contents
1

Unied Modeling Language

1.1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

History

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.1

Before UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.2

UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.3

UML 2.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Design/Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.1

Software development methods

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.2

Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.3

Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.4

Meta modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

1.4

Adoption

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5

Criticisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.1

Critique of UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6

See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.7

References

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.8

Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.9

External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Class diagram

2.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2.1

Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2.2

Scopes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.3.1

Instance level relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.3.2

Class level relationships

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.3.3

General relationship

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.3.4

Multiplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.3

2.4

Analysis stereotypes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.5

See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.6

References

15

2.4.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i

ii

CONTENTS
2.7

External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

Object diagram

16

3.1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.2

Object diagram topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.2.1

Instance specications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.2.2

Object diagram example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.2.3

Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.3

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.4

External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

Use Case Diagram

19

4.1

See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.2

References

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.3

Bibliography

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

Interaction overview diagram

21

5.1

References

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

5.2

External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

Sequence diagram
6.1

Diagram building blocks

6.2

References

23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

6.3

External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

6.4

Text and image sources, contributors, and licenses . . . . . . . . . . . . . . . . . . . . . . . . . .

25

6.4.1

Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

6.4.2

Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

6.4.3

Content license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

Chapter 1

Unied Modeling Language

UML logo

The Unied Modeling Language (UML) is a general-purpose modeling language in the eld of software engineering, which is designed to provide a standard way to visualize the design of a system.[1]
It was created and developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software during
199495, with further development led by them through 1996.[1]
In 1997 it was adopted as a standard by the Object Management Group (OMG), and has been managed by this
organization ever since. In 2005 the Unied Modeling Language was also published by the International Organization
for Standardization (ISO) as an approved ISO standard.[2] Since then it has been periodically revised to cover the latest
revision of UML.[3]
1

CHAPTER 1. UNIFIED MODELING LANGUAGE

A collage of UML diagrams

1.1 Overview
The Unied Modeling Language (UML) oers a way to visualize a systems architectural blueprints in a diagram (see
image), including elements such as:[4]
Any activities (jobs)
Individual components of the system
And how they can interact with other software components.
How the system will run
How entities interact with others (components and interfaces)
External user interface
Although originally intended solely for object-oriented design documentation, the Unied Modeling Language (UML)
has been extended to cover a larger set of design documentation (as listed above),[5] and been found useful in many
contexts.[6]

1.2 History
UML has been evolving since the second half of the 1990s and has its roots in the object-oriented methods developed
in the late 1980s and early 1990s. The timeline (see image) shows the highlights of the history of object-oriented
modeling methods and notation.
It is originally based on the notations of the Booch method, the Object-modeling technique (OMT) and Objectoriented software engineering (OOSE), which it has integrated into a single language.[4]

1.2. HISTORY

History of object-oriented methods and notation

1.2.1

Before UML 1.x

Rational Software Corporation hired James Rumbaugh from General Electric in 1994 and after that the company
became the source for two of the most popular object-oriented modeling approaches of the day:[7] Rumbaughs
Object-modeling technique (OMT) and Grady Booch's method. They were soon assisted in their eorts by Ivar
Jacobson, the creator of the object-oriented software engineering (OOSE) method, who joined them at Rational in
1995.[1]
Under the technical leadership of those three (Rumbaugh, Jacobson and Booch), a consortium called the UML
Partners was organized in 1996 to complete the Unied Modeling Language (UML) specication, and propose it
to the Object Management Group (OMG) for standardisation. The partnership also contained additional interested
parties (for example HP, DEC, IBM and Microsoft). The UML Partners UML 1.0 draft was proposed to the OMG
in January 1997 by the consortium. During the same month the UML Partners formed a group, designed to dene
the exact meaning of language constructs, chaired by Cris Kobryn and administered by Ed Eykholt, to nalize the
specication and integrate it with other standardization eorts. The result of this work, UML 1.1, was submitted to
the OMG in August 1997 and adopted by the OMG in November 1997.[1][8]

1.2.2

UML 1.x

After the rst release a task force was formed[1] to improve the language, which released several minor revisions, 1.3,
1.4, and 1.5.[9]
The standards it produced (as well as the original standard) have been noted as being ambiguous and inconsistent.[10][11]

1.2.3

UML 2.x

The UML 2.0 major revision replaced version 1.5 in 2005, which was developed with an enlarged consortium to
improve the language further to reect new experience on usage of its features.[12]

CHAPTER 1. UNIFIED MODELING LANGUAGE

Although UML 2.1 was never released as a formal specication, 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.[13] UML 2.4.1 was formally released
in August 2011.[13] UML 2.5 was released in October 2012 as an In process version and has yet to become formally
released.[13]
There are four parts to the UML 2.x specication:
1. The Superstructure that denes the notation and semantics for diagrams and their model elements
2. The Infrastructure that denes the core metamodel on which the Superstructure is based
3. The Object Constraint Language (OCL) for dening rules for model elements
4. The UML Diagram Interchange that denes how UML 2 diagram layouts are exchanged
The current versions of these standards follow: UML Superstructure version 2.4.1, UML Infrastructure version 2.4.1,
OCL version 2.3.1, and UML Diagram Interchange version 1.0.[14] It continues to be updated and improved by the
revision task force, who resolve any issues with the language.[15]

1.3 Design/Usage
1.3.1

Software development methods

UML is not a development method by itself;[16] however, it was designed to be compatible with the leading objectoriented software development methods of its time (for example OMT, Booch method, Objectory).

1.3.2

Modeling

It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial
graphic representation of a systems model. The set of diagrams need not completely cover the model and deleting a
diagram does not change the model. The model may also contain documentation that drives the model elements and
diagrams (such as written use cases).
UML diagrams represent two dierent views of a system model:[17]
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 XML Metadata Interchange (XMI) interchange
format.

1.3.3

Diagrams

UML 2 has many types of diagrams which are divided into two categories.[4] Some types represent structural information, and the rest represent general types of behavior, including a few that represent dierent aspects of interactions.
These diagrams can be categorized hierarchically as shown in the following class diagram:[4]
These diagrams may all contain comments or notes explaining usage, constraint, or intent.
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 software architecture of software systems. For
example, the component diagram which describes how a software system is split up into components and shows the
dependencies among these components.

1.3. DESIGN/USAGE

Diagram

Structure
Diagram

Class
Diagram

Prole
Diagram

ComponentDiagram

CompositeStruktur
Diagram

Notation: UML

BehaviourDiagram

Object
Diagram

Deployment
Diagram

Activity
Diagram

Package
Diagram

Sequence
Diagram

Communication
Diagram

Use Case
Diagram

Interaction
Diagram

Interaction
Overview
diagramm

State
Machine
Diagram

Timing
Diagram

Hierarchy of UML 2.2 Diagrams, shown as a class diagram

Behavior 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. As an example, the
activity diagram describes the business and operational step-by-step activities of the components in a system.
Interaction diagrams
Interaction diagrams, a subset of behavior diagrams, emphasize the ow of control and data among the things in the
system being modeled. For example, the sequence diagram which shows how objects communicate with each other
in terms of a sequence of messages.
Component diagram
Activity diagram
Sequence diagram
Class diagram
Use Case Diagram
Communication diagram

1.3.4

Meta modeling

Main article: Meta-Object Facility

The Object Management Group (OMG) has developed a metamodeling architecture to dene the Unied Modeling
Language (UML), called the Meta-Object Facility (MOF).[18] The Meta-Object Facility is 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
instances of the system.[19]

CHAPTER 1. UNIFIED MODELING LANGUAGE

Illustration of the Meta-Object Facility

The meta-model can be extended using a mechanism which is called stereotyping. This has been criticised as being
insucient/untenable by Brian Henderson-Sellers and Cesar Gonzalez-Perez in Uses and Abuses of the Stereotype
Mechanism in UML 1.x and 2.0.[20]

1.4 Adoption
UML has been found useful in many design contexts,[6] so much so that is has become ubiquitous in its eld.[21]
It has been treated, at times, as a design silver bullet, which has led to problems in its usage. Misuse of it includes
excessive usage of it (design every little part of the systems code with it, which is unnecessary) and assuming that
anyone can design anything with it (even those who haven't programmed).[22]
It is seen to be a large language, with many constructs in it. Some (including Jacobson) feel that there are too many
and that this hinders the learning (and therefore usage) of it.[23]

1.5 Criticisms
1.5.1

Critique of UML 1.x

Cardinality notation As with database Chen, Bachman, and ISO ER diagrams, class models are specied to use
look-across cardinalities, even though several authors (Merise,[24] Elmasri & Navathe[25] amongst others[26] )
prefer same-side or look-here for roles and both minimum and maximum cardinalities. Recent researchers
(Feinerer,[27] Dullea et. alia[28] ) have shown that the look-across technique used by UML and ER diagrams
is less eective and less coherent when applied to n-ary relationships of order >2.

1.6. SEE ALSO

In Feinerer it says Problems arise if we operate under the look-across semantics as used for UML
associations. Hartmann[29] investigates this situation and shows how and why dierent transformations
fail. (Although the reduction mentioned is spurious as the two diagrams 3.4 and 3.5 are in fact the
same) and also As we will see on the next few pages, the look-across interpretation introduces several
diculties which prevent the extension of simple mechanisms from binary to n-ary associations.

1.6 See also

Model-based testing
Model-driven engineering
Applications of UML
List of Unied Modeling Language tools

1.7 References
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008
and incorporated under the relicensing terms of the GFDL, version 1.3 or later.
[1] Unied Modeling Language User Guide, The (2 ed.). Addison-Wesley. 2005. p. 496. ISBN 0321267974. , See the sample
content, look for history
[2] ISO/IEC 19501:2005 - Information technology - Open Distributed Processing - Unied Modeling Language (UML)
Version 1.4.2. Iso.org. 2005-04-01. Retrieved 2015-05-07.
[3] ISO/IEC 19505-1:2012 - Information technology - Object Management Group Unied Modeling Language (OMG UML)
- Part 1: Infrastructure. Iso.org. 2012-04-20. Retrieved 2014-04-10.
[4] OMG Unied Modeling Language (OMG UML), Superstructure. Version 2.4.1. Object Management Group. Retrieved
9 April 2014.
[5] Satish Mishra (1997). Visual Modeling & Unied Modeling Language (UML) : Introduction to UML. Rational Software
Corporation. Accessed 9 November 2008.
[6] UML, Success Stories. Retrieved 9 April 2014.
[7] Andreas Zendler (1997) Advanced Concepts, Life Cycle Models and Tools for Objeckt-Oriented Software Development.
p.122
[8] UML Specication version 1.1 (OMG document ad/97-08-11)". Omg.org. Retrieved 2011-09-22.
[9] UML. Omg.org. Retrieved 2014-04-10.
[10] Gnova et alia 2004 Open Issues in Industrial Use Case Modeling
[11] Will UML 2.0 Be Agile or Awkward?" (PDF). Retrieved 2011-09-22.
[12] UML 2.0. Omg.org. Retrieved 2011-09-22.
[13] UML. Omg.org. Retrieved 2011-09-22.
[14] OMG. Catalog of OMG Modeling and Metadata Specications. Retrieved 2012-02-21.
[15] Issues for UML 2.6 Revision task Force mailing list. Omg.org. Retrieved 2014-04-10.
[16] John Hunt (2000). The Unied Process for Practitioners: Object-oriented Design, UML and Java. Springer, 2000. ISBN
1-85233-275-1. p.5.door
[17] Jon Holt Institution of Electrical Engineers (2004). UML for Systems Engineering: Watching the Wheels IET, 2004, ISBN
0-86341-354-4. p.58
[18] Iman Poernomo (2006) "The Meta-Object Facility Typed" in: Proceeding SAC '06 Proceedings of the 2006 ACM symposium
on Applied computing. pp. 1845-1849

CHAPTER 1. UNIFIED MODELING LANGUAGE

[19] UML 2.4.1 Infrastructure. Omg.org. 2011-08-05. Retrieved 2014-04-10.

[20] B. Henderson-Sellers; C. Gonzalez-Perez (2006). Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0.
in: Model Driven Engineering Languages and Systems. Springer Berlin / Heidelberg.
[21] UML 2.5: Do you even care?". UML truly is ubiquitous
[22] Death by UML Fever.
[23] Ivar Jacobson on UML, MDA, and the future of methodologies.
[24] Hubert Tardieu, Arnold Rochfeld and Ren Colletti La methode MERISE: Principes et outils (Paperback - 1983)
[25] Elmasri, Ramez, B. Shamkant, Navathe, Fundamentals of Database Systems, third ed., Addison-Wesley, Menlo Park, CA,
USA, 2000.
[26] ER 2004 : 23rd International Conference on Conceptual Modeling, Shanghai, China, 8-12 November 2004
[27] A Formal Treatment of UML Class Diagrams as an Ecient Method for Conguration Management 2007 (PDF). Retrieved 2011-09-22.
[28] James Dullea, Il-Yeol Song, Ioanna Lamprou - An analysis of structural validity in entity-relationship modeling 2002
(PDF). Retrieved 2011-09-22.
[29] ""Reasoning about participation constraints and Chens constraints S Hartmann - 2003 (PDF). Retrieved 2013-08-17.

1.8 Further reading

Ambler, Scott William (2004). The Object Primer: Agile Model Driven Development with UML 2. Cambridge
University Press. ISBN 0-521-54018-6.
Chonoles, Michael Jesse; James A. Schardt (2003). UML 2 for Dummies. Wiley Publishing. ISBN 0-76452614-6.
Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd ed.). AddisonWesley. ISBN 0-321-19368-7.
Jacobson, Ivar; Grady Booch; James Rumbaugh (1998). The Unied Software Development Process. Addison
Wesley Longman. ISBN 0-201-57169-2.
Martin, Robert Cecil (2003). UML for Java Programmers. Prentice Hall. ISBN 0-13-142848-9.
Noran, Ovidiu S. Business Modelling: UML vs. IDEF (PDF). Retrieved 2005-12-28.
Penker, Magnus; Hans-Erik Eriksson (2000). Business Modeling with UML. John Wiley & Sons. ISBN 0-47129551-5.

1.9 External links

Ocial website

Chapter 2

Class diagram

Diagram

Structure
Diagram

Class Diagram

Behaviour
Diagram

Component
Diagram

Composite
Structure
Diagram

Deployment
Diagram

Object
Diagram

Activity
Diagram

Package
Diagram

Use Case
Diagram

State Machine
Diagram

Interaction
Diagram

Sequence
Diagram

Interaction
Overview
Diagram

Communication
Diagram

Timing
Diagram

Hierarchy of UML 2.0 Diagrams, shown as a class diagram. The individual classes are represented just with one compartment, but
they often contain up to three compartments.

In software engineering, a class diagram in the Unied Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the systems classes, their attributes, operations (or
methods), and the relationships among objects.

2.1 Introduction
The class diagram is the main building block of 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. Class diagrams can also be used for data modeling.[1] The classes in a class diagram represent both the main
objects, interactions in the application and the classes to be programmed.
In the diagram, classes are represented with boxes which contain three parts:
The top part contains the name of the class. It is printed in bold and centered, and the rst letter is capitalized.
The middle part contains the attributes of the class. They are left-aligned and the rst letter is lowercase.
The bottom part contains the methods the class can execute. They are also left-aligned and the rst letter is
lowercase.
9

10

CHAPTER 2. CLASS DIAGRAM

BankAccount
owner : String
balance : Dollars = 0
deposit ( amount : Dollars )
withdrawal ( amount : Dollars )
A class with three sections.

In the design of a system, a number of classes are identied and grouped together in a class diagram which helps to
determine the static relations between those objects. With detailed modelling, the classes of the conceptual design
are often split into a number of subclasses.
In order to further describe the behaviour of systems, these class diagrams can be complemented by a state diagram
or UML state machine.[2]

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

2.2.1

Visibility

To specify the visibility of a class member (i.e., any attribute or method), these notations must be placed before the
members name:[3]

2.2.2

Scopes

The UML species two types of scope for members: instance and classier and these last are represented by underlined names.[4]
Classier members are commonly recognized as static in many programming languages. The scope is the
class itself.
Attribute values are equal for all instances
Method invocation does not aect the instances state
Instance members are scoped to a specic instance.
Attribute values may vary between instances
Method invocation may aect the instances state (i.e., change instances attributes)
To indicate a classier scope for a member, its name must be underlined. Otherwise, instance scope is assumed by
default.

2.3. RELATIONSHIPS

11

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

2.3.1

Instance level relationships

Links
A Link is the basic relationship among objects.
Association

Class diagram example of association between two classes

An association represents a family of links. A binary association (with two ends) is normally represented as a line.
An association can link any number of classes. An association with three links is called a ternary association. 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 four dierent types of association: bi-directional, uni-directional, Aggregation (includes Composition aggregation) and Reexive. Bi-directional and uni-directional associations are the most common ones.
For instance, a ight class is associated with a plane class bi-directionally. Association represents the static relationship shared among the objects of two classes.
Aggregation

Professor
+ listOfStudents : list

1..*

Class
+ Students : list

Class diagram showing Aggregation between two classes

Aggregation is a variant of the has a association relationship; aggregation is more specic 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.
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 are not automatically destroyed when
the container is.
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
Composition is a stronger variant of the has a association relationship; composition is more specic than aggregation.

12

CHAPTER 2. CLASS DIAGRAM

Car

Pond

0..1

1..1

0..1

0..*

Carburetor

Duck

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

Composition usually has a strong lifecycle 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, where allowed, a part can 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 lled diamond shape on the containing class
end of the tree of lines that connect contained class(es) to the containing class.
Dierences between composition and aggregation
Composition relationship : When attempting to represent real-world whole-part relationships, e.g., an engine is a part
of a car.
Aggregation relationship : When representing a software or database relationship, e.g., car model engine ENG01 is
part of a car model CM01, as the engine, ENG01 may be also part of a dierent car model.
Thus the aggregation relationship is often catalog containment to distinguish it from compositions physical containment.

2.3.2

Class level relationships

Generalization

Person
+ name : string
+ age : int = 0

Student
+ grades : list

Professor
+ listOfStudents : list

Class diagram showing generalization between one superclass and two subclasses

The Generalization relationship (is a) 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.

2.3. RELATIONSHIPS

13

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 classication: human beings are a subclass of simian, which are 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.
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.
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 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) species.
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, while 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 and interfaces and between components and
interfaces shows that the class realizes the operations oered by the interface.

2.3.3

General relationship

Dependency
Dependency is a weaker form of bond which 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. This is dierent from an association, where an attribute of the dependent class is
an instance of the independent 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.

2.3.4

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

14

CHAPTER 2. CLASS DIAGRAM

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)

2.4 Analysis stereotypes

In the early stages of a projects 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.

2.4.1

Entities

Entity classes model the information handled by the system, and sometimes the behavior associated with the information. They should not be identied 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.

2.5. SEE ALSO

15

2.5 See also

Executable UML
List of UML tools
Object-oriented modeling
Related diagrams
Domain model
Entity-relationship model
Object diagram

2.6 References
[1] Sparks, Georey. Database Modelling in UML. Retrieved 8 September 2011.
[2] Scott W. Ambler (2009) UML 2 Class Diagrams. Webdoc 2003-2009. Accessed Dec 2, 2009
[3] UML Reference Card, Version 2.1.2, Holub Associates, August 2007, retrieved 12 March 2011
[4] OMG Unied Modeling Language (OMG UML) Superstructure, Version 2.3: May 2010. Retrieved 23 September 2010.

2.7 External links

Introduction to UML 2 Class Diagrams
UML 2 Class Diagram Guidelines
IBM Class diagram Introduction
OMG UML 2.2 specication documents
UML 2 Class Diagrams

Chapter 3

Object diagram

Example of an Object diagram.

An object diagram in the Unied Modeling Language (UML), is a diagram that shows a complete or partial view
of the structure of a modeled system at a specic time.

3.1 Overview
In the Unied Modeling Language (UML), an object diagram focuses on some particular set of objects and attributes,
and the links between these instances. A correlated set of object diagrams provides insight into how an arbitrary view
of a system is expected to evolve over time. In early UML specications the object diagram is described as:
"An object diagram is a graph of instances, including objects and data values. A static object diagram is
an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The
use of object diagrams is fairly limited, namely to show examples of data structure.[1][2]
16

3.2. OBJECT DIAGRAM TOPICS

17

The latest UML 2.4 specication doesn't provide any denition of the object diagram.[3]
Object diagrams and class diagrams are closely related[4] and use almost identical notation.[5] Both diagrams are meant
to visualize static structure of a system. While class diagrams show classes, object diagrams displays instances of
classes (objects).[6] Object diagrams are more concrete than class diagrams. They are often used to provide examples
or act as test cases for class diagrams. Only aspects of current interest in a model are typically shown on an object
diagram.

3.2 Object diagram topics

3.2.1

Instance specications

Each object and link on an object diagram is represented by an InstanceSpecication. This can show an objects
classier (e.g. an abstract or concrete class) and instance name, as well as attributes and other structural features
using slots. Each slot corresponds to a single attribute or feature, and may include a value for that entity.
The name on an instance specication optionally shows an instance name, a ':' separator, and optionally one or more
classier names separated by commas. The contents of slots, if any, are included below the names, in a separate
attribute compartment. A link is shown as a solid line, and represents an instance of an association.

3.2.2

Object diagram example

Initially, when n=2, and f(n-2) = 0, and f(n-1) = 1, then f(n) = 0 + 1 = 1.

As an example, consider one possible way of modeling production of the Fibonacci sequence.
In the rst UML object diagram on the right, the instance in the leftmost instance specication is named v1, has
IndependentVariable as its classier, plays the NMinus2 role within the FibonacciSystem, and has a slot for the val
attribute with a value of 0. The second object is named v2, is of class IndependentVariable, plays the NMinus1
role, and has val = 1. The DependentVariable object is named v3, and plays the N role. The topmost instance, an
anonymous instance specication, has FibonacciFunction as its classier, and may have an instance name, a role, and
slots, but these are not shown here. The diagram also includes three named links, shown as lines. Links are instances
of an association.

After the rst iteration, when n = 3, and f(n-2) = 1, and f(n-1) = 1, then f(n) = 1 + 1 = 2.

In the second diagram, at a slightly later point in time, the IndependentVariable and DependentVariable objects are
the same, but the slots for the val attribute have dierent values. The role names are not shown here.
In the last object diagram, a still later snapshot, the same three objects are involved. Their slots have dierent values.
The instance and role names are not shown here.

18

CHAPTER 3. OBJECT DIAGRAM

After several more iterations, when n = 7, and f(n-2) = 5, and f(n-1) = 8, then f(n) = 5 + 8 = 13.

3.2.3

Usage

If you are using a UML modeling tool, you will typically draw object diagrams using some other diagram type, such
as on a class diagram. An object instance may be called an instance specication or just an instance. A link between
instances is generally referred to as a link. Other UML entities, such as an aggregation or composition symbol (a
diamond) may also appear on an object diagram.

3.3 References
[1] Object Management Group (2001) UML specication 1.4, September 2001
[2] Anne Banks Pidduck, John Mylopoulos, Carson C. Woo (2002) Advanced Information Systems Engineering. p.776.
[3] Classication of UML 2.5 Diagrams on uml-diagrams.org. Retrieved Dec 7, 2012
[4] Marcus Fontoura, Wolfgang Pree & Bernhard Rumpe (2002) The UML prole for framework architectures. p.19
[5] Kassem A. Saleh (2009) Software Engineering. p.47
[6] Bianca Scholten (2007) The Road to Integration: A Guide to Applying the ISA-95 Standard in Manufacturing. p.155

3.4 External links

General information on UML including the ocial UML 2.0 specication. See especially the section on InstanceSpecication.
The Expressive Power of Object Diagrams, an illustration from the real world
Modal object diagrams, an extension of object diagrams with existential/universal and positive/negative modes.

Chapter 4

Use Case Diagram

uc Use Cases
System Boundary

receive order

Order
Food

Waiter
place order

<<extend>> Order

Wine

conrm order

Serve
Food

Cook
Food
Chef

<<extend>>

{if wine was ordered}

Serve
Wine
Eat
Food
Client
facilitate payment

<<extend>>
{if wine
was
served}

Drink
Wine

pay
accept
payment
Cashier

Pay for
Food

<<extend>>
{if wine
was
consumed}

Pay for
Wine

A UML use case diagram for the interaction of a client (the actor) within a restaurant (the system)

A use case diagram at its simplest is a representation of a users interaction with the system that shows the relationship
between the user and the dierent use cases in which the user is involved. A use case diagram can identify the dierent
types of users of a system and the dierent use cases and will often be accompanied by other types of diagrams as
19

20

CHAPTER 4. USE CASE DIAGRAM

well.

4.1 See also

Agile software development
Applications of UML
Business Case
Fundamental modeling concepts
SysML
Unied Modeling Language
Use case
User story

4.2 References
4.3 Bibliography
Gemino, A., Parker, D.(2009) Use case diagrams in support of use case modeling: Deriving understanding
from the picture, Journal of Database Management, 20(1), 1-24.
Jacobson, I., Christerson M., Jonsson P., vergaard G., (1992). Object-Oriented Software Engineering - A Use
Case Driven Approach, Addison-Wesley.
Kawabata, R., Kasah, K. (2007). Systems Analysis for Collaborative System by Use Case Diagram, Journal
of Integrated Design & Process Science, 11(1), 13-27.
McLaughlin, B., Pollice, G., West, D. (2006). Head First Object Oriented Analysis and Design, O'Reilly Media,
Inc.
Siau, K., Lee, L. (2004). Are use case and class diagrams complementary in requirements analysis? An
experimental study on use case and class diagrams in UML, Requirements Engineering, 9(4), 229-237.
Vidgen, R. (2003). Requirements Analysis and UML: Use Cases and Class Diagrams, Computing & Control
Engineering, 14(2), 12.

Chapter 5

Interaction overview diagram

Interaction Overview Diagram is one of the thirteen types of diagrams of the Unied Modeling Language (UML),
which can picture a control ow with nodes that can contain interaction diagrams.[1]
The interaction overview diagram is similar to the activity diagram, in that both visualize a sequence of activities.
The dierence is that, for an interaction overview, each individual activity is pictured as a frame which can contain a
nested interaction diagrams. This makes the interaction overview diagram useful to deconstruct a complex scenario
that would otherwise require multiple if-then-else paths to be illustrated as a single sequence diagram.[2]
The other notation elements for interaction overview diagrams are the same as for activity diagrams. These include
initial, nal, decision, merge, fork and join nodes. The two new elements in the interaction overview diagrams are
the interaction occurrences and interaction elements.[3]

5.1 References
[1] Types of modeling diagrams. Retrieved 12 Sept 2008.
[2] UModel Interaction Overview Diagrams. Retrieved 12 Sept 2008.
[3] Sparx Systems - UML 2 Tutorial - Interaction Overview Diagram. Retrieved 12 Sept 2008.

5.2 External links

UML 2 Interaction Overview Diagrams at agilemodeling.com
UModel Interaction Overview Diagrams

21

22

CHAPTER 5. INTERACTION OVERVIEW DIAGRAM

sd AccessControl

sd Enter Code
:AccessControl
System

:User

enter code
check code

[code OK]

ref

Interaction overview diagram

Release door
for one access

[code not OK]

Chapter 6

Sequence diagram

:Computer

:Server

checkEmail
sendUnsentEmail

newEmail
response
[newEmail] downloadEmail

deleteOldEmail

Sequence diagram of e-mail message sequence

A Sequence diagram is an interaction diagram that shows how processes operate with one another and what is their
order. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in
time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged
23

24

CHAPTER 6. SEQUENCE DIAGRAM

between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically associated
with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes
called event diagrams or event scenarios.
A sequence diagram shows, as parallel vertical lines (lifelines), dierent 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
specication of simple runtime scenarios in a graphical manner.

6.1 Diagram building blocks

If the lifeline is that of an object, it demonstrates a role. Leaving the instance name blank can represent anonymous
and unnamed instances.
Messages, written with horizontal arrows with the message name written above them, display interaction. Solid arrow
heads represent synchronous calls, open arrow heads represent asynchronous messages, and dashed lines represent
reply messages.[1] If a caller sends a synchronous message, it must wait until the message is done, such as invoking
a subroutine. If a caller sends an asynchronous message, it can continue processing and doesnt have to wait for a
response. Asynchronous calls are present in multithreaded applications and in message-oriented middleware. 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 (ExecutionSpecications 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 rst 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 lled-in circle (found
message in UML) or from a border of the sequence diagram (gate in UML).
UML has introduced signicant 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.

6.2 References
[1] OMG (2011). OMG Unied Modeling Language (OMG UML), Superstructure, V2.4.1, p. 507.
[2] OMG (2008). OMG Unied Modeling Language (OMG UML), Superstructure, V2.1.2, p. 485.
[3] OMG (2008). OMG Unied Modeling Language (OMG UML), Superstructure, V2.1.2. p. 467.

6.3 External links

UML Distilled by Martin Fowler
Current UML Specication by Object Management Group (OMG)
Introduction to UML 2 Sequence Diagrams by Scott W. Ambler.
A Quick Introduction to UML Sequence Diagrams by Yanic Inghelbrecht
UML 2 Sequence Diagrams

6.4. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

25

6.4 Text and image sources, contributors, and licenses

6.4.1

Text

Unied Modeling Language Source: http://en.wikipedia.org/wiki/Unified%20Modeling%20Language?oldid=662422302 Contributors:

Tobias Hoevekamp, Derek Ross, Bryan Derksen, Timo Honkasalo, Taw, Andre Engels, Hannes Hirzel, DennisDaniels, Edward, Nealmcb,
Msa~enwiki, Michael Hardy, Booyabazooka, David Martland, Ixfd64, Sannse, MartinSpamer, Ronz, Snoyes, Angela, Mark Foskey,
Julesd, Poor Yorick, Nikai, Scott, IMSoP, Wael Ellithy, Daveryan, Jonik, Mxn, Conti, Technopilgrim, Boson, Sbwoodside, Jay, Andrewman327, Doradus, Zoicon5, Siyu LI, Bevo, TowerDragon, JorgeGG, Jeq, Robbot, ChrisG, Jakohn, Vespristiano, RedWolf, Bechemel,
Agentv, Hadal, Beorhast, Salty-horse, Pengo, Ancheta Wis, Gerald Mylog, Mintleaf~enwiki, Jriddell, BenFrantzDale, Levin, Herbee,
Mark.murphy, Everyking, Joconnor, Duncharris, Khalid hassani, Uzume, Wmahan, Comatose51, SebastianBreier~enwiki, Alexf, SarekOfVulcan, LiDaobing, Antandrus, Beland, Mysidia, BoP, Joyous!, MVerkerk, Mike Rosoft, Kmccoy, Poccil, Noisy, Discospinster, ElTyrant,
Rich Farmbrough, Leibniz, Rspeer, Abelson, LeeHunter, Martpol, Hhielscher, Harriv, Robertbowerman, TerraFrost, S.K., Danakil,
Um9penmc, Project2501a, Chairboy, Shanes, Femto, Jpiw~enwiki, TommyG, Cmdrjameson, Polluks, MaxHund, Obradovic Goran,
Kierano, Mdd, Kuratowskis Ghost, Alansohn, Mo0, Walter Grlitz, Craigy144, Yamla, Tayal01, Jancewic, Caesura, Ronark, RJFJR,
Sciurin, Thowa, Oleg Alexandrov, Demiurg, Rodii, Anish7, Woohookitty, Dbarashev, Camw, Zergwyn, Birge~enwiki, Firien, Sega381,
Lafeber~enwiki, Nick1nildram, Palica, PhilippWeissenbacher, Marudubshinki, Glenford, DePiep, Grammarbot, Mayumashu, Demian12358,
Koavf, Salix alba, Crazynas, Ligulem, Dmccreary, GeorgeBills, Sleepyhead81, Yamamoto Ichiro, Pgerts, FlaBot, Dirkbike, Marsve,
Pojo, Sketch-The-Fox, M7bot, JWenting, Spasemunki, Bobdc, Cactus.man, BrownHornet, Kakurady, YurikBot, Borgx, Josef Sbl cz,
StuOfInterest, RussBot, GLari, Opptic~enwiki, Xihr, Gardar Rurak, Bergsten, Rodasmith, Rsrikanth05, EngineerScotty, ENeville,
Piksou, SAE1962, Jpbowen, Dethomas, Mjchonoles, Gadget850, Bota47, Dirk Riehle, Black Falcon, Anders Nilsson~enwiki, Cdiggins, Lt-wiki-bot, Closedmouth, Abune, JLaTondre, Allens, Mardus, CrniBombarder!!!, Arnabbh, That Guy, From That Show!, Gparent, SmackBot, Lashiec, FishSpeaker, Slashme, Andres Agudelo, Hydrogen Iodide, Vardhanw, Deon Steyn, KocjoBot~enwiki, Brick
Thrower, Ozten, Ohnoitsjamie, Folajimi, Jcarroll, BenAveling, Jjalexand, Lloydsmart, Thumperward, Oli Filth, David KELLER~enwiki,
Logonos, Jerome Charles Potts, Octahedron80, DHN-bot~enwiki, Hongooi, Royboycrashfan, Can't sleep, clown will eat me, Stiang, Nixeagle, Cathness~enwiki, BarryNorton, Seattlenow, Allan McInnes, JustAnotherJoe, MichaelBillington, Clarepawling, Maximumbrownidge, Ewebxml, RayGates, ThurnerRupert, AdrianLozano, Fatespeaks, Kimdonndenman, Frentos, Antonielly, SpyMagician, Misteror,
A. Parrot, Beetstra, Noah Salzman, Julthep, Martinig, TastyPoutine, Victor Snezhko, AdultSwim, Mgillett, MTSbot~enwiki, Hu12,
ScottWAmbler, Iridescent, Vim-Hogar, J Di, Vocaro, Sahuagin, AGK, Fdp, Tawkerbot2, George100, Eastlaw, S ried, CmdrObot, Dvdrtrgn, Doral, MicahDCochran, Pmerson, Kenneth Vergil, Steven Kelly, Gregbard, MDE, Fl, Af1n, Luckyherb, OVERM1ND, Pindakaas, Mrockman, Malleus Fatuorum, Thijs!bot, Nagarjunag, Kilva, Hervegirod, QVT, Kataniza, Tellyaddict, Philippe, Xactium, Escarbot, KrakatoaKatie, Dhbernstein, AntiVandalBot, Hpetya, Zappernapper, Kishorekumar 62, Yellowdesk, Alphachimpbot, Progdev,
Myguest, MME, Jrutley, Krishvanth, Ppelleti, Bob22232, Emerks, Naayagan, Jdmarshall, Toddfast, Yakushima, Loqi, EPHERE, DerHexer, Xtifr, Oicumayberight, MartinBot, Glrx, ChristianPetro, PrestonH, Erkan Yilmaz, Oemmler, Rob Burbidge, Seanhan, Bhanks,
Peterkimrowe, LordAnubisBOT, Edrawing, Wht p0wer, Afxid, Vanished user g454XxNpUVWvxzlr, Aquatics, Ksumedh, Cometstyles,
Treisijs, Ja 62, CardinalDan, Remi0o, Tevirselrahc, VolkovBot, Soliloquial, Kyle the bot, Philip Trueman, Dobbin2000, TXiKiBoT,
Ryan shell, Salvar, O watkins, Figureskatingfan, MegoMars, Hhtracy, Sarav62, Falcon8765, Enviroboy, Sue Rangell, Arjun024, SieBot,
Gorpik, Gerakibot, Triwbe, Smsarmad, Happysailor, Jojalozzo, Twasserman, Techman224, Educres, Senak, OKBot, Ivpen, FranckBarbier, Vrsane, Stfg, Hedleya, DeQuire, Lecafe1, Denisarona, Classicalecon, ITocapa, ClueBot, Ccsingle07, Alksentrs, Niceguyedc,
Ryadav, Pointillist, VOGELLA, Alexbot, M4gnum0n, WalterGR, Jamestochter, El bot de la dieta, Learn4life, KyleSummers, DumZiBoT, BarretB, XLinkBot, Addbot, Mortense, Willking1979, Maria C Mosak, Acockrum, Fieldday-sunday, Leszek Jaczuk, MrOllie,
Roux, SpBot, Dayewalker, Legobot, Luckas-bot, Yobot, Jems421, Sprachpeger, Fraggle81, Mirosamek, Wonder, AnomieBOT, Fotomut, Jim1138, Piano non troppo, Kingpin13, Materialscientist, Citation bot, Thejavaguy, Narcsisuss, Xqbot, TheAMmollusc, Nioski,
JohnnyGeetar, , Nasa-verve, Xmen253, Lwoodyiii, RibotBOT, Kyng, Intelliw, Cyberhitesh, ed, Emmjoyit, Spacelib, Shadowjams,
Aholub~enwiki, Wiretse, Mark Renier, Sae1962, HamburgerRadio, I dream of horses, Jschnur, RedBot, Kimrew, Corrie.engelbrecht,
Profvalente, Monymirza, TobeBot, Jonkerz, Riverdusty, Corb3126, Reaper Eternal, Emakarov, Crysb, Suusion of Yellow, Ben modeler, Kire87, Pierre5018, Ottomachin, EmausBot, GeneralCheese, Acather96, Serkanbirkan, Aludstartups, Rajesh.jadhav.18, Wikipelli,
Rcdeboer, Bernard.szlachta, JensMDD, Alexey.kudinkin, Myselfram, Cloud ponderer, Samliew, Khishig.s, JeremySmyth, ZZZ zzz 222,
Graphity, TeleOce, Sven Manguard, Petrb, Mikhail Ryazanov, ClueBot NG, Astatine211, Smtchahal, Morgankevinj huggle, Timothyclethbridge, Satellizer, Richard-VS-545, Kadamwiki, Danim, Helpful Pixie Bot, Kronn8, BG19bot, , Leggattst, Karategeek6, MusikAnimal, Harshadsamant, Cncmaster, Tawaregs08.it, Joydeep, Manu31415, Jorgjimen, Zanemoody, Nashrul
Hakiem, Armand3496, BattyBot, Mrgamedesign, Famarsha, Deeray82, Jmcrispin, Windknigth, CarrieVS, EuroCarGT, Zuckon, Isarra
(HG), Frosty, De-Wiki-observer, Zolkash, Faizan, Red-eyed demon, Pp3223, Mthinkcpp, Diyoev, Softzen, Bebates, Skr15081997, Hohohoneysingh, MadScientistX11, Monkbot, Macofe, Niraj Aher, Saupav, Some Gadget Geek, Dklotz84, Miraclexix and Anonymous:
768
Class diagram Source: http://en.wikipedia.org/wiki/Class%20diagram?oldid=661626359 Contributors: Ubiquity, Daveryan, Chuunen
Baka, RedWolf, Techtonik, Tobias Bergemann, Oberiko, Esap, Khalid hassani, Alexf, Calm, Urhixidur, Klemen Kocjancic, Mathiasl26,
Shenme, LeonardoGregianin, SpeedyGonsales, Mdd, Zachlipton, Jeltz, Finem, Bennetto, Jdiemer, Kanenas, Gimboid13, Palica, DePiep, Ligulem, Dmccreary, Penumbra2000, Windchaser, Crazycomputers, MirianBruckschen, Korg, The Rambling Man, Wavelength,
Heiko, Bergsten, Rodasmith, Oni Lukos, Sundar22in~enwiki, SAE1962, Mjchonoles, Muu-karhu, Closedmouth, Ketsuekigata, Rcronk,
SmackBot, Unschool, Brick Thrower, Roma emu, Gilliam, Ohnoitsjamie, Betacommand, Lloydsmart, NCurse, Ctbolt, Can't sleep,
clown will eat me, Juandev, Mykolas OK, Dreadstar, Doug Bell, Disavian, Gang65, Ian.desouza, 16@r, Pccestudent, Noodlez84, Joe
Lennon~enwiki, Snooper77, CmdrObot, Astralblue, TXAggie, Spoxox, Cydebot, MC10, Myhlow, The prophet wizard of the crayon cake,
Luna Santin, Chico75, Kishorekumar 62, LaurentSmith, Dougher, JAnDbot, Josephmarty, Andonic, Giridharhb, .anacondabot, Magioladitis, Wikidudeman, JamesBWatson, Gregly, Cpl Syx, Ronbarak, JaGa, Touriste (usurped), Infrangible, J.delanoy, Pharaoh of the Wizards, Adavidb, Makslane, Bhanks, Barts1a, P pateriya, Jmcw37, Shoessss, VolkovBot, Je G., Oktalist, TyrantX, Codeshepherd, Medgno,
Vipb, SieBot, Winchelsea, Taemyr, Niharcatseye2k4, AlanUS, Anchor Link Bot, Gerardohc, PsyberS, ClueBot, Snigbrook, Justin W
Smith, Certes, Dfoxvog, VictoriaUni111, Addbot, BrainMarble, Samirsyed, MrOllie, West.andrew.g, Tide rolls, JakobVoss, Yobot,
Bigtophat, Jozrael, Nltheshadow, AnomieBOT, 9258fahskh917fas, Flewis, Materialscientist, Taeshadow, Xqbot, Leirbag.arc, Avuthu,
Sinisa.rudan, Karl80, Shadowjams, Quod erat demonstrandum 3.14159, Mark Renier, Sae1962, Umawera, Gar onn, Pinethicket, RedBot, Yunshui, Ryancwarren, Tbhotch, The Utahraptor, Autumnalmonk, EmausBot, WikitanvirBot, DHorse1, Active Banana, Wikipelli,
Ticaro, Dancsi5000, HamMElion, Carmichael, Shnako, Nonmal, 28bot, Harendra1987, ClueBot NG, Timothyclethbridge, Jessedo-

26

CHAPTER 6. SEQUENCE DIAGRAM

herty, Snotbot, Rezabot, Widr, Dr. Zombieman, Danim, Raghul.jayagopal, Titodutta, , Anandmr07, Writ Keeper, Kif2, Billie usagi,
Shilpa More, AmieeED, EagerToddler39, Sminthopsis84, Lugia2453, Isarra (HG), Chaimara, Epicgenius, Seanhalle, Franois Robere,
LambdaB, Babitaarora, Quenhitran, Jaundavid, Shobanagms, KH-1 and Anonymous: 464
Object diagram Source: http://en.wikipedia.org/wiki/Object%20diagram?oldid=636154282 Contributors: Quadell, Mike Gleason, Mdd,
Dionyziz, DePiep, Salix alba, Stephenb, Qualc1, Tom Morris, SmackBot, IanVaughan, Brick Thrower, Ohnoitsjamie, Cydebot, Thijs!bot,
VictorAnyakin, KenSWebb, VolkovBot, Deconstructhis, Yintan, Denisarona, Sfan00 IMG, Sun Creator, BOTarate, Thehelpfulone, MystBot, Addbot, Dawynn, AnomieBOT, Materialscientist, Mark Renier, Sae1962, EmausBot, RaptureBot, ClueBot NG, BG19bot, AvocatoBot and Anonymous: 28
Use Case Diagram Source: http://en.wikipedia.org/wiki/Use%20Case%20Diagram?oldid=658803408 Contributors: Bearcat, Mdd, Bgwhite, Chris the speller, DStoykov, Technopat, Flyer22, Trustable, Addbot, Mortense, Download, Materialscientist, A.amitkumar, RedBot, MastiBot, DonToto, ClueBot NG, Nobletripe, AvocatoBot, Tgdixon, Jmcrispin, AutomaticStrikeout, Sminthopsis84, Lugia2453,
Tentinator and Anonymous: 39
Interaction overview diagram Source: http://en.wikipedia.org/wiki/Interaction%20overview%20diagram?oldid=654323800 Contributors: Robbot, Mdd, Wainstead, Jgoulden, Cydebot, Alaibot, Lfstevens, Jesdisciple, Mercenario97, Hamid nazari, Alexbot, Muro Bot,
MystBot, Addbot, Dawynn, Legobot, Mark Renier, Sae1962, EmausBot, R.guest, Pb4378, Darylgolden, Draconis Imp, Wdm777, Javism,
Stkl and Anonymous: 4
Sequence diagram Source: http://en.wikipedia.org/wiki/Sequence%20diagram?oldid=653126567 Contributors: Frecklefoot, Rp, Ehn,
Selket, Adam McMaster, Ravikiran r, Humblefool, Jayjg, Discospinster, Bluap, LeonardoGregianin, Mdd, Interiot, Arthena, Alai,
Lensovet, Davidfstr, DePiep, Ligulem, FlaBot, Antiuser, Anrie Nord, YurikBot, Heiko, Muu-karhu, Wangi, Woling, Zerodamage,
DoriSmith, Allens, SmackBot, Reedy, Fikus, Elwood j blues, Iridiumcao, Jerome Charles Potts, Cplakidas, Viking880, Doug Bell, 16@r,
ScottWAmbler, Harold f, Smhanov, Makeemlighter, Cydebot, Mblumber, Andmatt, Divyangmithaiwala, Marek69, Kishorekumar 62,
LaurentSmith, VictorAnyakin, JAnDbot, Ali naqvi, Trusilver, Olivier Jaquemet, Skier Dude, Idioma-bot, Svt, VolkovBot, Anna Lincoln,
Kirkpthompson, Kovianyo, Falcon8765, !dea4u, Ivarru, SieBot, VVVBot, Flyer22, Maintainj, Helenabella, Watchduck, BOTarate, Nelson.cruz, Rror, SilvonenBot, Addbot, Dawynn, MrOllie, AndersBot, SpBot, Technoparkcorp, Yobot, Kingpin13, Materialscientist, Srinivas, Taeshadow, JimVC3, Nleghari, Ballenato, GrouchoBot, Intelliw, MerlLinkBot, Quod erat demonstrandum 3.14159, Dmitry.Bedrin,
Mark Renier, Sae1962, DixonDBot, Lotje, Vutrankien, Orphan Wiki, WikitanvirBot, Rajesh.jadhav.18, Ticaro, Utar, Anvesh1891,
Bill william compton, ClueBot NG, Cresdajv, Mangofantasy, Wikimpan, Dominikhonnef, Katydorjee, Ruhibg, Atlas-maker, MrLinkinPark333, Tunestig and Anonymous: 189

6.4.2

Images

File:AggregationAndComposition.svg Source: http://upload.wikimedia.org/wikipedia/en/9/9f/AggregationAndComposition.svg License: PD Contributors:

en.wikipedia.org
Original artist:
ACiD2, Mikm, Pne, Mjchonoles, Rjgodoy, NevilleDNZ, Tobias Bergemann
File:BankAccount1.svg Source: http://upload.wikimedia.org/wikipedia/commons/4/41/BankAccount1.svg License: GFDL Contributors: vectorized http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/index.html#main Original artist:
Donald Bell
File:CheckEmail.svg Source: http://upload.wikimedia.org/wikipedia/commons/9/9b/CheckEmail.svg License: CC BY-SA 3.0 Contributors: File:CheckEmail.png Original artist: Coupling_loss_graph.svg
File:Class_Dependency.png Source: http://upload.wikimedia.org/wikipedia/commons/f/f8/Class_Dependency.png License: CC BY
3.0 Contributors: Own work Original artist: Samirsyed
File:Commons-logo.svg Source: http://upload.wikimedia.org/wikipedia/en/4/4a/Commons-logo.svg License: ? Contributors: ? Original artist: ?
File:Crystal_Clear_device_cdrom_unmount.png Source: http://upload.wikimedia.org/wikipedia/commons/1/10/Crystal_Clear_device_
cdrom_unmount.png License: LGPL Contributors: All Crystal Clear icons were posted by the author as LGPL on kde-look; Original artist:
Everaldo Coelho and YellowIcon;
File:EntityControlBoundary_Pattern.jpg Source: http://upload.wikimedia.org/wikipedia/commons/6/6a/EntityControlBoundary_Pattern.
jpg License: Public domain Contributors: http://www.cs.sjsu.edu/~{}pearce/modules/lectures/ooa/analysis/ecb.htm Original artist: http:
//www.cs.sjsu.edu/~{}pearce/modules/lectures/ooa/analysis/ecb.htm
File:Folder_Hexagonal_Icon.svg Source: http://upload.wikimedia.org/wikipedia/en/4/48/Folder_Hexagonal_Icon.svg License: Cc-bysa-3.0 Contributors: ? Original artist: ?
File:KP-UML-Aggregation-20060420.svg Source: http://upload.wikimedia.org/wikipedia/commons/2/2a/KP-UML-Aggregation-20060420.
svg License: Public domain Contributors: ? Original artist: ?
File:KP-UML-Generalization-20060325.svg Source: http://upload.wikimedia.org/wikipedia/commons/6/66/KP-UML-Generalization-20060325.
svg License: Public domain Contributors: ? Original artist: ?
File:M0-m3.png Source: http://upload.wikimedia.org/wikipedia/commons/9/93/M0-m3.png License: Public domain Contributors: Own
work based on UML 2.0 Infrastructure Specication, S. 31, slightly adapted. Original artist: Gubaer
File:OO_Modeling_languages_history.jpg Source: http://upload.wikimedia.org/wikipedia/commons/d/d1/OO_Modeling_languages_
history.jpg License: CC BY-SA 3.0 Contributors: Translation and update of File:OO-historie-2.svg by AxelScheithauer, Okt 6, 2009
Original artist: Guido Zockoll, Axel Scheithauer & Marcel Douwe Dekker (Mdd)
File:Object_Diagram_1.png Source: http://upload.wikimedia.org/wikipedia/commons/a/a7/Object_Diagram_1.png License: Public
domain Contributors: Own work; original upload at en:File:ObjectDiagram N.png Original artist: KenSWebb

6.4. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

27

File:Object_Diagram_2.png Source: http://upload.wikimedia.org/wikipedia/commons/a/ad/Object_Diagram_2.png License: CC-BYSA-3.0 Contributors: Transferred from en.wikipedia

Own work (KenSWebb at en.wikipedia) Original artist: KenSWebb at en.wikipedia
File:Object_Diagram_Initial.png Source: http://upload.wikimedia.org/wikipedia/commons/a/aa/Object_Diagram_Initial.png License:
Public domain Contributors: Own work Original artist: KenSWebb
File:Object_diagram.png Source: http://upload.wikimedia.org/wikipedia/commons/1/17/Object_diagram.png License: Public domain
Contributors: Own work Original artist: Mac9
File:Question_book-new.svg Source: http://upload.wikimedia.org/wikipedia/en/9/99/Question_book-new.svg License: Cc-by-sa-3.0
Contributors:
Created from scratch in Adobe Illustrator. Based on Image:Question book.png created by User:Equazcion Original artist:
Tkgd2007
File:UML_Diagrams.jpg Source: http://upload.wikimedia.org/wikipedia/commons/8/81/UML_Diagrams.jpg License: CC-BY-SA3.0 Contributors: Own work Original artist: Kishorekumar 62
File:UML_diagrams_overview.svg Source: http://upload.wikimedia.org/wikipedia/commons/e/ed/UML_diagrams_overview.svg License: Public domain Contributors: This le was derived from: Uml diagram2.png
Original artist: Derfel73; Pmerson
File:UML_logo.gif Source: http://upload.wikimedia.org/wikipedia/en/2/2d/UML_logo.gif License: Fair use Contributors:
The logo is from the http://www.omg.org/legal/tm_list.htm website. http://uml.web.id/wp-content/uploads/2011/12/UML_logo.gif Original artist: ?
File:UML_role_example.gif Source: http://upload.wikimedia.org/wikipedia/commons/4/4d/UML_role_example.gif License: CC-BYSA-3.0 Contributors: Transferred from en.wikipedia by SreeBot Original artist: Esap at en.wikipedia
File:Uml-Iod-Diagram1.svg Source: http://upload.wikimedia.org/wikipedia/commons/1/17/Uml-Iod-Diagram1.svg License: CC BYSA 4.0 Contributors: Own work, translation from German version Uml-Iod-Diagramm1.svg Original artist: Stkl
File:Uml_diagram.svg Source: http://upload.wikimedia.org/wikipedia/commons/7/74/Uml_diagram.svg License: Public domain Contributors: Own work (original was <a href='//en.wikipedia.org/wiki/Image:Uml_diagram.svg' class='extiw' title='en:Image:Uml diagram.svg'>here</a>
Original artist: Dave A Ryan
File:Unbalanced_scales.svg Source: http://upload.wikimedia.org/wikipedia/commons/f/fe/Unbalanced_scales.svg License: Public domain Contributors: ? Original artist: ?
File:Use_case_restaurant_model.svg Source: http://upload.wikimedia.org/wikipedia/commons/1/1d/Use_case_restaurant_model.svg
License: CC BY-SA 3.0 Contributors: Own work, redrawn of w:File:Restaurant Model.png Original artist: Kishorekumar 62 (redrawn by
Marcel Douwe Dekker)
File:Wikiversity-logo.svg Source: http://upload.wikimedia.org/wikipedia/commons/9/91/Wikiversity-logo.svg License: CC BY-SA
3.0 Contributors: Snorky (optimized and cleaned up by verdy_p) Original artist: Snorky (optimized and cleaned up by verdy_p)

6.4.3

Content license

Creative Commons Attribution-Share Alike 3.0