[go: up one dir, main page]

100% found this document useful (1 vote)
307 views19 pages

Coupling and Cohesion

The document discusses different types of coupling and cohesion in software engineering. It defines high cohesion as having all elements of a component directed towards a single task, while low coupling means components have few or no dependencies on each other. Common types of coupling include content coupling, where one component directly modifies another's data, and stamp coupling, where a component passes a partial data structure to another. High cohesion and low coupling are generally desirable as they promote independence, reusability and ease of maintenance.

Uploaded by

shailu
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 PPT, PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
307 views19 pages

Coupling and Cohesion

The document discusses different types of coupling and cohesion in software engineering. It defines high cohesion as having all elements of a component directed towards a single task, while low coupling means components have few or no dependencies on each other. Common types of coupling include content coupling, where one component directly modifies another's data, and stamp coupling, where a component passes a partial data structure to another. High cohesion and low coupling are generally desirable as they promote independence, reusability and ease of maintenance.

Uploaded by

shailu
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 PPT, PDF, TXT or read online on Scribd
You are on page 1/ 19

1

Component

independence

High cohesion Low coupling

Exception

identification and handling Fault prevention and fault tolerance

No dependencies

Loosely coupled-some dependencies

Highly coupled-many dependencies

High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the component is connected.
3

High Coupling Content Common

Control
Loose

Stamp Data Uncoupled

Low

Definition:

One component references contents of another Example:


Component directly modifies anothers data Component refers to local data of another component in terms of numerical displacement Component modifies anothers code, e.g., jumps into the middle of a routine

Definition:

Two components share data

Global data structures Common blocks

Usually

a poor design choice because

Lack of clear responsibility for the data Reduces readability Difficult to determine all the components that affect a data element (reduces maintainability) Difficult to reuse components Reduces ability to control data accesses
6

Definition:

Component passes control parameters to coupled components. May be either good or bad, depending on situation.

Bad when component must be aware of internal structure and logic of another module Good if parameters allow factoring and reuse of functionality

Definition:

Component passes a data structure to another component that does not have access to the entire structure. Requires second component to know how to manipulate the data structure (e.g., needs to know about implementation) May be necessary due to efficiency factors: this is a choice made by insightful designer, not lazy programmer.

Definition:

Two components are data coupled if there are homogeneous data items. Every argument is simple argument or data structure in which all elements are used Good, if it can be achieved. Easy to write contracts for this and modify component independently.

Definition:

The degree to which all elements of a component are directed towards a single task and all elements directed towards that task are contained in a single component. Internal glue with which component is constructed All elements of component are directed toward and essential for performing the same task High is good
10

High Cohesion Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental Low
11

Definition:

Parts of the component are only related by their location in source code Elements needed to achieve some functionality are scattered throughout the system. Accidental Worst form

12

Definition:

Elements of component are related logically and not functionally. Several logically related elements are in the same component and one of the elements is selected by the client component.

13

Definition:

Elements of a component are related by timing. Difficult to change because you may have to look at numerous components when a change in a data structure is made. Increases chances of regression fault Component unlikely to be reusable.

14

Definition:

Elements of a component are related only to ensure a particular order of execution. Actions are still weakly connected and unlikely to be reusable

15

Definition:

Module performs a series of actions related by a sequence of steps to be followed by the product and all actions are performed on the same data

16

The

output of one component is the input to another. Occurs naturally in functional programming languages Good situation

17

Definition:

Module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data. Different from logical cohesion

Each piece of code has single entry and single exit In logical cohesion, actions of module intertwined

ADT

and object-oriented paradigm promote

18

Definition:

Every essential element to a single computation is contained in the component. Every element in the component is essential to the computation. Ideal situation.

19

You might also like