System Design Document

PAID Project

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):

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 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?

>>