PROBLEM

You are to create an object-oriented design for simulating the behavior of an elevator. Your design should consist of an appropriate use case diagram (with scenarios), class diagram, and interaction diagram in UML. We will assume that there is a single elevator for all floors.

The following entity types shall be part of this design:

ElevatorCar (which the passengers ride in)

ElevatorDoor (opens and closes)

CallButton (on each floor to request an elevator)

SelectFloorButton (in the elevator car, one button for each floor)

EmergencyButton (in elevator, rings buzzer if elevator gets stuck)

Controller (which controls all the actions of the elevator)

Buzzer

Elevator Requests Queue

All buttons light up at the appropriate times. When a CallButton is first pressed, it should light up, and turn off when the elevator reaches the floor that the call was from. Likewise, a SelectFloorButton should light up the first time pressed, and turn off when the elevator car reaches the desired floor. The EmergencyButton lights up when pressed, and stays lit.

The elevator door opens and closes at the appropriate times. When a SelectFloorButton is pressed, the elevator door should close. When an elevator reaches the requested floor (to either drop off or pick up someone) the elevator door should open.

ASSUMPTIONS

We will make the following simplifying assumptions:

There is no more than one passenger in the elevator at any given time, and thus only one SelectFloorButton is ever pressed at a time. Also, there is no need for separate up/down call elevator buttons on each floor (just one call button), since elevators will not stop to pick up waiting passengers when transporting a riding passenger.

Each request for an elevator (when a call button is pressed from a particular floor) is queued, because of our assumption that only one passenger is carried at a time.

There are no open/close door buttons on the elevator. This action is completely under the control of the controller.

UML DIAGRAMS

Use Case Diagram

There will be two actors in the use case diagram: a waiting passenger and a riding passenger. A waiting passenger is a person wanting to ride on the elevator, waiting on a specific floor. A riding passenger is a person currently on the elevator, being transported to the requested floor.

Following are the use cases to include:

Waiting Passenger

Request Elevator

Person on a given floor - for that floor to request the elevator

Riding Passenger

Select Floor

Person on elevator - to go to a particular floor

Call for Help

Person on elevator - for help when elevator stuck

Class Diagram

There will be the following classes in the design, with the indicated methods:

ElevatorCar

- moveUp() causes elevator car to move up to the next floor

- moveDown() causes elevator car to move down to the next floor

- getFloor() reports the floor elevator car currently on

ElevatorDoor

- open() causes elevator door to open

- close() causes elevator door to close

Button (abstract class)

- press() abstract method

- lightOn() concrete method (causes Button light to turn on)

- lightOff() concrete method (causes Button light to turn off)

SelectFloorButton (of type Button)

- press() passes reference to itself to controller

CallButton (of type Button)

- press() passes reference to itself to controller

EmergencyButton (of type Button)

- press() rings buzzer when pressed

Buzzer

- ring()

Controller

- floorRequest(Button) moves elevator to indicated floor

if Button of type SelectFloorButton, immediately request elevator to move to request floor

if Button of type CallButton, then add request to RequestQueue

- queueFloorRequest(num) queues request

this is a PRIVATE method of the Controller class

RequestQueue

- isEmpty() returns true of queue empty, otherwise returns false

- enqueue(num) adds requested floor number to the queue

- dequeue() returns floor number at front of the queue

All button classes should be subclasses of the abstract Button class. Make sure to also consider including in the class diagram navigation, multiplicity, composition and aggregation, as appropriate.

Interaction (Sequence) Diagram

There will be three interaction diagrams (one for each use case):

The Call Elevator interaction diagram begins when a CallButton is pressed.

The Select Floor interaction diagram begins when a SelectFloorButton is pressed.

The Request Help interaction diagram begins when an EmergencyButton is pressed.

WHAT TO TURN IN: Your diagrams must be done using a UML-capable drawing tool such as Lucidchart, Dia, ArgoUML, Visio, or Eclipse plugin, exported to pdf for submission.