System Design Document

STARS Project

15-413 Software Engineering

Fall 1999

Carnegie Mellon University

Pittsburgh, PA 15213

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

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

Client, Developers

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

• 1. Goals and Trade-offs (Architecture Team)
• 2. Subsystem Decomposition (Architecture Team)
• 3. Concurrency Identification (Inspection Team)
• 4. Hardware/Software Mapping (Augmented Reality Team)
• 5. Data Management(Modeling Team)
• 6. Global Resource Handling (Repair Team)
• 7. Software Control Implementation (Workflow Team)
• 8. Boundary Conditions (Authoring Team)
• 9. Design Rationale (All Teams)

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:

• What are the design priorities?
• What are the trade-offs made between design goals and why are they made?

• Rapid prototyping vs. completeness of functionality
• Usability vs. functionality
• Efficiency vs. portability
• Cost vs. reliability
• Reusability vs. cost

>>

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:

• 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 STARS system with component of deployment diagrams.

3. ConcurrenyIdentification

Typical questions to be answered in thissection:

• 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

• Describe the desired response time?
• What is the expected transaction rate? (Requests/sec)?

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

• Is the computation rate too demanding for a single processor?

• Is there enough memory to buffer bursts of requests?

4.2 Connectivity

• 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

• 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

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

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

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

>>