Optional Case Study

1
Optional Case Study
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
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
• 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 automatically illuminates (no
  programming necessary)
• Light turns off when button reset

4
2.3 Simulation Details

• Elevator Operation
• Elevator starts with doors closed on floor 1
• Only moves when necessary

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 delays creation of
  new person for one second.
• 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 in building, so elevator needs
  only one button (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

• Sample Simulation

9

• Sample Simulation

10

• Sample Simulation

11

• Sample Simulation

12

• Sample Simulation

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 these requirements
• Analysis phase - clearly state what system will
  do
• Design phase - clearly state how we will
  construct a system to perform tasks identified in
  analysis phase.

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)

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

21
2.7 Class Diagrams

• Class diagram
• Model classes and their relationships
• Model a single class elevator
• Top Class name
• Middle attributes
• Bottom operations
• May choose to display only the class name (and
  not attributes or operations), to improve
  readability
• Diagrams
• Solid line - relationship between classes
  (associations)
• 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

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
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
• Composed of ElevatorButton, Door, Bell
• Floor - represented near bottom
• Composed of 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