OO Software Design Specification Structure

OO Software Design Specification Structure
1 Overview
System Overview, software design goals, references, revision records
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.
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 the description of the High-level system structure (top-level system structure and sub-system structure), and uses a block diagram to display 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.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.
In addition, if the system interacts with other external systems or relies on other external systems to provide some function assistance, the system may be subject to other constraints. In this case, it is required to clearly describe the software type that interacts with the system and the constraints that result from this.
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
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. 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. The relationship between aggregation and inheritance must be clearly determined. A simple description is required for each graph.
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 used Algorithm ). If the variables or returned values are false, pre-conditions and post-conditions must be described here. 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.
7. Dynamic Model
This part describes how the system responds to various events. 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.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.
8 non-functional requirements