Summary: This article is some experience and learning notes in the professional design practice and learning, I hope to share with you, if you have any things, please refer to.
Keywords: profile design, structured, OOD
Text: Before the demand is clear, before you start the encoding, you must do a summary design, and the detailed design may not do most of the company, and most of them are in synchronization with coding, or after encoding. Therefore, for most companies, profile design documents are the only design documentation, which affects the rear development, test, implementation, and maintenance work.
I. What is the designation of the problem? How to do a summary design?
How to determine the design module is complete?
Why is the design phase too much attention to the business process is a misunderstanding?
Taking a demand analysis document or an overview design document to evaluate the development workload, guide the development plan accurate?
Structured or object-oriented?
The answer to the above questions should be found in the article.
Second, the purpose of summary design converts software system demand into future systems;
Gradually develop strong system architecture;
Make the design suitable for implementation of the environment to improve performance;
The structure should be broken down into modules and libraries.
Third, the task development specification for summary design: code system, interface statute, naming rules. This is the foundation of the project team in the future combat, has the interface rules between the development norms and program modules and project members, and the way, everyone has a common work language, a common work platform, making the entire software development Work can be coordinated in an orderly manner.
Overall Structure Design: Function (Processing) -> Module: Each function is implemented with those modules to ensure that each function has a corresponding module;
Module Hierarchy: Software Framework View of a Angle;
Call relationship between modules: overall description of the interface between the modules;
Inter-module Interface: The information is transmitted and its structure;
Design: Meeting the function and performance algorithm
User interface design;
Data structure design: Detailed data structure: table, index, file;
Algorithm related logical data structure and its operation;
The program module described above (in the front desk? In the background? Use a view? ·····
Data structure and rules of interface control tables
Other performance design.
Fourth, the summary design writes what structured software design specification structure (due to limited space is limited and too suspicious, there is no explanation here)
Task: Goals, Environment, Demand, Limitation
Overall design: processing flow, overall structure and module, function and module relationship;
Interface design: Overall instructions external users, soft, hardware interfaces; internal module interruption port (Note: Interface ≈ system interface)
Data structure: the relationship between logical structure, physical structure, and program structure;
Module Design: Every module "What", a brief description "How to do" (input, output, processing logic, interface with other modules, interface with other systems or hardware), what logic location, physical location;
Run design: running module combination, control, time
Error design: error message, wrong handling;
Other design: confidential, maintenance;
OO software design manual structure
1 Overview System Brief, Software Design Goals, References, Revised Version Record
This part discusses the design objectives of the entire system, which functions clearly indicate which functions are system decisions and which time is not ready. At the same time, for non-functional needs such as performance, availability, etc., it is also necessary. Demand specifications are important for this part of the content to see the functionality and non-functional demand. This part must be clear how the design is clear, and be sure to make the reader to see what features and functions doing the implementation system. In the subsequent document section, how is the explanation design to achieve these.
2 The glossary describes the various terms used in this document. If some terms have been described in the Demand Specification Specifications, this will not be repeated here, and you can guide the reader reference requirements.
3 Use cases require the system to use case diagram (UML), and have Chinese descriptions for each use case (normal processing).
4 Design Overview 4.1 Brief Introduction This part requires highlighting the entire design (is object-oriented or structured design), system architecture (such as customer / server structure), and the corresponding technology and tools used (such as OMT, Rose)
4.2 System Structure Design This part requires a description of the high-level system structure (top system structure, each subsystem structure), using block diagram to display the interaction between the primary components and components. Preferably, the logic structure is separated from the physical structure, and the former is described. Don't forget to explain the proverbs and symbols used in the figure.
4.3 System Interface Various interfaces to the user and external systems will be described here. If the user interface has been described in the demand specifications, it is not necessary to repeat it, and you can guide the reader reference requirements. If the system provides an interface to other systems, such as importing / exporting data from other software systems, you must explain here.
4.4 Constraints and assumptions describe the most important constraints in system design, which is compulsory and written in the demand manual. Description System how to adapt to these constraints.
In addition, if the system interacts with other external systems or provides some functional assistance, the system may also be restrained. In this case, it is required to clearly describe the type of software that interacts with the system and the constraints caused.
The realized language and platform will also constrain the system, which is also described herein.
For the constraints of the system due to the specific design implementation, you will briefly describe your idea ideas, how to trade, why should such a design, etc.
The 5 object model provides an object model of the entire system. If the model is too large, it divides it into a small piece according to the viable standard, for example, can separate the object model of the client and server to two figures. All system objects should be included therein. These objects are obtained from understanding requirements. What should be clear, which should not be placed in the picture. The association between all objects must be determined and must indicate the base of the contact. The aggregation and inheritance relationship must be clearly determined. Each figure must be attached with a brief description.
6 Objects Description In this section, the details of each object, its properties, it's. Objects must be organized from logically before this. You may need to use a structural diagram to divide the object according to subsystems.
Do an entry for each object. In the system object model, it describes its use, constraints (if there can be only one instance), list 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).
For each property of each object, the name, type, if the property is not very intuitive or constrained (for example, the attribute of each object must have a unique value or a value domain is a limited integer, etc.).
For each method of each object, the method name, return type, return value, parameters, use, and algorithms used algorithms (if not particularly simple). If the variable or the return value is assumed, pre-conditions and post-conits must be described here. List the properties that it or by the way it is called by it needs to be accessed or modified. Finally, provide test cases that can verify implementation methods. 7 Dynamic model This part of this part is to describe how the system responds to various events. Sequence diagrams and state diagrams are generally used.
Determining a different scene (SCENARIO) is the first step, there is no need to determine all possible scenes, but must at least cover the typical system use case. Don't want to create a scene yourself, usual strategy is to describe those customers who can feel.
7.1 Scenarios makes an entry for each scene, including the following:
Scene Name: Give it a name that can be written
Scene Description: Briefly describe what is dry and the order of action that occurs.
Sequence diagram: Describe the relative time sequence of various events and events.
7.2 Status Chart This section includes a state diagram of an important part of a system dynamic model. Maybe you want to draw a state diagram for each object, but in fact, it will lead to too many unexpected details, just determine some important objects in the system and provide a status map.
8 Non-functional demand 5. How to make structured software design methods: detailed reading requirements specifications, understand system construction goals, business status, existing systems, customer needs;
Analyze data flow maps and clarify the process of data flow processing;
Determine the type of data processing problem based on data flow graphs; transform, transaction, other types);
Through the above analysis, the initial structure map of the system is derived;
Improvement improvements to the initial structural map: all processing can correspond to the corresponding module (the integrity of the module lies in all the processes in the demand), eliminating a completely similar or localized repetitive function (the wise man is observed), The level, control relationship between the cleaning module, reduces the high fan-out structure, with the depth increase fan, balance module size.
Due to the modification of the data dictionary, export the logical data structure, export the operations on each data structure, which should belong to a module.
Determine which application service systems, clients, database management systems are included;
Determine which application server or client of each module, which file (library), or objects created inside the database.
A list of modules after each filter is performed.
List the logical data structure listing.
According to the structure of the structured software design, other issues need to be described, form an overview design.
OO Software Design Method: Design Objects and Categories on A OOA: After analysis (business modeling and demand analysis), the system architecture is started.
The first step is to extract the conceptual model of the establishment of the field, which is manifested in UML to establish an object class diagram, an active diagram, and interactive diagram. The object class is to form a class of common feature between the object through "an inspector" to find a group of objects:
Objects and class properties: data structure;
Objects and class services: operational algorithm;
Implementation structure of the objects of the objects and the outside of the class;
Design Strategy: Take advantage of existing classes;
Method: inherit, reuse, evolution
The activity map is used to define workflows, mainly indicating problems such as 5W (Do WHO, WHEN DO, WHEN DO, Why Do, WHEN DO, WHEN DO, Why Do), interacting people and business links together to understand the interaction process, discover business Various roles interacting in workflows. The second step is to build a comprehensive system structure: decompose the system, decompose the large system into a few subsystems, the subsystem is decomposed into several software components, and the static and dynamic interfaces between the subsystem, each subsystem can be used by the use case model , Analysis model, design model, test model representation. Two ways of software system structure: hierarchical, block
Hierarchy: System, Subsystem, Module, Components (have independent between the same layer);
Block structure: weak coupled mutual coupling
Component part of the system: Question Architecture: Business Related classes and objects (OOA focus);
Human-machine interface: windows, menus, buttons, commands, etc.
Data management: Data management methods, logical physical structure, operation object classes;
Task Management: Task Coordination and Management Process;
The third step is to use the "4 1" view to describe the system architecture: use examples and scripts; explain the design view of the architecture; form a packet and layer containing a profile implementation model; description process and threads, its architecture, allocation, and Process view of mutual relationship; explains the configuration view of the physical node on the operation platform and its task allocation. There is also an optional data view in the RUP.
The fourth step is to perform performance optimization (speed, resources, memory), model clarity, simplification (simple is enjoyable).
Sixth, principles of profile design general principles and methods: methods, decomposition and coordination methods, decomposition, and coordination methods, qualitative analysis and quantitative analysis of principles, qualitative analysis and quantitative analysis of principles, qualitative analysis and quantitative analysis.
To consider the general, correlation, integrity, and hierarchical properties of the system.
Decomposition coordination: The purpose is to create a better system. System decomposition refers to the decomposition of a complex system into several subsystems. The system coordination is the coordination within the system, that is, according to the system's summary, total function, total task, and total target requirements, each subsystem is coordinated with each other. On the basis of local optimization of each subsystem, the overall optimization of the system is achieved by internal balance;
Shield abstraction: starting from a simple frame, implicit detail;
Consistency: unified specifications, unified standards, unified file models;
Each module should have a unified naming name;
Encoding: from the outward (interface -> core);
User: Summary design is a brief description of the "how to do" after the button is pressed;
Module, full independence, closure of components;
At the same time considering static structure and dynamic operation;
Each logical object should explain its physical objects (non-one correspondence);
Each physical object has a suitable developer and is beneficial to division of labor and assembly. (For details, I see another article: The factors that the system architecture should be considered;
Establish an overall structure of each architecture: the detailed organizational structure, elements of the view, and the interface between these major packets;
The software architecture is closely related to the technical platform used. The currently used platforms include J2EE, .NET, CORBA, etc., so specific software architects should have software development experience using these platforms;
Corresponding to the list of demand functions and design modules, check if each requirements function has a corresponding module to implement, ensure the integrity of the traceability and demand implementation (module) of the requirements, and you can check repetition and unnecessary Module. The integrity and accuracy of the business processing process are very important during the demand research analysis. The survey learned that all business processes can design software that is suitable for the user's business characteristics and habits of all process business nodes, making the developed software more popular. Of course, when software summation is designed, try to exclude the service process, that is, work in the process as a separate object, design into a separate module, fully consider the interfaces of their various business object modules. Various services are implemented through the mutual calls of the business object module, so that when the business process changes (when the business logic of each business module itself is not changed), the system can be easily modified. The call relationship between the program module implements new needs. If this call relationship is designed to store the data dictionary stored in the configuration library, even the program code does not have to modify it, just modify the module call rules in the data dictionary.
7. Important output coding specifications for profile design: information form, interface statute, naming rules
Physical model: component map, configuration diagram
Different angles of architectural views: use case view, logical view, process view, deployment view, implementation view, data view (optional);
System Overall Layout: Which parts are composed, and each part is physically, logically interrelated;
Two non-negligible outputs:
Relationship with demand functions: Which layer is used, which module, which type, which object is used, which object is implemented (a pair of relationships); in turn, you should explain that every layer of the system to be created, each Module, each object, what to do, "what functions do they help implement (a pair of multiple relationships). (The particles of the demand are often relatively thick at the beginning, so according to the estimate of the functional point for the size of the overall project or the error range of the project WBS is also relatively large. More important reason is that demand is often decomposed by coding work. Accurate basis, because a demand function point may correspond to multiple code modules, and multiple demand function points may only correspond to one or a minority code module, and there is also a software reuse and other factors to consider, so it is only designed to complete The secondary WBS of the detailed design or coding phase can be accurately obtained, and the scale of more accurate overall projects is estimated.)
Logic and physical location: Which layer is logically logically, which module, which class; in physical per module, each object, which application server or client, which application server or client, which is Document (library), or what is built in a database management system (process, function, view, trigger, etc.).
8. Comparison of structured and object-oriented methods 1. From the conceptual terms, structured software is a collection of functions, realization through module and hierarchical call relationship between modules and modules; object-oriented software is a collection of things, through objects And communication between objects and objects;
2. From the perspective of the composition, structured software = process data, with process-centered; object-oriented software = (data corresponding operation) package, data-centric;
3. From the perspective of running control, the structured software uses sequential processing mode, drive control; object-oriented software adopts interactive, parallel processing mode, and is controlled by message drive;
4. From the perspective of development, the focus of structured methods is design; the focus of the object-oriented method is to analyze; however, in the structured method, the analysis phase and the design stage uses a non-matching expression, it needs to be The data flow diagram of the network feature used in the analysis stage converted to a structural diagram of the hierarchical feature used in the design phase, and there is no such problem in the object-oriented method. 5. From the application, relatively, the structured method is more suitable for the development of numerical calculations and data statistics software for data types; object-oriented methods are more suitable for large complex human machine interactive software and data statistics management software. Development;
Reference: "Practical Software Engineering" second edition, Zheng Renjie, Yin Ren, Tao Yonglei waiting
"Microsoft project: Survival law" Steve McConnell, Yu Mengxue translation
"Software Engineering: Research Method" (5th Edition) Roger S.PRESSMAN
"Software Architecture" SEI software engineering translation, Lin Bas
"RUP2000" electronic version;
"UML and System Analysis Design" Zhang Longxiang;
"Object-Oriented Analysis and Design" Yang Zhengyu;
