CMSC 345

Software Design and Development

Spring 2004

System Design Document Template

General Instructions

  1. Provide a cover page that includes the document name, product name, customer name, team name, team member names, and the current date.
  2. Number the pages of the document.
  3. Number and label all figures. Refer to the figures by number in the text.
  4. All sections should have an introductory sentence or two.
  5. Do not use vague words and phrases such as may, might, could, possibly, should, assumed to be, some, a little, and a lot. Use strong, definite words and phrases such as shall, will, will not, can, and cannot.
  6. Watch your spelling, punctuation, and grammar. It is a reflection on your professionalism.

Be sure that your document is

  • Complete - No information is missing
  • Clear - Every sentence's meaning must be clear to all parties
  • Consistent – The writing style and notation is consistent throughout the document and the document does not contradict itself.
  • Verifiable - All facts stated are verifiable

Remember that you are required to do a peer review of this document.

When you think you are done with the SDD, ask yourself, "Could someone who was not part of the development of this SDD write the corresponding code?"

Product Name

System Design Document

Table of Contents

Page

  1. Introduction

1.1Purpose of This Document

1.2References

  1. System Architecture

2.1Architectural Design

2.2Decomposition Description

  1. Component Design
  1. Global Data
  1. Persistent Data Design

5.1Database Descriptions

5.2File Descriptions

  1. Runtime Environment
  1. Requirements Matrix

Appendix A – Agreement Between Customer and Contractor

  1. Introduction

1.1 Purpose of This Document

State the purpose of this document and specify the intended readership.

1.2 References

Provide a list of all applicable and referenced documents and other media. Minimally, references to the SRS and UI Design Document go here. If you used any other documents or references to arrive at this design (e.g., the Somerville text, UML references, documents provided by the customer, websites), list them here. For each reference, provide the title, author, publisher (if applicable), date, and URL (for websites).

  1. System Architecture

2.1 Architectural Design

A brief description of all major subsystems and data repositories and their interconnections.

Put the architectural block diagram here.

2.2 Decomposition Description

A decomposition of the system into components (i.e., functions and/or objects). Supplement with text as needed.

Functional – Put data flow diagram (DFD), structural decomposition diagram, and data dictionary here. Supplement with text as necessary.

OOD – Put class diagrams here. (Include attributes and public operations only. Omit setters, getters, and destructors.) Supplement with text as needed.

Hybrid – Put data flow diagram (DFD), structural decomposition diagram, data dictionary, and class diagrams here. Supplement with text as needed.

  1. Component Design

Provide descriptions of the purpose of each function and/or method, its preconditions, and its postconditions.

Functional – Purpose, preconditions, and postconditions for all functions in the structural decomposition diagram of Section 2.2. PDL for all non-trivial functions.

OOD – Purpose, preconditions, and postconditions for all methods in all classes in the class diagrams of Section 2.2. PDL for all non-trivial methods.

Hybrid – Purpose, preconditions, and postconditions for all functions in the structural decomposition diagram and methods in the class diagrams of Section 2.2. PDL for all non-trivial functions and methods.

  1. Global Data

List and describe any global data.

  1. Persistent Data Design

5.1Database Descriptions

Describe the database(s) that are part of the system. Include diagrams of the schema with complete table and column descriptions.

5.2File Descriptions

Describe the file(s) that are a part of the system. Include a detailed format description.

  1. Runtime Environment

List the software and hardware that will be required to run the product. For software, this will include such things as the operating system, any database software (e.g., Oracle), web servers (e.g., Apache), and browsers. Be thorough. Be sure to give the exact name and version number(s) that are required. Although the compiler used (for compilable languages) is not required to run the product, list it also.

For hardware, list the runtime system’s processor, clock speed, RAM, and the minimum disk space needed for program execution (executable file, data space, and possibly code as with PHP). If you are using the UMBC gl system, you do not need to list the processor, clock speed, or RAM.

For web-based applications, you need to list the requirements for the client computer (i.e., web browser(s), processor, clock speed, RAM, and anything else).

  1. Requirements Matrix

Use a tabular format to show which system components (i.e., functions and/or methods) satisfy each of the functional requirements from the SRS. Refer to the functional requirements by use case number and name.

Appendix A – Agreement Between Customer and Contractor

Provide a separate page that describes what the customer and your team are agreeing to when all sign off on this document. Provide lines for printed names, signatures, and dates.

Unified Modeling Language (UML)

Reference: UML Distilled, 2nd edition, Martin Fowler and Kendall Scott, 2000

Note: The information below has been modified slightly to meet the purposes of CMSC 345

Class Diagrams

Symbols:

Class – Represented by a box as follows:

Association – Represented by a solid line. Indicates that there is a reference in one class to another.

Generalization – Represented by a solid line with a hollow arrowhead at one end. Indicates that one class is a subclass of another.

Composition – Represented by a solid line with a solid diamond at one end. Indicates that one class contains a data member whose type is of another class.

Multiplicity – Indicates how many objects of one class are associated with a single object of another.

Note: We will not be using any other symbols in our class diagrams.

Format for class attributes:

visibility name : type = defaultValue

where visibility = + for public, # for protected, - for private

name = attribute name

type = data type

defaultValue = default value

Format for class operations:

visibility name (parameter-list) : return-type

where visibility = + for public, # for protected, - for private

name = operation name

parameter-list = comma-separated parameters with the syntax

direction name : type = defaultValue

where direction = in for input

out for output

inout for input/output

return-type = return type

1