Abstract:
This article is a summary of the design at the practice and study some of the experiences with the study notes, I hope to share with you if there is inappropriate please correct me.
Keyword:
Summary of design, structural, OOD
Body:
At the demand for clear and ready to start coding before the design to do a summary of the detailed design of most companies is not likely to do, also have to do most and coding are carried out simultaneously, or after the encoding. Therefore, most of the companies, a summary of the design document is the only design documents on the back of the development, testing, implementation, maintenance play a key impact.
First, the problem
Writing a summary of what design? Summary of how to do design?
How to determine the design of the module is complete?
Why do I say that too much emphasis on the design phase of business processes is a misunderstanding?
Demand analysis of the document or a summary of the development of design documents to assess the workload of the guidance development plan accurate?
Structured object-oriented good or good?
Answers to these questions, please look at the article.
Second, the outline is designed to
Software system needs to be converted to future systems design;
Gradually developed a strong system architecture;
Designed to enable the implementation of suitable environment for the design and improve performance;
Structure should be broken down into modules and libraries.
Third, a summary of the design mission
Norm-setting: the code system interface statute, naming rules. This is the project team of the foundation for future joint operations, with the development of norms and procedures and projects between modules of the interface between the members of the rules, ways and means, everyone will have a common working language, a common job So that the whole software development work can be coordinated and orderly manner.
The overall structure of the design:
Functions (processing) -> modules: each functional module implementation by those who ensure that every function has a corresponding implementation module;
Module-level structure: a certain point of view of the software framework;
Call the relationship between modules: Module interface between the general description;
Inter-module interface: the message and its structure;
Treatment design: meet the functionality and performance of the algorithm for user interface design;
Design:
Detailed data structure: tables, indexes, documents;
Algorithm related to the logical data structure and its operation;
Program modules to operate the above-mentioned note (in the foreground? In the background? Using view? ?······) With the process of
Interface Control Table data structure and use of other performance-based design rules.
Four, Designed to write a summary of what
Structured software design specification structure (due to space limitations and outdated suspects, and I shall not too much to explain)
Missions: objectives, environment, needs, limitations;
Design: deal flow, overall structure and modules, functions and modules of the relationship;
Interface Design: Overall description of external users, software and hardware interfaces; internal inter-module interface (Note: ≈ Interface System Interface)
Data structure: the logical structure, physical structure, the relationship between structure and procedures;
Modular design: each module, "What to do", a brief description of "how to do" (import, export, processing logic, and other modules interface with other systems or hardware interface), what kind of logic in the location, physical location;
Designed to run: Run modules, control, time;
Designed error: error information, the Agency deal with mistake;
Other design: confidentiality, maintenance;
OO software design specification structure
1 outlines
System briefly, software design objectives, reference materials, a revised version of Record on this part of the whole system design objectives, clearly indicate which function is to achieve and what the system decided not ready for implementation. At the same time, for non-functional requirements such as performance, availability and so on, also referred to. Requirements specification specification for this part of the content is very important to reference, take a look at one of clearly defined functional and non-functional requirements.
This part must be made clear picture of how to design, to ensure that readers will look after the implementation of the system to know what features and functions. In the subsequent part of the document will explain the design is how to achieve this.
Glossary 2
In this document used to explain various terms. If some terms in the specification of requirements specification has been explained, and do not have to repeat here, you can demand that the reader is referred to the guidelines.
3 Use Cases
System used here to request statements Use Case Diagram (UML), for each use case (normal deal with the situation) should be described in Chinese.
4 Designed brief overview of 4.1
This part of the requirements throughout the design to highlight the methods used (which is object-oriented design or structural design), system architecture (such as client / Structure) and the use of the corresponding technologies and tools (such as OMT, Rose)
4.2 Design
This part of the requirements to provide high-level system architecture (top-level system architecture, the subsystem structure) description, use the block diagram to show the main components and interactions among components. Logical structure of the best are put with the physical structure of the separation of the former description. Do not forget to note the figure goes and symbols used.
4.3 System Interface
Variety available to the user's interface and external systems to be described here. If the instructions in the requirements specification of the user interface has been described here do not have to repeat, you can demand that the reader is referred to the guidelines. If the system provides the interface to other systems, for example, from other software system import / export data, must draw a distinction here.
4.4 Constraints and assumptions
Describe the most important system design constraints, these are mandatory requirements by the client and instructions stated in the demand. Help system is how to adapt to these constraints.
In addition, if the system interact with other external systems or rely on other external systems to provide some auxiliary function, then the system may also be subject to other constraints. Under the circumstances, request a clear description and the system has the type of interactive software and this has led to the binding.
Implementation language and platform will have on the system constraints, at this same explanation.
For selection of specific design and implementation lead to system constraints, briefly describe your thinking mind, after the weigh how to, why should we adopt such a design and so on.
5 Object Model
Provided throughout the system object model, if the model is too large, in accordance with the feasible Put it into small pieces, for example, can put client and server-side object model diagram into two separate statements. At one of the system should include all objects. These objects are from understanding the needs of after. What should be clear, and which should not be included in the figure. The links between all objects must be identified and linked to the base must be specified. Aggregation and inheritance relationship must be clearly defined. Each map must be accompanied by a simple note.
6 Object Description
In this section describes the details of each object, its property, and its methods. Prior to that must be logically organized to object. You may need to put structure into a good object by subsystem.
To make an entry for each object. In the system object model briefly description of its use, constraints (such as only one example), listed its property and methods. If the object is Data at sustained container, indicating it is a persistent object, otherwise it is a temporary object (transient object).
For each object of a detailed description of each property: name, type, if the property is not very intuitive or have bound (for example, each object of the property must have a unique value or range is limited positive integer, etc.).
For each object of a detailed description of each method: The method name, return type, return values, parameters, and the use of the algorithm uses a brief description (if not particularly easy, then). If the return value of the variable or what if the assumption that, Pre-conditions and Post-conditions must draw a distinction here. Listed in it or it calls the method required to visit or modify the property. Finally, the implementation method can be verified to provide test cases.
7 Dynamic Model
This part of the role is to describe how the system response to various events. Generally used sequence diagram and state diagram.
Determine the different scenes (Scenario) is a first step, do not need to identify all possible scenarios, but must at least cover the typical system use cases. Do not go assuming the creation of scenes, the usual strategy is to describe the feelings of those clients can be scene.
7.1 scenario (Scenarios)
For each scene to do an entry, include the following:
Scene name: give it a name the words too literally described the scene: a brief description of the scenes are doing as well as the sequence of actions happen.
Sequence Diagram: Describes a variety of events and the relative case happened in chronological order.
7.2 State Diagram
This part of the system dynamic model includes the important part of the state diagram. Possible for each object you want to draw a state diagram, but in fact will lead to too many do not expect the details of information, the system only need to identify a number of important objects and to provide the state diagram can be.
Eight non-functional needs of five, a summary of how to do the structural design of software design methods:
A detailed requirements specification to read instructions, understand the system-building objectives, operational status quo, the existing system, customer demand for functional description;
Analysis of data flow diagram, identify the process of data stream processing;
Data flow diagram in accordance with the decision problem of the type of data processing (transform-type, transaction type, other type);
Through the above analysis, derived from the initial structure of the system;
The initial structure for improved: all the processing must be mapped to the corresponding module (module integrity demand that they completed all of the processing), to eliminate completely or in part similar to the duplication of similar functions (Wise Review with), sort out inter-module level, control the relationship, reduce the high fan-out structure, with increasing fan-depth, balanced module size.
From the data dictionary changes to complement derived logical data structure, data structure on each export operation, these operations should belong to a module.
What are the application of the system service system, client, database management systems;
On each module to determine which application server or the client which directory, which file (library), or the internal set up in the database object.
For each filter the list after the module description.
Logical data structure for a list of notes.
According to the structure of software design specification structure on the other issues that required additional information, forming a summary of the design specification.
OO Software Design Methods:
Designed on the basic OOA objects and categories: analysis of the problem areas (business modeling and requirements analysis), the beginning of the establishment of system architecture.
The first step is to set up the field taken from the concept model, shown in the UML for the establishment of object class diagram, activity diagram and interactive map. Object class from the object after a "review with" a certain group of objects to identify the common characteristics between the formation of categories:
Object with the type of attributes: data structure;
Object with the type of service operation: the operation of algorithm implementation;
Object with the type of implementation of various external link structure;
Design Strategy: full use of the existing categories;
Methods: inheritance, reuse, evolution;
Activity diagram is used to define work flow, the main stream of the job description 5W (Do What, Who Do, When Do, Where Do, Why Do) and so on, interactive map and put the business are linked in order to understand the interaction process and found that business Workflow mutual interaction of various roles.
The second step is to build a perfect system architecture: the system decomposition, large-scale system will be decomposed into a number of subsystems, subsystem decomposition for a number of software components and subsystems that between static and dynamic interfaces, each subsystem can be used Example model, analysis model, design model, test model. Software system structure in two ways: the level of block-level structure: systems, subsystems, modules, components (with a layer of independence between);
Block structure: the weak coupling between
System components:
On the problem domain: business-related classes and objects (OOA focus);
Man-machine interface: windows, menus, buttons, commands and so on;
Data management: data management methods, the logic of the physical structure, operation object class;
Task Manager: Task coordination and management process;
The third step is the use of "4 +1" view description of system architecture: use case view and scripts; Description Architecture Design view; as a module component kits and implementation layer contains a summary of the implementation model view; explain the process and thread and its architecture, distribution and relations of mutual interactive process view; Help system in the operating platform on the physical nodes and their distribution on the mission configuration view. There are at RUP optional data view.
The fourth step is to optimize the performance (speed, , Memory), the model of clarity, simplicity (that is easy to enjoy).
VI, a summary of the principles of design
General principles and methods: from coarse-to-fine principle, combine the principles of qualitative analysis and quantitative analysis of a combination of methods, decomposition and coordination methods and modeling methods.
To the system to consider the general system, relevance, integrity and level of sexual.
Decomposition and coordination: The aim is to in order to create a better system. System decomposition refers to a complex system is decomposed into several sub-systems, system coordination system to coordinate first, that the general structure of the system, with a total function, mission and overall objective of the total requirements of the various subsystems in co-ordination between in various sub-systems based on local optimization, the coordination of the balance through internal control, implementation of the overall system optimization;
Shielding abstract: a simple framework from the beginning, implied details;
Consistency: a unified specification, unified standard, unified document model;
Each module should have a unified naming names easy to understand;
Coding:由外向内(interface -> core);
User-oriented: a summary of the design for the buttons are pressed after the system "how to do" a brief description;
Modules, components, full independence, closed;
Taking into account the static structure and dynamic operation;
Each logical object which should indicate its physical object (non-one correspondence);
Every physical object has a suitable developer, and in favor of the division of labor and assembly. (Detailed description see my other article: System Factors should be considered);
Established in each of the overall structure of the framework view: view detailed organizational structure, elements of the grouping as well as the interface between the major groupings;
Software architecture with the use of the technology platform is closely related to the most commonly used platform has , , CORBA and so on, so a specific software architecture personnel should have the use of these platforms, software development experience;
Through the demand function and design of the corresponding list of modules, each of the demand function to check whether there are corresponding module implementation to ensure that the demand function of the demand for traceability and implementation (module) the integrity, at the same time can check the duplication and unnecessary module.
Research at the demand for analysis of business process know the integrity and accuracy is very important. Investigate and try to find out all the business processes in order to design a suitable business node of the flow characteristics and habits of business users of software to enable the development of the software more popular. Of course, in a summary of the design of software to business processes as far as possible the constraints, that is, put the business flow in the node job as an independent object, designed as an independent module, take full account of their various business objects with other interface modules in the flow through the business objects between the modules call each other achieve a variety of business, so that happened in the business process changes in a limited (one for each business of the business logic module itself has not changed circumstances), it more convenient to be able to modify system procedures for inter-module calls realize the relationship between the new demands. If this relationship is designed to call stored in the configuration in the database dictionary, then even do not need to modify code, just modify the data dictionary of the module can call the rules.
Seven, a summary of important design output
Encoding specification: the form of information, interface statute, naming rules;
Physical model: component diagram, deployment diagram;
The framework of different perspectives view: use case view, logical view, process view, deployment view, implementation view, Data View (optional);
The overall layout of the system: What components, on the various parts of the physical, on the relationship between logic;
The output of the two can not be ignored:
And demand function: For each of the demand function, with which a layer, which module, which category, which objects to achieve (one-to-many relationship); in turn, should indicate the system will have to create each layer, each modules, each object, each type of "what to do," they are in order to help achieve what function (one-to-many relations). (Demand for particle size at the beginning is often the one relatively thick, so in accordance with Function Point size of the overall project estimate or project WBS its error range is relatively large. More important reason is that demand is often not the coding job decomposition accurate basis, because the function of a demand point may correspond to multiple code modules, and multiple demands of the points may also correspond to only one or a small number of code modules, as well as software reuse and other factors to consider, so only a summary of design is completed before they can be accurately detailed design or coding stages of the second WBS, and estimate more accurately the size of the overall project.)
Logic and physical location: at the logic of each object on which rests a layer separately, which module, which type; in physics on each module, each object, each type on which application server or the client which directory, which Documents (library), or are set up in the database management system what Dongdong (procedures, functions, views, triggers and so on).
Eight, structure and characteristics of object-oriented method compared
1. Look from the concept, structure and function are a collection of software, through the module, as well as modules and module calls the relationship between the layered implementation; object-oriented software is a collection of things, through the object and the object and the object of the communication links between implementation;
2. Look from the composition, structure, software = process + data to process for the center; object-oriented software = (data + the corresponding operation) of the package and data-center;
3. From the operation of the control side, the structure of software to adopt the order of treatment modalities, from process-driven control; object-oriented software using interactive, parallel processing methods, by the message-driven control;
4. Look from the development, structured methods are focused on job design; object-oriented methods are the focus of job analysis; however, structured methods, the analysis phase and design phase does not correspond to the use of the expression, the need to used in the analysis phase of the network characteristics of data flow diagram is converted to the design stage with the use of layered structure characteristics, in object-oriented methods do not exist the problem.
5. From the application side, relatively speaking, more suitable methods of structured data type is relatively simple numerical computing and data management software development; object-oriented method more suitable for large complex man-machine interactive software and data management software development;
References:
"Practical "Second edition,郑人杰,殷人Queensland, TAO Lei waiting" Project: survival rules "Steve McConnell, and learn余孟translation" software engineering: practitioner research methods "(5th edition) Roger S. Pressman of" software architecture in practice "SEI Software Engineering译丛,林巴斯book" RUP2000 "Electronics version;
"UML and System Design"张龙祥book;
"Object-Oriented Analysis and Design"杨正甫forward;
The author of this article E-mail: luls@dragonsoft.com.cn or lulsnet@21cn.com
This article is a summary of the design at the practice and study some of the experiences with the study notes, I hope to share with you if there is inappropriate please correct me.
Keyword:
Summary of design, structural, OOD
Body:
At the demand for clear and ready to start coding before the design to do a summary of the detailed design of most companies is not likely to do, also have to do most and coding are carried out simultaneously, or after the encoding. Therefore, most of the companies, a summary of the design document is the only design documents on the back of the development, testing, implementation, maintenance play a key impact.
First, the problem
Writing a summary of what design? Summary of how to do design?
How to determine the design of the module is complete?
Why do I say that too much emphasis on the design phase of business processes is a misunderstanding?
Demand analysis of the document or a summary of the development of design documents to assess the workload of the guidance development plan accurate?
Structured object-oriented good or good?
Answers to these questions, please look at the article.
Second, the outline is designed to
Software system needs to be converted to future systems design;
Gradually developed a strong system architecture;
Designed to enable the implementation of suitable environment for the design and improve performance;
Structure should be broken down into modules and libraries.
Third, a summary of the design mission
Norm-setting: the code system interface statute, naming rules. This is the project team of the foundation for future joint operations, with the development of norms and procedures and projects between modules of the interface between the members of the rules, ways and means, everyone will have a common working language, a common job So that the whole software development work can be coordinated and orderly manner.
The overall structure of the design:
Functions (processing) -> modules: each functional module implementation by those who ensure that every function has a corresponding implementation module;
Module-level structure: a certain point of view of the software framework;
Call the relationship between modules: Module interface between the general description;
Inter-module interface: the message and its structure;
Treatment design: meet the functionality and performance of the algorithm for user interface design;
Design:
Detailed data structure: tables, indexes, documents;
Algorithm related to the logical data structure and its operation;
Program modules to operate the above-mentioned note (in the foreground? In the background? Using view? ?······) With the process of
Interface Control Table data structure and use of other performance-based design rules.
Four, Designed to write a summary of what
Structured software design specification structure (due to space limitations and outdated suspects, and I shall not too much to explain)
Missions: objectives, environment, needs, limitations;
Design: deal flow, overall structure and modules, functions and modules of the relationship;
Interface Design: Overall description of external users, software and hardware interfaces; internal inter-module interface (Note: ≈ Interface System Interface)
Data structure: the logical structure, physical structure, the relationship between structure and procedures;
Modular design: each module, "What to do", a brief description of "how to do" (import, export, processing logic, and other modules interface with other systems or hardware interface), what kind of logic in the location, physical location;
Designed to run: Run modules, control, time;
Designed error: error information, the Agency deal with mistake;
Other design: confidentiality, maintenance;
OO software design specification structure
1 outlines
System briefly, software design objectives, reference materials, a revised version of Record on this part of the whole system design objectives, clearly indicate which function is to achieve and what the system decided not ready for implementation. At the same time, for non-functional requirements such as performance, availability and so on, also referred to. Requirements specification specification for this part of the content is very important to reference, take a look at one of clearly defined functional and non-functional requirements.
This part must be made clear picture of how to design, to ensure that readers will look after the implementation of the system to know what features and functions. In the subsequent part of the document will explain the design is how to achieve this.
Glossary 2
In this document used to explain various terms. If some terms in the specification of requirements specification has been explained, and do not have to repeat here, you can demand that the reader is referred to the guidelines.
3 Use Cases
System used here to request statements Use Case Diagram (UML), for each use case (normal deal with the situation) should be described in Chinese.
4 Designed brief overview of 4.1
This part of the requirements throughout the design to highlight the methods used (which is object-oriented design or structural design), system architecture (such as client / Structure) and the use of the corresponding technologies and tools (such as OMT, Rose)
4.2 Design
This part of the requirements to provide high-level system architecture (top-level system architecture, the subsystem structure) description, use the block diagram to show the main components and interactions among components. Logical structure of the best are put with the physical structure of the separation of the former description. Do not forget to note the figure goes and symbols used.
4.3 System Interface
Variety available to the user's interface and external systems to be described here. If the instructions in the requirements specification of the user interface has been described here do not have to repeat, you can demand that the reader is referred to the guidelines. If the system provides the interface to other systems, for example, from other software system import / export data, must draw a distinction here.
4.4 Constraints and assumptions
Describe the most important system design constraints, these are mandatory requirements by the client and instructions stated in the demand. Help system is how to adapt to these constraints.
In addition, if the system interact with other external systems or rely on other external systems to provide some auxiliary function, then the system may also be subject to other constraints. Under the circumstances, request a clear description and the system has the type of interactive software and this has led to the binding.
Implementation language and platform will have on the system constraints, at this same explanation.
For selection of specific design and implementation lead to system constraints, briefly describe your thinking mind, after the weigh how to, why should we adopt such a design and so on.
5 Object Model
Provided throughout the system object model, if the model is too large, in accordance with the feasible Put it into small pieces, for example, can put client and server-side object model diagram into two separate statements. At one of the system should include all objects. These objects are from understanding the needs of after. What should be clear, and which should not be included in the figure. The links between all objects must be identified and linked to the base must be specified. Aggregation and inheritance relationship must be clearly defined. Each map must be accompanied by a simple note.
6 Object Description
In this section describes the details of each object, its property, and its methods. Prior to that must be logically organized to object. You may need to put structure into a good object by subsystem.
To make an entry for each object. In the system object model briefly description of its use, constraints (such as only one example), listed its property and methods. If the object is Data at sustained container, indicating it is a persistent object, otherwise it is a temporary object (transient object).
For each object of a detailed description of each property: name, type, if the property is not very intuitive or have bound (for example, each object of the property must have a unique value or range is limited positive integer, etc.).
For each object of a detailed description of each method: The method name, return type, return values, parameters, and the use of the algorithm uses a brief description (if not particularly easy, then). If the return value of the variable or what if the assumption that, Pre-conditions and Post-conditions must draw a distinction here. Listed in it or it calls the method required to visit or modify the property. Finally, the implementation method can be verified to provide test cases.
7 Dynamic Model
This part of the role is to describe how the system response to various events. Generally used sequence diagram and state diagram.
Determine the different scenes (Scenario) is a first step, do not need to identify all possible scenarios, but must at least cover the typical system use cases. Do not go assuming the creation of scenes, the usual strategy is to describe the feelings of those clients can be scene.
7.1 scenario (Scenarios)
For each scene to do an entry, include the following:
Scene name: give it a name the words too literally described the scene: a brief description of the scenes are doing as well as the sequence of actions happen.
Sequence Diagram: Describes a variety of events and the relative case happened in chronological order.
7.2 State Diagram
This part of the system dynamic model includes the important part of the state diagram. Possible for each object you want to draw a state diagram, but in fact will lead to too many do not expect the details of information, the system only need to identify a number of important objects and to provide the state diagram can be.
Eight non-functional needs of five, a summary of how to do the structural design of software design methods:
A detailed requirements specification to read instructions, understand the system-building objectives, operational status quo, the existing system, customer demand for functional description;
Analysis of data flow diagram, identify the process of data stream processing;
Data flow diagram in accordance with the decision problem of the type of data processing (transform-type, transaction type, other type);
Through the above analysis, derived from the initial structure of the system;
The initial structure for improved: all the processing must be mapped to the corresponding module (module integrity demand that they completed all of the processing), to eliminate completely or in part similar to the duplication of similar functions (Wise Review with), sort out inter-module level, control the relationship, reduce the high fan-out structure, with increasing fan-depth, balanced module size.
From the data dictionary changes to complement derived logical data structure, data structure on each export operation, these operations should belong to a module.
What are the application of the system service system, client, database management systems;
On each module to determine which application server or the client which directory, which file (library), or the internal set up in the database object.
For each filter the list after the module description.
Logical data structure for a list of notes.
According to the structure of software design specification structure on the other issues that required additional information, forming a summary of the design specification.
OO Software Design Methods:
Designed on the basic OOA objects and categories: analysis of the problem areas (business modeling and requirements analysis), the beginning of the establishment of system architecture.
The first step is to set up the field taken from the concept model, shown in the UML for the establishment of object class diagram, activity diagram and interactive map. Object class from the object after a "review with" a certain group of objects to identify the common characteristics between the formation of categories:
Object with the type of attributes: data structure;
Object with the type of service operation: the operation of algorithm implementation;
Object with the type of implementation of various external link structure;
Design Strategy: full use of the existing categories;
Methods: inheritance, reuse, evolution;
Activity diagram is used to define work flow, the main stream of the job description 5W (Do What, Who Do, When Do, Where Do, Why Do) and so on, interactive map and put the business are linked in order to understand the interaction process and found that business Workflow mutual interaction of various roles.
The second step is to build a perfect system architecture: the system decomposition, large-scale system will be decomposed into a number of subsystems, subsystem decomposition for a number of software components and subsystems that between static and dynamic interfaces, each subsystem can be used Example model, analysis model, design model, test model. Software system structure in two ways: the level of block-level structure: systems, subsystems, modules, components (with a layer of independence between);
Block structure: the weak coupling between
System components:
On the problem domain: business-related classes and objects (OOA focus);
Man-machine interface: windows, menus, buttons, commands and so on;
Data management: data management methods, the logic of the physical structure, operation object class;
Task Manager: Task coordination and management process;
The third step is the use of "4 +1" view description of system architecture: use case view and scripts; Description Architecture Design view; as a module component kits and implementation layer contains a summary of the implementation model view; explain the process and thread and its architecture, distribution and relations of mutual interactive process view; Help system in the operating platform on the physical nodes and their distribution on the mission configuration view. There are at RUP optional data view.
The fourth step is to optimize the performance (speed, , Memory), the model of clarity, simplicity (that is easy to enjoy).
VI, a summary of the principles of design
General principles and methods: from coarse-to-fine principle, combine the principles of qualitative analysis and quantitative analysis of a combination of methods, decomposition and coordination methods and modeling methods.
To the system to consider the general system, relevance, integrity and level of sexual.
Decomposition and coordination: The aim is to in order to create a better system. System decomposition refers to a complex system is decomposed into several sub-systems, system coordination system to coordinate first, that the general structure of the system, with a total function, mission and overall objective of the total requirements of the various subsystems in co-ordination between in various sub-systems based on local optimization, the coordination of the balance through internal control, implementation of the overall system optimization;
Shielding abstract: a simple framework from the beginning, implied details;
Consistency: a unified specification, unified standard, unified document model;
Each module should have a unified naming names easy to understand;
Coding:由外向内(interface -> core);
User-oriented: a summary of the design for the buttons are pressed after the system "how to do" a brief description;
Modules, components, full independence, closed;
Taking into account the static structure and dynamic operation;
Each logical object which should indicate its physical object (non-one correspondence);
Every physical object has a suitable developer, and in favor of the division of labor and assembly. (Detailed description see my other article: System Factors should be considered);
Established in each of the overall structure of the framework view: view detailed organizational structure, elements of the grouping as well as the interface between the major groupings;
Software architecture with the use of the technology platform is closely related to the most commonly used platform has , , CORBA and so on, so a specific software architecture personnel should have the use of these platforms, software development experience;
Through the demand function and design of the corresponding list of modules, each of the demand function to check whether there are corresponding module implementation to ensure that the demand function of the demand for traceability and implementation (module) the integrity, at the same time can check the duplication and unnecessary module.
Research at the demand for analysis of business process know the integrity and accuracy is very important. Investigate and try to find out all the business processes in order to design a suitable business node of the flow characteristics and habits of business users of software to enable the development of the software more popular. Of course, in a summary of the design of software to business processes as far as possible the constraints, that is, put the business flow in the node job as an independent object, designed as an independent module, take full account of their various business objects with other interface modules in the flow through the business objects between the modules call each other achieve a variety of business, so that happened in the business process changes in a limited (one for each business of the business logic module itself has not changed circumstances), it more convenient to be able to modify system procedures for inter-module calls realize the relationship between the new demands. If this relationship is designed to call stored in the configuration in the database dictionary, then even do not need to modify code, just modify the data dictionary of the module can call the rules.
Seven, a summary of important design output
Encoding specification: the form of information, interface statute, naming rules;
Physical model: component diagram, deployment diagram;
The framework of different perspectives view: use case view, logical view, process view, deployment view, implementation view, Data View (optional);
The overall layout of the system: What components, on the various parts of the physical, on the relationship between logic;
The output of the two can not be ignored:
And demand function: For each of the demand function, with which a layer, which module, which category, which objects to achieve (one-to-many relationship); in turn, should indicate the system will have to create each layer, each modules, each object, each type of "what to do," they are in order to help achieve what function (one-to-many relations). (Demand for particle size at the beginning is often the one relatively thick, so in accordance with Function Point size of the overall project estimate or project WBS its error range is relatively large. More important reason is that demand is often not the coding job decomposition accurate basis, because the function of a demand point may correspond to multiple code modules, and multiple demands of the points may also correspond to only one or a small number of code modules, as well as software reuse and other factors to consider, so only a summary of design is completed before they can be accurately detailed design or coding stages of the second WBS, and estimate more accurately the size of the overall project.)
Logic and physical location: at the logic of each object on which rests a layer separately, which module, which type; in physics on each module, each object, each type on which application server or the client which directory, which Documents (library), or are set up in the database management system what Dongdong (procedures, functions, views, triggers and so on).
Eight, structure and characteristics of object-oriented method compared
1. Look from the concept, structure and function are a collection of software, through the module, as well as modules and module calls the relationship between the layered implementation; object-oriented software is a collection of things, through the object and the object and the object of the communication links between implementation;
2. Look from the composition, structure, software = process + data to process for the center; object-oriented software = (data + the corresponding operation) of the package and data-center;
3. From the operation of the control side, the structure of software to adopt the order of treatment modalities, from process-driven control; object-oriented software using interactive, parallel processing methods, by the message-driven control;
4. Look from the development, structured methods are focused on job design; object-oriented methods are the focus of job analysis; however, structured methods, the analysis phase and design phase does not correspond to the use of the expression, the need to used in the analysis phase of the network characteristics of data flow diagram is converted to the design stage with the use of layered structure characteristics, in object-oriented methods do not exist the problem.
5. From the application side, relatively speaking, more suitable methods of structured data type is relatively simple numerical computing and data management software development; object-oriented method more suitable for large complex man-machine interactive software and data management software development;
References:
"Practical "Second edition,郑人杰,殷人Queensland, TAO Lei waiting" Project: survival rules "Steve McConnell, and learn余孟translation" software engineering: practitioner research methods "(5th edition) Roger S. Pressman of" software architecture in practice "SEI Software Engineering译丛,林巴斯book" RUP2000 "Electronics version;
"UML and System Design"张龙祥book;
"Object-Oriented Analysis and Design"杨正甫forward;
The author of this article E-mail: luls@dragonsoft.com.cn or lulsnet@21cn.com