UML-casestudy.ppt

Unified Modeling Lanuage 1
CS-290 Intermediate Java
UML

1.15 Thinking About Objects: Introduction to Object Technology
and the Unified Modeling Language
• Object orientation
• Unified Modeling Language (UML)
– Graphical language that uses common notation
– Allows developers to represent object-oriented
designs

1.15 Thinking About Objects (cont.)
• Objects
– Reusable software components that model real-world
items
– Look all around you
• People, animals, plants, cars, etc.
– Attributes
• Size, shape, color, weight, etc.
– Behaviors
• Babies cry, crawl, sleep, etc.

• Object-oriented design (OOD)
– Models real-world objects
– Models communication among objects
– Encapsulates data (attributes) and functions
(behaviors)
• Information hiding
• Communication through well-defined interfaces
• Object-oriented language
– Programming is called object-oriented programming
(OOP)
– Java

• Object-Oriented Analysis and Design (OOAD)
– Essential for large programs
– Analyze program requirements, then develop solution
– We begin OOAD in Chapter 2
• Elevator-simulation case study

• History of the UML
– Need developed for process with which to approach
OOAD
– Brainchild of Booch, Rumbaugh and Jacobson
– Object Management Group (OMG) supervised
– Version 1.4 is current version
• Version 2.0 scheduled tentatively for release in 2002

• UML
– Graphical representation scheme
– Enables developers to model object-oriented systems
– Flexible and extendible

2.9 (Optional Case Study) Thinking About Objects: Examining the
Problem Statement
• Emphasize object-oriented programming (OOP)
• Object-oriented design (OOD) implementation
– Chapters 3 to 13, 15, 22
– Appendices G, H, I

2.9 (Optional Case Study) Thinking About Objects:
Examining the Problem Statement
• Program Goal
– Software simulator application
– 2-floor elevator simulator
• Models actual elevator operation
– Elevator graphics displayed to user
– Graphical user interface (GUI)
• User can control elevator

• Elevator Simulation
– Model people using elevator
– Elevator door, floor door, elevator button, floor
button, elevator shaft, bell, floor, backgrounds
• Operate accordingly or by request to avoid “injuring”
person and make useless operations
– Create person objects
– Simulation rules
• Elevator visits floor which person requests for elevator
service
• One person per elevator
• 5 seconds to move from floors

2.9 Thinking About Objects: Examining the
Problem Statement
• Application GUI
– First Floor/Second Floor buttons create person on
respective floors
• Disable button if floor occupied by a person already
• Unlimited number of passenger creations
– Animation requirements
• Passenger walking and pressing floor button
• Elevator moving, doors opening and closing
• Illumination of elevator lights and buttons during operation
– Incorporating sounds
• Footsteps when person walks
• Button pressing clicks
• Elevator bell rings upon elevator arrival, elevator music
• Doors creak when opening and closing

• Designing elevator system
– Specified in requirements document through OOD analysis
• UML
• Design used to implement Java code
– How system should be constructed to complete tasks
• System Structure
– System is a set of interactive components to solve problems
• Simplified by subsystems
– Simulator (through ch. 15), GUI (ch. 12 and 13, display (ch. 22)
– Describes system’s objects and inter-relationships
– System behavior describes how system changes through
object interaction

• UML diagram types
– System structure
• Class diagram (section 3.8)
– Models classes, or “building blocks” of a system
– Person, elevator, floor, etc.
• Object diagrams (section 3.8)
– Snapshot (model) of system’s objects and relationships at specific point in
time
• Component diagrams (section 13.17)
– Model components such as graphics resources and class packages that
make up the system
• Deployment diagrams (not discussed)
– Model hardware, memory and runtime resources

– System behavior
• Statechart diagrams (section 5.11)
– Model how object changes state
» Condition/behavior of an object at a specific time
• Activity diagrams (section 5.11)
– Flowchart modeling order and actions performed by object
• Collaboration diagrams (section 7.10)
– Emphasize what interactions occur
• Sequence diagrams (section 15.12)
– Emphasize when interactions occur
• Use-case diagrams (section 12.16)
– Represent interaction between user and system
» Clicking elevator button

Identifying the Classes in a Problem Statement
• Identifying classes in a System
– Nouns of system to implement elevator simulation
Nouns (and noun phrases) in
the problem statement
company elevator system graphical user interface (GUI)
office building elevator shaft elevator car
elevator display person
software-simulator application model floor (first floor; second floor)
passenger bell inside the elevator First Floor GUI button
floor door light on that floor Second Floor GUI button
user of our application energy audio
floor button capacity elevator music
elevator button
Fig. 3.19 Nouns (and noun phrases) in problem statement.

• Not all nouns pertain to model (not highlighted)
– Company and building not part of simulation
– Display, audio, and elevator music pertain to presentation
– GUI, user of application, First and Second Floor buttons
• How user controls model only
– Capacity of elevator only a property
– Energy preservation not modeled
– Simulation is the system
– Elevator and elevator car are same references
– Disregard elevator system for now

• Nouns highlighted to be implemented in system
– Elevator button and floor button separate functions
– Capitalize class names
• Each separate word in class name also capitalized
•ElevatorModel, ElevatorShaft, Elevator,
Person, Floor, ElevatorDoor, FloorDoor,
ElevatorButton, FloorButton, Bell, and Light

• Using UML to model elevator system
– Class diagrams models classes and relationships
• Model structure/building blocks of system
• Representing class Elevator using UML
– Top rectangle is class name
– Middle contains class’ attributes
– Bottom contains class’ operations
Elevator

• Class associations using UML
– Elided diagram
• Class attributes and operations ignored
• Class relation among ElevatorShaft, Elevator and
FloorButton
• Solid line is an association, or relationship between classes
• Numbers near lines express multiplicity values
– Indicate how many objects of class participate association
R
e quests
FloorButto n
ElevatorShaft
Elevator
1
1 1
2
2 1
Resets
Sig na ls
arriva l

– Diagram shows two objects of class FloorButton participate in
association with one object of ElevatorShaft
– FloorButton has two-to-one relationship with
ElevatorShaft
Symbol Meaning
0 None.
1 One.
m An integer value.
0..1 Zero or one.
m, n m or n
m..n At least m, but not more than n.
* Zero or more.
0..* Zero or more
1..* One or more
Fig. 3.22 Multiplic ity types.

– Associations can be named
• In diagram, “Requests” indicates association and arrow
indicates direction of association
– One object of FloorButton requests one object of class
Elevator
– Similar context with “Resets” and “Signals Arrival”
– Aggregation relationship
• Implies whole/part relationship
– Some object “has” some object
• Object attached with diamond is “owner”
– Object on other end is the “part”
• In diagram, elevator shaft “has an” elevator and two floor
buttons

L
ight E
leva to rMo del F
loo r
FloorDo or
E
leva to rDoor
Elev atorS
haft
E
lev ator
Bell
FloorButto n
E
le va to rButton
Perso n
C re ates
P
resses
P
resses
1
1
1
1
1
1
1
1 2
2
1
1
1
1 1
1
1
2
1
1
0..*
2
1
Req uests
1
1
R
id es
1
1
S
igna ls to
m ov e
Resets
Re sets
Walks
ac ross
Op ens
Opens
1
Ring s
T
urns
on/ off
S
ignals
a rriv al
1
1
1
1
Fig. 3.23 Class diagram for the elevator model.

• The complete class diagram for elevator model
– Several of many and aggregates
•ElevatorModel aggregates one ElevatorShaft and
two Floor
•Elevator is aggregation of ElevatorDoor,
ElevatorButton and Bell
– Several of many associations
•Person “presses” buttons
•Person also “rides” Elevator and “walks” across
Floor

firs
t Flo orLight : Light
: E
leva t orM odel
firs
t Flo or : Flo or
f irs
tFloorDoor : FloorDoor
: E
leva t orDoo r
: Elev at orS
ha ft
: Elev at or
: B
ell
firstFloorB
ut to n: Flo orBut ton
: Elev at orB
ut t on
s
ec ondFloor : Floor
sec ondFloorB
ut t on : FloorB
ut t on
s
ec ond Floo rDoo r : F
loo rDoor
s
e c ondFloorL
ight : L
ight
Fig. 3.24 Object diagram of an empty building in our elevator model.

• Object diagrams
– Model objects (instances of classes) at a specific time in
program execution
– Snapshot of system structure while running
• Information about participation of objects at that time
– Links
• Relationships between objects represented as solid lines
• Object diagram when no people in building
– No objects of class Person exist in system at this point
– Objects written in form objectName:ClassName
• UML permits omission of object names instantiated only once
• If object name unknown, just include class name

Identifying Class Attributes
• Classes have attributes (data)
– Implemented in Java programs as variables
– Attributes of real-world objects
• Radio (object)
– Station setting, volume setting, AM or FM (attributes)
• Identify attributes
– Look for descriptive words and phrases in problem statement
– Each identified word and phrase is a candidate attribute
• e.g., “the elevator is moving”
– “is moving” corresponds to boolean attribute moving
• e.g., “the elevator takes five seconds to travel between floors”
– corresponds to int attribute travelTime
» int travelTime = 5; (in Java)

Class Descriptive words and phrases
ElevatorModel number of people in the simulation
ElevatorShaft [no descriptive words or phrases]
Elevator moving
summoned
current floor
destination floor
capacity of only one person
five seconds to travel between floors
Person unique
waiting / moving
current floor
Floor first or second; capacity for only one person
FloorButton pressed / reset
ElevatorButton pressed / reset
FloorDoor door closed / door open
ElevatorDoor door closed / door open
Bell [no descriptive words or phrases]
Light illuminated / turned off
Fig. 4.17 Descriptive words and phrases from problem statement.

Identifying Class Attributes (cont.)
• UML class diagram
– Class attributes are place in the middle compartment
– Attributes are written language independently
• e.g., attribute open of class ElevatorDoor
– open : Boolean = false
• May be coded in Java as
– boolean open = false;

ElevatorShaft
<none ye t>
Elevator
mo ving : Boo le an = false
summ oned : Boolea n = fa lse
currentF
loo r : Integ er = 1
de stinationFlo or : Integer = 2
ca pa city : Inte ger = 1
tra velT
ime : Integer = 5
Perso n
ID : Integer
moving : Boolea n = true
currentFloor : Intege r
F
loo r
floorNumbe r : Integ er
cap acity : Integ er = 1
FloorButto n
pressed : Boolea n = fa lse
Eleva to rDoor
ope n : Boolean = fa lse
FloorDo or
ope n : Boolean = fa lse
Light
lightOn : Boolea n = fa lse
Bell
<no ne yet>
Eleva to rMo del
numb erOfPe ople : Integ er=0
Eleva to rButton
pressed : Boolea n = fa lse
Fig. 4.18 Classes with attributes.

Identifying Objects’ States and Activities
• State
– Describes an object’s condition at a given time
• Statechart diagram (UML)
– Express how an object can change state
– Express under what conditions an object can change state
– Diagram notation (Fig. 5.28)
• States are represented by rounded rectangles
– e.g., “Not Pressed” and “Pressed”
• Solid circle (with attached arrowhead) designates initial state
• Arrows represent transitions (state changes)
– Objects change state in response to messages
» e.g., “buttonPressed” and “buttonReset”

Fig. 5.28 Statechart diagram for FloorButton and ElevatorButton objects.
Not Pressed Pressed
buttonPressed
buttonReset
States
Initial state
Transitions
Transitions occur in
response to messages

5.11 Thinking About Objects (cont.):
• Activity diagram (UML)
– Models an object’s workflow during program
execution
– Models the actions that an object will perform
– Diagram notation (Fig. 5.28)
• Activities are represented by ovals
• Solid circle designates initial activity
• Arrows represents transitions between activities
• Small diamond represents branch
– Next transition at branch is based on guard condition

move toward floor button
[floor door closed]
Fig. 5.29 Activity diagram for a Person object.
press floor button
[floor door open]
wait for passenger (if there is one) to exit elevator wait for door to open
enter elevator
press elevator button
wait for door to open
exit elevator
Activities
Initial activity
Transitions
Branch
Guard condition determines
next activity

set summoned to true
[button on
current floor
pressed]
[elevator button
pressed]
set summoned to false
close elevator door
move to destination floor
reset elevator button
Fig. 5.30 Activity diagram for the Elevator object.
ring bell
open elevator door
[summoned] [not summoned]
[elevator idle] [elevator moving]
[button on
destination
floor pressed]
[button on
current floor
pressed]
[button on
destination
floor
pressed]

Identifying Class Operations
• Class operations
– Also known as behaviors
– Service the class provides to “clients” (users) of that
class
• e.g., radio’s operations
– Setting its station or volume

• Deriving class operations
– Use problem statement
• Identify verbs and verb phrases
• Verbs can help determine class operations

a
Class Verb phrases
Elevator moves to other floor, arrives at a floor, resets elevator
button, rings elevator bell, signals its arrival, opens its
door, closes its door
ElevatorShaft turns off light, turns on light, resets floor button
Person walks on floor, presses floor button, presses elevator
button, rides elevator, enters elevator, exits elevator
Floor [none in the problem statement]
FloorButton requests elevator
ElevatorButton closes elevator door, signals elevator to move to
opposite floor
FloorDoor signals person to enter elevator (by opening)
ElevatorDoor signals person to exit elevator (by opening), opens floor
door, closes floor door
Bell [none in the problem statement]
Light [none in the problem statement]
ElevatorModel creates person
Fig. 6.19 Verb phrases for each class in simulator.

– Verbs can help determine class operations
• e.g., verb phrase “the elevator resets its button”
– Elevator informs ElevatorButton to reset
– ElevatorButton needs method resetButton
• e.g., verb phrase “the elevator opens its door”
– Elevator informs ElevatorDoor to open
– ElevatorDoor needs method openDoor

– Not all verbs determine class operations
• e.g., verb phrase “the elevator arrives at a floor”
– Elevator decides when to arrive
» (after traveling 5 seconds)
– i.e., no object causes Elevator to arrive
– Elevator does not need to provide “arrival” service for other
objects
– arriveElevator is not a valid method (operation)
» We do not include method arriveElevator

• Store methods (operations) in UML class diagram
– Place class methods in bottom compartment of that
class

ElevatorModel
numberOfPeople : Integer=0
addPerson( ) : void
Person
ID : Integer
moving : Boolean = true
doorOpened( ) : void
Elevator
moving : Boolean = false
summoned : Boolean = false
currentFloor : Integer = 1
destinationFloor : Integer = 2
capacity : Integer = 1
travelTime : Integer = 5
ride( ) : void
requestElevator( ) : void
enterElevator( ) : void
exitElevator( ) : void
departElevator( ) : void
ElevatorShaft
<none yet>
<none yet>
ElevatorDoor
open : Boolean = false
addPerson( ) : void
ElevatorButton
pressed : Boolean = false
resetButton( ) : void
pressButton( ) : void
Light
lightOn : Boolean = false
turnOnLight( ) : void
turnOffLight( ) : void
Floor
floorNumber : Integer
capacity : Integer = 1
<none yet>
FloorButton
pressed : Boolean = false
resetButton( ) : void
pressButton( ) : void
Bell
<none yet>
ringBell( ) : void
ElevatorDoor
open : Boolean = false
openDoor( ) : void
closeDoor( ) : void

Collaboration Among Objects
• Collaborations
– When objects communicate to accomplish task
• Accomplished by invoking operations (methods)
– One object sends a message to another object
– In 6.17, we extracted verb phrases from problem
statement
• Verb phrases exhibit behaviors of classes
• “The elevator resets its button”
– Elevator object sends resetButton message to
ElevatorButton object
– Elevator collaborates with ElevatorButton

v
Class Verb phrases
Elevator Resets elevator button, rings elevator bell, signals its arrival,
signals its departure, opens its door, closes its door.
ElevatorShaft Turns off light, turns on light, resets floor button.
Person Presses floor button, presses elevator button, rides elevator,
enters elevator, exits elevator.
FloorButton Summons (requests) elevator.
ElevatorButton Signals elevator to move to opposite floor.
FloorDoor Signals person to enter elevator (by opening).
ElevatorDoor Signals person to exit elevator (by opening), opens floor
door, closes floor door.
ElevatorModel Creates person.
Fig. 7.17 Verb phrases for each class exhibiting behaviors in
simulation.

v
An object of cla s
s
... S
ends the mes
s
a ge... T
o a n object of cla s
s
...
Elevator resetButton
ringBell
elevatorArrived
elevatorDeparted
openDoor
closeDoor
ElevatorButton
Bell
ElevatorShaft
ElevatorShaft
ElevatorDoor
ElevatorDoor
ElevatorShaft resetButton
turnOnLight
turnOffLight
FloorButton
Light
Light
Person pressButton
enterElevator
exitElevator
FloorButton,
ElevatorButton
Elevator
Elevator
FloorButton requestElevator Elevator
ElevatorButton moveElevator Elevator
FloorDoor doorOpened
doorClosed
Person
Person
ElevatorDoor doorOpened
doorClosed
openDoor
closeDoor
Person
Person
FloorDoor
FloorDoor
F
ig. 7.18 Colla bora tions in the eleva tor system.

• Collaboration diagram (UML)
– Type of interaction diagram
• The other is sequence diagram, discussed in Chapter 15
– Models collaborations in system

• Collaboration-diagram notation
– Objects are written in form objectName :
ClassName
• Disregard objectName only when concerned about class
– Solid lines connect collaborating objects
– Arrows represent messages
• Indicates direction of collaboration
• Points toward object receiving message
• Can be implemented as a methods (synchronous calls) in
Java
– Message names appear next to arrows

: Person : FloorButton
pressButton( )
Fig. 7.19 Collaboration diagram of a person pressing a floor button.

• Collaboration-diagram sequence of messages
– Shows in what order objects send messages
– For diagrams modeling several collaborations
– Progresses in numerical order
• Least to greatest
• Numbering starts with message 1
• Follows a nested structure
– Message 1.1 is first message nested in message 1
– Message 3.2 is the second message nested in message 3
– Message can be passed only when all nested messages from
previous message have been passed

: FloorDoor
: FloorButton
4.1 : resetButton()
Fig. 7.20 Collaboration diagram for passengers exiting and entering the elevator.
: ElevatorShaft : Light
: Elevator
: Bell
: ElevatorButton : ElevatorDoor
ridingPassenger : Person
waitingPassenger : Person
3: openDoor( )
3.1.1 : doorOpened( )
4.2 : turnOnLight( )
4 : elevatorArrived( )
3.2.1 : exitElevator( )
3.2 : doorOpened( )
3.1 : openDoor( )
2 : ringBell( )
3.1.1.1 : enterElevator( )
1 : resetButton( )

• Collaborations in Fig. 7.20
– Message 1
• Elevator sends resetButton to ElevatorButton
– Message 2
• Elevator sends ringBell to Bell
– Message 3
• Elevator sends openDoor to ElevatorDoor
– Message 3.1
• ElevatorDoor sends openDoor to FloorDoor
– Message 3.1.1
• FloorDoor sends doorOpened to waitingPassenger
– Message 3.1.1.1
• waitingPassenger sends enterElevator to Elevator

• Collaborations in Fig. 7.20 (continued)
– Message 3.2
• ElevatorDoor sends doorOpened to ridingPassenger
– Message 3.2.1
• ridingPassenger sends exitElevator to Elevator
– Message 4
• Elevator sends elevatorArrived to ElevatorShaft
– Message 4.1
• ElevatorShaft sends resetButton to FloorButton
– Message 4.2
• ElevatorShaft sends turnOnLight to Light

• Unfortunately, this design has a problem
– waitingPassenger enters Elevator before
ridingPassenger exits
• We fix this in Section 15.12
• We modify this diagram in Section 10.22 (event handling)

Incorporating Inheritance into the Elevator
Simulation
• Our design can benefit from inheritance
– Examine sets of classes
– Look for commonality between/among sets
• Extract commonality into superclass
– Subclasses inherits this commonality

• ElevatorButton and FloorButton
– Treated as separate classes
– Both have attribute pressed
– Both have behaviors pressButton and resetButton
– Move attribute and behaviors into superclass Button?
• We must examine whether these objects have distinct behavior
– If same behavior
» They are objects of class Button
– If different behavior
» They are objects of distinct Button subclasses

Ele va to rButton
- pressed : Boolea n = fa lse
+ resetButton( ) : void
+ p ressButton( ) : void
FloorButto n
- pressed : Boolea n = fa lse
Fig. 9.35 Attributes and operations of classes FloorButton and ElevatorButton.

• ElevatorButton and FloorButton
– FloorButton requests Elevator to Floor of request
• Elevator will sometimes respond
– ElevatorButton signals Elevator to move
• Elevator will always respond
– Neither button decides for the Elevator to move
• Elevator decides itself
– Both buttons signal Elevator to move
• Therefore, both buttons exhibit identical behavior
– They are objects of class Button
– Combine (not inherit) ElevatorButton and FloorButton into class
Button

• ElevatorDoor and FloorDoor
– Treated as separate classes
– Both have attribute open
– Both have behaviors openDoor and closeDoor
– Both door “inform” a Person that a door has opened
• both doors exhibit identical behavior
– They are objects of class Door
– Combine (not inherit) ElevatorDoor and FloorDoor into
class Door

Fig. 9.36 Attributes and operations of classes FloorDoor and ElevatorDoor
Eleva to rDoor
- ope n : Boolean = fa lse
+ op enDoor( ) : void
+ closeDo or( ) : vo id
FloorDo or
- ope n : Boolean = fa lse

• Representing location of Person
– On what Floor is Person when riding Elevator?
– Both Floor and Elevator are types of locations
• Share int attribute capacity
• Inherit from abstract superclass Location
– Contains String locationName representing location
» “firstFloor”
» “secondFloor”
» “elevator”
– Person now contains Location reference
• References Elevator when person is in elevator
• References Floor when person is on floor

Fig. 9.37 Class diagram modeling generalization of superclass Location and subclasses
Elevator and Floor.
Loca tion
- loc atio nNa me : String
- cap acity : Intege r = 1 {froze n}
# setLo catio nName ( String ) : vo id
+ g etLo cationNam e( ) : String
+ g etCa pa city( ) : Integer
+ g etButton( ) : Butto n
+ g etDoor( ) : Doo r
Flo or
+ g etButto n( ) : Button
+ g etDo or( ) : Door
Elevator
- m oving : Bo olean = false
- sum moned : Boo lea n = false
- currentFlo or : Integ er
- d estina tionFloor : Inte ger
- tra velT
im e : Intege r = 5
+ ride( ) : void
+ req uestEleva to r( ) : void
+ enterElevator( ) : void
+ exitElevator( ) : void
+ dep artEle vator( ) : void
+ getButton( ) : Button
+ getDoo r( ) : Door
Italics indicate abstract
class or method
Pound sign (#) indicates
protected member Outline
Italics
indicate
abstract class
or method
Pound sign
(#) indicates
protected
member
{frozen}
{frozen} indicates
constant (final in Java)
Concrete classes implement
abstract methods

Fig. 9.38 Class diagram of our simulator (incorporating inheritance).
Light ElevatorModel Floor
ElevatorShaft
Bell
Person
Elevator
Button
- pressed : Boolean = false
+ pressButton( ) : void
Presses
2
2 2
2
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0..*
1
1
1
1
2
Signals to
move
Resets
Resets
Opens
Closes
Occupies
Signals
arrival
Rings
Location
- locationName : String
- capacity : Integer = 1 {frozen}
# setLocationName( String ) : void
+ getLocationName( ) : String
+ getCapacity( ) : Integer
+ getDoor( ) : Door
Creates
Doo r
- op en : Boolea n = fa lse
+ o penDoo r( ) : vo id
+ c lo seDoor( ) : void
Turns
on/off

Fig. 9.39 Class diagram with attributes and operations (incorporating inheritance).
Person
- ID : Integ er
- m oving : Bo olean = true
- loca tion : Lo cation
+ doo rOpe ned( ) : vo id
Ele va torShaft
Bell
Eleva torM odel
- numb erOfPe ople : Integ er = 0
+ ringBell( ) : void
Lig ht
- lig htOn : Boo lea n = false
+ turnOnLig ht( ) : vo id
+ turnOffLig ht( ) : vo id
+ a dd Pe rson( ) : vo id
Butto n
- pre ssed : Boolean = fa lse
+ re setButton( ) : void
Do or
- ope n : Boolean = false
Loca tion
- lo cationNam e : String
- cap ac ity : Integ er = 1 {frozen}
# setLocationNam e( String ) : void
+ getLoca tionNam e( ) : String
+ getC apa city( ) : Intege r
+ getDoor( ) : Door Flo or
Elevator
- currentFlo or : Location
- d estina tionFloor : Loca tion
- tra velT
im e : Intege r = 5
+ ride( ) : void

• Continue implementation
– Transform design (i.e., class diagram) to code
– Generate “skeleton code” with our design
• Use class Elevator as example
• Two steps (incorporating inheritance)

Step 1
public class Elevator extends Location {
// class constructor
public Elevator() {}
}

Event Handling
• How objects interact
– Sending object sends message to receiving object
– We discuss how elevator-system objects interact
• Model system behavior

• Event
– Message that notifies an object of an action
• Action: Elevator arrives at Floor
• Consequence: Elevator sends elevatorArrived
event to Elevator’s Door
– i.e., Door is “notified” that Elevator has arrived
• Action: Elevator’s Door opens
• Consequence: Door sends doorOpened event to
Person
– i.e., Person is “notified” that Door has opened
– Preferred naming structure
• Noun (“elevator”) preceded by verb (“arrived”)

ElevatorModelEvent.java
Line 8
Line 11
Line 14
1 // ElevatorModelEvent.java
2 // Basic event packet holding Location object
3 package com.deitel.jhtp4.elevator.event;
4
5 // Deitel packages
6 import com.deitel.jhtp4.elevator.model.*;
7
8 public class ElevatorModelEvent {
9
10 // Location that generated ElevatorModelEvent
11 private Location location;
12
13 // source of generated ElevatorModelEvent
14 private Object source;
15
16 // ElevatorModelEvent constructor sets Location
17 public ElevatorModelEvent( Object source,
Represents an event
in elevator simulation
Location object reference
represents location where even
was generated
Object object reference represents
object that generated event

ElevatorModelEvent.java
36 // set ElevatorModelEvent source
37 private void setSource( Object eventSource )
38 {
39 source = eventSource;
40 }
41
42 // get ElevatorModelEvent source
43 public Object getSource()
44 {
45 return source;
46 }
47 }

• Every object sends ElevatorModelEvent
– This may become confusing
•Door sends ElevatorModelEvent to Person upon
opening
•Elevator sends ElevatorModelEvent to Door
upon arrival
– Solution:
• Create several ElevatorModelEvent subclasses
– Each subclass better represents action
– e.g., BellEvent when Bell rings

Fig. 10.23 Class diagram that models the generalization between
ElevatorModelEvent and its subclasses.
Eleva torM ode lEvent
BellEvent Doo rEvent
Perso nMoveEve nt
ButtonEvent
ElevatorM ove Eve nt
LightEve nt

Fig. 10.24 Triggering actions of the ElevatorModelEvent subclass events.
Event Sent when (triggering action) Sent by object of class
BellEvent the Bell has rung Bell
ButtonEvent a Button has been pressed
a Button has been reset
Button
Button
DoorEvent a Door has opened
a Door has closed
Door
Door
LightEvent a Light has turned on
a Light has turned off
Light
PersonMoveEvent a Person has been created
a Person has arrived at the Elevator
a Person has entered the Elevator
a Person has exited the Elevator
a Person has pressed a Button
a Person has exited the simulation
Person
ElevatorMoveEvent the Elevator has arrived at a Floor
the Elevator has departed from a Floor
Elevator
Fig. 10.24 Triggering actions of the ElevatorModelEvent subclass events.

• Event handling
– Similar to collaboration
– Object sends message (event) to objects
• However, receiving objects must be listening for event
– Called event listeners
– Listeners must register with sender to receive event

• Modify collaboration diagram of Fig. 7.20
– Incorporate event handling (Fig. 10.25)
– Three changes
• Include notes
– Explanatory remarks about UML graphics
– Represented as rectangles with corners “folded over”
• All interactions happen on first Floor
– Eliminates naming ambiguity
• Include events
– Elevator informs objects of action that has happened
» Elevator notifies object of arrival

Fig. 10.25 Modified collaboration diagram for passengers entering and exiting the
Elevator on the first Floor.
firstFloorLight: Light
ele vatorDoor: Doo r
: ElevatorShaft
: Elevator
: Bell
firstFloorButton : Butto n
e levatorButton: Button
wa iting Passeng er : Perso n
firstF
loo rDoor : Do or
rid ingPa ssenger : Person
3.2.1 d oorOpened ( )
4.2.1 : turnOnLight( )
4.1.1 : resetButton( )
3.3.1 : e xitEleva to r( )
3.2.1.1 : enterElevator( )
4 : eleva to rArrived( )
3 : eleva to r
Arrived( )
3.2 : op enDoor( )
3.3 : doo rOpe ne d( )
3.1: op enDoor( )
1 : eleva to rArrived( )
1.1: resetButton( )
2.1: ring Bell( )
2 : eleva to r
Arrived( )
4.1 : eleva to rArrived( ) 4.2 : e levatorArrive d( )
<>
(DoorEvent)
<>
(Eleva to rMo veEvent)
<>
(Lo cation)

• Event listeners
– Elevator sends ElevatorMoveEvent
• All event classes (in our simulation) have this structure
– Door must implement interface that “listens” for this
event
– Door implements interface
ElevatorMoveListener
• Method elevatorArrived
– Invoked when Elevator arrives
• Method elevatorDeparted
– Invoked when Elevator departs

ElevatorMoveEvent.java
1 // ElevatorMoveEvent.java
2 // Indicates on which Floor the Elevator arrived or
departed
4
5 // Deitel package
7
8 public class ElevatorMoveEvent extends ElevatorModelEvent {
9
10 // ElevatorMoveEvent constructor
11 public ElevatorMoveEvent( Object source, Location
location )
12 {
13 super( source, location );
14 }
15 }

ElevatorMoveListener.java
1 // ElevatorMoveListener.java
2 // Methods invoked when Elevator has either
departed or arrived
4
5 public interface ElevatorMoveListener {
6
7 // invoked when Elevator has departed
8 public void elevatorDeparted( ElevatorMoveEvent
moveEvent );
9
10 // invoked when Elevator has arrived
11 public void elevatorArrived( ElevatorMoveEvent
moveEvent );
12 }

• Class diagram revisited
– Modify class diagram of Fig. 9.19 to include
• Signals (events)
– e.g., Elevator signals arrival to Light
• Self associations
– e.g., Light turns itself on and off

Fig. 10.28 Class diagram of our simulator (including event handling).
L
ight Eleva to rMo del F
loo r
ElevatorShaft
Bell
Perso n
Elevator
C re ates
Pre sses
2
2 2
2
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0..*
1
1
1
1
2
Signalsto
m ove
Resets
Op ens/
C lo ses
Occup ies
Signals
a rrival
T
urns
on/ off
Rings
Do or Button
L
o cation
Signals
a rrival
Sig na ls
arriva l
Sig na ls
arriva l
Signals
a rrival
Signals
a rrival
Info rmsof
o pening
1
1
1
1
1
1
1
1
1 1

Designing Interfaces With the UML
• Use UML to represent listener interfaces
– Class diagram modeling realizations
• Classes realize, or implement, interface behaviors
•Person realizes DoorListener
• In Java, class Person implements interface
DoorListener

Fig. 11.25 Class diagram that models class Person
realizing interface DoorListener.
«inte rfa ce»
DoorListener
+ doo rOpe ne d( Doo rEvent : do orEvent ) : vo id
+ do orC lo sed( Do orEvent : d oorEve nt ) : void
Perso n
- ID : Integer
- mo ving : Boo lea n = true
- lo cation : Loca tion
+ d oorOpened ( ) : void

Fig. 11.26 Elided class diagram that models class
Person realizing interface DoorListener
DoorListener
Perso n
- ID : Integer
- mo ving : Boo lea n = true
- lo cation : Loca tion
+ d oorOpened ( ) : void

1 // Person.java
2 // Generated from Fig. 11.24
3 public class Person implements DoorListener
{
4
5 // attributes
6 private int ID;
7 private boolean moving = true;
8 private Location location;
9
10 // constructor
11 public Person() {}
12
13 // methods of DoorListener
14 public void doorOpened( DoorEvent
doorEvent ) {}
15 public void doorClosed( DoorEvent
doorEvent ) {}
16 }
Person.java
Lines 3 and 14-15
Class Person must implement
DoorListener methods

Fig. 11.27 Class diagram that models realizations in
the elevator model.
Light
ElevatorModel
ElevatorShaft
Bell
Elevator
Person
Door Button
ButtonListener DoorListener
ElevatorMoveListener
PersonMoveListener
DoorListener
LightListener
ButtonListener DoorListener BellListener

Fig. 11.28 Class diagram for listener interfaces
«inte rface»
DoorListener
+ doo rOpe ne d( Doo rEvent : do orEvent ) : vo id
+ do orClo sed( Do orEvent : d oorEve nt ) : void
«interfa ce»
Be llListener
+ b ellRang ( BellEvent : be llEvent ) : void
«interfa ce»
ElevatorM oveListener
+ eleva to rArrived ( Eleva to rMo veEvent : e levatorMoveEvent ) : void
+ eleva to rDep arted ( ElevatorM ove Eve nt : eleva to rMo veEvent ) : void
«interfac e»
Perso nMoveListener
+ personCrea te d( PersonMoveEvent : p ersonM ove Event ) : vo id
+ personArrived ( Pe rsonM oveEvent : personMoveEvent ) : void
+ personDep arted ( PersonMoveEvent : pe rsonM oveEvent ) : void
+ personPresse dButton( PersonMoveEvent : personMo veEvent ) : vo id
+ personEntered( PersonMo veEvent : p erso nMoveEve nt ) : void
+ personExited( PersonMoveEvent : p erso nMoveEve nt ) : vo id
«inte rface»
LightListener
+ lightT
urne dOn( Lig htEvent : lig htEvent ) : vo id
+ lightT
urne dOff( Lig htEvent : lig htEvent ) : vo id
«interface»
ButtonListener
+ b uttonPresse d( ButtonEvent : b uttonEvent ) : void
+ b uttonReset( ButtonEvent : b uttonEvent ) : void

Use Cases
• Use case
– Represents capabilities that systems provide to clients
• Automated-teller-machine use cases
– “Deposit Money,” “Withdraw Money,” “Transfer Funds”

• Use-case diagram
– Models use cases in system
– Facilitates system-requirements gathering
– Notation
• Stick figure represents actor
– Actor represents set of roles that external entity can play
• System box (rectangle) contains system use cases
• Ovals represent use cases

• Elevator-simulation use cases
– “Create Person”
• From user’s perspective
– “Relocate Person” (move to other floor)
• From Person’s perspective
• Constructing GUI
– Use “Create Person” use case

Fig. 12.28 Use-case diagram for elevator simulation
from user’s perspective
C rea te Person
Elevator Sim ula tion
User

Fig. 12.28 Use-case diagram from the perspective of a
Person
Reloca te Person
Elevator
Perso n

9 // Java extension packages
10 import javax.swing.*;
11
14 import com.deitel.jhtp4.elevator.event.*;
15 import com.deitel.jhtp4.elevator.ElevatorConstants;
16
17 public class ElevatorController extends JPanel
18 implements ElevatorConstants {
19
20 // controller contains two JButtons
21 private JButton firstControllerButton;
22 private JButton secondControllerButton;
23
24 // reference to model
25 private ElevatorModel elevatorModel;
26
27 public ElevatorController( ElevatorModel model )
28 {
29 elevatorModel = model;
30 setBackground( Color.white );
31
32 // add first button to controller
33 firstControllerButton = new JButton( "First Floor" );
ElevatorController.java
Line 17
Lines 21-22
ElevatorController
GUI for elevator simulation
JButtons for creating
Persons on Floor

45 // invoked when a JButton has been
pressed
46 public void actionPerformed(
ActionEvent event )
47 {
48 // place Person on first Floor
49 elevatorModel.addPerson(
50 FIRST_FLOOR_NAME );
51
52 // disable user input
53 firstControllerButton.setEnabled(
false );
54 }
55 } // end anonymous inner class
56 );
57
58 // anonymous inner class registers to receive
ActionEvents
59 // from second Controller JButton
60 secondControllerButton.addActionListener(
61 new ActionListener() {
62
Lines 42-43 and 60-61
Lines 49-50 and 67-68
Register JButtons with
separate anonymous
ActionListeners
Add Person to respective
Floor, depending on
JButton that user pressed
Disable JButton after
Person is created (so user
cannot create more than one
Person on Floor)

81 // invoked when Person has entered
Elevator
82 public void personEntered(
83 PersonMoveEvent event )
84 {
85 // get Floor of departure
86 String location =
87
event.getLocation().getLocationName();
88
89 // enable first JButton if first
Floor departure
90 if ( location.equals(
FIRST_FLOOR_NAME ) )
91 firstControllerButton.setEnabled(
true );
92
93 // enable second JButton if second
Floor
94 else
95 secondControllerButton.setEnabled(
true );
Lines 78-79
Lines 90-95
Enable JButton after Person
enters Elevator (so user can
create another Person)
Enable ElevatorModel
to listener for
PersonMoveEvents

106 public void personExited(
107 PersonMoveEvent event ) {}
108
109 public void personDeparted(
111
112 public void personPressedButton(
114
115 } // end anonymous inner class
116 );
117 } // end ElevatorController constructor
118 } ElevatorController.java

1 // ElevatorConstants.java
2 // Constants used between ElevatorModel and
ElevatorView
3 package com.deitel.jhtp4.elevator;
4
5 public interface ElevatorConstants {
6
7 public static final String FIRST_FLOOR_NAME =
"firstFloor";
8 public static final String SECOND_FLOOR_NAME =
"secondFloor";
9 public static final String ELEVATOR_NAME =
"elevator";
10 }
ElevatorConstants.java
Lines 7-9
Classes use these constants
to refer to Locations

• Classes Location
– Subclasses Elevator and Floor
• Attribute capacity no longer needed

Fig. 12.32 Modfied class diagram showing
generalization of superclass Location and
subclasses Elevator and Floor.
Loca tion
- loc atio nNa me : String
# setLoca tionNam e( String ) : void
+ getLoca tionNam e( ) : String
Flo or
Elevator
- currentFlo or : Location
- d estina tionFloor : Loca tion
- tra velT
im e : Intege r = 5
+ ride( ) : void

Model-View-Controller
• Model-View-Controller
– Architectural pattern for building systems
– Divide system responsibilities into three parts
• Model
– Contains all program data and logic
• View
– Visual representation of model
• Controller
– Defines system behavior by sending user input to model
– Step by step
• User uses controller to change data in model
• Model then informs view of change
• View changes visual presentation to reflect change

• Model-View-Controller in elevator simulation
– Example
• User presses First Floor of Second Floor Jbutton
– Controller adds Person to model
• Model notifies view of Person’s creation
• View displays Person on Floor in response to
notification

Fig. 13.22 Class diagram of the elevator simulation.
ElevatorSim ula tion
1
1 1
1
a pp lica tion
ElevatorM od el ElevatorView
co ntroller
view
m odel
ja va x.swing.JFram e
ElevatorController
1 1
Ele va to rMo delListener

• Component diagram (UML)
– Models “pieces” (components) used by system
• e.g., .class file, .java files, images, packages, etc.
– Notation
• Components are represented as “plugs”
• Packages are represented as “folders”
• Dotted arrows indicate dependencies among components
– Changing one component requires changing another

Fir. 13.23 Component diagram for elevator
simulation
ElevatorSim ula tion.c la ss
view
controlle r
m ode l
Eleva to rSimulatio n.ja va
«co mp ilation»
1
1
1
1
1
«exec uta ble»
«file»
ElevatorMod el.ja va
«file»
ElevatorView .java
«file»
ElevatorContro ller.ja va
«file»
ElevatorM ode l-
Listener
1

ElevatorSimulation.java
Lines 12-13
Lines 19-21
Line 34
1 // ElevatorSimulation.java
2 // Application with Elevator Model, View, and
Controller (MVC)
3 package com.deitel.jhtp4.elevator;
4
5 // Java core packages
6 import java.awt.*;
7
8 // Java extension packages
9 import javax.swing.*;
10
13 import com.deitel.jhtp4.elevator.view.*;
14 import com.deitel.jhtp4.elevator.controller.*;
15
16 public class ElevatorSimulation extends JFrame {
17
Import packages model,
view and controller
ElevatorSimulation
aggregates one instance
each of classes
ElevatorModel,
ElevatorView and
ElevatorController
Register ElevatorModel as
listener for ElevatorView

ElevatorSimulation.java
Lines 37-38
36 // add view and controller to ElevatorSimulation
37 getContentPane().add( view, BorderLayout.CENTER );
38 getContentPane().add( controller,
BorderLayout.SOUTH );
39
40 } // end ElevatorSimulation constructor
41
42 // main method starts program
43 public static void main( String args[] )
44 {
45 // instantiate ElevatorSimulation
46 ElevatorSimulation simulation = new
ElevatorSimulation();
47 simulation.setDefaultCloseOperation( EXIT_ON_CLOSE
);
48 simulation.pack();
49 simulation.setVisible( true );
50 }
51 }
Add ElevatorView and
ElevatorController to
ElevatorSimulation

Multithreading
• Concurrent models
– UML contains support for building concurrent models
– Discus how simulation benefits from multithreading
•waitingPassenger must wait for
ridingPassenger to exit Elevator
• Use synchronized method
– Guarantees only one Person in Elevator at a time

Multithreading
• Threads, Active Classes and Synchronized
method
– UML represents a thread as an active class
• Thick black border in UML diagram indicates an active
class
– Synchronized Methods in UML
• Notation B/A to indicates A must wait for B to finish

Multithreading
• Sequence Diagrams
– Shows interactions between objects
• Shows messages passed between objects over time
– Rectangle enclosing an object name represents that object
• Use same naming conventions as collaboration diagrams
– Lifeline
• Dotted line running down from an object name
• Actions occur on lifeline in chronological order, top to bottom
– Arrows
• Dashed arrows
– Represent “return messages,” return of control to object
• Solid arrows
– A message sent from one object to another

Multithreading
• Class diagram now uses active classes
– Elevator and Person are now active classes

Multithreading
f irs
t F
loo rLig ht : Lig ht
e lev at orDoor : Doo r
: E
leva t orS
ha ft
: E
lev at or
: Bell
firs
t F
lo orBut ton : But t on
e lev at orB
ut to n : Butt on
wa it ing Pas
s
eng er : Pers
o n
firs
t F
loorDo or : Door
rid ingPa s
s
enger : Pers
on
3.2.1 : do orO p ened( )
4. 2.1 : t urnO nLig ht( )
4. 1.1 : res
et B
ut t on( )
3.3.1 : exitEle vat or( )
4 : eleva to rA rriv ed( )
3 : eleva to r
A rriv ed( )
3.2 : o penDoo r( )
3.3 : doo rO pe ne d( )
3.1 : openDoo r( )
1 : eleva to rA rriv ed( )
1.1 : res
et Butt on( )
2.1 : ringBell( )
2 : elev at or
A rrived ( )
4.1 : elev at orArrived ( ) 4.2 : eleva t orA rrived ( )
<<pa ra met er>>
(Doo rE
v ent )
<>
(E
le va to rMo veE
v ent )
<>
(L
o c at io n)
3.2.1. 2 : ride( )
{c onc urrent}
3.3.1 / 3.2. 1.1 : e nt erE
leva to r( )
Fig. 15.18 Modified collaboration diagram with active classes for passengers entering and exiting the Elevator.

Multithreading
p re s
s
But t o n ( )
d o o rO p e n e d ( )
rid e ( ) {c o n c u rre n t}
re q u e s
t E
le va to r( )
e le va to rA rri
v e d ( )
p re s
s
But t o n ( )
e le va to rA rri
v e d ( )
o p e n Do o r( )
c lo s
e Do o r( )
c lo s
e Do o r( )
o p e n Do o r( )
s
e t Mo v i
n g ( tru e )
d o o rO p e n e d ( )
[El
e va t o r
o n s
a me
F
l
o o r o f
re q u e s
t ]
p e rs
o n : Pe rs
o n
f l
o o rBu tt o n : B
u t t o n
e le va to rBu tt o n : B
u t t o n
e le va to r: El
e va t o r
f l
o o rDo o r : Do o r
e le va t o rDo o r : Do o r
p e rso n e xits
e le va to r
p e rs
o n e n t e rs
e le va to r
p e rs
o n w a it s
fo r e le va t o r
i
n t e rru p t ( )
p e rs
o n rid e s
e le v a t o r
[E
l
e va to r o n
o p p o s
it e
F
l
o o r o f
re q u e s
t ]
b u t to n P
re s
s
e d ( )
e l
e v a t o r t ra ve ls
5 se c o n d s
s
e t Mo vin g ( f a ls
e )
e le va to rt ra ve l
s
to o t h e r f lo o r
t e rmin a t e
m e t h o d rid e
Fig. 15.19 Sequence diagram for a single Person changing floors in system.

Multithreading
L
ight E
leva to rMo del F
loo r
Elev at orS
haft
Bell
Pers
o n
E
lev at or
C re at es
Pre s
s
es
2
2 2
2
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0.. *
1
1
1
1
2
S
ignalst o
m ove
Res
et s
O p ens/
C lo s
es
O c c up ies
S
ignals
a rriv al
T
urns
on/ off
Rings
Do or Butt on
L
o c at ion
S
ignals
a rriv al
S
ig na ls
arriva l
S
ig na ls
arriva l
S
ignals
a rriv al
S
ignals
a rriv al
Info rms of
o pening
1
1
1
1
1
1
1
1
1 1
Fig. 15.20 Final class diagram of the elevator simulation

UML-casestudy.ppt

More Related Content

Similar to UML-casestudy.ppt (20)

More from Ramanamurthy Banda (11)

Recently uploaded (20)

UML-casestudy.ppt