CS446/646/E&CE452-Fall 2007

Software Design and Architecture

Assignment 1

(printed copy by each student due at the start of class on October 3rd)


This is the first of the two assignments that will altogether yield a detailed design and integration test plan for an IP based private branch exchange (PBX) as a consquence of a software design tender by a hypothetical communications startup called SuperTel Ltd. Your target audience is a manager or developer at SuperTel who is familiar with telephone switching and with software architecture.

To proceed with this, you will need to become familiar with the following documents.
The following constraints apply to both assignments.

Report Format

Your initial high level architecture should contain the following sections.

Title: About 3 to 6 words making clear what your report is about.

Author: Your name, student number and email address.

Abstract: About 2/3 of a page presenting an overview of the key points in your report, targeted to a manager or developer.

Introduction and Overview: About 1 to 3 pages that give a summary of your report, its organization, and its salient conclusions. A person should be able to read the abstract and introduction and have a good idea of the contents of the remainder of your report.

Architecture: Give the overall structure of the system that you are proposing to implement, with descriptions of each major component and of the interactions among them. These components are to be primarily subsystems and modules, but also include processes (as in Unix processes), files, and data bases. In your descriptions, concentrate on goals, requirements, evolvability, testability, etc., rather than on lower level concepts such as variables and control flow. However, you should clarify global control flow, such as units of concurrency and method of passing control from one component to another.

Your system's architecture should be easy to understand, with simple interfaces, and modest interactions among subsystems and modules.

Clarify what style of architecture (in the sense of Garlan and Shaw) that you are proposing.

Avoid concentrating on minor components, such as procedures, which are smaller than modules. However, you may wish to discuss important abstractions, ADTs, data structures or algorithms that are critical to the successful implementation of your architecture.

You should use diagrams that clearly illustrate the structure of your system. You are free to use DFDs (Data Flow Diagrams), ERDs (Entity-Relation Diagrams), structure charts (at the level of modules not procedures), class and object diagrams, etc. You should not include diagrams that are too low level. In particular, avoid diagrams that concern details within objects or within modules.

External Interfaces: List information transmitted to/from the system, such as by Graphical User Interfaces, files, data bases, messages or networks. Do not give details such as menus, but rather concentrate on information content. Although the information to be stored in a database should be specified, the form of this data need not be given (perhaps one or two pages).

Data Dictionary: Include a glossary that briefly defines all the key terms used in your architecture, giving when appropriate, the "type" of the item being explained.

Evolvability: Discuss how your architecture is designed to support future telephony features (perhaps a page.)

References: List any documents that your reader may wish to or need to read in conjunction with your report. Since the report is to be web readable, include links to references when appropriate.

Document Style and Length

Do not make your report longer than necessary. In general, shorter reports that contain appropriate information are preferred. Your report must not be longer than 15 pages using 11pt character size, including all diagrams and appendices.

Write clearly. Organize your report so it is easy to find things within.