Correctly compile the outline design...

A Brief design should be done before the requirements are clear and the code is ready to begin. The detailed design may not be done by most companies, and most of the work is synchronized with the code or after encoding. Therefore, for most companies, the summary design document is the only design document that will have a critical impact on subsequent development, testing, implementation, and maintenance.
I. Question proposal
What is the outline design? How does the outline design work?
How can we determine whether the Designed module is complete?
Why is it a misunderstanding that the design stage places too much emphasis on business processes?
Is the requirement analysis document or the summary design document used to evaluate the development workload and guide the accuracy of the development plan?
Is it structured or object-oriented?
For the answer to the above questions, see Article .
Ii. Purpose of Outline Design
Design of converting software system requirements into future systems;
Gradually develop a strong system architecture;
Make the design suitable for the implementation environment to improve performance;
The structure should be broken down into modules and libraries.
Iii. outline design tasks
Specifications: Code System, interface specification, and naming rules. This is the foundation for the project team to work together in the future, with development specifications and Program The interface rules and methods between modules and project members provide a common working language and a common working platform, so that the entire software development work can be carried out in a coordinated and orderly manner.
Overall Structure Design:
Function (processing)-> module: each function is implemented by those modules to ensure that each function is implemented by corresponding modules;
Module hierarchy: Software Framework view from a certain angle;
Inter-module call relationship: the overall description of Inter-module interfaces;
Inter-Module Interface: transmitted information and its structure;
Processing Method Design: meets the functional and performance requirements Algorithm
User Interface Design;
Data Structure Design:
Detailed data structures: tables, indexes, and files;
Logical Data structures and operations related to algorithms;
Description of the program module for the above operations (on the frontend? In the background? View? Use process? ······)
Interface control table data structure and usage rules
Other performance designs.
Iv. Outline Design Description
Structured Software Design Specification structure (I will not explain it too much here due to space limitations and out-of-date issues)
Task: goals, environment, requirements, limitations;
Overall Design: Relationship between processes, overall structure, modules, functions, and modules;
Interface Design: general description of external users, software and hardware interfaces; interfaces between internal modules (Note: interface ≈ System Interface)
Data Structure: logical structure, physical structure, and relationship with program structure;
Module Design: "what to do" for each module, and briefly describes "How to do it" (input, output, processing logic, interfaces with other modules, and interfaces with other systems or hardware ), logical and physical locations;
Operation design: operation module combination, control, and time;
Error design: Error information and handling;
Other designs: confidentiality and maintenance;
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 brief description of the algorithm used (if not very simple ). Pre-conditions and post-conditions must be described here if any assumptions are made about the variables or returned values. 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
V. How to Implement the Outline Design
Structured Software Design Method:
Read the requirement specification in detail to understand the system construction objectives, business status, existing systems, and customer requirements;
Analyze the data flow diagram to find out the data flow processing process;
Determines the type of data processing problems (conversion, transaction, and Other types) based on the data flow diagram );
Through the above analysis, we can export the initial structure of the system;
Improved the initial structure: all processes must correspond to the corresponding modules (the integrity of the modules lies in that they have completed all the processes required ), eliminate completely similar or partially similar duplicate functions (the wise man observes the same), clarify the hierarchy and control relationships between modules, reduce the high fan-out structure, and balance the module size as the depth increases.
The modifications to the data dictionary are complete, the logical data structure is exported, and operations on each data structure are exported. These operations should belong to a certain module.
Determine which application service systems, clients, and database management systems are included in the system;
Determine the Directory and file (database) of the app server or client on which each module is stored, or the object created in the database.
List the filtered modules.
List the logical data structures.
Other issues to be explained are supplemented according to the structure of the structured software design specification to form a summary design specification.
OO software design method:
Design objects and classes based on OOA: Build a system architecture after problem domain analysis (Business Modeling and Requirement Analysis.
The first step is to extract and establish a conceptual model of the domain. In UML, it is represented by creating an object class diagram, activity diagram, and interaction diagram. An object class is used to identify the common features of a group of objects from the object and form a class:
Attributes of objects and classes: data structure;
Object and class service operations: Operation implementation algorithms;
Implementation Structure of various external links between objects and classes;
Design Strategy: make full use of existing classes;
Methods: inheritance, reuse, and Evolution;
The activity diagram is used to define a workflow. It mainly describes the workflow's 5 million (do what, who do, when do, where do, and why do) problems, the interaction diagram associates people with the 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 build a complete system structure: the system is decomposed, the system is divided into several subsystems, the subsystem is divided into several software components, and the static and dynamic interfaces between subsystems are described, each subsystem can be represented by case model, analysis model, design model, and test model. Two Methods of Software System Structure: hierarchical and block
Hierarchy: system, subsystem, module, and component (independent between the same layer );
Block Structure: weak coupling between each other
System components:
Problem domain: business-related classes and objects (the focus of OOA );
Man-Machine Interface: Windows, menus, buttons, commands, etc;
Data Management: data management methods, logical physical structures, and operation object classes;
Task Management: task coordination and management processes;
Step 3: Use the "4 + 1" view to describe the system architecture: Use Case view and script; describe the design view of the architecture; A module form consists of a package and a layer containing a summary of the implementation view of the model. It describes the process view of processes and threads and their architecture, allocation, and interaction; describes the configuration view of the physical nodes on the operating platform and the task allocation on the system. There are also optional data views in the RUP.
Step 4 is performance optimization (speed, resource, memory), model clarity, and simplification (simplicity is enjoyment ).
Vi. Outline Design Principles
General Principles and Methods: principles from coarse to fine, principles of mutual integration, methods of combining qualitative analysis and quantitative analysis, methods of decomposition and coordination, and modeling methods.
The system should consider the general, relevance, integrity and hierarchy of the system.
Decomposition and coordination: aims 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 requirements of the system's overall structure, total functions, total tasks and total objectives, coordinate and cooperate among subsystems to achieve overall system optimization through coordination and control of internal balance on the basis of local optimization of each subsystem;
Blocking Abstraction: starts with a simple framework and implies details;
Consistency: unified standardization, unified standards, and Unified File mode;
Each module should have a name that is easy to understand;
Encoding: from external to internal (interface> core );
User-oriented: The outline design is a brief description of "how to do it" after the button is pressed;
Full independence and closeness of modules and components;
Static structure and dynamic operation are also considered;
Each logical object should indicate its physical object (not a one-to-one response );
Each physical object has a suitable developer and facilitates division of labor and assembly. (For details, see my other article: factors to be considered in the system architecture design );
Establish the overall structure of each Architectural View: detailed structure of the view, grouping of elements, and interfaces between these main groups;
The software architecture is closely related to the technical platform in use. Currently, common platforms include J2EE,. net, and CORBA. Therefore, the specific software architecture personnel should have the software development experience to use these platforms;
Check whether each requirement function has a corresponding module through the list correspondence between the requirement function and the design module to ensure the traceability of the requirement function and the integrity of the requirement implementation (module, you can also check duplicate and unnecessary modules.
In the process of requirement investigation and analysis, it is very important to understand the integrity and accuracy of the business processing process. Only by investigating and understanding all business processes can we design software suitable for the business characteristics and habits of business nodes of various processes, making the developed software more popular. Of course, when performing software outline design, we should try to eliminate the constraints of the business process, that is, we should take the work of various business nodes in the process as an independent object and design them into independent modules, fully consider the interfaces between them and various other business object modules, and implement various businesses through mutual calls between processes, when the business process has limited changes (the business logic of each business module has not changed ), you can easily modify the call relationships between system program modules to meet new requirements. If the call relationship is designed to be stored in the data dictionary of the configuration library, you do not need to modify the program code. You only need to modify the module call rules in the data dictionary.
VII. Important output of Outline Design
Code specifications: Information Format, interface specification, and naming rules;
Physical Model: component diagram and configuration diagram;
Architectural views from different perspectives: Case view, logic view, process view, deployment view, implementation view, and data view (optional );
Overall system layout: What components are physically and logically related to each other;
Two outputs that cannot be ignored:
Relationship with requirement functions: for each function in the requirement, which layer, module, class, and object are used for implementation (one-to-many relationship); in turn, it should be noted that each layer, module, object, and class of the system to be created are "what" to help implement (one-to-many relationship ). (The granularity of the requirement is often rough at the beginning. Therefore, the error range of the Project WBS is also relatively large based on the estimation of the overall project scale based on the Function Points or the project WBS is obtained. The more important reason is that the requirement is often not the accurate basis for coding decomposition, because the functional points of a requirement may correspond to multiple code modules, the functional points of multiple requirements may correspond to only one or a few code modules, as well as software reuse and other factors to consider, therefore, the secondary WBS of the detailed design or coding phase can be obtained accurately only after the outline design is completed, and the overall project scale is estimated to be more accurate .)
Logical and physical location: the logical layer, module, and class of each object; physically, each module, each object, and each class are stored in the app server or client directory and files (databases ), or what is built on the database management system (processes, functions, views, triggers, and so on ).
VIII. Comparison of features between structured and object-oriented methods
1. in terms of concept, Structured Software is a set of functions, implemented through modules and hierarchical call relationships between modules. object-oriented software is a collection of things, through communication between objects and objects;
2. In terms of composition, Structured Software = process + data is process-centric; Object-oriented software = (Data + corresponding operations) is encapsulated and data-centric;
3. From the perspective of Operation Control, structured software adopts the sequential processing mode and is controlled by process drivers. object-oriented software adopts interactive and parallel processing methods, and is controlled by message drivers;
4. from the perspective of development, the focus of structured methods is design; the focus of object-oriented methods is analysis; however, in structured methods, the analysis phase and design phase adopt inconsistent expressions, and the data flow diagram with network characteristics adopted in the analysis phase needs to be converted into the structure diagram with hierarchical characteristics adopted in the design phase, this problem does not exist in object-oriented methods.
5. from the perspective of application, the structured method is more suitable for the development of relatively simple numerical computing and data statistics management software for data types; the object-oriented method is more suitable for the development of large-scale and complex man-machine interactive software and data statistics management software;
References:
The second edition of practical software engineering, such as Zheng Renjie, Yin renkun, and Tao yonglei
Microsoft Project: Survival law by Steve McConnell, translated by Yu mengxue
Software Engineering: Research Methods for practitioners (5th) by Roger S. Pressman
Sei Software Engineering Translation, by Lin basi
An electronic version of rup2000;
Zhang longxiang, UML and system analysis design;
Yang Zhengfu, Object-Oriented Analysis and Design;