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 ...
S G Ganesh Tushar Sharma Girish Suryanarayana
Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
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! * http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf
Design quality means: flexibility, extensibility, understandability, reusability,...
Good design practices needs to be followed. A designer/developer should aware of and address “design smells” in his software design.
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]
“Code and design smells are poor solutions to recurring implementation and design problems.” – Moha et. al. [MGDM10]
“Smells are certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring.” – M. Fowler [Fow99]
“Design smells are the odors of rotting software.” – R C Martin [Mar03]
Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
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 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
Mixes different kinds of concerns and addresses different target audience 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
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 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.
Though useful, there are numerous shortcomings in this classification scheme 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 Inconsistent “Encapsulators” does not have negative connotation like other categories
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.
Using common names for design smells leads to confusion
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? Need to use scientific names Using common names for roses will lead to confusion
Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
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
272 design smells
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
To address Insight 2, we needed a classification that can indicate both the cause of the smell and potential refactoring
smell
smell
smell
smell
If a practitioner could easily trace the cause of smells to violated design principles, it would better guide him in addressing that 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
A deeper reflection revealed that a classification approach based on fundamental design principles (relevant to OO) would help practitioners
smell
smell smell smell
We attempted using numerous catalogs of fundamental software engineering design principles Of them, we found that Booch’s classification best suited our needs
These concise set of 4 principles are fundamental principles and wellknown
abstraction smell
smell
Aids easy recall
smell
smell
smell
smell
Name = (adjective + principle) Uniform naming scheme!
smell
smell
smell
smell
modularity
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
Each principle is a single word. A smell can be named by prefixing a suitable adjective to the principle name
smell
smell smell
smell
smell smell
smell
smell smell
smell
smell
smell
smell
smell smell
Almost all smells in our catalog could be traced back to violation of these principles
encapsulation
hierarchy
Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
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.
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''.
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.
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.
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 recompilation 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.
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].
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].
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].
Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
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? … In order to draw reasonable comparisons between our work and other wellknown catalogs/classifications, an extensive set-up would be required In an organizational context, this is difficult to achieve
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? …
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
Objectives
How useful is the catalog and classification to practitioners?
How complete is the
Is the “principle-based classification scheme” correct?
Received responses from all the 12 participants
Experience in IT industry: 10.8 years (average)
Experience as an architect: 2.9 years (average)
catalog?
Is the naming scheme useful and intuitive?
Question [note in square brackets] 1
Responses: Mean/Summary
Rate your knowledge in design smells before this assignment on design smells. [0 - no
1.9
Rate your knowledge in design smells after this assignment on design smells. [0 - no knowledge; 5
3.7
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
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
Did you nd any design smells in your project that were not covered in this catalog? [Yes / No.]
Yes - 3 No - 6 No response - 3
knowledge; 5 - "expert" level knowledge]
2
Knowledge improvement by a factor of two!
- "expert" level knowledge]
3
Catalog “very useful”
use; 5 - the catalog was extremely useful.]
4
5
If yes, please list them.
Catalog “reasonably comprehensive”
Question [note in square brackets] 6
Responses: Mean/Summary
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
3.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
3.8
8
How intuitive is the naming scheme in the design smells catalog? [0 - not at all intuitive; 5 - very intuitive]
3.9
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
violation of the corresponding design principle; 5 - all of the design smells resulted from violation of the design principle]
7
understand]
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
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.”
“Very difficult to identify smells … due to lack of tools.”
“I personally felt this assignment to be very challenging …”
“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.”
“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”
Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
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.
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.
Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
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
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”.
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)
“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.”
“The paper presents a good classification and I clearly think that it is necessary. ”
“I really like this paper. Excellent work! This paper can be a key reference in the field.”
“… a really comprehensive catalog about design smells organizing what is found in relevant literature...”
![[PDF] Refactoring for Software Design Smells - Google Sites](https://m.moam.info/img/260x300/pdf-refactoring-for-software-design-smells-google-_6478b1b4097c474c228d6ab4.jpg)
