BACKGROUND
This course is conceptually a follow on from course CS445 [CS645] / ECE451. In that course the major assignment was to:
Carry out an OO analysis of the SX4 telephone switching system, given the specification of its hardware and given division of that system into two levels (OAM: upper level data processing and CU: control of actual switching hardware).
This course's assignments will carry this work forward by
Background documentation, available on the web, which you are assumed to have read, includes:
For this version of the course, the following constraints are imposed by the management:
GOAL
You are to produce a (web-readable) report that documents the architecture of the software that you propose to develop for the SX4 system (for OAM in this trimester). Your target audience is a manager or developer who is somewhat but not intimately familiar with telephone switching and with software architecture.
REPORT
You report should include the following:
Title: About 3 to 6 words making clear what your report is about.
Authors: List of authors, their addresses, date, etc.
Abstract: About 2/3 of a page overviewing the key points in your report, targeted to a manager or developer.
Introduction and Overview: About 1 to 3 pages summarizing the purpose of report, its organization, and its salient conclusions. A person should be able to read just the abstract or just the introduction and have a good idea what is in the rest of your report.
Architecture: Give the overall structure 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.
In this version of the course, the implementation is to be in C, so a "module" will eventually be implemented as a file (or a set of files) in the C language. A subsystem is to be a set of modules and other systems.
You are not to concentrate 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 may choose to use DFDs (Data Flow Diagrams), ERDs (Entity-Relation Diagrams), structure charts (at the level of modules not procedures), or software landscapes. Except possibly at a very high level, STDs (State Transition Diagrams) are not the right kind of diagram. Do not give diagrams that are too low level, eg, do not give diagrams of details within objects (as in OOA), nor within modules. You can use tools such as StP for diagrams, but this is not required.
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.
Naming Conventions: List any naming conventions used in your architecture. Explain any abbreviations that you use.
Tentative Test Plan: Briefly describe how you plan on testing your system. (Perhaps a page.)
Methodology and Cost: Give a plan for how the system is to be implemented, (what modules and subsystems in what order, by whom and how to do unit testing), with estimates of number of lines in each module and number of person hours to both implement and unit test each module. (You are to record this same information during your development, to compare with these estimates.) (Roughly a page or two.)
Evolvability: Discuss how your architecture is designed to support future changes in the SX4 switch. (Perhaps a page.)
Feasibility Studies: Investigate and report on the feasibility of using the supporting software for: the databases (NDBM), the Message Queues, and Graphical User Interfaces (Tcl/Tk). You may wish to do small prototypes investigating the use of each of these. (Perhaps one or two pages.)
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 25 pages (in the hard copy version), including all diagrams and appendices.
Write clearly. Organize your report so it is easy to find things in it.
FUTURE ASSIGNMENTS
Future reports are to be interlinked with an updated version of this software architecture report.
The Detailed Design of your system, which is to be done in your next assignment, will be a companion document to the Software Architecture document created in this assignment. Write the current report in a way to make this possible. In the Detailed Design, you are to give, for each module, a clear specification for the module, such that a junior programmer can implement that module. The Detailed Design will include a clear description of the behaviour of the module and its externally visible interface. It will include a description of algorithms and data structures to be used and will give pseudo code when necessary to describe non-obvious implementation techniques.