Unified Modeling Language

Contents

1 Unied Modeling Language 11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Before UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.3 UML 2.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Design/Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.1 Software development methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.2 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.3 Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.4 Meta modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Criticisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.1 Critique of UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.8 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Class diagram 92.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 Instance level relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Class level relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 General relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.4 Multiplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Analysis stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.1 Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

i

ii CONTENTS

2.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Object diagram 163.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Object diagram topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Instance specications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.2 Object diagram example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Use Case Diagram 194.1 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Interaction overview diagram 215.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Sequence diagram 236.1 Diagram building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.4 Text and image sources, contributors, and licenses . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.4.1 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.4.2 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.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 engineer-ing, 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 during199495, 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 thisorganization ever since. In 2005 the UniedModeling Language was also published by the International Organizationfor Standardization (ISO) as an approved ISO standard.[2] Since then it has been periodically revised to cover the latestrevision of UML.[3]

1

2 CHAPTER 1. UNIFIED MODELING LANGUAGE

A collage of UML diagrams

1.1 OverviewThe Unied Modeling Language (UML) oers a way to visualize a systems architectural blueprints in a diagram (seeimage), 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 UniedModeling Language (UML)has been extended to cover a larger set of design documentation (as listed above),[5] and been found useful in manycontexts.[6]

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

1.2. HISTORY 3

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 companybecame the source for two of the most popular object-oriented modeling approaches of the day:[7] RumbaughsObject-modeling technique (OMT) and Grady Booch's method. They were soon assisted in their eorts by IvarJacobson, the creator of the object-oriented software engineering (OOSE) method, who joined them at Rational in1995.[1]

Under the technical leadership of those three (Rumbaugh, Jacobson and Booch), a consortium called the UMLPartners was organized in 1996 to complete the Unied Modeling Language (UML) specication, and propose itto the Object Management Group (OMG) for standardisation. The partnership also contained additional interestedparties (for example HP, DEC, IBM and Microsoft). The UML Partners UML 1.0 draft was proposed to the OMGin January 1997 by the consortium. During the same month the UML Partners formed a group, designed to denethe exact meaning of language constructs, chaired by Cris Kobryn and administered by Ed Eykholt, to nalize thespecication and integrate it with other standardization eorts. The result of this work, UML 1.1, was submitted tothe 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 toimprove the language further to reect new experience on usage of its features.[12]


Although UML 2.1 was never released as a formal specication, versions 2.1.1 and 2.1.2 appeared in 2007, followedby UML 2.2 in February 2009. UML 2.3 was formally released in May 2010.[13] UML 2.4.1 was formally releasedin August 2011.[13] UML 2.5 was released in October 2012 as an In process version and has yet to become formallyreleased.[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 elements2. The Infrastructure that denes the core metamodel on which the Superstructure is based3. The Object Constraint Language (OCL) for dening rules for model elements4. 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 therevision task force, who resolve any issues with the language.[15]

1.3 Design/Usage

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

1.3.2 ModelingIt is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partialgraphic representation of a systems model. The set of diagrams need not completely cover the model and deleting adiagram does not change the model. The model may also contain documentation that drives the model elements anddiagrams (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, operationsand relationships. The structural view includes class diagrams and composite structure diagrams.

Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborationsamong objects and changes to the internal states of objects. This view includes sequence diagrams, activitydiagrams and state machine diagrams.

UML models can be exchanged among UML tools by using the XML Metadata Interchange (XMI) interchangeformat.

1.3.3 DiagramsUML 2 has many types of diagrams which are divided into two categories.[4] Some types represent structural informa-tion, 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 diagramsrepresent the structure, they are used extensively in documenting the software architecture of software systems. Forexample, the component diagram which describes how a software system is split up into components and shows thedependencies among these components.

1.3. DESIGN/USAGE 5

Diagram

StructureDiagram

Behaviour-Diagram

ClassDiagram

Component-Diagram

ObjectDiagram

ActivityDiagram

Use CaseDiagram

ProleDiagram

Composite-StrukturDiagram

DeploymentDiagram

PackageDiagram

InteractionDiagram

StateMachineDiagram

SequenceDiagram

CommunicationDiagram

InteractionOverviewdiagramm

TimingDiagramNotation: UML

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 thebehavior of a system, they are used extensively to describe the functionality of software systems. As an example, theactivity 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 thesystem being modeled. For example, the sequence diagram which shows how objects communicate with each otherin terms of a sequence of messages.

Component diagram Activity diagram Sequence diagram Class diagram Use Case Diagram Communication diagram

1.3.4 Meta modelingMain article: Meta-Object FacilityThe Object Management Group (OMG) has developed a metamodeling architecture to dene the Unied ModelingLanguage (UML), called the Meta-Object Facility (MOF).[18] The Meta-Object Facility is designed as a four-layeredarchitecture, as shown in the image at right. It provides a meta-meta model at the top layer, called the M3 layer. ThisM3-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 thatdescribes the UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These wouldbe, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe runtimeinstances of the system.[19]


Illustration of the Meta-Object Facility

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

1.4 AdoptionUML 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 includesexcessive usage of it (design every little part of the systems code with it, which is unnecessary) and assuming thatanyone 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 manyand that this hinders the learning (and therefore usage) of it.[23]

1.5 Criticisms

1.5.1 Critique of UML 1.xCardinality 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 diagramsis less eective and less coherent when applied to n-ary relationships of order >2.

1.6. SEE ALSO 7

In Feinerer it says Problems arise if we operate under the look-across semantics as used for UMLassociations. Hartmann[29] investigates this situation and shows how and why dierent transformationsfail. (Although the reduction mentioned is spurious as the two diagrams 3.4 and 3.5 are in fact thesame) and also As we will see on the next few pages, the look-across interpretation introduces severaldiculties 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 ReferencesThis article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008and 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 samplecontent, 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 UniedModeling Language (OMGUML)- 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. Retrieved9 April 2014.

[5] Satish Mishra (1997). Visual Modeling &UniedModeling Language (UML) : Introduction to UML. Rational SoftwareCorporation. 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. ISBN1-85233-275-1. p.5.door

[17] Jon Holt Institution of Electrical Engineers (2004). UML for Systems Engineering: Watching the Wheels IET, 2004, ISBN0-86341-354-4. p.58

[18] Iman Poernomo (2006) "TheMeta-Object Facility Typed" in: Proceeding SAC '06 Proceedings of the 2006 ACM symposiumon Applied computing. pp. 1845-1849


[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). Re-trieved 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. CambridgeUniversity Press. ISBN 0-521-54018-6.

Chonoles, Michael Jesse; James A. Schardt (2003). UML 2 for Dummies. Wiley Publishing. ISBN 0-7645-2614-6.

Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd ed.). Addison-Wesley. ISBN 0-321-19368-7.

Jacobson, Ivar; Grady Booch; James Rumbaugh (1998). The Unied Software Development Process. AddisonWesley 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-471-29551-5.

1.9 External links Ocial website

Chapter 2

Class diagram

Diagram

StructureDiagram

BehaviourDiagram

Class Diagram ComponentDiagramObject

DiagramActivityDiagram

Use CaseDiagram

State MachineDiagram

CompositeStructureDiagram

DeploymentDiagram

PackageDiagram

InteractionDiagram

SequenceDiagram

InteractionOverviewDiagram

CommunicationDiagram

TimingDiagram

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

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

2.1 IntroductionThe class diagram is the main building block of object oriented modelling. It is used both for general conceptualmodelling of the systematics of the application, and for detailed modelling translating the models into programmingcode. Class diagrams can also be used for data modeling.[1] The classes in a class diagram represent both the mainobjects, 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 islowercase.

9

10 CHAPTER 2. CLASS DIAGRAM

BankAccount

owner : Stringbalance : 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 todetermine the static relations between those objects. With detailed modelling, the classes of the conceptual designare 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 diagramor UML state machine.[2]

2.2 MembersUML provides mechanisms to represent class members, such as attributes and methods, and additional informationabout them.

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

2.2.2 ScopesThe UML species two types of scope for members: instance and classier and these last are represented by under-lined names.[4]

Classier members are commonly recognized as static in many programming languages. The scope is theclass 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 bydefault.

2.3. RELATIONSHIPS 11

2.3 RelationshipsA 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. Anassociation 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 ag-gregation) 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 relation-ship shared among the objects of two classes.

Aggregation

1..*1Professor

+ listOfStudents : list

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 anassociation that represents a part-whole or part-of relationship. As shown in the image, a Professor 'has a' class toteach. 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 havea strong lifecycle dependency on the container. The contents of the container are not automatically destroyed whenthe container is.In UML, it is graphically represented as a hollow diamond shape on the containing class with a single line that connectsit 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.


Car Carburetor0..1 1..1

0..1 0..*Pond 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 thecontained class(es): if the container is destroyed, normally every instance that it contains is destroyed as well. (Notethat, where allowed, a part can be removed from a composite before the composite is deleted, and thus not be deletedas part of the composite.)The UML graphical representation of a composition relationship is a lled diamond shape on the containing classend 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 partof a car.Aggregation relationship : When representing a software or database relationship, e.g., car model engine ENG01 ispart 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 con-tainment.

2.3.2 Class level relationshipsGeneralization

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 bea 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 ofgeneralizations of this form is found in biological classication: human beings are a subclass of simian, which are asubclass of mammal, and so on. The relationship is most easily understood by the phrase 'an A is a B' (a human is amammal, a mammal is an animal).The UML graphical representation of a Generalization is a hollow triangle shape on the superclass end of the line (ortree 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, orbase type.The subtype in the specialization relationship is also known as the child, subclass, derived class, derived type, inher-iting class, or inheriting type.Note that this relationship bears no resemblance to the biological parent/child relationship: the use of these terms isextremely common, but can be misleading.

Generalization-Specialization relationship

A is a type of BE. 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 ele-ment (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 ofthe 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 elementwith a supplier element. A realization relationship between classes and interfaces and between components andinterfaces shows that the class realizes the operations oered by the interface.

2.3.3 General relationshipDependency

Dependency is a weaker form of bond which indicates that one class depends on another because it uses it at somepoint in time. One class depends on another if the independent class is a parameter variable or local variable of amethod of the dependent class. This is dierent from an association, where an attribute of the dependent class isan instance of the independent class. Sometimes the relationship between two classes is very weak. They are notimplemented with member variables at all. Rather they might be implemented as member function arguments.

2.3.4 MultiplicityThis association relationship indicates that (at least) one of the two related classes make reference to the other. Thisrelationship 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) inthe relationship, and an optional notation at each end indicating themultiplicity of instances of that entity (the numberof objects that participate in the association).


Class diagram showing dependency between Car class and Wheel class (An even clearer example would be Car depends onWheel, 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 ofthe system. Classes at this stage often take the form of boundaries, controls and entities and rarely survive into thedesign without heavy changes.

2.4.1 Entities

Entity classes model the information handled by the system, and sometimes the behavior associated with the infor-mation. 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 asnormal 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 viewof the structure of a modeled system at a specic time.

3.1 OverviewIn the UniedModeling 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 viewof 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 isan instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. Theuse 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 aremeantto visualize static structure of a system. While class diagrams show classes, object diagrams displays instances ofclasses (objects).[6] Object diagrams are more concrete than class diagrams. They are often used to provide examplesor act as test cases for class diagrams. Only aspects of current interest in a model are typically shown on an objectdiagram.

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 objectsclassier (e.g. an abstract or concrete class) and instance name, as well as attributes and other structural featuresusing 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 moreclassier names separated by commas. The contents of slots, if any, are included below the names, in a separateattribute 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, hasIndependentVariable as its classier, plays the NMinus2 role within the FibonacciSystem, and has a slot for the valattribute with a value of 0. The second object is named v2, is of class IndependentVariable, plays the NMinus1role, and has val = 1. The DependentVariable object is named v3, and plays the N role. The topmost instance, ananonymous instance specication, has FibonacciFunction as its classier, and may have an instance name, a role, andslots, but these are not shown here. The diagram also includes three named links, shown as lines. Links are instancesof 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 arethe 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 UsageIf you are using a UML modeling tool, you will typically draw object diagrams using some other diagram type, suchas on a class diagram. An object instance may be called an instance specication or just an instance. A link betweeninstances is generally referred to as a link. Other UML entities, such as an aggregation or composition symbol (adiamond) 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 In-stanceSpecication.

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 CasesSystem Boundary

OrderFood

CookFood

OrderWine

ServeFood

ServeWine

EatFood

DrinkWine

Pay forFood

Pay forWine

Waiter

Chef

Client

Cashier

receive order

conrm order

facilitate payment

pay

accept payment

place order

{if wine was ordered}

{if wine

was served}

{if wine

was consumed}

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 relationshipbetween the user and the dierent use cases in which the user is involved. A use case diagram can identify the dierenttypes 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 understandingfrom the picture, Journal of Database Management, 20(1), 1-24.

Jacobson, I., Christerson M., Jonsson P., vergaard G., (1992). Object-Oriented Software Engineering - A UseCase Driven Approach, Addison-Wesley.

Kawabata, R., Kasah, K. (2007). Systems Analysis for Collaborative System by Use Case Diagram, Journalof 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? Anexperimental 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 & ControlEngineering, 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 anested interaction diagrams. This makes the interaction overview diagram useful to deconstruct a complex scenariothat 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 includeinitial, nal, decision, merge, fork and join nodes. The two new elements in the interaction overview diagrams arethe 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

:User :AccessControlSystem

enter codecheck code

[code OK]

ref Release doorfor one access

[code not OK]

Interaction overview diagram

Chapter 6

Sequence diagram

checkEmail

:Computer :Server

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 theirorder. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged intime 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 associatedwith use case realizations in the Logical View of the system under development. Sequence diagrams are sometimescalled 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 thespecication of simple runtime scenarios in a graphical manner.

6.1 Diagram building blocksIf the lifeline is that of an object, it demonstrates a role. Leaving the instance name blank can represent anonymousand unnamed instances.Messages, written with horizontal arrows with the message name written above them, display interaction. Solid arrowheads represent synchronous calls, open arrow heads represent asynchronous messages, and dashed lines representreply messages.[1] If a caller sends a synchronous message, it must wait until the message is done, such as invokinga subroutine. If a caller sends an asynchronous message, it can continue processing and doesnt have to wait for aresponse. Asynchronous calls are present in multithreaded applications and in message-oriented middleware. Acti-vation boxes, or method-call boxes, are opaque rectangles drawn on top of lifelines to represent that processes arebeing 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 afurther level of processing.When an object is destroyed (removed from memory), an X is drawn on top of the lifeline, and the dashed line ceasesto be drawn below it (this is not the case in the rst example though). It should be the result of a message, either fromthe object itself, or another.A message sent from outside the diagram can be represented by a message originating from a lled-in circle (foundmessage 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 improve-ments 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 tomodel 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 licenses6.4.1 Text

UniedModeling Language Source: http://en.wikipedia.org/wiki/Unified%20Modeling%20Language?oldid=662422302Contributors: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, Andrew-man327, 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, SarekOfVul-can, 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, Cdig-gins, Lt-wiki-bot, Closedmouth, Abune, JLaTondre, Allens, Mardus, CrniBombarder!!!, Arnabbh, That Guy, From That Show!, Gpar-ent, SmackBot, Lashiec, FishSpeaker, Slashme, Andres Agudelo, Hydrogen Iodide, Vardhanw, Deon Steyn, KocjoBot~enwiki, BrickThrower, 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, Nix-eagle, Cathness~enwiki, BarryNorton, Seattlenow, Allan McInnes, JustAnotherJoe, MichaelBillington, Clarepawling, Maximumbrown-idge, 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, Dv-drtrgn, Doral, MicahDCochran, Pmerson, Kenneth Vergil, Steven Kelly, Gregbard, MDE, Fl, Af1n, Luckyherb, OVERM1ND, Pin-dakaas, Mrockman, Malleus Fatuorum, Thijs!bot, Nagarjunag, Kilva, Hervegirod, QVT, Kataniza, Tellyaddict, Philippe, Xactium, Es-carbot, KrakatoaKatie, Dhbernstein, AntiVandalBot, Hpetya, Zappernapper, Kishorekumar 62, Yellowdesk, Alphachimpbot, Progdev,Myguest, MME, Jrutley, Krishvanth, Ppelleti, Bob22232, Emerks, Naayagan, Jdmarshall, Toddfast, Yakushima, Loqi, EPHERE, Der-Hexer, 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, Franck-Barbier, 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, DumZ-iBoT, 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, Fo-tomut, 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 mod-eler, 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, Timo-thyclethbridge, Satellizer, Richard-VS-545, Kadamwiki, Danim, Helpful Pixie Bot, Kronn8, BG19bot, , Leg-gattst, Karategeek6, MusikAnimal, Harshadsamant, Cncmaster, Tawaregs08.it, Joydeep, Manu31415, Jorgjimen, Zanemoody, NashrulHakiem, 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, Ho-hohoneysingh, 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, ChuunenBaka, 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, De-Piep, 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, JoeLennon~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, Magiola-ditis, Wikidudeman, JamesBWatson, Gregly, Cpl Syx, Ronbarak, JaGa, Touriste (usurped), Infrangible, J.delanoy, Pharaoh of the Wiz-ards, 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 WSmith, 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, Red-Bot, 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=636154282Contributors: Quadell, MikeGleason,Mdd,Dionyziz, DePiep, Salix alba, Stephenb, Qualc1, TomMorris, SmackBot, IanVaughan, Brick Thrower, Ohnoitsjamie, Cydebot, Thijs!bot,VictorAnyakin, KenSWebb, VolkovBot, Deconstructhis, Yintan, Denisarona, Sfan00 IMG, Sun Creator, BOTarate, Thehelpfulone, Myst-Bot, Addbot, Dawynn, AnomieBOT, Materialscientist, Mark Renier, Sae1962, EmausBot, RaptureBot, ClueBot NG, BG19bot, Avoca-toBot and Anonymous: 28

Use Case Diagram Source: http://en.wikipedia.org/wiki/Use%20Case%20Diagram?oldid=658803408 Contributors: Bearcat, Mdd, Bg-white, Chris the speller, DStoykov, Technopat, Flyer22, Trustable, Addbot, Mortense, Download, Materialscientist, A.amitkumar, Red-Bot, 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 Contrib-utors: 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, Nel-son.cruz, Rror, SilvonenBot, Addbot, Dawynn, MrOllie, AndersBot, SpBot, Technoparkcorp, Yobot, Kingpin13, Materialscientist, Srini-vas, 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, MrLinkin-Park333, Tunestig and Anonymous: 189

6.4.2 Images File:AggregationAndComposition.svg Source: http://upload.wikimedia.org/wikipedia/en/9/9f/AggregationAndComposition.svg Li-

cense: PD Contributors:en.wikipedia.orgOriginal 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 Contribu-tors: 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 Contrib-utors: 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 BY3.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: ? Origi-nal 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-by-sa-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: Ownwork 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, 2009Original 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: Publicdomain 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-BY-SA-3.0 Contributors: Transferred from en.wikipediaOwn 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.pngLicense: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 domainContributors: 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.0Contributors: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-SA-3.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 Li-cense: Public domain Contributors: This le was derived from: Uml diagram2.pngOriginal 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.gifOrig-inal artist: ?

File:UML_role_example.gif Source: http://upload.wikimedia.org/wikipedia/commons/4/4d/UML_role_example.gif License: CC-BY-SA-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 BY-SA 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 Con-tributors: Ownwork (original was hereOriginal artist: Dave A Ryan

File:Unbalanced_scales.svg Source: http://upload.wikimedia.org/wikipedia/commons/f/fe/Unbalanced_scales.svg License: Public do-main Contributors: ? Original artist: ?

File:Use_case_restaurant_model.svg Source: http://upload.wikimedia.org/wikipedia/commons/1/1d/Use_case_restaurant_model.svgLicense: CC BY-SA 3.0 Contributors: Own work, redrawn of w:File:Restaurant Model.png Original artist: Kishorekumar 62 (redrawn byMarcel Douwe Dekker)

File:Wikiversity-logo.svg Source: http://upload.wikimedia.org/wikipedia/commons/9/91/Wikiversity-logo.svg License: CC BY-SA3.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

Unified Modeling LanguageOverview History Before UML 1.x UML 1.x UML 2.x

Design/Usage Software development methods Modeling Diagrams Meta modeling

Adoption Criticisms Critique of UML 1.x

See also References Further reading External links

Class diagramIntroduction Members Visibility Scopes

Relationships Instance level relationships Class level relationships General relationship Multiplicity

Analysis stereotypes Entities

See also References External links

Object diagramOverview Object diagram topicsInstance specificationsObject diagram exampleUsage

ReferencesExternal links

Use Case DiagramSee also References Bibliography

Interaction overview diagramReferences External links

Sequence diagramDiagram building blocks References External links Text and image sources, contributors, and licensesTextImagesContent license

Unified Modeling Language

Documents

Transcript of Unified Modeling Language