System Design Document
STARS3 Project
15-413 Software Engineering
Fall 2000
Carnegie Mellon University
Pittsburgh, PA 15213
Revision History:
Version R1.0 10/13/99 Eric Stein. Created
Version R1.1 10/17/00 Joyce Johnstone. Revised
Preface:
This document addresses the design of the STARS3 system. The intended
audience for this document are the designers and the clients of the project.
Target Audience:
Client, Developers
STARS3 Members:
Bernd Bruegge, Eric Nyberg, Marc Kellner, Alan Black, Joyce
Johnstone, Jim Beck, Oliver Creighton, Will Ross, Kannan Ramaswamy, Zia Syed,
Yevgeny M. Bokk, Christian Buergy, Eugene Cheleshkin, Tom Min-Tien Chen, Aaron
Gideon Goldstein, Yan Ke, David Ryan Koes, David Kogan, Roman Kurin, Daniel
Siu Ping Kwok, Donovan P. Lange, Ted M Lin, Matthew J. McGrath, Kevin C.
Miller, Qian Shen, Shalin U. Sheth, Justin L. Sovich, Cort William Stratton,
Nathan V. Strom, Chien Tuan Tseng, Yang Wang, Alice Wu
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):
- Copy this document from the course homepage.
- 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.
- 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 31 at 6pm. The integrated version is due Nov 4, 3:00pm. Section 9 is due
on November 30, 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. Also use 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:
- What are the design priorities?
- What are the trade-offs made between design goals and why are they made?
Examples of trade-offs:
- Rapid prototyping vs. completeness of functionality
- Usability vs. functionality
- Efficiency vs. portability
- Cost vs. reliability
- Reusability vs. cost
>>
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 inthis section:
- Description of the subsystems
- Relationship between the subsystems
- Client/Server relationships
- Peer-to-Peer Relationships
- Do the subsystems call each other services (Peer-to-Peer
architecture)?>>
2.1.1 Layers &Partitions
- Describe the DependsOn associations between subsystems.
- Can the dependency between the subsystems be described as a hierarchy? If
not, why not?
2.1.2 System Topology
- Illustrate the topology of the STARS3 system with component of deployment
diagrams.
3. Concurreny Identification
Typical questions to be answered in this section:
- Which objects of the object model are independent?
- What kinds of threads of control are identifiable?
- Does the system provide access to multiple users?
- Can a single "query" consists of multiple queries?
- Could queries be handled in parallel by different subsystems? Describe the
problems for such a design.
- Describe the concurrency scheme used in the system.
4. Hardware/SoftwareAllocation
- Describe the existing hardware platform (client environment) and the
hardware platform chosen for development. Justify the choice of the
development platform.
- How are the subsystems mapped on the existing hardware & software?
- Do certain tasks require specific locations to control the hardware or to
permit concurrent operation?
4.1 System Performance
4.1.1 General systemperformance
- Describe the desired response time?
- What is the expected transaction rate? (Requests/sec)?
4.1.2 Input/OutputPerformance
- Do you need an extra piece of hardware to handle the data generation rate?
- Does the response time or information flow rate exceed the available
communication bandwidth between subsystems or a task and a piece of hardware?
4.1.3 Processor allocation
- Is the computation rate too demanding for a single processor?
4.1.4 Memory allocation
- Is there enough memory to buffer bursts of requests?
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:
- Choose the topology of connecting the physical units (Physical connections
often correspond to associations in the analysis model).
- Choose the topology of repeated components. If several copies of a
particular kind of unit or group of units is included for performance reasons,
their topology must be specified. The analysis model is usually not helpful
here, because the use of multiple components is a design optimization not
required by analysis.
- Show a diagram of the connectivity.
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:
- What are the transmission media?
- How reliable is wireless communication? How does the network architecture
deal with this problem?
- What kind of connection channels and communication protocols are used?
- Is the interaction asynchronous, synchronous or blocking?
- What are the estimated bandwidth requirements (Kbytes or Mbytes/sec)?
5. DataManagement
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 datastructures, files and databases implemented in memory or
on secondary storage devices. Typical questions to be answered in this
section:
- How does the system deal with data ? Are they using main memory, files,
databases? (For example, if the systems requires a lot of infrastructure a
database is appropriate)
- Are the data distributed?
- Should the database be extensible?
- What is the average request (query) rate? Worst case?
- How often is the database accessed?
- What is the size of typical (average) requests (queries)? Worst case?
- Does the data need to be archived? Which ones?
- Does the system hide the location of the databases (location
transparency)?
- Does the database have a single interface to the rest of the applications
accessing the data?
- What is the query format?
- Is it relational or object-oriented or a set of files? Justify your
answer.
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:
- Does the system provide authentication?
- What is the authentication scheme?
- What is the user interface for authentication?
- What hardware is used to support global resource handling?
- Does the system have a network-wide name server?
- How is a subsystem service known to the rest of the system?
- Are resources partitioned? Are they named? Can subsets of resources be
assigned to different guards?
- In time-critical applications it might be necessary to provide direct
access to a resource, because the general access mechanism is too slow. The
problem is that each resource user must be trusted to behave itself when
accessing the resource. Is this a problem in STARS?>>
7. Software Control Implementation
7.1 External control flow (between subsystems)
- Is the control flow distributed within the system?
- Is there a single control flow residing within a single program?
- Do procedures request input, wait for it and resume control when it
arrives?
- Is there a single control flow residing within a dispatcher?
- Does it wait for events and dispatches to the procedure that will take
care of it (callback)?
7.2 Concurrent control
- Describe subsystems or components of subsystems that can be run
concurrently.
7.3 Internal control (within a singleprocess)
- How is the process control implemented? By procedure calls? Are there any
threads?
7.4 User Interface
- Describe the rationale for certain design decisions made for the control
flow in the STARS system, in particular
a) does all the control reside in a
single location?
b) do the subsystems have their own user interface and
event loop?
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
- Dynamic model of the system start up
- Description of data that need to be accessed at start-up time
- Services that have to be registered
- What does the user interface do at start up time?
- How does the system present itself to the user?
8.2 Termination
- Are single subsystems allowed to terminate?
- Are other subsystems to be notified if only a single subsystem terminates?
- Are local updates communicated to the database when the system or a
subsystem terminates?
8.3 Failure
- How does the system behave in the context of node or communication link
failures?
- Are there backup communication links?
- How does the system recover from failure?
- Is this recovery different from initialization?
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 three 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:
- Scalability: What is the growth path of the system? Does the design allow
the addition of more users?
- How does the system design deal with
- the addition of more workstations
- additional types of communication links, for example wireless
communication?
- with the incorporation of additional applications such as a trend
analysis system?
- Extensibility: Does the system allow the addition of new data types?
- What is the impact of adding new databases?
- What is the impact of interfacing to existing legacy databases?
- What is the impact of adding video as new data type to the system?
- Modifiability of the design
- How stable is the hardware/software platform?
- What kind of technological changes will happen in the near future?
- Did these anticipated changes influence your design?
- Can your design cope with these changes?
>>