Cohesion and Coupling Relationships

Coupling can be divided into the following categories, and the coupling degree between them is arranged as follows:
(1) Content coupling: When one module directly accesses the content of another module, the two modules are called content coupling.
If one of the following situations occurs in the program, it means that content coupling occurs between the two modules:
1. One module directly accesses the internal data of another module.
2. A module is directly transferred to the inside of another module without going through the normal entry.
3. The two modules have a part of code overlapping (this part of the code has a certain independent function).
4. A module has multiple entries.
Content coupling can occur in assembly language. Most high-level languages ​​have been designed to disallow content coupling. This coupling has the strongest coupling and the weakest module independence.
(2) Public coupling: A group of modules all access the same global data structure, which is called public coupling. The common data environment can be a global data structure, a shared communication area, a common footprint of memory, and the like. If the module only inputs data to the public data environment, or only retrieves data from the public data environment, this is a relatively loose public coupling; if the module both inputs data to the public data environment and retrieves data from the public data environment, this is a relatively tight public coupling.
Common coupling causes the following problems:
1. It is impossible to control the access of each module to the public data, which seriously affects the reliability and adaptability of the software module.
2. Make the maintainability of the software worse. If a module modifies public data, it will affect related modules.
3. Reduce the understandability of the software. It is not easy to know which data is shared by which modules, and it is difficult to troubleshoot.
In general, public coupling is only used when there is a lot of data shared between modules and it is inconvenient to pass parameters.
(3) External coupling: When a group of modules all access the same global simple variable and do not pass the information of the global variable through the parameter table, it is called external coupling.
(4) Control coupling: The transmission between modules is not data information, but control information such as signs, switches, etc. One module controls the function of another module.
(5) Mark coupling: transfer data structure instead of simple data between the calling module and the called module, also known as feature coupling. It is not simple variables that are passed between the modules of the table, but data results such as data names, record names, and file names in high-level languages. These names are tags, and in fact, addresses are passed.
(6) Data coupling: Only simple data item parameters are passed between the calling module and the called module. Equivalent to pass-by-value in high-level languages.
(7) Indirect coupling: There is no direct relationship between the two modules, and the connection between them is completely realized through the control and invocation of the main module. The coupling degree is the weakest, and the module independence is the strongest.
Summary: Coupling is an important factor that affects software complexity and design quality. In order to improve the independence of modules, a system that is as loose as possible between modules should be established. In the design, we should adopt the following principles: if there must be coupling between modules, it should be Try to use data coupling, use less control coupling, use public coupling with caution or control, limit the scope of public coupling, and try to avoid content coupling.
There are the following types of cohesion, and the degree of cohesion between them is ranked from weak to strong as follows:
(1) Accidental cohesion: There is no connection between the processing elements in a module, but they are just accidentally put together. This type of module, also known as coincidental cohesion, is the least cohesive.
(2) Logical cohesion: This kind of module combines several related functions, and each time it is called, the parameters passed to the module determine which function the module should complete.
(3) Time aggregation: A module formed by combining actions that need to be executed at the same time is called a time aggregation module. 
(4) Process cohesion: Components or operations are combined in such a way that after calling the previous component or operation, the latter component or operation is called immediately, even if no data is passed between the two. Simply put, it is called procedural cohesion if the processing elements within a module are related and must be executed in a specific order.
(5) Communication cohesion: It means that all processing elements in the module operate on the same data structure or all processing functions are associated through common data (sometimes called information cohesion). That is, each component in the module uses the same data or generates the same data structure.
(6) Sequential cohesion: each processing element in a module is closely related to the same function, and these processing must be executed sequentially, usually the output of the previous processing element is the input of the latter processing element.
For example, a module completes the function of evaluating the industrial output value. The former functional element calculates the total output value, and the latter functional element calculates the average output value. Obviously, the two parts in this module are closely related.
The cohesion of sequential cohesion is relatively high, but the disadvantage is that it is not as easy to maintain as functional cohesion.
(7) Functional cohesion: All the components of all elements in the module exist to complete the same function, and together complete a single function, the module can no longer be divided. That is to say, the module only includes all the components necessary to complete a certain function, and these components are closely related and indispensable.
Functional cohesion is the strongest cohesion and has the advantage of being functionally explicit. To judge whether a module is functionally cohesive, it can generally be seen from the module name. If the module name has only one verb and a specific goal (singular noun), it is generally functional cohesion, such as: "calculate water bills", "calculate output value" and other modules. Functional cohesion generally occurs at the lower levels of the software structure diagram.
An important feature of the functional cohesion module is that it is a "dark box". For the caller of the module, he only needs to know what the module can do, not how the module does it.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326181054&siteId=291194637