| Summary:
This article is in the summary design practice and the study some experience and the study note, hoped to share with you, if has the wrong place to welcome to correct.
Key words:
Overview design, structuring, OOD
Body:
Before the requirements are clear and ready to begin coding, the outline design is done, and the detailed design may not be done by most companies, and most of the work is done in sync with the code, or after the code. 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 Write what. Outline design how to do.
How to judge the design of the module is complete.
Why the design phase too much emphasis on business processes is a misunderstanding.
Evaluate the development effort and guide the development plan accurately with the requirement analysis document or the profile design document.
Good structure or object-oriented.
Please find the answers to the above questions in the article.
Ii. purpose of the outline design
Transform the requirements of software systems into the design of future systems;
Progressively develop robust system architectures;
Make the design suitable for the implementation environment, in order to improve performance and design;
The structure should be decomposed into modules and libraries.
Iii. task of the outline design
Develop specifications: Code system, Interface specification, naming rules. This is the basis for the project team to work together in the future, with the development of norms and procedures between the module and the project members of the interface between the rules, ways and means, we have a common working language, a common working platform, so that the entire software development work can be coordinated and orderly.
Overall structural design:
function (processing), modules: Each function with those modules to ensure that each function has a corresponding module to achieve;
Module hierarchy: A software framework view of an angle;
The call relationship between modules: The overall description of the interface between modules;
Interface between modules: the 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 (in the foreground. In the background. Use the view. Use the process. ）
Data structure and usage rules for interface control tables
Other performance designs.
Iv. Summary Design What to write
Structured Software design specification structure (due to limited space and outdated suspicion, there is no too much explanation here)
Tasks: Objectives, environment, needs, limitations;
Overall design: The relationship between processing flow, overall structure and module, function and module;
Interface design: The overall description of external users, software and hardware interface; interface between internal modules (Note: interface ≈ system Interface)
Data structure: The relationship between logical structure, physical structure and 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 location, physical location;
Operation Design: Operation module combination, control, time;
Error-Prone design: error message, fault handling;
Other design: confidentiality, maintenance;
OO Software Design specification structure
1 overview
System brief, software design objectives, reference materials, revision history
This part discusses the design goal of the whole system, which clearly shows which functions are not ready to be realized when the system is decided. At the same time, for non-functional requirements such as performance, availability and so on, also need to mention. The requirements specification is an important reference for this part of the content, looking at the specific functional and non-functional requirements.
This part must be clear about the design of the whole picture, it is important to make the reader to know what the system will be implemented features and functions. In the subsequent documentation section, you will explain how the design is implemented.
2 Glossary
Describe the various terms used in this document. If some of the terms are already stated in the requirements specification, there is no need to repeat them here, so you can guide the reader through the requirements statement.
3 Use Cases
This requires the system to use use-case diagram representations (UML), which should be described in Chinese for each use case (normal handling case).
4 Design Overview
4.1 Description
This section requires highlighting the methodology used throughout the design (object-oriented or structured design), system architecture (such as client/server architecture), and the appropriate technologies and tools used (e.g. OMT, Rose)
5. From the perspective of application, the structural method is more suitable for the data type comparison simple numerical computation and the data statistic management software development; The object-oriented approach is more suitable for the development of large and complex human-computer interactive software and data statistics management software. |
