On the Criteria To Be Used in Decomposing Systems into Modules

Abstract

This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modulariza tion 11 is dependent upon the criteria used in dividing the system into modules. Two system design problems are presented, and for each, both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decomposi tions are discussed. The unconventional decomposition, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.

Global Software Engineering: The Future of Socio-technical Coordination

“…Conway [16] observed that the structure of a product tends to resemble the structure of the organization that designed it. The reason is that once interfaces have been specified, the components themselves can be designed relatively independently of one another [4,57]. The underlying assumption is that modularity in product structure (i.e., relatively few, and well-specified interactions among components) results in modularity in subsequent design tasks (i.e., relatively few dependencies between design decisions concerning different components).…”

Managerial Authority When Knowledge is Distributed: A Knowledge Governance Perspective

“…16 However, in actual practice, the design of a problem 15 An illustration of the notion that "systemic" knowledge can be had without necessarily having (much) knowledge of individual knowledge elements may be found in the theory and practice of software development. Thus, Parnas (1972) develops the notion of "information hiding," that is, the desirability in software development (particularly in big projects) of literally hiding information in decomposed modules and so bring interdependencies down to the absolute minimum. Individual programmers ideally (!)…”

Types for Hierarchic Shapes

“…Information hiding [28] was suggested as early as the 1970s, as a means to make programs more robust and easy to understand. Mechanisms that achieve information hiding by restricting the visibility of names, e.g., private/protected annotations, are useful but insufficient.…”