1. 7. Modular and structured design

2. Module Specification
Modularization is the decomposition of a system into subcomponents or small units
A module is a collection of instructions & data structure
Modules should be such that it can be separately compiled & stored
Module should be such that it can be use by other modules
It makes process of debugging, testing, integration of system easy

3. Criteria to evaluate a program module
Function decomposition approach software is partitioned into independent modules so that each module is small enough to be manageable
Objectives of modular software design
Functional partitioning into discrete scalable , reusable modules
Rigorous use of well-defined modular interface
Ease of change to achieve technology transparency and to the extent possible make use of industry standards for key interfaces

4. Modularity is the principle of keeping separate the various unrelated aspects of a system, so that each aspect can be studied in isolation (also called separation of concerns)
If the principle is applied well, each resulting module will have a single purpose and will be relatively independent of the others
each module will be easy to understand and develop
easier to locate faults (because there are fewer suspect modules per fault)
Easier to change the system (because a change to one module affects relatively few other modules

5. Cohesion & Coupling (v. imp)
Cohesion is a measure of the functional strength of a module whereas the
Coupling between two modules is a measure of degree of interdependence or interaction between two modules
A module having High Cohesion and Low Coupling is said to be functional Independent

6. Classification of Cohesiveness
coincidental
Logical
Temporal
Procedural
Communicational
Sequential
Functional
High
Low
Coincidental – if a module performs a set of tasks that relate to other very loosely
Logical- if all elements of the module performs similar operations such as error handling, data input, etc
Temporal- When a module contains functions that are related by the fact that all the functions must be executed in the same time span. Eg start or shut down of any process

7. 4. Procedural – If the set of functions of the module are all part of procedure in which certain sequence of steps has to be carried out for achieving an objective
Eg login(), place order() ,check order(), print bill().
5. Communicational- if all functions of the module refer to or update the same data structure.
Eg in student management system all modules such as admissions, exam, consist of a named student which is to be updated

8. Classification of Cohesiveness
coincidental
Logical
Temporal
Procedural
Communicational
Sequential
Functional
High
Low
6. Sequential- if the elements of a module from the parts of a sequence where the output from one element of the sequence is input to next
7. Functional- If all element of a module cooperate to achieve a single function

9. Classification of Coupling
Data- two modules are data coupled if they communicate using an elementary data items that is passed as a parameter between the two. Eg int, float
Stamp coupling : Stamp coupling occurs when modules share a data structure and use only parts of it, possibly different parts (e.g., passing a whole record to a function that only needs one field of it).
In this situation, a modification in a field that a module does not need may lead to changing the way the module reads the record.

10. 3.External coupling: External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface.
This is basically related to the communication to external tools and devices.
Control- If data from one module is used to direct the order of instruction execution in other module.
5. Common- If they share some global data items
6. Content- If there code is shared. Example:
Component directly modifies another’s data
Component modifies another’s code, e.g., jumps (goto) into the middle of a routine

11. Characteristics of Good Design
Component independence
High cohesion
Low coupling
Exception identification and handling
Fault prevention and fault tolerance
Design for change

12. Top Down Design
We know that a system is composed of more than one sub-systems and it contains a number of components.
Further, these sub-systems and components may have their own set of sub-system and components and creates hierarchical structure in the system.
Top-down design takes the whole software system as one entity and then decomposes it to achieve more than one sub-system or component based on some characteristics.
Each sub-system or component is then treated as a system and decomposed further.
This process keeps on running until the lowest level of system in the top-down hierarchy is achieved.
Top-down design is more suitable when the software solution needs to be designed from scratch and specific details are unknown.

13. Bottom-up Design
The bottom up design model starts with most specific and basic components.
It proceeds with composing higher level of components by using basic or lower level components.
It keeps creating higher level components until the desired system is not evolved as one single component. With each higher level, the amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some existing system, where the basic primitives can be used in the newer system.
Both, top-down and bottom-up approaches are not practical individually. Instead, a good combination of both is used.