Modularity

• If a system is partitioned into modules so that the modules are solvable and modifiable separately.
• It will be even better if the modules are also separately compliable.
• A system is considered modular if it consists of discreet components so that each component can be implemented separately, and a change to one component has minimal impact on other components.
• Modularity helps in system:

1. debugging—isolating the system problem to a component is easier if the system is modular;
2. in system repair—changing a part of the system is easy as it affects few other parts;
3. in system building—a modular system can be easily built by "putting its modules together.“ 

• For modularity, each module needs to support a well defined abstraction and have a clear interface through which it can interact with other modules. Modularity is where abstraction and partitioning come together.
• Module-Level Concepts:

1. A module is a logically separable part of a program. It is a program unit that is discreet and identifiable with respect to compiling and loading.
2. In terms of common programming language constructs, a module can be a macro, a function, a procedure (or subroutine), a process, or a package.
3. In systems using functional abstraction, a module is usually a procedure of function or a collection of these.
4. To produce modular designs, some criteria must be used to select modules so that the modules support well-defined abstractions and are solvable and modifiable separately. 
5. In a system using functional abstraction, coupling and cohesion are two modularization criteria, which are often used together.