Overall Design of Software Engineering

After the work in the demand analysis stage, the system must do something clearly, and the overall design stage is the time to decide how to do it.

The basic purpose of the overall design:

Is to answer "In summary, how should the system be implemented ?" This problem. This phase mainly includes:

1. Divide the physical elements that constitute the system-programs, files, databases, human processes, and documents.

2. design the system structure, that is, determine which modules are composed of each program in the system and the relationship between these modules.
Steps for the overall design phase:
1. Find various solutions for implementing the system, and follow the data flow chart obtained in the requirement analysis phase.
2. The analyst selects several reasonable schemes from these alternative schemes for analysis, prepares a system flowchart for each scheme, and lists all the physical elements of the system, cost/benefit analysis and plan the progress of the solution.
3. The analyst comprehensively analyzes and compares these reasonable solutions and selects an optimal solution to recommend to users and department heads.
4. Optimize and improve the final solution to obtain a more reasonable structure, design necessary databases, determine test requirements, and develop test plans.
From the above description, it is not difficult to see that the necessity of implementing the overall design before the detailed design is: you can stand at the height of the global architecture and spend less on costs, analyzes and compares various possible implementation solutions and software structures at an abstract level, selects the best solution and the most reasonable software structure, and develops high-quality software systems at a lower cost.
Principles required for the overall design:
1. Modular
Module definition: a module is a sequence of adjacent program elements restricted by boundary elements. A module is a basic component of a program.
The theoretical basis of modularization: it is easy to resolve complicated problems into many small problems that are easy to solve.
Modular advantages:
(1) to make the software structure clear, not only easy to design but also easy to read and understand.
(2) Easy testing and debugging, improving software reliability.
(3) Improve Software maintainability.
(4) facilitates the organization and management of software development projects.
2. Abstraction
Abstract definition: abstract is one of the most powerful thinking tools in the process of recognizing complex phenomena. In practice, people realize that there are some similarities (commonalities) between certain things, states, and processes in the real world ). These similar aspects are centralized and summarized, and the differences between them are temporarily ignored. This is abstract. Or abstraction is to consider the characteristics of things that are concerned with each other without considering other details.
Abstract Theoretical Basis: Due to the limitation of human thinking ability, it is impossible to make accurate thinking if there are too many factors each time. The only effective way to process a complex system is to construct and analyze it in a hierarchical manner. Each step of software engineering is a refined abstraction layer of software solutions.
3. gradually improve
Definition of progressive refinement: progressive refinement is the basic usage of humans in solving complex problems and also the basis of many software engineering technologies. Gradually improving can be understood as: "to focus on solving the main problems, we should try to postpone the consideration of the problem details ".
The theoretical basis for progressive refinement: The Miller law enables one to focus only on five to nine pieces of knowledge at any time.
The benefit of progressive refinement: it helps software engineers focus on the most relevant aspects of the current development phase, while ignoring those that are necessary for the overall solution, however, no details are required, which will be considered later. The miller law is the basic limitation of human intelligence. We cannot defeat our own nature. We can only accept this fact, acknowledge our limitations, and make our best effort on this premise.
4. Information Hiding and Localization
The principle of information hiding means that the module should be designed in this way so that the information contained in a module is inaccessible to modules that do not need the information.
The concept of localization is closely related to the concept of information hiding. The so-called localization refers to physically putting software elements that are closely related to each other.
If you need to modify the software during testing and later software maintenance, the principle of information hiding will bring great benefits as a standard for modular system design. It will not spread the impact to other modules.
5. independent modules
The concept of module independence is the direct result of modularization, abstraction, information hiding, and localization. There are two obvious advantages of module independence: First, effective modular software is easier to develop and is suitable for division of labor development by teams. Second, independent modules are easier to test and maintain.
The degree of independence of a module can be measured by two qualitative standards: cohesion and coupling. Coupling refers to the degree of mutual dependency between different modules, and cohesion refers to the degree of mutual integration of various elements in the module.
In software design, we should pursue systems that are as loose as possible. In such a system, you can study, test, and maintain any module without having to know much about other modules of the system. The Coupling Degree between modules strongly affects the comprehensibility, testability, reliability and maintainability of the system.
Coupling classification:
(1) Data coupling. If two modules exchange information through parameters and only data is exchanged, this coupling means data coupling.
(2) control coupling. If two modules exchange information through parameters and the information exchanged has control information, this coupling is control coupling.
(3) feature coupling. If the called module needs to transmit all data in the data structure passed in as a parameter, it is completely correct to transmit the data structure as a parameter. However, feature coupling occurs when the entire data structure is passed as a parameter and a part of the data elements are used. In this case, the called module can use more data than it actually needs, which will lead to the loss of control over data access and thus provide opportunities for computers to make mistakes.
(4) Public environment Coupling. When two or more modules interact through the public data environment, the coupling between them is called public environment coupling.
(5) content coupling occurs in either of the following scenarios:
* One module accesses the internal data of another module
* A module is not transferred to another module through the normal portal.
* A module has multiple portals.
When designing software structures, we should adopt the following design principles: Data coupling should be used whenever possible, control coupling and feature coupling should be used less, the scope of public environment Coupling should be limited, and internal coupling should not be used at all.
Classification of cohesion:
Low cohesion
(1) Accidental cohesion: If a module completes a group of tasks, the relationship between these tasks is loose even if they are related to each other. This is called accidental cohesion.
(2) logical cohesion: If a module completes a task in the same or similar logic, it is called logical cohesion.
(3) Time cohesion: If a module contains a task that must be executed within the same period of time, it is called time cohesion.
Cohesion
(4) process cohesion: If the processing elements in a module are related and must be executed in a specific order, it is called process cohesion.
(5) communication cohesion: If all elements in the module use the same input data and generate an output data, it becomes a communication cohesion.
High Cohesion
(6) sequential cohesion: If the processing elements in a module are closely related to the same function and these processes must be executed sequentially, they are called sequential cohesion.
(7) function cohesion: if all the processing elements in the module belong to one whole and a single function is completed, it is called function cohesion.
In fact, there is no need to precisely define the module cohesion level. It is important to strive for high cohesion during design and identify low cohesion modules. It is capable of improving the degree of cohesion of modules by modifying the design to reduce coupling between modules, in this way, high module independence is achieved.
Heuristic rules for Software Architecture Design:
1. Improve the software structure and improve the module independence.
2. The module scale should be moderate.
3. The depth, width, fan-out, and fan-in should be appropriate.
Depth indicates the number of layers controlled in the software structure, which can roughly mark the size and complexity of a system.
The width is the maximum number of modules at the same level of the software structure. Generally, the larger the width, the more complicated the system is.
Fan-out refers to the number of modules directly called by a module. Experience shows that the average fan-out of a well-designed typical system is usually 3 or 4, which is not good if there are too many or too few.
Fan-In refers to the number of other modules that directly call a module. The larger the fan entry, the better.
4. The module scope should be within the control domain.
5. strive to reduce the complexity of the Module Interface
6. Design a single portal and Single Exit Module
7. The module functions should be predictable
If a module can be regarded as a black box, that is, the same output can be generated as long as the same data is input, and the function of this module is predictable. The functionality of a module with an internal "Memory" may be unpredictable because its output depends on the status of the internal memory. Because internal memory is invisible to upper-level modules, such modules are hard to understand and difficult to test and maintain.
The above heuristic rules are mostly empirical rules, which often have important reference values for improving design and improving software quality. However, they are neither designed goals nor principles that should be followed in design.
Design Optimization:
1. When considering Design Optimization Problems, remember that "the value of an 'optimal design that cannot work is questionable ".
2. The software structure should be refined as much as possible in the early stages of design. Different software structures can be exported and then evaluated and compared to achieve the "best" results. This optimization may be one of the true advantages of separating the software structure design from the process design.
3. the structure is simple, which usually indicates that the design style is elegant and the efficiency is high. The design optimization should strive to use the smallest number of modules while effectively modularized, and use the simplest data structure while meeting the information requirements.
4. Follow the motto: "First enable it to work, then make it faster ."