Principle of software module division

In software high-level design, how to break down modules is the primary consideration. Currently, the industry recognizes that modules should be divided according to the principle of "high cohesion and low coupling". How can we achieve "High Cohesion and low coupling? Next, we will explore the principles of module decomposition. If you have any questions, please let us know.

Is the module broken down by function?

Many people may have experience. In the face of a bunch of functional requirements, multiple different requirements may need to be put in the same module, and a certain requirement needs to be decomposed into multiple modules for implementation.

For example, a dictionary software (similar to Kingsoft's software) usually needs to query the dictionary function and add the user dictionary function. Obviously, it is impossible to simply break down one module for each of these two functions. The query interface and the processing part of the user dictionary are divided into one module, and the data management (query, add, and so on) part of the dictionary is divided into another module.

By analyzing the module division of the dictionary software, we can conclude that the module is not simply divided by function, therefore, splitting modules by function is not a feasible solution under any circumstances.

Modules are decomposed by professional fields

After carefully observing the module decomposition of the dictionary software mentioned above, we will find that the two modules are in different professional fields, one is the interactive field (graphic interface ), the other is Data Management (data structures and algorithms ). In this case, modules are divided by professional fields. Should all modules be divided by professional fields?

By observing the decomposition of a large number of software modules, we can find that most of the modules are broken down by professional fields. These specialized fields include various sub-fields in the public software field, the professional and sub-fields of the software processing business.

Common Sub-fields in the software public field include data structure algorithms, graphic interfaces, Io processing, network communication, databases, encryption, security, image processing, and mathematical algorithms, of course, these sub-fields can be further divided into smaller sub-fields.

The professional field of the software processing business refers to the specialized field of the specific business aspect. For example, the financial software business includes the financial professional field, CAD software business includes specialized areas in mechanical drawing.

The content in these different fields is divided into different modules, and no one will implement the network communication and data structure Algorithm functions in the same module at the same time. In this way, we can obtain a basic principle of module decomposition:

Basic Principle of module decomposition: two different professional fields cannot be implemented in the same module

The meaning of the above sentence is actually the same as that of the module in the professional field, but the meaning is clearer. Note that this is "Implementation". Many modules require interfaces in different professional fields for processing, that is, in the same module, APIs in different professional fields may be called for processing. The called interfaces are not implemented ".

Modules are broken down by specialized fields only by a principle and cannot prove its correctness. Therefore, let's see if it will conflict with some existing design features, for example, "High Cohesion, "low coupling", reusability, scalability, and other issues will conflict.

Inference 1: modules decomposed by specialized fields are "High Cohesion, low coupling"

Why do we say "high cohesion and low coupling" for modules decomposed by professional fields? The division of professionals is divided by people who have been through long-term practice and exploration. The professional field itself is "High Cohesion and low coupling". For example, the coupling between the data structure algorithm specialty and the network specialty is very small, however, each major is highly cohesive internally.

Inference 2: modules decomposed by specialized fields are reusable.

This is easy to understand. After the modules are divided by professional fields, it is clear that no two different modules have repeated content, so they can meet reusable features.

Inference 3: modules decomposed by specialized fields are scalable

When there is a new demand, as long as the new demand is divided into the content of various professional fields, the new content can be divided into three types:

1. Corresponding implementations are available in existing modules,

2. belongs to the field of existing modules, but there is no corresponding implementation

3. Not in the field of existing modules

In 1st cases, you obviously do not need to modify or add existing modules. For 2nd cases, you need to add corresponding interfaces to existing modules to implement the corresponding content; for the 3rd types, a new module is required to implement the corresponding content.

All three cases are in line with the scalability feature in software design, so modules decomposed by specialized fields are scalable.

Conclusion 4: modules decomposed by professional fields are maintainable.

This can be derived from the features of high module cohesion, low coupling, and scalability.

From this we can see that the basic principle of module decomposition is consistent with the previous design requirements, but will there be any counterexamples? I am not sure, because this principle cannot be proved. If someone finds that the module should not be decomposed according to the professional field, please reply.

Difficulties in Decomposing modules in specialized fields

Although it seems perfect to break down modules in specialized fields, most of the requirements can be broken down according to this principle. But it does not mean that there is no problem. In fact, the prerequisite for decomposing by major is to break down the requirements into existing professional fields.

Difficulty 1: If the demand content is in the emerging and unformed professional fields, it is not that easy to break down by major.

Difficulty 2, at this time, Division of modules is not an easy task.

Principle of software module division