This article will present the  SW Component Cohesion. Along with the introduction of this topic, examples from the MechLynx project will be used  (https://github.com/CharlieGearsTech/MechLynx).

The following articles mentioned the SOLID Principles, which were discussed previously:

  1. SRP: http://gearstech.com.mx/blog/2020/07/01/design-principles-single-responsibility-principle/
  2. OCP:  http://gearstech.com.mx/blog/2020/07/15/design-principles-open-close-principle/
  3. LSP: http://gearstech.com.mx/blog/2020/07/15/design-pattern-interface-segregation-principle/
  4. ISP: http://gearstech.com.mx/blog/2020/07/15/design-pattern-interface-segregation-principle/
  5. DIP: http://gearstech.com.mx/blog/2020/08/01/design-principle-dependency-inversion-principle/

In contrast with the SOLID principle which determines how a SW Component should be internally built. The SW Component Design Principles (set of SW Component Cohesion and set of SW Component Coupling) determines the arrangement of SW Components within a SW system.

Component Cohesion principles indicate how to build SW Components (what is put inside), while Component Coupling principles dictate the relationship between SW Components.

Release/Reuse Equivalency Principle

As Component Cohesion principle, REP indicates that  the granule of reuse  is the granule of release. Components should be part of a tracking system  in order to be reused.

SW Components are “packages” of deployment. They are a high organization of finer granule entities for large projects. SW Components are the smallest entities that can be deployed as “plugins” within a system. These plugins can be attached to older systems in order to solve bugs… it makes no sense to change the whole system to solve a small bug.

In this context, SW Reuse is the ability of a “user” to add SW plugins to its own system and just be concerned to use the plugin interfaces correctly. If MechLynx adds a SW plugin called “LCD_Presenter”, then developers of MechLynx should care only about using the “public” interface of LDC Presenter correctly, and not to maintain bugs and features of LCD Presenter.

MechLynx developers can determine a “version” of LCD Presenter that works for their system and stick with this version. Versions of LCD Presenter are release deployments that the LCD Presenter developers offer to the various users that LCD Presenter might have.  Since LCD Presenter is changing gradually to be stabler, then the releasing version should be numbered and the changes of this version on the new release should be notified for all the users.

Versions of good defined plugins expose only the public interfaces, then users are only concerned to use this SW properly. If a new version of a plugin is published, then users can decide whether or not to integrate this plugin depending on their systems. Some systems can start failing with new versions since changes of plugin might affect functionalities that expect old behavior of this plugin; therefore, users might decide to change their plugin versions based on the information of that plugin release.

For example, MechLynx is using LCD Presenter plugin 1.1  to show the questions and conclusion of the expert system. One MechLynx requirement indicates that the system should display Unicode characters. The support of Unicode characters is a big problem for the LCD Presenter team, so they decided to stop supporting Unicode characters and they changed the interfaces to not display these characters in the new release 1.2. If MechLynx integrates the new version 1.2 unaware that it does not support Unicode characters, then the system will start failing in the tests that version LCD Presenter 1.1 had passed.

REP is an SW Component cohesion principle since indicates that all SW entities that encloses a specific features (or are dependent from each other) should be releasable together. Classes, for example, are fine granulated SW entities, in large systems, classes are organized together for deployment and should not be versioned since this approach probably will overwhelm the release tracing system.

Versioning of releases from reuse as REP illustrates, is better that branching releases for large systems. Branching releases might involve a huge amount of effort to manage and keep on track.

Common Closure Principle

As the Component Cohesion principle, CCP indicates that  classes that are affected by the same change should be grouped together into a SW Component. Classes that are not affected by the same change should be separated into different SW Components.

When a change involves only one SW Component, then the deployment, change and validation are from only one SW Component. If two SW entities are tightly bound, either by conceptual relationship or physical dependency, then both SW entities should be grouped within a SW Component. Following the CCP, the developers avoid the scattering of changes that implies redeployment, revalidation and recompilation of several SW Components.

Common Reuse Principle

CRP indicates that  classes that tend to be deployed together should be grouped together into a SW Component, don’t dependent on things that you don’t use.  This also implies the classes depending on others should be gathered together, and avoid to couple classes which methods are not used together.

SW Component Cohesion Tension Diagram

Robert C. Martin’s Clean Architecture book introduces the Tension diagram for SW Component Cohesion, this diagram indicates the correlation between the SW Component cohesion principles and how they tend to fight each other, all cannot coexist together fully.

While CRP tries to exclude classes that are not dependent from each other, REP and CCP tend to include classes that change together.

When the architecture is based principally by the REP and CRP, then various SW Components should be redeployed when a change is made. When the architecture is based principally by REP and CCP, then releases should be made for tiny changes, causing unnecessary releases. This demonstrates that these principles cannot be implemented fully as “rules” but rather they can be considered based on the system status and timeline.

For example, for starting up projects, they don’t need to be reusable, since they are beginning and a small set of other projects will draw from it; then architects should focus on CCP and REP. When projects are mature, then reusability is more important and then the architect should focus on CRP and REP too.

 

Leave a Reply

Your email address will not be published.