An Empirical Study on How Developers Reason about Module Cohesion

Design and Evolution Group
http://aside.dcc.ufba.br
Software Engineering Lab
http://les.dcc.ufba.br
By Ticino Turismo Byline: swiss-image.ch
Federal University
of Bahia, Brazil

It has been recognized as an important quality
attribute of software design.
[W. Stevens, Myers & Constantine, 1974], [Bieman & Kang, 1995], [Fenton & Pfleger,
1998], [R. Martin, 2003] …
The degree to which a module is
focused on a single concern of the
software
4

Strong related to modularity.
Highly cohesive modules are claimed to be:
easier to understand
easier to maintain
less likely to undergo changes and faults
5

Structural cohesion measurement
Conceptual cohesion measurement
6

9
Methods accessing
the same attributes

10
Methods accessing
the same attributes
For structural
cohesion
metrics, it is
highly cohesive

11
How many
concerns does
this class
address?

12
For conceptual
cohesion
metrics, it is
not highly
cohesive
How many
concerns does
this class
address?

It is still unaddressed to what extent
structural and conceptual cohesion
measurements reflect developer’s
perception of module cohesion.
13

RQ1: How do developers perceive module cohesion?
How do they reason about it?
RQ2: To what extent do structural cohesion and
conceptual cohesion measurements relate with how
developers rate cohesion of modules?
14

RQ1: How do developers perceive module cohesion?
How do they reason about it?
RQ2: To what extent do structural cohesion and
conceptual cohesion measurements relate with how
developers rate cohesion of modules?
15

Goal: Collect developers’ opinion about
module cohesion.
16

Goal: Collect developers’ opinion about
module cohesion.
228 invitations sent to software developers.
80 full responses (35%).
From different countries: Canada, Germany, Chile, Japan, USA,
Iran, Poland, Spain, Portugal and Brazil.
17

18
1.1 “Are you familiar with the concept
of cohesion in the context of software
development?”
1.2 “How would you explain
to someone else what a
highly cohesive class is?”
1.3 Providing cohesion
definition to participants
[YES]
[NO]
2.0 Questions for comparing class
cohesion (in pairs of classes)
3.0 Questions for collecting
participat's profile

19
development?”
[YES]
[NO]
Participants’
profile

Academic degree
and Occupation
20
0
5
10
15
20
25
30
35
40
Occupation
2 (2%)
25 (31%)
11 (14%)
33 (41%)
9 (11%)
0
0
5
10
15
20
25
30
35
Undergraduate Graduate Graduate
(Certified
expert)
Graduate
(Master)
Graduate (PhD) No academic
degree
Academic degree

22
1.1 “Are you familiar with the
concept of cohesion in the context
of software development?”
[YES]
[NO]
Cohesion
familiarity
question

71 –YES (89%)
9 – NO (11%)
Most of the participants are familiar with cohesion.
These 9 who are not familiar with cohesion have little
experience.
23

Coding on 71 respones.
11 topics coded.
78% related to the “class responsibilities” topic.
“It is a class with a well defined scope of responsibilities”;
“(...) When it performs a well-defined role”;
“Singular in purpose. It does one thing, and only one thing”;
7% related to class internal structure.
“Methods of this class implement features by calling each other”;
24

25
2.0 Questions for comparing
class cohesion (in pairs of
classes)
Cohesion ratings
and reasoning
development?”
[YES]
[NO]

26
“Which class is more cohesive?”
 “A”
 “B”
 “Quite similar cohesion”
 “I don’t know”
“What was your rationale?”
Cohesion ratings and reasoning
A Bvs.

Comparison
scenarios
27
A Bvs.
1st scenario
- Structural cohesion +
= Conceptual cohesion =
DB_Backend.java DB_InsertUpdate.java
A Bvs.
2nd scenario
+ Conceptual cohesion -
Main_Config2.java DB_Helpers.java
A Bvs.
3rd scenario
= Structural cohesion =
- Conceptual cohesion +
RelationSpouse.java RelationParentChild.java
Structural cohesion => LCOM5
[Henderson-Sellers, 1996]
Conceptual cohesion => LCbC
[Silva, 2012]

28
A Bvs.
Their explanation showed that none of them applied the structural cohesion perception.

29
A Bvs.
Our coding analysis confirmed that most of them used the conceptual cohesion perception.

30
A Bvs.
Why?

31
A Bvs.
41 had the conceptual cohesion perception by identifying less responsibilities in (A) class.

32
A Bvs.

33
A Bvs.
45 mentioned the class single behavior.
6 mentioned the structural relatedness of class internal members.

34
A Bvs.
They did not use structural cohesion perception in their
explanation.

35
A Bvs.
12 justified their answers by mentioning class
responsibilities.

36
A Bvs.

37
A Bvs.
“Class responsibilities” topic in all of them.

38
A Bvs.
4 of them seem to had done that by mistake. Their explanations match with the
opposite.

39
A Bvs.
2 explanations were actually related to structural cohesion
perception, whereas 24 were related to conceptual cohesion.

Most of the developers were
familiar with cohesion.
Experience may influence

Perception of conceptual cohesion
was predominant.
Regardless experience

Conceptual cohesion seems to be
more intuitive and closer to the
human-oriented view of cohesion.

Conceptual cohesion
measurement captures better the
real notion of cohesion

Implementation of conceptual cohesion metrics in
software measurement tools
take advantage of evolving concern mining techniques
Investigation on how developers maintain high (low)
cohesive modules
46

goo.gl/DmE6Is
brunocs@dcc.ufba.br
47

Design and Evolution Group
http://aside.dcc.ufba.br
Software Engineering Lab
http://les.dcc.ufba.br
Federal University
of Bahia, Brazil

LCOM – Lack of Cohesion in Methods
[Chidamber & Kemerer, 1994]
50
Counts the number of pairs of methods
that access (Q) and do not access (P)
attributes in common.
Q = 1
P = 1 + 1 = 2
LCOM = P – Q = 2 -1 = 1

Rely on text mining techniques and/or
identification of pieces of code
implementing the concerns.
C3
 [Marcus & Poshyvanyk, 2005]
MWE
 [Y. Liu et al., 2009]
LCbC
 [B. Silva et al., 2012]
51

LCbC – Lack of Concern-based Cohesion
[B. Silva, C. Sant’Anna, C. Chavez, A. Garcia, 2012]
52
Counts the number of concerns implemented
by a class.
Relies on a concerns-to-code mapping.
Concerns:
Business rule
Persistence
Exception handling
LCbC = 3

 “it is a class with a well defined scope of responsibilities”;
 “(...) It should not take responsibility for functions other than its own”;
 “(...) When it performs a well- defined role”;
 “Singular in purpose. It does one thing, and only one thing”;
 “All the included functionalities are conceptually highly related”;
 “(…) If you think of a Def-Use-Graph almost all nodes should be connected to
achieve high cohesion”;
 “Methods of this class implement features by calling each other”;
 “Its members are concerned mostly with themselves and other members of the
same class”. 53

The term cohesion was first introduced in 1974 by Stevens and colleagues in the
context of structured design and defined as a measure of the degree to which the
internal elements* of a module* belong together. Accordingly, in a highly
cohesive module, all the elements are related to the performance of a single
behavior of the software.
Martin (2003) defined that a highly cohesive class should have a single
responsibility. Bieman and Kang (1995) stated that a highly cohesive class should
be dificult to split.
* A module can be considered as a class in object-oriented programming. Accordingly, the internal
elements are its fields and methods.
54

55
• Size
• Context
• Naming conventions
• Source code comments

An Empirical Study on How Developers Reason about Module Cohesion

More Related Content

Similar to An Empirical Study on How Developers Reason about Module Cohesion (20)

Recently uploaded (20)

An Empirical Study on How Developers Reason about Module Cohesion