7. Modular and structured design

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

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

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

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

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

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

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

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.

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. 4. 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

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

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.

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.