ABSTRACT SEMANTIC INCONSISTENCY AND COMPUTATIONAL INTRACTABILITY IN TRANSITIVE ABSTRACTION RULES By Cihan Kaynak Class diagrams in UML have the ability to capture the conceptual design view of a software system. Therefore, the abstraction of them has vital implications in reverse engineering and program comprehension. Building abstraction of class diagrams that are directly generated from source code is crucial to provide a maintenance engineer the ontology of a legacy system. Egyed proposed 121 transitive abstraction rules to discover UML relationships among classes that are related to domain concepts. In this work, we propose a number of modifications to Egyed’s rules that address some semantic inconsistencies. Furthermore, we prove that serial application of Egyed’s rules is inherently ambiguous in some cases and the identification of a semantically consistent abstraction is computationally intractable. Finally, we introduce a methodology that simplifies the set of abstraction rules introduced by Egyed. SEMANTIC INCONSISTENCY AND COMPUTATIONAL INTRACTABILITY IN TRANSITIVE ABSTRACTION RULES A Thesis Submitted to the Faculty of Miami University in partial fulfillment of the requirements for the degree of Masters of Computer Science Department of Computer Science and System Analysis by Cihan Kaynak Miami University Oxford, Ohio 2008 Advisor______________________________________ Dr. Gerald C. Gannod Reader_______________________________________ Dr. James Kiper Reader_______________________________________ Dr. Valerie Cross TABLE OF CONTENTS 1 Introduction ............................................................................................................................. 1 2 Background and Related Work ............................................................................................... 3 2.1 Unified Modeling Language (UML) ................................................................................ 3 2.2 Reverse Engineering and Design Recovery ..................................................................... 5 2.3 Concept Identification ...................................................................................................... 6 2.4 Transitive Abstraction Rules ............................................................................................ 7 2.5 Related Work.................................................................................................................... 9 3 Abstraction Rules .................................................................................................................. 13 3.1 Analysis of Abstraction Rules ........................................................................................ 13 3.1.1 Generalization ......................................................................................................... 13 3.1.2 Dependency............................................................................................................. 22 3.1.3 Association .............................................................................................................. 30 3.2 Ambiguity in Serial Abstraction .................................................................................... 33 3.3 Reducing the Set of Abstraction Rules .......................................................................... 37 4 Tool Support: XARules .......................................................................................................... 43 5 Conclusion and Future Investigations ................................................................................... 47 References ..................................................................................................................................... 49 Appendix A: The Proposed Abstraction Rules ............................................................................. 51 Appendix B: Ambiguous Paths with four Classes ........................................................................ 55 ii LIST OF FIGURES Figure 1. Generalization relationship. ............................................................................................. 4 Figure 2. Association relationship. ................................................................................................. 4 Figure 3. Aggregation relationship. ................................................................................................ 4 Figure 4. Dependency relationship. ................................................................................................ 4 Figure 5. Input-Output Schema of the Abstraction Function ......................................................... 8 Figure 6. A counterexample where ............................................................................................... 18 Figure 7. An example where does not depend on T. ................................................................. 21 Figure 8. An example where there is no association between and . ........................................ 21 Figure 9. A path that contains four classes. .................................................................................. 33 Figure 10. The first way of abstracting the path in Figure 9. ........................................................ 34 Figure 11. The second way of abstracting the path in Figure 9. ................................................... 34 Figure 12. Structure of the path that contains classes............................................................ 36 Figure 13. The abstraction of a path according to Rule #3 defined by Egyed. ............................. 38 Figure 14. The abstraction of a path according to Rule #60 defined by Egyed. ........................... 38 Figure 15. New syntax to represent an abstraction rule. ............................................................... 41 Figure 16. The high-level workflow of XARules. ......................................................................... 43 Figure 17. An example from XARules. ......................................................................................... 45 Figure 18. Abstraction of the low-level model in Figure 17. ........................................................ 46 iii Acknowledgements Firstly, I would like to thank Dr. Gerald C. Gannod for his continuous support and commitment on my thesis. This work would not have been realized without his valuable feedback. In the meantime, I would like to thank Dr. James Kiper and Dr. Valerie Cross for participating in my thesis committee and reviewing this work. Secondly, I can never thank my parents and brother enough for their constant encouragement. The inspiration they have been providing me has always been my principal guide while achieving my goals in my life. I would also like to thank all of my friends for their sincerity. Enduring friendships that I made at Miami University let me enjoy and be grateful for every single moment in my last two years. Finally, I would like to extend my love to a beautiful woman in my life. Words cannot express how much I appreciate her strong support on my every single step. She is not only the one whom I love to death, but also my best friend whose encouragement always helped me to overcome any challenge that I encountered. iv 1 Introduction The Unified Modeling Language (UML) is a well accepted standard that has been used in the software industry to model structural, behavioral, and architectural views of a software system [1]. Class diagrams specified by UML address the design view of a program so that a developer can conceptually model the software by abstracting implementation details during the development phase. Regarding the reverse engineering phase, class diagrams can also be utilized by software maintainers in the process of understanding the program architecture and capturing domain-level concepts that are embedded in the source code. Today, many UML tools exist in the domain, which have the ability to construct class diagrams directly from source code [2]. Since model elements in these diagrams are straightforwardly recovered from the original source code, they are often called as “as-built” diagrams. However, these diagrams are too detailed to present the high-level, structural view of a program, because implementation details are also captured during the construction. Therefore, there is a need to have methods for building abstract class diagrams so that a reverse engineer can have a better understanding of domain concepts of a given legacy software system. Carey and Gannod proposed an approach that identifies classes in a class diagram that are related to domain concepts by also filtering others which are considered as implementation details [3]. However, their approach primarily focuses on class abstraction, but not on the issues related to UML relationships. On the other hand, Egyed proposed another method with 121 transitive abstraction rules where the main goal is to discover UML relationships among domain-level classes [4]. However, even though Egyed’s rules are complete in terms of coverage, we observed several semantic inconsistencies that cause ambiguities in abstracted class diagrams. As a result, we can claim the following statement. Thesis Statement: An ontology of a legacy software system can be constructed if and only if domain-level classes that are embedded into the program source code are identified and semantically valid relationships among them are captured. 1 In this work, we first analyze the semantics of each transitive abstraction