Chapter Two: Introduction of UML

1
Overview of UML
 UML is a notation that resulted from the unification of
OMT (Object Modeling Technique) and OOSE (Object-
Oriented Software Engineering
 It is an industry-standard graphical language or modeling
language for specifying, visualizing, constructing, and
documenting the artifacts of software systems.
 Goal: provide a standard notation that can be used by all
object-oriented methods
 The UML uses mostly graphical notations to express the
OO analysis and design of software projects.
 Simplifies the complex process of software design
2Help acquire an overall view of a system.
 The Unified Modelling Language is a standard
graphical language for modelling object
oriented software
At the end of the 1980s and the beginning of
1990s, the first object-oriented development
processes appeared
The proliferation of methods and notations
tended to cause considerable confusion
Two important methodologists Rum Baugh
and Booch decided to merge their
approaches in 1994.
They worked together at the Rational
Software Corporation
3
In 1995, another methodologist, Jacobson,
Cont.…
 Any real-world system is used by different users. The users can be
developers, testers, business people, analysts, and many more. Hence,
before designing a system, the architecture is made with different
perspectives in mind.
 The most important part is to visualize the system from the perspective
of different viewers.
 The better we understand the better we can build the system.
 UML plays an important role in defining different perspectives of a
system. These perspectives are −
 Design
 Implementation
 Process
 Deployment
4
Cont..
Model a system:-
Describing the system at abstract level to comprehend its
complexity
Necessary to manage complexity
Good for quick understanding of the systems
Less chances of conflicting views between end-user and system
designers common understanding
In projects involving many participants, with different technical
and cultural backgrounds,
accuracy and clarity are critical standard notation

5
Cont...
System development focuses on three different models of
the system:
The functional model,  use case diagrams, describes the
functionality of the system from the user’s point of view.
The object model,  represented in UML with class
diagrams, describes the structure of the system in terms
of objects, attributes, associations, and operations.
The dynamic model  represented in UML with
interaction diagrams, state machine diagrams, and
activity diagrams, describes the internal behavior of the
system.
6
Building blocks of the UML
 The building blocks of UML can be defined as:
Things
Diagrams
Relationships
Things
It can be structural, behavioral, grouping or annotational

7
Cont.…
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: represents set of objects having similar responsibilities.
Interface: defines a set of operations which specify the
responsibility of a class.
Collaboration: defines interaction between elements.
Use case: represents a set of actions performed by a system for a
specific goal.
Component: a software unit.
Node: can be defined as a physical element that exists at run time

8
Cont.…

Behavioral things:
 A behavioral thing consists of the dynamic parts of UML
models.
 Following are the behavioral things:
Interaction: defined as a behavior that consists of a
group of messages exchanged among elements to
accomplish a specific task.
State chart: 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.
9
Cont.…
Grouping things:
 Grouping things can be defined as a mechanism to group
elements of a UML model together.
 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: is used to render comments, constraints etc of an UML
element.
10
Cont.…
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: is a relationship between two things in
which change in one element also affects the other one.
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
11
relationship.
Cont.…
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: it 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.

12
Cont.…
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.

13
UML Diagrams
 UML has two types of diagrams:
 Structural Diagrams:
 Behavioral Diagrams:
 Structural Diagrams:
 Visualize, specify, construct and document the static aspects of a
system.
 The static aspects of a software system encompass the existence and
placement of things such as classes, interfaces, collaborations,
components and nodes etc.
 There are following four structural UML diagrams.
 Class Diagram
 Object Diagram
 Component Diagram

14
 Deployment Diagram
Cont...
 Behavioral Diagrams: visualize, specify, construct, and
document the dynamic aspects of a system.
 Dynamic aspects of a system as representing its changing parts.
 The dynamic aspects of a software system encompass things
such as the flow of messages over time and physical movements
of components across network
 Following five are the UML behavioral diagrams.
 Use Case Diagram
 Sequence Diagram
 Collaboration Diagram
 State-chart Diagram
 Activity Diagram

15
Use Case Diagram
Describe the functional behavior of the system as seen by
the user.
Model the functionality of a system using actors and use
cases.
Use cases are a set of actions, services, and functions that
the system needs to perform.
Mainly used for Visualizing/capturing the functional
requirements of a system that will translate into design
Used during requirements elicitation Specify how the
system interacts with actors.
Work like a contract between end user and software
developers.
16
Use Case Diagram Symbols and Notations:

Use case represent the system's functions

Actors are the users of a system
17
Represent systems boundary
Actors
 An actor models an external entity which
communicates with the system:
User
External system
Physical environment

Teacher  An actor has a unique name and an optional

description.
 Examples:
Teacher: a person who teaches the students
Student: a person in school and registered
Student for class
18
 Relationships in Use Case Diagrams
 There are five types of relationships in a use case diagram.

They are
Association between an actor and a use case

Generalization of an actor

Extend relationship between two use cases

Include relationship between two use cases

Generalization of a use case

19
Association:
Communication between an actor and a use case(Illustrate
relationships between an actor and a use case )
Represented by a solid line.

Change
grade

Teacher

20
 Generalization
 Generalization: is a 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.

Is it Possible to Generalize Actors and Use Cases?

 There maybe instances where actors are associated with similar use
cases while triggering few use cases unique only to them.
 In such instances you can generalize the actor to show the inheritance
of functions.
21
 You can do a similar thing for use case as well.
Cont.…
Generalization is simply the inheritance relationship
between two use cases by which one use case inherits all the
properties and relationships of another use case.
You can use the generalization relationship when you find
two or more use cases which have common behavior/logic.
In this instance, you can describe the common parts in a
separate use case (the parent) which then is specialized into
two or more specialized child use cases.
Eg1. One of the best examples of this is “Make Payment”
use case in a payment system.
You can further generalize it to “Pay by Credit Card”, “Pay by
22 Cash”, “Pay by Check” etc. All of them have the attributes and the
 Cont.…
Include relationship between two use cases
 For include relationships among use cases, use arrows labeled
“include"
 An <<include>> relationship indicates that one use case is
needed by another in order to perform a task.
Avoid redundancy.
<<include>>
 Look for common functionality that can be reused across the
system.
 Then you can connect it via the include relationship to show that
its always called when the original use case is executed.
23
 Cont.…
Extend relationship between two use cases
For extends relationships among use cases, use arrows
labeled "extends"
An <<extends>> relationship indicates alternative options
under a certain use case.

<<extend>>

There are some functions that are triggered optionally. In

such cases you can use the extend relationship and attach
and extension rule to it.
24
Cont.…
 Banking system example “Calculate Bonus” is optional
and only triggers when a certain condition is matched.
 Extend doesn’t always mean its optional. Sometimes the
use case connected by extend can supplement the base
use case.
 Thing to remember is that the base use case should be
able to perform a function on its own even if the
extending use case is not called.
 The direction of a <<extend>> relationship is to the
extended use case

25
Cont.…
Customer
EnterPin Withdraw
>
de>
In cl u
< <

Bank’s Other’s
<<extend>>

<<extend>>
<<extend>>
Receipt Timeout
NoCash

26
Example
Invalid
<<extend>>
card
Transfer

<<Include>> Verify System

>>
ex tend
<<Include>> <<
Customer Enter Outof
Pin lu d e >>
<<I n c Date
n d >>
<<Include>> With xte
<<e
draw Timeout
Bank’s Other’s
CheckB n d >> <<extend>>
< exte
alance < NoCash
Receipt

27
Sequence diagram
 Model the interactions between objects in a single use case.
 Illustrate how the different parts of a system interact with
each other to carry out a function.
 Sequence diagrams describe interactions among classes in
terms of an exchange of messages over time.
 Displays the time sequence of the objects participating in the
interaction.
 This consists of the vertical dimension (time) and horizontal
dimension (different objects).

28
Cont...
 Sequence diagram is interaction diagram that shows the
set of objects and messages send and receive by those
object.
 It mainly emphases on time ordering and messages.
 It is used to illustrate the dynamic view of system.
 Describe the flow of messages, events, actions between
objects
 Show concurrent processes and activations
 Show time sequences that are not easily depicted in
other diagrams
 Typically used during analysis and design to document
and understand the logical flow of your system
29
Terms and Concepts of Sequence Diagram
Objects or Participants
 The sequence diagram is made up of collection of
participants or objects.
 Participants are system parts that interact each other
during sequence diagram.
 The participants interact with each other by sending and
receiving message
 The object is represented by rectangle.

ObjectName

30
Cont...
Lifeline
 Lifeline represents the existence of an object over a
period of time.
 It is represented by vertical dashed line.
 Most objects that appeared in ‘Interaction diagram’ will
be in existence for the duration of an interaction.
 So, these objects are aligned at top at top of diagram
with their lifeline from top to bottom of diagram.
ObjectName

Life Line

31
Cont...
Activation bar
 It is also called as focus of control.
 It shows the period of time during which an object is performing an
action.
 It is represented by tall thin rectangle
 Means the object is active and using resources during that time
period
 Denotes when an object is sending or receiving messages

ObjectName

Activation bar

32
Cont...
Messages
 The interaction in a sequence diagram between the objects can be
shown by using messages.
 The messages on sequence diagram are specifies using an arrow
from participant that wants to pass the messages to the participant
that receive the messages .
 Messages can be flow in whatever direction required for
interaction from left to right and right to left.

ObjectName ObjectName

[Message1]

[Message2]
33
Cont...
There are six main types of messages:
1. Synchronous messages:-
 It is a message where the sender is blocked and waits until the
receiver has finished processing of message.
 It is invoked the caller waits for the receiver to return from the
message invocation.
 It is represented by solid line with full arrow.
Message

2. Asynchronous messages:-
 It is a messages where the sender is not blocked and can continue
executing.
 It is represent by solid line with half arrow.

Message
34
Cont...
3. Reflexive messages:-
 If the object sends the message to itself then it is called as
Reflexive message.
 It is represented by solid line with loops the lifeline of object.
Message

4. Return messages:-
 It can be used at the end of activation bar to show that control flow
of activation returns to the participant that pass the original
message.
 It is represent by dashed line from sender to receiver.

Message

35
Cont...
5. Create messages:-
 It is used to create object during interaction(first message).
 The object can be created by using <<create>> to indicate the
timing of creation. <<create>>
[Message]
6. Destroy messages:-
 It is used to destroy the objects during interaction.
 The objects can be terminated using <<destroy>> which points to
an “x”.
 It indicates that object named message is terminated.

<<destroy>>
[Message]

36
Cont...
Time:-
 The sequence diagram describes the order in which interaction
takes place.
 So time in an important factor. The time on sequence diagram
starts at top of the page just below the object and then progress
down the page.
 Time is all about ordering but not duration.
Actor:-
 Shows entities that interact with or are external to the system.

Time

37
Cont...

ObjectName ObjectName

<<Message>>
<<Message>>
[Message]

Time Message
Message

Message

Message

38
Steps for constructing sequence diagram

Step1: Set the context.

o Select a use case.
o Decide the initiating actor.
Step 2: Identify the objects or participants in the use
case
Step 3: List down the steps involved in the execution of
the use case
Step 4: Identify which messages should be passed
between the objects

39
 Bank KeyPad
Card Reader Display
consortium

Customer
1: Insert ATM
1.1: Validate

1.2: Validated

1.3: ask for pin

1.3.1: prompt user to input pin

2: input pin
2.1: verify pin

2.2: pin verified

2.3: Show menu

40
3: Select/input the amount to withdraw money
Activity Diagram
 Activity diagrams show flow of control and data flow.
Typically used to model:
Business process workflow
Flow within a use case
Business rules logic
Functional processes
 They are the perfect tool for mapping processes and
workflows
 Visually presents a series of actions or flow of control in a
system similar to a flowchart.
 Activities modeled can be sequential and concurrent.

41
Basic Activity Diagram Notations and Symbols
 Initial State or Start Point:

 represents the initial action state or the start point for any activity diagram.

 Activity or Action State:

 An action state represents the non-interruptible action of objects.

 Action Flow:

 Illustrate the transitions from one action state to another.

 Decisions and Branching:

 A diamond represents a decision with alternate paths. When an

activity requires a decision prior to moving on to the next activity,

42 add a diamond between the two activities
Cont...

 Time Event:

This refers to an event that stops the flow for a time.

 Merge Event:

A merge event brings together multiple flows that are not

concurrent.
 Final State or End Point:
An arrow pointing to a filled circle nested inside another
circle represents the final action state.
43
Cont..

 Synchronization:
 It is represented as a straight, slightly
thicker line in an activity diagram.
 A fork node is used to split a single
incoming flow into multiple concurrent
flows.
 A join node joins multiple concurrent
flows back into a single outgoing flow.
 A fork and join node used together are
often referred to as synchronization.

44
 Insert Card Validate Card

Valid Invalid

Enter Pin Verify Pin

Valid pin Invalid pin
Enter Amount

Check Balance
Amount > Balance Amount<=Balance

Take Money Debit Account

Take Card Eject Card

45
State Machine Diagram
 A state machine diagram shows
 The life history of a given class
 The events that cause a transition from one state to another
 The actions that result from a state change
 State machine diagram shows how state of some object or system
could change.
 State diagram describes the behavior of a single object in
response to a series of events in a system.
 Models the dynamic flow of control from state to state of a
particular object within a system.

46
Cont..
Used to model the dynamic nature of a system.
They define different states of an object during its lifetime and
these states are changed by events.
Useful to model the reactive systems.
Reactive systems can be defined as a system that responds to
external or internal events.
Describes the flow of control from one state to another state.

47
Cont..

 The most important purpose of state chart diagram is

to model lifetime of an object from creation to
termination.
 To model the life time of a reactive system.
 To describe different states of an object during its life
time.
 Define a state machine to model the states of an
object.
 As State chart diagram, it defines the states, it is used
to model the lifetime of an object.
48
Cont..
 UML state machine diagrams depict the various states that an object
may be in and the transitions between those states.
 States - A state is denoted by a round-cornered rectangle with the
name of the state written inside it.

State

 The initial state is denoted by a filled black circle and may be

labeled with a name.

 The final state is denoted by a circle with a dot inside and may also
be labeled with a name.

49
 Cont..
 Transitions - Transitions is a progression from one state to another
are denoted by lines with arrowheads.
o A transition may have a trigger, a guard and an effect.
o Trigger is the cause of the transition, which could be a signal,
an event, a change in some condition, or the passage of time.
o Guard is a condition which must be true in order for the trigger
to cause the transition.
o Effect is an action which will be invoked directly on the object
that owns the state machine as a result of the transition.
 Self-Transitions - A state can have a transition that returns to itself.
o This is most useful when an effect is associated with the
transition.

50
Example: an ATM transaction

idle
Invalid
Insert card Validating card Cancel Eject
Take card
Card ok

Request Pin

Enter a pin

Wrong pin
Verifying

Pin ok
No balance
Account

Withdraw
Take cash & card
Debit
51
Component diagram
 Component diagrams are used to model the physical aspects of a
system.
 Now the question is, what are these physical aspects?
 Physical aspects are the elements such as executables, libraries, files,
documents, etc. which reside in a node.
 Component diagrams are used to visualize/describe the organization
and relationships of the components
 Shows the dependencies among software components, including the
classifiers that specify them (for example implementation classes) and
the artifacts that implement them; such as source code files, binary
code files, executable files, scripts and tables.
 It does not describe the functionality of the system but it describes the
components used to make those functionalities.
52
Cont..
 Component diagrams are used during the implementation phase of an
application. However, it is prepared well in advance:
o To visualize the implementation details.
o To get an idea of the implementation.
 This diagram is very important to implement the application
efficiently and for other aspects such as application performance,
maintenance, etc.
 The implementation team of an application should have a proper
knowledge of the component details Component diagrams can be used
to −
o Model the components of a system.
o Model the database schema.
o Model the executables of an application.

53 Model the system's source code.

o
Cont..
You model components and their relationship so that
 Clients can envision the structure and functionality in finished
system
 Developers have a structure to work toward
 Technical writers who have to provide documentation and help
files can understand what they are writing about
 You are ready for use
Steps to Creating a Component Diagram:
 Take stock of everything needed to implement the planned
system.
 Create a visual for each of the components.
 Describe the organization and relationships between components
using interfaces, ports, and dependencies.

54
Example: ATM Component diagram

Employ
Station Account info
Bank
Data Base Card
Reader

Client
Desktop
ATM
Machine
ATM
Network

Client Desktop
transaction Customer Cash
Interface Dispenser

ATM transaction
55
Deployment Diagram
 Deployment diagram Describes a static view of the run-time
configuration of hardware nodes and the software components
that run on those nodes.
 The deployment diagram captures the configuration of the run time
element of the application.
 Deployment diagrams show the hardware for your system, the
software that is installed on that hardware, and the middleware used
to connect the disparate machines to one another.
 Deployment diagrams are used for describing the hardware
components, where software components are deployed.

56
Cont..
 Component diagrams are used to describe the components and
deployment diagrams shows how they are deployed in hardware.
They are Closely related
 UML is mainly designed to focus on the software artifacts of a
system. However, these two diagrams are special diagrams used to
focus on software and hardware components.
 Deployment diagrams can be visualized as the hardware
components/nodes on which the software components reside.
 The purpose of deployment diagrams can be described as −
o Visualize the hardware topology of a system.
o Describe the hardware components used to deploy software
components.
o Describe the runtime processing nodes.

57
Cont..
 An efficient deployment diagram is very important as it controls the
following parameters −
o Performance, Scalability, Maintainability, Portability
o To meet these types of requirements, hardware components should
be designed efficiently and in a cost-effective way.
 Before drawing a deployment diagram, the following artifacts should
be identified
o Nodes
o Relationships among nodes
 Now-a-days software applications are very complex in nature.
Software applications can be standalone, web-based, distributed,
mainframe-based and many more

58
Cont..
 An artifact represents a physical entity Examples: Model files, source
files, scripts, binary executable files.
 Node are Execution environments (virtual machine, app server, and
other “middleware”)
 Displays the configuration of run-time processing elements and the
software components, processes, and objects that reside within them.

 Nodes are connected by

communication paths to
create network systems

59
Cont..
Example:
 Consider a system that includes a Web server and two database
servers.
 Both database servers are identical:
o The first acts as a main server, while
o the second acts as a redundant backup in case the first one
fails.
 Users use Web browsers to access data through the Web server.
 They also have the option of using a proprietary client that
accesses the databases directly.
 Draw a UML deployment diagram representing the
hardware/software mapping of this system.
60
Cont..

61
Example: ATM Deployment diagram

Card Receipt
reader Printer

Cash
dispenser

Display

ATM System
Node
Network
Interface

Server
Database internet
connection

branch Database Node

Network
62 Database Interface
Class Diagram
 Class diagrams is a static diagram
 Describe/ represents the static structure/ view of an
application(system):
• Objects,
• Attributes, and
• Associations.
 Class diagram is not only used for visualizing, describing,
and documenting different aspects of a system but also for
constructing executable code of the software application.

63
Cont.…
 Class diagrams are the only diagrams which can be
directly mapped with object-oriented languages and
thus widely used at the time of construction.
 Class diagram shows a collection of classes,
interfaces, associations, collaborations, and
constraints.
 The purpose of lass diagram is to Model the static
view of a system/Analysis and design of the static
view of an application and Describe responsibilities
of a system

64
Class Diagram basics/ Symbols and Notations
Class: Define the classes in an OO system. their fields and
methods.
Classes are composed of three things: a name, attributes, and
operations.
ClassName
Attributes

Operations

65
Cont..
Visibility: Define the access specification of class
members(methods/attributes)

+ public
# protected
- private
~ package (default)
/ derived

66
Cont...
However, the UML provides abbreviations for visibility:
+ (public), - (private), and # (protected).
A public member is visible anywhere in the program and
may be called by any object within the system.(+)
A private member may be used only by the class that
defines it.(-)
A protected member may be used only by
o (a) the class that defines it or
o (b) a subclass of that class.(#)

67
Attributes/Methods

 attributes (fields, instance variables)

 visibility name : type [count] = default_value
attribute example: Rectangle
-width:int
- balance : double = 0.00 -heght:int
 Class operations / methods /area:double

 visibility name (parameters) : return_type +rectangle(widt

h:int,hegght:int)
parameter types listed as (name: type) :double
+distane(r.recta
example: ngle):double

+ distance(p1: int, p2: int): double

68
Relationships between classes
 Generalization: an inheritance relationship
 Inheritance between classes
(dashed line, white arrow)
 Interface implementation
(dashed line, white arrow)
 Association: a usage relationship
 Aggregation (clear white diamond)
 Composition ( black diamond)

Multiplicity (how many are used)

* === 0, 1, or more
1 === 1 exactly
2..4 === between 2 and 4, inclusive
3..* === 3 or more (also written as “3..”)
69
Classes Relationships
A generalization: is used when two classes are similar, but
have some differences. Read as “A kind of”
 The association relationship is the most common
relationship in a class diagram.
 The association shows the relationship between instances
of classes.

70
Cont..
 all objects have their own lifecycle and there is no owner.
Let's take an example of Teacher and Student.
Multiple students can associate with single teacher and
single student can associate with multiple teachers, but
there is no ownership between the objects and both have
their own lifecycle. Both can be created and deleted
independently.
E.g. the class Order is associated with the class Customer.

71
 Cont..
 Uni-directional association, two classes are related, but
only one class knows that the relationship exists.
 Bi-directional association is a linkage between two
classes. Associations are always assumed to be bi-
directional; this means that both classes are aware of
each other and their relationship, unless you qualify the
association as some other type

72
Cont..
Aggregation: refers to the formation of a particular class as
a result of one class being aggregated or built as a collection.
Read as “part of”
E.g. the class “library” is made up of one or more books,
among other materials.
In aggregation, the contained classes are not strongly
dependent on the lifecycle of the container.
In the same example, books will remain so even when the
library is dissolved.

73
Cont..
 Composition: is very similar to the aggregation relationship
with the only difference being its key purpose of stressing
the dependence of the contained class to the life cycle of the
container class.
 That is, the contained class will be destroyed when the
container class is destroyed.
 composition: “is entirely made of”
Stronger version of aggregation
The parts live and die with the whole
 E.g. a shoulder bag’s side pocket will also cease to exist
once the shoulder bag is destroyed.

74
 Bank maintains
1 1 ATM
+address
+manage() 1 +location
1 manages +transaction()
has
1..* 1..* 1
Customer ATMcard
Identifies

owns +card_owner 1..*

+card_number
ATMTransaction
1..* 1..* -pin
1..* -transaction_id
+access
+date
1..* owns 1..* +type

Account get +update()

1..* access

Checking Saving Withdraw Transfer

75