TAKING COHESION INTO THE CLASSROOM
Suzanne Smith
Department of Computer and Information Sciences
East Tennessee State University
Johnson City, TN
423-439-5807
smits01@etsu.edu
Sara F. Stoecklin
Computer Science Department
Florida State University - Panama City Campus
Panama City, FL
850-443-8784
stoeckli@cs.fsu.edu
Judy Mullins
Computer Science Telecommunications Department
University of Missouri-Kansas City
Kansas City, MO
816-235-1194
mullinsj@umkc.edu
ABSTRACT
This paper describes cohesion as used and recognized in structured design as well as in the objectoriented design of methods. A technique for determining the cohesiveness of object-oriented methods,
simplistic enough for even CS1 students, is presented.
INTRODUCTION
Cohesion and coupling are well understood as measures of quality in the design and coding of
structured procedures. However, these and similar software measurements have not been effectively
utilized in object-oriented development. This paper examines the software measurement cohesion and
explains how cohesion can be effectively measured in the object-oriented design of methods. We believe
that cohesion is an important concept in object-oriented design and should be more effectively addressed in
computer science courses. Towards this goal, we are introducing in this paper a technique for determining
the cohesiveness of object-oriented methods which is simplistic enough for use in CS1 courses.
BACKGROUND
In the early 1970s, the software engineering community used a transformational design technique
called “structured design.” While the techniques used for structured design had various implementations,
the technique for building structured software was defined [1, 6], used, measured [5], and improved.
Software structures that resulted from the use of structured design techniques were considered to be “good
design.” These structures were evaluated to show that they met minimum standards for low maintenance
cost, high understanding, and high reusability [5]. Software that did not have good evaluations was
revised.
In the 1980s, structured design techniques were more clearly defined, and they became accepted
by both the professional and academic communities. These techniques were directly related to such
software quality attributes as overall program quality, maintainability, reusability, flexibility, testability,
understandability, and modifiability. Quality assurance measurements, otherwise known as software
measurements, were associated with structured design techniques to ensure that established quality
attributes (i.e., “good design”) were realized in the code. Two significant measurements used on structured
code were cohesion and coupling. In pursuit of software quality through good design, computing
organizations included standard evaluation of programs using these measurements, and computer science
and software engineering professors taught these measurements in conjunction with the concepts of good
design.
During the 1990s, object-oriented development became increasingly popular in both the
professional and academic computing communities. However, during the evolution from structured to
object-oriented design, software measurements for “good design” were often disregarded. Consequently,
many object-oriented software products became a “sprawling, sloppy, duct-tape and bailing wire, spaghetti
code jungle” called a “big ball of mud” [2]. Product developers fully intended to follow best practices for
reusable components and good design. However, without standard measurements being used, unregulated
iterative development, functionality growth, and repeated changes resulted in a degradation to haphazard
object-oriented architectural structures. Although various software measurements have been identified for
object-oriented design, the effective use of these measurements in the software development process and
their role in the development of quality object-oriented software have not been clearly understood.
COHESION AND THE OBJECT-ORIENTED DESIGN OF METHODS
Various software measurements have been identified for the evaluation of methods developed in
object-oriented design. This article focuses on the measure of cohesion in the lowest level functional unit of
object-oriented design (i.e., a method or function).
Method cohesion, originally defined for structured design, has unique characteristics in objectoriented design. Kang [3], like Page-Jones [4], defines method cohesion as “the relatedness of a module’s
components.” Using the definitions of Kang and Page-Jones, the types of cohesion for both structured
design and object-oriented design are compared in Figure 1.
The original measurements identified by Page-Jones are denoted with an asterisk beside their
names. The first difference noted is that structured functional cohesion deals with the cohesion of the
actions in a module (unit) to perform one and only one task. Object-oriented functional cohesion deals
with the ability of a module to produce only one output for one module (i.e., to change the state of only one
object).
Iterative
Structured Design
All elements of module contribute to
one and only one task
Outputs of one module serve as input
data to the next module
Elements contribute to activities that
use the same input or output data
Elements of a module are involved in
different and possibly unrelated
activities in which control flows from
each activity to the next
N/A
Conditional
Same as logical cohesion in structured
Temporal*
Elements of a module are involved in
activities that are related in time
Elements of a module contribute to
activities of the same general category
but are conditionally dependent on the
input
Elements contribute to activities with
no meaningful relationship
Functional*
Sequential*
Communicational*
Procedural*
Logical*
Coincidental*
Object-oriented Design
Only one output exists for the module
One output is dependent on the other
output
Two outputs are dependent on a
common input
Would be evaluated as coincidental
cohesion in OO
Two outputs are iteratively dependent
on the same input
Two outputs are conditionally
dependent on the same input
Would be evaluated as coincidental
cohesion in OO
Would be evaluated as conditional
cohesion in OO
Two outputs have no dependence
relationship with each other and no
dependence relation on a common
input
Figure 1
Comparison of Cohesion in Structured and Object-oriented Design
Strongly cohesive modules are desired because cohesion contributes to the maintainability,
understandability, and reusability of a module. The stronger the cohesion, the easier the module is to
maintain, understand, and reuse. The types of cohesion listed in Figure 1 are ranked from the best level of
cohesion to the worst. Functional, sequential and communicational cohesion in modules is acceptable in
both structured and object-oriented development. Anything less cohesive is considered unacceptable.
To make the cohesion measurement more usable and understandable, Page-Jones [4] provided a quickreference decision tree to determine the level of cohesion of a structured module. This decision tree is
shown in Figure 2.
Functional Cohesion
yes
Is the module
performing only
one task
no
Sequential Cohesion
yes
Does data relate
the task AND is
sequence of tasks important
no
Communicational Cohesion
yes
Does data relate the
task AND is
the sequence of the
task NOT important
no
Procedural Cohesion
yes
Does flow of control
relate the tasks AND
sequence is important
Temporal Cohesion
yes
no
Does flow of control
relate the tasks AND
sequence is NOT important
Logical Cohesion
yes
Are the activities
in the same general category
no
Coincidental Cohesion
no
Figure 2
Cohesion Decision Tree for Structured Design
EVALUATING AN OBJECT-ORIENTED METHOD USING COHESION
Using Kang’s definitions for object-oriented cohesion, we have defined an easy-to-use decision
tree for determining the level of method cohesion in an object-oriented design. The decision tree by PageJones was the inspiration for our decision tree. This object-oriented decision tree, shown in Figure 3, should
prove useful to practitioners and students in evaluating object-oriented methods
Functional Cohesion
yes
Does the module
modify fewer than 2
object variables
Sequential Cohesion
yes
no
Do all modifications actually
result in the change
to only one variable
Communicational Cohesion
yes
no
Are the output(s) dependent
on common input but not
derived in a loop or a
select statement
Iterative Cohesion
yes
no
Are the output(s) dependent
on common input and are
they used in a loop
Conditional Cohesion
yes
no
Are the output(s) dependent
on common input and are
they used in a selection
no
Coincidental Cohesion
Figure 3
Cohesion Decision Tree for Object-oriented Methods
APPLYING OBJECT-ORIENTED COHESION
Using the cohesion decision tree for the evaluation of object-oriented methods shown in Figure 3,
segments of Java code have been evaluated to show examples of each of the types of object-oriented
cohesion for methods.
Functional Cohesion
The module, deposit, illustrates object-oriented functional cohesion because it produces only one
output for one module (i.e., to change the state of only one object).
public void deposit (double amount)
{
balance = balance - amount;
}
Sequential Cohesion
In the module withdraw, two objects (variables), namely amount and balance, are modified.
However, both modifications result in changing only one instance variable (balance).
public double withdraw (double amount, double fee)
{
amount = amount + fee;
if (amount < 0)
System.out.println (“Error: withdraw amount is invalid.”);
else if (amount > balance)
System.out.println (“Error: Insufficient funds.”);
else
balance = balance – amount;
return balance;
}
Communicational Cohesion
The module addCD modifies more than one object (variable), and those outputs are dependent on
only one common input, namely the CD. Thus, addCD is an example of communicational cohesion.
public void addCD (String title, String artist, double cost, int tracks)
{
if (count = = collection.length)
increaseSize ( );
collection [count] = new CD (title, artist, cost, tracks);
totalCosts = totalCosts + cost;
count++;
}
Iterative Cohesion
In the module formDet, there are several objects (array variables) modified. However, each
modification is a result of looping. Although this level of cohesion is acceptable, it could be improved by
calling a method that changes the three variables rather than changing them within the loop. A meaningful
name for such a method would increase the understandability of this module.
void formDet (float Equations[2][3], float x[2][2], float y[2][2],
float D[2][2])
{
for (int Row = 0; Row < 2; ++Row)
for (int Col = 0; Col < 2; ++Col)
{
x[Row][Col] = Equations[Row][Col];
y[Row][Col] = Equations[Row][Col];
D[Row][Col] = Equations[Row][Col];
}
x[0][0] = Equations[0][2];
x[1][0] = Equations[1][2];
y[0][1] = Equations[0][2];
y[1][1] = Equations[1][2];
}
Conditional Cohesion
In the following method, there is more than one object output, namely dueDate, availability, and
the return variable. All modifications are the result of an if statement. Again, this is an acceptable level of
cohesion, but it could be made better by adding a method to change dueDate and availability.
public boolean checkBookIn ( )
{
if (this.isAvailable ( ))
{ //this object cannot be checked out
System.out.println (“Error: “ + callNumber + “ is not checked out”);
return false;
}
else
{
dueDate = null;
availability = true;
return true;
}
}
Coincidental Cohesion
In the method readInput, various objects are modified, but no loop or selection statement defines
what will be modified. The readInput method does not demonstrate an acceptable level of cohesion, but it
can be improved.
public void readInput ( )
{
System.out.println (“Enter name of item being purchased: “);
name = MyInput.readLine ( );
System.out.println (“Enter price of item: “);
price = MyInput.readLineDouble ( );
System.out.println (“Enter number of items purchased: “);
numberBought = MyInput.readLineInt ( );
}
In this method, objects are placed together because they are modified at the same time, and the
modifications yield all the input for the program. However, a better solution would be to embed three
separate methods (each containing the appropriate prompt and read statements for one variable) in
readInput. The readInput method could then simply call the individual input methods for each variable.
Each embedded method (for example, AcceptItem) would be more easily modifiable, more maintainable,
and reusable.
public String AcceptItem ( )
{
System.out.println (“Enter name of item being purchased: “);
name = MyInput.readLine ( );
return name;
}
USE IN THE CLASSROOM
Developing highly cohesive object-oriented methods is challenging for novice programmers.
Nevertheless, teaching students how to build highly cohesive object-oriented methods needs to be
addressed by computer science academia. In this article, a simple approach for evaluating object-oriented
methods is provided. It allows students and practitioners to determine the level of cohesion found in their
method designs. It is usable in the lowest level of the curriculum, namely CS1, and can also be used in
more advanced courses.
REFERENCES
[1] DeMarco, T., Structured Analysis and System Specification, New York, NY: Yourdon Press, 1978.
[2] Foote, B., Yoder, J.W., Big ball of mud, Fourth Conference on Patterns Languages of Programs,
Monticello, Illinois, September 1997, technical report #wucs-97-34, Department of Computer Science,
Washington University Department of Computer Science, September 1997.
[3] Kang, B., Bieman, J.M., A quantitative framework for software restructuring, Journal of Software
Maintenance: Research and Practice, 11 (4), 245-284, 1999.
[4] Page-Jones, M., The Practical Guide to Structured Systems Design, New York, NY: Yourdon Press,
1980.
[5] Stevens, W., Myers, G., Constantine L., Structured design, IBM Systems Journal, 13 (2), 115-139,
1974.
[6] Yourdon, E., Constantine, L., Structured Design, New York, NY: Yourdon Press, 1978.