Write the summary design instructions correctly

Write the summary design instructions correctly

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)
4.2 System Structure Design
This section requires a description of the high-level system structure (top-level system structure, each subsystem structure), using block diagrams to show the interaction between the main components and components. It is better to separate the logical structure from the physical structure and describe the former. Don't forget to describe the sayings and symbols used in the picture.
4.3 System interface
Various interfaces and external systems provided to the user are described here. If the user interface is already described in the requirements specification, there is no need to repeat it, so 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, it must be explained here.
4.4 Constraints and assumptions
Describe the most important constraints in system design, which are mandated by the customer and are 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 assistance, the system may be subject to other constraints. In this case, it is required to clearly describe the type of software that interacts with the system and the constraints that result.
The language and platform implemented will also be binding on the system, as described here.
For the constraints of the system due to the choice of the specific design implementation, briefly describe your ideas, how to weigh, why to take such a design and so on.
5 Object Model
Provide an object model of the entire system, if the model is too large, according to the feasible criteria to divide it into small pieces, such as the client and the server side of the object model can be divided into two diagram representation. In which all system objects should be included. These objects are obtained 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 identified. Each diagram must be accompanied by a simple description.
6 Object Description
In this section, we describe the details of each object, its properties, its methods. Before this, you must logically organize the objects. You may need to divide the object into subsystems by using a structure diagram.
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, indicating that it is a persistent object, otherwise it is a temporary object (transient. Object).
Detailed description of each property of each object: First name, type, if the property is not very intuitive or constrained (for example, the property of each object must have a unique value or the range is a finite positive integer, etc.).
Detailed description of each method for each object: Method name, return type, return value, parameters, purpose, and a brief description of the algorithm used (if not particularly simple). If the variables or return values are assumed, pre-conditions and post-conditions must be described here. Lists the properties that it or the method called by it needs to access or modify. Finally, you provide a test case that validates the implementation method.
7 Dynamic Models
This part of the role is to describe how the system responds to various events. General use of sequence diagrams and state diagrams.
Determining the different scenarios (Scenario) is the first step and you do not need to identify all the possible scenarios, but you must overwrite at least the typical system use case. Instead of creating the scene yourself, the usual strategy is to describe the scenarios that customers can feel.
7.1 Scenes (Scenarios)
Make an entry for each scenario, including the following:
Scene Name: Give it a name that can be words too literally.
Description of the scene: a brief account of what the scene is and the sequence of actions taken.
Sequence diagram: Describes the relative chronological order of events and events.
7.2 State diagram
This section includes a state diagram of the important parts of the system dynamic model. You might want to draw a state diagram for each object, but in fact it can lead to too much undesirable detail, just to identify some important objects in the system and provide them with a state diagram.
8 Non-functional requirements
V. Summary design HOW to do
Structured Software Design Methodology:
Read the requirements specification, understand the system construction objectives, business status, the existing system, customer requirements of the functional description;
Analyzing data flow chart and figuring out the process of processing;
The type of data processing problem (transform type, transaction type, other type) is determined according to flow graph;
Through the above analysis, the initial structure diagram of the system is deduced.
Improvement of the initial structure: all the processing must be able to correspond to the corresponding modules (the integrity of the module is that they have completed the requirements of all processing), to eliminate the exact similar or local similar repetition function (the wise to observe the same), clear the hierarchy between the modules, control relations, reduce the high fan out structure, with the depth of the fan into Balance module size.
Complement the modifications to the data dictionary, export the logical data structures, and export the operations on each data structure, which should belong to a module.
Determine which application service systems, clients, and database management systems are included in the system;
Determine which application server or client directory each module is placed on, which file (library), or what objects are built within the database.
A list of each filtered module is described.
A list of logical data structures is described.
According to the structure of the structural Software Design specification, the other needs to explain the problem to be supplemented, the formation of a summary design manual.
OO Software Design Methodology:
Design objects and classes on a OOA basis: After the problem domain analysis (business modeling and requirements analysis), start building the system architecture.
The first step is to extract the conceptual model of the established domain, which is represented in UML to establish object class diagram, activity diagram and interaction diagram. An object class is a class that has been "observed" from an object to find common features between a set of objects:
Properties of objects and classes: data structures;
Object and Class service operation: The implementation algorithm of the operation;
The implementation structure of the external relations between the object and the class;
Design strategy: Make full use of existing classes;
Methods: Inheritance, reuse and evolution;
The activity diagram is used to define the workflow, which mainly describes the 5W of the workflow (do-to, who does, when does, Where do, and why does), and the interaction diagram that ties people and business together 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 perfect 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 the subsystems, each subsystem can be represented by use case model, analysis model, design model and test model. Two ways of software system structure: hierarchy, block
Hierarchy: Systems, subsystems, modules, components (the same layer has independence);
Block structure: weak coupling with each other
Components of the system:
Problem domain: Business-related classes and objects (the focus of OOA);
Human-machine Interface: window, menu, button, command and so on;
Data management: Data management method, logical physical structure, Operation object class;
Task Management: Task coordination and management processes;
The third step is to use the "4+1" view to describe the system architecture: use case views and scripts, describe the design view of the architecture, compose packages and layers in a modular form to implement a view of a summary implementation model, and a process view that describes processes and threads and their schemas, allocations, and interactions. Description of the system's configuration view of the 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 (simplicity is enjoyment).
Vi. Principles of Outline design
General principles and methods: from coarse to fine principles, the principle of mutual integration, qualitative and quantitative analysis of the combination of methods, decomposition and coordination of methods and modeling methods.
Systematic consideration should be given to the generality, relevance, integrity and hierarchy of the system.
Decomposition and 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 coordination within the system, that is, according to the total structure of the system, total function, total tasks and overall objectives of the requirements, so that each subsystem coordination with each other, on the basis of local optimization of each subsystem, through the coordination of internal balance control, To achieve the overall optimization of the system;
Masking abstraction: Starting with a simple frame, with hidden details;
Consistency: Unified norms, unified standards, a unified document model;
Each module should have a uniformly named easy-to-understand name;
Coding: From Inside Out (interface-core);
User-oriented: The summary design is a brief description of the system "How to Do" after the button is pressed.
Modules, components of the full independence, sealing;
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 the right developer, and facilitates division and assembly. (Detailed description See my other article: System architecture design should consider factors);
Establish the overall structure of each architectural view: the detailed organizational structure of the view, the grouping of elements, and the interfaces between these major groupings;
Software architecture and the use of the technology platform is closely related to the current common platform has the Java EE,. NET, CORBA and so on, so the specific software architect should have the use of these platforms software development experience;
By matching the requirements function with the list of design modules, check that each requirement function has a corresponding module to ensure the traceability of demand functions and the completeness of requirements (modules), as well as the ability to inspect repetitive and unnecessary modules.
It is important to understand the completeness and accuracy of the business process during the analysis of the demand research. The survey understands that all business processes can be designed to fit the business characteristics and habits of each process business node, making the software developed more popular. Of course, in the software outline design, to try to exclude the business process constraints, that is, the process of the various business node work as a separate object, designed as a separate module, take full account of their interface with various other business object modules, between the process through the business object module mutual calls to achieve a variety of business, so, When there is a limited change in the business process (the business logic of each business module itself is not changed), it is easy to modify the calling relationship between the System program modules to realize the new requirements. If this invocation relationship is designed to be stored in the data dictionary of the Configuration Library, then the program code is not modified, just modify the module invocation rules in the data dictionary.
Vii. important output of the outline design
Coding specification: Information Form, interface specification, 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);
Overall system layout: Which parts are composed, the parts are physically and logically interrelated;
Two non-negligible outputs:
Relationship to the requirements function: For each function in the requirements, which layer, which module, which class, which object to implement (one-to-many relationship); In turn, you should explain what the system will be created for each layer, each module, each object, and each class, and what they are doing to help implement (one-to-many relationships). (The granularity of demand is often coarse at the beginning, so it is also relatively large to estimate the overall project size according to the function point or to get the project WBS with its error range.) The more important reason is that the requirement is often not the exact basis of the coding work decomposition, because the function point of a requirement may correspond to multiple code modules, and the function points of multiple requirements may correspond to only one or a few code modules, while there are some factors to consider, such as software reuse, Therefore, only after the completion of the summary design can accurately get the detailed design or coding phase of the two WBS, and estimate the more accurate overall project size. ）
Logical AND physical location: Each object logically falls on which layer, which module, which class, and which directory, which file (library) of each module, each object, each class is placed on which application server or client, or what is built into the database management system (procedures, functions, views, triggers, and so on).
A comparison of the characteristics of structure and object-oriented methods
1. From a conceptual perspective, structured software is a collection of functions, implemented through modules and hierarchical call relationships between modules and modules; object-oriented software is a collection of objects, which is realized through communication between object and object.
2. From the perspective of composition, structured software = process + data, process-centric, object-oriented software = (data + corresponding operation) of the package, data-centric;
3. From the aspect of Operation control, the structured software adopts sequential processing mode, which is controlled by the process, and the object-oriented software adopts the interactive and parallel processing mode, which is controlled by message-driven;
4. In terms of development, the focus of the structural approach is on design; the object-oriented approach focuses on analysis, but in a structured approach, the analysis phase and design phase use a non-consistent expression, It is necessary to transform the flow chart with network characteristics in the analysis stage into a structured graph with layered features used in the design phase, and there is no such problem in object-oriented method.
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;
Reference documents:
"Practical Software Engineering" Second Edition, Zheng, Yin, Tau Yongrei and so on
Microsoft Project: The Law of Survival, Steve McConnell, Yu Mengxue
"Software Engineering: A practitioner's approach to research" (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;