Seven Strategies for Successful Software Engineering: Part 2

In Part 1, we discussed Rigor and Formality, and Separation of Concerns. In this article, we explain how Modularity and Abstraction help in successful Software Engineering.

Modularity is an important Software Engineering principle. It is a practical application of the principle of “Separation of Concerns” by dividing a complex system into simpler and more manageable modules.

The ubiquitous television set is an example of a system made up of a number of modules – speakers, projection tube, channel buttons, volume buttons, etc. Each module has its own defined functionality but when they are put together synergistically, the complete functionalities of a television are realized.

Modularization can take place in two ways: composition or decomposition. The Composition or bottom-up approach takes modules and puts them together to form a larger system. An application of such an approach is in the assembly of a television set. The composition process begins with the assembling of electronic components such as projection tube, buttons, speakers, control board, etc. into a complete television. The alternative approach is to take a complete system and decompose it into its modules. This approach is known as the decomposition or top-down approach. A car, for example, can be decomposed into a number of sub-systems: body, fuel system, electrical system, transmission, etc. The electrical system can be further decomposed into modules such as battery, alternator, lights, etc. The Lights module can in turn be decomposed into light bulb, reflector, brackets, etc. This decomposition process repeats itself until all the elementary components are identified.

Modules are technically connected to one another. The measure of inter-module relation is known as coupling. Design goals require modules to have low-coupling and high cohesion. Cohesion is a measure of the inter-relatedness of elements (statements, procedures, declarations) within a module. A module is said to have high cohesion if all the elements in the module are strongly connected with one another. Tight coupling of modules makes analysis, understanding, modification and testing of modules difficult. Reuse of modules is also hindered.

To illustrate the concept of coupling and cohesion, let us consider the partnership of a television set with a set-top box. A set-top box is provided by a cable or satellite company as a conduit for receiving programme signals. It is connected to the television via a cable. The television set and the set-top box are each said to be highly cohesive since the internal components of the television set and the set-top box have been designed to achieve their defined functional specification. The television set does not know how a set-top box works internally, neither does a set-top box knows how a television works internally. However, both components are able to function together to produce programme contents for the viewers. The two components are said to be lowly coupled as they are weakly connected with one another (in this case, just a cable). The television set and the set-top box can be described as black-boxes since they can be operated without the need to know how their internal components function in order to operate them.

Modularity enhances the understandability of software systems and change process. Developers need not have to understand the entire system for changes to be made as details are localized into components. As the above example shows, modularity separates concerns down to the modules and is thus a direct realization of the principle of “Separation of Concerns”.

Abstraction is the separation of important details from the unimportant ones. Importance is relative. To most general users of television sets, a useful abstraction would be a description of the functionalities and how the functionalities can be achieved via the available buttons. However, to a television repairman, a useful abstraction would be a box he can dismantle for examination and repair. In other words, for the same reality, there can be different abstractions, each providing a view of the reality and serving some specific purposes.

Abstractions have long been applied in software development. Even a programming language is a form of abstraction. A high-level programming language hides the bits and the manipulation of the bits via the registers from the programmer. It does so by providing constructs to achieve the functionalities. Even the comment at the beginning of a module describing what the module does is a form of abstraction. It describes the module without revealing how the module implements its function.

In our next article we will explain Anticipation of Change, Generality and Incremental Development as Software Engineering Principles.