This document specifies the software architecture and design for the Traffic Controller program. The design decisions specified in this document directly relate to the functional and non-functional requirements previously specified.
This program simulates automobile traffic flow and traffic signals at a typical four way intersection. There are eight different queues for cars to enter, two each from the north, south, east, and west approaches to the intersection. Cars entering from the given direction have two options: continue straight (such as north to south) or turn left (such as north to east).
This system contains the rules that the traffic light and cars must follow in order to reduce the likelihood of collisions.
This document describes the software architecture and design for the initial release of the Traffic Controller program, version 1.0. The intended audience of this document exclusively includes the designers, the developers, and the testers of the Traffic Controller software system.
Definitions, Acronyms, and Abbreviations
The wording used to describe this system does not need to be further defined.
This system is completely standalone. It requires no input from external systems and provides no externally accessible services.
Figure 2: System architecture
This system is entirely self-contained. It consists of three modules: the cars, the light, and the traffic controller. The traffic controller is responsible for coordinating the behavior of the light and the cars. Note that you would need to describe any sub components in the architecture. The VODKA example does this well.
Note that this section may be replaced by a functional decomposition if applicable.
Figure 3: Object model
The direction class is an enumeration that specifies the different ways to move through an intersection.
The car class encapsulates the car objects. Each car is given a unique identification number and is able to approach an intersection from different directions.
The car queue class encapsulates a line of cars attempting to move through the intersection in a specific direction.
The car queue collection class contains a set of initialized car queues. There are a total of eight queues instantiated at once, four straight movement queues and four left turn queues.
Requirements Satisfied: 0110 and 0120.
The traffic light color class is an enumeration that specifies whether a traffic light is red or green.
Traffic Light Collection
The traffic light class is used to encapsulate the lights for the eight different car queues at the intersection. It can be queried to find the light status for a specific direction, which direction has a green light, and can also be used to change the individual lights.
Requirements Satisfied: 0110 and 0120.
The traffic controller class is used to check the status of a traffic light as well as change that light to the next status according to the rules specified in Section 2.4: Algorithms.
Requirements Satisfied: 0210, 0220, 0230, and 0240.
The traffic class handles the logic of moving cars through an intersection. It also allows for the system to receive user input.
Requirements Satisfied: 0130, 0140, and 0150.
This document does not have any data model requirements. This section should exist only in design documents that do. For extensibility purposes, it is possible that the CarQueueCollection and LightCollection objects may be shown here. This is typically done if those objects are being persisted between sessions.
This system implements a traffic light rotation algorithm. The traffic signal is instantiated to allow the north turning lane and south turning lanes to proceed. Traffic signals repeatedly rotate in the following order:
North turning lane and south turning lane
North straight lane and south straight lane
East turning lane and west turning lane
East straight lane and west straight lane
Furthermore, the light changes after at most five cars have cleared the light from a single direction or if there are no cars in both queues for a single light.
Most designs are for systems of sufficient complexity to require details about each sub-component in the system. They would be shown in this section. See the VODKA sample for a good idea of how to structure it.