0% found this document useful (0 votes)
223 views

Coupling Cohesion

This document discusses coupling and cohesion in software design. It defines coupling as the degree of interdependence between components, and aims to reduce complexity by making components as independent as possible. The types of coupling discussed include data coupling, stamp coupling, control coupling, common coupling, and content coupling. Cohesion refers to how well the responsibilities within a component fit together, and the document outlines seven levels of cohesion from worst to best. The goal is to minimize coupling and maximize cohesion to improve understandability, reusability, and maintainability of software.

Uploaded by

akbisoi1
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
223 views

Coupling Cohesion

This document discusses coupling and cohesion in software design. It defines coupling as the degree of interdependence between components, and aims to reduce complexity by making components as independent as possible. The types of coupling discussed include data coupling, stamp coupling, control coupling, common coupling, and content coupling. Cohesion refers to how well the responsibilities within a component fit together, and the document outlines seven levels of cohesion from worst to best. The goal is to minimize coupling and maximize cohesion to improve understandability, reusability, and maintainability of software.

Uploaded by

akbisoi1
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 28

Coupling and Cohesion

Dr. Michelle L. Lee

(C) Michelle Lee, 1999

Coupling

(C) Michelle Lee, 1999

Definition of Coupling
The degree of interdependence between two or more components.
Reducded coupling Reduced Complexity

Make components as independent as possible.


Eliminate unnecessary relationships Ease the tightness of necessary relationships.
(C) Michelle Lee, 1999 3

Definition of Coupling
The fewer the connection, the less chance there is for the ripple effect.
Ideally, changing one component should not require a change in another. Should not have to understand details of one component in order to change another (c.f. principle of locality).

(C) Michelle Lee, 1999

Coupling Principles
Create narrow connections Create direct Connections Create local connections Create obvious connections Create flexible connections

(C) Michelle Lee, 1999

Narrow (vs. Broad) Connections


The breadth of connections is number of connections that link two components.
A connection that passes 15 pieces of information from one component to another is broader than a connection in which only two are passed. The greater the number of parameters in a method call the broader the connection.
(C) Michelle Lee, 1999 6

Direct vs. Indirect Connections


A direct connection is one in which the interface between two components can be understood without having to refer to other prices of information.
A method definition including pre- and postconditions has a more direct interface than one that does not.

(C) Michelle Lee, 1999

Direct vs. Indirect Connections


Pass simple pieces of information, Do not pass aggregate structures unless the aggregate is a logical entity. Do not group elements into arbitrary aggregates just to reduce coupling - it does not work!

(C) Michelle Lee, 1999

Local vs. Remote Connections


Local Connection
All information required to understand theconnection is present in the connection itself.

Remote Connection
Coupled through global data. May be hundreds of lines removed from a call point. May be remote in time. (C) Michelle Lee, 1999

Obvious Connections
Easier to understand the obscure connections
Avoid strange or unnatural connections.
E.g storing area code at the end of phone number.

Direct access to state variables is an obscure connection.

(C) Michelle Lee, 1999

10

Flexible Connections
Systems evolve over time.
information being passed changes. May want to switch to a different logical or physical devices.

(C) Michelle Lee, 1999

11

Types of Coupling
NORMAL
Data Stamp Control
Acceptable

COMMON CONTENT
Unacceptable
(C) Michelle Lee, 1999 12

Normal Coupling
Two components, A and B, are normally coupled if
A calls B B returns to A All information passed between them is by parameters in the call (or a return).

Types of Normal Coupling


Data Coupling Stamp Coupling Control Coupling
(C) Michelle Lee, 1999 13

Data Coupling
Two components are data coupled if they communicate through parameters. Each parameter is an elementary piece of data. Most common form of coupling. Harmless if number of parameters is kept to a minimum.
(C) Michelle Lee, 1999 14

Data Coupling
Keep interfaces as narrow as possible. Avoid tramp data:
Data passed from component to component that is unwanted and meaningless to most.

(C) Michelle Lee, 1999

15

Stamp Coupling
Two normally coupled components are stamp coupled if one passes to the other a complete piece of data - one with meaningful internal structure.
E.g customer records

(C) Michelle Lee, 1999

16

Stamp Coupling Warnings


Do not pass aggregate structures containing many fields when only one or two are needed by callee.
You do not want to couple caller to the structure of the aggregate. Creates dependencies between otherwise unrelated components.

Do not bundle unrelated data.


(C) Michelle Lee, 1999 17

Control Coupling
Two components are control coupled if one passes to the other a piece of information intended to control the internal logic of another.
E.g. flags

Downside: Caller must understand some of the details about how the logic of the callee is organized.
(C) Michelle Lee, 1999 18

Control Coupling Warnings


Avoid hybrid coupling, which results from the assignment of different meaning to different parts of the range of a piece of data.

(C) Michelle Lee, 1999

19

Common (Global) Coupling


Two components are common coupled if they refer to the same global data area. This is an undesirable form of coupling. Defect in one component using common global data can affect others. Introduces remoteness (with respect to time).
(C) Michelle Lee, 1999 20

10

Common (Global) Coupling


Maintenance effort is increased due to difficulty in knowing what data is used by a particular component. Difficult to determine what data must be changed when a component is modified. Also difficult to find what components will be affected by a change.
(C) Michelle Lee, 1999 21

Content (Pathological) Coupling


Two components exhibit content coupling if one refers to the internals of the other in any way. This form of coupling is unacceptable. It forces you to understand the semantics implemented in another component.

(C) Michelle Lee, 1999

22

11

Determine Coupling Type


Ask:
Can programmers work independently? To what degree? What may change that may cause changes to multiple components?

A pair of components may be coupled in more than one way:


Their coupling is determined by their worst type that they exhibit.
(C) Michelle Lee, 1999 23

Coupling in Object-Oriented Programs

(C) Michelle Lee, 1999

24

12

Effects of Object Technology on Coupling


Object Technology adds additional relationships that often result in increased coupling. Proper application of design principles can reduce the complexity often found in procedural programs.
E.g. effective use of access control can eliminate common coupling.
(C) Michelle Lee, 1999 25

Class Coupling
The coupling between tow classes is a measure of how much they depend on each other (degree of dependency) Addresses tow related issues
How much do I need to understand about related classes in order to understand a particular class? If changes are made in one class, what is the potential impact with respect to other classes in the system?
(C) Michelle Lee, 1999 26

13

Class Coupling
Coupling chan range from none (independent classes) to very strong (e.g. friend classes in C++) Dependency between classes can be in one direction (Class A dependents on B, but not conversely) or both directions Direct correlation between low coupling and reusability General goal: Minimize the amount of coupling between classes
(C) Michelle Lee, 1999 27

Coupling due to Aggregation


Nothing really new: do not access state variables directly (proper access control can prevent this). Use abstraction to create well-defined method interfaces that only expose logical properties of object.

(C) Michelle Lee, 1999

28

14

Coupling due to Interface


Abstract Interface Coupling:
One class references the operations contained in the public interface of an abstract class (weakest form of coupling)

Concrete Interference Coupling:


One class reference the operations contained in the public interface of a concrete class (generally acceptable form of coupling)
(C) Michelle Lee, 1999 29

Coupling due to Inheritance


Inheritance Coupling:
One class is a subclass of another
String coupling but generally desirable (factor out commonality and promote reuse) minimize coupling introduced by inheritance by not accessing inherited instance variables directly (where possible,use inherited operations to access to inherited instance variable)

(C) Michelle Lee, 1999

30

15

Coupling due to Inheritance


Adds another dimension to the coupling problem. What you see is not necessarily all that you get.
Many non-apparent details.

Inheritance forces you to look in potentially many places in order to understand a component.
(C) Michelle Lee, 1999 31

Acceptable forms of Coupling in Object-Oriented Programs


Normal Coupling (all forms) Context Coupling
The only acceptable form of common coupling.

Type Coupling

(C) Michelle Lee, 1999

32

16

Context Coupling
Classes are like mini systems:
Have their own set of methods Encapsulate a set of state variables. But, classes are more than this, they define types!

State variables in a class act like global variables in a system:


Local methods that depend on them are common coupled together.
(C) Michelle Lee, 1999 33

Type Coupling
Coupling that results from the use of common type declarations.
Probably the most common form of coupling in an object-oriented program.

(C) Michelle Lee, 1999

34

17

Unacceptable Forms of Coupling in Object-Oriented Programs


Content Coupling Common Coupling (Except for Context Coupling)
This means no public state variables! What about protected?
Best to avoid Encapsulated behind a protected selector method.

(C) Michelle Lee, 1999

35

Content Coupling
Internal Representation Coupling: one class has direct access to the private attribute values (instance variables) of another class
Very strong coupling and usually undesirable Example: friend classes in C++ Possible application: container class and an associated iterator class (two highly interdependent classes which work closely together to achieve a common goal)
(C) Michelle Lee, 1999 36

18

Cohesion

(C) Michelle Lee, 1999

37

Cohesion
The cohesion of a component is a measure of how well it fits together. A component should implement a single logical function or should implement a single logical entity.

(C) Michelle Lee, 1999

38

19

Seven levels of cohesion


Coincidental Logical Temporal Procedural Communicational Sequential Functional
Worst Maintainability

Best Maintainability
39

(C) Michelle Lee, 1999

Seven levels of cohesion


Coincidental cohesion
The parts of a component are not related but simply bundled into a single component

Logical association
Components which perform similar functions such as input, error handling, etc. are put together in a simple component.

(C) Michelle Lee, 1999

40

20

Seven levels of cohesion


Elements contribute to activities of the same general category. Activities are selected from outside the component. Logically cohesive components contain a number of activities of the same kind. We choose which pieces to use.

(C) Michelle Lee, 1999

41

Seven levels of cohesion


Temporal cohesion
All of the components which are activated at a single time, such as start up or shut down are put together. Tend to be composed of partial functions whose relationship is that the happen to be carried out at a particular time. Activities are usually more closely related to activities in other components than they are to each other. (C) Michelle 1999 42 Lee, Harder to reuse.

21

Seven levels of cohesion


Procedure cohesion
The elements in a component make up a single control sequence Control flows from each activity to the next. Elements are involved in different and (potentially) unrealted activities.

Drawbacks:
Tend to be composed of pieces of functions that have little relationship to one another (except for order and time that they are carried out).
(C) Michelle Lee, 1999 43

Seven levels of cohesion


Communicational cohesion
All the elements of a component operate on the same input data or produce the same output data

Sequential cohesion
The output from one element in the component serves as input for some other element Good coupling, easily maintained.
(C) Michelle Lee, 1999 44

22

Functional Cohension
Functional cohesion
The parts of a functionally cohesive component contribute to a single purpose or problem. Each part of the component is necessary for the execution of a single function Single-purpose
Low-level (methods, classes) Medium-level (packages, class categories) High-level (systems, sub-systems)
(C) Michelle Lee, 1999 45

Cohesion Decision Tree

(C) Michelle Lee, 1999

46

23

Comparison of Cohension Level

1 Page-Jones, M. (1988). The Practical Guide to Structured Systems Design. Englewoold Cliffs, New Jersey, Yourdon Press.

(C) Michelle Lee, 1999

47

Object-Oriented Cohesion

(C) Michelle Lee, 1999

48

24

Class Cohesion
Class cohesion
Each operation provides function which allows the attributes of the class to be modified, inspected or used as a basis for service provision.

A cohesive object is one where a single entity is represented and all of the operations on that entity are included with the object
(C) Michelle Lee, 1999

49

Class Cohesion
Cohesion is a measure of strength of connectivity of the items within a class (binding strength) Whereas coupling describe the relationships between classes, cohesion describes the relationships within the class. Address the purpose of the class: Do the items (attributes, operations, etc.) of a class work together toward a single, common purpose? (C) Michelle Lee, 1999 50

25

Class Cohesive
Highly cohesive classes are usually more easily understood and and less susceptible to change (more stable) General goal: strong class cohesion

(C) Michelle Lee, 1999

51

Types of Class Cohesion


Single Abstraction Cohesion:
The class encapsulates a single abstraction(strong cohesion)
all items work together to achieve a common purpose usually provides operations in the public interface which manipulate hidden representation details

(C) Michelle Lee, 1999

52

26

Types of Class Cohesion


Sequential
The items within the class must be accessed or activated in a particular order
may be required at some level of abstraction within the system but sequential nature should be hidden as much as possible limit coupling to a class with sequential cohesion a system decomposition based on the order in which operations are to be executed stands to suffer considerable from any change of external (C) Michelle Lee, 1999 53 specifications - Bertrand Meyer

Types of Class Cohesion


Temporal Cohesion:
Items are bound together within a class because they must be used at approximately the same time
example: system initialization class weak form of cohesion which should generally be avoided.

(C) Michelle Lee, 1999

54

27

Types of Class Cohesion


Logical Cohesion:
There is a weak, logical connection among the items in the class but not in terms of data or control
example: class of mathematical functions (sine, cosine, etc.)

(C) Michelle Lee, 1999

55

Class cohesion
Cohesion means a unit represents a single part of the problem solution. The inheritance promotes reusability but reduce cohesion
It is no longer consider that object as a separate unit. All super-classes also have to be inspected if the objects functionality is to be understood completely.
(C) Michelle Lee, 1999 56

28

You might also like