System iNetwork

September 2006

« Previous Month Main Next Month »

September 26, 2006

Dimensions of Modularity

Whether we are developing new applications or modernizing older applications written in the "structured monolith" style of former times, the virtue of modularization is widely acknowledged as contributing to applications which are swiftly comprehended, flexible, easy to maintain, and give a high degree of reusability. Modularity is a fundamental premise of modern application development.

But modularity can come in many shapes and sizes and be mapped out according to a variety of architectural strategies. Different applications may be modularized differently to accomplish different objectives, and modularization practices may reflect distinctive corporate traditions and customs. It may be worthwhile to give some reflection to the dimensions which give shape to the characteristic of application modularity.

I can think of three basic dimensions: 1) the degree of differentiation of tasks into functional modules, 2) the extent of distribution of the modules across compilation units or source members, and 3) the overall modularization strategy applied.

If we think of an application as a system for holding information and performing tasks, modularization is primarily concerned with the design -- the differentiation and placement -- of the tasks. The tasks will be placed in "modules" (procedures, methods, subroutines, programs, some identifiable block of code capable of being executed either internally or by being called), the modules will be placed in source members or compilation units, and there will be a design of relationship between modules.

The degree of differentiation of tasks into functional modules is a basic dimension of modularity. A fine-grained design will have a small number of tasks per module whereas a course-grained design may have larger sets of tasks per module. The traditional structured monolith generally had a course-grained design, with several tasks grouped into each subroutine. This style has given way to more fine-grained designs with small task-focused modules, usually placed in procedures or methods rather than subroutines.

The extent of distribution of the modules across compilation units or source members is another basic dimension of modularity. Here we might distinguish between dispersed versus congregated designs. The traditional practice among RPG developers prior to RPG IV was to congregate tasks into subroutines and subroutines into programs, and often each significant program (file maintenance, order entry, MRP run, etc.) would contain most, if not all, of its tasks in subroutines, and only rarely call other programs. The congregated design resulted in a small number of source members each holding a large set of task modules. That design has given way to a more dispersed distribution of task modules across a larger number of source members or compilation units. This results in more opportunities for code reuse and seems to simplify maintenance.

How the application tasks are differentiated and distributed is further influenced by the overall modularization strategy applied. Here we might distinguish between the traditional systems analysis and design taught back in the 70s and 80s with the object-oriented analysis and design which became popular in the 90s and is now the dominant design/analysis model. In the traditional approach there was great independence of the data from the processes performed on it, whereas with the OO approach data and the methods which can be applied to it are generally bound together into "objects". These two basic approaches govern how we think about our solution space and imagine our options within that space.

But it would be misleading to think that there are only two general perspectives here, for some limitations of the object-oriented approach have required its supplementation with things like aspect-oriented programming. Indeed, it might be best to retain and use all valuable approaches to analysis and design in a pluralistic practice which includes business process analysis as well as the more technical practices. The application of any analysis and design practice would be determined by its relevance and fitness to the particular challenge at hand.

But in the end, the preference today is to have applications designed with a high degree of modularity, i.e., with a fine-grained and dispersed modularization strategy. It is generally believed that such applications will be more flexible and easier (and hence less costly) to maintain than course-grained, congregated designs.

Posted by on September 26, 2006 at 5:24 AM | Comments (1)