Modularity

The concept of modularity in computer software has been espoused for almost four decades. The Software architecture embodies modularity which is, software is divided into separately addressable and named components called modules which are integrated to satisfy problem needs.

It  has  been  begin that  modularity is  the  single  attribute of  software which  allows  a  program to  be intellectually manageable. The Monolithic software example for a huge program comprised of a single module cannot be simply grasped by a reader. The number of control, span of reference, paths number of variables and overall complexity would make understanding close to impossible. To describe this point let's consider the following argument based on observations of human problem solving.

Let C(x) be a function which describe the perceived complexity of a problem x and E(x) be a function which describe the effort in time need to solve a problem x. For 2 problems p₁ and p₂, if it follows that

C(p₁) > C(p₂) (1a)

E(p₁) > E(p₂)     (1b)

As a general case this result is intuitively observable. It does take more time to solve a hard problem.

Another interesting characteristic has been uncovered by experimentation in human problem solving. Which is

C(p₁+p₂) > C(p₁) + C(p₂) (2)

The Equation (2) implies in which the perceived complexity of a problem which combines p1 and p2 is greater than the perceived complexity when each problem is considered separately. The Considering equation (2) and the condition implied through equations (1), it follows which

E(p₁+p₂) > E(p₁)+E(p₂)     ........3

This leads to conquer and divide conclusion - it's simpler to solve a complex problem when you break it into manageable pieces. Result expressed in inequality has very important implications with regard to software and modularity. It is fact an argument for modularity.

It is possible to conclude from not equality (3) in which if we subdivide software indefinitely the effort needs to establish it will become negligibly small! Unfortunately other forces come into play causing this conclusion to be sadly invalid. In figure 18.2   describe, the effort cost to established an individual software module does decrease as the total number of modules increases.  By given the similar group of requirements more modules mean smaller individual size. Moreover, as the number of modules grows the effort cost related with integrating the modules also grow. With These characteristics it lead to a total cost or effort curve describe in the figure. There is a number M of modules which would result in minimum development cost but we do not have the necessary sophistication to predict M with assurance.

The curves describe in Figure do give useful guidance when modularity is measured. We should modularize but care should be taken to stay in the vicinity of M. Under modularity or over modularity should be avoided but How modular should we make software?  how do we know the vicinity of M? The answers to these questions need an understanding of other design concepts considered later in this lecture another   important question rise when modularity is considered. How do we describe an appropriate module of a given size? The answer lies in the methods used to describe modules within a system. The Meyer defines 5 criteria which enable us to evaluate a design technique with respect to its ability to define an effective modular system:

Modular decomposability: If a design technique provides a systematic mechanism for decomposing the problem into sub problems it will decrease the complexity of the overall problem thereby achieving an effective modular solution.

Modular composability: If a design technique enables existing reusable   design parts to be assembled into a new system it will yield a modular solution that does not reinvent the wheel.

Modular understandability: It will be simple to easier and build to modify a module can be understood as a standalone unit without reference to other modules.

Modular continuity: If little changes to the system needs result in changes to individual modules rather than system-broad changes the impact of modification-induced side effects will be minimized.

Modular protection: If an aberrant situation occurs within a module and its effects are constrained within that particular module the impact of error-induced side effects will be minimized.

At the final stage, it is important to note that a system may be designed modularly even if its implementation must be monolithic. There are condition Example for real time software embedded software in which relatively minimal speed and memory overhead introduced by subprograms example for subroutines, procedures is unacceptable. In such situations like software can and should be designed with modularity as an overriding philosophy. Code may be developed in-line. While the program source code may not look modular at first glance the philosophy has been maintained and the program will give the advantages a modular system.