Taking Cohesion Into the Classroom

TAKING COHESION INTO THE CLASSROOM

Suzanne Smith Department of Computer and Information Sciences East Tennessee State University Johnson City, TN 423-439-5807 [email protected]

Sara F. Stoecklin Computer Science Department Florida State University - Panama City Campus Panama City, FL 850-443-8784 [email protected]

Judy Mullins Computer Science Telecommunications Department University of Missouri-Kansas City Kansas City, MO 816-235-1194 [email protected]

ABSTRACT This paper describes cohesion as used and recognized in structured design as well as in the object- oriented 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 object- oriented 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).

Structured Design Object-oriented Design Functional* All elements of module contribute to Only one output exists for the module one and only one task Sequential* Outputs of one module serve as input One output is dependent on the other data to the next module output Communicational* Elements contribute to activities that Two outputs are dependent on a use the same input or output data common input Procedural* Elements of a module are involved in Would be evaluated as coincidental different and possibly unrelated cohesion in OO activities in which control flows from each activity to the next Iterative N/A Two outputs are iteratively dependent on the same input Conditional Same as logical cohesion in structured Two outputs are conditionally dependent on the same input Temporal* Elements of a module are involved in Would be evaluated as coincidental activities that are related in time cohesion in OO Logical* Elements of a module contribute to Would be evaluated as conditional activities of the same general category cohesion in OO but are conditionally dependent on the input Coincidental* Elements contribute to activities with Two outputs have no dependence no meaningful relationship 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 quick- reference 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 Sequential Cohesion one task yes no Does data relate the task AND is sequence of tasks important Communicational Cohesion yes no Does data relate the task AND is the sequence of the task NOT important Procedural Cohesion yes no Does flow of control relate the tasks AND sequence is important Temporal Cohesion yes no Does flow of control relate the tasks AND Logical Cohesion sequence is NOT important yes no Are the activities in the same general category 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 Page- Jones 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.