SIE 277: Object-Oriented Modeling and Design
Smart Park Software Proposal
Professor:
Sherilyn Keaton
By:
Chris Zurita
Chris Miller
December 6, 2016
Overview
This system is a pilot project and will be built in a phased approach. The first phase, the one we will
define and model here, will implement real-time space occupancy sensors only for spaces designated for
Accessible Parking. Overall garage availability will be measured through vehicle counts upon enter / exit
(e.g., 33 / 100 spaces available). Per-space occupancy sensors will be implemented for the remaining
spaces (garage, lot, and metered) in future phases if this project proves successful.
The Smart Park system has a central server (hub) component, a browser-based graphical user interface
(GUI) and a device level controller / monitor component. The server component is responsible for
running the business logic of the system (see Use cases below), storing and displaying availability
information, sending counts and informational messages to LED signs at each garage, and providing
reports like garage usage trends over time. The user interface will use a standard web browser for
displaying system information to internal staff and external, registered users.
Wireless vehicle detection sensors are installed in each parking space (phase 1 is for spaces designated
as Accessible Parking only). The space-specific status (occupied / unoccupied) is transmitted to a local
data collector which in turns sends the data to the central server for storage and system display. For
overall garage availability status, vehicle counts are generated at the entry and exit points, updated for
each vehicle, via detectors tracking vehicle direction and collected by the local controller that sends the
information on to the central server. There are message signs at the entrance of each garage that
display the current number of open spaces (received from the controller connected to the detectors)
and another message sign that displays informational messages.
«device»
D ataCollector
1 ..
1 ..
1 ..
1 ..
1 ..
1
0 ..*
«device»
S m artP arkC entralServer
«device»
EntryExitSensor
1
1 ..
1 ..1 ..
«device»
A p p licationServer
1 ..
«device»
L E DMessageSign
1 ..
0 ..*
1 ..
0 ..*
0 ..*
«device»
Terminal
«device»
H an d HeldDevice
0 ..*
«device»
D eskto p D evice
0 ..*
«device»
LEDAvailabilityDisplaySign
0 ..*
«device»
W irelessVehicleDetectionSensor
Diagram: Class ModeL
The following class diagram displays the interactions between the different systems for the
parking system.
Diagram: SystemViewStatus
Use Case: Register for Smart Park
ID: SPS001
Brief Description: A new user registers for the Smart Park system
Primary Actor: Driver
Secondary Actors:
Precondition: Email must not be previously registered
Main Flow:
a. The use case starts when the Driver opens the application
b. The user selects register for account
c. The user enters email, password, and vehicle type
d. The use case ends when the user selects submit
Post Condition: The new user is registered
Alternative Flow: The email is taken
Use Case: System View Status
ID: SPS002
Brief Description: A user views available of the system
Primary Actor: Driver
Secondary Actors:
Precondition: Driver must be a registered user
Main Flow:
a. The use case begins when the user opens the application
b. The driver selects view system status
c. The driver selects their current location
Post Condition: The System displays the current status of garages in their area
Alternative Flow: There are no garages in the driver’s area
Use Case: Search for Accessible Parking Availability
ID: SPS003
Brief Description: A registered Driver checks for parking availability
Primary Actor: Driver
Secondary Actors:
Precondition: The driver must be registered as an Accessible user
Main Flow:
a. The use case starts when the driver selects the status of a garage
b. The Driver selects the view Accessible Parking Availability
c. The Driver selects the desired parking garage
d. The Driver selects time range of parking
Post Condition: The system displays available Accessible Parking spots
Alternative Flow: The system displays a no vacany message for garage
Use Case: Control Device by Schedule
ID: SPS004
Brief Description: A controller is set for an event at a future date
Primary Actor: Parking Garage Manager
Secondary Actors:
Precondition: Must be a future time and date
Main Flow:
a. The user case begins when the Parking Garage Manager logs into
the system
b. The PGM creates a scheduled event
c. The PGM selects the designated garage
d. The PGM sets the time, date, and duration of event
e. The PGM saves the event
Post Condition: The event is scheduled
Alternative Flow:
Use Case: Send Device Measurement to Central Server
ID: SPS005
Brief Description: Vehicle sensor is activated
Primary Actor: Device
Secondary Actors:
Precondition: Device must be online
Main Flow:
a. The use case begins when the device senses a vehicle entering a
spot
b. The device logs time of day and location
Post Condition: The device sends information to the Central Server
Alternative Flow: The device is unable to communicate with Central Server
Use Case: Send Alert
ID: SPS006
Brief Description:
Primary Actor: Parking Garage Manager
Secondary Actors: Driver
Precondition:
Main Flow:
a. The use case begins when the PGM logs into the system
b. The PGM creates an alert
c. The PGM selects the designated Driver for the alert
d. The PGM saves the alert
Post Condition: The designated driver is alerted
Alternative Flow: The driver does not exist
Use Case: Create Parking Space Report
ID: SPS007
Brief Description:
Primary Actor: Parking Garage Manager
Secondary Actors:
Precondition:
Main Flow:
a. The use case begins when the PGM logs into the system
b. The PGM selects a garage from the system
c. The PGM selects run report
Post Condition: The system creates a Parking Space Report
Alternative Flow: There is no data to report
Diagram: ControlDeviceBySchedule
This sequence diagram demonstrates that in order to use the schedule feature on the application,
information from the Central Server as well as the local Garage are needed. This also shows that it is
the Central Server communicating with the LED sign when scheduling for parking.
Diagram: ControlDeviceBySchedule
This object diagram is an enumeration of a driver at Cherry Garage who schedules parking and,
again, requires that the LED sign responds to the new schedule and the Central Server and parking
sensor to become aware of the change as well.
Diagram: CreateParkingSpaceReport
This sequence diagram shows that the parking manager uses the parking application which takes
information from the Central Server to create the parking space report.
Diagram: CreateParkingSpaceReport
This object diagram is an enumeration at 6th Street as well as 2nd Street Garage. It shows that
each garage gathers information from the Central Server, but each garage communicates with its
own accessible sensor.
Diagram: RegisterForSmartPark
This class diagram like many others, represents how the application relies on information from the
Central Server.
Diagram: RegisterForSmartPark
This sequence diagram shows how the driver must first select to register for parking through the
application. That information is then sent to the Central Server.
Diagram: RegisterForSmartPark
Here, an account of a registration shows that the application connects with the Central Server.
Diagram: RegisterForSmartPark
The activity diagram shows that the registration information must be put into the system and
verified before continuing.
Diagram: RegisterForSmartPark
The possible states of the driver going through the registration process are shown in this state
diagram.
Diagram: SearchAccessibleParkingAvailability
Diagram: SendAlert
Diagram: Activity
Diagram: SendAlert
Diagram: SendDeviceMeasurementToCentralServer
Diagram: SendDeviceMeasurementToCentralServer
Diagram: SystemViewStatus
This class diagram shows how the application interface needs to interact with the Central Server in
order to view the status of the parking availability.
Diagram: SystemViewStatus