System Design Document
 
PAID Project
15-413 Software Engineering
Fall 1998
Carnegie Mellon University
Pittsburgh, PA 15213
 
 
 
 
 
 
Revision History:
Version R0.9 10/13/98 Bernd Bruegge. Created
Preface:
This document addresses the requirements of the PAID system. The
intended audience for this document are the designers and the clients
of the project.
Target Audience:
Client, Developers
PAID Members:
Bernd Bruegge, Elizabeth Bigelow, Elaine Hyder, Robin Loh, Jack Moffett, Eric Stein, Keith Arner, Swati Gupta, Russell Heywood, Joyce Johnstone, Luis Alonso, Orly Canlas, Anthony Dilello, Kumar Dwarakanath, Yan Fu, David Garmire, Xuemei Gu, Jonathon Hsieh, Kyle Jennings, Yu-Ching Lee, Wing Ling Leung, Jianping Liu, Kent Ma, Georgios Markakis, Richard Markwart, Daniel McCarrira, Reynald Ong, Brian Paterson, Adam Phelps, Arnaldo Piccinelli, Natalya Polyakova, Euijung Ra, Qiang Rao, Pooja Saksena, Rudy Satiewan, Timothy Shirley, Michael Smith, Jeffery Stephenson, Barrett Trask, Ivan Tumanov, Anthony Watkiuns, Jonathon Wildstrom, Brian Woo, Stephane Zermatten, Andrew Zimdars
   - 1. Goals and Trade-offs
   (Architecture Team)
 
   - 2. System Decomposition
   (Architecture Team)
 
   - 3. Concurrency
   Identification (Learning Team)
 
   - 4.
   Hardware/Software Mapping (Network Team)
 
   - 5. Data Management(Database
   Team)
 
   - 6. Global Resource
   Handling (Authentication Team)
 
   - 7. Software
   Control Implementation (Architecture Team)
 
   - 8. Boundary Conditions
   (User Interface Team)
 
   - 9. Design Rationale (All
   Teams)
 
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 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 PAID 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:
   - 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 in
this 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 PAID
   system with component of deployment diagrams.
 
3. Concurrency
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/Software
Allocation
   - 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 system
performance
   - Describe the desired response
   time?
 
   - What is the expected transaction rate?
   (Requests/sec)? 
 
4.1.2 Input/Output
Performance
   - 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. 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:
   - 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 be
answered 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 PAID?>>
 
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 single
process)
   - 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 PAID 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 PAID 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 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:
   - 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?
   
 
    
>>
This page is hosted by the Chair for Applied Software Engineering of the Technische Universität München.
Imprint (Impressum)