Information Flow Metrics
This metric is purely based on information. Information flow metric is different from size metric, and data structure metric as size metric is based on the final size of program and data structure metric is based on the type of structure between the module so that programming time, effort, and resources will be less used.
Information refers to the data provided by the number of components of a program. For example:
Let suppose a program S has three components, S = A+ B + C.
Information metric says "how much components are called by A, B, C and how many components call them."
Every system hascomponents; the work and structure of these components determine the complexity of the function. Information flow metric is based on two terms, i.e., Cohesion and Coupling.
Cohesion:-If a component has to do numerous discrete tasks, it is said to lack cohesion. Cohesion is defined as the degree to which a component performs a single function.
Coupling:-Coupling is the degree of linkage between one component and others. Component linked with many components is highly coupled and vice versa.
Notes: Components with a lack of cohesion and high linkage (highly coupled) are less reliable and difficult to maintain.
Information Flow Model
Information flow metric is only applied to components, not to the whole program or system directly. On each component, an information metric is applied, and then all components are sum up.
Each component has three measures:-
- FAN IN: It measure number of component that can call A.
- FAN OUT: It measure number of component that is called by A.
Information Flow (A) = [FAN IN(A) x FANOUT(A)]2
All the analysis in IF are based on the above three points, and characteristics of the information flow metric are:-
- It can be done easily
It doesn't seem very easy to apply information metric on each component individually and sum it up in a system, but practically it can be done very quickly.
- It can be updated easily.
It is a tremendous advantage of information metrics as changes and updation of components can be quickly done.
- In a system, automation of information flow metrics can be possible.
It might be possible for a system to automatically find out IF or each component and then add each result for the final solution.
- Every component is relative to a system.
Suppose a system has three components (A, B, C) and the resultant value after applying IF on each component is A= high, B= Medium, C= Low. Therefore, it isn't easy to maintain the A component compared to B and C. All these components are relative to each other within a system.
Components of two different systems are not relative to each other.
- High FANIN or FAN OUT states lack cohesion or no abstraction.
A component which is called and which call many other components or involved in the various task has a lack of cohesion.
No abstraction = A single component cannot do all the work it has to call many functions.It doesn't matter how internally a task work. For example, component A is calling many functions. It can be possible that a single function can perform all the functions that state that there is no abstraction (A component doesn't matter about internal working).
- High IF indicates that components are highly coupled.
When components have high IF, then it means they are highly linked and coupled.
- Information flow metric is calculated in three steps
- IF is applied to individual component
- IF is applied at different levels
- Sum of IF at different level = System sum
Let’s see an example and find out the IF of the system.
- Find FAN IN and FAN OUT of each component.
FAN IN (A), FAN-OUT (A)
FAN IN (B), FAN-OUT (B)
FAN IN (D), FAN-OUT (D)
FAN IN (E), FAN-OUT (E)
FAN IN (F), FAN-OUT (F)
FAN IN (G), FAN-OUT (G)
- Find information flow of each level called as level sum (L).
L1 → IF(C)
L2 → IF (A) + IF (B)
L3 → IF (D) + IF (E) + IF (F) + IF (G)
- System sum
S = L1 + L2 + L3
Why is there a need to find out IF of different levels?
- Identify nightmare component
Nightmare component refers to the component having high IF. The developer tries to remove or find an alternate for the component having high IF in the system.
- 25% of the components with the highest score for FAN values should be investigated.
The main goal is to reduce the IF value to the lowest; therefore, 25% of components having the highest FAN IN or FAN OUT value are searched, and their value is tried to be reduced.
- Reduce the failure rate to improve the things
Sometimes a component having high IF cannot be replaced, or there is no alternative to that component; therefore, it becomes mandatory to apply the best version of the component by testing it as much as there will be no lop hole left for failure.
- Missed level of abstraction is indicated by a sudden increase in IF value across levels.
Information flow value increases from level 1 to level 2 due to no abstraction. Suppose, in the above diagram, IF value at level 2 > level 1 because component C has to call a different function that increases IF value of called component at level 2, which is due to no abstraction.
No component or function does all the tasks. Therefore abstraction is necessary among the components.
- In the last system, the SUM value gives the overall complexity rate and helps to compare alternative designs.
After getting the final system sum, the developer must calculate the system sum from other design approaches and compare them. The lowest system sum will give complexity rate, more reliability, low maintenance, and help in comparing alternative designs.