10.8 A Measure of Cohesion

10.8 A Measure of Cohesion

The term "cohesion" is used frequently in the software engineering literature, mostly without a clear definition; that is, a definition that lends itself to quantification. In general, a module is said to be cohesive if all of the module parts work toward some common goal or function. That is, each module with good cohesion will tend to use all of its parts to the solution of a particular function whenever it is invoked. If we were to write a C function called trig that would return the sine, cosine, or tangent of an angle given as a parameter depending on the value of yet another parameter, then this module would obviously not have good cohesive properties. Sometimes it would compute the sine and return that value; sometimes it would compute the tangent and return that value; etc. Different code segments in the module would be responsible for each of the trigonometric functions. Each of the code segments would operate more or less independently of the others. Although this is a relatively extreme example, in most cases we simply will not know how well we have performed in creating modules that have this property of cohesion until we actually begin to run the code.

It is clear, then, that a measure of software module cohesion will be a dynamic property of that module. Basically, each time a module is executed, it will select a subset of paths from its flowgraph. If the set of arcs executed from this flowgraph is essentially the same from one epoch to another, then the module will have this property of cohesion. Actually, we are not interested in all of the arcs in the program. We are interested only in those that are exiting edges from predicate nodes.

We can measure the execution of the arcs with the instrumentation methodology discussed in Section 10.5.1. For the purposes of assessing the cohesiveness of a module, we are only interested in whether or not an arc executed during one module execution epoch. Let represent the execution of an arc j in module i on the kth execution epoch. If, during epoch k, arc j in module i was expressed, then we will represent the arc contact by letting , otherwise . After the execution of l epochs, then, the average will be

where c is the number of times that this arc was executed during the l epochs. The variance of will be

It is clear, then that if the same arcs of module i execute over all epochs, the variance will be zero for all arcs. This is the point of maximum cohesion. A module will have demonstrated less cohesion if is relatively large.

Clearly, the larger the module, the more complex it will become. As its complexity increases, so too will the complexity of the flowgraph for the module. The number of paths through a flowgraph will also tend to follow this trend. Quite naturally, then, we would expect a reasonable correlation between and any of our module size metrics such as Exec.



Software Engineering Measurement
Software Engineering Measurement
ISBN: 0849315034
EAN: 2147483647
Year: 2003
Pages: 139

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net