 2000 Deitel & Associates, Inc. All rights reserved. Optional Case Study - Chapter 2 Outline 2.1 Introduction 2.2 Thinking About Objects: Identifying the Classes in a Problem 2.3 Simulation Details 2.4 Analyzing and Designing the System 2.5 Use Case Diagrams 2.6 Identifying the Classes in a System 2.7 Class Diagrams 2.8 Full Class Diagram 2.9 Object Diagrams 2.10 Conclusion

 2000 Deitel & Associates, Inc. All rights reserved. 2.1 Introduction Case study –Substantial, carefully paced, complete design and implementation experience Chapters –Steps of an object-oriented design (OOD) using the UML Chapters 6, 7 and 9 –Implement elevator simulator using the techniques of object- oriented programming (OOP) This is not an exercise –End-to-end learning experience

 2000 Deitel & Associates, Inc. All rights reserved. 2.2 Thinking About Objects: Identifying the Classes in a Problem Problem Statement (full text in book) –Company wants you to build a 2-floor elevator simulator Decide if it meets their needs Clock that begins with zero seconds –Incremented every second, does not keep track of hours and minutes Scheduler –Randomly picks two times when two people use the elevator (one on floor1, one on floor 2) –Each time is a random integer from 5 to 20, inclusive

 2000 Deitel & Associates, Inc. All rights reserved. 2.3 Simulation Details Clock that begins with zero seconds –Incremented every second, does not keep track of hours and minutes Scheduler –Randomly picks two times when two people use the elevator (one on floor1, one on floor 2) –Each time is a random integer from 5 to 20, inclusive When clock reaches earlier of two times, scheduler creates a person who hits appropriate floor button Floor button illuminates - automatic Light turns off when button reset Elevator Operation –Elevator starts with doors closed on floor 1 –Only moves when necessary, to conserve energy

 2000 Deitel & Associates, Inc. All rights reserved. 2.3 Simulation Details (II) Details –For simplicity, elevator and floor can hold one person Scheduler verifies floor empty before creating a person on it –If floor occupied, scheduler waits one second for person to get on elevator and clear floor, then creates new person –After person walks onto floor, scheduler creates random time (5 to 20 seconds in future) for another person to walk onto the floor –When elevator arrives on floor, resets button and sounds bell (inside elevator) Signals arrival to floor Floor resets floor button, turns on elevator arrival light Elevator opens door (floor door opens automatically, needs no programming) Elevator passenger, if there is one, exits elevator Floor large enough to allow person to wait while passenger exits elevator

 2000 Deitel & Associates, Inc. All rights reserved. 2.3 Simulation Details (III) Person entering elevator –Presses elevator button (lights automatically, no programming necessary) Button turns off when elevator reaches desired floor Only two floors, so only one button necessary (to tell elevator to move to other floor) –Elevator closes door, begins moving to other floor –Person exits –If no one enters and other floor button not pushed, elevator stays on floor with doors closed Timing –All activities that happen when elevator reaches a floor take zero time The activities still occur sequentially (door opens before passenger exits)

 2000 Deitel & Associates, Inc. All rights reserved. 2.3 Simulation Details (IV) Timing (continued) –Elevator takes 5 seconds to move between floors –Once per second, simulator provides time to scheduler and elevator They use the time to determine what actions to take Simulator –Should display messages on screen describing activities of system –Person pressing floor button, elevator arrival, clock ticking, person entering, etc. Sample output on following slides

 2000 Deitel & Associates, Inc. All rights reserved. Outline Sample Simulation Enter run time: 30 (scheduler schedules next person for floor 1 at time 5) (scheduler schedules next person for floor 2 at time 17) *** ELEVATOR SIMULATION BEGINS *** TIME: 1 elevator at rest on floor 1 TIME: 2 elevator at rest on floor 1 TIME: 3 elevator at rest on floor 1 TIME: 4 elevator at rest on floor 1 TIME: 5 scheduler creates person 1 person 1 steps onto floor 1 person 1 presses floor button on floor 1 floor 1 button summons elevator (scheduler schedules next person for floor 1 at time 20) elevator resets its button elevator rings its bell floor 1 resets its button floor 1 turns on its light elevator opens its door on floor 1 person 1 enters elevator from floor 1 person 1 presses elevator button elevator button tells elevator to prepare to leave floor 1 turns off its light elevator closes its door on floor 1 elevator begins moving up to floor 2 (arrives at time 10)

 2000 Deitel & Associates, Inc. All rights reserved. Outline Sample Simulation TIME: 6 elevator moving up TIME: 7 elevator moving up TIME: 8 elevator moving up TIME: 9 elevator moving up TIME: 10 elevator arrives on floor 2 elevator resets its button elevator rings its bell floor 2 resets its button floor 2 turns on its light elevator opens its door on floor 2 person 1 exits elevator on floor 2 floor 2 turns off its light elevator closes its door on floor 2 elevator at rest on floor 2 TIME: 11 elevator at rest on floor 2 TIME: 12 elevator at rest on floor 2 TIME: 13 elevator at rest on floor 2

 2000 Deitel & Associates, Inc. All rights reserved. Outline Sample Simulation TIME: 14 elevator at rest on floor 2 TIME: 15 elevator at rest on floor 2 TIME: 16 elevator at rest on floor 2 TIME: 17 scheduler creates person 2 person 2 steps onto floor 2 person 2 presses floor button on floor 2 floor 2 button summons elevator (scheduler schedules next person for floor 2 at time 34) elevator resets its button elevator rings its bell floor 2 resets its button floor 2 turns on its light elevator opens its door on floor 2 person 2 enters elevator from floor 2 person 2 presses elevator button elevator button tells elevator to prepare to leave floor 2 turns off its light elevator closes its door on floor 2 elevator begins moving down to floor 1 (arrives at time 22) TIME: 18 elevator moving down TIME: 19 elevator moving down

 2000 Deitel & Associates, Inc. All rights reserved. Outline Sample Simulation TIME: 20 scheduler creates person 3 person 3 steps onto floor 1 person 3 presses floor button on floor 1 floor 1 button summons elevator (scheduler schedules next person for floor 1 at time 26) elevator moving down TIME: 21 elevator moving down TIME: 22 elevator arrives on floor 1 elevator resets its button elevator rings its bell floor 1 resets its button floor 1 turns on its light elevator opens its door on floor 1 person 2 exits elevator on floor 1 person 3 enters elevator from floor 1 person 3 presses elevator button elevator button tells elevator to prepare to leave floor 1 turns off its light elevator closes its door on floor 1 elevator begins moving up to floor 2 (arrives at time 27) TIME: 23 elevator moving up TIME: 24 elevator moving up TIME: 25 elevator moving up

 2000 Deitel & Associates, Inc. All rights reserved. Outline Sample Simulation TIME: 26 scheduler creates person 4 person 4 steps onto floor 1 person 4 presses floor button on floor 1 floor 1 button summons elevator (scheduler schedules next person for floor 1 at time 35) elevator moving up TIME: 27 elevator arrives on floor 2 elevator resets its button elevator rings its bell floor 2 resets its button floor 2 turns on its light elevator opens its door on floor 2 person 3 exits elevator on floor 2 floor 2 turns off its light elevator closes its door on floor 2 elevator begins moving down to floor 1 (arrives at time 32) TIME: 28 elevator moving down TIME: 29 elevator moving down TIME: 30 elevator moving down *** ELEVATOR SIMULATION ENDS ***

 2000 Deitel & Associates, Inc. All rights reserved. 2.4 Analyzing and Designing the System In the "Thinking about Objects" sections –Perform steps of an object-oriented design process for the elevator system –UML design for use with any OOAD process (many exist) Rational Unified Process - popular method –We present our own simplified design process Simulations –World portion: elements that belong to the world which we simulate Elevator, floors, buttons, lights, etc –Controller portion: elements needed to simulate word Clock and scheduler

 2000 Deitel & Associates, Inc. All rights reserved. 2.5 Use Case Diagrams Project development –Developers rarely start with a detailed problem statement, as we are –This document usually result of object oriented analysis (OOA) Interview people who will build and use system Get a list of system requirements, which guide design Our problem statement contains requirements –Analysis phase - clearly state what system will do –Design phase - clearly state how system will do it

 2000 Deitel & Associates, Inc. All rights reserved. 2.5 Use Case Diagrams (II) Use Case Diagrams –Models interactions between external clients and use cases of system Each use case represents a unique capability of system Example: an ATM has use cases "Deposit", "Withdraw", "Transfer Funds", etc. –Actor - external entities (people, robots, other systems) that use the system Only actors in our system are people riding the elevator

 2000 Deitel & Associates, Inc. All rights reserved. 2.5 Use Case Diagrams (III) Case Diagrams (continued) –System box - contains use cases for the system Contains use cases as ovals Our only use case is "Move to other floor" - that is all our elevator does Larger systems have many, and diagrams invaluable –As you build your system, rely on case diagram to ensure all needs are met Diagram shows types of interactions without showing details

 2000 Deitel & Associates, Inc. All rights reserved. 2.5 Use Case Diagrams (IV) Elevator System Person Move to other floor Case diagram for our system

 2000 Deitel & Associates, Inc. All rights reserved. 2.6 Identifying the Classes in a System Identify classes –Eventually implement them in C++ (beginning Chapter 6) –Review problem statement, locate all nouns: companyschedulerenergy buildingpersoncapacity elevatorfloor1elevator button simulatorfloor2floor's elevator arrival light clockfloor buttonperson waiting on a floor timeelevator doorelevator's passenger

 2000 Deitel & Associates, Inc. All rights reserved. 2.6 Identifying the Classes in a System (II) Only choose nouns that perform important duties Omit: company simulator time energy capacity –Time and capacity are properties of the clock and elevator, not separate entities –We do not need to model energy use –Company does not need to be modeled –Simulator is the entire program, not a class

 2000 Deitel & Associates, Inc. All rights reserved. 2.6 Identifying the Classes in a System (III) Filter remaining nouns into categories buildingfloor (floor1, floor2)door elevatorfloor buttonlight clockelevator button schedulerbell person (person waiting on a floor, elevator's passenger) –These nouns are likely to be classes –Two button categories - perform different functions –Model classes based on these categories Capitalize class names, first letter of each new word MultipleWordName –Must get understanding of how classes relate

 2000 Deitel & Associates, Inc. All rights reserved. 2.7 Class Diagrams Class diagram –Model classes and their relationships –Model a single class elevator: Top: Class name Middle: attributes Bottom: operations Allowed to have class name only to improve readability Diagrams –Associations - relationship between classes –Solid line - association –Numbers - how many objects of class participate in association (multiplicity) I.e., two objects of class Floor associated with class Building Building has a one-to-two relationship with class Floor Elevator

 2000 Deitel & Associates, Inc. All rights reserved. 2.7 Class Diagrams (II) Diagrams (continued) –Associations can be named "Services" Arrow shows direction of association "one object of class Elevator services two objects of class Floor " –Solid diamond - composition (whole/part) relationship Class with solid diamond on its end of association is the whole (i.e., Building, the other end is the part ( Floor and Elevator )

 2000 Deitel & Associates, Inc. All rights reserved. 2.8 Full Class Diagram Solid diamonds represent composition

 2000 Deitel & Associates, Inc. All rights reserved. 2.8 Full Class Diagram (II) Class Building –Represented near top –Composed of four classes: –Clock, Scheduler - controller part of simulation –Elevator - represented near bottom ElevatorButton, Door, Bell –Floor - represented near bottom Light, FloorButton Roles –Clarify relationship between classes –Person plays the "waiting passenger" role in association with Floor –Person plays passenger role with Elevator –Name of role placed on either side of association line, near class's rectangle

 2000 Deitel & Associates, Inc. All rights reserved. 2.8 Full Class Diagram (II) Association between Floor and Person –Indicates a Floor object can relate to zero or one Person objects Elevator also relates to zero or one Person objects –Dashed line represents constraint between Person, Floor, and Elevator xor - exclusive or. A Person can have a relationship with Floor or Elevator, but not both at same time –Scheduler can make zero or more Person objects

 2000 Deitel & Associates, Inc. All rights reserved. 2.9 Object Diagrams Object diagrams –Similar to class diagrams (model structure of system) –Model objects and links (relationships between objects) –Provide snapshot of system while it is running Info about which objects are participating at any specific instant Object Names –Written in form objectName : ClassName First word not capitalized, following words are –Object names underlined –Omit object name for some classes In large systems, many objects Causes cluttered diagrams If name unknown or unnecessary, leave it out Display colon and class name

 2000 Deitel & Associates, Inc. All rights reserved. 2.9 Object Diagram of Empty Building scheduler : Schedulerbuilding : Building S e r v i c e s elevator : Elevator S e r v i c e s : Door : ElevatorButton : Light S u m m o n s S u m m o n s clock : Clock : Light: FloorButton : Bell floor1 : Floorfloor2 : Floor

 2000 Deitel & Associates, Inc. All rights reserved Conclusion We have –Identified classes (although we may discover more) –Examined use case Chapter 3 –Implement randomness –Examine how system changes over time –Describe classes in greater depth