Download Notes on Structuring the Program - Good Modularity | CSCI 169 and more Study notes Computer Science in PDF only on Docsity!
Structuring the Program: Good Modularity
- Goals.......................................................................................
- Cohesion
- 2.1. Coincidental cohesion.....................................................
- 2.2. Logical cohesion.............................................................
- 2.3. Temporal cohesion..........................................................
- 2.4. Procedural cohesion........................................................
- 2.5. Communicational cohesion.............................................
- 2.6. Informational cohesion
- 2.7. Functional cohesion
- Coupling
- 3.1. Content Coupling............................................................
- 3.2. Common Coupling..........................................................
- 3.3. Control Coupling
- 3.4. Stamp Coupling
- 3.5. Data Coupling...............................................................
- Formal Definitions................................................................
1. Goals - Maximize interaction within each ( cohesion ) and minimize interaction between modules ( coupling ) 2. Cohesion - the degree to which the internals of a module are related - A module has high cohesion if all of its elements are strongly related: elements are grouped together for a logical reason, not just by chance. They cooperate to achieve the common goal of the module. - High cohesion Î well-designed reusable module - There are seven cohesion levels: 1. Coincidental cohesion Î BAD 2. Logical cohesion 3. Temporal cohesion 4. Procedural cohesion 5. Communication cohesion 6. Informational cohesion 7. Functional cohesion Î GOOD
Problems: Î Module interface is difficult to understand ÎDifficult to maintain
2.3. Temporal cohesion
A module has temporal cohesion when it performs a series of related actions in time.
Ex. Î An initialization module: Initial several unrelated objects: customer_table, item_table, etc.
Î Modules to manipulate these objects are located in other modules
Problems: Maintenance and Reusability
2.4. Procedural cohesion
A module has procedural cohesion if it performs a series of actions related by the sequence of steps to be followed by the product.
Ex. Read(part_number, part_table);
Update(repair_record) maintain(cutomer_table)
Better than temporal cohesion
Problem: Reusability: actions are weakly related.
2.5. Communicational cohesion
A module has communicational cohesion if it performs a series of actions related by the sequence of steps to be followed by the product and if all actions are performed on the same data.
Better than procedural cohesion: actions of the module are closely related.
Ex. Update_record(R,table); Write_record(R,audit_table);
2.6. Informational cohesion
A module has informational cohesion if it performs a number of actions each with its own entry point, with independent code for each action, all performed on the same data structure. All actions in an informational cohesion level are closely related.
3. Coupling - Originally designed to support programming in the large Modules Encapsulation Interfaces
Uncoupled no dependencies
Loosely coupled some dependencies
Highly coupled many dependencies
- Coupling measures the degree to which the modules of a design are related.
- Ex. Module A calls a routine provided by B or access an object of module B.
Module A and B have high coupling if they depend on each other heavily.
- low coupling is a desirable feature. Modules are:
Î Modules are Reusable Î Modules are easily tested and modified Î Reduction of the maintenance cost
- There are five coupling levels:
- Data coupling Î GOOD
- Stamp coupling
- Control coupling
- Common coupling
- Content coupling Î BAD
3.1. Content Coupling
- Two modules are content-coupled if one directly references the contents of the other.
- Ex. ¾ Module p modifies a statement of module q ¾ Module p refers to local data of module q ¾ Module p refers to a local label of module q
- Problems:
¾ Any change to q may require a change to p.
¾ It is impossible to reuse module p without reusing q
Î global_variable may be changed by function_1() or function_2().
Î Modification of the declaration of the global_variable may yield a modification of every module that accesses the global variable.
¾ Common-coupled are not reusable Î They depend on modules where global variables are declared.
3.3. Control Coupling
- Two modules are control-coupled if one passes an element of control to the other module; one module explicitly the logic of the other.
- Ex. If p calls q and q passes back a flag to p that says, "I am unable to perform the requested action Ai, please write the message number
Î q informs p as what to do Î Control-coupling
3.4. Stamp Coupling
- Two modules are stamp-coupled if a whole data structure is passed as an argument but the called module operates on only some of the individual components of that data structure.
- Problems: ¾ Data access cannot be controlled: More data is passed than needed.
- Optimization:
¾ Passing different variables Î slower ¾ Passing one single record Î faster
Knuth's first law: Don't!!
¾ Required optimization Î Leave it to the experts
Knuth's second law: Not yet!!
3.5. Data Coupling
- Two modules are data-coupled if all arguments are homogeneous data items.
- It is a desirable goal.
- Data-coupled modules are easier to maintain.
Where Ri is the number of internal links and Re is the number of external links. o Example:
The cohesion of M1 and M2 in Figure 1 are:
CH(M1) = 2/ CH(M2) = 1/
o The cohesion of a software system is the average cohesion of all its n modules:
CH = (1/n) * ∑ CH(mi) for all mi of the system.
o Example: The cohesion of the system in Figure 1 is:
CH = 7/
o The coupling of a module is the ratio of the number of external links to the total number of links:
CP(mi) = Re /(Ri+Re)
o The coupling of a system is the average coupling of all its n modules:
CP = (1/n)* ∑ CP(mi) for all mi of the system.
