Optional Case Study - Chapter 2

(1)

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

(2)

2.1 Introduction

• Case study

– Substantial, carefully paced, complete design and implementation experience

• Chapters 2 - 5

– 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

(3)

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

(4)

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

(5)

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

(6)

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)

(7)

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

(8)

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

TIME: 3

TIME: 4

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)

(9)

Outline

TIME: 6

elevator moving up

TIME: 7

TIME: 8

TIME: 9

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

TIME: 12

elevator at rest on floor 2 TIME: 13

(10)

Outline

TIME: 14

TIME: 15

TIME: 16

TIME: 17

(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 begins moving down to floor 1 (arrives at time 22)

TIME: 18

elevator moving down TIME: 19

elevator moving down

(11)

Outline

TIME: 20

(scheduler schedules next person for floor 1 at time 26) elevator moving down

TIME: 21

TIME: 22

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 begins moving up to floor 2 (arrives at time 27)

TIME: 23

TIME: 24

elevator moving up TIME: 25

(12)

Outline

TIME: 26

(scheduler schedules next person for floor 1 at time 35) elevator moving up

TIME: 27

elevator opens its door on floor 2 person 3 exits elevator on floor 2 floor 2 turns off its light

elevator begins moving down to floor 1 (arrives at time 32)

TIME: 28

TIME: 29

TIME: 30

*** ELEVATOR SIMULATION ENDS ***

(13)

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

(14)

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

(15)

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

(16)

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

(17)

2.5 Use Case Diagrams (IV)

Elevator System

Person

Move to other floor

Case diagram for our system

(18)

2.6 Identifying the Classes in a System

• Identify classes

– Eventually implement them in C++ (beginning Chapter 6) – Review problem statement, locate all nouns:

company scheduler energy

building person capacity

elevator floor1 elevator button

simulator floor2 floor's elevator arrival light clock floor button person waiting on a floor time elevator door elevator's passenger

(19)

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

(20)

2.6 Identifying the Classes in a System (III)

• Filter remaining nouns into categories

building floor (floor1, floor2) door

elevator floor button light

clock elevator button scheduler bell

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

(21)

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

(22)

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)

(23)

2.8 Full Class Diagram

Solid diamonds represent composition

(24)

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

(25)

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

(26)

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

(27)

2.9 Object Diagram of Empty Building

scheduler : Scheduler building : Building

Services

elevator : Elevator

Services

: Door

: ElevatorButton

: Light

Summons Summons

clock : Clock

: Light : FloorButton : FloorButton

: Bell

floor1 : Floor floor2 : Floor

(28)

2.10 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