1. Role-Based Exploration of 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 State Objects rara rbrb rcrc P 1 (o 1 )=T P 2 (o 1 )=T P 3 (o 1 )=T P 1 (o 2 )=F P 2 (o 2 )=T P 3 (o 2 )=T P 1 (o 3 )=F P 2 (o 3 )=T P 3 (o 3 )=T P 1 (o 4 )=T P 2 (o 4 )=F P 3 (o 4 )=T P 1 (o 5 )=T P 2 (o 5 )=F P 3 (o 5 )=T o1o1 o2o2 o3o3 o4o4 o5o5

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 Employee Salesperson Developer salesperson developer manages

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. Examples of Employees Playing Developer and Salesperson Roles Employee Developer developer Employee SalesPerson salesperson Employee Developer developer Employee SalesPerson salesperson Employee SalesPerson salesperson

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

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

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

15. Role Changes 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 Employee Developer developer Employee SalesPerson salesperson Employee Developer developer SalesPerson salesperson

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

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

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

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

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

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

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 The role name assigned to this role description is: manages Vector w/ 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 manages Vector w/ elementData manages elementData Class: java.lang.Vector

25. Roles and Functional Properties

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

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

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. (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 Employee w/ manages developer & salesperson Employee developer & salesperson Employee w/ manages Developer developer

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

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 Employee w/ manages developer & salesperson Employee developer & salesperson Employee w/ manages Developer developer

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

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

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

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

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

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

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 Role Subspace { Class: Employee Non-null Fields: manages } P Employee (o) P manages (o) P Developer.developer (o) P SalesPerson.salesperson (o)...

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

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

46. Multiple Object Data Structures Employee manages Developer SalesPerson

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 ServerSocket ServerSocket w/fd bound ServerSocket listening ServerSocket Socket Socket w/ address Socket w/fd Socket w/ input Socket w/ output Socket w/o fd Socket w/o output Garbage

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

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

53. Role Transition Diagram for Socket Initial Socket ServerSocket ServerSocket w/fd bound ServerSocket listening ServerSocket Socket Socket w/ address Socket w/fd Socket w/ input Socket w/ output Socket w/o fd Socket w/o output Garbage this arg of bind this arg of listen

54. Jess

55. Role Transition Diagram InitialLengthNode LengthNode w/ successor & engine node LengthNode LengthNode w/ successorArray Garbage 1 st arg of Successor. this arg of Node.freeze Jess.run_jess this arg of Node1. this arg of LengthNode., this arg of Node.

56. Role Description Role node LengthNode satisfies Class: LengthNode Heap Aliases: Successor.node Non-null Fields: engine, successor engine successor Successor.node P LengthNode (o) =T P Successor.node (o) = T P engine (o) = T P successor (o) = T

57. Role Description Role LengthNode w/ successorArray satisfies Class: LengthNode Heap Aliases: Successor.node Non-null Fields: engine, successorArray engine successorArray Successor.node P LengthNode (o) =T P Successor.node (o) = T P engine (o) = T P successorArray (o) = T

58. Jess Most nodes have exactly one Successor object referring to them The MergeNode class has exactly two Successor objects referring to it Successor.node No other kinds of nodes

59. Direct-To

60. Role Transition Diagram for Flight Initial Flight Flight w/ flightID Flight in flightlist Flight w/ aircraftType Flight w/ flightType Flight w/ fPlan Flight w/ track Flight w/ trajectory with nextFix Flight w/ trajectory

61. Role Transition Diagram for Flight Initial Flight Flight w/ flightID Flight in flightlist Flight w/ aircraftType Flight w/ flightType Flight w/ fPlan Flight w/ track Flight w/ trajectory with nextFix Flight w/ trajectory

62. Role Transition Diagram for Flight Initial Flight Flight w/ flightID Flight in flightlist Flight w/ aircraftType Flight w/ flightType Flight w/ fPlan Flight w/ track Flight w/ trajectory with nextFix Flight w/ trajectory

63. Role Transition Diagram for Point4d Initial Point4d Track.pos Point4d Velocity.vector Point4d currentPos Point4d Point4d in array Garbage

64. Role Transition Diagram for Point4d Initial Point4d Track.pos Point4d Velocity.vector Point4d currentPos Point4d Point4d in array Garbage

65. Role Transition Diagram for Point4d Initial Point4d Track.pos Point4d Velocity.vector Point4d currentPos Point4d Point4d in array Garbage

66. Role Transition Diagram for Point4d Initial Point4d Track.pos Point4d Velocity.vector Point4d currentPos Point4d Point4d in array Garbage

67. How is This Useful? Program exploration - to discover The different conceptual roles that objects play Important referencing relationships between objects playing different roles Constraints between roles and actions of program Debugging – to check that the program respects Structural object referencing constraints Functional constraints between actions and object roles Specification generation – to automatically produce models of the program and objects it manipulates Documentation of key properties Starting point for static verification

68. Related Work Design formalisms Object models such as Syntropy (Cook and Daniels ’94) Fusion (Coleman ’93) Catalysis (D’Souza & Wells ’99) Alloy (Jackson ’00) Dream (Riddle, Sayler, Segal, Wileden ’77) Design patterns Role-based conceptual design methods (Jacobs, Fowler, Familiar)

69. Related Work Program understanding tools Algebraic invariants - Daikon (Ernst, Czeisler, Griswold, Notkin ’00) Object model extraction – Womble (Jackson, Waingold ’99) Static analysis Shape Analysis (Sagiv ’97, Hendren ’90) Role Analysis (Kuncak, Lam, Rinard ’02)

70. Conclusion Type systems have been a primary mechanism for capturing object properties Standard systems give each object a single type for its entire lifetime in computation Changing object states underemphasized Our technology focuses on changing states More precise structural properties More precise functional properties Better understanding of the program Goal is to make changing object states a central aspect of software engineering tools