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.