Specification for outline design document writing

Outline design How to write

Do the software to a certain level, it is necessary to consider the design, design for a long time, is not a system, the system design needs a record, records on the use of documents, then the project all including technical design are recorded, we can understand as the software outline design. Design Specifications for reference


Before the need is clear, ready to start coding, to do the outline design, and the detailed design may be most of the company did not do, and do most of it and coding synchronization, or after coding. Therefore, for most companies, the profile design document is the only design document that has a critical impact on the subsequent development, testing, implementation, and maintenance work.
first, the question of the proposed
Outline design for what to write. Outline design how to do.
How to judge the design of the module is complete.
Why the design stage too much attention to business processes is a misunderstanding.
Evaluate the development effort and guide the development plan accurately with the requirements analysis document or the profile design document.
Good structure or object oriented.
Please find the answers to the above questions in the article.
Second, the purpose of the outline design
Transform the software system requirements into the design of the future system;
Gradually develop a strong system structure;
Make the design suitable for the implementation of the environment, in order to improve performance and design;
Structs should be decomposed into modules and libraries.
iii. tasks of the outline design
Develop specifications: Code system, Interface specification, naming rules. This is the basis of the team's future joint operations, with the development of norms and program modules and project members of the interface between the rules, ways and means, we have a common working language, common work platform, so that the whole software development work can be coordinated and orderly.
Overall structure Design:
function (processing)-> module: Each function with those modules to achieve, ensure that each function has a corresponding module to achieve;
Module hierarchy: A view of the software frame of an angle;
The call relationship between modules: A general description of the interface between modules;
Interface between modules: information transmitted and its structure;
Process design: Algorithms to meet function and performance
user interface design;
Data Structure Design:
Detailed Data structure: table, index, file;
Algorithm-related logical data structure and its operation;
The program module description of the above operation (at the front desk). In the background. With the view. With the process. ）
Data structure and usage rules of interface control table
Other performance design.
Iv. Outline Design What to write
Structure of Software Design specification

Tasks: Objectives, environment, needs, limitations;
Overall design: process flow, overall structure and module, function and module relationship;
Interface Design: General description of external users, software and hardware interface; interface between internal modules (Note: interface ≈ system Interface)
Data structure: Logical structure, physical structure, and the relationship with program structure;
Module design: What each module "Do", a brief description of "How To Do" (input, output, processing logic, interface with other modules, and other systems or hardware interface), in what logical position, physical location;
Operation Design: Operation module combination, control, time;
Error Design: Error information, fault handling;
Other design: confidentiality, maintenance;
OO Software Design specification structure
1 Overview
System briefs, software design objectives, reference materials, revised version records
This section discusses the design objectives of the entire system and clearly describes which functions are system-determined and which are not intended to be implemented. At the same time, non-functional requirements such as performance, availability, etc. need to be mentioned. The requirements specification is an important reference for this part of the content to see the functional and non-functional requirements that are identified.
This part must be clear about the full picture of the design, make sure that the reader can see what features and functions of the system to be implemented. In the subsequent documentation section, you will explain how the design is implemented.
2 Glossary
Describes the various terms used in this document. If some terms are already stated in the requirements specification, there is no need to repeat them here, and you can guide the reader to the requirements instructions.
3 Use Cases
This requires that the system use use case diagrams (UML) to have a Chinese description of each use case (the normal process).
4 Design Overview
4.1 Brief Introduction
This section requires highlighting the methodology used throughout the design (object-oriented or structured design), system architecture (e.g. client/server architecture), and appropriate technologies and tools to use (e.g. OMT, Rose)
4.2 System Structure design
This section provides a description of the structure of the top-level system (top system structure, subsystem structure), and uses a block diagram to show the interaction between the main components and the components. 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 picture.
4.3 System interface
The various interfaces provided to the user and the external system are described here. If you have a description of the user interface in the requirements specification, there is no need to repeat it here, and you can guide the reader to the requirements description. If the system provides interfaces to other systems, such as importing/exporting data from other software systems, this must be explained here.
4.4 Constraints and assumptions
Describe the most important constraints in system design, which are mandatory by the customer 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 function assistance, then the system may be subject to other constraints. In this case, it requires a clear description of the type of software that interacts with the system and the constraints it causes.
The language and platform of the implementation will also have constraints on the system, as explained here.
For the specific design of the implementation of the constraints caused by the system, a brief description of your ideas, after how the Trade-offs, why to take such a design and so on.
5 Object Model
The object model of the whole system is provided, if the model is too large, it can be divided into small pieces according to the feasible standard, for example, the client and the server-side object model could be separated into two graph representations. You should include all the system objects in it. These objects are derived from understanding the requirements. Be clear about what should and should not be put into the diagram. The association between all objects must be determined and the cardinality of the contact must be specified. Aggregation and inheritance relationships must be clearly defined. Each diagram must be accompanied by a simple description.
6 Object Description
In this section, the details of each object, its properties, its methods are described. The object must be logically organized before that. You may want to use the structure diagram to divide the objects by subsystem.
Make an entry for each object. A brief description of its purpose, constraints (such as only one instance) in the System object model lists its properties and methods. If the object is stored in a persistent data container, it is indicated as a persistent object, otherwise it is a temporary object (transient object).
Each property of each object is described in detail: First name, type, if the attribute is not intuitive or constrained (for example, the property of each object must have a unique value or a range that is a finite positive integer, etc.).
Detailed description of each method of each object: Method name, return type, return value, parameter, purpose, and a brief description of the algorithm used, if it is not particularly simple. If the variable or return value is assumed, pre-conditions and post-conditions must be described here. A property that lists it or the method it calls to require access or modification. Finally, you provide a test case that validates the implementation method.
7 Dynamic Models
The role of this section is to describe how the system responds to various events. General use of sequence diagrams and state diagrams.
Determining a different scenario (scenario) is the first step and you do not need to identify all possible scenarios, but you must at least overwrite the typical system use cases. Instead of creating scenarios for yourself, the usual strategy is to describe the scenarios that customers can feel.
7.1 Scene (scenarios)
Make an entry for each scene, including the following:
Scene Name: Give it a name that can be words too literally
Scene Description: Briefly describe what the scene is and the order in which the action takes place.
Sequence diagram: Describes the relative chronological order of events and occurrences.
7.2 State diagram
The content of this part includes the state diagram of the important parts of the system dynamic model. You may want to draw a statechart diagram for each object, but in fact it can lead to too many unwanted details, just to identify some important objects in the system and provide a statechart diagram.
8 Non-functional requirements
V. Outline design How to do
Structured Software design methods:
Read the requirements specifications, understand the system construction objectives, business situation, existing systems, customer requirements of the functional description;
Analyze data flow diagram to make clear the process of processing.
The type of data processing problem is decided according to flow diagram (transform type, transaction type, other type);
The initial structure diagram of the system is deduced through the above analysis.
To improve the initial structure: all processing should be able to correspond to the corresponding modules (the integrity of the module is that they completed all the requirements of the processing), eliminate identical or locally similar repetitive functions (wise Man), clear the hierarchy between the modules, control relations, reduce the high fan out structure, as the depth of the fan into, Balance module size.
Supplemented by modifications to the data dictionary, the logical data structure is derived, the operations on each data structure are exported, and these operations belong to a module.
Determine which application service system, client, database management system is included in the system;
Determine which of the application servers or clients each module is placed in, which directory, which file (library), or objects created within the database.
A list description of each filtered module.
A list of logical data structures is described.
According to the structure of the structural software design specifications for other issues to be explained, to form an outline design instructions.
oo Software design methods:
Design objects and classes on the basis of OOA: After the problem domain analysis (business modeling and requirements analysis), start to build the system architecture.
The first step is to extract the conceptual model of building domain, which is manifested in UML As Object class diagram, activity diagram and interaction diagram. An object class is a class that forms the common characteristics of a group of objects from within an object by "observing" it:
Properties of objects and classes: data structure;
The service operation of object and class: implementation algorithm of operation;
The implementation structure of each external connection of the object and class;
Design strategy: Make full use of existing classes;
Methods: Inheritance, reuse and evolution;
Activity diagrams are used to define workflows, which are mainly about 5W of workflow (do What, who does, when done, Where do, and Why do), which link people and business to understand the interaction process and discover the various roles that interact with each other in the business workflow.
The second step is to construct and perfect the system structure: decompose the system, decompose the large system into several subsystems, decompose the subsystem into several software components, and explain the static and dynamic interfaces between subsystems, each subsystem can be represented by use case model, analysis model, design model and test model. Two ways of software system structure: level, block
Hierarchy: System, subsystem, module, component (independent of the same layer);
Block structure: weak coupling between each other
components of the system:
Problem domain: Business-related classes and objects (OOA);
HMI: windows, menus, buttons, commands, etc.;
Data management: Data management method, logical physical structure, Operation object class;
Task Management: Task coordination and management process;
The third step is to use the "4+1" view to describe the system architecture: Use Case view and script, description architecture Design view, module form package and layer contains the implementation view of the outline implementation model; A process view that describes processes and threads and their schemas, allocations, and interactions Describes the configuration view of the system's physical node on the operating platform and the task assignments on it. There is also an optional view of the data in Rup.
The fourth step is performance optimization (speed, resources, memory), model clarity, simplicity (simple is enjoyment).
vi. principles of schematic design
General principles and methods: from coarse to fine principles, the principle of mutual integration, qualitative analysis and quantitative analysis of the combination of methods, decomposition and coordination of methods and modelling methods.
The general, relevance, integrity and hierarchy of the system should be considered systematically.
Decomposition coordination: The goal is to create a better system. System decomposition refers to the decomposition of a complex system into several subsystems, system coordination is the system coordination, that is, according to the overall structure of the system, the total function, the total task and the requirements of the overall goal, so that each subsystem coordination between the various subsystems on the basis of local optimization, through the internal balance of coordinated control, To achieve the overall optimization of the system;
Masking abstraction: Starting from a simple frame, and concealing details;
Consistency: Unified norms, unified standards, a unified document model;
Each module should have a uniformly named easy to understand name;
Coding: From the outward inner (interface-> core);
User-oriented: summary design is a brief description of how the System "does" when the button is pressed;
Full independence and closeness of modules and components;
At the same time, static structure and dynamic operation are considered.
Each logical object should indicate its physical object (not one by one correspondence);
Each physical object has a suitable developer, and facilitates division and assembly. (Detailed explanation see oneself another article: The system structure design should consider factor);
Establish the overall structure of each architectural view: the detailed organizational structure of the view, the grouping of elements, and the interface between these major groupings;
Software architecture and the use of technology platform is closely related to the current commonly used platforms are Java-EE,. NET, CORBA and so on, so the specific software architects should have the use of these platforms software development experience;
According to the list of requirements function and design module, check whether each requirement function has corresponding module to realize, ensure the traceability of requirement function and the integrality of Requirement realization (module), and check redundant and unnecessary module.
It is important to understand the integrity and accuracy of the business process during the requirements research and analysis process. Survey to understand all business processes can be designed for each process business node user business characteristics and habits of the software, so that the development of software more popular. Of course, in the design of the software outline, as far as possible to exclude business process constraints, that is, the process of the various business nodes as a separate object, design into a separate module, fully consider their interface with various business object modules, in the process through the business object module mutual invocation to achieve a variety of business, so that When the business process has a limited change (the business logic of each business module is not changed), it is easy to modify the call relationship between the System program modules to realize the new requirement. If this invocation relationship is designed to be stored in the data dictionary of the Configuration Library, the code for the program can be changed without modification, simply by modifying the module invocation rules in the data dictionary.
vii. Important outputs of outline design
Coding Specifications: Information Form, interface protocol, naming rules;
Physical model: Component diagram, configuration diagram;
Architectural views of different angles: Use case view, logical view, process view, deployment view, implementation view, Data View (optional);
The overall layout of the system: which part of the composition, the various parts of the physical and logical interrelationship;
Two output that cannot be ignored:
Relationship to demand function: For each function in the requirement, which layer, which module, which class, which object to implement (One-to-many relationship), in turn, should describe each layer of the system you will create, each module, each object, each class "what" they are to help implement what functions (One-to-many relationship). (The particle size of the demand is often coarse in the beginning, therefore, the error range of the overall project scale based on the function point is larger than that of the project WBS.) More important reason is that demand is often not the exact basis for coding work decomposition, because a demand function point may correspond to multiple code modules, and multiple requirements of the function point may only correspond to one or a few code modules, as well as software reuse and other factors to consider, Therefore, only after the outline design is completed can the detailed design or the coding phase of the two WBS be accurately obtained, and the overall project scale is estimated to be more accurate. ）
Logical AND physical location: which layer each object logically falls into, which module, which class, the physical each module, each object, each class on which application server or client, which directory, which file (library), or what is built in the database management system (procedures, functions, views, triggers, and so on).
Viii. characteristics of structured and object-oriented methods
1. Conceptually, structured software is a collection of functions, implemented through modules and hierarchical call relationships between modules and modules; object-oriented software is the collection of things, which is realized through communication between objects and objects.
2. From the perspective of composition, structured software = process + data, process-centric, object-oriented software = (data + corresponding operation) encapsulation, data-centric;
3. From the aspect of Operation control, the structured software adopts sequential processing mode, which is driven by process, and object-oriented software adopts interactive and parallel processing mode, which is controlled by message-driven.
4. From the perspective of development, the focus of the structured approach is on design, and the focus of object-oriented methods is analysis; however, in the structured approach, the analysis phase and design phase adopt a not consistent expression, It is necessary to transform the data flow diagram with network characteristics adopted in the analysis phase into the layered structure diagram adopted in the design phase, which is not in the Object-oriented method.
5. From the perspective of application, comparatively speaking, the structured method is more suitable for the development of numerical computation and data statistic management software, which is more simple in data type, and object-oriented method is more suitable for the development of large and complex human-computer interactive software and data statistic management software.
Reference Documents:
The second edition of Practical Software Engineering, Zheng, Yin, Tau Yongrei, etc.
Microsoft Project: The Law of Survival Steve McConnell, Yu Mengxue
Software Engineering: The research Method of Practitioners (5th edition) Roger S.pressman
"Software architecture practice" sei Software Engineering translation bundle, Lin Basse
"RUP2000" electronic version;
"UML and System Analysis design" Zhanglongxiang;
"Object-oriented Analysis and design" Yang Zhengfu;