System Design Document

 

STARS Project

15-413 Software Engineering

Fall 1999

Carnegie Mellon University

Pittsburgh, PA 15213

 

 

 

 

 

 


Revision History:

Version R0.1 10/13/98 Robin Loh. Created

Preface:

This document addresses the requirements of the STARS system. The intended audience for this document are the designers and the clients of the project.

Target Audience:

Client, Developers

STARS Members:

Bernd Bruegge, William Scherlis, . . .

We encourage you strongly to coordinate your section with other teams via e-mail, discussions in team meetings, integration liaison meetings and on the discuss bboard.Submission (must be a HTML document):

  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 17, 6pm

1. Goals and Trade-offs

<<In this section describe the design goals of the STARS system. Some of the design goals are mentioned in the global requirements section of the problem statement. Use also any special requirements (often called pseudo requirements)selection of the programming language) as the starting point of your discussion. After discussing the design goals, describe how they influence the functional requirements (use cases) and describe the trade-offs you have made. The system design must set priorities that will be used to guide trade-offs during the rest of design and implementation. During design it is often required that you choose among desirable but incompatible goals. For example, a system can often be made faster by using extra memory. Design trade-offs must be made regarding not only the software product itself but also regarding the process of developing it. For example, timely delivery might have to be traded-off against functionality. Note that not all the trade-offs are made during system design, but the priorities for making them are established in this phase. The entire character of a system is affected by the trade-off decisions made by the designer. The success or failure of the final product may depend on whether its goals are well-chosen. Here are some typical questions to be answered:

>>

2. System Decomposition

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

2.1 System Decomposition

<<Typical issues to be described in this section:

2.1.1 Layers & Partitions

2.1.2 System Topology

3. Concurrency Identification

Typical questions to be answered in this section:

4. Hardware/Software Allocation

4.1 System Performance

4.1.1 General system performance

4.1.2 Input/Output Performance

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 underlying network architecture. After determining the kinds and relative numbers of physical components in the system (processors, memory and network), this section describes the arrangement and form of the connections among them. The following decisions must be made and described:

4.3 Network architecture

Describe the form of connection channels and the communication protocol. Describe the general interaction mechanism and protocols, for example if the interaction is asynchronous, synchronous or blocking. Describe bandwidth and latency of the communication channels and whether they determine the choice for the protocol.Typical questions to be answered in this section:

5. Data Management

The internal and external data stores in a system provide clean separation points between subsystems with well-defined interfaces. In general each data store may combine data structures, files and databases implemented in memory or on secondary storage devices. Typical questions to be answered in this section:

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 be answered in this section:

7. Software Control Implementation

7.1 External control flow (between subsystems)

 

7.2 Concurrent control

7.3 Internal control (within a single process)

7.4 User Interface

8. Boundary Conditions

<< Although most of the design effort in many systems is concerned with the steady-state behavior, the system designer must consider boundary conditions as well, in particular initialization, termination and failure. This section describes how the STARS system deals with each of these issues.>>

8.1 Initialization

8.2 Termination

8.3 Failure


9. Design Rationale

<< Describe design issues that were discussed in the various subsystems. Describe why certain design decisions were made. Describe proposals that were considered but rejected. Give the reasoning behind your decisions (Arguments pro, Arguments against the proposal). Use the rhethorical model introduced in 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 to the length of the current design window. Describe the redesign and/or growth possibilities of the system with respect to different users: Customer, End-user, System Administrator. Show how the current system design can be converted to incorporate these technology enablers. What kind of problems do you expect in the transition? Typical questions asked in this part of the rationale are:

>>



This page is hosted by the Chair for Applied Software Engineering of the Technische Universität München.
Imprint (Impressum)