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.

Top-Down and Bottom-Up Strategies

• A system consists of components, which have components of their own; indeed a system is a hierarchy of components. The highest-level component correspond to the total system.
• To design such a hierarchy there are two possible approaches: top-down and bottom-up.
• A top-down design approach starts by identifying the major components of the system, decomposing them into their lower-level components and iterating until the desired level of detail is achieved.
• Top-down design methods often result in some form of stepwise refinement .
• Starting from an abstract design, in each step the design is refined to a more concrete level, until we reach a level where no more refinement is needed and the design can be implemented directly.
• Most design methodologies are based on the top-down approach.
• A bottom-up design approach starts with designing the most basic or primitive components and proceeds to higher-level components that use these lower-level components.
• Bottom-up methods work with layers of abstraction.
• Starting from the very bottom, operations that provide a layer of abstraction are implemented.
• The operations of this layer are then used to implement more powerful operations and a still higher layer of abstraction, until the stage is reached where the operations supported by the layer are those desired by the system.
• A top-down approach is suitable only if the specifications of the system are clearly known and the system development is from scratch.
• If a system is to be built from an existing system, a bottom-up approach is more suitable, as it starts from some existing components.

- for example, if an iterative enhancement type of process is being followed, in later iterations, the bottom-up approach could be more suitable (in the first iteration a top down approach can be used).

• Pure top-down or pure bottom-up approaches are often not practical.
• Combine approaches is also use full for layer of abstraction.
• This approach is frequently used for developing systems.

Abstraction

• Abstraction is a tool that permits a designer to consider a component at an abstract level without worrying about the details of the implementation of the component.
• An abstraction of a component describes the external behavior of that component without bothering with the internal details that produce the behavior.
• Abstraction is an indispensable part of the design process and is essential for problem partitioning.
• There are two common abstraction mechanisms for software systems:

        - Functional abstraction, a module is specified by the function it performs.

• For example, a module to compute the log of a value can be abstractly represented by the function log.
• Similarly, a module to sort an input array can be represented by the specification of sorting.

       - Functional abstraction is the basis of partitioning in function-oriented approaches. The decomposition of the system is in terms of functional modules.

       - Data abstraction, any entity in the real world provides some services to the environment to which it belongs.

       - Data is not treated simply as objects, but is treated as objects with some predefined operations on them. The operations defined on a data object are the only operations that can be performed on those objects.

       - Data abstraction forms the basis for object-oriented design.