"We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others." Parnas, D.L. "On the Criteria To Be Used in Decomposing Systems Into Modules"
- A design criterion for modular systems
- A software design principle and tool
- Program modularity
A large system requires decomposition. One way to decompose a system is to segment it into collaborating objects. In large systems a first-cut rough model might produce hundreds or thousands of potential objects. Additional refactoring typically leads to object groupings that provide related types of services. When these groups are properly segmented, and their interfaces consolidated, the result is a layered architecture.
How to manage a complex system as a set of distinct components that can be developed independently and then combined together? How do we decompose a software solution to obtain the best set of modules?
- Roger S. Pressman. Software Engineering, Fifth Edition
How to develop coding techniques which makes a modular system easier to write, to explain, to maintain, to test, and to verify in other way with as little reference as possible to other modules?
- The user should not know anything about how an interface or abstract class is implemented, they should only program to the abstract specification.
- The implementor of a class or an interface should not know anything about how it will be used. The implementers should write the implementation code based solely on the abstract specification
- 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.
- Provide simple interfaces
- Ensure that modules hide information
- Use appropriate tools
Improve simplicity by segmenting from high-level to simple-level issues. Complex problems can be broken into smaller more manageable pieces. Then use a combination of abstraction and information hiding to take advantage of our solution to these smaller problems.
The specification of a particular problem says nothing about its implementation, the implementation details of a particular problem are hidden (abstracted) from other problems.
- Effectively manage complexity
- Save the development time
- Simplifies Verification
- Aid digestion (better than PeptoBismol??)
- Easier to change and to maintain the resulting system
- Easier to understand and to explain
This page is missing something valuable without a big ThreadMode
rant and argument... we could have a much better page here. Anyhow, I believe PatternMining
, in a different context, is a primary means of developing KnowLedge
-PatternMining basically being a method, or set of methods, for discovering patterns in architecture, computer engineering, etc. The way(s) that ChristopherAlexander and co. discovered the patterns in PatternLanguage. Some kind of observational ScientificMethod perhaps? or more creative?