Unified Modeling Language

Page 1 of 13

UPES

Unified Modeling Language (UML) combines techniques from data modeling (entity relationship diagrams), business

modeling (work flows),object modeling, and component modeling. It can be used with all processes, throughout the software

development life cycle, and across different implementation technologies.

The Unified Modeling Language (UML) offers a standard way to visualize a system's architectural blueprints, including

elements such as:

activities

actors

business processes

database schemas

(logical) components

programming language statements

reusable software components.

UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented

software engineering (OOSE) by fusing them into a single, common and widely usable modeling language. UML aims to be

a standard modeling language which can model concurrent and distributed systems.

UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation

languages. UML is extensible, with two mechanisms for customization: profiles and stereotypes.

History

History of object-oriented methods and notation.

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 highlight of the history of object-oriented modeling methods

and notation.

Before UML 1.x

After Rational Software Corporation hired James Rumbaugh from General Electric in 1994, the company became the source

for two of the most popular object-oriented modeling approaches of the day: Rumbaugh's Object-modeling technique (OMT)

and Grady Booch's method known as Object-oriented design (OOD). They were soon assisted in their efforts by Ivar

Jacobson, the creator of the object-oriented software engineering(OOSE) method. Jacobson joined Rational in 1995, after

his company, Objectory AB, was acquired by Rational. The three methodologists were collectively referred to as the Three

Amigos.

Unified Modeling Language

Page 2 of 13

UPES In 1996, Rational concluded that the abundance of modeling languages was slowing the adoption of object technology, so

repositioning the work on a unified method, they tasked the Three Amigos with the development of a non-proprietary Unified

Modeling Language. Representatives of competing object technology companies were consulted during OOPSLA '96; they

chose boxes for representing classes rather than the cloud symbols that were used in Booch's notation.

Under the technical leadership of the Three Amigos, an international consortium called the UML Partners was organized in

1996 to complete the Unified Modeling Language (UML) specification, and propose it as a response to the OMG RFP. The

UML Partners' UML 1.0 specification draft was proposed to the OMG in January 1997. During the same month the UML

Partners formed a Semantics Task Force, chaired by Cris Kobryn and administered by Ed Eykholt, to finalize the semantics

of the specification and integrate it with other standardization efforts. The result of this work, UML 1.1, was submitted to the

OMG in August 1997 and adopted by the OMG in November 1997.

UML 1.x

As a modeling notation, the influence of the OMT notation dominates (e. g., using rectangles for classes and objects).

Though the Booch "cloud" notation was dropped, the Booch capability to specify lower-level design detail was embraced.

The use case notation from Objectory and the component notation from Booch were integrated with the rest of the notation,

but the semantic integration was relatively weak in UML 1.1, and was not really fixed until the UML 2.0 major revision.

Concepts from many other OO methods were also loosely integrated with UML with the intent that UML would support all

OO methods. Many others also contributed, with their approaches flavouring the many models of the day, including: Tony

Wasserman and Peter Pircher with the "Object-Oriented Structured Design (OOSD)" notation (not a method), Ray Buhr's

"Systems Design with Ada", Archie Bowen's use case and timing analysis, Paul Ward's data analysis and David Harel's

"State charts"; as the group tried to ensure broad coverage in the real-time systems domain. As a result, UML is useful in a

variety of engineering problems, from single process, single user applications to concurrent, distributed systems, making

UML rich but also large.

The Unified Modeling Language is an international standard:

ISO/IEC 19501:2005 Information technology – Open Distributed Processing – Unified Modeling Language (UML)

UML 2.x

UML has matured significantly since UML 1.1. Several minor revisions (UML 1.3, 1.4, and 1.5) fixed shortcomings and bugs

with the first version of UML, followed by the UML 2.0 major revision that was adopted by the OMG in 2005.

Although UML 2.1 was never released as a formal specification, versions 2.1.1 and 2.1.2 appeared in 2007, followed by

UML 2.2 in February 2009. UML 2.3 was formally released in May 2010. UML 2.4.1 was formally released in August

2011. UML 2.5 was released in October 2012 as an "In process" version and has yet to become formally released.

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

1. The Superstructure that defines the notation and semantics for diagrams and their model elements

2. The Infrastructure that defines the core meta model on which the Superstructure is based

3. The Object Constraint Language (OCL) for defining rules for model elements

4. The UML Diagram Interchange that defines 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.

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

compliance with its specifications.

Topics

Software development methods

UML is not a development method by itself; however, it was designed to be compatible with the leading object-oriented

software development methods of its time (for example OMT, Booch method, Object ory). Since UML has evolved, some of

Unified Modeling Language

Page 3 of 13

UPES these methods have been recast to take advantage of the new notations (for example OMT), and new methods have been

created based on UML, such as IBM Rational Unified Process (RUP). Others include Abstraction Method and Dynamic

Systems Development Method.

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 system's model. The model also contains documentation that drives the model elements and diagrams

(such as written use cases).

UML diagrams represent two different views of a system model:

Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and

relationships. The structural view includes class diagrams and composite structure diagrams.

Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects

and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine

diagrams.

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

Diagrams overview

UML diagrams

Structural UML diagrams

Class diagram

Component diagram

Composite structure diagram

Deployment diagram

Object diagram

Package diagram

Profile diagram

Behavioral UML diagrams

Activity diagram

Communication diagram

Interaction overview diagram

Sequence diagram

State diagram

Timing diagram

Use case diagram

UML 2.2 has 14 types of diagrams divided into two categories. Seven diagram types represent structural information, and

the other seven represent general types of behavior, including four that represent different aspects of interactions. These

diagrams can be categorized hierarchically as shown in the following class diagram:

Unified Modeling Language

Page 4 of 13

UPES

UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost

all types of diagrams; this flexibility has been partially restricted in UML 2.0. UML profiles may define additional diagram

types or extend existing diagrams with additional notations.

In keeping with the tradition of engineering drawings,[citation needed] a comment or note explaining usage, constraint, or intent is

allowed in a UML diagram.

Structure diagrams

Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams

represent the structure, they are used extensively in documenting the software architecture of software systems.

Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the

relationships among the classes.

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. The classes in a class diagram represent both the main objects, interactions in the

application and the classes to be programmed.

A class with three sections.

In the diagram, classes are represented with boxes which contain three parts:

The upper part holds the name of the class

The middle part contains the attributes of the class

The bottom part gives the methods or operations the class can take or undertake

In the design of a system, a number of classes are identified and grouped together in a class diagram which helps to

determine the static relations between those objects. With detailed modeling, the classes of the conceptual design are often

split into a number of subclasses.

Unified Modeling Language

Page 5 of 13

UPES Component diagram: describes how a software system is split up into components and shows the dependencies among

these components.

Components are wired together by using an assembly connector to connect the required interface of one component with

the provided interface of another component. This illustrates the service consumer - service provider relationship between

the two components.

An assembly connector is a "connector between two components that defines that one component provides the services that

another component requires. An assembly connector is a connector that is defined from a required interface or port to a

provided interface or port."

When using a component diagram to show the internal structure of a component, the provided and required interfaces of the

encompassing component can delegate to the corresponding interfaces of the contained components.

A delegation connector is a "connector that links the external contract of a component (as specified by its ports) to the

internal realization of that behavior by the component’s parts."

Composite structure diagram: describes the internal structure of a class and the collaborations that this

structure makes possible.

The key composite structure entities identified in the UML 2.0 specification are structured classifiers, parts, ports,

connectors, and collaborations.

Part : A part represents a role played at runtime by one instance of a classifier or by a collection of instances. The part may

only name the role, it may name an abstract superclass, or it may name a specific concrete class. The part can include a

multiplicity factor, such as the [0..*] shown for Viewer in the diagram.

Port : A port is an interaction point that can be used to connect structured classifiers with their parts and with the

environment. Ports can optionally specify the services they provide and the services they require from other parts of the

system. In the diagram, each of the small squares is a port. Each port has a type and is labelled with a name, such as "var",

"indVar1", or "view" in the diagram. Ports may contain a multiplicity factor, for example.

Connector : A connector binds two or more entities together, allowing them to interact at runtime. The connector is shown as

a line between some combination of parts, ports and structured classifiers. The diagram shows three connectors between

ports, and one connector between a structured classifier and a part.

Collaboration : A collaboration is generally more abstract than a structured classifier. It is shown as a dotted oval containing

roles that instances can play in the collaboration.

Structured classifier : A StructuredClassifier represents a class, often an abstract class, whose behavior can be completely

or partially described through interactions between parts.

Deployment diagram: describes the hardware used in system implementations and the execution environments

and artifacts deployed on the hardware.

A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. To

describe a web site, for example, a deployment diagram would show what hardware components ("nodes") exist (e.g., a

web server, an application server, and a database server), what software components ("artifacts") run on each node (e.g.,

web application, database), and how the different pieces are connected (e.g. JDBC, REST, RMI).

The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within the boxes. Nodes may

have subnodes, which appear as nested boxes. A single node in a deployment diagram may conceptually represent multiple

physical nodes, such as a cluster of database servers.

There are two types of Nodes .

Unified Modeling Language

Page 6 of 13

UPES 1. Device Node

2. Execution Environment Node

Device nodes are physically computing resources with processing memory and services to execute software, such as typical

computer or mobile phones. An execution environment node (EEN) is a software computing resource that runs within an

outer node and which itself provides a service to host and execute other executable software elements.

Object diagram: shows a complete or partial view of the structure of an example modeled system at a specific time.

Object diagrams are derived from class diagrams so object diagrams are dependent upon class diagrams.

Object diagrams represent an instance of a class diagram. The basic concepts are similar for class diagrams and object diagrams. Object diagrams also represent the static view of a system but this static view is a snapshot of the system at a particular moment.

Object diagrams are used to render a set of objects and their relationships as an instance.

Purpose:

The purpose of a diagram should be understood clearly to implement it practically. The purposes of object diagrams are similar to class diagrams.

The difference is that a class diagram represents an abstract model consisting of classes and their relationships. But an object diagram represents an instance at a particular moment which is concrete in nature.

It means the object diagram is more close to the actual system behaviour. The purpose is to capture the static view of a system at a particular moment.

So the purpose of the object diagram can be summarized as:

Forward and reverse engineering.

Object relationships of a system

Static view of an interaction.

Understand object behaviour and their relationship from practical perspective

How to draw Object Diagram?

An object diagram is an instance of a class diagram. It implies that an object diagram consists of instances of things used in a class diagram.

So both diagrams are made of same basic elements but in different form. In class diagram elements are in abstract form to represent the blue print and in object diagram the elements are in concrete form to represent the real world object.

To capture a particular system, numbers of class diagrams are limited. But if we consider object diagrams then we can have unlimited number of instances which are unique in nature. So only those instances are considered which are having impact on the system.

From the above discussion it is clear that a single object diagram cannot capture all the necessary instances or rather cannot specify all objects of a system. So the solution is:

First, analyze the system and decide which instances are having important data and association.

Second, consider only those instances which will cover the functionality.

Third, make some optimization as the numbers of instances are unlimited.

Before drawing an object diagrams the following things should be remembered and understood clearly:

Unified Modeling Language

Page 7 of 13

UPES Object diagrams are consist of objects.

The link in object diagram is used to connect objects.

Objects and links are the two elements used to construct an object diagram.

Now after this the following things are to be decided before starting the construction of the diagram:

The object diagram should have a meaningful name to indicate its purpose.

The most important elements are to be identified.

The association among objects should be clarified.

Values of different elements need to be captured to include in the object diagram.

Add proper notes at points where more clarity is required.

The following diagram is an example of an object diagram. It represents the Order management system which we have discussed in Class Diagram. The following diagram is an instance of the system at a particular time of purchase. It has the following objects

Customer

Order

SpecialOrder

NormalOrder

Now the customer object (C) is associated with three order objects (O1, O2 and O3). These order objects are associated with special order and normal order objects (S1, S2 and N1). The customer is having the following three orders with different numbers (12, 32 and 40) for the particular time considered.

Now the customer can increase number of orders in future and in that scenario the object diagram will reflect that. If order, special order and normal order objects are observed then we you will find that they are having some values.

For orders the values are 12, 32, and 40 which implies that the objects are having these values for the particular moment (here the particular time when the purchase is made is considered as the moment) when the instance is captured.

The same is for special order and normal order objects which are having number of orders as 20, 30 and 60. If a different time of purchase is considered then these values will change accordingly.

So the following object diagram has been drawn considering all the points mentioned above:

Package diagram: describes how a system is split up into logical groupings by showing the dependencies among

these groupings.

Unified Modeling Language

Page 8 of 13

UPES

Package diagram visualizes packages and depicts the dependency, import, access, generalization, realization

and merge relationships between them. Package diagram enables you to gain a high level understanding of the

collaboration among model elements through analyzing the relationships among their parent package. This

also helps explain the system's architecture from a broad view.

Here are some of the notations you can use in package diagram.

Notation Description

Package Represents a group of model elements and/or diagrams.

Subsystem A system that is part of a large scale system.

Dependency

When a package (e.g. client) requires another (e.g. supplier) for specification or

implementation, a dependency would be established to model that. Dependency can also

be found among model elements contained in packages.

Import

A relationship that shows the model elements in a package which are to be imported from

another package. It allows a package to refer to a model element in another package

without qualification.

Access Model elements in a package that can be used by the model elements in another package

but cannot be further imported from that package.

Generalization A relationship that shows a package inheriting from another by sharing its properties and

adding its own properties to produce a package with more specific specification.

Unified Modeling Language

Page 9 of 13

UPES

Realization An abstraction relationship between two packages showing that the supplier package

provides specification while the client package implements it.

Merge

A relationship between two packages showing that their contents are to be combined.

This should be used when elements in packages have the same name and represent the

same concept.

Profile diagram: operates at the meta model level to show stereotypes as classes with the <<stereotype>> stereotype, and

profiles as packages with the <<profile>> stereotype. The extension relation (solid line with closed, filled arrowhead)

indicates what meta model element a given stereotype is extending.

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.

Activity diagram: describes the business and operational step-by-step workflows of components in a system. An activity

diagram shows the overall flow of control.

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice,

iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to describe the business and

operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.

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

rounded rectangles represent actions;

diamonds represent decisions;

bars represent the start (split) or end (join) of concurrent activities;

a black circle represents the start (initial state) of the workflow;

an encircled black circle represents the end (final state).

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

Hence they can be regarded as a form of flowchart. Typical flowchart techniques lack constructs for expressing concurrency.

However, the join and split symbols in activity diagrams only resolve this for simple cases; the meaning of the model is not

clear when they are arbitrarily combined with decisions or loops.

An example of activity diagram for online shopping. Online customer can browse or search items, view

specific item, add it to shopping cart, view and update shopping cart, checkout. User can view shopping cart at

any time. Checkout is assumed to include user registration and login.

This example is not using partitions, most of the actions are assumed to be fulfilled by online customer.

Unified Modeling Language

Page 10 of 13

UPES

An example of activity diagram for online shopping.

UML state machine diagram: describes the states and state transitions of the system.

Use Case Diagram: describes the functionality provided by a system in terms of actors, their goals represented as use

cases, and any dependencies among those use cases.

Interaction diagrams

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system

being modeled:

From the name Interaction it is clear that the diagram is used to describe some type of interactions among the different elements in the model. So this interaction is a part of dynamic behaviour of the system.

This interactive behaviour is represented in UML by two diagrams known as Sequence diagramand Collaboration diagram. The basic purposes of both the diagrams are similar.

Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on the structural organization of the objects that send and receive messages.

Purpose:

The purposes of interaction diagrams are to visualize the interactive behaviour of the system. Now visualizing interaction is a difficult task. So the solution is to use different types of models to capture the different aspects of the interaction.

That is why sequence and collaboration diagrams are used to capture dynamic nature but from a different angle.

So the purposes of interaction diagram can be describes as:

Unified Modeling Language

Page 11 of 13

UPES To capture dynamic behaviour of a system.

To describe the message flow in the system.

To describe structural organization of the objects.

To describe interaction among objects.

How to draw Interaction Diagram?

As we have already discussed that the purpose of interaction diagrams are to capture the dynamic aspect of a system. So to capture the dynamic aspect we need to understand what a dynamic aspect is and how it is visualized. Dynamic aspect can be defined as the snap shot of the running system at a particular moment.

We have two types of interaction diagrams in UML. One is sequence diagram and the other is a collaboration diagram. The sequence diagram captures the time sequence of message flow from one object to another and the collaboration diagram describes the organization of objects in a system taking part in the message flow.

So the following things are to identified clearly before drawing the interaction diagram:

Objects taking part in the interaction.

Message flows among the objects.

The sequence in which the messages are flowing.

Object organization.

Following are two interaction diagrams modeling order management system. The first diagram is a sequence diagram and the second is a collaboration diagram.

The Sequence Diagram:

The sequence diagram is having four objects (Customer, Order, SpecialOrder and NormalOrder).

The following diagram has shown the message sequence for SpecialOrder object and the same can be used in case of NormalOrder object. Now it is important to understand the time sequence of message flows. The message flow is nothing but a method call of an object.

The first call is sendOrder () which is a method of Order object. The next call is confirm () which is a method of SpecialOrder object and the last call is Dispatch () which is a method ofSpecialOrder object. So here the diagram is mainly describing the method calls from one object to another and this is also the actual scenario when the system is running.

Unified Modeling Language

Page 12 of 13

UPES The Collaboration Diagram:

The second interaction diagram is collaboration diagram. It shows the object organization as shown below. Here in collaboration diagram the method call sequence is indicated by some numbering technique as shown below. The number indicates how the methods are called one after another. We have taken the same order management system to describe the collaboration diagram.

The method calls are similar to that of a sequence diagram. But the difference is that the sequence diagram does not describe the object organization where as the collaboration diagram shows the object organization.

Now to choose between these two diagrams the main emphasis is given on the type of requirement. If the time sequence is important then sequence diagram is used and if organization is required then collaboration diagram is used.

Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent

a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and

dynamic behavior of a system.

A Communication diagram models the interactions between objects or parts in terms of sequenced messages.

Communication diagrams represent a combination of information taken from Class, Sequence, and Use Case

Diagrams describing both the static structure and dynamic behavior of a system.

However, communication diagrams use the free-form arrangement of objects and links as used in Object diagrams. In order

to maintain the ordering of messages in such a free-form diagram, messages are labeled with a chronological number and

placed near the link the message is sent over. Reading a communication diagram involves starting at message 1.0, and

following the messages from object to object.

Communication diagrams show a lot of the same information as sequence diagrams, but because of how the information is

presented, some of it is easier to find in one diagram than the other. Communication diagrams show which elements each

one interacts with better, but sequence diagrams show the order in which the interactions take place more clearly.

Interaction overview diagram: provides an overview in which the nodes represent communication diagrams.

Interaction Overview Diagram is one of the fourteen types ofdiagrams of the Unified Modeling Language (UML),

which can picture a control flow with nodes that can contain interaction diagrams.[1]

Unified Modeling Language

Page 13 of 13

UPES The interaction overview diagram is similar to the activity diagram both visualizing a sequence of activities. The difference is

that the individual activity in the interaction overview diagram is pictured as a frame, which can contain interaction -

or sequence diagrams. These interaction/sequence diagrams are constructed with building blocks

like: sequence, communication, interaction overview and timing diagram. The nodes in the diagram connect these sequence

diagrams, which can be place in a specific order. With these elements the interaction overview diagram can be used to

"deconstruct a complex scenario that would otherwise require multiple if-then-else paths to be illustrated as a single

sequence diagram".

Except for the activity nodes the other notation elements for interaction overview diagrams are the same as for activity

diagrams, such as initial, final, decision, merge, fork and join nodes. The two new elements in the interaction overview

diagrams are the "interaction occurrences" and "interaction elements"

Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates

the life spans of objects relative to those messages.

Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints.

Timing diagrams are used to explore the behaviors of objects throughout a given period of time. A timing diagram is a

special form of a sequence diagram. The differences between timing diagram and sequence diagram are the axes are

reversed so that the time is increased from left to right and the lifelines are shown in separate compartments arranged

vertically.

There are two basic flavors of timing diagram: the concise notation, and the robust notation

The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication

protocols.

The Object Management Group (OMG) has developed a meta modeling architecture to define the Unified Modeling

Language (UML), called the Meta-Object Facility (MOF).[16] 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 meta models, called M2-models.

The most prominent example of a Layer 2 Meta-Object Facility model is the UML meta model, the model that describes the

UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example,

models written in UML. The last layer is the M0-layer or data layer. It is used to describe runtime instance of the system.

Beyond the M3-model, the Meta-Object Facility describes the means to create and manipulate models and meta models by

defining Common Object Request Broker Architecture (CORBA) interfaces that describe those operations. Because of the

similarities between the Meta-Object Facility M0-model and UML structure models, Meta-Object Facility meta models are

usually modeled as UML class diagrams. A supporting standard of the Meta-Object Facility is XMI, which defines an XML-

based exchange format for models on the M3-, M2-, or M1-Layer.