Student Resources > CMPT 275 > assignment schedule > Design Document

Software Design Document

In this deliverable, you are to create and hand in your Software Design Document, which must contain the following sections:

• Cover page
• Table of Contents
• Revision History
• High Level Design - Architecture Design
  • Architecture Diagram
  • Sub-system Description
  • Refined Use Cases
• Low Level Design - Class Design
  • Interaction Diagrams
    • sequence diagram
    • collaboration diagram
  • Final and most detailed Class Diagram (one diagram)
• Data Persistence
  • Table Design

Some Helpful Instructions for Document Preparation

1) You MUST use the title page provided as the first page of your Software Requirements Specification Document.

2) Your revision history MUST be on the page following your title page.

3) Your table of contents MUST include all section and subsection titles, as well as the page numbers on which each section or subsection starts.

4) High Level Design (Architecture) - Construct the architecture diagram for your software system. An architecture diagram is a graphical representation of your software system's architecture. The number of separate components needed will depend on the type of architecture (client-server, repository, model-view-controller) that you choose for your system. Each separate component in your software system is represented by a box in your architecture diagram. (client, server, model, controller ...). In each of these boxes you will place the sub-systems that make up the component and show which of those subsystem communicate directly with each other. You will also show which of those sub-systems communicate with external actors (other components may be external actors). The number of components and subsystems neede will depend on the type of architecture (client-server, repository, model-view-controller) that you choose for your system and the requirements of your software system.
As a supplement to the architecture diagram describe in a line or two the responsibility (function) of each of the sub-systems in each of your components..

5) High Level Design (Refined Use Cases) - Write the following two refined use cases.
Refined use case one: add a programming activity to a course.
Refined use case two: run one previously specified test on a students submitted code and display the results of that test and the instructor's solution ready to be compared

6) Low Level Design (Interaction Diagrams) - Create 1 sequence diagram representing refined use case 1. Create 1 collaboration diagram representing refined use case two. This way, you will gain proficiency in creating both types of interaction diagrams.

7) Low Level Design (Final and most detailed Class Diagram) - You are to build a single detailed class diagram to represent your entire software system (the entire system NOT just your prototype). This class diagram should be detailed enough to be utilized as the implementation blueprint of each class. Show all entity classes and all relationships between those entity classes. When appropriate, each relationship should indicate multiplicity, navigability, name, and type of association (aggregation, composition). Each relation should be labelled with the requirement numbers or the requirements it satisfies. All attributes and methods should be listed.

For each class in your diagram, express its attributes using the following UML syntax:
[visibility]name [multiplicity] [: type] [= initial-value]
About type: When a data structure such as a hash table or a linked list is chosen as the type of an attribute, briefly explain why it was chosen. In your explanation, talk about the operations that will be performed on the data structure and their time and space efficiency. For example, considering the LMS example, you may decide to use a hash table as the data structure (type) for the "list of borrowed resources" attribute of the Patron class (Library Staff type of Patron - remember, this type of Patron can borrow unlimited number of resources). You may decide this because of the efficiency of the hash table's operations (insertion, searching and deletion). Indeed, when a patron is checking out a resource, the resource is inserted into the hash table "list of borrowed resources" in O(1) time if no collision occurs. Similarly, when a patron is checking in a resource, the resource is first found then removed from the hash table "list of borrowed resources" in O(1) time if no collision occurs.

For each class in your diagram, express its methods using the following UML syntax:
[visibility] name[(parameter-list)][: return-type]


8) Data Persistence (Table Design) -- Include a diagram representing the structure (layout) of each of your relational database tables (1 diagram per table). In terms of format, your diagram should look like the ones presented during our lectures on Normalization. Example data is not required.

10) The electronic copy of your project planning document must be checked into your subversion repository. Individual contributions to your document should also be checked into your subversion repository.

Marking Scheme - out of 100

We will be looking at:

• Completeness and quality of your Software Design Document and its sections
• Completeness and quality of diagrams and other representations
• Correct usage of UML
• Organization and neatness
• Spelling and grammar. Read each other's work. Use a spelling checker. Marks will be deducted for spelling and grammar errors, and for lack of clarity due to questionable or overly complex grammatical structures

Specifically:

• 2 marks for Revision History
• 24 marks for High Level Design
  • 8 marks for the Architecture Diagram and Sub-system Description
  • 16 marks for Refined use cases
• 45 marks for Low Level Design
  • 20 marks for Interaction Diagrams
  • 25 marks for final and most detailed Class Diagram
• 25 marks for Data Persistence, Table Design
• 3.5 marks for checking each team members contributions to the document into the subversion repository Each team member should check in their own contributions to the document (including any revisions to their own or other team members work)
• 0.5 marks for checking the submitted version of your requirements document into your subversion repository
• Up to 10 marks may be deducted for poor spelling, grammar or organization