Drexel University Traffic Controller System



Download 56.81 Kb.
Date28.05.2018
Size56.81 Kb.
#50485

Drexel University

Traffic Controller System

Design Document




Phil Maconi








Table of Contents

1Introduction 2

1.1Purpose 2

1.2Scope 2

1.3Definitions, Acronyms, and Abbreviations 2

1.4Contextual Diagram 2

2Architecture 3

2.1Overview 3

2.2Object Model 3

2.2.1Direction 5

2.2.2Car 5

2.2.3Car Queue 5

2.2.4Car Queue Collection 5

2.2.5Light Color 5

2.2.6Traffic Light Collection 5

2.2.7Traffic Controller 5

2.2.8Traffic 5

2.3Data model 5

2.4Algorithms 6

3Detailed Architecture Diagram 7

4Design Components 8

Appendix A: Traceability Matrix 9



  1. Introduction

    1. Purpose


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.

    1. Scope


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.

    1. Definitions, Acronyms, and Abbreviations


The wording used to describe this system does not need to be further defined.

    1. Contextual Diagram




Figure 1: Contextual Diagram

This system is completely standalone. It requires no input from external systems and provides no externally accessible services.


  1. Architecture




Figure 2: System architecture

    1. Overview


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.

    1. Object Model


Note that this section may be replaced by a functional decomposition if applicable.



Figure 3: Object model


      1. Direction


The direction class is an enumeration that specifies the different ways to move through an intersection.

      1. Car


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.

      1. Car Queue


The car queue class encapsulates a line of cars attempting to move through the intersection in a specific direction.

      1. Car Queue Collection


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.

      1. Light Color


The traffic light color class is an enumeration that specifies whether a traffic light is red or green.

      1. 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.

      1. Traffic Controller


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.

      1. Traffic


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.

    1. Data model


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.

    1. Algorithms


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:

  1. North turning lane and south turning lane

  2. North straight lane and south straight lane

  3. East turning lane and west turning lane

  4. 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.

  1. Detailed Architecture Diagram




Figure 4: Detailed System Architecture

  1. Design Components


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.

Appendix A: Traceability Matrix




Requirement Component

Design Components

0110

2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.2.6

0120

2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.2.6

0130

2.2.8

0140

2.2.8

0150

2.2.8

0210

2.2.5, 2.2.6, 2.2.7

0220

2.2.5, 2.2.6, 2.2.7

0230

2.2.5, 2.2.6, 2.2.7

0240

2.2.5, 2.2.6, 2.2.7

Download 56.81 Kb.

Share with your friends:



The database is protected by copyright ©ininet.org 2024
send message
    Main page
different ways
initial release
traffic light
intended audience