Introduction to

UML
Overview
What is Modeling?
What is UML?
A brief history of UML
Understanding the basics of UML
UML diagrams
UML Modeling tools
Modeling
Describing a system at a high level of abstraction
◦ A model of the system
◦ Used for requirements and specifications

Is it necessary to model software systems?

Object Oriented Modeling
 Evolution of OOAD
It was developed in 1990s as an amalgamation of several techniques,
prominently OOAD technique by Grady Booch, OMT (Object Modeling
Technique) by James Rumbaugh, and OOSE (Object Oriented Software
Engineering) by Ivar Jacobson. UML attempted to standardize semantic
models, syntactic notations, and diagrams of OOAD.
 What is UML?
The Unified Modeling Language (UML) is a graphical language fo
OOAD that gives a standard way to write a software system’s
blueprint. It helps to visualize, specify, construct, and document the
artifacts of an object-oriented system. It is used to depict the
structures and the relationships in a complex system.
It is a industry-standard graphical language for specifying,
visualizing, constructing, and documenting the artifacts of software
systems

The UML uses mostly graphical notations to express the OO

analysis and design of software projects.

Simplifies the complex process of software design

Systems and Models in UML

System − A set of elements organized to achieve certain

objectives form a system. Systems are often divided into
subsystems and described by a set of models.
Model − Model is a simplified, complete, and consistent
abstraction of a system, created for better understanding of
the system.
View − A view is a projection of a system’s model from a
specific perspective.
Conceptual Model of UML
The Conceptual Model of UML encompasses three major elements −
◦ Basic building blocks
◦ Rules
◦ Common mechanisms
Why UML for Modeling
Use graphical notation to communicate more clearly than
natural language (imprecise) and code(too detailed).

Help acquire an overall view of a system.

UML is not dependent on any one language or technology.

UML moves us from fragmentation to standardization.

Basic Building Blocks
The three building blocks of UML are −
◦ Things
◦ Relationships
◦ Diagrams
 Building Blocks :Things
There are four kinds of things in UML, namely −
Structural Things − These are the nouns of the UML models representing the static
elements that may be either physical or conceptual. The structural things are class,
interface, collaboration, use case, active class, components, and nodes.
Behavioral Things − These are the verbs of the UML models representing the dynamic
behavior over time and space. The two types of behavioral things are interaction and
state machine.
Grouping Things − They comprise the organizational parts of the UML models. There is
only one kind of grouping thing, i.e., package.
Annotational Things − These are the explanations in the UML models representing the
comments applied to describe elements.
Relationships
Relationships are the connection between things. The four types of
relationships that can be represented in UML are −
◦ Dependency − This is a semantic relationship between two things such that a change
in one thing brings a change in the other. The former is the independent thing, while
the latter is the dependent thing.
◦ Association − This is a structural relationship that represents a group of links having
common structure and common behavior.
◦ Generalization − This represents a generalization/specialization relationship in which
subclasses inherit structure and behavior from super-classes.
◦ Realization − This is a semantic relationship between two or more classifiers such that
one classifier lays down a contract that the other classifiers ensure to abide by.
 Diagrams
A diagram is a graphical representation of a system. It comprises of a group of
elements generally in the form of a graph. UML includes nine diagrams in all,
namely −
◦ Use Case Diagram
◦ Class Diagram
◦ Object Diagram
◦ Sequence Diagram
◦ Collaboration Diagram
◦ State Chart Diagram
◦ Activity Diagram
◦ Component Diagram
◦ Deployment Diagram
Rules
UML has a number of rules so that the models are semantically self-
consistent and related to other models in the system harmoniously.
UML has semantic rules for the following −
◦ Names
◦ Scope
◦ Visibility
◦ Integrity
◦ Execution
Use Case Diagram
Use Case Diagram is UML behavioral diagram that visualize, specify,
construct, and document the dynamic aspects of a system.
The behavioral diagrams are categorized as follows: use case diagrams,
interaction diagrams, state–chart diagrams, and activity diagrams.
Used for describing a set of user scenarios
Mainly used for capturing user requirements
Work like a contract between end user and software developers
Use case diagram
Use case diagrams present an outside view of the manner the elements in a
system behave and how they can be used in the context.
Use case diagrams comprise of −
Use cases
Actors
Relationships like dependency, generalization, and association
Use case diagrams are used −
To model the context of a system by enclosing all the activities of a system
within a rectangle and focusing on the actors outside the system by
interacting with it.
To model the requirements of a system from the outside point of view.
 Use Case Diagram (core components)

Actors: A role that a user plays with respect to the system,including

human users and other systems. e.g.,inanimate physical objects (e.g. robot);
an external system that needs some information from the current system.

Use case: A set of scenarios that describing an interaction between a user

and a system, including alternatives.

System boundary: rectangle diagram representing the boundary between

the actors and the system.
Use Case Diagram(core relationship)

Association: communication between an actor and

a use case; Represented by a solid line.

Generalization: relationship between one general

use case and a special use case (used for defining
special alternatives)
Represented by a line with a triangular arrow head
toward the parent use case.
Use Case Diagram(core relationship)

Include: a dotted line labeled <<include>> beginning at base

use case and ending with an arrows pointing to the include use
case. The include relationship occurs when a chunk of
behavior is similar across more than one use case. Use
“include” in stead of copying the description of that behavior.
<<include>>

Extend: a dotted line labeled <<extend>> with an arrow

toward the base case. The extending use case may add behavior to
the base use case. The base class declares “extension points”.

<<extend>>
Use Case Diagrams

Boundary Use Case

Actor
Library System

Borrow
Employee
Client

Order Title

Fine Remittance

Supervisor

• A generalized description of how a system will be used.

• Provides an overview of the intended functionality of the system
Use Case Diagrams(cont.)

(TogetherSoft, Inc)
Use Case Diagrams(cont.)
•Pay Bill is a parent use case and Bill Insurance is the
child use case. (generalization)

•Both Make Appointment and Request Medication

include Check Patient Record as a subtask.(include)

•The extension point is written inside the base case

Pay bill; the extending class Defer payment adds the
behavior of this extension point. (extend)
Class diagram
Used for describing structure and behavior in the use cases
Provide a conceptual model of the system in terms of entities and their
relationships
Used for requirement capture, end-user interaction
Detailed class diagrams are used for developers
Class representation
Each class is represented by a rectangle subdivided into three
compartments
◦ Name
◦ Attributes
◦ Operations

Modifiers are used to indicate visibility of attributes and operations.

◦ ‘+’ is used to denote Public visibility (everyone)
◦ ‘#’ is used to denote Protected visibility (friends and derived)
◦ ‘-’ is used to denote Private visibility (no one)

By default, attributes are hidden and operations are visible.

Class diagram
Each class is represented by a rectangle subdivided into three compartments
◦ Name-the top section containing the name of the class
◦ Attributes-the middle section containing class attributes
◦ Operations-the bottom section representing operations of the class

The visibility of the attributes and operations can be represented in the following
ways −
Public − A public member is visible from anywhere in the system. In class diagram, it
is prefixed by the symbol ‘+’.
Private − A private member is visible only from within the class. It cannot be
accessed from outside the class. A private member is prefixed by the symbol ‘−’.
Protected − A protected member is visible from within the class and from the
subclasses inherited from this class, but not from outside. It is prefixed by the symbol
‘#’.
Example
Let us consider the Circle class introduced earlier. The attributes of
Circle are x-coord, y-coord, and radius. The operations are findArea(),
findCircumference(), and scale(). Let us assume that x-coord and y-
coord are private data members, radius is a protected data member,
and the member functions are public. The following figure gives the
diagrammatic representation of the class.
An example of Class

Name
Account_Name
- Customer_Name
Attributes
- Balance
+addFunds( ) Operations
+withDraw( )
+transfer( )
OO Relationships

There are two kinds of Relationships

◦ Generalization (parent-child relationship)
◦ Association (student enrolls in course)

Associations can be further classified as

◦ Aggregation
◦ Composition
 OO Relationships: Generalization

Supertype Example: Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2
or: Customer
- Generalization expresses a
parent/child relationship among related
classes.
- Used for abstracting details in several Regular Loyalty
layers Customer Customer
OO Relationships: Association

Represent relationship between instances of classes

◦ Student enrolls in a course
◦ Courses have students
◦ Courses have exams
◦ Etc.
Association has two ends
◦ Role names (e.g. enrolls)
◦ Multiplicity (e.g. One course can have many students)
◦ Navigability (unidirectional, bidirectional)
Association: Multiplicity and Roles
student
1 *

University Person

0..1 *
employer teacher

Role
Multiplicity
Symbol Meaning
1 One and only one Role
0..1 Zero or one “A given university groups many people;
M..N From M to N (natural language)
some act as students, others as teachers.
A given student belongs to a single
* From zero to any positive integer university; a given teacher may or may not
0..* From zero to any positive integer be working for the university at a particular
1..* From one to any positive integer time.”
 Class Diagram
Name Order class
Multiplicity: mandatory
-dateReceived
Attributes -isPrepaid Customer
-number :String
-price : Money
* 1 -name
-address
+dispatch() Association +creditRating() : String()
Operations +close()

1
{if Order.customer.creditRating is Generalization
"poor", then Order.isPrepaid must
be true }

Corporate Customer Personal Customer

-contactName -creditCard#
Constraint -creditRating
-creditLimit
Multiplicity: (inside braces{}}
+remind()
Many value +billForMonth(Integer)

0..1
Multiplicity:
optional *
Employee
*
OrderLine
-quantity: Integer 1
* Product
-price: Money
-isSatisfied: Boolean

[from UML Distilled Third Edition]

Association: Model to Implementation
* 4
Student Course
has enrolls

Class Student {
Course enrolls[4];
}

Class Course {
Student have[];
}
 OO Relationships: Composition
Composition: expresses a relationship among instances
Whole Class of related classes. It is a specific kind of Whole-Part
Class W relationship.

It expresses a relationship where an instance of the

Whole-class has the responsibility to create and initialize
instances of each Part-class.

Class P1 Class P2 It may also be used to express a relationship where instances

of the Part-classes have privileged access or visibility to
certain attributes and/or behaviors defined by the
Part Classes Whole-class.

Composition should also be used to express relationship where

Example instances of the Whole-class have exclusive access to and
control of instances of the Part-classes.
Automobile
Composition should be used to express a relationship where
the behavior of Part instances is undefined without being
related to an instance of the Whole. And, conversely, the
behavior of the Whole is ill-defined or incomplete if one or
more of the Part instances are undefined.
Engine Transmission

[From Dr.David A. Workman]

OO Relationships: Aggregation
Container Class
Class C Aggregation: expresses a relationship among instances
of related classes. It is a specific kind of Container-
AGGREGATION Containee
relationship.

It expresses a relationship where an instance of the

Class E1 Class E2 Container-class has the responsibility to hold and maintain
instances of each Containee-class that have been created
outside the auspices of the Container-class.
Containee Classes
Aggregation should be used to express a more informal
relationship than composition expresses. That is, it is an
appropriate relationship where the Container and its
Containees can be manipulated independently.
Example
Bag
Aggregation is appropriate when Container and
Containees have no special access privileges to each other.

Apples Milk

[From Dr.David A. Workman]

Aggregation vs. Composition

•Composition is really a strong form of aggregation

•components have only one owner
•components cannot exist independent of their owner
•components live or die with their owner
e.g. Each car has an engine that can not be shared with
other cars.

•Aggregations may form "part of" the aggregate, but may not
be essential to it. They may also exist independent of the
aggregate.
e.g. Apples may exist independent of the bag.