Principle based classification of design smells

2,620 views
2,543 views

Published on

Published in: Technology, Health & Medicine
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,620
On SlideShare
0
From Embeds
0
Number of Embeds
1,806
Actions
Shares
0
Downloads
36
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Principle based classification of design smells

  1. 1. S G Ganesh Tushar Sharma Girish Suryanarayana
  2. 2. Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
  3. 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. 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]
  5. 5. Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
  10. 10. smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell 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
  11. 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 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
  12. 12. We attempted using numerous catalogs of fundamental software engineering design principles Of them, we found that Booch’s classification best suited our needs
  13. 13. smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell smell 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
  14. 14. Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
  15. 15. 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.
  16. 16. 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''.
  17. 17. 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.
  18. 18. 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.
  19. 19. 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.
  20. 20. 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].
  21. 21. 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].
  22. 22. 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].
  23. 23. Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
  24. 24. 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? …
  25. 25. 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
  26. 26. 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?
  27. 27. 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
  28. 28. 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
  29. 29. 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”
  30. 30. Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
  31. 31. 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.
  32. 32. 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.
  33. 33. Introduction Motivation and Background Principle-based Classification Scheme for Smells Documentation of Cataloged Smells Initial Evaluation Challenges Future Directions
  34. 34. 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
  35. 35. 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”.
  36. 36. 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. ”

×