Cohesion And Coupling In Software Engineering Ppt

Cohesion is an indication of how related and focused the responsibilities of an software element are. Coupling refers to how strongly a software element is connected to other elements. The software element could be class, package, component, subsystem or a system. And while designing the systems it is recommended to have software elements that have High cohesion and support Low coupling. 1 Coupling and Cohesion Software Engineering Module: Definition A logical collection of related program entities Not necessarily a physical concept, e.g., file, function, class, package Often requires multiple program entities to express: – Linked list module may require many class, e.g., list, node, iterators, etc. Why Use Modules?

In computer programming, cohesion refers to the degree to which the elements inside a module belong together.^[1] In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class's methods and data themselves.

Cohesion is an ordinal type of measurement and is usually described as “high cohesion” or “low cohesion”. Modules with high cohesion tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.

Cohesion is often contrasted with coupling, a different concept. High cohesion often correlates with loose coupling, and vice versa.^[2] The software metrics of coupling and cohesion were invented by Larry Constantine in the late 1960s as part of Structured Design, based on characteristics of “good” programming practices that reduced maintenance and modification costs. Structured Design, cohesion and coupling were published in the article Stevens, Myers & Constantine (1974)^[3] and the book Yourdon & Constantine (1979);^[1] the latter two subsequently became standard terms in software engineering.

High cohesion[edit]

In object-oriented programming, if the methods that serve a class tend to be similar in many aspects, then the class is said to have high cohesion.^[4] In a highly cohesive system, code readability and reusability is increased, while complexity is kept manageable.

Cohesion is increased if:

• The functionalities embedded in a class, accessed through its methods, have much in common.
• Methods carry out a small number of related activities, by avoidingcoarsely grained or unrelated sets of data.

Advantages of high cohesion (or 'strong cohesion') are:

• Reduced module complexity (they are simpler, having fewer operations).
• Increased system maintainability, because logical changes in the domain affect fewer modules, and because changes in one module require fewer changes in other modules.
• Increased module reusability, because application developers will find the component they need more easily among the cohesive set of operations provided by the module.

While in principle a module can have perfect cohesion by only consisting of a single, atomic element – having a single function, for example – in practice complex tasks are not expressible by a single, simple element. Thus a single-element module has an element that either is too complicated, in order to accomplish a task, or is too narrow, and thus tightly coupled to other modules. Thus cohesion is balanced with both unit complexity and coupling.

Types of cohesion[edit]

Cohesion is a qualitative measure, meaning that the source code to be measured is examined using a rubric to determine a classification. Cohesion types, from the worst to the best, are as follows:

Coincidental cohesion (worst)

Coincidental cohesion is when parts of a module are grouped arbitrarily; the only relationship between the parts is that they have been grouped together (e.g., a “Utilities” class). Example:

Logical cohesion

Logical cohesion is when parts of a module are grouped because they are logically categorized to do the same thing even though they are different by nature (e.g., grouping all mouse and keyboard input handling routines).

Temporal cohesion

Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g., a function which is called after catching an exception which closes open files, creates an error log, and notifies the user).

Procedural cohesion

Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g., a function which checks file permissions and then opens the file).

Communicational/informational cohesion

Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g., a module which operates on the same record of information).

Sequential cohesion

Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g., a function which reads data from a file and processes the data).

Functional cohesion (best)

Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module (e.g., Lexical analysis of an XML string). Example:

Perfect cohesion (atomic)

Example.

Although cohesion is a ranking type of scale, the ranks do not indicate a steady progression of improved cohesion. Studies by various people including Larry Constantine, Edward Yourdon, and Steve McConnell^[5] indicate that the first two types of cohesion are inferior; communicational and sequential cohesion are very good; and functional cohesion is superior.

While functional cohesion is considered the most desirable type of cohesion for a software module, it may not be achievable. There are cases where communicational cohesion is the highest level of cohesion that can be attained under the circumstances.^{[citation needed]}

See also[edit]

References[edit]

1. ^ ^abYourdon, Edward; Constantine, Larry LeRoy (1979) [1975]. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Yourdon Press. Bibcode:1979sdfd.book...Y. ISBN978-0-13-854471-3. ISBN0-13-854471-9.
2. ^Ingeno, Joseph (2018). Software Architect's Handbook. Packt Publishing. p. 175. ISBN178862406-8.
3. ^Stevens, Wayne P.; Myers, Glenford J.; Constantine, Larry LeRoy (June 1974). 'Structured design'. IBM Systems Journal. 13 (2): 115–139. doi:10.1147/sj.132.0115.
4. ^Marsic, Ivan (2012). Software Engineering. Rutgers University.
5. ^McConnell, Steve (June 2004) [1993]. Code Complete (2 ed.). pp. 168-171. ISBN978-0-7356-1967-8.

External links[edit]