1 overview
1. 1 system introduction
The brief description of the content to be completed, the users to be faced and the environment in which the system runs mainly comes from the beginning of the requirement specification.
1.2 software design objectives
This part discusses the design goal of the whole system, and clearly explains which functions the system decides to realize and which functions it does not intend to realize. At the same time, non-functional requirements such as performance and usability should also be mentioned. Requirements specification is an important reference for this part. Look at the functional and non-functional requirements defined in it.
This part must clearly explain the overall design and ensure that readers know what features and functions the system will have after reading. In the following document section, we will explain how the design can achieve this.
1.3 reference
List the references cited in this document. (At least quote the requirement specification)
1.4 revision record
Lists the modification history of this document. You must specify the modified content, date and modifier.
2 glossary
Explain the various terms used in this document. If some terms have been explained in the requirements specification, there is no need to repeat them here, and readers can be guided to refer to the requirements specification.
3 use cases
Here, the system is required to be represented by use case diagram (UML), and each use case (normal processing situation) should be described in Chinese.
4 design overview
4. 1 Introduction
This part requires highlighting the methods (object-oriented design or structured design), system architecture (such as client/server structure) and corresponding technologies and tools (such as OMT and Ross) used in the whole design.
4.2 System Structure Design
This part requires describing the high-level system structure and using block diagrams to show the main components and the interactions between them. It is best to separate the logical structure from the physical structure and describe the former. Don't forget to explain the idioms and symbols used in the pictures.
4.2. 1 top system structure
4.2.2 Subsystem 1 Structure
Structure of subsystem 2
4.3 System Interface
Various interfaces provided to users and external systems are described here. If the user interface has been described in the requirements specification, there is no need to repeat it here, and the reader can be guided to refer to the requirements specification. If the system provides an interface with other systems, such as importing/exporting data from other software systems, it must be stated here.
4.4 Constraints and assumptions
Describe the most important constraints in system design, which are mandatory by customers and stated in the requirements specification. Explain how the system adapts to these constraints.
In addition, if the system interacts with other external systems or relies on other external systems to provide some functional help, then the system may be subject to other constraints. In this case, it is necessary to clearly describe the types of software interacting with the system (such as XXX database software and XXX mail software) and the resulting constraints (such as allowing only plain text mail).
The language and platform implemented will also have constraints on the system, and there are also explanations here.
For the constraints on the system caused by choosing a specific design, briefly describe your thoughts, what kind of trade-offs, why you should adopt such a design, and so on.
5 object model
5. 1 system object model
Provide the object model of the whole system. If the model is too large, divide it into small pieces according to feasible standards. For example, the object models of client and server can be divided into two graphs.
What should an object graph contain?
It should contain all system objects. These objects come from the understanding of requirements. Be clear about what should be put in the chart and what should not be put in it.
The association between all objects must be determined, and the cardinality of the association must be indicated (one-to-one, one-to-many or many-to-many, 0... 1, *, 1 ...*). The relationship between aggregation and inheritance must be clearly defined. Each number must be accompanied by a simple explanation.
It may take many iterations to get the correct system object model.
6 object description
In this part, the details, attributes and methods of each object are described. Before that, objects must be logically organized. You may need to use structure diagrams to divide objects into subsystems.
Create an entry for each object. Briefly describe its purpose and constraints (such as only one instance) in the system object model, 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.
Explain each attribute of each object in detail: name, type, if the attribute is not very intuitive or constrained (for example, the attribute of each object must have a unique value or the value range is a finite positive integer, etc.). ).
A detailed description of each method of each object: method name, return type, return value, parameters, purpose and a brief description of the algorithm used (if not particularly simple). If a variable or a return value is assumed, the preconditions and postconditions must be stated here. Lists the properties that it or the methods it calls need to access or modify. Finally, the implementation method is verified by a test case.
6. Objects in 1 subsystem1
6. 1. 1 object: object 1
Use:
Constraints:
Persistence:
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:
Prerequisites:
Postcondition:
Properties read/modified:
Called method:
Processing logic:
Test case: What parameters are used to call this method and what is the expected output? ...
7 dynamic model
The function of this part is to describe how the system responds to various events. For example, the behavior model of the system can be established. Sequence diagram and state diagram are generally used.
Determining different scenes is the first step. It is not necessary to determine all possible scenarios, but at least typical system use cases must be covered. Don't take it for granted to create the scene yourself. The usual strategy is to describe the scenes that customers can feel.
7. 1 scene
Create an entry for each scene, including the following:
Name of the scene: Give it a meaningful name.
Scene description: briefly describe what the scene does and the sequence of actions.
Sequence diagram: describes various events and their relative time sequences.
7. 1. 1 scene: scene 1
Description:
Action 1
Action 2
7.2 state diagram
This part includes the state diagram of the important part of the system dynamic model. Maybe you want to draw a state diagram for each object, but it will actually lead to too many unexpected details. You only need to identify some important objects in the system and provide them with state diagrams.
7.2. 1 state diagram 1:
8 non-functional requirements
In this section, it is necessary to explain how to deal with the non-functional requirements specified in the requirements document. Evaluate the system's ability to handle each non-functional requirement as objectively as possible. If some non-functional requirements are not fully realized in the designed system, please be sure to explain them here. In addition, you need to estimate the future evolution of the system and describe how this design can adapt the system to these foreseeable changes.
9 auxiliary documents
Provide relevant documents to help you understand the design.
10 glossary index
Article entry