Unified Modeling Language

LOGO

Introduction to UML

Prof. Erwin M. Globio, MSIT
Senior IT Lecturer
Far Eastern University

What is UML?

Unified Modeling Language
 OMG Standard, Object Management Group
 Based on work from Booch, Rumbaugh,
Jacobson

UML is a modeling language to express
and design documents, software
 Particularly useful for OO design
 Not a process, but some have been proposed
using UML
 Independent of implementation language 2

Why use UML

 Open Standard, Graphical notation for
 Specifying, visualizing, constructing, and documenting
software systems
 Language can be used from general initial design to
very specific detailed design across the entire software
development lifecycle
 Increase understanding/communication of product to
customers and developers
 Support for diverse application areas
 Support for UML in many software packages today
(e.g. Rational, plugins for popular IDE‟s like JBuilder,
NetBeans, Eclipse)
 Based upon experience and needs of the user
community
3

Brief History

 Inundated with methodologies in early 90‟s
 Booch, Jacobson, Yourden, Rumbaugh
 1989-1994: 50+ OO methods
 Clearly prominent methods
• Jacobson‟s OOSE: support for use cases to capture requirements
• Booch: expressive during design/construction
• Rumbaugh‟s OMT: analysis+ data intensive systems
 1994: Rumbaugh joined Booch at Rational
 1995: Jacobson joined Rational
 1996: UML version 0.9
 1997 UML 1.1 from OMG includes input from others, e.g.
Yourden
 1997: Standardized by OMG
 UML 1.1…1.4 (2.0)
 UML v2.0 current version 4

Contributions to UML

6

Conceptual model of UML

UML

Building Rules Common
blocks name, scope, visibility mechanisms

Things Relations Diagrams

Class
Dependency Object
Structural Behavioral Grouping Annotate
Association Use case
Class Interaction Generalization Sequence
Interface Package Note
State machine Realization Collaboration
Active class Statechart
Component Activity
Node Use case Component
Collaboration Deployment
7

Systems, Models and Views

A model is an abstraction describing a subset of a
system
A view depicts selected aspects of a model
A notation is a set of graphical or textual rules for
depicting views
Views and models of a single system may overlap
each other
Examples:
System: Aircraft
Models: Flight simulator, scale model
Views: All blueprints, electrical wiring, fuel system
8

Systems, Models and Views

Flightsimulator
Blueprints
Aircraft
Model 2
View 2
View 1
System
View 3
Model 1
Electrical
Wiring
Scale Model

9

UML Models, Views, Diagrams

UML is a multi-diagrammatic language
 Each diagram is a view into a model
• Diagram presented from the aspect of a particular
stakeholder
• Provides a partial representation of the system
• Is semantically consistent with other views
 Example views

10

Models, Views, Diagrams

11

Summary of diagram kinds in UML (nine
concrete kinds)

 Structural diagrams
 Static structural diagrams
• Class diagrams
• Object diagrams
 Implementation diagrams
• Component diagrams
• Deployment diagrams
 Behavior diagrams
 Use case diagrams
 Interaction diagrams
• Sequence diagrams
• Collaboration diagrams
 Statechart diagrams
 Activity diagrams

12

UML Baseline

Use Case Diagrams
Class Diagrams
Package Diagrams
Interaction Diagrams
 Sequence
 Collaboration
Activity Diagrams
State Transition Diagrams
Deployment Diagrams

13

Views

Static Dynamic
 Use case  Sequence
 Class  Collaboration
 Object  Statechart
 Component  Activity
 Deployment

14

How Many Views?

Views should to fit the context
 Not all systems require all views
 Single processor: drop deployment view
 Single process: drop process view
 Very small program: drop implementation
view
A system might need additional views
 Data view, security view, …

15

Basic Modeling Steps

Use Cases
 Capture requirements
Domain Model
 Capture process, key classes
Design Model
 Capture details and behaviors of use cases
and domain objects
 Add classes that do the work and define the
architecture

16

Use Case Modeling: Core Elements

Construct Description Syntax
use case Describes what a system
/subsystem/class/interface does.
A set of sequences of actions UseCaseName

performed by a system to yield an
observable result to an actor.
actor A coherent set of roles that users of
use cases play when interacting with
these use cases. They live outside the
ActorName
system.
system Represents the boundary between the
boundary physical system and the actors who
interact with the physical system.

17

Use Case Modeling: Core Relationships

association The participation of an actor in a use case.
i.e., instance of an actor and instances of a
use case communicate with each other.
generalization A taxonomic relationship between a more
general use case and a more specific use
case.
extend A relationship from an extension use case
to a base use case, specifying how the
behavior for the extension use case can be <<extend>>
inserted into the behavior defined for the
base use case.

18

Use Case Modeling: Core Relationships (cont’d)

include An relationship from a base use case to an
inclusion use case, specifying how the <<include>>
behavior for the inclusion use case is
inserted into the behavior defined for the
base use case.

19

Use Case Diagram

The same person
Telephone Catalog
(or system) may
play the roles of
Check
status a number of actors
at the same time
Place Salesperson
order

Fill orders

Customer Shipping Clerk

Billing
Establish System
credit

Supervisor

20

Use Case Diagrams

 Used during requirements
elicitation to represent external
behavior

 Actors represent roles, that is,
a type of user of the system
Passenger  Use cases represent a
sequence of interaction for a
type of functionality; summary
of scenarios
 The use case model is the set
of all use cases. It is a
complete description of the
PurchaseTicket functionality of the system and
its environment

21

Actors

An actor models an external entity
which communicates with the
system:
 User
 External system
Passenger  Physical environment
An actor has a unique name and an
optional description.
Examples:
 Passenger: A person in the train
 GPS satellite: Provides the system
with GPS coordinates 22

Use Case

A use case represents a class of
functionality provided by the
system as an event flow.

A use case consists of:
PurchaseTicket
Unique name
Participating actors
Entry conditions
Flow of events
Exit conditions
Special requirements
23

Use Case Diagram: Example

Name: Purchase ticket Event flow:
1. Passenger selects the
Participating actor: Passenger number of zones to be
traveled.
Entry condition:
2. Distributor displays the
 Passenger standing in front of
ticket distributor. amount due.
 Passenger has sufficient 3. Passenger inserts
money to purchase ticket. money, of at least the
amount due.
Exit condition: 4. Distributor returns
 Passenger has ticket. change.
5. Distributor issues ticket.

24

The <<extends>> Relationship

 <<extends>> relationships represent
exceptional or seldom invoked cases.
Passenger  The exceptional event flows are factored
out of the main event flow for clarity.
 Use cases representing exceptional flows
can extend more than one use case.
PurchaseTicket  The direction of a <<extends>> relationship
is to the extended use case
<<extends>>

<<extends>>
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel NoChange
25

The <<includes>> Relationship

 <<includes>> relationship
represents behavior that is
factored out of the use case.
Passenger
 <<includes>> behavior is
factored out for reuse, not
PurchaseMultiCard because it is an exception.
PurchaseSingleTicket  The direction of a <<includes>>
<<includes>> relationship is to the using use
<<includes>> case (unlike <<extends>>
relationships).

CollectMoney
<<extends>> <<extends>>

NoChange Cancel
26

Use Cases are useful to…

Determining requirements
 New use cases often generate new requirements as
the system is analyzed and the design takes shape.
Communicating with clients
 Their notational simplicity makes use case diagrams
a good way for developers to communicate with
clients.
Generating test cases
 The collection of scenarios for a use case may
suggest a suite of test cases for those scenarios.

27

Use Case Diagrams: Summary

Use case diagrams represent external
behavior
Use case diagrams are useful as an index
into the use cases
Use case descriptions provide meat of
model, not the use case diagrams.
All use cases need to be described for the
model to be useful.

28

What is structural modeling?

Structural model: a view of a system that
emphasizes the structure of the objects,
including their classifiers, relationships,
attributes and operations.

29

Class Diagrams

Gives an overview of a system by showing
its classes and the relationships among
them.
 Class diagrams are static
 they display what interacts but not what
happens when they do interact
Also shows attributes and operations of
each class
Good way to describe the overall
architecture of system components

30

Structural Modeling: Core Elements

class a description of a set of objects that
share the same attributes, operations,
methods, relationships and semantics.
interface a named set of operations that
characterize the behavior of an
element. «interface»

component a modular, replaceable and significant
part of a system that packages
implementation and exposes a set of
interfaces.
node a run-time physical object that
represents a computational resource.

31

Structural Modeling: Core Elements (cont’d)

constraint¹ a semantic condition or restriction.
{constraint}

¹ An extension mechanism useful for specifying structural elements.

32

Structural Modeling: Core Relationships

association a relationship between two or more
classifiers that involves connections
among their instances.
aggregation A special form of association that
specifies a whole-part relationship
between the aggregate (whole) and the
component part.
generalization a taxonomic relationship between a more
general and a more specific element.

dependency a relationship between two modeling
elements, in which a change to one
modeling element (the independent
element) will affect the other modeling
element (the dependent element).
33

Structural Modeling: Core Relationships (cont’d)

realization a relationship between a specification and
its implementation.

34

Class Diagram Perspectives

We draw Class Diagrams under three
perspectives
 Conceptual
• Software independent
• Language independent
 Specification
• Focus on the interfaces of the software
 Implementation
• Focus on the implementation of the software

35

Classes – Not Just for Code

TariffSchedule
Name Table zone2price
Enumeration getZones()
TariffSchedule Price getPrice(Zone)
zone2price Attributes
getZones()
getPrice() Signature
Operations

A class represent a concept TariffSchedule

A class encapsulates state (attributes) and
behavior (operations).
Each attribute has a type.
Each operation has a signature.
The class name is the only mandatory information. 36

Instances

tarif_1974:TarifSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}

An instance represents a phenomenon.
The name of an instance is underlined and can
contain the class of the instance.
The attributes are represented with their values.

37

Actor vs Instances

What is the difference between an actor , a
class and an instance?
Actor:
 An entity outside the system to be modeled,
interacting with the system (“Passenger”)
Class:
 An abstraction modeling an entity in the problem
domain, must be modeled inside the system (“User”)
Object:
 A specific instance of a class (“Joe, the passenger
who is purchasing a ticket from the ticket distributor”).

38

UML Class Notation

 A class is a rectangle divided into three parts
 Class name
 Class attributes (i.e. data members, variables)
 Class operations (i.e. methods)
 Modifiers
 Private: -
 Public: +
 Protected: #
 Static: Underlined (i.e. shared among all members of the
class)
 Abstract class: Name in italics
Employee
-Name : string
+ID : long
#Salary : double
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal) 39

UML Class Notation

 Lines or arrows between classes indicate
relationships
 Association
• A relationship between instances of two classes, where one
class must know about the other to do its work, e.g. client
communicates to server
• indicated by a straight line or arrow
 Aggregation
• An association where one class belongs to a collection, e.g.
instructor part of Faculty
• Indicated by an empty diamond on the side of the collection
 Composition
• Strong form of Aggregation
• Lifetime control; components cannot exist without the aggregate
• Indicated by a solid diamond on the side of the collection
 Inheritance
• An inheritance link indicating one class a superclass
relationship, e.g. bird is part of mammal
• Indicated by triangle pointing to superclass 40

Binary Association

Binary Association: Both entities “Know About” each other

myB.service(); myA.doSomething();

Optionally, may create an Associate Class

41

Unary Association

A knows about B, but B knows nothing about A

myB.service(); Arrow points in direction
of the dependency

42

Aggregation

Aggregation is an association with a “collection-member” relationship

void doSomething() Hollow diamond on
aModule.service(); the Collection side

No sole ownership implied

43

Composition

Composition is Aggregation with:
Lifetime control; components cannot exist without the aggregate
Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object
Employee
Team
-Name : string
-members : Employee +ID : long
1 #Salary : double
-adfaf : bool
*
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
members[0] =
new Employee();
… Filled diamond on
delete members[0]; side of the Collection

44

Inheritance

Standard concept of inheritance

Base Class

Derived Class

class B() extends A
…

45

UML Multiplicities

Links on associations to specify more details about the relationship
Multiplicities Meaning
zero or one instance. The notation n . .
0..1
m indicates n to m instances.
no limit on the number of instances
0..* or *
(including none).
1 exactly one instance
1..* at least one instance

46

UML Class Example

47

Association Details

Can assign names to the ends of the
association to give further information

Employee
Team -group
-Name : string
-members: Employee -individual +ID : long
1 #Salary : double
-adfaf : bool
*
+getName : string
()
+setName ()
-calcInternalStuffin x : byte, in y : decimal
( )

48

From Problem Statement To Object Model

Problem Statement: A stock exchange lists many companies. Each
company is uniquely identified by a ticker symbol

Class Diagram:

StockExchange * * Company
Lists
tickerSymbol

49

From Problem Statement to Code

Problem Statement : A stock exchange lists many companies.
Each company is identified by a ticker Symbol

Class Diagram:
StockExchange * * Company
Lists tickerSymbol

Java Code
public class StockExchange
{
private Vector m_Company = new Vector();
};
public class Company
{
public int m_tickerSymbol;
private Vector m_StockExchange = new Vector();
};
50

Object Modeling in Practice: Class Identification

Foo

Dinero
CustomerId
Deposit()
Withdraw()
GetBalance()

Class Identification: Name of Class, Attributes and Methods

51

Object Modeling in Practice: Encourage Brainstorming

“Dada” Foo

Dinero Dinero
CustomerId CustomerId
Account
Deposit() Deposit()
Withdraw() Withdraw() Dinero
GetBalance() GetBalance()
CustomerId

Deposit()
Naming is important! Withdraw()
Is Foo the right name? GetBalance()

52

Object Modeling in Practice

Account

Betrag Customer
AccountId
Bank
Name
Name Deposit() CustomerId
Withdraw()
GetBalance()

1) Find New Objects

2) Iterate on Names, Attributes and Methods

53

Object Modeling in Practice: A Banking System

Account

Dinero * Has Customer
Bank AccountId
CustomerId
Name
Name Deposit() CustomerId
Withdraw()
GetBalance()

1) Find New Objects
2) Iterate on Names, Attributes and Methods
3) Find Associations between Objects
4) Label the assocations
5) Determine the multiplicity of the assocations
54

Practice Object Modeling: Iterate, Categorize!

Account
Bank Customer

Name
* Amount
* Has Name
AccountId
CustomerId
Deposit()
Withdraw()
GetBalance() CustomerId()

Savings Checking Mortgage
Account Account Account

Withdraw() Withdraw() Withdraw()

55

Static vs. Dynamic Design

Static design describes code structure and
object relations
 Class relations
 Objects at design time
 Doesn‟t change
Dynamic design shows communication between
objects
 Similarity to class relations
 Can follow sequences of events
 May change depending upon execution scenario
 Called Object Diagrams

56

Object Diagrams

Shows instances of Class Diagrams and
links among them
 An object diagram is a snapshot of the objects
in a system
• At a point in time
• With a selected focus
– Interactions – Sequence diagram
– Message passing – Collaboration diagram
– Operation – Deployment diagram

57

Object Diagrams

Format is
 Instance name : Class name
 Attributes and Values

 Example:

58

Objects and Links

Can add association type and also message type
59

Package Diagrams

To organize complex class diagrams, you can
group classes into packages. A package is a
collection of logically related UML elements
Notation
 Packages appear as rectangles with small tabs at the
top.
 The package name is on the tab or inside the
rectangle.
 The dotted arrows are dependencies. One package
depends on another if changes in the other could
possibly force changes in the first.
 Packages are the basic grouping construct with which
you may organize UML models to increase their
readability
60

Example

Package 1 Package 2

Package 3

61

Example

Subsystem Name

Package 1 Package 2

Package 3

62

Package Example

DispatcherInterface

Notification IncidentManagement

63

More Package Examples

64

Interaction Diagrams

Interaction diagrams are dynamic -- they
describe how objects collaborate.
A Sequence Diagram:
 Indicates what messages are sent and when
 Time progresses from top to bottom
 Objects involved are listed left to right
 Messages are sent left to right between
objects in sequence

65

What are interactions?

Interaction: describes a collection of
communications between instances,
including all ways to affect instances, like
operation invocation, as well as creation
and destruction of instances
The communications are partially ordered
(in time)

66

Interactions: Core Elements

Instance An entity with a unique identity and
(object, to which a set of operations can be name

data value, applied (signals be sent) and which attr values

component has a state that stores the effects of
instance the operations (the signals).
etc.)

Action A specification of an executable textual
statement.
A few different kinds of actions are
predefined, e.g. CreateAction,
CallAction, DestroyAction, and
UninterpretedAction.
67

Interactions: Core Elements (cont’d)

Stimulus A communication between two
instances.

Operation A declaration of a service that can textual
be requested from an instance to
effect behavior.

Signal A specification of an asynchronous «Signal»
Name
stimulus communicated between
parameters
instances.

68

Interaction: Core Relationships

Link A connection between instances.

Attribute Link A named slot in an instance, which textual
holds the value of an attribute.

69

Different kinds of arrows

Procedure call or other kind
of nested (synchronous) flow
of control (caller waits for the
callee to return)

Return

Asynchronous flow of
control (no waiting, no
nesting, caller returns
immediately)
70

Example: Different Arrows

Nested Flow Nested Flow Asynchronous flow
teller : Order : Article teller : Order : Article caller exchange callee
lift receiver

getValue getValue dial tone

price price dial digit

dial digit
getName getName ringing tone ringing signal

lift receiver

71

Interaction diagram tour

Show interactions between instances in
the model
 graph of instances (possibly including links)
and stimuli
 existing instances
 creation and deletion of instances
Kinds
 sequence diagram (temporal focus)
 collaboration diagram (structural focus)

72

Interaction diagrams

Sequence Diagram Collaboration Diagram
x y z 1.1: a
1.2: c
a x y

b
1.1.1: b
c
z

73

Sequence Diagram Format

Actor from
Use Case Objects

1

2
Activation 3

4

Lifeline Calls = Solid Lines
Returns = Dashed Lines 74

Sequence Diagram : Destruction

Shows Destruction of b
(and Construction)

75

Sequence Diagram : Timing

Slanted Lines show propagation delay of messages
Good for modeling real-time systems

If messages cross this is usually problematic – race conditions 76

Sequence Example: Alarm System

When the alarm goes off, it rings the alarm, puts
a message on the display, notifies the
monitoring service

77

Sequence Diagram Example
Hotel Reservation

78

Collaboration Diagram

Collaboration Diagrams show similar information
to sequence diagrams, except that the vertical
sequence is missing. In its place are:
 Object Links - solid lines between the objects that
interact
 On the links are Messages - arrows with one or more
message name that show the direction and names of
the messages sent between objects
Emphasis on static links as opposed to
sequence in the sequence diagram

79

Collaboration Diagram

80

Example: A Booking System

81

Use Case Description: Change Flt Itinerary

 Actors: traveler, client account db, airline
reservation system
 Preconditions: Traveler has logged in
 Basic course:
 Traveler selects „change flight itinerary‟ option
 System retrieves traveler‟s account and flight itinerary from client account
database
 System asks traveler to select itinerary segment she wants to change;
traveler selects itinerary segment.
 System asks traveler for new departure and destination information;
traveler provides information.
 If flights are available then …
 …
 System displays transaction summary.
 Alternative course:
 If no flights are available then…

82

Sequence Diagram: Change Flight Itinerary

Traveler : Booking System Client Account DBMS Airline Reservation System
change flight itinerary
get customer account

get itinerary
present itinerary

select segment

present detailed info

update information
available flight

:
:

83

Collaboration Diagram: Change Flt Itinerary

1: change flight itinerary
5: select segment 2: get customer account
3: get itinerary
7: update information
: Booking System
4: present itinerary
Traveler 6: present detailed info Client Account DBMS

8: available flight

Airline Reservation System

84

Activity Diagrams

 Fancy flowchart
 Displays the flow of activities involved in a single process
 States
• Describe what is being processed
• Indicated by boxes with rounded corners
 Swim lanes
• Indicates which object is responsible for what activity
 Branch
• Transition that branch
• Indicated by a diamond
 Fork
• Transition forking into parallel activities
• Indicated by solid bars
 Start and End

85

Sample Activity Diagram

Ordering System
May need multiple
diagrams from
other points of
view

86

Activity Diagram Example

87

State Transition Diagrams

Shows the possible states of the object and
the transitions that cause a change in state
 i.e. how incoming calls change the state
Notation
 States are rounded rectangles
 Transitions are arrows from one state to another.
Events or conditions that trigger transitions are
written beside the arrows.
 Initial and Final States indicated by circles as in
the Activity Diagram
• Final state terminates the action; may have multiple final
states
88

State Representation

The set of properties and values describing the
object in a well defined instant are characterized
by
 Name
 Activities (executed inside the state)
• Do/ activity
 Actions (executed at state entry or exit)
• Entry/ action
• Exit/ action
 Actions executed due to an event
• Event [Condition] / Action ^Send Event

89

Notation for States

90

Simple Transition Example

91

More Simple State Examples

92

State Transition Example

Validating PIN/SSN

93

State Charts – Local Variables

State Diagrams can also store their own
local variables, do processing on them
Library example counting books checked
out and returned
Borrow /
N = N+1

Is-Member Clean-Up

Start / N=0 Stop / N=0

Return /
N=N-1
94

Component Diagrams

Shows various components in a system and
their dependencies, interfaces
Explains the structure of a system
Usually a physical collection of classes
 Similar to a Package Diagram in that both are used to
group elements into logical structures
 With Component Diagrams all of the model elements
are private with a public interface whereas Package
diagrams only display public items.

95

Component Diagram Notation

Components are shown as rectangles with
two tabs at the upper left

Dashed arrows indicate dependencies
Circle and solid line indicates an interface
to the component

96

Component Example - Interfaces

Restaurant
ordering
system
Define
interfaces
first –
comes
from Class
Diagrams

97

Component Example - Components

Graphical depiction of components

98

Component Example - Linking

Linking components with dependencies

99

Deployment Diagrams

Shows the physical architecture of the hardware
and software of the deployed system
Nodes
 Typically contain components or packages
 Usually some kind of computational unit; e.g. machine
or device (physical or logical)
Physical relationships among software and
hardware in a delivered systems
 Explains how a system interacts with the external
environment

100

Some Deployment Examples

101

Deployment Example

Often the Component Diagram is combined with the Deployment
102

Summary and Tools

 UML is a modeling language that can be used
independent of development
 Adopted by OMG and notation of choice for visual
modeling
 http://www.omg.org/uml/
 Creating and modifying UML diagrams can be labor and
time intensive.
 Lots of tools exist to help
 Tools help keep diagrams, code in sync
 Repository for a complete software development project
 Examples here created with TogetherSoft ControlCenter,
Microsoft Visio, Tablet UML
 Other tools:
• Rational, Cetus, Embarcadero
• See http://plg.uwaterloo.ca/~migod/uml.html for a list of tools, some
free 103

Sample
Implementation
of UML
104

Hotel Reservation [USE CASE]

(1) Identify the actors.
(2) Identify the responsibilities of each
role.
(3) Identify the use cases by considering
what the system can offer.

105


(1) Identify the actors.

– staff
– customer
– guest
– management
– front desk
– laundry service
– room service
106


(2) Identify the responsibilities of each
role.
Staff includes management, front desk,
laundry service, room service
Each actor is considered individually.
Dividing the responsibilities based on the
description gives the following breakdown:

107


i) front desk
accept reservation
cancel reservation
assign rooms
check in guests
check out guests
receive payment

108


ii) room service
provide room service
laundry service
provide laundry service
iii) customer
make reservation
cancel reservation

109


iv) guest
check in
check out
v) management
need for increasing rooms based on non
availability
occupancy rate
revenue from services
reservation pattern based on holidays and
conventions
corporate customer reservations 110


(3) Identify the use cases by considering what
the system can offer.
A set of use cases can be derived by grouping the
related actions together
accept reservation  AcceptReservation
cancel reservation  CancelReservation
assign rooms  AssignRooms
check in guests  CheckInGuests
check out guests  CheckOutGuests
receive payment  ReceivePayment
provide room service  ProvideRoomService
provide laundry service  ProvideLaundryService

111


Consider any other possible situations.
You can also consider different situations representing the use case.

Example
When a person walks into the hotel without any reservation and wants to stay
Notice that the current use cases cannot handle this situation.
We discover the need to separate two possible situations where a guest may use
our hotel.

i) Walk in
ii) Previous reservation made

i) Walk in
The walk in use case represents the situation when no previous
reservations were made.
The customer walks into the hotel and wants to stay
A new class may be created to represent this use case. This use case
comprises a combination of the following existing use cases:
a) accept reservation
b) assign rooms
c) check in guests 112


113

Hotel Reservation
[Analysis Class Diagram ]

(1) Identify the nouns and model the
concepts as classes and adjectives as
attributes.
(2) Identify the possible attributes by
looking at how to describe each
concept.
(3) Test the 3 relationships between the
classes, has a or part of, uses or
depends on, kind of or is a.
(4) Consider the range, default and
limitations of each attribute. 114

Hotel Reservation

(1) Identify the nouns and model the concepts
as classes and adjectives as attributes.
(2) Identify the possible attributes by looking at
how to describe each concept.
Guidelines in abstracting the possible classes and
attributes
You may also include the adjectives as adjectives
represent descriptions.
Adjectives become the attributes.
When absolute values are mentioned, it represents
an attribute.
115

Hotel Reservation

Example
$250 for a twin room
Descriptions attached to the nouns indicate possible specializations.

Example
Single room, Twin room, Suite
Room can be thought of as the general class and the single and twin as
specialized classes.
If there are no additional attributes or operations in the specialized
classes, it is possible to replace the specialized classes by an
attribute.
In this example the suite is described by a name. A set of specialized
classes is used.
To represent the type of room
This indicates that an attribute has to be defined in a room class to hold
the value.

116

Hotel Reservation

i) Abstracting the nouns from the description gives the
following:
hotel, branch, reservation, room, room no, customer,
Customer’s name
Contact address, Country, Sex, Type of accommodations,
and number of rooms required
Names of the people and the type of room they need
Period of stay, Expected check in date, reservation identity,
Block bookings, agencies, payment, Credit card, Credit
card type, number and issuing company
Traveler’s checks, Check No., issuing company, Direct
corporate billing corporate account number, Cash, room
rate, $10 for breakfast, $10 for lunch, $10 for dinner,
Reservation, Name of the guest’s expected, Type of
payment, Shirt $5, Suits $12, Dress $8, Trousers $9,
Others $6, suite, single, twin, Single $150, Twin $250,
Suite $550 117

Hotel Reservation

ii) Organizing the nouns and adjectives
gives the following:
System
Hotel represents the system.
Possible classes
The following gives the potential classes and
the possible attributes from the list of nouns
and adjectives.

118

Hotel Reservation

Reservation
Reservation identity
No. of single rooms required
No. of twin rooms required
No. of suite rooms required
breakfast
lunch
dinner
Meal charge
type of meal
cost

119

Hotel Reservation

Guest
name
Single room
room no.
rate
Twin room
room no.
rate
Suite
room no.
rate
suite name
Customer
name, contact address, country, sex,
Cash payment
amount
Credit card payment
amount, Credit card type, number and issuing company
Traveler’s check payment
amount, Check No., issuing company 120

Hotel Reservation

Direct corporate billing payment
amount, corporate account number
Laundry charge
type of clothing
cost per piece
Laundry use
date of use
No. of pieces
type of clothing
Room service charge
type of service
cost

121

Hotel Reservation

(3) Test the 3 relationships between the
classes, has a or part of, uses or depends
on, kind of or is a.

Generalization specialization
Traveler’s check, Direct corporate billing, cash and
credit card are types of payment.
The general class is abstracted.
payment
amount

122

Hotel Reservation

Aggregation
laundry use is a set of objects.
laundry usage has many laundry items.
An aggregation can be used to represent laundry.
Association
The following shows the type:
Customer makes reservation.
rooms are assigned to the reservation.
guests belonging to the reservation
reservation requires meals
Reservation has a payment attached.
Payment comprises meals, room service, laundry service and room charge
When rooms are assigned to the reservation, an assignment class
representing the association is created.
The reservation object is associated with room objects through the room
assignment object. Each room object is related through one room
assignment object to the reservation.
This means one reservation may have one or more rooms.
One customer can make one or more reservations.
One reservation may have one or more guests.
Each reservation can have the meal options. 123

Hotel Reservation

(4) Consider the range, default and limitations of each attribute.

laundry charge
type of clothing: Shirt, Suits, Dress, Trousers, Others
cost per piece: 5, 12, 8, 9, 6
single room
room No.: 100 to 149, 200 to 249
rate 150
twin room
room No., 150 to 199, 250 to 299
rate 250
suite
room No., 300, 301, 302
rate 550
suite name Royal suite, Presidential suite, Honeymoon suite
meal charge
type of meal breakfast, lunch, dinner
cost: $10
124

[Statecharts]

(1) Consider the state changes induced by the use case.
Now that we have a set of classes, we can consider how the objects
representing each class is affected by the use cases.
The following shows the possible state changes and the classes affected:
accept reservation use case
The reservation object is created and the state is unpaid and room Unassigned.
It can also be a Block reservation if the reservation is made by the agency.
Or a Not Block reservation
assign rooms
The reservation object goes from room Unassigned to rooms Not checked in
state but is still in the unpaid state.
The association object (Room Assignment) is created with the state assigned
Not check in.
To represent the relationship between the reservation and the room
check in guests
The reservation object goes from rooms Not checked in state to Partial check
Out when the first guest checks in.
The Room Assignment object goes from the assigned Not check in to
Assigned Check in.
A change back to the same state is also allowed in this use case.
The reservation object goes from Partial check Out state to Partial check Out
when the other guests checks in.
126
If the last guest comes in then it becomes All Guest Check in.

[Statecharts]
cancel reservation
The reservation object goes from Rooms Not checked in if rooms are assigned or Room
Unassigned to Cancelled if the whole reservation is cancelled.
This represents the situation where only some guests are cancelled.
The reservation object goes from Rooms Not checked in to Rooms Not checked in.
check out guests
The reservation object goes from Unpaid to paid if the type of payment is cash, check or credit card.
The payment takes place in the check out.
If the type of payment is corporate, a different payment use case takes place after the checkout
representing the payment received from the corporate.
The reservation also goes from the Partial check in or all guest checked in to the partial checked
out if the there are still guests remaining in the hotel for the reservation.
The reservation also goes from partial checked out to partial checked out when the guests checked
out.
When the last guest checked out, the reservation goes to the All guest checked out.
The Room Assignment object goes from the assigned Not check in to Assigned Checkout.
receive payment
This is done either the checkout or a different use case depending upon the
Type of payment.
If the type of payment is corporate the payment is a separate use case as the
Hotel have to wait for notification of payment from the company.
For the other payment types, direct payment is made when the guests checked out
provide room service
The room service usage object is created.
provide laundry service 127
The laundry service usage object is created.

Activity Diagram

The activity diagram shows the actual steps performed in the use case.
It looks like a flowchart with the decisions represented by a diamond
and the tasks represented by a box.
(1) Make Reservation
The following shows the related tasks and decisions made when a
reservation is made.
- A customer specifies the type of accommodation, number required,
period of stay, and expected check in date.
- The person at the front desk checks the availability, and if available,
the following additional information is requested:
Name and Contact telephone of the person making the reservation
Name of the guest’s expected
Type of room for them
- The person at the front desk also asks if any combination of the
meals is required, i.e. breakfast, lunch or dinner.
- The person at the front desk then informs the customer of the
reservation identity.
130

Continuation….

142

Useful Websites

http://erwinglobio.wix.com/ittraining

http://ittrainingsolutions.webs.com/

http://erwinglobio.sulit.com.ph/

http://erwinglobio.multiply.com/

151

Unified Modeling Language

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (17)

Similar to Unified Modeling Language

Similar to Unified Modeling Language (20)

More from Prof. Erwin Globio

More from Prof. Erwin Globio (20)

Recently uploaded

Recently uploaded (20)

Unified Modeling Language