High-Level Views in Object-Oriented Software using Formal Concept Analysis

1. P P Abstract Z Z C C B D B D High-Level Views in Object-Oriented Software using Formal Concept Analysis Gabriela B. Arévalo LIRMM - Séminaire D’OC - 9/02/06

2. Who I am … • 1999: Licenciatura en Informática Universidad Nacional de La Plata, Argentina • 2000: Master in the EMOOSE Program Ecole des Mines de Nantes (France) and Vrije Universiteit Brussels (Belgium) • 2005: Ph.D. in Computer Science Universitaet Bern (Switzerland) • 2006: Postdoc in LIRMM Université de Montpellier (France) • From 1995 - … Research and Teaching Assistant in different research groups. Séminaire D'OC

3. B C D B C P Abstract Z Abstract Z Abstract Z Roadmap • Dependencies in Maintenance of Object Oriented Systems • Goals of the Approach • Introduction to Formal Concept Analysis • High-Level Views • Achievement of Goals and Conclusions Séminaire D'OC

4. 50% - 75 % Maintenance of Software Systems • Software System: Laws of Continuing Change and Increasing Complexity • Maintenance of software systems • 50% to 75 % of the total cost • Reading and Analysis of Software: • ½ time of maintenance phase • We need to detect Implicit Contracts between software components in a system 50% Séminaire D'OC

5. ? H A The system is like a puzzle • No precise and updated documentation • Pieces have no order at all • Structure is not obvious Partial Information Working System Séminaire D'OC

6. Dynamic Binding Reuse Delegation Inheritance Polymorphism Data Encapsulation Dependencies in Object Oriented Systems • Dependency is the glue between the objects • Explicit Dependency: • Direct inheritance relationship between two classes • Implicit Dependency: • Method lookup in a chain of superclasses • Appear several times • Do not appear isolated • Can appear at different abstraction levels Séminaire D'OC

7. P P Abstract Z Z C C B D B D High-Level Views based on Formal Concept Analysis (FCA) High Level Views Formal Concept Analysis as a base tool Object Oriented Systems Séminaire D'OC

8. ? H A Goals of High-Level Views (1/2) • How can we detect implicit unanticipated dependencies ? • How can we discover defects introduced in the systems • How can we discover recurring situations (patterns-like) of dependencies ? • Is the mental model with high-level views meaningful enough to understand the system? Séminaire D'OC

9. ? H A Goals of High-Level Views (2/2) • Is FCA an easy-to-use clustering technique ? • Is FCA scalable ? • Is there any limit in the use of the technique ? • Is the interpretation of the results an automatic process ? Séminaire D'OC

10. {Oscar, Stephane, Giuliano}, {Patterns} {Oscar, Stephane}, {Traits, Patterns} {Giuliano}, {Patterns, FCA, RE} Formal Concept Analysis in a Nutshell PROPERTIES ELEMENTS Lattice: Partial Order Top Top Less Elements More Properties More Elements Less Properties Bottom Bottom Séminaire D'OC

11. High Level Views Interpretation = = = Meaningful Concepts Concept Lattice Analysis Post-Filtering FCA Mapping ConAn Engine Model Import Modelling Elements and Properties Magnitude isAbstract Magnitude <self send = ….. > < = Magnitude Integer Source code model Inheritance Our Methodology < Source Code Séminaire D'OC

12. B C D B C P Abstract Z Abstract Z Abstract Z High Level Views XRay Views: Class Level Hierarchy Schemas: Class Hierarchy Level Collaboration Patterns: Application Level Séminaire D'OC

13. B C D B C P Abstract Z Abstract Z Abstract Z High Level Views • Which methods access attributes ? • Which methods are used internally ? • Which methods are heavily used ? • How methods and attributes collaborate ? XRay Views: Class Level Hierarchy Schemas: Class Hierarchy Level Collaboration Patterns: Application Level Séminaire D'OC

14. (m1,m2), (a,b) (m1,m3,m6), (d) (m1), (a,b,d) Abstract Z Formal Concept Analysis on Classes Properties: Access to instance variables Top Elements: methods Bottom Class A Analysis of Accesses to State a, b, c, d, e m1() { .. a .. b .. d } m2() { .. a .. b .. e } Séminaire D'OC

15. Exclusive Accessors Abstract Z Collaborating Attributes Collaborating Methods Interface X-Ray Views on Classes X-Ray View is a set of collaborations to show patterns based on the state and behavior Ordered Collection representBinaryOn: before removeFirst addFirst: firstIndex lastIndex addLast: add:after: add: notEmpty: includes: at:put: changeSizeTo: Séminaire D'OC

16. Abstract Z • XRay View: State Usage • State of the class is not exposed to the clients • Naming conventions in the methods • Cohesive Collaboration • 20 of 56 methods access systematically all the state Validation: Case Studies • State Usage • External/Internal Calls • Behavioral Skeleton XRay Views Séminaire D'OC

17. Wrap-up on XRay Views • XRay Views • Use of FCA • Compact Representation of the data • Partial Information of the Concepts • Meaningless Concepts (concepts with only one property) • Overlapping of Information • Opportunistic Code Reading • Class Functionality • Class as a sole development unit Séminaire D'OC

18. B C D B C P Abstract Z Abstract Z Abstract Z High Level Views • Which classes define and use their own state ? • Which classes uses state defined in superclasses ? • Which classes reuse or extend behavior of their superclasses ? XRay Views: Class Level Hierarchy Schemas: Class Hierarchy Level Collaboration Patterns: Application Level Séminaire D'OC

19. B define m2 and C defines m4 (abstract in A) A m3 { .... } m2 {<abstract>} m4 {<abstract>} B and C calls m3 defined in A via a super call • B and C have a similar structure C B m1 { ... } m4 { ... } ... { self m1 } ... { self m4 } ... { super m3 } m1 { ... } m2 { ... } ... { self m1 } ... { super m3 } Hierarchy Schemas Séminaire D'OC

20. Formal Concept Analysis on Class Hierarchies Type of calls – Definer Class A m3 { .... } m2 {<abstract>} m4 {<abstract>} invocations • Elements: Invocations • Properties: type of calls and hierarchical relationships with definer class C B m1 { ... } m2 { ... } ... { self m1 } ... { super m3 } m1 { ... } m4 { ... } ... { self m1 } ... { self m4 } ... { super m3 } Séminaire D'OC

21. OrderedCollection add: { .. self addLast: .. } addLast: { <concrete> } Sorted Collection addLast: { <cancelled> } FontDescriptionBundle addLast: { <concrete> } Discovering Bad Smell Schema: Cancelled Behavior • Concrete local or inherited methods • Via-self call • Cancelled in subclasses. • Method cancellation: code reuse without regarding for subtyping. • Calling cancelled methods can provoke runtime errors Séminaire D'OC

22. Validation: Case Study • Class: Collection • Essential part of Smalltalk & Heavy use of subclassing • 104 classes in 8 levels of inheritance • 2162 defined methods • 3117 invocations • 1146 accesses to state • Classical • Reuse of superclass behavior (111 instances) • Bad Smell • Cancelled Local or Inherited Behavior (6 instances) • Irregularities • Inherited and Local Invocations (15 instances) Séminaire D'OC

23. Wrap-up on Hierarchy Schemas • Hierarchy Schemas: • Analysis of State and Behavior • Identify irregularities and bad smell schemas • Main constraints of a class in a class hierarchy • Use of FCA • Performance of the Algorithm • Partial Usage of Lattice • Mapping from Concepts to Schemas • Filtered out non-invoked methods Séminaire D'OC

24. D B C P B C Abstract Z Abstract Z Abstract Z High Level Views XRay Views: Class Level • Are known design patterns implemented in a system ? • Can we discover new patterns ? • Do they occur several times ? Hierarchy Schemas: Class Hierarchy Level Collaboration Patterns: Application Level Séminaire D'OC

25. Collaboration Patterns Abstract X P Z Y Abstract A T C B Collaboration Patterns: Common structural aspects between classes D Séminaire D'OC

26. (1,2)Subclass (3,2)Subclass (2)Abstract (3,2)Accesses 2 A X = , 1 3 C P Z Y Formal Concept Analysis on Object-Oriented Applications Properties: Relationships between classes 2 A Elements: Tuples of classes C P 1 3 Séminaire D'OC

27. A A A A Selected Collaboration Patterns Attribute Star Attribute Chain A Tuple: 3 Classes A Tuple: 3 Classes 4 Classes Tuple: 4 Classes Composite Bridge A A Tuple: 3 classes 4 Classes Tuple: 3 Classes 4 Classes Séminaire D'OC

28. Validation: Case Studies • ADvance: multidimensional OOAD-tool (www.io.com/~icc) • CodeCrawler: language independent software visualization tool (www.iam.unibe.ch/~scg) Séminaire D'OC

29. Evaluation of Results • Classes as Center of Systems • CodeCrawler: CCTool is in none of patterns • CCNodePlugin is in 47 patterns up to order = 4 • Identify candidates of design patterns • Advance: 6 instances of Composite, 37 instances of Bridge • CodeCrawler: 19 instances of Bridge • Coding Styles: frequency of some patterns • CodeCrawler: heavy use of Attribute Star and Façade • Advance: Composite Séminaire D'OC

30. Wrap-up on Collaboration Patterns • Collaboration Patterns • Detect class dependencies • Detect presence of classical design patterns • Mining Patterns • Understand class roles • Identify Coding Styles • Use of FCA • Performance of Algorithm • Meaningless concepts • Multiple Contexts • Mapping Partial Order Séminaire D'OC

31. We achieved the goals ... • High-Level Views • Development of a general methodology • Detected Implicit Dependencies with FCA • Discovered defects in the system • Discovered patterns • Metamodel Information • Use of FCA [ICFCA `05] • Modelling software entities as FCA components • Performance of FCA algorithms • Interpretation of Concepts • Use of Complete Lattice • Use of Partial Order Séminaire D'OC

32. A good application of FCA …. • High-level Views: XRay Views, Hierarchy Schemas, Collaboration Patterns • Development of a methodology • Tool support of the Methodology: ConAn • Analysis of advantages and constraints • Interpretation without any mathematical knowlege Séminaire D'OC