1. S G Ganesh
Tushar Sharma
Girish Suryanarayana

2. Introduction
Motivation and Background
Principle-based Classification Scheme for Smells
Documentation of Cataloged Smells
Initial Evaluation
Challenges
Future Directions

3. * http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf
Design quality is important
• Organizations develop critical, large,
and/or reusable software
Design errors are costly
• Capers Jones*: Up to 64% of software
defects can be traced back to errors in
software design in enterprise
software!
Good design practices
needs to be followed.
A designer/developer should
aware of and address
“design smells” in his
software design.
Design quality means: flexibility,
extensibility, understandability,
reusability,...

4. Smells have been defined differently
We embrace all the following definitions!
“We suggest that, like any living creature, system designs are subject to diseases, which are
design smells (code smells and anti-patterns). Design smells are conjectured in the literature to
impact the quality and life of systems.” – Hassaine et al. [HKGH10]
“Smells are certain structures in the
code that suggest (sometimes they
scream for) the possibility of
refactoring.” – M. Fowler [Fow99]
“Code and design smells are poor
solutions to recurring implementation
and design problems.” – Moha et. al.
[MGDM10]
“Design smells are the odors of rotting software.” – R C Martin [Mar03]

6. Introduction
Motivation and Background
Principle-based Classification Scheme for Smells
Documentation of Cataloged Smells
Initial Evaluation
Challenges
Future Directions

7. Many catalogs of smells exist; e.g.:
Design rules by Garzas et al.
[Gar07]
Bad smells by Fowler [Fow99]
Problem patterns by Frank et al.
[SSM06]
Existing catalogs fail to provide a
coherent structure
This tends to limit the
usefulness of these catalogs
An example: “problem patterns” by
Frank et al. [SSM06]
Architectural level
God package
Cyclic dependency
between packages
Micro-architectural level
Knows of derived
Polymorphism placebo
Implementation level
Improper name length
Variables having constant
value
Mixes different kinds of
concerns and addresses
different target audience
Insight 1: For a catalog to be useful, it needs to
clearly separate design smells at different levels of
abstractions and focus on smells at one specific level

8. Some catalogs also classify
smells
Impact based classification of
Fowler’s smells by Mantyla
Design property based
classification by InFusion tool
Moha’s smell classification based
on how smells can be detected
Existing classifications suffer from
numerous limitations
Mantyla [MVL03] classified Fowler’s code
smells [Fow99] as “encapsulators”, “bloaters”,
“couplers”, “OO abusers”, “change preventers”,
“dispensables”, and “others”.
Lacks maturity
Even in the Fowler’s small list
of 22 smells, 2 are classified in
“others” category
Though useful, there are
numerous shortcomings in
this classification scheme
Insight 2: A classification scheme will be more
useful when it provides high-level hints on
understanding the cause of the smell as well as
what needs to be done to fix the smell.
Inconsistent
“Encapsulators” does not have
negative connotation like
other categories

9. During our extensive literature
survey, we found 500+ smells!
However, we did not find any
attempt towards creating a
consistent naming scheme to
unambiguously distinguish design
smells.
Insight 3: Creating a consistent naming scheme
to unambiguously distinguish design smells can
provide an effective vocabulary for discussing
design smells.
Rose is a rose is a rose is a rose …
How to differentiate roses?
There are at least 135 rose
species – how do you
differentiate one from another
without separate names?
Using common names
for design smells leads
to confusion
Need to use scientific names
Using common names for
roses will lead to confusion

10. Introduction
Motivation and Background
Principle-based Classification Scheme for Smells
Documentation of Cataloged Smells
Initial Evaluation
Challenges
Future Directions

11. smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell smell
smell
As a first step,
towards Insight 1,
we decided to focus
only on design (i.e.,
micro-architectural
structural) smells
272 design smells

12. smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
To address Insight 2, we needed a
classification that can indicate both
the cause of the smell and potential
refactoring
A deeper reflection revealed that a
classification approach based on
fundamental design principles
(relevant to OO) would help
practitioners
If a practitioner could easily trace
the cause of smells to violated
design principles, it would better
guide him in addressing that smell

13. We attempted using numerous catalogs of fundamental software
engineering design principles
Of them, we found that Booch’s classification best suited our needs

14. smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
These concise set of 4 principles are
fundamental principles and well-
known
Aids easy recall
Almost all smells in our catalog could
be traced back to violation of these
principles
Each principle is a single word. A
smell can be named by prefixing a
suitable adjective to the principle
name
Name = (adjective + principle)
Uniform naming scheme!
abstraction encapsulation
hierarchy
modularity

19. Introduction
Motivation and Background
Principle-based Classification Scheme for Smells
Documentation of Cataloged Smells
Initial Evaluation
Challenges
Future Directions

20. Element Short Description
Name A concise, intuitive name based on our naming scheme
Short Description A short description of the design smell to explain the smell concisely
Long Description A detailed description about the design smell to explain the design smell (with
optional discussion on potential causes of the smell, or its e ect on design)
Rationale A rationale to justify why the identi ed issue indicates a bad smell in design
Example(s) One or more illustrative examples (including from open source software)
Violated Principles OO design principles (out of the four) whose violations can lead to this smell, the
speci c object oriented enabling techniques that have been violated, and the
justification for why the design smell is classi ed under a particular principle.
Impacted quality
attributes
The design quality attributes (reusability, exibility, understandability, functionality,
extendibility, and e ectiveness ) that are negatively impacted due to this smell.
Also known as Alternative names documented in literature that are used to describe the smell.
Variants Design smells documented in literature that are fundamentally identical to and yet
exhibit a slight variation from the smell. The variation may include a special form, or a
more general form of the design smell.
Exceptions Contexts or situations where the smell is likely to be not considered a problem.
Detection Strategy High-level hints on how the design smell can be detected from design or code artifacts.
Suggested Refactoring Generic high-level suggestions and steps to refactor the design smell.

21. Short description:
This design smell arises when a supertype directly or indirectly refers to one of its subtypes,
forming a cycle in the hierarchy [Ber04, BNL05, Gar07, Rie96, DMTS10a, WCKD11].
Long description:
This smell arises when a supertype refers to any of its subtypes. Here the term ``reference''
means:
a) a supertype contains an object of one of its subtypes
b) a supertype refers to the type name of one of its subtypes
c) a supertype accesses data members, or calls methods from one of its subtypes.
Such a reference can be either direct or indirect. Since subtype knowledge introduces a cycle
in the inheritance graph annotated with class relationships, this smell is termed as ``cyclic
hierarchy''.

22. Rationale:
It is undesirable for a supertype to have knowledge about its subtype(s) for the following
reasons:
• Supertypes and subtypes can be thought of as separating the interface and the
implementation aspects of an abstraction. An interface should specify a contract and
should not know anything about the implementation, and hence a supertype should not
have any knowledge of its subtypes.
• A supertype needs to be agnostic of any of its subtypes; only then, it is possible to compile
it, use it and reuse it independent of its subtypes. With subtype knowledge, changes to
subtypes can potentially affect the supertype, which is undesirable.

23. Example:
The example in above figure shows inheritance relationship between MutableBigInteger
and SignedMutableBigInteger from JDK; these classes were introduced in Java from version
1.3 and are part of java.math package.
The private modInverse() method in MutableBigInteger class implements an algorithm that
requires the use of signed integer and hence it creates instances of
SignedMutableBigInteger; this instance creation introduces a reference from the supertype
method to the subtype resulting in cyclic hierarchy smell.
One potential refactoring for addressing this smell is to re-implement the modInverse()
method (say, using an alternative algorithm if available) in such a way that it does not
require creating instances of SignedMutableBigInteger.

24. Violated principles:
Abstraction: A forward reference to the subtype likely indicates ineffective abstraction of
the problem domain [Mil99]. Thus the principle of abstraction is violated.
Modularity: Cyclic dependencies create tight coupling and thus violate the principle of
modularity. Specifically, cyclic dependencies indicate the violation of the Acyclic
Dependencies Principle (ADP) [Mar03]. Further, changes to subtype might require re-
compilation of the supertype affecting independent module compilability [SRK07].
Hierarchy: Ideally, inheritance should model a generalization/specialization hierarchy and
the hierarchy specializations should have dependencies that are directed towards
generalizations. A forward association from the supertype to subtype violates Dependency
Inversion Principle [Mar03], and this changing of dependency direction towards
specializations violates the principle of hierarchy.
This smell can only manifest in the context of a hierarchy. We, therefore, classify it
under the principle of hierarchy.

25. Impacted quality attributes:
• Flexibility: Changes to or removal of subtypes affect supertype, hence flexibility is
impacted.
• Understandability: In order to understand the supertype, one has to understand the
subtype also. This increases the cognitive load, affecting understandability.
• Extendability: Adding a new subtype may require changes in supertype, thus impacting
extendability of the design.
Also known as: ``Knows of derived'' [CIU99, SSM06], ``subtype knowledge'' [DTMS10b],
``subclass knowledge‘’ [BNL05], ``curious superclasses'' [BNL05], ``inheritance/reference
cycles'' [SSC96], ``base class depends on derived classes‘’ [CWZ00], ``forward associations in
a hierarchy'' [Mil99].
Variants: ``Inheritance loops'' [Bin99].

26. Exceptions:
This design smell might be acceptable if it is known that the supertype and subtype(s) are
not going to change in future [SSC96]. Sometimes, to support unanticipated changes, when
inheritance is used as registration mechanism or factory where the client should always
refer to the supertype, it is acceptable for supertypes to refer to their subtypes. Examples
(both from [DMTS10a]): Returning instance of a subtype as the default instance in Singleton
pattern and installing global default factory in case of Abstract Factory pattern.
Detection Strategy:
Check if the inheritance graph annotated with class relationships is a Directed Acyclic Graph
(DAG).
Suggested refactoring:
If the reference from supertype to subtype is accidental or incidental, refactor the
supertype to eliminate such references. If the supertype requires the services of its
subtypes, consider applying State or Strategy patterns [Gar07].

27. Degraded Hierarchy:
This design smell arises when the hierarchy tends to be more concrete towards the root and
more abstract towards the leaves. This smell includes the case where a supertype is declared
concrete and its subtype is declared abstract.
Also known as:
``Illegal abstract inheritance'' [Ber04], ``super class is a concrete class'' [Gar07], ``illegal
abstract inheritance'' [Ber04], ``abstract leaf classes'' [Mil99].
Variants:
``Abstracting concrete methods'' [ADGN10], ``inflexible root class'' [Mil99], ``inverse
abstraction hierarchies'' [Mil99].

28. Introduction
Motivation and Background
Principle-based Classification Scheme for Smells
Documentation of Cataloged Smells
Initial Evaluation
Challenges
Future Directions

29. In order to draw reasonable comparisons between our work and other well-
known catalogs/classifications, an extensive set-up would be required
In an organizational context, this is difficult to achieve
Comparative evaluation
Is our classification scheme more useful than other classification schemes?
Is our naming scheme simpler or easier to remember?
Is our catalog more complete than other catalogs?
…
Non-comparative evaluation relies on opinion of experts
Is our classification scheme useful?
Is our naming scheme simple or easy to remember?
Is our catalog complete?
…

30. As an initial step, we decided to elicit feedback
from CT DC AA practitioners
We created a design smells-centric assignment
for CT DC AA architects participating in an
advanced design and architecture training
Task: “Find design smells in your project using
our catalog as a reference”
Duration of the assignment was 1.5 months
Next, the participants were requested to provide
feedback on the usefulness of the catalog/classification
via a questionnaire
Questionnaire consisted of 10 rating-based
questions
Ratings were on a scale of 0 to 5

31. Received responses from all the 12 participants
Experience in IT industry: 10.8 years (average)
Experience as an architect: 2.9 years (average)
Objectives
How useful is the catalog
and classification to
practitioners?
How complete is the
catalog?
Is the “principle-based
classification scheme”
correct?
Is the naming scheme
useful and intuitive?

32. Knowledge improvement
by a factor of two!
Catalog “very useful”
Catalog “reasonably
comprehensive”
Question [note in square brackets] Responses:
Mean/Summary
1 Rate your knowledge in design smells before
this assignment on design smells. [0 - no
knowledge; 5 - "expert" level knowledge]
1.9
2 Rate your knowledge in design smells after this
assignment on design smells. [0 - no knowledge; 5
- "expert" level knowledge]
3.7
4 Have you come across any design smells you’ve
never seen before but was provided in this
catalog? [Yes/No] If yes, please list them.
Yes - 9
No - 2
No response - 1
5 Did you nd any design smells in your project
that were not covered in this catalog? [Yes / No.]
If yes, please list them.
Yes - 3
No - 6
No response - 3
3 How useful was the design smells catalog to
understand the kind and extent of design
problems in your project? [0 - the catalog was of no
use; 5 - the catalog was extremely useful.]
4

33. Respondents
mentioned other
factors, but they trace
back to violation of
principles
Naming scheme
reasonably useful and
intuitive
Design smells work has
been received mostly
positively
Question [note in square brackets] Responses:
Mean/Summary
6 Rate the extent to which you believe that the smells
found in your project (during the assignment) actually
resulted from a violation of the corresponding design
principles. [0 - none of the design smells resulted from
violation of the corresponding design principle; 5 - all of the
design smells resulted from violation of the design principle]
3.7
9 Would you use the design smell catalog to identify
smells in the future for your project(s)? [Yes / No]
Yes - 11
No - 1
10 Would you recommend this design smell catalog to
be used by architects in other projects that you
know? [Yes / No]
Yes - 11
No - 1
7 How useful is the naming scheme in the design
smells catalog to understand the cause of design
smell? [0 - not at all understandable; 5- very easy to
understand]
3.8
8 How intuitive is the naming scheme in the design
smells catalog? [0 - not at all intuitive; 5 - very intuitive]
3.9

34. Overall feedback
All the three aspects of our design smells work - the catalog, the classification,
and the naming scheme - has been received positively by the practitioners.
“Except a few [design smells], most of
them were new to me.”
“Generally I use my experience to identify the design
smells. But the catalog provided in the assignment
gave me a good reference about the different types of
design smells that can exist such that identifying the
design smells becomes much easy.”
“Very difficult to identify smells … due
to lack of tools.”
“I personally felt this assignment to be
very challenging …”
“Need to go through it [design smells in the catalog]
again and understand them in more depth so that next
time when designing, we would be careful about these
design problems/smells”

35. Introduction
Motivation and Background
Principle-based Classification Scheme for Smells
Documentation of Cataloged Smells
Initial Evaluation
Challenges
Future Directions

36. We found it difficult to name smells related to modularity.
Perhaps because modularity is more of a “design property” than a
principle.
We could attempt using alternative terms such as
“modularization” but that would entail deviating from principles
proposed by Booch.
Or, use alternative naming scheme with different principle names.
We believe it is perhaps not be possible to have a “perfect solution” to
naming smells.

37. Overall, most names created using our naming scheme are intuitive
As supported by the initial evaluation results.
However, our naming scheme needs to adhere to the following criteria
Violated principle should be part of the name.
Simple and easy to remember names.
Uniform and consistent names.
Sometimes, it is difficult to satisfy all these criteria, resulting in unintuitive
names
For example, just from the name “unrestrained encapsulation”, it is not
evident that it arises when an abstraction depends on global state
Again, we believe it is perhaps not possible to have a “perfect solution” to
naming smells.

38. Introduction
Motivation and Background
Principle-based Classification Scheme for Smells
Documentation of Cataloged Smells
Initial Evaluation
Challenges
Future Directions

39. Augment the catalog with smells undocumented in literature
Include a larger set of principles to classify more smells
Introduce enabling techniques to the classification scheme
Specify smells in formal/semi-formal notation
Categorize architectural and code smells
Expand the smell template (e.g. include detailed refactoring steps)
Explore relationships between smells
Develop tool support for detecting smells
Comprehensively evaluate the classification and naming scheme

40. In this work, we limited ourselves to cataloging, classifying and naming known or
“documented” smells.
Based on our industry experience, we find some smells are not
documented.
Perhaps because the focus has not been on identifying the cause of smells –
i.e. the specific sub-principles that are violated.
We believe it is possible “discover” smells! How?
Approach: Map each high-level principle to criteria or sub-principles.
If the criteria/sub-principle is violated, it could result in one or more smells
– check if these are documented.
Example: Consider the criterion offered by Booch for abstraction –
sufficiency, primitiveness, and completeness.
If we violate any one of this criteria, we may get smells such as “insufficient
abstraction” and “non-primitive abstraction”.

41. Published in Journal of Object Technology (Vol. 12, No. 2, 2013)
S.G. Ganesh, Tushar Sharma, Girish Suryanarayana, “Towards a Principle-based
Classification of Structural Design Smells”, Journal of Object Technology, Volume
12, no. 2 (June 2013), pp. 1:1-29, doi:10.5381/jot.2013.12.2.a1.
URL: http://www.jot.fm/issues/issue_2013_06/article1.pdf (open access)
“… a really comprehensive
catalog about design
smells organizing what is
found in relevant
literature...”
“The paper presents a novel idea for identifying, specifying, name and classifying design smells.
The proposal contains an extensive classification of almost 300 design smell references.”
“I really like this paper.
Excellent work! This paper can
be a key reference in the field.”
“The paper presents a
good classification and I
clearly think that it is
necessary. ”