Asus Bo Net WWW.CHINA-B.C0M April 22, 2009 Source: the InternetASUS BO Network Core tip: Do the software to a certain level, it is necessary to consider the design, design for a long time, is not the system, the system design needs a record, record on the document, then all the project including technical
Do the software to a certain level, it is necessary to consider the design, design for a long time, is not a system, the system design needs a record, records on the use of documents, then the project all including technical design are recorded, we can understand as the software outline design. Project Manager Blog
Before the need is clear, ready to start coding, to do the outline design, and the detailed design may be most of the company did not do, and do most of it and coding synchronization, or after coding. 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.
Project Management Forum
First, the question of the proposed
Outline design for what to write. Outline design how to do. Project Manager Blog
How to judge the design of the module is complete. Transferred from
Why the design stage too much attention to business processes is a misunderstanding.
Evaluate the development effort and guide the development plan accurately with the requirements analysis document or the profile design document.
Good structure or object oriented.
Please find the answers to the above questions in the article.
Second, the purpose of the outline design
Transform the software system requirements into the design of the future system;
Gradually develop a strong system structure;
Make the design suitable for the implementation of the environment, in order to improve performance and design;
Structs should be decomposed into modules and libraries.
Bbs. MYPM. Net
Iii. tasks of the outline design
Develop specifications: Code system, Interface specification, naming rules. This is the basis of the team's future joint operations, with the development of norms and program modules and project members of the interface between the rules, ways and means, we have a common working language, common work platform, so that the whole software development work can be coordinated and orderly.
Overall structure design:
function (processing)-> module: Each function with those modules to achieve, ensure that each function has a corresponding module to achieve;
Module hierarchy: A view of the software frame of an angle;
The call relationship between modules: A general description of the interface between modules;
Interface between modules: information transmitted and its structure;
Process design: Algorithms to meet function and performance
User interface design, project management training
Data structure Design:
Detailed Data structure: table, index, file;
Algorithm related logical data structure and its operation; project management training
The program module description of the above operation (at the front desk). In the background. With the view. With the process. )
Data structure and usage rules of interface control table
Other performance design.
Project Management Forum
Iv. Summary Design Write what project management forum
Structural Software Design specification structure (due to limited space and outdated suspicion, not too much explanation here)
Project Management Forum
Tasks: Objectives, environment, needs, limitations;
Overall design: process flow, overall structure and module, function and module relationship;
Interface Design: The general description of external users, software and hardware interface, Internal module interface (Note: interface ≈ system interface) BBS. MYPM. Net
Data structure: Logical structure, physical structure, and the relationship with 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 position, physical location;
Operation Design: Operation module combination, control, time;
Error Design: Error information, fault handling;
Other design: confidentiality, maintenance;
OO Software Design specification Structure Project Manager circle
Bbs. MYPM. Net
1 overview
System briefs, software design objectives, reference materials, revised version records
This section discusses the design objectives of the entire system and clearly describes which functions are not intended to be implemented by the system. At the same time, non-functional requirements such as performance, availability, etc. need to be mentioned. The requirements specification is an important reference for this part of the content to see the functional and non-functional requirements that are identified. Project Management Forum
This part must be clear about the full picture of the design, make sure that the reader can see what features and functions of the system to be implemented. In the subsequent documentation section, you will explain how the design is implemented.
2 Glossary
Describes the various terms used in this document. If some terms are already stated in the requirements specification, there is no need to repeat them here, and you can guide the reader to the requirements instructions.
3 Use Cases
This requires that the system use use case diagrams (UML) to have a Chinese description of each use case (the normal process).
4 Design Overview
4. 1 Brief introduction
This section requires highlighting the methodology used throughout the design (object-oriented or structured design), system architecture (e.g. client/server architecture), and appropriate technologies and tools to use (e.g. OMT, Rose)
4. 2 System Structure Design
Project Management Forum
This section provides a description of the structure of the top-level system (top system structure, subsystem structure), and uses a block diagram to show the interaction between the main components and the components. It is best to separate the logical structure from the physical structure and describe the former. Don't forget to explain the idioms and symbols used in the picture.
Project Management Training
4. 3 System interface
The various interfaces provided to the user and the external system are described here. If you have a description of the user interface in the requirements specification, there is no need to repeat it here, and 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, this must be explained here.
4. 4 Constraints and assumptions
Describe the most important constraints in system design, which are mandatory by the customer and stated in the requirements specification. Explain how the system adapts to these constraints.
Bbs. MYPM. Net
In addition, if the system interacts with other external systems or relies on other external systems to provide some function assistance, then the system may be subject to other constraints. In this case, it requires a clear description of the type of software that interacts with the system and the constraints it causes.
The language and platform of the implementation will also have constraints on the system, as explained here. Bbs. MYPM. Net
For the specific design of the implementation of the constraints caused by the system, a brief description of your ideas, after how the Trade-offs, why to take such a design and so on.
Project Management Training
5 Object Model
The object model of the whole system is provided, if the model is too large, it can be divided into small pieces according to the feasible standard, for example, the client and the server-side object model could be separated into two graph representations. You should include all the system objects in it. These objects are derived 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 defined. Each diagram must be accompanied by a simple description.
6 Object Description
In this section, the details of each object, its properties, its methods are described. The object must be logically organized before that. You may want to use the structure diagram to divide the objects by subsystem.
Bbs. MYPM. Net
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, it is indicated as a persistent object, otherwise it is a temporary object (transientobject).
Each property of each object is described in detail: First name, type, if the attribute is not intuitive or constrained (for example, the property of each object must have a unique value or a range that is a finite positive integer, etc.).
Detailed description of each method of each object: Method name, return type, return value, parameter, purpose, and a brief description of the algorithm used, if it is not particularly simple. If the variable or return value is assumed, pre-conditions and post-conditions must be described here. A property that lists it or the method it calls to require access or modification. Finally, you provide a test case that validates the implementation method.
7 Dynamic Models
The role of this section is to describe how the system responds to various events. General use of sequence diagrams and state diagrams. Bbs. MYPM. Net
Determining a different scenario (scenario) is the first step and you do not need to identify all possible scenarios, but you must at least overwrite the typical system use cases. Instead of creating scenarios for yourself, the usual strategy is to describe the scenarios that customers can feel.
7. 1 Scene (scenarios) project management training
Make an entry for each scene, including the following:
Scene Name: Give it a name that can be words too literally
Scene Description: Briefly describe what the scene is and the order in which the action takes place.
Sequence diagram: Describes the relative chronological order of events and occurrences.
7. 2 State diagram
The content of this part includes the state diagram of the important parts of the system dynamic model. You may want to draw a statechart diagram for each object, but in fact it can lead to too many unwanted details, just to identify some important objects in the system and provide a statechart diagram.
8 Non-functional requirements
V. Outline design How to do
Project Management Training
Structured Software design methods:
Read the requirements specifications, understand the system construction objectives, business situation, existing systems, customer requirements of the functional description;
Project Management Forum
Analyze data flow diagram to make clear the process of processing.
Project Manager Blog
The type of data processing problem is decided according to flow diagram (transform type, transaction type, other type);
Bbs. MYPM. Net
The initial structure diagram of the system is deduced through the above analysis. Project Management Training
To improve the initial structure: all processing should be able to correspond to the corresponding modules (the integrity of the module is that they completed all the requirements of the processing), eliminate identical or locally similar repetitive functions (wise Man), clear the hierarchy between the modules, control relations, reduce the high fan out structure, as the depth of the fan into, Balance module size.
Supplemented by modifications to the data dictionary, the logical data structure is derived, the operations on each data structure are exported, and these operations belong to a module.
Transferred from
Determine which application service systems, clients, database management systems are included in the system, and project management training
Determine which of the application servers or clients each module is placed in, which directory, which file (library), or objects created within the database. Project Manager Blog
A list description of each filtered module.
A list of logical data structures is described.
Project Management Training
According to the structure of the structural software design specifications for other issues to be explained, to form an outline design instructions.
OO Software design methods:
Design objects and classes on the basis of OOA: After the problem domain analysis (business modeling and requirements analysis), start to build the system architecture.
The first step is to extract the conceptual model of building domain, which is manifested in UML As Object class diagram, activity diagram and interaction diagram. An object class is a class that forms the common characteristics of a group of objects from within an object by "observing" it:
Bbs. MYPM. Net
Properties of objects and classes: data structure;
The service operation of object and class: implementation algorithm of operation;
The implementation structure of each external connection of the object and class;
Design strategy: Make full use of existing classes;
Methods: Inheritance, Reuse, Evolution, BBS. MYPM. Net
Activity diagrams are used to define workflows, which mainly describe the 5W (Dowhat, Whodo, Whendo, Wheredo, Whydo) of workflows, which link people and 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 construct and perfect the 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 subsystems, each subsystem can be represented by use case model, analysis model, design model and test model. Two ways of software system structure: level, block project management training
Hierarchy: System, subsystem, module, component (independent of the same layer);
Block structure: weak coupling between each other
Components of the system:
Problem domain: Business-related classes and objects (OOA);
HMI: windows, menus, buttons, commands, etc.;
Data management: Data management method, logical physical structure, Operation object class;
Task Management: Task coordination and management process;
The third step is to use the "4+1" view to describe the system architecture: Use Case view and script, description architecture Design view, module form package and layer contains the implementation view of the outline implementation model; A process view that describes processes and threads and their schemas, allocations, and interactions Describes the configuration view of the system's 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 (simple is enjoyment). Project Management Training
Vi. Principles of schematic design
General principles and methods: from coarse to fine principles, the principle of mutual integration, qualitative analysis and quantitative analysis of the combination of methods, decomposition and coordination of methods and modelling methods.
The general, relevance, integrity and hierarchy of the system should be considered systematically.
Decomposition 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 system coordination, that is, according to the overall structure of the system, the total function, the total task and the requirements of the overall goal, so that each subsystem coordination between the various subsystems on the basis of local optimization, through the internal balance of coordinated control, To achieve the overall optimization of the system;
Masking abstraction: Starting from a simple frame, and concealing details;
Consistency: Unified norms, unified standards, a unified document model;
Each module should have a uniformly named easy to understand name;
Coding: From the outward inner (interface-> core), BBS. MYPM. Net
User-oriented: summary design is a brief description of how the System "does" when the button is pressed;
Full independence and closeness of modules and components;
At the same time, static structure and dynamic operation are considered.
Each logical object should indicate its physical object (not one by one correspondence); Project Manager Blog
Each physical object has a suitable developer, and facilitates division and assembly. (Detailed explanation see oneself another article: The system structure design should consider factor);
Establish the overall structure of each architectural view: the detailed organizational structure of the view, the grouping of elements, and the interface between these major groupings;
Software architecture and the use of technology platform is closely related to the current common platform has Java EE,. NET, CORBA and so on, so the specific software architects should have the experience of software development using these platforms;
According to the list of requirements function and design module, check whether each requirement function has corresponding module to realize, ensure the traceability of requirement function and the integrality of Requirement realization (module), and check redundant and unnecessary module.
Project Manager Blog
It is important to understand the integrity and accuracy of the business process during the requirements research and analysis process. Survey to understand all business processes can be designed for each process business node user business characteristics and habits of the software, so that the development of software more popular. Of course, in the design of the software outline, as far as possible to exclude business process constraints, that is, the process of the various business nodes as a separate object, design into a separate module, fully consider their interface with various business object modules, in the process through the business object module mutual invocation to achieve a variety of business, so that When the business process has a limited change (the business logic of each business module is not changed), it is easy to modify the call relationship between the System program modules to realize the new requirement. If this invocation relationship is designed to be stored in the data dictionary of the Configuration Library, the code for the program can be changed without modification, simply by modifying the module invocation rules in the data dictionary.
Vii. key outputs of outline design project Manager blog
Transferred from
Coding Specifications: Information Form, interface protocol, 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);
The overall layout of the system: which part of the composition, the various parts of the physical and logical interrelationship;
Two output that cannot be ignored:
Relationship to demand function: For each function in the requirement, which layer, which module, which class, which object to implement (One-to-many relationship), in turn, should describe each layer of the system you will create, each module, each object, each class "what" they are to help implement what functions (One-to-many relationship). (The particle size of the demand is often coarse in the beginning, therefore, the error range of the overall project scale based on the function point is larger than that of the project WBS.) More important reason is that demand is often not the exact basis for coding work decomposition, because a demand function point may correspond to multiple code modules, and multiple requirements of the function point may only correspond to one or a few code modules, as well as software reuse and other factors to consider, Therefore, only after the outline design is completed can the detailed design or the coding phase of the two WBS be accurately obtained, and the overall project scale is estimated to be more accurate. )
Logical AND physical location: which layer each object logically falls into, which module, which class, the physical each module, each object, each class on which application server or client, which directory, which file (library), or what is built in the database management system (procedures, functions, views, triggers, and so on).
Project Manager Circle
Viii. characteristics of structured and object-oriented methods
1. From the concept aspect, the structured software is a set of functions, which is realized through the hierarchical call relationship between modules and modules, and object-oriented software is the collection of things, which is realized through the communication between objects and objects.
Bbs. MYPM. Net
2. From the aspects of composition, structured software = process + data, process-centric, object-oriented software = (data + corresponding operation) encapsulation, data-centric; Project Manager blog
3. From the aspect of Operation control, the structured software adopts sequential processing mode, which is driven by process, and object-oriented software adopts interactive and parallel processing mode, which is controlled by message-driven.
4. From the aspect of development, the focus of the structured method is the design, the focus of object-oriented method is analysis; however, in the structural method, the analysis stage and design phase adopt the not consistent expression way, need to put The data flow diagram adopted in the analysis phase is transformed into a layered structure diagram adopted in the design phase, and there is no such problem in the Object-oriented method.
5. From the aspect of application, the structural method is more suitable for the development of numerical calculation and data statistic management software which is more simple in data type, and object-oriented method is more suitable for the development of large and complex human-computer interactive software and data statistic management software.