Transcript Elevator - WordPress.com

1
Case Study: Elevator System Simulation
• Program Goal
– Software simulator application
– N-floor elevator simulator
• Models actual elevator operation
– Elevator graphics displayed to user
– Graphical user interface (GUI)
• User can control elevator
 2006 Doan Van Ban, IOIT. All rights reserved.
2
1. Elevator system Requirements
• 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
 2006 Doan Van Ban, IOIT. All rights reserved.
3
1. Elevator system Requirements
• 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
 2006 Doan Van Ban, IOIT. All rights reserved.
4
1. Elevator system Requirements
 2006 Doan Van Ban, IOIT. All rights reserved.
5
1. Elevator system Requirements
 2006 Doan Van Ban, IOIT. All rights reserved.
6
1. Elevator system Requirements
 2006 Doan Van Ban, IOIT. All rights reserved.
7
2.
Designing elevator system
• 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
– Describes system’s objects and inter-relationships
– System behavior describes how system changes through object
interaction
 2006 Doan Van Ban, IOIT. All rights reserved.
8
2.
Designing elevator system
• UML diagram types
– System structure
• Class diagram
– Models classes, or “building blocks” of a system
– Person, elevator, floor, etc.
• Object diagrams
– Snapshot (model) of system’s objects and relationships at
specific point in time
• Component diagrams
– Model components such as graphics resources and class
packages that make up the system
• Deployment diagrams (not discussed)
– Model hardware, memory and runtime resources
 2006 Doan Van Ban, IOIT. All rights reserved.
9
2.
Designing elevator system
– System behavior
• Statechart diagrams
• Model how object changes state
• Condition/behavior of an object at a specific time
• Activity diagrams
– Flowchart modeling order and actions performed by object
• Collaboration diagrams
– Emphasize what interactions occur
• Sequence diagrams
– Emphasize when interactions occur
• Use-case diagrams
– Represent interaction between user and system
• Clicking elevator button
 2006 Doan Van Ban, IOIT. All rights reserved.
10
2.4 Case Study: 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
office building
elevator shaft
elevator
floor door
software-simulator application
bell inside the elevator
passenger
light on that floor
user of our application
energy
floor button
capacity
elevator button
elevator car
Fig. 3.15 Nouns (and noun phrases) in problem statement.
 2006 Doan Van Ban, IOIT. All rights reserved.
graphical user interface (GUI)
person
floor (first floor; second floor)
First Floor GUI button
Second Floor GUI button
audio
elevator music
display
11
2.4 Case Study: Identifying the Classes in a
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
 2006 Doan Van Ban, IOIT. All rights reserved.
12
2.4 Case Study: Identifying the Classes in a
Problem Statement
• 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
• ElevatorShaft, Elevator, Person, Floor,
ElevatorDoor, FloorDoor, ElevatorButton,
FloorButton, Bell, and Light
 2006 Doan Van Ban, IOIT. All rights reserved.
13
2.4 Case Study: Identifying the Classes in a
Problem Statement
• Using UML to model elevator system
– Class diagrams models classes and relationships
• Model structure/building blocks of system
• Representing class Elevator using UML
Elevator
– Top rectangle is class name
– Middle contains class’ attributes
– Bottom contains class’ operations
 2006 Doan Van Ban, IOIT. All rights reserved.
14
2.4 Case Study: Identifying the Classes in a
Problem Statement
• Class associations using UML
– Elided diagram
• Class attributes and operations ignored
• Class relation among ElevatorShaft, Elevator and
FloorButton
ElevatorShaft
1
1
Resets
Signals
arrival
2
1
2
FloorButton
Requests
1
Elevator
• Solid line is an association, or relationship between classes
• Numbers near lines express multiplicity values
– Indicate how many objects of class participate association
 2006 Doan Van Ban, IOIT. All rights reserved.
15
2.4 Case Study: Identifying the Classes in a
Problem Statement
– 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.18 Multiplicity types.
 2006 Doan Van Ban, IOIT. All rights reserved.
16
2.4 Case Study: Identifying the Classes in a
Problem Statement
– 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
 2006 Doan Van Ban, IOIT. All rights reserved.
17
2.4 Case Study: Identifying the Classes in a
Problem Statement
Fig. 3.23 Class diagram for the elevator model.
1
Floor
2
Walks
across
Turns on/off
Light
1
Resets
ElevatorShaft
FloorDoor
2
1
1
1
FloorButton
2
1
1
1
1
1
Presses
Signalsarrival
Requests
Person
Opens
Presses
1
1
1
1
1
Signals to
move
Opens
ElevatorDoor
Elevator
1
1
1
1
Resets
ElevatorButton
1
1
Rings
Rides
1
Bell
 2006 Doan Van Ban, IOIT. All rights reserved.
1
passenger
2.4 Case Study: Identifying the Classes in a
Problem Statement
• The complete class diagram for elevator model
– Several of many and aggregates
• Elevator is aggregation of ElevatorDoor,
ElevatorButton and Bell
– Several of many associations
• Person “presses” buttons
• Person also “rides” Elevator and “walks” across Floor
 2006 Doan Van Ban, IOIT. All rights reserved.
18
19
3.8
Case Study: 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)
 2006 Doan Van Ban, IOIT. All rights reserved.
20
Cla ss
ElevatorShaft
Desc rip tive wo rd s a nd p hra ses
[no descriptive words or phrases]
Elevator
moving
summoned
current floor
destination floor
capacity of only one person
five seconds to travel between floors
unique
waiting / moving
current floor
first or second; capacity for only one person
pressed / reset
pressed / reset
door closed / door open
door closed / door open
Person
Floor
FloorButton
ElevatorButton
FloorDoor
ElevatorDoor
Bell
Light
Fig. 4.17
[no descriptive words or phrases]
turned on / turned off
Desc rip tive wo rd s a nd p hra ses fro m p ro b lem sta tem ent.
 2006 Doan Van Ban, IOIT. All rights reserved.
21
3.9
Case Study: Identifying Class Attributes
• 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;
 2006 Doan Van Ban, IOIT. All rights reserved.
22
ElevatorDoor
ElevatorShaft
open : Boolean = false
Person
ID : Integer
moving : Boolean = true
currentFloor : Integer
Floor
lightOn : Boolean = false
Bell
floorNumber : Integer
capacity : Integer = 1
ElevatorButton
Elevator
moving : Boolean = false
summoned : Boolean = false
currentFloor : Integer = 1
destinationFloor : Integer = 2
capacity : Integer = 1
travelTime : Integer = 5
Light
pressed : Boolean = false
FloorButton
pressed : Boolean = false
Fig. 3.4 Classes with attributes.
 2006 Doan Van Ban, IOIT. All rights reserved.
FloorDoor
open : Boolean = false
23
4.9 Case Study: Identifying Objects’ States and Activities
• 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
 2006 Doan Van Ban, IOIT. All rights reserved.
24
move toward floor button
[floor door closed]
press floor button
[floor door open]
wait for door to open
[no passenger on
elevator]
[passenger on elevator]
wait for passenger to exit elevator
enter elevator
press elevator button
wait for door to open
exit elevator
Fig. 4.28 Activity diagram for a Person object.
 2006 Doan Van Ban, IOIT. All rights reserved.
25
5.12 Case Study: 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
 2006 Doan Van Ban, IOIT. All rights reserved.
26
Class
Elevator
Verb phrases
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]
Fig. 6.19
Verb phrases for each class in simulator.
 2006 Doan Van Ban, IOIT. All rights reserved.
27
5.12 Case Study: Identifying Class Operations
• Deriving class operations
– Verbs can help determine class operations
• e.g., verb phrase “resets elevator button”
– Elevator informs ElevatorButton to reset
– ElevatorButton needs method resetButton
• e.g., verb phrase “signal its arrival”
– Elevator informs ElevatorDoor to open
– ElevatorDoor needs method openDoor
 2006 Doan Van Ban, IOIT. All rights reserved.
28
5.12 Case Study: Identifying Class Operations
• Deriving class operations
– 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
 2006 Doan Van Ban, IOIT. All rights reserved.
29
5.12 Case Study: Identifying Class Operations
• Store methods (operations) in UML class diagram
– Place class methods in bottom compartment of that class
 2006 Doan Van Ban, IOIT. All rights reserved.
30
[floor button
pressed]
[elevator button
pressed]
set summoned to false
[button on destination[elevator idle]
floor
pressed]
[elevator moving]
close elevator door
[button on
destination
floor
pressed]
move to destination floor
reset elevator button
[button on
current floor
pressed]
ring bell
[button on
current floor
pressed]
set summoned to true
open elevator door
[summoned]
[not summoned]
Fig. 4.29 Activity diagram for the Elevator object.
 2006 Doan Van Ban, IOIT. All rights reserved.
31
6.9 Case Study: 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.15, 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
 2006 Doan Van Ban, IOIT. All rights reserved.
32
Class
Elevator
Verb phrases
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
Fig. 7.16
Verb phrases for each class exhibiting behaviors in
simulation.
 2006 Doan Van Ban, IOIT. All rights reserved.
33
An object of class...
Elevator
Sends the message... To an object of class...
resetButton
ElevatorButton
ringBell
Bell
elevatorArrived ElevatorShaft
elevatorDeparted ElevatorShaft
openDoor
ElevatorDoor
closeDoor
ElevatorDoor
ElevatorShaft
resetButton
FloorButton
turnOnLight
Light
turnOffLight
Light
Person
pressButton
FloorButton, ElevatorButton
enterElevator
Elevator
exitElevator
Elevator
FloorButton
requestElevator Elevator
ElevatorButton
moveElevator
Elevator
FloorDoor
doorOpened
Person
doorClosed
Person
ElevatorDoor
doorOpened
Person
doorClosed
Person
openDoor
FloorDoor
closeDoor
FloorDoor
Fig. 7.17 Collaborations in the elevator system.
 2006 Doan Van Ban, IOIT. All rights reserved.
34
6.9 Case Study: Collaboration Among Objects
• Collaboration diagram (UML)
– Type of interaction diagram
• The other is sequence diagram, discussed in Chapter 16
– Models collaborations in system
 2006 Doan Van Ban, IOIT. All rights reserved.
35
6.9 Case Study: Collaboration Among Objects
• 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
 2006 Doan Van Ban, IOIT. All rights reserved.
36
pressButton( )
: Person
: FloorButton
Fig. 7.18 Collaboration diagram of a person pressing a floor button.
 2006 Doan Van Ban, IOIT. All rights reserved.
37
6.9 Case Study: Collaboration Among Objects
• 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
 2006 Doan Van Ban, IOIT. All rights reserved.
38
3.1 : openDoor( )
3.1.1 doorOpened( )
: FloorDoor
4.1 : resetButton( )
4.2 : turnOnLight( )
: ElevatorShaft
: FloorButton
: Light
4 : elevatorArrived( )
: Person
passenger : Person
: Elevator
3.2.1 : exitElevator( )
3.1.1.1 : enterElevator( )
3.2 : doorOpened( )
1: resetButton( )
2: ringBell( )
: ElevatorButton
3: openDoor( )
: Bell
: ElevatorDoor
Fig. 7.19 Collaboration diagram for passengers exiting and entering the elevator.
 2006 Doan Van Ban, IOIT. All rights reserved.
39
6.9 Case Study: Collaboration Among Objects
• Collaborations in Fig.6.19
– 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
 2006 Doan Van Ban, IOIT. All rights reserved.
40
6.9 Case Study: Collaboration Among Objects
• Collaborations in Fig. 6.20 (continued)
– Message 3.2
• ElevatorDoor sends doorOpened to
ridingPassenger
– Message 3.2.1
• Person 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
 2006 Doan Van Ban, IOIT. All rights reserved.
41
7.15 Case Study: Starting to Program the
Classes for the Elevator Simulation
• Visibility
– Apply member-access modifiers to class members
– public methods
• to provide services to clients
– private variables
• To promote encapsulation
 2006 Doan Van Ban, IOIT. All rights reserved.
42
7.15 Case Study: Starting to Program the
Classes for the Elevator Simulation
• Class diagram (UML)
– Member-access modifiers
• public
– Denoted by plus sign (+)
• private
– Denoted by minus sign (-)
 2006 Doan Van Ban, IOIT. All rights reserved.
43
Person
ElevatorShaft
- ID : Integer
- moving : Boolean = true
- open : Boolean = false
+ openDoor( ) : void
+ closeDoor( ) : void
+ doorOpened() : void
Elevator
- moving : Boolean = false
- summoned:Boolean = false
- currentFloor : Integer = 1
- destinationFloor:Integer = 2
- capacity : Integer = 1
- travelTime : Integer = 5
ElevatorDoor
Floor
- floorNumber : Integer
- capacity : Integer = 1
Light
- lightOn : Boolean = false
+ turnOnLight( ) : void
+ turnOffLight( ) : void
ElevatorButton
+ ride( ) : void
+ requestElevator( ) : void
+ enterElevator( ) : void
+ exitElevator( ) : void
+ departElevator( ) : void
+ resetButton( ) : void
+ pressButton( ) : void
FloorButton
- pressed : Boolean = false
+ resetButton( ) : void
+ pressButton( ) : void
Bell
- pressed : Boolean = false
+ ringBell( ) : void
FloorDoor
- open : Boolean = false
+ openDoor( ) : void
+ closeDoor( ) : void
Fig 8.19 Class diagram with visibility notations.
 2006 Doan Van Ban, IOIT. All rights reserved.
44
7.15 Case Study: Starting to Program the
Classes for the Elevator Simulation
• Navigability
– Indicate in which direction an association can be navigated
– Help programmers determine which objects need references
to other objects
 2006 Doan Van Ban, IOIT. All rights reserved.
45
1
Floor
2
Light
FloorDoor
Walks
across
Turns on/off
1
ElevatorShaft
2
1
Resets
1
FloorButton
2
1
1
1
Signals
arrival
Opens
ElevatorDoor
Opens
1
Presses 1
Person
Presses
1
1
Signals to
move
1
Resets
1
ElevatorButton
1
Rings
1
Bell
Fig 8.20 Class diagram with navigability.
 2006 Doan Van Ban, IOIT. All rights reserved.
1
1
1
Elevator
1
1
Requests
1
1
1
Rides
passenger
46
7.15 Case Study: Starting to Program the
Classes for the Elevator Simulation
• Implementation
– Forward engineering
• Transform design (i.e., class diagram) to code
 2006 Doan Van Ban, IOIT. All rights reserved.
47
7.15 Case Study: Starting to Program the
Classes for the Elevator Simulation
• We generate “skeleton code” with our design
– Use class Elevator as example
– Four steps:
• Use name in first compartment to declare public class
– Empty constructor
• Use attributes in second compartment to declare instance
variables
• Use associations in class diagram (Fig. 3.19) to declare object
references
• Use operations in third compartment to declare methods
 2006 Doan Van Ban, IOIT. All rights reserved.
48
7.15 Case Study: Starting to Program the
Classes for the Elevator Simulation
Step 1
public class Elevator {
public Elevator() {}
}
 2006 Doan Van Ban, IOIT. All rights reserved.
49
7.15 Case Study: Starting to Program the
Classes for the Elevator Simulation
Step 2
public class Elevator {
// attributes
private boolean moving;
private boolean summoned;
private int currentFloor = 1;
private int destinationFloor = 2;
private int capacity = 1;
private int travelTime = 5;
// constructor
public Elevator() {}
}
 2006 Doan Van Ban, IOIT. All rights reserved.
50
7.15 Case Study: Starting to Program the
Classes for the Elevator Simulation
Step 3
public class Elevator {
// attributes
private boolean moving;
private boolean summoned;
private int currentFloor = 1;
private int destinationFloor = 2;
private int capacity = 1;
private int travelTime = 5;
// associated objects
private ElevatorDoor elevatorDoor;
private ElevatorButton elevatorButton;
private Bell bell;
// constructor
public Elevator() {}
}
 2006 Doan Van Ban, IOIT. All rights reserved.
51
7.15 Case Study: Starting to Program the
Classes for the Elevator Simulation
Step 4
public class Elevator {
// attributes
private boolean moving;
private boolean summoned;
private int currentFloor = 1;
private int destinationFloor = 2;
private int capacity = 1;
private int travelTime = 5;
// associated objects
private ElevatorDoor elevatorDoor;
private ElevatorButton elevatorButton;
private Bell bell;
// constructor
public Elevator() {}
// operations
public void ride() {}
public void requestElevator() {}
public void enterElevator() {}
public void exitElevator() {}
public void departElevator() {}
}
 2006 Doan Van Ban, IOIT. All rights reserved.
52
9.11 Case Study: 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
 2006 Doan Van Ban, IOIT. All rights reserved.
53
9.11 Thinking About Objects (cont.)
• ElevatorButton and FloorButton
–
–
–
–
Treated as separate classes
Both have attribute pressed
Both have operations pressButton and resetButton
Move attribute and operations into superclass Button?
 2006 Doan Van Ban, IOIT. All rights reserved.
54
FloorButton
ElevatorButton
- pressed : Boolean = false
- pressed : Boolean = false
+ resetButton( ) : void
+ pressButton( ) : void
+ resetButton( ) : void
+ pressButton( ) : void
Fig. 9.24 Attributes and operations of classes FloorButton and ElevatorButton.
 2006 Doan Van Ban, IOIT. All rights reserved.
55
9.11 Thinking About Objects (cont.)
• ElevatorButton and FloorButton
– FloorButton requests Elevator to move
– ElevatorButton signals Elevator to move
– Neither button orders the Elevator to move
• Elevator responds depending on its state
– Both buttons signal Elevator to move
• Different objects of the same class
– They are objects of class Button
– Combine (not inherit) ElevatorButton and
FloorButton into class Button
 2006 Doan Van Ban, IOIT. All rights reserved.
56
9.11 Thinking About Objects (cont.)
• 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
 2006 Doan Van Ban, IOIT. All rights reserved.
57
Location
- locationName : String
- capacity : Integer = 1 {frozen}
# setLocationName( String ) : void
+ getLocationName( ) : String
+ getCapacity( ) : Integer
+ getButton( ) : Button
+ getDoor( ) : Door
Elevator
- moving : Boolean = false
- summoned : Boolean = false
- currentFloor : Integer
- destinationFloor : Integer
- travelTime : Integer = 5
Floor
+ getButton( ) : Button
+ getDoor( ) : Door
+ ride( ) : void
+ requestElevator( ) : void
+ enterElevator( ) : void
+ exitElevator( ) : void
+ departElevator( ) : void
+ getButton( ) : Button
+ getDoor( ) : Door
Fig. 10.25 Class diagram modeling generalization of superclass Location and
subclasses Elevator and Floor.
 2006 Doan Van Ban, IOIT. All rights reserved.
58
9.11 Thinking About Objects (cont.)
• ElevatorDoor and FloorDoor
– Both have attribute open
– Both have operations openDoor and closeDoor
– Different behavior
• Rename FloorDoor to Door
• ElevatorDoor is “special case” of Door
– Override methods openDoor and closeDoor
 2006 Doan Van Ban, IOIT. All rights reserved.
59
FloorDoor
ElevatorDoor
- open : Boolean = false
- open : Boolean = false
+ openDoor( ) : void
+ closeDoor( ) : void
+ openDoor( ) : void
+ closeDoor( ) : void
Fig. 10.26 Attributes and operations of classes FloorDoor and ElevatorDoor.
Door
ElevatorDoor
- open : Boolean = false
+ openDoor( ) : void
+ closeDoor( ) : void
+ openDoor( ) : void
+ closeDoor( ) : void
Fig. 9.27 Generalization of superclass Door and subclass ElevatorDoor.
 2006 Doan Van Ban, IOIT. All rights reserved.
60
2
Light
Turns
on/off
1
1
ElevatorShaft
1
Resets
Floor
1
2
2
Door
- open : Boolean = false
Button
Signals
arrival
+ openDoor( ) : void
+ closeDoor( ) : void
0..*
- pressed : Boolean = false
1
+ resetButton( ) : void
+ pressButton( ) : void
Presse
1
s
Person
1
1
1
Opens/Closes
1
1
1
Opens
Signals to
move
1
Elevator
ElevatorDoor
Closes
1
1
1
Rings
1
2
Occupies
Resets
Location
- locationName : String
- capacity : Integer = 1 {frozen}
1
# setLocationName( String ) : void
+ getLocationName( ) : String
+ getCapacity( ) : Integer
+ getButton( ) : Button
+ getDoor( ) : Door
Bell
Fig. 9.28 Class diagram of our simulator (incorporating inheritance).
 2006 Doan Van Ban, IOIT. All rights reserved.
61
Location
- locationName : String
- capacity : Integer = 1 {frozen}
# setLocationName( String ) : void
+ getLocationName( ) : String
+ getCapacity( ) : Integer
+ getButton( ) : Button
+ getDoor( ) : Door
Light
- lightOn : Boolean = false
+ turnOnLight( ) : void
+ turnOffLight( ) : void
ElevatorShaft
Person
- ID : Integer
- moving : Boolean = true
- location : Location
+ doorOpened( ) : void
Floor
+ getButton( ) : Button
+ getDoor( ) : Door
Elevator
- moving : Boolean = false
- summoned : Boolean = false
- currentFloor : Location
- destinationFloor : Location
- travelTime : Integer = 5
+ ride( ) : void
+ requestElevator( ) : void
+ enterElevator( ) : void
+ exitElevator( ) : void
+ departElevator( ) : void
+ getButton( ) : Button
+ getDoor( ) : Door
Door
Bell
+ ringBell( ) : void
Button
- pressed : Boolean = false
+ resetButton( ) : void
+ pressButton( ) : void
ElevatorDoor
- open : Boolean = false
+ openDoor( ) : void
+ closeDoor( ) : void
+ openDoor( ) : void
+ closeDoor( ) : void
Fig. 9.29 Class diagram with attributes and operations (incorporating inheritance).
 2006 Doan Van Ban, IOIT. All rights reserved.
62
9.11 Thinking About Objects (cont.)
• Implementation: Forward Engineering
(Incorporating Inheritance)
– Transform design (i.e., class diagram) to code
– Generate “skeleton code” with our design
• Use class Elevator as example
• Two steps (incorporating inheritance)
 2006 Doan Van Ban, IOIT. All rights reserved.
63
9.11 Thinking About Objects (cont.)
public class Elevator extends Location {
// constructor
public Elevator() {}
}
 2006 Doan Van Ban, IOIT. All rights reserved.
64
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// Elevator.java
// Generated using class diagrams 10.28 and 10.29
public class Elevator extends Location {
// attributes
private boolean moving;
private boolean summoned;
private Location currentFloor;
private Location destinationFloor;
private int travelTime = 5;
private Button elevatorButton;
private Door elevatorDoor;
private Bell bell;
// constructor
public Elevator() {}
// operations
public void ride() {}
public void requestElevator() {}
public void enterElevator() {}
public void exitElevator() {}
public void departElevator() {}
Outline
Elevator.java
65
25
26
27
28
29
30
31
32
33
34
35
36
// method overriding getButton
public Button getButton()
{
return elevatorButton;
}
// method overriding getDoor
public Door getDoor()
{
return elevatorDoor;
}
}
Outline
Elevator.java
66
10.5 Case Study: Thinking About Objects Event Handling
• How objects interact
– Sending object sends message to receiving object
– We discuss how elevator-system objects interact
• Model system behavior
 2006 Doan Van Ban, IOIT. All rights reserved.
67
10.5 Case Study: Thinking About Objects Event Handling
• 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”)
 2006 Doan Van Ban, IOIT. All rights reserved.
68
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Outline
// ElevatorSimulationEvent.java
// Basic event packet holding Location object
package com.deitel.jhtp5.elevator.event;
ElevatorSimulat
ionEvent.java
// Deitel packages
import com.deitel.jhtp5.elevator.model.*;
public class ElevatorSimulationEvent {
Represents an event
in elevator simulation
Line 8
Line 11
// Location that generated ElevatorSimulationEvent Location object reference
private Location location;
represents location where even
was generated Line 14
// source of generated ElevatorSimulationEvent
private Object source;
Object object reference represents
Location object that generated event
// ElevatorSimulationEvent constructor sets
public ElevatorSimulationEvent( Object source,
Location location )
{
setSource( source );
setLocation( location );
}
69
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// set ElevatorSimulationEvent Location
public void setLocation( Location eventLocation )
{
location = eventLocation;
}
// get ElevatorSimulationEvent Location
public Location getLocation()
{
return location;
}
// set ElevatorSimulationEvent source
private void setSource( Object eventSource )
{
source = eventSource;
}
// get ElevatorSimulationEvent source
public Object getSource()
{
return source;
}
}
Outline
ElevatorSimulat
ionEvent.java
70
10.5 Case Study: Thinking About Objects Event Handling
• Objects send ElevatorSimulationEvent
– This may become confusing
• Door sends ElevatorSimulationEvent to Person
upon opening
• Elevator sends ElevatorSimulationEvent to Door
upon arrival
– Solution:
• Create several ElevatorSimulationEvent subclasses
– Each subclass better represents action
– e.g., BellEvent when Bell rings
 2006 Doan Van Ban, IOIT. All rights reserved.
71
Fig. 10.26 Class diagram that models the generalization between
ElevatorSimulationEvent and its subclasses.
ElevatorSimulationEvent
BellEvent
DoorEvent
LightEvent
PersonMoveEvent
 2006 Doan Van Ban, IOIT. All rights reserved.
ButtonEvent
ElevatorMoveEvent
72
Fig. 10.27 Triggering actions of the
ElevatorSimulationEvent subclass events
Event
BellEvent
Sent when (triggering action)
the Bell has rung
Sent by object of class
Bell
ButtonEvent
a Button has been pressed
a Button has been reset
a Door has opened
a Door has closed
a Light has turned on
a Light has turned off
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
the Elevator has arrived at a Floor
the Elevator has departed from a Floor
Button
Button
Door
Door
Light
DoorEvent
LightEvent
PersonMoveEvent
ElevatorMoveEvent
Person
Elevator
Fig. 11.27 Triggering actions of the ElevatorSimulationEvent subclass events.
 2006 Doan Van Ban, IOIT. All rights reserved.
73
10.5 Case Study: Thinking About Objects Event Handling
• 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
 2006 Doan Van Ban, IOIT. All rights reserved.
74
10.5 Case Study: Thinking About Objects Event Handling
• Modify collaboration diagram of Fig. 7.19
– Incorporate event handling (Fig. 10.28)
– 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
 2006 Doan Van Ban, IOIT. All rights reserved.
75
Fig. 10.28 Modified collaboration diagram for passengers entering
and exiting the Elevator on the first Floor
3.2.1 doorOpened( DoorEvent )
3.2 : openDoor( )
firstFloorDoor : Door
4.1.1 : resetButton( )
firstFloorButton : Button
4.2.1 : turnOnLight( )
: ElevatorShaft
4.1 : elevatorArrived(
ElevatorMoveEvent )
firstFloorLight: Light
4.2 : elevatorArrived( ElevatorMoveEvent )
4 : elevatorArrived( ElevatorMoveEvent )
waitingPassenger : Person
ridingPassenger : Person
: Elevator
3.2.1.1 : enterElevator( )
3.3.1 : exitElevator( )
2 : elevatorArrived(
ElevatorMoveEvent )
elevatorButton: Button
1.1: resetButton( )
 2006 Doan Van Ban, IOIT. All rights reserved.
: Bell
2.1: ringBell( )
3.3 : doorOpened( )
: ElevatorDoor
3.1: openDoor( Location )
76
10.5 Case Study: Thinking About Objects Event Handling
• 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
 2006 Doan Van Ban, IOIT. All rights reserved.
77
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// ElevatorMoveEvent.java
// Indicates on which Floor the Elevator arrived or departed
package com.deitel.jhtp5.elevator.event;
// Deitel package
import com.deitel.jhtp5.elevator.model.*;
public class ElevatorMoveEvent extends ElevatorSimulationEvent {
// ElevatorMoveEvent constructor
public ElevatorMoveEvent( Object source, Location location )
{
super( source, location );
}
}
Outline
ElevatorMoveEve
nt.java
78
1
2
3
4
5
6
7
8
9
10
11
12
// ElevatorMoveListener.java
// Methods invoked when Elevator has either departed or arrived
package com.deitel.jhtp5.elevator.event;
public interface ElevatorMoveListener {
// invoked when Elevator has departed
public void elevatorDeparted( ElevatorMoveEvent moveEvent );
// invoked when Elevator has arrived
public void elevatorArrived( ElevatorMoveEvent moveEvent );
}
Outline
ElevatorMoveLis
tener.java
79
10.5 Case Study: Thinking About Objects Event Handling
• Class diagram revisited
– Modify class diagram of Fig. 10.28 to include
• Signals (events)
– e.g., Elevator signals arrival to Light
• Self associations
– e.g., Light turns itself on and off
 2006 Doan Van Ban, IOIT. All rights reserved.
80
Fig. 10.31 Class diagram of our simulator
(including event handling)
1
1
Light
ElevatorShaft
1
2
Opens /
Closes
1
Door
1
1
Signalsar
rival
Resets
1
Signals
arrival
1
1
1
1
Turns
on/off
2
Signals arrival
2
Button
1
Presses
1
Person
1
1
1
1
Informs of
opening
Opens/Closes
1
1
1
Elevator
ElevatorDoor
Signals
arrival
1
Signals
arrival
Rings
1
1
1
Signals to
move
1
Bell
 2006 Doan Van Ban, IOIT. All rights reserved.
1
1
Occupies
Signals
arrival
2
1
Location
Floor
81
11.9 Case Study: Thinking About Objects 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
Person
- ID : Integer
- moving : Boolean = true
- location : Location
+ doorOpened( ) : void
+ doorClosed( ) : void
JavaInterface
DoorListener
+ doorOpened( doorEvent : DoorEvent ) : void
+ doorClosed( doorEvent : DoorEvent ) : void
Elided class diagram that models class Person realizing interface DoorListener
Person
- ID : Integer
- moving : Boolean = true
- location : Location
+ doorOpened( ) : void
+ doorClosed( ) : void
 2006 Doan Van Ban, IOIT. All rights reserved.
DoorListener
82
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Person.java
// Generated from Fig. 11.24
public class Person implements DoorListener {
Outline
Person.java
// attributes
private int ID;
private boolean moving = true;
private Location location;
// constructor
public Person() {}
// methods of DoorListener
public void doorOpened( DoorEvent doorEvent ) {}
public void doorClosed( DoorEvent doorEvent ) {}
}
Lines 3-15
Class Person must implement
DoorListener methods
83
Fig. 11.27 Class diagram that models
realizations in the elevator model
ButtonListener
DoorListener
BellListener
Elevator
LightListener
ButtonListener
DoorListener
ElevatorShaft
DoorListener
Person
ElevatorMoveListener
Door
 2006 Doan Van Ban, IOIT. All rights reserved.
Light
Bell
Button
84
Fig. 11.28 Class diagram for listener interfaces
JavaInterface
BellListener
+ bellRang( BellEvent : bellEvent ) : void
JavaInterface
ButtonListener
+ buttonPressed( ButtonEvent : buttonEvent ) : void
+ buttonReset( ButtonEvent : buttonEvent ) : void
JavaInterface
DoorListener
+ doorOpened( DoorEvent : doorEvent ) : void
+ doorClosed( DoorEvent : doorEvent ) : void
JavaInterface
ElevatorMoveListener
+ elevatorArrived( ElevatorMoveEvent : elevatorMoveEvent ) : void
+ elevatorDeparted( ElevatorMoveEvent : elevatorMoveEvent ) : void
JavaInterface
LightListener
+ lightTurnedOn( LightEvent : lightEvent ) : void
+ lightTurnedOff( LightEvent : lightEvent ) : void
JavaInterface
PersonMoveListener
+ personCreated( PersonMoveEvent : personMoveEvent ) : void
+ personArrived( PersonMoveEvent : personMoveEvent ) : void
+ personDeparted( PersonMoveEvent : personMoveEvent ) : void
+ personPressedButton( PersonMoveEvent : personMoveEvent ) : void
+ personEntered( PersonMoveEvent : personMoveEvent ) : void
+ personExited( PersonMoveEvent : personMoveEvent ) : void
 2006 Doan Van Ban, IOIT. All rights reserved.