Traffic Signal Model
By James Sheets
Table of Contents
Introduction ................................................................................................................................................3
System Requirements .................................................................................................................................3
Use Case Diagram ......................................................................................................................................4
Use Case Specifications ........................................................................................................................5
Use Case Description ............................................................................................................................7
Class Diagram ............................................................................................................................................8
Class Description...................................................................................................................................8
Sequence Diagrams ....................................................................................................................................9
Sequence 1 Diagram ..............................................................................................................................9
Sequence 1 Description .......................................................................................................................10
Sequence 2 Diagram ............................................................................................................................11
Sequence 2 Description .......................................................................................................................11
Collaboration Diagrams ...........................................................................................................................12
Collaboration 1 Diagram .....................................................................................................................12
Collaboration 1 Description ................................................................................................................12
Collaboration 2 Diagram .....................................................................................................................13
Collaboration 2 Description ................................................................................................................13
State Chart Diagram .................................................................................................................................14
State Chart Description .......................................................................................................................15
Activity Diagram......................................................................................................................................16
Activity Description ............................................................................................................................17
Deployment Diagram ...............................................................................................................................18
Deployment Description .....................................................................................................................18
Introduction
The specifications for this project state that we need to develop a traffic control system for a four-way
intersection (minus pedestrian signals), which could be operated remotely or on-site. In order to
achieve this goal, I have modeled a generic traffic control system capable of being deployed to
any/multiple traffic signal clusters which only require basic traffic light information.
System Requirements
I have created this model under the following assumptions:
●
●
●
●
●
●
The hardware to operate these systems is of trivial importance
A networking infrastructure connecting light clusters to a remote control center exists
The hardware for each light cluster will identify where the light cluster exists to the control
center through some hard-wired means
Traffic lights simply take an input 'color' (such as red, green, yellow, blinking red, blinking
yellow), and maintain that 'color' until they're told to change it.
There is either hard-coded login information contained within each light cluster, or a remote
database which they are all networked to
Whenever there's more than two lights, we can always assume that the lights will be
perpendicular or parallel to one another. Thus, we only need to ever worry about making sure
one group is red so long as another group is green/yellow.
Use Case Diagram
Use Case Specifications
Use Case:
Login
Pre-Condition:
1. Login server accessible
Flow of Events:
1. Name/Password entered
2. Information authenticated
3. Authentication success returned
Post-Condition:
Use Case:
Toggle Power
Pre-Condition:
1. A LightCluster is available/selected
2. There are 1 or more lights attached to the LightCluster
Flow of Events:
1. Toggle power to each light connected to a
LightCluster on/off
Post-Condition:
1. Power state for all attached lights changed
Use Case:
Pause/Resume Scheduling
Pre-Condition:
1. A LightCluster is available/selected
2. The LightCluster has at least one schedule
Flow of Events:
1. Toggle scheduling on/off for the LightCluster
Post-Condition:
Use Case:
Change Light Color
Pre-Condition:
1.
2.
3.
4.
A LightCluster is available/selected
There are 1 or more lights attached to the LightCluster
The light being requested to change exists
The new color is valid
Flow of Events:
1.
2.
3.
4.
If scheduling is active, pause scheduling
A light and new color are specified
The new color is sent to the light
If the color is different from the current light, change
the color
Post-Condition:
1. Light is set to the selected color
2. Scheduling paused
Use Case:
Control Light-Change Scheduling
Pre-Condition:
1. A LightCluster is available/selected
2. The Lights referred to in the schedule exist
Flow of Events:
1. Ad schedule
1. Pick a schedule type
2. Enter schedule parameters
3. Make sure this schedule+light combination doesn't
conflict with an existing schedule+light
combination
4. Add to the scheduling list
1. Remove schedule
1. Select an existing schedule
2. Remove it from scheduling list
2. View schedule
1. Return list of schedules in scheduling list
Post-Condition:
Use Case:
Change Clock
Pre-Condition:
3. A LightCluster is available/selected
4. Time entered is valid
Flow of Events:
1. Enter a time for the clock
2. Set the clock to the new date/time
Post-Condition:
1. Clock is set to the specified time
Use Case:
Control Light Structures
Pre-Condition:
1. 1 or more LightCluster's connected to grid
Flow of Events:
1. Add LightCluster
1. List of connected LightCluster's appear
2. Select LightCluster
3. Add LightCluster to the list
2. Remove LightCluster
1. Display all LightCluster's in our list
2. Select LightCluster
3. Remove LightCluster from the list
3. Select LightCluster
1. Display all LightCluster's in our list
2. Select LightCluster
3. Display all information about the LightCluster
Post-Condition:
Use Case Description
There is only one type of user in our system: a CityWorker who's responsible for controlling the traffic
signals.
There are two separate sections, as well. The first is the On-Site Cluster Controls, which would be any
grouping of traffic lights which need to coordinate with one another (we'll later refer to these as
LightClusters). The cluster sections provides all of the functionality required to interact with a set of
traffic signals.
There's also the Control Center group. This will be a remote locations from which all light clusters can
be controlled from. It is able to access all the functionality provided by the On-Site Cluster Controls,
and provides a way to access various clusters in the network.
Class Diagram
Class Description
The LightCluster class is primarily responsible for keeping track of all the lights in the cluster,
changing the light color, keeping track of when the lights need to be changed, etc.
The Light class represents a single light in the cluster, and has functions to directly change that light's
color.
LightSchedule is an abstract class, which holds basic information about needed for any schedule.
Basically, every schedule has a starting and ending DateTime, which governs the periods of time which
the schedule should be active, as well as a listing of all lights affected by that schedule. No schedule
may have overlapping times if one of the Light's inside it's list is in a conflicting schedule. The
LightCluster class will actually monitor the current schedule(s) (as it's possible to have more than 1 at
the same time), and will activate the proper light changes as the schedule dictates.
The BlinkingRedSchedule and BlinkingYellowSchedule are concrete classes of LightSchedule. These
classes simply take any lights assigned to them, and make sure they constantly blink yellow or red.
The NormalSchedule handles the basic red/yellow/green controls that will normally be required. It
uses two lists of Light's. Each group has it's own duration for how long a light should be green, and a
generic length for how long the yellow light lasts. As long as we operate under the assumption that if
two parallel lights will also be the same color, and the perpendicular lights will be a different color, this
provides all the information we will need to keep a four-way signal correctly working.
Sequence Diagrams
Sequence 1 Diagram
Sequence 1 Description
In this sequence, we see a city worker logging into our four-way light cluster to set up two of the lights
(we'll say north/south to make the example more clear) to blink red, and the other two (east/west) to
blink yellow.
Once the employee logs into the system, he creates an instance of our BlinkingRedSchedule. He sets
the parameters, telling the system what time the schedule should occur during, and sets the lights which
the schedule should control.
He then creates an instance of the BlinkingYellowSchedule, enters in the same time as given for the
blinking red schedule, and enters the remaining two lights into it.
These two schedules are then entered into the LightCluster schedule. We'll assume there's no
scheduling conflict, and that they're added to the schedule list.
Sequence 2 Diagram
Sequence 2 Description
This simple sequence shows a CityWorker logging into a LightCluser to change the current light. To
expand on this idea slightly, changing the lights manually is something which would rarely occur, as
schedules are how the lights would normally be controlled, and the CityWorker is responsible for
making sure they don't turn two perpendicular lights green at the same time. Thus, it would mostly the
lights or such.
After logging in, the current schedule is paused. This is done to ensure that none of the light schedules
interfere with the worker as he modifies the lights. The city worker then selects a light, and picks a
color he wants to set the light to, and sets that colors light.
Collaboration Diagrams
Collaboration 1 Diagram
Collaboration 1 Description
This is a collaboration represents the same diagram as in our sequence 1 diagram. The only difference
is that our CityWorker is remotely controlling the LightCluster through the ControlCenter here.
After logging in, our worker creates the BlinkingRedLight and BlinkingYellowLight schedules, sets the
appropriate light and time information to each one, and enters them into the LightCluster's schedule
list.
Collaboration 2 Diagram
Collaboration 2 Description
This describes the same process as in our sequence 2 diagram. The CityWorker logs into a
LightCluster, pauses all current scheduling, selects the light he wants, and changes it's color.
State Chart Diagram
State Chart Description
Our state chart describes the light changing process which occurs in our LightCluster class when it
processes a schedule.
First, it ensures that scheduling is enable. It then fetches the schedule(s) which should be running
through it's internal clock loop.
Once the schedule has been selected, it determines the type of schedule it's found, in order to correctly
process it.
The blinking schedules behave in basically the same fashion: it finds the lights associated with each
schedule, and ensures that those lights are set to the correct 'color'.
If it's a normal schedule, it needs to find out which group of lights are currently set to red. Since the
NormalSchedule only allows for two groups of lights, we know which group currently isn't red. We
then find out when the last light change occurred, and see if the current time is greater than the last
changed time and the sum of the duration this light group is set to be green. If it is, we change the
green lights to yellow.
If the current time is greater than the last changed time and the sum of the duration of this light group is
set to be green and the yellow light duration, we know it's time to set this light group to red. Then we'd
change the currently red light group to green, reset the last changed time, etc.
Activity Diagram
Activity Description
Unlike my state diagram which dealt with schedule changing, my activity diagram deals with the
interaction of a CityWorker with the various systems provided by a LightCluster. It displays all the
interactions as specified in the Use Case diagrams, with the exception of controlling the light clusters
themselves from the traffic control center.
The graph is fairly self-explanatory, especially considering most of the steps I could describe are
already outlined in the Use Case Specifications.
Deployment Diagram
Deployment Description
Our deployment diagram deals specifically with the four-way traffic signal which we were to design
for. The first hardware system is our Traffic Control Station, which contains our simple ControlCenter
class.
The Traffic Light Cluster is whatever switching/hardware system the lights at our four-way cross are
connected to. This system houses our LightCluster class, and all the scheduling classes.
Hard-wired to our cluster are our four lights, which we will give directional names to, to distinguish
them from one another. Each of these lights holds an instance of our Light class, which will allow us to
actually control the color of the light.