[Software Engineering General Review] Chapter 5 Overall Design (Concept, Principle)

(Fill in the blank) The overall design process usually consists of two main stages, the system design stage, to determine the specific implementation plan of the system; the structure design stage, to determine the software structure. A typical overall design process includes 9 steps: imagine alternative solutions, select reasonable solutions, recommend the best solution, functional decomposition, design software structure, design database, specify test plan

1. Software design steps (fill in the blank)

From the perspective of engineering management, software design is completed in two steps; two stages of overall design (outline design) and detailed design.

2. Tasks in the software design phase (fill in the blanks)

1. Divide modules and determine software structure
Different development methods lead to different methods of determining software structure. For example, the SD method is to derive the initial structure diagram from the layered DFD diagram, and then improve the initial structure diagram to obtain the final structure diagram.
It generally includes determining the software structure of the system, decomposing modules, and determining the hierarchical relationship between the modules of the system.
2. Determine the data structure of the system
The establishment of the data structure is particularly important for the information system. It is necessary to determine the type, organization, access method, degree of relevance and processing method of the data.
3. Determine the algorithm inside the module
4. Design the user interface
As the human-machine interface, the user interface plays an increasingly important role, and it directly affects the life of the software.

3. Software design process (fill in the blank)

1. Conceive alternative solutions
2. Select reasonable solutions
3. Recommend the best solution
4. Functional decomposition 5.
Design software structure 6.
Design database
7. Develop test plan
8. Write documents
9. Review and review

3. What is modularization (noun explanation) (reduce system complexity)

A module is a sequence of adjacent program elements defined by boundary elements.
Modularization is to divide the program into independently named and independently accessible modules. Each module completes a sub-function. These modules are integrated to form a whole, which can complete the specified The functions meet the needs of users.

3.1 The purpose of modularization - the system

3.2 Benefits of Modularization - Improving Development Efficiency

4. Abstraction

The most powerful thinking tool humans use in the process of understanding complex phenomena is abstraction. People have realized in practice that there are always some aspects of similarity (commonness) between certain things, states or processes in the real world. To concentrate and generalize these similar aspects and temporarily ignore the differences between them is abstraction.

5. Step by step refinement

Step by step refinement is the basic method adopted by human beings to solve complex problems, and it is also the basis of many software engineering techniques.

6. Information concealment and localization——enhance cohesion and independence

Information hiding points out that modules should be designed and determined so that the information contained in a module cannot be accessed by modules that do not need the information.

Localization refers to placing closely related software elements physically close to each other.

7. How to measure module independence (noun explanation)

Strong independence, high cohesion and low coupling
Module independence means that each module in the software system only involves specific sub-functions required by the software. Module independence means that each module only completes the independent sub-functions required by the system, and has the least connection with other modules and the simplest interface. The criteria for measuring module independence are coupling and cohesion. (low coupling high cohesion)

7.1 Coupling

7.1.1 Concept

Coupling is a measure of the degree of interconnection between different modules in a software structure (coupling refers to the degree to which modules are connected to each other in a software structure, and is a measure of the interconnectivity between modules.)

7.1.2 Type

1. Content: The content of the two parts overlaps/shares, and one module directly accesses the internal data of the other module.
   A module does not pass through the normal entrance to the interior of another module.
   A module has multiple entries.
   The two modules have some code overlap.
2. Common: If a group of modules all access the same common data environment
3. Features: The entire data structure is passed as a parameter, and the called module only needs a part of the data elements.
4. Control: If a module passes information such as switches, logos, names, etc., it can clearly control the selection of the function of another module.
5. Data: If information is passed between two modules through parameters, the information is limited to data parameters rather than control parameters.
6. Indirect: If there is no direct relationship between modules, they can work independently without relying on each other.
   Coupling
   High to Low

7.2 Cohesion

7.2.1 Concept

Cohesion marks how tightly each element in a module is combined with each other (cohesion indicates the degree of connection between various data and various processes within a module, and it measures the connection between modules from a functional point of view.)

7.2.2 Type

1. Casual: There is no connection between the parts within the module.

2. Logic: This module combines several related functions together, and it is determined which function should be executed by the judgment parameters of the transmission module.

3. Time: Tasks within a module must be completed within the same time (such as initializing the module).
   low cohesion

4. Process: The parts of a module are related to each other and must be executed in a specific order.

5. Communication: components within a module operate on the same area of ​​the data structure
   Intermediate cohesion

6. Sequence: Each processing component in a module is related to a specific function, and each processing component must be executed sequentially.

7. Function: Each component in a module is an essential part to complete a specific function.
   advanced cohesion

Cohesion
from weak to strong

8. Heuristic rules (comprehension) (true or false)

The more modules the better (False)
The fewer modules the better (False)
The right size (True)
Reduce the complexity of the module interface and help improve module independence (True)
The scope should be within the control domain (True)

1. Each component in a module is an essential part to complete a specific function
2. Depth, width, fan-in and fan-out should all be appropriate
3. Strive to reduce the complexity of the module interface
4. Module size should be moderate
5. The scope of the module should be within the control domain
6. Design a module with one entry and one exit
7. Module functionality should be predictable

9. Software Structure Diagram SC

9. Transformation analysis (understanding) (not much test)

10. Analysis (understanding) of things (not much test)