Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Levels of Cohesion
This material was covered during lectures on February 28, 1997.
As previously mentioned, one way to assess the ``functional independence'' of a module is to find its level of cohesion. You can do this by considering each of the kinds of ``cohesion'' that are listed below.
It isn't generally important to determine the level of cohesion precisely. It is somewhat more important to decide which broader grouping - low (unacceptable) cohesion, moderate (acceptable but not ideal) cohesion, or high (desirable) cohesion.
Modules with ``low'' levels of cohesion are highly undesirable and should be modified or replaced. Strategies for doing this will be given on a separate page.
A module that only has coincidental cohesion is one supporting tasks that have no meaningful relationship to one another. Page-Jones gives, as an example, a module (not necessarily one that can be implemented using software!) supporting the following tasks.
The legendary - and, one hopes, mythical- FORTRAN or COBOL programmer who, after being told to use subroutines and being told of an ``ideal'' length for these, drew a horizontal line after every twenty lines of code and put each block into a module, was no doubt creating modules with ``coincidental cohesion'' (and breaking one or two other rules along the way).
If you discover that the best name you can find for a module is, ``Miscellaneous Functions,'' then this a sign that your module has this undesirably low level of cohesion.
There is, pretty much, no excuse for inclusion of modules whose level of cohesion is this low, in a design for a system that's to be implemented using any high level programming language.
Again, quoting Page-Jones: ``A logically cohesive module is one whose elements contribute to activities of the same general category in which the activity or activities to be executed are selected from outside the module.'' Keeping this definition in mind, consider the following example. Someone contemplating a journey might compile the following list:
What relates these activities? They're all means of transport, of course. But a crucial point is that for any journey, a person must choose a specific subset of these modes of transport. It's unlikely anyone would use them all on any particular journey.
A logically cohesive module contains a number of activities of the same general kind. To use the module, we pick out just the piece(s) we need. Thus, a logically cohesive module is a grab bag of activities. The activities, although different, are forced to share the one and only interface to the module. The meaning of each parameter depends on which activity is being used; for certain activities, some of the parameters will even be left blank (although the calling module still needs to use them and to know their specific types)."
As Page-Jones notes later on his description, a module with a name like ``Do all System I/O'' is probably a module that is only ``logically cohesive.'' Again, a module whose level of cohesion is low as this will be extremely difficult to effectively implement, test, and maintain - so it should be avoided.
A temporally cohesive module is one supporting tasks that are all related in time. Page-Jones' (somewhat dated) example is a module supporting the tasks
and argues that these activities are (only) related by the fact that you do them all late at night, just before you go to bed.
A module whose name is ``Do All Startup Activities,'' or ``Do All Shutdown Activities,'' might only have "temporal cohesion." On the other hand, it might have the higher level of cohesion that is described next.
Modules with ``moderate'' cohesion are acceptable, but not ideal. Consider modifying them, but note that changes might introduce other design problems, so that you might best leave these as they are.
A module with (only) procedural cohesion is one supporting different and possibly unrelated activities, in which control passes from one activity to the next. Page-Jones gives an example of a module (whose name might be something like, ``Prepare for Holiday Meal:''
This is a bit better than ``temporal cohesion,'' since we know that there's a fixed ``linear ordering'' of the activities. However, there's still not much reason for putting all these activities together into one module.
A module exhibits communicational cohesion if all the activities it supports use the same input or output data - or access and modify the same part of a data structure.
Page-Jones gives, as an example, a module supporting the activities
(again, presumably, with a user to specify one, or a set, of these activities that will occur when the module is called).
Another example would be a module providing the entire interface to a stack - supporting activities ``Push,'' ``Pop,'' an ``Empty?'' test, initialization of a new (empty) stack - and, possibly, operations for initialization by reading the contents from a file, and that perform a ``save'' by writing contents to a file.
(Note that we've now left the kind of ``linear ordering'', or ``containment relationships,'' that we've had for levels of cohesion until now: I can imagine a module that would seem to have ``procedural cohesion" but not ``communicational cohesion'', and another module that has ``communicational cohesion'' but not ``procedural cohesion.'' For most of the kinds of cohesion defined up until this point, if a module had the kind of cohesion that had just been defined, then it could be argued that it also had all the other kinds of cohesion that had been defined before that.)
Again, quoting Page-Jones: ``A sequentially cohesive module is one whose elements are involved in activities such that output data from one activity serves as input data to the next.'' Page-Jones gives an example of a module supporting the following activities.
...presumably, with the ``car'' being the input that is being ``passed'' as a parameter from task to task.
Modules with high cohesion are extremely desirable, and don't need to be changed (except to correct other kinds of design problems).
A module exhibits ``functional cohesion'' if it supports activities needed for the execution for one and only one problem-related task.
Page-Jones gives several examples - modules with names
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Levels of Cohesion