On the criteria to be used in decomposing systems into modules
Communications of the ACM
TEGAS2—anatomy of a general purpose TEST GENERATION AND SIMULATION system for digital logic
DAC '72 Proceedings of the 9th Design Automation Workshop
Techniques and modules for element specification in a time - delay logic simulator
ANSS '73 Proceedings of the 1st symposium on Simulation of computer systems
Timing analysis for digital fault simulation using assignable delays
DAC '74 Proceedings of the 11th Design Automation Workshop
| Hi-index | 0.00 |
Modularity and data hiding have been considered important software engineering concepts in the design of large software systems. Program modularity deals with the partitioning of a large program into small subprograms, namely modules performing one conceptual function. Such partitioning helps to decrease the complexity of a large system. A module being small and conceptually complete, it is easier to design, test, and can be well documented. While modularization deals with program flow, data hiding on the other hand deals with the accessing of data structures. Communication between modules is established through some form of data structure. If modules directly manipulate a data structure, then their complexity is increased and a change in the data structure would force the redesign of the modules using it. Also direct access to a data structure used by many modules may propagate an error by one module to the other modules thereby making it difficult to locate the error. Such difficulties can be minimized by introducing levels of abstraction between modules and the data structures they use. These levels of abstraction should be such that modules using a data structure should be unaffected by changes in that data structure.