Project Iteration 1: Architecture Sketch and Project Kernel
Software Architecture and Design (Fall 2003)
An electronically submitted copy of the document and code is due on October 3rd using the 'submit' command.
You will as a group implement a small subset of your system, including unit tests. As well, working papers of an architectural sketch of the system, the unit tests, and an installation guide will be required.
Your architectural sketch working paper will contain the following sections:
About 3 to 6 words making clear what your report is about.
Your names, email addresses, student ids, group number, date, etc.
About 1/3 – 1/2 of a page presenting an overview of the key points in your report and any salient conclusions, targeted to a knowledgeable manager or developer.
Convey the overall structure of the system that you are proposing to build, with descriptions of each major component and of the interactions among them. Cover the structure of the system as it will be when complete, not as it is for the subset being built now. You will have to defer some design decisions and leave some parts under-designed.
The components are primarily subsystems and modules, but also may be processes, files, and data bases. Give a diagram(s) showing the overall set of components and how they relate to each other. For each component describe its purpose, responsibilities and so forth. Your system's architecture should be easy to understand, with simple interfaces, and modest interactions among subsystems and modules.
Make sure any uncommon abbreviations or notation used is described.
Each shown interaction between components must be described in terms of the type of communication that's occurring.
Include a glossary that briefly defines all the key terms used in your architecture, giving when appropriate, the "type" of the item being explained.
List any documents that your reader may wish to or need to read in conjunction with your report.
The virtual audience for this working paper is the development team and its intelligent hands-on manager.
Do not make your report longer than necessary. In general, shorter reports that contain appropriate information are preferred. Your report should not be longer than 7-10 pages, including all diagrams and appendices.
Write clearly. Organize your report so it is easy to find things in it.
The first iteration of the project will be the delivery of a small
subset of function in a minimal version of the intended architecture. Building this will familiarize you with the IP phones and the chosen SQL database environment. Your system specification, given in your SRS, may deviate from what is outlined below. For example, the calling permissions are normally associated with a user account as opposed to a specific phone, as hinted at for this assignment. Ultimately you will implement the system as you specified it, but for this assignment it's ok to deviate from it if you wish.
Your kernel will include the following:
The database will contain the following data:
A list of four-digit phone numbers mapped to IP addresses
The maximum system load
The permissions placed on each phone (if it can make calls, receive calls, or both)
The database can simply be a SQL database running. Reading and modifying the data can be done directly through an appropriate API. Alternately a server process can be written to handle database requests.
You must also write a script or process which will create the table in the database and fill it with any information necessary. This is so when we mark your assignment we can easily recreate the database in our home directories and test it from there.
Build a phone process and any necessary servers to perform to following:
Place a successful call from one free phone to another free phone. Either phone can hang up and place another call.
Correctly handle attempting to place a call from a phone that doesn't have permission to place calls
Correctly handle attempting to place a call to a phone which doesn't have permission to receive calls
Correctly handle attempting to place a call once the maximum resources have been reached.
You don't have to handle every signal/state that you specified for your call processing in your SRS. For example, we haven't mentioned anything about calling a phone that's off-hook. You are only required to do as much as is necessary to satisfy the list above.
Remember that each phone process can only communicate with other processes in your system through IP sockets. There will be one instance of the phone process running for each phone in the system.
You will implement a set of automated unit tests which demonstrate the correctness of your project kernel. These tests will include changing of the data in the database and demonstrating that the call processing reacts accordingly. You are to use a common unit testing framework such as JUnit or CppUnit.
Include a working paper that briefly describes each unit test. Include a brief executive summary and for each test, the purpose of the test, where the test is implemented, and what part(s) of your SRS are related to it (sequence diagrams, specific requirements, etc). This document should only be about 2-3 pages long.
You'll find the <Test ...> messages in the interface API useful for unit testing your phone processes.
A 1-2 page working paper describing the build process, any needed libraries, and the required steps necessary to run your system and the unit tests. Don't forget to include a brief executive summary of the purpose of the paper.
Architecture skeleton document
Unit test document
Installation guide
Kernel code (database setup script, phone process, unit tests, anything else)
JUnit – http://www.junit.org/
CppUnit – http://cppunit.sourceforge.net/