On Practices in Design: Modular Design (Modularity)

Recently, I read an article on Java Modularity on InfoQ (Modular Java: What Is It?) and forced me to revisit my notes on modularity from the 1990s. As expected, every bit of the principles espoused then are applicable now. The following is what I learned then.

In Modular design, software is divided into separately named and addressable components, called modules, which are integrated to satisfy problem requirement. It implies a system decomposed into “natural” components that can be developed and maintained independently.

Many researchers are advocating the benefit of using a modular design approach. Bertrand Meyer (in his book Object-Oriented Software Construction) came up with a set of criteria to characterize modular design. These criteria provide a first step in formalizing the design practice of modularity.

Meyer’s Five Criteria for achieving modularity:

• Decomposability - the facility with which a design method helps the designer to decompose a large problem into sub problems that are easier to solve.


• Composability – the facility with which a design method ensures that program components (modules), once designed and built, can be reused to create other systems.


• Understandability – the ease with which a program component can be understood without reference to other information or modules.


• Continuity – the ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or very few modules.


• Protection – an architectural characteristic that will reduce the propagation of side effects if an error does occur in a given module.

From the above criteria, Meyer suggests five basic design principles can be derived for modular architecture:

1. Linguistic (such as Java) modular units


2. Few interfaces


3. Small interfaces (weak coupling)


4. Explicit interfaces


5. Information hiding

Effective modular design practice always encompasses the well-understood software development principles such as Abstraction, information hiding, and Functional independence. The concepts of abstraction and information hiding help to focus on the relevant element during design and development. The main focus of functional independence is to design modules that serve one function and limit excessive interaction to other modules. The two methods that are used to measure the independence of a module are Cohesion and Coupling. Thus, the main goal of modular design is to minimize Coupling and to maximize Cohesion.

Since Modularity is a process of creating or structuring a system in to manageable size of modules, it may suggest that creating many modules to be an optimal solution. But, there are some principles to be considered here:

• On what bases is the modularization effort to be conducted, i.e, by functionality or by size?


• When do we know we have crated optimal modules for the solution?


• What are the procedures to achieve modularity?


• Is the process reversible?


• What properties are available to measure the conformance of the modules with?

In order to answer the above questions, I suggest the use of SOLID principles from Robert Martin (Agile Software Development, Principles, Patterns, and Practices). These principles provide two aspects: the first one is that they help in the development activity to attain good design and the second aspect is to evaluate an existing design or during a design review activity.

I will continue to revisit my notes and share the interesting ones on the up coming posts.

Currently Reading: What Got You Here Won't Get You There: How Successful People Become Even More Successful by Marshall Goldsmith and Mark Reiter.