UNIFIED MODELING LANGUAGE (UML)

UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts
of software systems.

UML was created by Object Management Group (OMG) and UML 1.0 specification draft was
proposed to the OMG in January 1997.

OMG is continuously putting effort to make a truly industry standard.

• UML stands for Unified Modeling Language.

• UML is different from the other common programming languages like C++, Java, COBOL
etc.
• UML is a pictorial language used to make software blue prints.

So UML can be described as a general purpose visual modeling language to visualize, specify,
construct and document software system. Although UML is generally used to model software
systems but it is not limited within this boundary. It is also used to model non software systems as
well like process flow in a manufacturing unit etc.

UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams. UML has a direct relation with object oriented analysis and design. After some
standardization UML is become an OMG (Object Management Group) standard.

UML describes the real time systems. It is used to make a conceptual model. Conceptual model of
UML can be mastered by learning the following three major elements:

• UML building blocks

• Rules to connect the building blocks
• Common mechanisms of UML

The building blocks of UML can be defined as:

• Things
• Relationships
• Diagrams

(1) Things:
Things are the most important building blocks of UML. Things can be:

• Structural
• Behavioral
• Grouping
• Annotational

Structural things:
The Structural things define the static part of the model. They represent physical and conceptual
elements. Following are the brief descriptions of the structural things.

Class:

Class represents set of objects having similar responsibilities.

Interface:

Interface defines a set of operations which specify the responsibility of a class.

Collaboration:

Collaboration defines interaction between elements.

Use case:

Use case represents a set of actions performed by a system for a specific goal.

Component:

Component describes physical part of a system.

Node:

A node can be defined as a physical element that exists at run time.

Behavioral things:

A behavioral thing consists of the dynamic parts of UML models. Following are the
behavioral things:

Interaction: Interaction is defined as a behavior that consists of a group of messages exchanged

among elements to accomplish a specific task.
State machine:

State machine is useful when the state of an object in its life cycle is important. It defines the
sequence of states an object goes through in response to events. Events are external factors
responsible for state change.

Grouping things:
Grouping things can be defined as a mechanism to group elements of a UML model together.
There is only one grouping thing available:

Package:

Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things:
Annotational things can be defined as a mechanism to capture remarks, descriptions, and
comments of UML model elements. Note is the only one Annotational thing available.

Note:

A note is used to render comments, constraints etc of an UML element.

(2) Relationship:
Relationship is another most important building block of UML. It shows how elements are
associated with each other and this association describes the functionality of an application.

There are four kinds of relationships available.

Dependency:

Dependency is a relationship between two things in which change in one element also affects the
other one.
Association:

Association is basically a set of links that connects elements of an UML model. It also describes how
many objects are taking part in that relationship.

Generalization:

Generalization can be defined as a relationship which connects a specialized element with a

generalized element. It basically describes inheritance relationship in the world of objects.

Realization:

Realization can be defined as a relationship in which two elements are connected. One element
describes some responsibility which is not implemented and the other one implements them. This
relationship exists in case of interfaces.

(3) UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are
used to make a complete UML diagram and the diagram represents a system.

The visual effect of the UML diagram is the most important part of the entire process. All the other
elements are used to make it a complete one.

UML includes the following nine diagrams and the details are described in the following chapters.

1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Activity diagram
7. Statechart diagram
8. Deployment diagram
9. Component diagram

There are three classifications of UML diagrams:

• Behavior diagrams. A type of diagram that depicts behavioral features of a system or

business process. This includes activity, state machine, and use case diagrams as well
as the four interaction diagrams.
• Interaction diagrams. A subset of behavior diagrams which emphasize object
interactions. This includes communication, interaction overview, sequence, and timing
diagrams.
 • Structure diagrams. A type of diagram that depicts the elements of a specification that
are irrespective of time. This includes class, composite structure, component,
deployment, object, and package diagrams.

Table summarizes the thirteen, up from nine in UML 1.x, diagram types of UML 2.x. In the
diagram column the links will take you to description pages for the artifact. The learning priority
column indicates how important it is for a business application developer to learn the artifact
(IMHO).

The diagrams of UML

Diagram Description Learning

Priority
Activity Diagram Depicts high-level business processes, including data flow, or to High
model the logic of complex logic within a system.
Class Diagram Shows a collection of static model elements such as classes and types, High
their contents, and their relationships.
Communication Shows instances of classes, their interrelationships, and the message Low
Diagram flow between them. Communication diagrams typically focus on the
structural organization of objects that send and receive messages.
Formerly called a Collaboration Diagram.
Component Depicts the components that compose an application, system, or Medium
Diagram enterprise. The components, their interrelationships, interactions, and
their public interfaces are depicted. .
Composite Depicts the internal structure of a classifier (such as a class, Low
Structure Diagram component, or use case), including the interaction points of the
classifier to other parts of the system.
Deployment Shows the execution architecture of systems. This includes nodes, Medium
Diagram either hardware or software execution environments, as well as the
middleware connecting them.
Interaction A variant of an activity diagram which overviews the control flow Low
Overview Diagram within a system or business process. Each node/activity within the
diagram can represent another interaction diagram.
Object Diagram Depicts objects and their relationships at a point in time, typically a Low
special case of either a class diagram or a communication diagram.
Package Diagram Shows how model elements are organized into packages as well as theLow
dependencies between packages.
Sequence Diagram Models the sequential logic, in effect the time ordering of messages High
between classifiers.
State Machine Describes the states an object or interaction may be in, as well as the Medium
Diagram transitions between states. Formerly referred to as a state diagram,
state chart diagram, or a state-transition diagram.
Timing Diagram Depicts the change in state or condition of a classifier instance or role Low
over time. Typically used to show the change in state of an object
over time in response to external events.
Use Case Diagram Shows use cases, actors, and their interrelationships. Medium

CLASS DIAGRAMS

To create and evolve a conceptual class diagram, you need to iteratively model:

• Classes
• Responsibilities
• Associations
• Inheritance relationships
• Composition associations
• Vocabularies
To create and evolve a design class diagram, you need to iteratively model:

• Classes
• Responsibilities
• Associations
• Inheritance relationships
• Composition associations
• Interfaces

Associations

Objects are often associated with, or related to, other objects. For example, Students are
ON WAITING LIST for seminars, professors INSTRUCT seminars, seminars are an
OFFERING OF courses, a professor LIVES AT an address, and so on. Associations are
modeled as lines connecting the two classes whose instances (objects) are involved in the
relationship.

When you model associations in UML class diagrams, you show them as a thin line
connecting two classes. Associations can become quite complex; consequently, you can
depict some things about them on your diagrams. The label, which is optional, although
highly recommended, is typically one or two words describing the association. For
example, professors instruct seminars.

Notation for associations.

USE CASE DIAGRAMS

Use case diagrams depict:

 • Use cases. A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.
• Actors. An actor is a person, organization, or external system that plays a role in one or
more interactions with your system. Actors are drawn as stick figures.
• Associations. Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is involved with an
interaction described by a use case. Associations are modeled as lines connecting use
cases and actors to one another, with an optional arrowhead on one end of the line. The
arrowhead is often used to indicating the direction of the initial invocation of the
relationship or to indicate the primary actor within the use case. The arrowheads are
typically confused with data flow and as a result I avoid their use.
• System boundary boxes (optional). You can draw a rectangle around the use cases,
called the system boundary box, to indicate the scope of your system. Anything within
the box represents functionality that is in scope and anything outside the box is not.

Using System boundary boxes to indicate releases.

Applying packages to simplify use case diagrams.

Use case reuse.

 SEQUENCE DIAGRAM

he main purpose of a sequence diagram is to define event sequences that result in some
desired outcome. The focus is less on messages themselves and more on the order in which
messages occur; nevertheless, most sequence diagrams will communicate what messages
are sent between a system's objects as well as the order in which they occur. The diagram
conveys this information along the horizontal and vertical dimensions: the vertical dimension
shows, top down, the time sequence of messages/calls as they occur, and the horizontal
dimension shows, left to right, the object instances that the messages are sent to.
Lifelines
When drawing a sequence diagram, lifeline notation elements are placed across the top of
the diagram. Lifelines represent either roles or object instances that participate in the
sequence being modeled. [Note: In fully modeled systems the objects (instances of classes)
will also be modeled on a system's class diagram.] Lifelines are drawn as a box with a
dashed line descending from the center of the bottom edge (Figure 3). The lifeline's name is
placed inside the box.
Messages
The first message of a sequence diagram always starts at the top and is typically located on
the left side of the diagram for readability. Subsequent messages are then added to the
diagram slightly lower than the previous message.
To show an object (i.e., lifeline) sending a message to another object, you draw a line to the
receiving object with a solid arrowhead (if a synchronous call operation) or with a stick
arrowhead (if an asynchronous signal). The message/method name is placed above the
arrowed line. The message that is being sent to the receiving object represents an
operation/method that the receiving object's class implements.
 COLLABORATION DIAGRAM

Collaboration diagrams belong to a group of UML diagrams called Interaction Diagrams.

Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course of
time. However, instead of showing the sequence of events by the layout on the diagram,
collaboration diagrams show the sequence by numbering the messages on the diagram. This
makes it easier to show how the objects are linked together, but harder to see the sequence at a
glance.

Instance:

An instance of a class shows a sample configuration of an object. On the sequence diagram,

each instance has a lifeline box underneath it showing it's existence over a period of time.

Lollipop Interface:

A lollipop interface is shorthand syntax for an interface. It shows the interface name without
displaying the operations.

Message:

The message indicates communication between objects. The order of messages from top to
bottom on your diagram should be the order in which the messages occur.

COMPONENT DIAGRAM

The component diagram's main purpose is to show the structural relationships between the
components of a system. Components are larger design units that represent things that will
typically be implemented using replaceable" modules.
In component-based development (CBD), component diagrams offer architects a natural
format to begin modeling a solution. Component diagrams allow an architect to verify that a
system's required functionality is being implemented by components, thus ensuring that the
eventual system will be acceptable.
In addition, component diagrams are useful communication tools for various groups. The
diagrams can be presented to key project stakeholders and implementation staff. While
component diagrams are generally geared towards a system's implementation staff,
component diagrams can generally put stakeholders at ease because the diagram presents
an early understanding of the overall system that is being built.

The notation
The component diagram notation set now makes it one of the easiest UML diagrams to
draw. The example shows a relationship between two components: an Order System
component that uses the Inventory System component. As you can see, a component is
drawn as a rectangle with two smaller rectangles protruding from its left side.

ACTIVITY DIAGRAM
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 typically used for business process modeling, for modeling the logic
captured by a single use case or usage scenario, or for modeling the detailed logic of
a business rule.

The basic notation:

• Initial node. The filled in circle is the starting point of the diagram. An initial
node isn’t required although it does make it significantly easier to read the
diagram.

• Activity final node. The filled circle with a border is the ending point. An
activity diagram can have zero or more activity final nodes.
• Activity. The rounded rectangles represent activities that occur. An activity may
be physical, such as Inspect Forms, or electronic, such as Display Create Student
Screen.
• Flow/edge. The arrows on the diagram. Although there is a subtle difference
between flows and edges I have never seen a practical purpose for the difference
although I have no doubt one exists. I’ll use the term flow.
• Fork. A black bar with one flow going into it and several leaving it. This
denotes the beginning of parallel activity.
 • Join. A black bar with several flows entering it and one leaving it. All flows
going into the join must reach it before processing may continue. This denotes
the end of parallel processing.

Activity diagram for a guided brainstorming process

DEPLOYMENT DIAGRAM
The deployment diagram shows how the components of the completed system are physically
related (i.e. what hardware will the system be running on and how will it all be connected).

Each node represents a computational unit such as a piece of hardware.

The connections between the nodes show the system interaction paths.

STATE CHART DIAGRAM

The name of the diagram itself clarifies the purpose of the diagram and other details. It describes
different states of a component in a system. The states are specific to a component/object of a
system.

A State chart diagram describes a state machine. A state machine can be defined as a machine
which defines different states of an object and these states are controlled by external or internal
events.

Activity diagram is a special kind of a State chart diagram. As State chart diagram defines states it
is used to model lifetime of an object.

Purpose:

State chart diagram is one of the five UML diagrams used to model dynamic nature of a system.
They define different states of an object during its lifetime. And these states are changed by events.
So State chart diagrams are useful to model reactive systems. Reactive systems can be defined as a
system that responds to external or internal events.

Statechart diagram describes the flow of control from one state to another state. States are defined
as a condition in which an object exists and it changes when some event is triggered. So the most
important purpose of Statechart diagram is to model life time of an object from creation to
termination.

Statechart diagrams are also used for forward and reverse engineering of a system. But the main
purpose is to model reactive system.

Following are the main purposes of using Statechart diagrams:

• To model dynamic aspect of a system.

• To model life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model states of an object.