Ric Holt, DC 2508, x4671, email@example.com, Department of Computer Science, University of Waterloo
Assignment 0: Tues Jan 18 2000 Assignment 1: Tues Jan 25 2000 Proj Proposal: Tues Feb 1 2000 Assignment 2: Tues Feb 8 2000
Your report should be web-readable, with links as appropriate to web-accessible related information. In particular, links to items in the Mozilla web pages are important.
In Assignment 1, please work individually.
The abstract architecture includes information about what the system does (its functionality) and how this is broken into interacting parts. What are the parts? How do they interact? How does the system evolve? What is the control and data flow among parts? What concurrency if any is present? What are the implications for division of responsibilities among participating developers?
The concentration is on the conceptual organization of the system rather than on the details of its implementation. You should assume that your readers have the basic knowledge of a typical computer science graduate.
The following are suggestions for your report.
Title: About 3 to 6 words making clear what your report is about.
Authors: Author, address, date, etc.
Abstract: About 2/3 of a page overviewing the key points in your report.
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, with descriptions of each major component and of the interactions among them. These components are to be primarily subsystems and modules, 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 description of this architecture should be easy to understand, ideally with simple interfaces, and modest interactions among subsystems and modules.
Clarify what style of architecture (in the sense of Garlan and Shaw) that characterizes (various parts of) the system.
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 the 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.
Data Dictionary: Include a glossary that briefly defines all the key terms used in the architecture, giving when appropriate, the "type" of the item being explained.
Naming Conventions: List any naming conventions used in the architecture. Explain any abbreviations that you use.
Evolvability: Discuss how the architecture is designed to support future changes.
References: List any documents that your reader may wish to or need to read in conjunction with your report. Include URL 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, including all diagrams and appendices.
Like much work in software development, you are being asked to do more that you have time to do. Part of your job is to choose what you will actually do for these assignments.
In Assignment 2, please work in groups of size 3 (approximately).
Please make your report accessible (readable) by a reasonably wide audience.
Your report should be organized approximately like your report for Assignment 1.
Give a clear description of each subsystem or module within you top level subsystem.
Use diagrams as needed for this report. You are to include a "dependency diagram", in which the boxes are subsystems and modules and the arrows are dependencies. A dependency from module M to N could be due to a call from a procedure in M to one in N, or a reference from inside M to a variable in N, etc. These diagrams can be created using any method you choose.
You may want to use a software visualization tool such as Rigi, CIA or Software Bookshelf (PBS) to create a view (or views) of your subsystem.
See note on limited time in Assignment 1
Updated 6 Jan 2000 --- RCH