Role-Based Exploration of Object-Oriented Programs

1. Role-Based Explorationof Object-Oriented Programs Brian Demsky and Martin Rinard MIT Laboratory for Computer Science

2. Research Goal Help developers discover and understand • Different states of objects in computation • Relationships between objects in different states • How states and actions interact • How objects change state in response to program actions • Assumptions that program actions make on the states of accessed objects

3. Basic Approach • Automatically examine execution of program • Extract information about states and actions • Graphically and interactively present information

4. Outline • Challenges • Example • Roles and Object States • Extracted Information • Presenting Information to Developer • Extensions and Customization • Experience • Related Work • Conclusion

5. Challenges Given a program, automatically infer an appropriate set of abstract object states for that program Relate the object states to important structural and functional properties of the program Present this information to the developer

6. Role Separation Predicates • Set of predicates (role separation predicates) • Evaluate predicates on each object • Objects with the same values for the predicates are in the same state • We call each state a role • We say that an object plays its role

7. Role Separation Predicates:Set of Predicates ra rb rc State o1 o2 o3 o4 o5 Objects P1(o1)=T P2(o1)=T P3(o1)=T P1(o2)=F P2(o2)=T P3(o2)=T P1(o3)=F P2(o3)=T P3(o3)=T P1(o4)=T P2(o4)=F P3(o4)=T P1(o5)=T P2(o5)=F P3(o5)=T

8. Choosing Predicates • Each predicate should capture some aspect of some conceptual role that an object might play • One obvious category of predicates Predicates that capture the class of the object • How do we select other predicates? • Examine common information representation strategies • Select predicates that capture the distinctions that these patterns are designed to represent

9. Example Developer Salesperson salesperson developer manages manages Employee

10. Properties • Interesting invariants: • Only an employee who is a salesperson should make a sale • Only an employee who is a developer should check code in to the code base • How can we tell a salesperson from a developer?

11. Developer Developer developer developer Employee Employee SalesPerson SalesPerson SalesPerson salesperson salesperson salesperson Employee Employee Employee Examples of Employees Playing Developer and Salesperson Roles

12. SalesPerson SalesPerson SalesPerson salesperson salesperson salesperson Employee Employee Employee Examples of Employees Playing Developer and Salesperson Roles Developer developer Employee Developer developer Employee

13. Examples of Employees Playing Developer and Salesperson Roles SalesPerson Developer salesperson developer Employee Employee SalesPerson salesperson Employee Developer SalesPerson developer salesperson Employee Employee

14. Solution Heap Alias Predicates: Captures whether a given field of a given class points to object in question Formal Predicate: Pc.f(o) is true if o has a reference from the f field of an instance of class c Example: PDeveloper.developer(o) is true if o is a developer

15. Role Changes Developer Developer SalesPerson SalesPerson • Employees can migrate through careers • Roles can capture these changes of an object’s referencing state and of the functional constraints placed on the object developer salesperson developer salesperson Employee Employee Employee

16. More Properties • Property: Only managers are sent to management training seminars • How can we identify managers?

17. Employee Employee Employee manages manages manages Vector of Developer & SalesPerson Vector of Developer & SalesPerson Vector of Developer & SalesPerson Instances of an Employee Playing Managing and Non-managing Roles Employee Employee Employee

18. Instances of an Employee Playing Managing and Non-managing Roles Employee Employee Employee manages Employee Vector of Developer & SalesPerson Employee Employee manages manages Vector of Developer & SalesPerson Vector of Developer & SalesPerson

19. Solution Non-null field predicates: Capture what references an object has to other objects Formal Predicates: Pg(o) is true if o has the non-null field g, false otherwise Example: Pmanages(o) is true if o is a manager

20. Role Separation Criteria For each class c: Pc(o) = object o has class c For each class and field pair <c,f>: Pc.f(o) = there is a reference to o from the field f of an instance of c For each field g: Pg(o) = object o has a non-null field g For key local and global variables v: Pv(o) = object o is reachable from v For each fields f,g: Pf,g(o) = object o has the cyclic path o.f.g=o For key methods m and parameters n: Pm,n(o)= object o has been parameter n of method m

21. Role developer Employee w/manages Class: Employee Heap Aliases: Developer.developer, Non-null Fields: manages Role Description PEmployee(o) =T PDeveloper.developer(o)=T Pmanages(o) = T Developer.developer manages

22. Dynamic Role Inference • Instrument execution of the program • Run program to generate a trace of heap operations • Dynamically compute • Roles that each object plays • Transitions between roles • Roles of methods’ parameters

23. When Do We Evaluate Roles? • Goal: Evaluate roles when objects have consistent states • Objects are likely to have consistent states at method entry and exit points • By default our tool evaluates the roles of objects at method boundaries • The developer can modify this default policy

24. Role Naming Heuristic manages Vector w/ elementData • The role name assigned to this role description is: manages Vectorw/ elementData • manages refers to the heap alias to the object • Vector is the class name of the object • elementData refers to the non-null field of the object • The tool allows the developer to manually provide more descriptive names for a role, and we have done so in some cases to improve readability elementData manages Class: java.lang.Vector

25. Roles and Functional Properties

26. Role Transition Diagram Initial Employee developer Employee salesperson Employee this arg of Developer.<init> this arg of SalesPerson.<init> this arg of assignEmployees developer Employee w/ manages this arg of assignEmployees this arg of SalesPerson.<init> salesperson Employee w/ manages developer & salesperson Employee restructureCompany this arg of assignEmployees developer & salesperson w/ manages

27. Role Transition Diagram Initial Employee developer Employee salesperson Employee this arg of Developer.<init> this arg of SalesPerson.<init> this arg of assignEmployees developer Employee w/ manages this arg of assignEmployees this arg of SalesPerson.<init> salesperson Employee w/ manages developer & salesperson Employee restructureCompany this arg of assignEmployees developer & salesperson w/ manages

28. Enhanced Method Interfaces • Our tool can generate an enhanced method interface which includes: • the roles of the parameters • the role changes that the method performs • We believe developers will find this sort of information useful for understanding • assumptions that methods make • effects of a method on objects it accesses

29. Enhanced Method Interface Developer.<init>(Developer, Employee) Calling Context: (InitialDeveloper, InitialEmployee) Return Context: (Developer, developer Employee) Role Changes: InitialDeveloper -> Developer InitialEmployee -> developer Employee

30. Structural Properties

31. Role Relationship Diagram developer Employee developer developer developer Employee w/ manages developer & salesperson Employee w/ manages Developer developer developer developer & salesperson Employee

32. Role Relationship Diagram developer Employee developer developer developer & salesperson Employee w/ manages developer Employee w/ manages Developer developer developer developer & salesperson Employee

33. Interactive Support • Our tool uses a graphical web-based interface to communicate inferred properties • The tool presents: • Role transition diagrams for each class • A role relationship diagram • Links from the diagrams to the appropriate • role descriptions • enhanced method interfaces

34. Role Relationship Diagram developer Employee developer developer developer Employee w/ manages developer & salesperson Employee w/ manages Developer developer developer developer & salesperson Employee

35. Role Relationship Diagram developer Employee developer developer developer Employee w/ manages developer Employee w/ manages developer & salesperson Employee w/ manages Developer developer developer developer & salesperson Employee

36. Role developer Employee w/manages satisfies Class: Employee Heap Aliases: Developer.developer Non-null Fields: manages Role Description manages Developer.developer

37. Role developer Employee w/manages satisfies Class: Employee Heap Aliases: Developer.developer Non-null Fields: manages Role Description Employee manages Developer.developer

38. Role Transition Diagram Initial Employee developer Employee salesperson Employee this arg of Developer.<init> this arg of SalesPerson.<init> this arg of assignEmployees developer Employee w/ manages this arg of assignEmployees this arg of SalesPerson.<init> salesperson Employee w/ manages developer & salesperson Employee restructureCompany this arg of assignEmployees developer & salesperson w/ manages

39. Role Transition Diagram Initial Employee developer Employee salesperson Employee this arg of Developer.<init> this arg of SalesPerson.<init> this arg of assignEmployees developer Employee w/ manages this arg of assignEmployees this arg of SalesPerson.<init> salesperson Employee w/ manages salesperson Employee w/ manages developer & salesperson Employee restructureCompany this arg of assignEmployees developer & salesperson w/ manages

40. Role salesperson Employee w/manages satisfies Class: Employee Heap Aliases: SalesPerson.salesperson Non-null Fields: manages Role Description manages SalesPerson.salesperson

41. Extensions

42. Role Subspaces • Different activities require exploration at varying levels of detail • The developer may initially need very coarse information then later explore certain aspects in greater detail • The developer may coarsen aspects of objects orthogonal to the developer’s current interest • Role subspaces provide a means to manage role separation predicates • Developers specify a role subspace by specifying a subset of role separation criteria • Multiple role subspaces can be used simultaneously

43. Role Subspaces PEmployee(o) Pmanages(o) PDeveloper.developer(o) PSalesPerson.salesperson(o) Role Subspace { Class: Employee Non-null Fields: manages } . . .

44. Role Transition Diagram InitialEmployee this arg of assignEmployee Employee w/ manages

45. Multiple Object Data Structures Employee manages Vector Array Developer Developer SalesPerson Developer

46. Multiple Object Data Structures Employee manages Developer Developer SalesPerson Developer

47. Customization • Our web-based interface allows the developer to control the analysis. The developer can: • Define multiple role subspaces • View projections of role transition diagrams and role relationship diagrams onto the defined role subspaces • Declare methods atomic to hide internal role changes • Declare a set of methods to be considered in the method invocation history of objects

48. Experience • We used our tool on a variety of different applications: • JhttpServer – a simple web server • Jess – an expert system shell • Direct-To – an air-traffic control tool

49. JhttpServer

50. Role Transition Diagram for Socket Initial Socket Socket ServerSocket Socket w/ address ServerSocket w/fd Garbage Socket w/fd bound ServerSocket Socket w/o output Socket w/ input listening ServerSocket Socket w/o fd Socket w/ output