System Design Document

STARS Project

15-413 Software Engineering

Fall 1999

Carnegie Mellon University

Pittsburgh, PA 15213


 
 










Revision History:

Version R1.0 10/13/99 Eric Stein. Created

Preface:

This document addresses the design of the STARS system. The intended audience for this document are the designers and the client sof the project.

Target Audience:

Client, Developers

STARS Members:

Kevin Babbitt, Nathan Bingham, Bernd Bruegge, Bill Scherlis, Timothy Canfield, Paul Cassella, Jason Chalecki, Patrick Ditterline, Zeb Drivdahl, Richard Ekwall, Michael Fortson, David Garmire, Daniel Gindikin, Rachel Goldstein, David Guttendorf, Tom Hawley, Daniel Heller, Roger Hong, Joyce Johnstone, Jeremy Jones, Robert Kurian, Alexander Kutner, Patrick Larkin, Christopher Lee, Mark Marrin, Kaushik Merchant, Brian Parkinson, Fani Pavlova, Graham Prud'homme, Li Qiu, Grace Ritter, Jonathan Rosenberg, Pooja Saksena, Paul Shao, Brian Showers, Roger Smith, Eric Stein, Zia Syed, Leong Teo, Stephen Verleye, Matthew Weyant, Tracy Wortham, Yik Lin Khoo, Anthony Yip, Cheng Zhao, Adi Zukerman
We encourage you strongly to coordinate your section with otherteams via e-mail, discussions in team meetings, integration liaisonmeetings and on the discuss bboard.Submission (must be a HTMLdocument):
  1. Copy this document from the course homepage.
  2. The text enclosed by brackets (<< . . . >>) and the bullets in each section are intended to help you overcome "writer's block". Replace the << . . . .>> text and the bullets with paragraphs containing your own original narrative text. Note: Your grade will be impacted, if any of the bullets show up in the final document, or if you are just writing sentences that answer each of these bullets.
  3. Work out an integration plan with the documentation editor for integrating and submitting the document. The individual document sections 1 to 8 are due Oct 27 at 6pm. The integrated version is due Nov 4, 3:00pm. Section 9 is due on November 24, 6pm

1.Goals and Trade-offs

<<In this section describe the designgoals of the STARS system. Some of the design goals are mentioned inthe global requirements section of the problem statement. Use alsoany special requirements (often called pseudo requirements)selectionof the programming language) as the starting point of yourdiscussion. After discussing the design goals, describe how theyinfluence the functional requirements (use cases) and describe thetrade-offs you have made. The system design must set priorities thatwill be used to guide trade-offs during the rest of design andimplementation. During design it is often required that you chooseamong desirable but incompatible goals. For example, a system canoften be made faster by using extra memory. Design trade-offs must bemade regarding not only the software product itself but alsoregarding the process of developing it. For example, timely deliverymight have to be traded-off against functionality. Note that not allthe trade-offs are made during system design, but the priorities formaking them are established in this phase. The entire character of asystem is affected by the trade-off decisions made by the designer.The success or failure of the final product may depend on whether itsgoals are well-chosen. Here are some typical questions to beanswered: Examples of trade-offs: >>

2. SystemDecomposition

<<Note: This section has to becompleted by each group. The content of this section will hopefullybe produced as a result of the design modeling in Together/J (e.g.,the creation and descriptions of design level subsystems). Some ofthe information required in those documents will need to beexplicitly entered in appropriate sections by each team and by theArchitecture team to complete the Design Model. The Architecture teamwill post explicit instructions about what information is required,who should enter it, and where to enter it so it will appear in theright places in the models maintained in Together/J and theassociated documentation.>>

2.1 System Decomposition

<<Typical issues to be described inthis section:

2.1.1 Layers &Partitions

2.1.2 System Topology

3. ConcurrenyIdentification

Typical questions to be answered in thissection:

4. Hardware/SoftwareAllocation

4.1 System Performance

4.1.1 General systemperformance 4.1.2 Input/OutputPerformance 4.1.3 Processor allocation 4.1.4 Memory allocation

4.2 Connectivity

This section describes the connectivity of the subsystems in terms of physical connections and the underlyingnetwork architecture. After determining the kinds and relativenumbers of physical components in the system (processors, memory andnetwork), this section describes the arrangement and form of theconnections among them. The following decisions must be made anddescribed:

4.3 Network architecture

Describe the form of connection channels and the communication protocol. Describe the general interactionmechanism and protocols, for example if the interaction isasynchronous, synchronous or blocking. Describe bandwidth and latencyof the communication channels and whether they determine the choicefor the protocol.Typical questions to be answered in thissection:

5. DataManagement

The internal and external data stores ina system provide clean separation points between subsystems withwell-defined interfaces. In general each data store may combine datastructures, files and databases implemented in memory or on secondarystorage devices. Typical questions to be answered in thissection:

6. Global Resource Handling

<<This section identifies global resources and determines mechanisms for controlling access to them.Global resources include: physical components (lap-tops,workstations, smart cards,...), disk space, workstation screens,buttons on a mouse, microphone, logical names such as IDs, filenames,service names, access to shared data, etc. Typical questions to beanswered in this section:

7. Software Control Implementation

7.1 External control flow (between subsystems)

   

7.2 Concurrent control

7.3 Internal control (within a singleprocess)

7.4 User Interface

8. Boundary Conditions

<< Although most of the design effortin many systems is concerned with the steady-state behavior, thesystem designer must consider boundary conditions as well, inparticular initialization, termination and failure. This sectiondescribes how the STARS system deals with each of theseissues.>>

8.1 Initialization

8.2 Termination

8.3 Failure

9. Design Rationale

<< Describe design issues that werediscussed in the various subsystems. Describe why certain designdecisions were made. Describe proposals that were considered butrejected. Give the reasoning behind your decisions (Arguments pro,Arguments against the proposal). Use the rhethorical model introducedin class based on issues, proposals, arguments and resolutions.Describe important issues that are still unresolved.

Open the design window by 3 more months,look at technology enablers that were considered but dropped due tothe length of the current design window. Describe the redesign and/orgrowth possibilities of the system with respect to different users:Customer, End-user, System Administrator. Show how the current systemdesign can be converted to incorporate these technology enablers.What kind of problems do you expect in the transition? Typicalquestions asked in this part of the rationale are:

>>