avatarCaitlin Jee

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

3577

Abstract

uld we be decomposing our projects into modules? As shown in my experience with a single-file program, programs without proper modularization would be a nightmare to maintain and extend.</p><p id="c2c6">In modularization, the modules have minimal dependency on other modules. So, we can easily make changes in a module without affecting other parts of the program.</p><p id="59d2">The following are just the gist of how modularization would improve the development process for a program.</p><ul><li>Easier to add and maintain smaller components</li><li>Easier to understand each module and their purpose</li><li>Easier to reuse and refactor modules</li><li>Better abstraction between modules</li><li>Saves time needed to develop, debug, test and deploy a program</li></ul><h1 id="0d7e">How should we decompose modules?</h1><p id="48d0">A module should have only a single responsibility, that is the <a href="https://en.wikipedia.org/wiki/Single-responsibility_principle">Single Responsibility Principle</a>. Thus, it should depend minimally on other modules. The independence of a module can be measured using coupling and cohesion.</p><blockquote id="b74c"><p>Coupling: Coupling is the measure of the degree of interdependence between the modules. A good software will have low coupling.</p></blockquote><blockquote id="8c33"><p>Cohesion: Cohesion is a measure of the degree to which the elements of the module are functionally related. It is the degree to which all elements directed towards performing a single task are contained in the component. Basically, cohesion is the internal glue that keeps the module together. A good software design will have high cohesion.</p></blockquote><figure id="269b"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*KerJ1DkDffzo9IBn.png"><figcaption>Cohesion and coupling, from <a href="https://www.geeksforgeeks.org/effective-modular-design-in-software-engineering/">geeksforgeeks</a></figcaption></figure><figure id="a762"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*LeYrqzsURfoi6GzD.png"><figcaption>Module coupling, with (c) being what we want to avoid, from <a href="https://www.javatpoint.com/software-engineering-coupling-and-cohesion">javatpoint</a></figcaption></figure><p id="f57f">Each module should have a clear and focused purpose, such that its developers have a clear idea of the requirement for each function. Its interface should be easy to understand and use, even without understanding its implementation details. Thus, leading into our next point, is that its implementation details, while not only correct, should be encapsulated and private, and that it should be changeable without affecting another module. Furthermore, the dependency between modules should be minimised.</p><h1 id="cc44">Example: Modularization on a text-to-speech application</h1><p id="dbb3">Consider a text-to-speech application that will translate a user’s input text into speech and read it out loud. It should be able to:</p><ul><li>Parse a user’s input text</li><li>Use a selected computer’s voice to read out the text</li><li>Have a controllers that can speed up or slow down the computer’s speech if the user chooses</li></ul><p id="083e">We can apply modularization to this application and decompose it to the following modules:</p><ul><li>Text-to-speech: Parses the user’s text to be read out loud</li><li>Computer voice: Stores and provides computer voices that the user can choose</li><li>Text speech controller: Controls that speed of the speech that the user chooses</li></ul><figure id="423f

Options

"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*TCcz_apMtHh8Y3QamAeqKg.png"><figcaption>How we can decompose the monolithic text-to-speech application into separate modules</figcaption></figure><p id="e176">Rather than designing the application as one giant monolith, it can instead be broken down into modules, each specific for one software function. Thus, the developers can develop each module in parallel, saving development time.</p><p id="a056">Additionally, the text-to-speech and computer voice modules can be used for other applications, for example a voice navigation application.</p><figure id="8a9c"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*lWW4vMWi1rw3veEea6bNTA.png"><figcaption>How we can reuse the text-to-speech and computer voice modules for a voice navigation application</figcaption></figure><p id="a1cb">Therefore, the benefits of designing the text-to-speech application using modularization is that each module is responsible for its own independant function, which makes it easier to develop, test and maintain. Plus, they can be reused in other applications.</p><h1 id="add8">Conclusion</h1><p id="43a8">To sum it up, modularization is essential while working in a software engineering team, maximizing developer productivity. The complexity of a program can easily scale exponentially as it grows, which is the crux of developer productivity.</p><p id="fa1e">Modularization helps us break down large, complex systems into small and manageable components. Without it, it would be difficult to handle any but the smallest programs.</p><p id="20b9">The power of modularization lies in its ability in allowing code to remain flexible when facing ever-changing requirements. Thus, we should always decompose our programs into modules so that we can fully enjoy the benefits of modularization.</p><h1 id="1c89">Further Reading</h1><p id="be79">The following link is a practical example of how we can apply modularization to a React-Redux application:</p><ul><li><a href="https://www.genui.com/resources/modular-redux">https://www.genui.com/resources/modular-redux</a></li></ul><h1 id="bd91">References</h1><ul><li><a href="https://www.geeksforgeeks.org/effective-modular-design-in-software-engineering/">https://www.geeksforgeeks.org/effective-modular-design-in-software-engineering/</a></li><li><a href="https://www.modularmanagement.com/blog/software-modularity">https://www.modularmanagement.com/blog/software-modularity</a></li><li><a href="https://www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/">https://www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/</a></li><li><a href="https://www.genui.com/resources/5-essential-elements-of-modular-software-design">https://www.genui.com/resources/5-essential-elements-of-modular-software-design</a></li><li><a href="https://www.infanion.com/news-blogs/modular-programming-increased-value-our-customers">https://www.infanion.com/news-blogs/modular-programming-increased-value-our-customers</a></li><li><a href="https://thecustomizewindows.com/2020/12/what-is-modular-programming/">https://thecustomizewindows.com/2020/12/what-is-modular-programming/</a></li><li><a href="https://www.janeve.me/software-programming/modular-programming-in-java">https://www.janeve.me/software-programming/modular-programming-in-java</a></li><li><a href="https://help.liferay.com/hc/en-us/articles/360018168431-The-Benefits-of-Modularity">https://help.liferay.com/hc/en-us/articles/360018168431-The-Benefits-of-Modularity</a></li></ul></article></body>

Modularization in Software Engineering

Photo by Markus Spiske on Unsplash

One year ago, when a friend and I were working on one of our first software engineering projects, we wrote the whole program in one singular file. There was no separation, no modularization, only one file with 2000+ lines of code. That inevitably led to countless merge conflicts, and changing one part of the code would almost always affect another part. We would often be changing a lot of old code just to add a new function.

In short, working on it was a headache.

What is modularization?

Modularization diagram, from infanion

In this current age of software, you would be hard-pressed to find a program that isn't continuously growing and evolving. Designing a program all at once, with all required functions, would be difficult due to its size, complexity and constant changes. This is where modularization comes in.

Modularization is the process of separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

Monolith vs modular program, from janeve

With modularization, we can easily work on adding separate and smaller modules to a program without being hindered by the complexity of its other functions. In short, it’s about being flexible and fast in adding more software functions to a program. In a software engineering team, we could easily work independently on each module without affecting others’ work.

It is the backbone of the microservice architecture, whose basic idea is also the simplicity of developing applications that are easier to extend and maintain when disassembled into small and independent parts. On the other hand, in monolithic architecture, there’s always the risk of bringing down the whole program with a simple update.

Microservices and modularity, from thecustomizedwindows

Without modularization, this will lead to an increase in development time, the number of bugs and the duration it takes to test and release a program.

Monolithic vs modular software, from modularmanagement

Benefits of modularization

Why should we be decomposing our projects into modules? As shown in my experience with a single-file program, programs without proper modularization would be a nightmare to maintain and extend.

In modularization, the modules have minimal dependency on other modules. So, we can easily make changes in a module without affecting other parts of the program.

The following are just the gist of how modularization would improve the development process for a program.

  • Easier to add and maintain smaller components
  • Easier to understand each module and their purpose
  • Easier to reuse and refactor modules
  • Better abstraction between modules
  • Saves time needed to develop, debug, test and deploy a program

How should we decompose modules?

A module should have only a single responsibility, that is the Single Responsibility Principle. Thus, it should depend minimally on other modules. The independence of a module can be measured using coupling and cohesion.

Coupling: Coupling is the measure of the degree of interdependence between the modules. A good software will have low coupling.

Cohesion: Cohesion is a measure of the degree to which the elements of the module are functionally related. It is the degree to which all elements directed towards performing a single task are contained in the component. Basically, cohesion is the internal glue that keeps the module together. A good software design will have high cohesion.

Cohesion and coupling, from geeksforgeeks
Module coupling, with (c) being what we want to avoid, from javatpoint

Each module should have a clear and focused purpose, such that its developers have a clear idea of the requirement for each function. Its interface should be easy to understand and use, even without understanding its implementation details. Thus, leading into our next point, is that its implementation details, while not only correct, should be encapsulated and private, and that it should be changeable without affecting another module. Furthermore, the dependency between modules should be minimised.

Example: Modularization on a text-to-speech application

Consider a text-to-speech application that will translate a user’s input text into speech and read it out loud. It should be able to:

  • Parse a user’s input text
  • Use a selected computer’s voice to read out the text
  • Have a controllers that can speed up or slow down the computer’s speech if the user chooses

We can apply modularization to this application and decompose it to the following modules:

  • Text-to-speech: Parses the user’s text to be read out loud
  • Computer voice: Stores and provides computer voices that the user can choose
  • Text speech controller: Controls that speed of the speech that the user chooses
How we can decompose the monolithic text-to-speech application into separate modules

Rather than designing the application as one giant monolith, it can instead be broken down into modules, each specific for one software function. Thus, the developers can develop each module in parallel, saving development time.

Additionally, the text-to-speech and computer voice modules can be used for other applications, for example a voice navigation application.

How we can reuse the text-to-speech and computer voice modules for a voice navigation application

Therefore, the benefits of designing the text-to-speech application using modularization is that each module is responsible for its own independant function, which makes it easier to develop, test and maintain. Plus, they can be reused in other applications.

Conclusion

To sum it up, modularization is essential while working in a software engineering team, maximizing developer productivity. The complexity of a program can easily scale exponentially as it grows, which is the crux of developer productivity.

Modularization helps us break down large, complex systems into small and manageable components. Without it, it would be difficult to handle any but the smallest programs.

The power of modularization lies in its ability in allowing code to remain flexible when facing ever-changing requirements. Thus, we should always decompose our programs into modules so that we can fully enjoy the benefits of modularization.

Further Reading

The following link is a practical example of how we can apply modularization to a React-Redux application:

References

Software Development
Software Engineering
Modularization
Modular Programming
Recommended from ReadMedium