This is the 13th article on the System Design and Software Architecture series. In this article, we are discussing the Software Component Cohesion.

Previous articles

Contents hide
1 Previous articles
2 What is a Software Component Cohesion?
3 Reuse / Release Equality Principle (REP)
4 The Common Reuse Principle (CRP)
5 The Common Closure Principle (CCP)
6 Types of Component Cohesion:
7 Conclusion

What is a Software Component Cohesion?

Principles of component cohesion help developers to determine how to divide the class into components. These principles depend on the fact that at least some classes and their interrelationships have been found. Thus, these principles take a downward view of partitioning.

Reuse / Release Equality Principle (REP)

REP states that reusable granules, a component that is not smaller than release granules. Anything we reuse should need to release and pursued. It is unrealistic for a developer to simply write a class and say it is reusable. It can only use again after a tracking system has been activated and re-users have been notified, protected, and supported.

REP gives us the first hint on how to divide our design into components. Since reusability should need component-based, reusable components should include reusable classes. Therefore, at least some components must consist of reusable class kits.

While it may seem unsettling that a political force will affect the partitioning of our software, the software is not a mathematically clean entity that has the ability to structure according to mathematically clean rules. Software is a human product that supports human endeavors. Software is created by humans and used by humans. If the software is needed to reuse, it must need to be partitioned to make it easier for people to use.

Furthermore, it is not simply a criterion for reuse; we also need to consider who is reusing it. Of course, a container class library is reusable and it is also a financial framework. But we do not want them to become part of the same component. Because of many people who want to reuse a container class library are not interested in a financial framework. Thus, all classes in a component must be reused by the same audience. One component consists of the required classes and we do not want the viewer to find that the others are completely inappropriate.

The Common Reuse Principle (CRP)

This principle helps us to decide which class component to put. CRP says classes that tend to become reusable belong to the same component.

Class isolation is rarely re-used. In general, reusable classes collaborate with other classes that are part of the reusable abstract. CRP It is said that these classes belong to the same component. In such a component, we expect to see classes with a lot of interdependence. A simple example is a container class and its associated emulator. Because these classes are tightly reconnected, they are reusable. Thus, they must need the same component.

But the CRP simply tells us which classes should need to add to a component. It also tells us which classes should not include in the component. When one component uses another component, a dependency is created between the components. The component is the use of only one class within the used component. However, it does not weaken dependence. The component used still depends on the component used. Each time a used component is released; the used component must need to re-validated and reissued. This is true even if the used component is released due to class differences. That does not consider the component used.

CRP We are not told about classes that should need to together. CRP Says that classes that are not closely related to each other should not need to in the same component.

The Common Closure Principle (CCP)

This is the single responsibility principle that has been redesigned for components. Just as the SRP states that a class change should not contain different reasons. Also, the CCP states that there should not need to different reasons for a component change.

In many applications, maintaining reusability is more important. If an application code needs to change, you may want to make changes to one component rather than distributing it across multiple components. If the changes are focused on a single component, we only need one modified component. Other components that are not dependent on the modified component do not need to re-validated or replaced.

The CCP urges us to bring together all the classes that may change for the same reasons. If two classes are physically or conceptually closely related, if they are always different together, they belong to the same component. This minimizes the role of software release, validation, and redistribution.

This principle is closely related to the open/closed principle (OCP). This is because the word that deals with this principle are “shutting down” in the OCP sense. Classes should need to close for modernization but long. OCP says it should open to. But as we have learned, one hundred percent closure is not achievable. Closing must sometimes strategic. We design our systems because they are closed to the most common types of changes we experience.

CCP expands this by grouping classes that are open to some kind of change into the same components. Thus, when a change in requirements occurs, there is a good chance that the change will need to be limited to a minimum number of components.

Types of Component Cohesion:

  • Functional symbiosis: The component contains all the essential elements for a single calculation. Active coexistence performs function and functions. It is a great situation.
  • Sequential symbiosis: An element returns some data, which becomes the input to another element, that is, data flow between parts. It occurs naturally in functional programming languages.
  • Communication Symbiosis: Two elements operate on the same input data or contribute to the same output data. Example: Update the database and send it to the printer.
  • Procedural Coexistence: Ensures the sequence of implementation of the elements of procedural coexistence. The verbs are still poorly connected and difficult to reuse. Student GPA Calculation, Student Report Printing, Accumulated GPA Calculation, Accumulated GPA Printing.
  • Temporal symbiosis: Elements are related by their timing. A module related to temporary coexistence must execute all functions within the same time frame. The code to initialize all parts of the system is contained in this symbiosis. A lot of different activities take place during the start time.
  • Logical symbiosis: Elements are logically related and those are not functional. E.g., a component reads input from tape, disk, and network. All the codes for these functions are in one component. Operations are related, but functions vary considerably.
  • Random symbiosis: Elemental not related. Elements have no conceptual relationship other than the location of the source code. It is a coincidence and the worst symbiosis. Print the next line and reverse the text of a single element thread.

Conclusion

However, the three principles of component cohesion describe a more complex form of coexistence. When selecting classes for grouping as a component, the opposing forces of reuse and development must consider.

Balancing these forces with the needs of the application is not essential. Moreover, the balance is almost always dynamic. That is, the appropriate partitioning today will not appropriate next year. Thus, as the core of the project changes from development to reusability and the composition of the component will evolve over time.

Thanks for reading the article Software Components cohesion as an essential component in System design and architecture.

My articles on medium