Questioning Meyer's Definition of Modularity

The definition of Modularity is much more complex that one would expect. The Six Operators of Modularity that I talked about in a previous article is one definition. It's a definition that is based on empirical observation, furthermore it's complete. That is with the six operators it can be shown that any hierarchical structure of modules can be transformed to another using a sequence of these operators.

However, a comment from another reader is that Bertrand Meyer's definition is more appropriate for software. Meyer presents five fundamental requirements that a design method worthy of being called "modular" must satisfy:

1. Modular Decomposability - A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex subproblems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.
2. Modular Composability - A method satisfies Modular Composability if it favors the products of software elements which may then be freely combined with each other o produce new systems, possibly in an environment quite different from the one in which they were initially developed.
3. Modular Understandability - A method favors Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.
4. Modular Continuity - A method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.
5. Modular Protection - A method satisfied Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

The six operator definition focuses on functional invariance in the presence of design transformations. Meyer's definition although isn't as complete as the six design operators, emphasizes quality attributes in the form of understandability, changeability and fault tolerability. Unfortunately, quality attributes are a bit too open ended, there are other "ilities" that come in to play in almost every design context.

Another problem with the definition is that "ilities" tend to be cross cutting concerns that may span multiple modules. Meyer's definition assumes that that these align with the module boundaries. It's an assumption that doesn't hold up very well in practice. That could be one reason that that the last 3 definitions are qualified with words like "at worst", "a small number" and "a few neighboring". In practice, absolute isolation of an "ility" is extremely difficult to achieve. The best one can hope for is that the six operators of modularity are available for the manageability of the "ility". In other-words, modularity as defined by design operators appears as the modularity of aspects.