Overview Summary of the design of how to do that - the design of structured methods and object-oriented design methods

Posted on 2009-07-02 filed under: Development (RSS) 48 views

Overview Summary of the design of how to do that - the design of structured methods and object-oriented design methods

At 23:52 on February 12, 2008

Overview Summary of the design of how to do that - the design of structured methods and object-oriented design methods

Abstract:
This article is a summary of the design in practice and learn from some of the experiences and learning notes, I hope to share with you if there is inappropriate please correct me.
Keyword:
Summary of the design, structure, ood
Body:
In the demand for clear and ready to start coding before the design outline done, and the detailed design of the majority of companies do not do may have to do the majority and coding the same time, or after the encoding. Therefore, most of the company, a summary of the design of the design document is the only document on the back of the development, testing, implementation, maintenance play a crucial impact.
First, the problem <br /> write a summary of what design? How to do a summary of the 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?
Document or a needs analysis in order to outline the development of design documents to assess the workload of the development plan to guide accurate?
Structured object-oriented good or good?
Answers to these questions please find in the article.
Second, the purpose of a summary of the design of software systems <br /> demand will be converted to the design of future systems;
The gradual development of a strong system architecture;
Design suitable for the implementation of the environment, to improve the performance and design;
Structure should be broken down into modules and libraries.
Third, a summary of the design task <br /> norm: the code system interface of the Statute, the rules of naming. This is a project team basis for future joint operations, with the development of norms and procedures and project modules of the interface between the members of the rules, ways and means, we will have a common working language, a common working platform so that the whole software development work can be carried out in an orderly manner.
The overall structure of the design:
Functions (processing) -> modules: each functional module with those who ensure that every function has a corresponding module to achieve;
Module-level structure: a certain point of view of the software framework;
Call the relationship between modules: the interface between modules of a general description;
Interface between modules: the message and its structure;
Design approach: to meet the functionality and performance of the algorithm for user interface design;
Data structure design:
Detailed data structure: tables, indexes, documents;
Algorithm related to the logical data structure and its operation;
The above description the operation of program modules (in the foreground? In the background? With the View? ?······) With the process of
Interface Control Table data structure and use of other performance-based design rules.
Fourth, write a summary of what design <br /> structured software design specification structure (due to space limitations and outdated suspect, will not be too much to explain)
Tasks: the goal, the environment, needs, limitations;
Design: process, the overall structure and modules, the relationship between functions and modules;
Interface design: general description of external users, hardware and software interface; 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", a brief description of "how to do" (import, export, processing logic, the interface with other modules, and other system or hardware interface), what kind of logic in the location, physical location;
Run Design: modules to run, control, time;
Design error: error message, is wrong to deal with;
Other design: confidentiality, maintenance;
oo software design specification structure
A brief overview of the system, software design objectives, reference materials, a revised version of record on this part of the whole system design objectives, clearly indicate which function is the system to achieve and what the decision is not ready to achieve. At the same time, for non-functional requirements such as performance, availability and so on, also referred to. Specification requirements for the contents of this part is very important for the reference to see which defined the functional and non-functional requirements.
This part of the design must be made clear picture of how to ensure that readers will realize after the system know what features and functions. Part in the subsequent documents will be designed to explain how to achieve this.
Table 2 of this document the term used to explain the various terms. If the number of terms in the specification requirements have been explained, and do not have to repeat here, you can demand that the reader is referred to the guidelines.
3 requirements of system use case here with statements Use Case Diagram (uml), for each use case (the normal situation) should be described in English.
4 Design Overview
4.1 on
Requirements of this part of the whole design to highlight the methods used (which is object-oriented design or structural design), system architecture (such as client / server architecture), as well as the use of the corresponding technologies and tools (for example, omt, rose)
4.2 system requirements of this part of the structural design of system architecture to provide high-level (top-level system architecture, the subsystem structure) description, use the block diagram to show the major components and the interaction between components. The best is the logical structure of the separation with the physical structure of the former description. Do not forget that the figure goes and symbols used.
4.3 system to the user interface to provide a variety of interfaces and external systems to be described here. If the specification requirements 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, software systems from other import / export data, must draw a distinction here.
4.4 describes the system constraints and the assumption that the most important design constraint, which is mandatory for customers and the demand for manual stated. Help system is how to adapt to these constraints.
In addition, if the system interact with other external systems or other external systems rely on a number of auxiliary functions, then the system may also be bound by the other. Under the circumstances, the requirements clearly describes the interaction with the system software and this has led to the type of binding.
The realization of the language and platform will be binding on the system, the same explanation here.
For the specific design choices to achieve a result of constraints on the system, a brief description of your idea of thinking through how to trade-off, why should we adopt such a design and so on.
5 Object Model to provide the object model the entire system, if the model is too large, in accordance with the standards feasible it into small pieces, for example, the client and server-side object model diagram into two separate statements. In which all systems should include the object. These objects are obtained from the understanding of the needs. What should be clear, 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 plan must be accompanied by a simple note.
6 objects described in this section describes the details of each object, its attributes, its methods. Before in this object from the logical organization. You may need to structure the object divided by sub-system well.
Be a target for each entry. Object model in the system a brief description of its use, constraints (for example, there can be only one example), are listed in its properties and methods. If the object is persistent data stored in the container, indicating it is a persistent object, otherwise it is a temporary object (transient object).
Each object of a detailed description of each attribute: name, type, if the property is not very intuitive or constraint (for example, the attributes of each object must have a unique value or range is limited positive integer, etc.).
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 especially simple). 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 call the method it needs to access or modify the properties. Finally, the method can be verified to provide the test cases.
7 This part of the dynamic model describes how the system is to respond to events. The general use of Sequence Diagrams and Statechart.
Determine the different scenes (scenario) is the first step, do not need to identify all possible scenarios, but must at least cover the typical use case of the system. Do not take it for granted to create their own scenes, the usual strategy is to describe the feelings of those customers can be scene.
7.1 scenario (scenarios)
For each scene to do an entry, include the following:
Scene Name: give it a name of the words too literally described the scene: a brief description of the scene is doing as well as the order of the action took place.
Sequence diagram: describes the various incidents and events in chronological order relative.
7.2 The state diagram of the contents of this part of the system dynamic model of an important part of the state diagram. Possible for each object you want to draw a state diagram, but in fact will lead to the details do not expect too much information, the system only need to identify the target of a number of important and can provide state diagram.
8 non-functional requirements

V. Summary of the design of how to do

Structured software design methods:
Read the needs of a detailed specification, understanding the target system, operational status, the existing system, the function of customer demand note;
Analysis of data flow diagram, identify the process of data stream processing;
Data flow diagram in accordance with the decision to deal with the problem of data types (transform-type, transaction type, other type);
Through the above analysis, derived from the initial structure of the system;
Carried out the initial structure refinement: All processing must be mapped to the corresponding module (module integrity demand that they completed all of the processing), similar to the elimination of complete or partial duplication of similar functions (Wise Review with), sort out inter-module level, the relationship between control and reduce the high fan-out structure, with increasing fan-depth, balanced module size.
By the changes to the data dictionary to add sound, logical data structure of export, export the data structure of each operation, these operations should be part of a module.
What are the application of the system service, client, database management systems;
On each module to determine which application server or the client which directory, which file (library), or the establishment of the target database.
For each filter module list after that.
Logical structure of data in tabulated form.
According to the structure of software design specification to describe the structure of the other issues added to form a summary of the design specification.

oo software design methods:

Ooa basis in the design of 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 taken to establish the field of conceptual model, shown in the uml class diagram for the establishment of the object, activity maps and interactive map. Object class from the object after a "review with" a group to identify common features between the object and the formation of categories:
The properties of objects and categories: data structure;
Object with the type of service operation: to operate the realization algorithm;
Various types of objects and the realization of the structure of external links;
Design Strategy: full use of the existing categories;
Methods: inheritance, reuse, evolution;
Activity diagram is used to define work flow, the main stream of work 5w (do what, who do, when do, where do, why do) and so on, interactive map to link staff and business interaction in order to understand the process and found that business Workflow interact with each other in a variety of roles.
The second step is to build a perfect system: decomposition of the system will be large-scale system is decomposed into a number of subsystems, sub-system is decomposed into a number of software components, as well as between sub-system static and dynamic interfaces, each subsystem can use case model, analysis model, design model, test model. The structure of software systems 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:
The problem domain: business-related classes and objects (ooa focus);
Man-machine interface: windows, menus, buttons, commands, etc.;
Data management: data management methods, the logic of the physical structure and operation of 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 the script; that the design of architecture view; the form of a module package and the realization of the model layer that contains a summary of the achievement of view; that process and the thread and its structure, the distribution of interaction and mutual relations between the process view; that platform in the operation of the physical nodes and their distribution of tasks on the configuration view. Rup also optional in the data view.
The fourth step is to optimize the performance (speed, resources, and memory), the model of clarity, simplicity (simple is to enjoy).

VI, a summary of the principles of design

General principles and methods: from the principle of coarse-to-fine, combine the principles of qualitative analysis and quantitative analysis methods, decomposition and coordination methods and modeling methods.
System to consider the general system, relevance, integrity and the level.
Decomposition and coordination: The aim is to create a better system. System decomposition refers to a complex system is decomposed into several sub-systems, the system co-ordination system to coordinate first, that is, the total structure of the system, with a total function, the overall goal of the overall mission and the requirements of the various sub-systems in co-ordination between in various sub-systems based on local optimization, through the coordination of the internal balance control, to achieve the overall system optimization;
Shielding abstract: a simple framework from the beginning, the implied details;
Consistency: a unified specification, unified standard, unified document model;
Each module should have a uniform naming names easy to understand;
Coding:由外向内(interface -> core);
User-oriented: a summary of the design is the system by pressing the button for "how to do" for the request;
Module, the full independence of components, closed;
Taking into account the structure of static and dynamic operation;
Each logical object which should be its physical object (non-one-to-one);
Every physical object developers have the right, and in favor of the division of labor and assembly. (Detailed description see my other article: system architecture design factors should be considered);
Established for each view the overall structure of the framework: a detailed view of the organizational structure of the sub-elements as well as the interface between the major groupings;
With the use of software architecture is closely related to the technology platform, the platform is currently used j2ee,. Net, corba and so 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 needs to check whether there are corresponding functional modules to achieve to ensure that the demand function of the demand for traceability and achieve the (module) integrity, as well as duplication and unnecessary check module.
Research analysis on the demand for business process integrity and accuracy of understanding is very important. Investigation and try to find out all the business processes in order to design a business node for the flow characteristics and habits of business users of software to enable the development of more popular the software. Course outline during the software design business processes as far as possible to the constraint that the flow of the business working as an independent node of the object, designed as an independent module, take full account of their business objects and other types of interface modules in the flow between the modules through the business object to call each other to achieve a variety of business, so that in the business process changes occurred in a limited (one for each business of the business logic module itself has not changed circumstances), will be able to modify the system more convenient procedure calls between modules and the realization of 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 be called rules.

7, a summary of the important design output

Coding norms: Information form interface statute, naming rules;
Physical model: component diagram, deployment diagram;
Different angles of view framework: use case view, logical view, process view, deployment view, implementation view, Data View (optional);
The overall layout of the system: What are the parts, all parts of the physical, the logical relationship between;
The output of the two can not be ignored:
Function and demand: the demand for each function, with which one, which module, which category, which targets to achieve (one-to-many relationship); in turn, should indicate the system will be created at every level, every modules, each object, each type of "what", they are in order to help achieve what function (one-to-many relationship). (Particle size needs are often at the beginning is relatively coarse, and therefore under the functional point of the scale of the overall project estimate or scope of the project wbs error is relatively large. More important reason is that demand is often not the work of decomposition coding accurate basis for a demand function may correspond to a number of code modules, and features a number of demand points may correspond to only one or a small number of code modules, as well as software reuse and other factors to consider, only the outline design is completed to be accurate after the detailed design or coding phase of the Second wbs, and more accurate estimates of the size of the overall project.)
Logic and physical location: each object in the logical layer, respectively, which falls on which modules, which type; in physics on each module, each object on which each type of application server or the client which directory, which Documents (library), or is built on the database management system, what Dongdong (procedures, functions, views, triggers, etc.).

8, structure and characteristics of object-oriented method compared

1. From the concept, the structure of software is a collection of functions, through the module and between modules and module called hierarchical relations; object-oriented software is a collection of things, through the object and the object and the object of the communication links between achieved;
2. From the composition, the structure of software = process + data to process for the center; object-oriented software = (data + the corresponding operation) of the package, data-center;
3. From the operation of the control side, the structure of the order of the software approach used by the process-driven control; the use of an interactive object-oriented software, parallel processing methods, by the message-driven control;
4. From the development perspective, a structured approach is the design focus of the work; object-oriented method of analysis of the focus of the work; 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 the data flow diagram into a design phase with the use of hierarchical structure of characteristics in object-oriented approach to this problem does not exist.
5. From the application side, relatively speaking, a structured method of data types more suitable for relatively simple numerical calculation and data management software development; more suitable for object-oriented method of large and complex human-machine interactive software and data management software development;