UML for OOP languages

1
Outline
▪ What is UML and why we use UML?
▪ UML Diagrams
▪ Use case Diagram
▪ Sequence Diagram
▪ State Diagram
▪ Activity Diagram (Flowchart)
▪ Class Diagram

2
 What is UML?
➢ Diagramming language designed for Object-Oriented programming

➢ UML stands for Unified Modeling Language

➢ Language: express idea, not a methodology

➢ Modeling: Describing a software system at a high level of abstraction

(human language is very imprecise and source code is very detailed ➔ UML is in the
middle )

➢ Unified: UML has become a world standard (Everyone likes to draw…but

how do we draw pictures that we all understand?)
Object Management Group (OMG): www.omg.org

3
 Do we really need UML?
◼ Software project is not done by a single person! Complex applications
need collaboration and planning from multiple teams and hence require
a clear and concise way to communicate amongst them.

◼ Businessmen do not understand code! So UML becomes essential to

communicate with non programmers essential requirements,
functionalities and processes of the system.

◼ Picture is worth a thousand words! A lot of time is saved down the line
when teams are able to visualize processes, user interactions and static
structure of the system.

4
 More description about UML:
◼ UML uses graphical notations to express the OO analysis and design of software
projects.

◼ Simplifies the complex process of software design

◼ UML is independent from the implementation programming language (A UML

design could be realized in Java, C++, Perl, etc…)
◼ UML is a big, complicated diagramming language that comprises a lot of
different kinds of diagrams
◼ Diagrams can be used to describe:
◼ Who are the program users
◼ What is the program used for
◼ the organization of a program
◼ how a program executes
◼ how a program is used
◼ …and more
5
UML Diagrams Tree

Only few people on the earth know

all UML diagrams ☺ So we will
study the highlighted ones.
6
Outline
▪ What is UML and why we use UML?
▪ UML Diagrams
Use case Diagram
▪ Sequence Diagram
▪ State Diagram
▪ Activity Diagram (Flowchart)
▪ Class Diagram

7
 Use-Case Diagrams
◼ A use-case diagram is a set of use cases

◼ Use cases specify the expected behavior (what), and not the
exact method of making it happen (how).

◼ it helps us design a system from the end user's perspective.

◼ It is usually simple: no details, no order of the steps, only the

relationship between the external users (actors) and the
program

◼ More precisely, an actor is a user playing a specific role

8
Use-Case Diagram

9
 Actor
◼ Someone interacts with use case (system function).
◼ Named by noun.
◼ Actor plays a role in the business
◼ Actor triggers use case(s).
◼ Actor has a responsibility toward the system (inputs)
◼ and Actor has expectations from the system (outputs).

10
 Finding Actors
➢ External objects that produce/consume data:
➢ Must serve as sources and destinations for data
➢ Must be external to the system

11
 Finding Actors (2)
➢ Ask yourself the following questions:
• Who uses the system?
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• Who shuts down the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?

12
 Primary & secondary actors

• Primary actor (on the left of the diagram)

• Invokes a system functionality (for consultancy/modification)
• The initiator of exchanges with the system
• He is the actor for whom the use case produces an observable result

• Secondary actor (on the right of the diagram)

• An actor that the system needs assistance from to achieve the primary actor's goal
• Does not trigger any functionality in the system

13
 Use Case
◼ System function (process - automated or manual)
◼ Named by verb + Noun (or Noun Phrase).
◼ i.e. Do something
◼ Each Actor must be linked to a use case, while some
use cases may not be linked to actors.

Finding a use case

◼ Answer the three questions:
1.Who?
2.Does what?
3.And why?
14
 Communication Link and System Boundary

◼ Communication Link
◼ The participation of an actor in a use case is shown by
connecting an actor to a use case by a solid link.
◼ Actors may be connected to use cases by associations,
indicating that the actor and the use case communicate
with one another using messages.

◼ System Boundary:
◼ entire system as defined in the requirements
document.
◼ For large and complex systems, each module
may be the system boundary.

15
Example:

16
Example:

17
 Use Case Relationship: Include

◼ Use case include is a directed relationship

between two use cases which is used to show that
behavior of the included use case (the addition) is
inserted into the behavior of the including (the
base) use case.
◼ It is used to simplify large use case by splitting it Directed dotted arrow (from
into several use cases base to included), with the
stereotype "<<include>>“.
18
 Use Case Relationship: Extend
◼ Extend is a directed relationship that specifies how and when the behavior
defined in usually supplementary (optional) extending use case can be
added to the behavior defined in the extended (base) use case.
◼ Extending use case typically defines optional behavior that is not
necessarily meaningful by itself.
◼ Extended use case is meaningful on its own, it is independent of the
extending use case.

Directed dashed arrow (head on

the base use case), with the
stereotype "<<extend>>“.

19
 Use Case Relationship: Generalization
◼ A generalization relationship is a parent-child relationship
between use cases.
◼ The child use case is an enhancement of the parent use case
(inherits properties and behavior of the parent and may override
them)

Directed normal arrow with a

triangle head, head on the
parent use case

20
 Use-Case Diagram Examples
◼ 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)

◼ Pay Bill is a parent use case and

Bill Insurance is the child use case.
(generalization)
Not that
easy!

We will use base use-cases with no relationships

21
 Use-Case Diagram Examples
◼ University Management System:
◼ Professors indicate which courses they will teach on-line.
◼ A course catalog can be printed
◼ Allow students to select on-line four courses for upcoming semester.
◼ No course may have more than 10 students or less than 3 students.
◼ When the registration is completed, the system sends information to the billing
system.
◼ Professors can obtain course rosters on-line.
◼ Students can add or drop classes on-line.

22
 Use-Case Diagram Examples
◼ University
Management
System:

23
 Use-Case Diagram Examples
◼ ATM machine system:
◼ An automated teller machine (ATM) or the automatic banking machine
(ABM) is a banking subsystem (subject) that provides bank customers
with access to financial transactions in a public space without the need for
a cashier, clerk, or bank teller.
◼ Customer (actor) uses bank ATM to Check Balances of his/her bank
accounts, Deposit Funds, Withdraw Cash and/or Transfer Funds (use
cases).
◼ ATM Technician provides Maintenance and Repairs.
◼ All these use cases also involve Bank actor whether it is related to
customer transactions or to the ATM servicing.

24
 Use-Case Diagram Examples
ATM
machine
system:

25
Outline
▪ What is UML and why we use UML?
▪ UML Diagrams
▪ Use case Diagram
Sequence Diagram
▪ State Diagram
▪ Activity Diagram (Flowchart)
▪ Class Diagram

26
 Scenario of Use cases
◼ Typically each use case includes a primary scenario ( or main
course of events) and zero or more secondary scenarios that are
alternative courses of events to the primary scenario.

◼ A scenario is one path or flow through use cases that describes a

sequence of events that occurs during one particular execution of a
system

27
 UML Sequence Diagram
◼ 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

Emphasis on time ordering!

28
 Sequence Diagram(make a phone call)
Caller Phone Recipient

Picks up
Object Dial tone Message
direction
Dial

Ring notification Ring

message Picks up Life line

Hello

29
 Sequence Diagram main elements

◼ participant: object or entity that acts in the

diagram

◼ message: communication between participant

objects

◼ the axes in a sequence diagram:

– horizontal: which object/participant is acting
– vertical: timeline (down -> forward in time)
30
 Messages between objects
◼ messages (method calls) indicated by arrow to other object
– write message name and arguments above arrow
– dashed back-arrow indicates return /Solid head for procedure call

31
 Lifeline of the object
Creation

◼ creation: arrow with 'new' written above it

(notice that an object created after the start of the
scenario appears lower than the others)
Activation

◼ deletion: an X at bottom of object's lifeline nested

– Java doesn't explicitly delete objects; they fall out of

scope and are garbage-collected

◼ activation: thick box over object's life line;

drawn when object's method is on the stack
– object is running its code
– or it is on the stack waiting for another object code to finish Deletion
Self deletion
◼ nested activations to indicate recursion from
another
32
object
 Selection and loops
◼ frame: box around part of
diagram to indicate if or loop

◼ if -> (opt) [condition]

◼ if/else -> (alt) [condition],

separated by horizontal
dashed line

◼ loop -> (loop) [condition or

items to loop over]

33
 More details
• "opt" Operator
• The opt (optional) operator is an optional • « alt » operator
step in the flow • A test instruction
• The sequence of this fragment only (condition) with one or
executes if the guard [condition] is true multiple alternatives..
[if-then-else]
• Example: the user requests from the system
to return a ticket

34
 More details
account
CardHolder
• « loop » operator
loop [3]
• Allowing to execute a sequence of sendPin ( )
interactions while a certain condition is verifyPin ( )
evaluated as true
…

• Example of guards [condition]

• Loop[3]
• Loop[boolean_expression]
• Loop[foreach object in collection]

Lab. Software Design

 List of operators
• « par » operator (parallel)
• Allows representing two interactions that occur in parallel.

:Class1 :Class2

par
operation1 ( ) operation2 ( )

Lab. Software Design

 Sequence Diagram Examples
ATM ‘Check Card’ sequence Diagram

37
 Sequence Diagram Examples
ATM ‘withdraw’
sequence Diagram

38
Music playlist based on face emotion:
An application that takes the image of the user via the webcam and based
on a face detection algorithm that predicts the mood, it generate a song
playlist and show it to the user.

1. Firstly the application is opened by

the user.
2. The device then gets access to the
web cam.
3. The webcam captures the image of
the user.
4. The device uses algorithms to detect
the face and predict the mood.
5. It then requests database for
dictionary of possible moods.
6. The mood is retrieved from the
database.
7. The mood is displayed to the user.
8. The music is requested from the
database.
9. The playlist is generated and finally
shown to the user.