Object-Oriented Software Design Specification Template

1 Overview

1.1 System Overview

A brief description of what the system is to accomplish, the target users, and the operating environment of the system. This part mainly comes from the beginning of the requirement manual.

1.2 software design goals

This part discusses the design objectives of the entire system, and clearly describes which functions are determined by the system and which are not prepared for implementation. In addition, non-functional requirements such as performance and availability should also be mentioned. The Requirement Specification is an important reference for this part. Let's take a look at the specific functional and non-functional requirements.

This part must clearly explain how the overall design is, and make sure that the reader can understand the features and functions of the system to be implemented. The subsequent document explains how the design is implemented.

1.3 references

Lists references referenced in this document. (At least the requirement specification must be referenced)

1.4 revision history

Lists the modified history of this document. The modified content, date, and modifier must be specified.

2 Glossary

The terms used in this document are described. If some terms have already been described in the requirement specification, you do not need to repeat them here.

3 Use Cases

The use case diagram (UML) must be used to describe each use case (normal processing) in Chinese.

4. design overview

4.1 Brief Introduction

This part requires highlighting the methods used by the entire design (Object-Oriented Design or structural design) and the system architecture (such as the customer/Server structure) and the technologies and tools used (such as OMT and Rose)

4.2 System Structure Design

This part requires a description of the structure of the high-level system, and a block diagram is used to show the interaction between the main components and components. It is best to separate the logical structure from the physical structure and describe the former. Do not forget to describe the Common Sayings and symbols used in the figure.

4.2.1 top-level system structure

4.2.2 subsystem 1 Structure

4.2.3 subsystem 2 Structure

4.3 System Interface

Various user interfaces and external systems should be described here. If you have already described the user interface in the requirement specification, you do not need to repeat it here. You can instruct the readers to refer to the Requirement Description. If the system provides interfaces for other systems, such as importing/exporting data from other software systems, it must be described here.

4.4 constraints and assumptions

Describes the most important constraints in the system design. These are mandatory by the customer and stated in the requirement specification. Describes how the system adapts to these constraints.

Mail software) and the resulting constraints (for example, only plain text emails are allowed ).

The language and platform for implementation will also have constraints on the system, which are also described here.

For the constraints on the system caused by the specific design implementation, briefly describe your ideas, how to weigh them, and why to adopt such a design.

5. Object Model

5.1 System Object Model

Provides the object model of the entire system. If the model is too large, it is divided into small pieces according to feasible standards. For example, you can split the object model on the client and server into two charts.

What Should an object graph contain?

It should contain all system objects. These objects are obtained after understanding the requirements. It is necessary to clarify which and which should not be put into the graph.

The association between all objects must be determined and the base of the contact must be specified (one-to-one, one-to-many, many-to-many, 0... 1, *, 1 ..*). The relationship between aggregation and inheritance must be clearly determined. A simple description is required for each graph.

The correct object model of the system can be obtained after multiple iterations.

6. Object Description

This section describes the details of each object, its attributes, and its methods. Before that, the object must be organized logically. You may need to use a structure chart to divide objects by subsystems.

Create an entry for each object. Briefly describe the purpose and constraints of the System Object Model (for example, only one instance can be used) and list its attributes and methods. If the object is stored in a persistent data container, it indicates that it is a persistent object. Otherwise, it indicates that it is a temporary object (transient object ).

Detailed description of each attribute of each object: name and type. If the attribute is not intuitive or constrained (for example, each object must have a unique value or a finite positive integer value ).

Detailed description of each method of each object: method name, return type, return value, parameter, purpose, and brief description of the algorithm used (if not very simple ). Pre-conditions and Post-conditions must be described here if any assumptions are made about the variables or returned values. Lists the attributes that need to be accessed or modified by the method it calls. Finally, a test case can be provided to verify the implementation method.

6.1 objects in subsystem 1:

6.1.1 object: Object 1

Purpose:

Constraints:

Durability:

6.1.1.1 attribute description:

1. attribute: attribute 1

Type:

Description:

Constraints:

2. attribute: attribute 2

6.1.1.2 method description:

1. Method: method 1

Return type:

Parameters:

Return Value:

Pre-Condition:

Post-Condition:

Read/modify attributes:

Call method:

Processing logic:

Test example: What parameter is used to call the method and what is the expected output ......

7. Dynamic Model

This part describes how the system responds to various events. For example, you can create a system behavior model. The sequence chart and status chart are generally used.

Determining different scenarios (scenario) is the first step. You do not need to determine all possible scenarios, but you must cover at least the typical system use cases. Do not create a scenario on your own. The general strategy is to describe the scenarios that customers can feel.

7.1 scenario (scenarios)

Create an entry for each scenario, including the following:

Scenario name: Give it a meaningful name

Scenario Description: briefly describes what the scenario is and the sequence of actions that occur.

Sequence diagram: Describes the relative time sequence of events and events.

 

7.1.1 scenario: Scenario 1

Description:

Action 1

Action 2

7.2 status chart

This part includes the status chart of the important part of the system dynamic model. You may want to draw a state chart for each object, but in fact it will lead to too much unexpected details. You only need to determine some important objects in the system and provide a state chart for them.

7.2.1 status chart 1:

8 non-functional requirements

This section describes how to handle the non-functional requirements specified in the requirement document. Evaluate the system's ability to cope with every non-functional requirement as objectively as possible. If some non-functional requirements are not fully implemented in the designed system, be sure to describe them here. In addition, you also need to estimate the future evolution of the system and describe how this design enables the system to adapt to these foreseeable changes.

9 auxiliary documents

Provides documents that help you understand the design.

10. Vocabulary Index