1. Diagnosing Design Problems in Object Oriented Systems Adrian Trifu, Radu Marinescu Proceedings of the 12th IEEE Working Conference on Reverse Engineering Presented by James T. O’Hara SE 516, Fall 2006

2. 1 Software Design Problems Software decay is a phenomena that plagues aging software systems Modern IDEs provide tools for automatic detection of “code smells” and code refactoring Restructuring practices are severely hampered by their symptomatic and informal nature

3. 2 Software Decay Maintenance activities account for more than 70% of the total costs associated with the life cycle of software systems A significant part of maintenance efforts is concerned with the phenomena called software decay (Fowler, Refactoring: Improving the Design of Existing Code. )

4. 3 Correcting Design Problems Fixing large object oriented systems is still largely a manual time-consuming process extremely risky requires human design and domain expertise

5. 4 Problem A: God Class A large, overly complex, non-cohesive class Caused by: excessive intra-class code duplication cut-and-paste coding the class encapsulates more than one cohesive concept

6. 5 A Real World Analogy A disease is diagnosed based on the presence of a specific group of symptoms Therapies are reusable procedures describe how to cure a disease

7. 6 Terminology Structural anomaly (symptom) Contextual hint Design problem problem indicators Diagnosis Restructuring strategy (treatment)

8. 7 Relationships between terminology

9. 8 Design Problems Patterns Description Indicators M (mandatory) all are required to fire O (optional) provide increased certainty Restructuring strategy how to eliminate the problem

10. 9 Pattern Structure For Specifying Design Problems Description Indicators Restructuring strategy

11. 10 Design Problems Examples Abusive Centralization of Control Abusive Conceptualization Inheritance for Implementation Reuse

12. 11 Abusive Centralization of Control Description The abusive centralization of control is a typical design problem for systems that have undergone repeated extensions over a period of time. Indicators (M) “feature envy” (O) class is a “god class” (O) class has satellite data classes (envied classes) Restructuring strategy 1: let A be the set of methods suffering from “feature envy”… 2: identify cohesive feature envious kernels in method A. Apply Fowler’s heuristic concerning extraction of methods…

13. 12 Case Study Example

14. 13 Abusive Conceptualization Description One class should model one abstraction Indicators (M) class is a “god class” (O) extensive coupling to other classes in the system (O) refused parent bequest in subclasses of the affected class Restructuring strategy 1: identify A, the set of cohesive kernels of data and associated functionality in the class 2: extract classes corresponding to the identified cohesive kernels replacing calls with delegations where necessary

15. 14 Inheritance for Implementation Reuse Description This problem corresponds to the situation in which the inheritance mechanism of the programming language is not used in conformity with the object oriented paradigm Indicators (M) at least two of the following indicators must fire (O) refused parent bequest in subclass (O) subclass is a “tradition breaker” (O) subclass uses multiple inheritance Restructuring strategy 1: replace inheritance relation with composition

16. 15 Related Work Refactoring Design Patterns Design Rules Detection Strategies Automation

17. 16 Conclusion The paper presented a causal approach to support the decision making process in object oriented restructuring The approach has a high potential for automation, which can lead to an important decrease in costs associated with restructuring

18. 17 The illusion of simplicity* *The Complexity of Programming Models. Grady Booch

19. 18 Links Martin Fowler http://martinfowler.com/ http://martinfowler.com/ Refactoring Home Page http://www.refactoring.com/ http://www.refactoring.com/ In pursuit of code quality: Monitoring cyclomatic complexity http://www- 128.ibm.com/developerworks/java/libr ary/j-cq03316/ http://www- 128.ibm.com/developerworks/java/libr ary/j-cq03316/

20. 19 References Diagnosing Design Problems in Object Oriented Systems. Adrian Trifu, Radu Marinescu, Diagnosing Design Problems in Object Oriented Systems, Proceedings of the 12th IEEE Working Conference on Reverse Engineering (WCRE 2005), IEEE Computer Society Press, 2005 Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley. 2000. Grady Booch. The Complexity of Programming Models. aosd.net/2005/archive/Complexity.ppt