Unified Modeling Language

Introduction
Spanoudakis (2012) categorizes design modeling
languages to:
•Design modeling languages
1.Operation oriented
 DFD’s
 Flow Charts
2.Object Oriented
 UML
•Architecture description languages
2
UML (Mouratidis, 2007)
Object Modeling Technique (OMT) Booch Method

Coad and Yourdon UML Shlaer and Mellor

Martin and Odell

Object Oriented Software Engineering (OOSE)
THE GOAL:

Result of the unification Provide a standard notation that can be used by all
object-oriented methods to model Object Oriented
Systems
Has influenced 3
Versions
• UML 1.x in 1997; earlier works contributed
to the development of the language,

• UML 2.x: Improvements done in 2005,

meta-modeling, Diagram interchange,
OCL
An introduction to UML (II)
• UML has been designed for a
• Main Behavioural UML diagrams
broad range of applications
I. Activity diagram
II. Communication diagram
• Main Structural UML diagrams III. Interaction overview diagram
I. Class diagram IV. Sequence diagram
II. Component diagram V. Statechart diagram
III. Deployment diagram VI. Use case diagram
IV. Object diagram
V. Package diagram

5
Use Case Diagrams
• A use case diagram
– Describes the functional behavior of the system (as seen by the
users)
– Defines the boundaries of the system
– Displays the relationships between actors and use cases
• Actor
– A user or another system that will interact with the system under
development
• Use Case
– an external view of the system that represents some functionality of
the system (an action the user might perform)
– A complete run of a scenario
• System Boundary
– Defines the scope of the system 6
Use Case description
• A use case is initiated by an actor
• A use case should have:
– Unique Name
– Participating actors
– Entry/Exit Condition
– Flow of Events
– Describe Exceptions
– Describe Special Requirements (Constraints,
Nonfunctional Requirements)
7
Graphical Representation

8
 Use Case Relationships
• Communication
– Denote access to functionality
– Only relationship between actors and use
cases
– Depicted by solid line between actor and use
case

9
Include Relationship
• Include (uses)
– in an include relationship, a use case includes the
functionality described in another use case as a part of its
process
– Adds extra behaviour into a base use case
– Include reduces complexity
– Depicted by a dashed open arrow originating from the base use
case and labelled with the stereotype “<<include>>”
– e.g. IssueBook includes loggin In

10
Include Relationship (II)

11
Include Relationship (II)

12
Extend Relationship
• Extend
– Adds extra functionality
– A use case extends another use case by adding events
– Extend is also used to model exception cases, helps,
errors, and other unexpected conditions
– Depicted by a dashed arrow (similar to the include),
originating from the child (extend) use case and labelled with
the stereotype "<<extend>>“
– HandleInvalidUserException, HandleAbort
extends Log In
13
Extend Relationship (II)

14
Extend Relationship (II)

15
Extend Relationship (II)

16
 Include or Extend???
When all you have is a hammer, every problem
looks like a nail!!

When the Driver (actor) takes a trip, fueling the vehicle is part of taking
the trip (included use cases are mandatory behavior).

The Driver may or may not take photos and/or eat a meal (extending
used cases are optional behavior) as part of taking a trip. 17
Use Case diagram testing questions
• Is our notation correct?
• Are all actors identified?
• Can the system described actually be built?
• Are all the system's functional requirements
reflected in the use cases?
• Do the use cases define all the functionality within
the scope of the system and nothing outside the
scope?
• Can we trace each use case back to its
requirements? 18
Use Case diagram guidelines
• Do have a clear idea of the system you intend to
describe
• Do ensure all use cases provide value to at least one
actor
• Do involve a “user” in the writing process. It is users’
requirements
• Do not believe anyone telling you use case modelling is
simple…It is not!!!
• Do not include system design elements in the use cases
• Do not get worked up about <<extend>>, <<include>>!
• Do not forget actors representing other systems!

19
 Prepare use cases:
The clock shows time of the day . Using buttons the user
can set the hours and minutes fields individually and
choose between 12 and 24 hour display. It is possible to
set one or two alarms. When an alarm fires it will sound
some noise the user can turn it off or choose to snooze. If
the user does not respond at all the alarm will turn off itself
after 2 minutes. Snoozing means to turn off the sound but
the alarm will fire again after some minutes of delay . this
snoozing time is pre adjustable
 Prepare use cases:
The clock shows time of the day . Using buttons the
user can set the hours and minutes fields
individually and choose between 12 and 24 hour
display. It is possible to set one or two alarms.
When an alarm fires it will sound some noise the
user can turn it off or choose to snooze. If the user
does not respond at all the alarm will turn off itself
after 2 minutes. Snoozing means to turn off the
sound but the alarm will fire again after some
minutes of delay . this snoozing time is pre
adjustable
Prepare use cases:
 Cake Store
Bake cake
Heat oven
Mix flour/egg/sugar/milk
Place in oven
Store cake
Start cooler
Place cake in cool place
Sell cake
Get order from customer
Pack cake ordered by customer
Accept payment
What happens in a Cake Store??
Tender cash return
purchase Stock
Note items below reserve level
Calculate quantity to order
Place order
Store arrived materials
Chef
Receptionist
Actors??
Manager
Wholesaler
 Customer
Cake Store
 ATM MACHINE
We need to build the ATM system to allow a user to withdraw money.
Series of common interactions in this scenario:
‧ enter card ‧ enter pin number ‧ select amount required
‧ confirm amount required ‧ remove card ‧ take receipt
Should each of these steps . for example, .enter pin number. be a use case?

A Use Case should satisfy a goal for the actor

Well, not really. It wouldn’t be the end

Is take receipt. the goal
of the world if the receipt wasn’t
for our customer?
dispensed.

Apply the rule to the other Use Cases, and you.ll find that really, none of them
describe the goal of the user.
The goal of the user is to withdraw money, and that should be the use case!
 ATM MACHINE

We need to build the ATM system to allow a user to withdraw money. We might have the following series
of common interactions in this scenario:
‧ enter card ‧ enter pin number ‧ select amount required
‧ confirm amount required ‧ remove card ‧ take receipt
Should each of these steps . for example, .enter pin number. be a use case?

A Use Case should satisfy a goal for the actor

Is take receipt. the goal

for our customer?
Wrong!!!!!!

Apply the rule to the other Use Cases, and you.ll find that really, none of them
describe the goal of the user.
The goal of the user is to withdraw money, and that should be the use case!
 ATM MACHINE

We need to build the ATM system to allow a user to withdraw money. We might have the following series
of common interactions in this scenario:
‧ enter card ‧ enter pin number ‧ select amount required
‧ confirm amount required ‧ remove card ‧ take receipt
Should each of these steps . for example, .enter pin number. be a use case?

A Use Case should satisfy a goal for the actor

Is take receipt. the goal

for our customer?

Apply the rule to the other Use Cases, and you.ll find that really, none of them
describe the goal of the user.
The goal of the user is to withdraw money, and that should be the use case!
 Video Shop
Any one who wishes to rent a video from the shop must first be registered as a
member. Members may rent out videos provided that they are old enough, for
this reason the Sales Assistant needs to record each member’s date of birth
when they join. It also records each member’s address and phone number, so
that they can trace them in the event of a video not being returned.
Members can reserve a video provided a copy is available for the day they
require it and that they are genuine members. All video reservations are
recorded in the company’s video database so that the status of each copy can
be monitored. Reserved videos must be collected before 7pm.
To rent a video, members must present their Membership Card. Each video
attracts a rental charge depending on its popularity and how recently it has
been released. All Video rented out must be returned by 6pm the following day
otherwise members will be charged an extra day.
Staff need to update stock records with new titles or extra copies when
deliveries are received from Suppliers and deleting records of copies which are
lost or damaged on return.
 Video Shop
Any one who wishes to rent a video from the shop must first be registered
as a member. Members may rent out videos provided that they are old
enough, for this reason the Sales Assistant needs to record each member’s
date of birth when they join. It also records each member’s address and phone
number, so that they can trace them in the event of a video not being returned.
Members can reserve a video provided a copy is available for the day they
require it and that they are genuine members. All video reservations are
recorded in the company’s video database so that the status of each copy can
be monitored. Reserved videos must be collected before 7pm.
To rent a video, members must present their Membership Card. Each video
attracts a rental charge depending on its popularity and how recently it has
been released. All Video rented out must be returned by 6pm the following day
otherwise members will be charged an extra day.
Staff need to update stock records with new titles or extra copies when
deliveries are received from Suppliers and deleting records of copies which are
lost or damaged on return.
Class Diagram
• Represent the structure of a system in terms of classes
– A class is a collection of objects
– Classes have a name, attributes, operations and relationships.
– Class names start with uppercase letter

30
Developing a class diagram
• Not right or wrong technique
• Can be modelled with more details in the design stage,
• One technique
– Pick all the nouns (person, place, thing) and noun phrases
from the requirements
– Discard any inappropriate candidates
• Redundant, event, operation, attribute, outside the scope of the
system
• Practice!
31
Associations
• Associations depict relationships between classes
• If classes correspond to nouns, associations correspond
to verbs
• Two types
– Bidirectional
– Unidirectional: an arrow indicates the direction

32
Aggregation
• Special case of association
• It indicates a whole-part (is part of) relationship
• Denoted by a hollow diamond at the end of the whole

• Composition is a special case of aggregation

• The whole owns its part (if whole is destroyed the part
is destroyed)

33
Inheritance (generalization)
• Relationship between a general class
(superclass) and a more specialised one
(subclass)
• It is an “is a” relationship
• It enables us to describes all the attributes and
operations that are common to a set of classes
• Denoted by a hollow
triangle at the end
of the superclass
34
Multiplicity
• Indicate the number of links that can legitimate
originate from an instance of a class connected
to the association end
• Label the association end by a set of integers
• Three common types
– One-to-One
– One-to-Many
– Many-to-Many
35
Class Diagram testing questions
• Does each class define attributes, methods,
relationships, and multiplicity?
• Is each association well named?
• Is each association’s and aggregation’s
multiplicity correct?
• Is each class named with a strong noun?
• Have all redundant, irrelevant, or vague classes
been removed from the diagram?
36
Class diagram guidelines
• Use singular names because each class represents
a generalised version of a singular object
• Use simple class names (Student instead of …
PersonWhoStudies)
• Do not model actors in class diagrams
• Use full names for attributes
• Make sure you class diagram is consistent with the
requirements
• Try to avoid using only * for multiplicity (Is it 0..* or
1..*)
37
 Draw Class diagram:
A hockey league is made up of at least four hockey teams. Each
hockey team is composed of six to twelve players, and one player
captains the team. A team has a name and a record. Players have a
number and a position. Hockey teams play games against each other.
Each game has a score and a location. Teams are sometimes lead by
a coach. A coach has a level of accreditation and a number of years of
experience and can coach multiple teams. Coaches and players are
people and people have names and addresses. Draw a class diagram
for this information and be sure to label all associations and
appropriate multiplicities.
 Draw Class diagram:
A hockey league is made up of at least four hockey teams.
Each hockey team is composed of six to twelve players, and
one player captains the team. A team has a name and a record.
Players have a number and a position. Hockey teams play
games against each other. Each game has a score and a
location. Teams are sometimes lead by a coach. A coach has a
level of accreditation and a number of years of experience and
can coach multiple teams. Coaches and players are people and
people have names and addresses. Draw a class diagram for
this information and be sure to label all associations and
appropriate multiplicities.
Draw Class diagram:
 Design a Class diagram
For class Books with the following attributes and
operations
Attributes: name, Author name, ISSSN Number,
price
Operation to take value for the above data, to
search a book by its ISSN and to display the
details of a book
 Come up with a class
diagram:
A health clinic provides medical services to patients in a town.
Five doctors and three nurses work at the clinic, they consult
with patients, prescribe medicines and carry out minor medical
treatments. Patients with more serious conditions are referred to
specialists at the local hospital. A medical information system is
being designed for use in the clinic. The system will manage
information about employees (doctors, nurses, admins) , patients
and their contact details, appointments and consultations,
medicines and prescriptions, treatments given and referrals.
A library own by a college contains many books. Students of the
college are allowed to take books, return books, pay fines if the
books are retuned late. Students can receive many books. The
librarian of the college initiates lots of transaction for serving
students requests like issuing and returning of books, charging
fines etc, a transaction of this kind includes one or many books
belonging to the library
UML Class Model
+ 1..1
+ has

+ Library + 1..*
+ 1..1 + initiates + 1..*
+ Transaction + 1..1 + 1..* + Book
+ includes
+ 1..1 + 1..1

+ 1..*
+ helps
+ Issuance + Return + Fine

+ 1..*
+ 1..1
+ Student + receives

+ 1..* + 1..1
+ admits + College
+ owns + 1..1
Quiz time!!!
• Consider an ATM System. Which of the
following is NOT an actor.
A. Customer
B. Central Bank computer
C. ATM processor
D. Thief

46
Question 2-1
• Which of the following use case diagrams
is NOT correct (if any)

47
Question 2-2

48
Question 2-3

49
Integrated Development Environments

• There are number of IDE’s for drawing UML

diagrams:
I. Modelio,
II. AgileJ StructureViews (An extension to Eclipse)
III.StarUML
IV.IBM’s Rational Rose
V. QSEE!

50
Differences with ERD
• Many similarities!
• Class diagram as part of object oriented modeling techniques
represents static and to some extent dynamic features of your
system; class diagram maps the real world objects.
• Entity Relation Diagramming, on the other hand. Models
structural and static features of a system; ERD represents and
abstract representation of the system

51