A summary outline how to do design 51CMM.COM original author: Xiamen Dragon Software Engineering Co., Ltd. Lulin Sheng [2003/12/22] Abstract: This article is some experience with study notes in outline design practice and learning, I hope to share with you, If there is anything unappropriate, please correct it. Keywords: profile design, structure, OOD text: Before demand, prepare to start encoding, to do summaries, and detailed design may not do it, 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 system design; gradually develop strong system architecture; so that the design is suitable for implementing the environment, designing performance; 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 for those modules to ensure that each function has a corresponding module to implement; module hierarchy: an angle software frame view; the modulation between modules: Overall description of the interface between the modules; interface between modules: information and its structure; processing mode design: algorithm user interface design; data structure design: Detailed data structure: table, index, file; algorithm Related logical data structure and its operation; program module description of the above operation (in the front desk? Using the view? ·····) The data structure and use rules of the interface control table have other performance design.
Fourth, the summary design writes what structured software design specification structure (due to limited space and excessive suspect, there is no more explanation) task: target, environment, demand, limit; overall design: processing process, overall structure and module, function and The relationship of the module; interface design: overall instructions external users, soft, hardware interfaces; internal module interrocation ports (Note: interface ≈ system interface) data structure: the relationship between logical structure, physical structure, and program structure; module design: Each module "What to do", briefly explain "how to do" (input, output, processing logic, interface with other modules, interface with other systems or hardware), what logic location, physical location; operation design: running module combination, Control, time; error design: error information, wrong handling; other design: confidential, maintenance; OO Software Design Structure 1 Overview System, Software Design Goals, References, Revision Record This section discusses the design objectives of the entire system , Clearly explains 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 the description of the high-level system structure (top system structure, each subsystem structure), using block diagram to display interactions 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 Make an entry for each scene, including the following: Scene Name: Give it a name scenario that can be written, a brief narrative scenario is dry and what the action 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 targets, business status, existing systems, customer needs, various functional descriptions; analysis data flow map, clear data The process of flow processing; the type of data processing problem (transformation, transaction, other type) is determined according to data flow graph; the initial structural map of the system is derived by the above analysis; the initial structural map is improved: all processing It is necessary to correspond to the corresponding module (the integrity of the module lies in all the processes in the demand), eliminating the completely similar or localized repetition (the wise man is observed), clarify the level, control relationship between the modules, and reduce the high fan 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 is placed, 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. Object classes are "informatics" identifying a common feature between a group of objects from an object, an attribute: object and class attribute: data structure; object and class service: Operation algorithm; objects and classes The implementation structure of each external connection; design strategy: Take advantage of existing classes; methods: inherit, reuse, evolution; activity maps are used to define workflows, mainly explaining 5W of workflows (Do What, WHO, WHEN DO, WHERE DO, WHY DO), etc., interactive maps link people and business together to understand the interaction process, discover all kinds of roles that interact with each other in business 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, component (independence between the same layer); block structure: Component part of the weak coupled system: problem arrest : 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; shielding abstraction: starting from a simple framework, implicit detail; consistency: unified standard, unified standard, unified document Mode; each module should have a unified named 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, Component's full independence, closure; simultaneous 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 conducive to labor With assembly. (Detailed explanation) Another article: System architecture design should be considered; establish an overall structure of each architecture: the detailed organizational structure of the view, the packet of the element, and the interface between these major packets; software architecture and use The technical platform is closely related. At present, the common platforms include J2EE, .NET, CORBA, etc., therefore, the specific software architect personnel should have software development experience using these platforms; pass the list of demand functions and design modules, check each Whether the demand function has the corresponding module to implement, to ensure the traceability and demand implementation of the requirements (module) integrity, and you can check the repeated and unnecessary modules. 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 summary design: information form, interface statute, naming rules View (optional); system overall layout: Which parts are constituted, each part is physically, logically interrelated; two non-negligible outputs: relationship with demand functions: Which one is used for every function in demand Layer, which module, which object is implemented (a couple of relationships); in turn, you should explain that every layer of the system, each module, each object, every class ", what do you do, they are In order to help what functions are implemented (a pair of multiple relationships). (The particles of the demand are often relatively thick at the beginning, so the estimation of the functional point for the overall project size or the error range of the project WBS is also relatively large.
