CS 696: Advanced OO
Spring Semester, 1997
Doc 3, Cohesion

To Lecture Notes Index
San Diego State University -- This page last updated Feb 6, 1997

Contents of Doc 3, Cohesion

References	1

Cohesion	2
...Coincidental	4
...Logical	5
...Temporal	6
...Procedural	8
...Communication	9
...Sequential	10
...Functional	11
...Informational Strength	12

Object Cohesion	13
...Individual Objects	16

References

Object Coupling and Object Cohesion, chapter 7 of Essays on Object-Oriented Software Engineering, Vol 1, Berard, Prentice-Hall, 1993,

Doc 3, Cohesion Slide # 2

Cohesion

"Cohesion is the degree to which the tasks performed by a single module are functionally related."

IEEE, 1983

"Cohesion is the "glue" that holds a module together. It can be thought of as the type of association among the component elements of a module. Generally, one wants the highest level of cohesion possible."

Bergland, 1981

"A software component is said to exhibit a high degree of cohesion if the elements in that unit exhibit a high degree of functional relatedness. This means that each element in the program unit should be essential for that unit to achieve its purpose."

Sommerville, 1989

Types of Module Cohesion
From Worst to Best

Coincidental (worst)

Logical

Temporal

Procedural

Communication

Sequential

Functional (best)

Doc 3, Cohesion Slide # 3
Module Cohesion

Coincidental

Little or no constructive relationship among the elements of the module

Common Object Occurrence:

Object does not represent any single object-oriented concept

Collection of commonly used source code as a class inherited via multiple inheritance

class Rous
     {
     public static int findPattern( String text, String pattern)
          { // blah}

     public static int average( Vector numbers )
          { // blah}

     public static OutputStream openFile( String fileName )
          { // blah}
          
     }

Doc 3, Cohesion Slide # 4
Module Cohesion

Logical

Module performs a set of related functions, one of which is selected via function parameter when calling the module

Similar to control coupling

Cure:

Isolate each function into separate operations

public void sample( int flag )
     {
     switch ( flag )
          {
          case ON:
               // bunch of on stuff
               break;
          case OFF:
               // bunch of off stuff
               break;
          case CLOSE:
               // bunch of close stuff
               break;
          case COLOR:
               // bunch of color stuff
               break;
          }
     }

Doc 3, Cohesion Slide # 5
Module Cohesion

Temporal

Elements are grouped into a module because they are all processed within the same limited time period

Common example:

"Initialization" modules that provide default values for objects

"End of Job" modules that clean up

procedure initializeData()
     {
     font = "times";
     windowSize = "200,400";
     foo.name = "Not Set";
     foo.size = 12;
     foo.location = "/usr/local/lib/java";
     }

Cure: Each object should have a constructor and destructor

class foo
     {
     public foo()
          {
          foo.name = "Not Set";
          foo.size = 12;
          foo.location = "/usr/local/lib/java";
          }
     }
Doc 3, Cohesion Slide # 6

Sample Configuration File

[Macintosh]
EquationWindow=146,171,406,661
SpacingWindow=0,0,0,0

[Spacing]
LineSpacing=150%
MatrixRowSpacing=150%
MatrixColSpacing=100%
SuperscriptHeight=45%
SubscriptDepth=25%
LimHeight=25%
LimDepth=100%
LimLineSpacing=100%
NumerHeight=35%
DenomDepth=100%
FractBarOver=1pt
FractBarThick=0.5pt
SubFractBarThick=0.25pt
FenceOver=1pt
SpacingFactor=100%
MinGap=8%
RadicalGap=2pt
EmbellGap=1.5pt
PrimeHeight=45%

[General]
Zoom=200
CustomZoom=150
ShowAll=0
Version=2.01
OptimalPrinter=1
MinRect=0
ForceOpen=0
ToolbarDocked=1
ToolbarShown=1
ToolbarDockPos=1

[Fonts]
Text=Times
Function=Times
Variable=Times,I
LCGreek=Symbol,I
UCGreek=Symbol
Symbol=Symbol
Vector=Times,B
Number=Times

[Sizes]
Full=12pt
Script=7pt
ScriptScript=5pt
Symbol=18pt
SubSymbol=12pt

Call these constructors/destructors from a nonobject-oriented routine that performs a single, cohesive task

Doc 3, Cohesion Slide # 7
Module Cohesion

Procedural

Associates processing elements on the basis of their procedural or algorithmic relationships

Procedural modules are application specific

In context the module seems reasonable

Removed from the context these modules seem strange and very hard to understand

Why is that being done here?

Can not understand module without understanding the program and the conditions existing when module is called

Makes module hard to modify, understand

Class Builder verse Program writer

Cure:

Redesign the system

If a module is necessary, remove it from objects

Doc 3, Cohesion Slide # 8
Module Cohesion

Communication

Operations of a module all operate upon the same input data set and/or produce the same output data

Cure:

Isolate each element into a separate modules

Rarely occurs in object-oriented systems due to polymorphism

Doc 3, Cohesion Slide # 9
Module Cohesion

Sequential

Sequential association the type in which the output data from one processing element serve as input data for the next processing element

A module that performs multiple sequential functions where the sequential relationship among all of the functions is implied by the problems or application statement and where there is a data relationship among all of the functions

Cure:

Decompose into smaller modules

Doc 3, Cohesion Slide # 10
Module Cohesion

Functional

If the operations of a module can be collectively described as a single specific function in a coherent way, the module has functional cohesion

If not, the module has lower type of cohesion

In an object-oriented system:

Each operation in public interface of an object should be functional cohesive
Each object should represent a single cohesive concept

Doc 3, Cohesion Slide # 11

Module Cohesion

Informational Strength

Myers states:

"The purpose of an informational-strength module is to hide some concept, data structure, or resource within a single module.

An informational-strength module has the following definition:

It contains multiple entry points
Each entry point performs a single specific function
All of the functions are related by a concept, data structure, or resource that is hidden within the module"

Doc 3, Cohesion Slide # 12

Object Cohesion

The degree to which components of a class are tied together

Evaluating cohesion requires:

technical knowledge of the application domain
some experience in building, modifying, maintaining, testing and managing applications in the appropriate domain
technical background in and experience with reusability

Doc 3, Cohesion Slide # 13

Questions to probe cohesiveness of an object

Does the object represent a complete and coherent concept,or does it more closely resemble a partial concept, or a random collection of information?

Does the object directly correspond to a "real world entity," physical or logical?

Is the object characterized in very non-specific terms?

collection of data, statistics, etc.

Do each of the methods in the public interface for the object perform a single coherent function?

If the object ( or system of objects) is removed from the context of the immediate application, does it still represent a coherent and complete object-oriented concept?

For objects that are "system of objects"

Does the system represent an object-oriented concept?

Do all the objects directly support, or directly contribute to the support of, the object-oriented concept that the system represents?

Are there missing objects?

Doc 3, Cohesion Slide # 14

Objects in Isolation

Isolation means without considering any hierarchy that may contain the object or class

Does not discuss non-objects:

object with only functions

objects with only data

Doc 3, Cohesion Slide # 15

Individual Objects

A primitive method is any method that cannot be implemented simply, efficiently, and reliably without knowledge of the underlying implementation of the object

A composite method is any method constructed from two or more primitive methods sometimes from different objects

A sufficient set of primitive methods for an object is a minimum set of primitive methods to accomplish all necessary work with on the object

A sufficient set of primitive methods has two major problems:

Some tasks may be awkward and/or difficult with just a sufficient set of primitive methods
A sufficient set of primitive methods may not allow us to fully capture the abstraction represented by the object

A complete set of primitive methods is a set of primitive methods that both allows us to easily work with the object, and fully captures the abstraction represented by the object.

Doc 3, Cohesion Slide # 16

An object is not as cohesive as it could be if the public interface contains:

only primitive methods, but does not fully capture the abstraction represented by the object
primitive and composite methods, but does not fully capture the abstraction represented by the object
a sufficient set of primitive methods with composite methods
no primitive methods, just composite methods

Note

Objects with a sufficient set of primitive methods with composite methods is more cohesive than objects with out a sufficient set of primitive methods
All public methods must directly support the abstraction represented by the object. The methods must make sense when object is removed from the application

Doc 3, Cohesion Slide # 17

Exercise: Primitive Operations and Table Class

Abstraction: A growable two dimensional table that can be converted to and from a string.

What are:

the primitive operations?
sufficient set of primitive methods?
complete set of primitive methods?
composite methods?

Existing operations on sdsu.util.Table class

Constructors

Selectors

Iterators

addColumn(Vector)
addRow(Vector)
setElementAt(Object, int, int)

fromString(String)
load(InputStream)

setColumnSeperatorChar(...)
setRowSeparatorChar(...)
setTokenCharacters(...)

columnAt(int)
columnsAt(int, int)
columnsAt(Object, int)
rowAt(int)
rowsAt(int, int)
rowsAt(Object, int)

contains(Object)
elementAt(int, int)
indexOf(Object)

numberOfColumns()
numberOfRows()
size()

save(OutputStream, String)
toString()
toString(String)

elements()

Constructors - an operation that alters the state of an object
Selectors - an operation that evaluates the state of an object

CS 696: Advanced OO Spring Semester, 1997 Doc 3, Cohesion

Contents of Doc 3, Cohesion

References

Cohesion

Coincidental

Logical

Temporal

Procedural

Communication

Sequential

Functional

Informational Strength

Object Cohesion

Individual Objects

CS 696: Advanced OO
Spring Semester, 1997
Doc 3, Cohesion