Author: Ric Holt, Department of Computer Science, University of Waterloo
Modified by: Grant Weddell, Department of Computer Science, University of Waterloo

(hard copy due in class on October 5^th, 1999)

BACKGROUND

This course is conceptually a follow on from course E&CE451/CS445/CS645. 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 a division of that system into two subsystems: (1) Operations, Administration and Maintenance (OAM), and (2) the Control Unit (CU).

This is the first of a sequence of assignments that will carry this work forward by

• (assignment 1) creating a corresponding software architecture,
• (assignment 2) creating a detailed design,
• (assignment 3) implementing the design, and possibly
• (assignment 4) extracting the concrete architecture.

Background documentation, available on the web, which you are assumed to have read, includes:

• the SX4 Hardware Description, and
• the SX4 Software Interface Description (interface between OAM and CU).

CONSTRAINTS FOR THIS TERM

The following constraints are imposed by the management:

• (1) Implementation is to be done in C or C++.
• (2) All documentation (including the solution to each assignment) is to be web-readable, eg, in HTML (or other form readable from the web). At the same time, your report must be printable (you are to turn in a hard copy of your report for marking).
• (3) You are to work individually on this first assignment, and in teams of three to five for the remaining assignments.

GOAL

You are to produce a (web-readable) report that documents the architecture of the software that you propose to develop for either the OAM or CU components of the SX4 system. Your target audience is a manager or developer who is familiar with telephone switching and with software architecture.

REPORT

Your report is to include the following sections:

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

Author: Your name, email address, date, etc.

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 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 or C++, so a "module" will eventually be implemented as a file (or a set of files) in the C or C++ language. A subsystem is to be a set of modules and other systems.

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 diagrams, etc. You should not include diagrams that are too low level. In particular, avoid diagrams that concern details within objects (as in OOA), or within modules. You are free to use any tools to create these diagrams.

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.

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). (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.

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.