2006 doan van ban, ioit. all rights reserved. 1 case study: e levator system simulation program goal...

2006 Doan Van Ban, IOIT. All rights reserved.

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


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


3


• 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


4



5



6



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


8


• 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


9


– 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


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 graphical user interface (GUI)

office building elevator shaft person elevator floor door floor (first floor; second floor) software-simulator application bell inside the elevator First Floor GUI button passenger light on that floor Second Floor GUI button user of our application energy audio floor button capacity elevator music elevator button elevator car display Fig. 3.15 Nouns (and noun phrases) in problem statement.


11


• 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


12


• 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


13


• 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


14


• 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

Requests

1

1 1

2

2

ElevatorShaft

FloorButton Elevator1

ResetsSignalsarrival


15


– 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.


16


– 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


17


Fig. 3.23 Class diagram for the elevator model.

1

11

1 22

1

1

1

1 1

1

11

1

2

1

1

1

1

1

Person

FloorDoor

Light

Floor

ElevatorShaftFloorButton

ElevatorDoor Elevator ElevatorButton

Bell

Requests

Presses

Presses

Rides

Signals to move

Resets

Resets

Walks across

Opens

Opens

1

Rings

Turns on/off

Signalsarrival

1

1

1

1

passenger


182.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


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)


20

Class Descriptive words and phrases 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 turned on / turned off Fig. 4.17 Descriptive words and phrases from problem statement.


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;


22

Fig. 3.4 Classes with attributes.

Person

ID : Integermoving : Boolean = truecurrentFloor : Integer

Elevator

moving : Boolean = falsesummoned : Boolean = falsecurrentFloor : Integer = 1destinationFloor : Integer = 2capacity : Integer = 1travelTime : Integer = 5

ElevatorShaft

Floor

floorNumber : Integercapacity : Integer = 1

ElevatorButton

pressed : Boolean = false

FloorButton

pressed : Boolean = false

ElevatorDoor

open : Boolean = false

Light

lightOn : Boolean = false

Bell

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


24

Fig. 4.28 Activity diagram for a Person object.

[floor door closed]

press elevator button

enter elevator

move toward floor button

wait for door to open

press floor button

wait for door to open

[floor door open]

exit elevator

wait for passenger to exit elevator

[passenger on elevator][no passenger on

elevator]


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


26

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] Fig. 6.19 Verb phrases for each class in simulator.


27


• 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


28


• 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


29


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


30

Fig. 4.29 Activity diagram for the Elevator object.

close elevator door

ring bell

reset elevator button

[elevator idle][button on destination floor

pressed]

open elevator door

[elevator moving]

[button on current floorpressed]

[floor button pressed]

[elevator button pressed]

[summoned][not summoned]

set summoned to true

set summoned to false

move to destination floor

[button on destination floorpressed]

[button on current floorpressed]


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


32

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 Fig. 7.16 Verb phrases for each class exhibiting behaviors in

simulation.


33

An object of class... Sends the message... To an object of class... 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

Fig. 7.17 Collaborations in the elevator system.


34


• Collaboration diagram (UML)– Type of interaction diagram

• The other is sequence diagram, discussed in Chapter 16

– Models collaborations in system


35


• 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


36

Fig. 7.18 Collaboration diagram of a person pressing a floor button.

pressButton( )

: FloorButton: Person


37


• 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


38

Fig. 7.19 Collaboration diagram for passengers exiting and entering the elevator.

: Elevator

: Light: FloorButton : ElevatorShaft

: Person

: ElevatorDoor

: ElevatorButton : Bell

: FloorDoor

passenger : Person

3.1.1 doorOpened( )

4.2 : turnOnLight( )4.1 : resetButton( )

3.2.1 : exitElevator( )

3.1.1.1 : enterElevator( )

4 : elevatorArrived( )

3.1 : openDoor( )

3.2 : doorOpened( )

3: openDoor( )

1: resetButton( )

2: ringBell( )


39


• 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


40


• 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


417.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



Simulation• Class diagram (UML)

– Member-access modifiers• public

– Denoted by plus sign (+)

• private– Denoted by minus sign (-)


43

Fig 8.19 Class diagram with visibility notations.

Floor

- floorNumber : Integer- capacity : Integer = 1

ElevatorButton

- pressed : Boolean = false+ resetButton( ) : void+ pressButton( ) : void

ElevatorDoor

- open : Boolean = false

+ openDoor( ) : void+ closeDoor( ) : void

Light

- lightOn : Boolean = false

+ turnOnLight( ) : void+ turnOffLight( ) : void

Bell

+ ringBell( ) : void

ElevatorShaft

FloorButton

- pressed : Boolean = false

+ resetButton( ) : void+ pressButton( ) : void

Person

- ID : Integer- moving : Boolean = true

+ doorOpened() : void

Elevator- moving : Boolean = falsesummoned:Boolean = false- currentFloor : Integer = 1- destinationFloor:Integer = 2- capacity : Integer = 1- travelTime : Integer = 5

+ ride( ) : void+ requestElevator( ) : void+ enterElevator( ) : void+ exitElevator( ) : void+ departElevator( ) : void

FloorDoor





Simulation• Navigability

– Indicate in which direction an association can be navigated

– Help programmers determine which objects need references to other objects


45

Fig 8.20 Class diagram with navigability.

1

11

1 22

1

1

1

1 1

1

1

1

1

2

1

1

1

1

1

Person

FloorDoor

Light

Floor

ElevatorShaftFloorButton

ElevatorDoor Elevator ElevatorButton

Bell

Requests

Presses

Presses

Rides

Signals to move

Resets

Resets

Walks across

Opens

Opens

1

Rings

Turns on/off

Signals arrival

1

1

1

1

passenger



Simulation• Implementation

– Forward engineering• Transform design (i.e., class diagram) to code



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



Simulation

public class Elevator {

public Elevator() {}}

Step 1



Simulation


// 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() {}}

Step 2



Simulation



// associated objects private ElevatorDoor elevatorDoor; private ElevatorButton elevatorButton; private Bell bell;


Step 3



Simulation public class Elevator {


// 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() {}}

Step 4


529.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


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?


54

Fig. 9.24 Attributes and operations of classes FloorButton and ElevatorButton.

ElevatorButton



FloorButton




55


• 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


56


• 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


57

Fig. 10.25 Class diagram modeling generalization of superclass Location and subclasses Elevator and Floor.

Floor

+ getButton( ) : Button+ getDoor( ) : Door

Elevator- moving : Boolean = falsesummoned : Boolean = false- currentFloor : Integer- destinationFloor : Integer- travelTime : Integer = 5

+ ride( ) : void+ requestElevator( ) : void+ enterElevator( ) : void+ exitElevator( ) : void+ departElevator( ) : void+ getButton( ) : Button+ getDoor( ) : Door

Location- locationName : String- capacity : Integer = 1 {frozen}

# setLocationName( String ) : void+ getLocationName( ) : String+ getCapacity( ) : Integer+ getButton( ) : Button+ getDoor( ) : Door


58


• 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


59

Fig. 10.26 Attributes and operations of classes FloorDoor and ElevatorDoor.

ElevatorDoor



FloorDoor



Fig. 9.27 Generalization of superclass Door and subclass ElevatorDoor.

ElevatorDoor


Door




60

Fig. 9.28 Class diagram of our simulator (incorporating inheritance).

LightFloorElevatorShaft

Elevator

Person

Bell

2

2 2

1

1

1

1

1

1

1

1

1

1

1

1

0..*

1

1

1

1

2

Button- pressed : Boolean = false


Door- open : Boolean = false


Presses

Signals to move

Resets

Resets

Opens

Closes

Occupies

Signalsarrival

Turns on/off

Rings

Location

- locationName : String- capacity : Integer = 1 {frozen}

Opens/Closes

1

ElevatorDoor1



61

Fig. 9.29 Class diagram with attributes and operations (incorporating inheritance).

Light

- lightOn : Boolean = false

+ turnOnLight( ) : void+ turnOffLight( ) : void

Bell

+ ringBell( ) : void

ElevatorShaft

Button- pressed : Boolean = false


Person

- ID : Integer- moving : Boolean = true- location : Location

+ doorOpened( ) : void

ElevatorDoor


Location- locationName : String- capacity : Integer = 1 {frozen}


Floor

+ getButton( ) : Button+ getDoor( ) : Door

Elevator- moving : Boolean = falsesummoned : Boolean = false- currentFloor : Location- destinationFloor : Location- travelTime : Integer = 5

+ ride( ) : void+ requestElevator( ) : void+ enterElevator( ) : void+ exitElevator( ) : void+ departElevator( ) : void+ getButton( ) : Button+ getDoor( ) : Door

Door- open : Boolean = false



62


• 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)


63


public class Elevator extends Location {


Outline64

Elevator.java

1 // Elevator.java

2 // Generated using class diagrams 10.28 and 10.29

3 public class Elevator extends Location {

4

5 // attributes

6 private boolean moving;

7 private boolean summoned;

8 private Location currentFloor;

9 private Location destinationFloor;

10 private int travelTime = 5;

11 private Button elevatorButton;

12 private Door elevatorDoor;

13 private Bell bell;

14

15 // constructor

16 public Elevator() {}

17

18 // operations

19 public void ride() {}

20 public void requestElevator() {}

21 public void enterElevator() {}

22 public void exitElevator() {}

23 public void departElevator() {}

24

Outline65

Elevator.java

25 // method overriding getButton

26 public Button getButton()

27 {

28 return elevatorButton;

29 }

30

31 // method overriding getDoor

32 public Door getDoor()

33 {

34 return elevatorDoor;

35 }

36 }


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


67


• 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”)

Outline68

ElevatorSimulationEvent.java

Line 8

Line 11

Line 14

1 // ElevatorSimulationEvent.java

2 // Basic event packet holding Location object

3 package com.deitel.jhtp5.elevator.event;

4

5 // Deitel packages

6 import com.deitel.jhtp5.elevator.model.*;

7

8 public class ElevatorSimulationEvent {

9

10 // Location that generated ElevatorSimulationEvent

11 private Location location;

12

13 // source of generated ElevatorSimulationEvent

14 private Object source;

15

16 // ElevatorSimulationEvent constructor sets Location

17 public ElevatorSimulationEvent( Object source,

18 Location location )

19 {

20 setSource( source );

21 setLocation( location );

22 }

23

Represents an event in elevator simulation

Location object reference represents location where even

was generated

Object object reference represents object that generated event

Outline69

ElevatorSimulationEvent.java

24 // set ElevatorSimulationEvent Location

25 public void setLocation( Location eventLocation )

26 {

27 location = eventLocation;

28 }

29

30 // get ElevatorSimulationEvent Location

31 public Location getLocation()

32 {

33 return location;

34 }

35

36 // set ElevatorSimulationEvent source

37 private void setSource( Object eventSource )

38 {

39 source = eventSource;

40 }

41

42 // get ElevatorSimulationEvent source

43 public Object getSource()

44 {

45 return source;

46 }

47 }


70


• 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


71

Fig. 10.26 Class diagram that models the generalization between ElevatorSimulationEvent and its subclasses.

ElevatorSimulationEvent

BellEvent DoorEvent

PersonMoveEvent

ButtonEvent

ElevatorMoveEvent

LightEvent


72

Fig. 10.27 Triggering actions of the ElevatorSimulationEvent 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. 11.27 Triggering actions of the ElevatorSimulationEvent subclass events.


73


• 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


74


• 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


75

Fig. 10.28 Modified collaboration diagram for passengers entering and exiting the Elevator on the first Floor

: Elevator

firstFloorLight: LightfirstFloorButton : Button : ElevatorShaft

waitingPassenger : Person

: ElevatorDoor

firstFloorDoor : Door

ridingPassenger : Person

3.2.1 doorOpened( DoorEvent )

4.2.1 : turnOnLight( )4.1.1 : resetButton( )

3.3.1 : exitElevator( )3.2.1.1 : enterElevator( )

4 : elevatorArrived( ElevatorMoveEvent )

3.2 : openDoor( )

3.3 : doorOpened( )

3.1: openDoor( Location )

1 :

elev

ator

Arrive

d( E

leva

t

orM

oveE

vent

)

4.1 : elevatorArrived( ElevatorMoveEvent )

4.2 : elevatorArrived( ElevatorMoveEvent )

2 :

ele

vato

rArrive

d( E

levato

rMo

veE

ven

t ): Bell

2.1: ringBell( )

elevatorButton: Button

1.1: resetButton( )

3 : elevatorArrived( Eleva

torMoveEvent )


76


• 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

Outline77

ElevatorMoveEvent.java

1 // ElevatorMoveEvent.java

2 // Indicates on which Floor the Elevator arrived or departed


4

5 // Deitel package

6 import com.deitel.jhtp5.elevator.model.*;

7

8 public class ElevatorMoveEvent extends ElevatorSimulationEvent {

9

10 // ElevatorMoveEvent constructor

11 public ElevatorMoveEvent( Object source, Location location )

12 {

13 super( source, location );

14 }

15 }

Outline78

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 }


79


• 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


80

Fig. 10.31 Class diagram of our simulator (including event handling)

Light

Floor

ElevatorShaft

Elevator

Person

Bell

2

2 2

1

1

1

1

1

1

1

1

1 1

1 11

1

1

2

Presses

Signals to move

ResetsOpens / Closes

Occupies

Signalsarrival

Turns on/off

Rings

Door Button

Location

Signals arrival

Signalsarrival

Signalsarrival

Signalsarrival

Signalsarrival

Informs of opening

1

1

1

1

1

1

1

1

11

1

Opens/Closes

1

ElevatorDoor

1


8111.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

JavaInterface DoorListener

+ doorOpened( doorEvent : DoorEvent ) : void+ doorClosed( doorEvent : DoorEvent ) : void

Person

- ID : Integer- moving : Boolean = true- location : Location+ doorOpened( ) : void+ doorClosed( ) : void

DoorListenerPerson

- ID : Integer- moving : Boolean = true- location : Location+ doorOpened( ) : void+ doorClosed( ) : void

Elided class diagram that models class Person realizing interface DoorListener

Outline82

Person.java

Lines 3-15

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 }

Class Person must implement DoorListener methods


83

Fig. 11.27 Class diagram that models realizations in the elevator model

Light

ElevatorShaft

Bell

Person

Door Button

ButtonListener DoorListener

ElevatorMoveListener

DoorListenerLightListener

Elevator

ButtonListener DoorListener BellListener


84

Fig. 11.28 Class diagram for listener interfaces

JavaInterface DoorListener

+ doorOpened( DoorEvent : doorEvent ) : void+ doorClosed( DoorEvent : doorEvent ) : void

JavaInterface BellListener

+ bellRang( BellEvent : bellEvent ) : void

JavaInterface ElevatorMoveListener

+ elevatorArrived( ElevatorMoveEvent : elevatorMoveEvent ) : void+ elevatorDeparted( ElevatorMoveEvent : elevatorMoveEvent ) : 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

JavaInterface LightListener

+ lightTurnedOn( LightEvent : lightEvent ) : void+ lightTurnedOff( LightEvent : lightEvent ) : void

JavaInterface ButtonListener

+ buttonPressed( ButtonEvent : buttonEvent ) : void+ buttonReset( ButtonEvent : buttonEvent ) : void

2006 doan van ban, ioit. all rights reserved. 1 case study: e levator system simulation program goal...

Documents