 2006 Doan Van Ban, IOIT. All rights reserved. 1 Case Study: E levator System Simulation Program Goal –Software simulator application –N-floor elevator.

 2006 Doan Van Ban, IOIT. All rights reserved. 1 Case Study: E levator 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. 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. 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 –Top rectangle is class name –Middle contains class’ attributes –Bottom contains class’ operations Elevator

 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 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 11 2 2 ElevatorShaft FloorButtonElevator 1 Resets Signals arrival

 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

 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.23Class diagram for the elevator model. 1 1 1 12 2 1 1 1 11 1 1 1 1 2 1 1 1 1 1 Person FloorDoor Light Floor ElevatorShaft FloorButton ElevatorDoorElevator ElevatorButton Bell Requests Presses Rides Signals to move Resets Walks across Opens 1 Rings Turns on/off Signalsarrival 1 1 1 1 passenger

 2006 Doan Van Ban, IOIT. All rights reserved. 18 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. 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. 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 Fig. 3.4 Classes with attributes. Person ID : Integer moving : Boolean = true currentFloor : Integer Elevator moving : Boolean = false summoned : Boolean = false currentFloor : Integer = 1 destinationFloor : Integer = 2 capacity : Integer = 1 travelTime : Integer = 5 ElevatorShaft Floor floorNumber : Integer capacity : Integer = 1 ElevatorButton pressed : Boolean = false FloorButton pressed : Boolean = false ElevatorDoor open : Boolean = false Light lightOn : Boolean = false Bell FloorDoor open : Boolean = false

 2006 Doan Van Ban, IOIT. All rights reserved. 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 Fig. 4.28Activity 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]

 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. 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 Fig. 4.29Activity 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 floor pressed] [floor button pressed] [elevator button pressed] [summoned] [not summoned] set summoned to true set summoned to false move to destination floor [ button on destination floor pressed] [button on current floor pressed]

 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. 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. 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 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( )

 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 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 = 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 FloorDoor - open : Boolean = false + openDoor( ) : void + closeDoor( ) : void

 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 Fig 8.20 Class diagram with navigability. 1 1 1 122 1 1 1 11 1 1 1 1 2 1 1 1 1 1 Person FloorDoor Light Floor ElevatorShaft FloorButton ElevatorDoorElevator ElevatorButtonBell Requests Presses Rides Signals to move Resets Walks across Opens 1 Rings Turns on/off Signals arrival 1 1 1 1 passenger

 2006 Doan Van Ban, IOIT. All rights reserved. 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. 49 7.15 Case Study: Starting to Program the Classes for the Elevator Simulation 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() {} } Step 2

 2006 Doan Van Ban, IOIT. All rights reserved. 50 7.15 Case Study: Starting to Program the Classes for the Elevator Simulation 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() {} } Step 3

 2006 Doan Van Ban, IOIT. All rights reserved. 51 7.15 Case Study: Starting to Program the Classes for the Elevator Simulation 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() {} } Step 4

 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 Fig. 9.24 Attributes and operations of classes FloorButton and ElevatorButton. ElevatorButton - pressed : Boolean = false + resetButton( ) : void + pressButton( ) : void FloorButton - pressed : Boolean = false + resetButton( ) : void + pressButton( ) : void

 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 Fig. 10.25 Class diagram modeling generalization of superclass Location and subclasses Elevator and Floor. Floor + getButton( ) : Button + getDoor( ) : Door Elevator - moving : Boolean = false - summoned : 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

 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 Fig. 10.26 Attributes and operations of classes FloorDoor and ElevatorDoor. ElevatorDoor - open : Boolean = false + openDoor( ) : void + closeDoor( ) : void FloorDoor - open : Boolean = false + openDoor( ) : void + closeDoor( ) : void Fig. 9.27 Generalization of superclass Door and subclass ElevatorDoor. ElevatorDoor + openDoor( ) : void + closeDoor( ) : void Door - open : Boolean = false + openDoor( ) : void + closeDoor( ) : void

 2006 Doan Van Ban, IOIT. All rights reserved. 60 Fig. 9.28 Class diagram of our simulator (incorporating inheritance). Light Floor ElevatorShaft 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 + resetButton( ) : void + pressButton( ) : void Door - open : Boolean = false + openDoor( ) : void + closeDoor( ) : void Presse s Signals to move Resets Opens Closes Occupies Signals arrival Turns on/off Rings Location - locationName : String - capacity : Integer = 1 {frozen} Opens/Closes 1 ElevatorDoor 1 # setLocationName( String ) : void + getLocationName( ) : String + getCapacity( ) : Integer + getButton( ) : Button + getDoor( ) : Door

 2006 Doan Van Ban, IOIT. All rights reserved. 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 + resetButton( ) : void + pressButton( ) : void Person - ID : Integer - moving : Boolean = true - location : Location + doorOpened( ) : void ElevatorDoor + openDoor( ) : void + closeDoor( ) : void Location - locationName : String - capacity : Integer = 1 {frozen} # setLocationName( String ) : void + getLocationName( ) : String + getCapacity( ) : Integer + getButton( ) : Button + getDoor( ) : Door 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 - open : Boolean = false + openDoor( ) : void + closeDoor( ) : void

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

Outline 64 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

Outline 65 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 }

 2006 Doan Van Ban, IOIT. All rights reserved. 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”)

Outline 68 ElevatorSimulat ionEvent.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

Outline 69 ElevatorSimulat ionEvent.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 }

 2006 Doan Van Ban, IOIT. All rights reserved. 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 BellEventDoorEvent PersonMoveEvent ButtonEvent ElevatorMoveEvent LightEvent

 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 : Elevator firstFloorLight: Light firstFloorButton : Button : ElevatorShaft waitingPassenger : Person : ElevatorDoorfirstFloorDoor : 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 : elevatorArrived( ElevatorMoveEvent ) 4.1 : elevatorArrived( ElevatorMoveEvent ) 4.2 : elevatorArrived( ElevatorMoveEvent ) 2 : elevatorArrived( ElevatorMoveEvent ) : Bell 2.1: ringBell( ) elevatorButton: Button 1.1: resetButton( ) 3 : elevatorArrived( ElevatorMoveEvent )

 2006 Doan Van Ban, IOIT. All rights reserved. 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

Outline 77 ElevatorMoveEve nt.java 1 // ElevatorMoveEvent.java 2 // Indicates on which Floor the Elevator arrived or departed 3 package com.deitel.jhtp5.elevator.event; 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 }

Outline 78 ElevatorMoveLis tener.java 1 // ElevatorMoveListener.java 2 // Methods invoked when Elevator has either departed or arrived 3 package com.deitel.jhtp5.elevator.event; 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 }

 2006 Doan Van Ban, IOIT. All rights reserved. 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. 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 JavaInterface DoorListener + doorOpened( doorEvent : DoorEvent ) : void + doorClosed( doorEvent : DoorEvent ) : void Person - ID : Integer - moving : Boolean = true - location : Location + doorOpened( ) : void + doorClosed( ) : void DoorListener Person - ID : Integer - moving : Boolean = true - location : Location + doorOpened( ) : void + doorClosed( ) : void Elided class diagram that models class Person realizing interface DoorListener

Outline 82 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

 2006 Doan Van Ban, IOIT. All rights reserved. 83 Fig. 11.27Class diagram that models realizations in the elevator model Light ElevatorShaft Bell Person DoorButton ButtonListenerDoorListener ElevatorMoveListener DoorListenerLightListener Elevator ButtonListenerDoorListenerBellListener

 2006 Doan Van Ban, IOIT. All rights reserved. 84 Fig. 11.28Class 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 –Software simulator application –N-floor elevator.

Similar presentations

Presentation on theme: " 2006 Doan Van Ban, IOIT. All rights reserved. 1 Case Study: E levator System Simulation Program Goal –Software simulator application –N-floor elevator."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

 2006 Doan Van Ban, IOIT. All rights reserved. 1 Case Study: E levator System Simulation Program Goal –Software simulator application –N-floor elevator.

Similar presentations

Presentation on theme: " 2006 Doan Van Ban, IOIT. All rights reserved. 1 Case Study: E levator System Simulation Program Goal –Software simulator application –N-floor elevator."— Presentation transcript:

Similar presentations

About project

Feedback