RoleBased Exploration of ObjectOriented 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 PredicatesSet 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
Examples of Employees Playing Developer and
Salesperson Roles
12
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
SalesPerson
Developer
SalesPerson
developer
salesperson
developer
salesperson
Employee
Employee
Employee

• Employees can migrate through careers
• Roles can capture these changes of an objects
  referencing state and of the functional
  constraints placed on the object

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
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 ltc,fgt
• 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.go
• For key methods m and parameters n
• Pm,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

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
elementData
manages
Class java.lang.Vector

• 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

25
Roles and Functional Properties
26
Role Transition Diagram
Initial Employee
developer Employee
salesperson Employee
this arg of Developer.ltinitgt
this arg of SalesPerson.ltinitgt
this arg of assignEmployees
developer Employee w/ manages
this arg of assignEmployees
this arg of SalesPerson.ltinitgt
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.ltinitgt
this arg of SalesPerson.ltinitgt
this arg of assignEmployees
developer Employee w/ manages
this arg of assignEmployees
this arg of SalesPerson.ltinitgt
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.ltinitgt(Developer, Employee)
• Calling Context
• (InitialDeveloper, InitialEmployee)
• Return Context
• (Developer,
• developer Employee)
• Role Changes
• InitialDeveloper -gt Developer
• InitialEmployee -gt 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 salesperson Employee w/ manages
developer Employee w/ manages
Developer
developer
developer
developer salesperson Employee
36
Role Description

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

manages
Developer.developer
37
Role Description

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

Employee
manages
Developer.developer
38
Role Transition Diagram
Initial Employee
developer Employee
salesperson Employee
this arg of Developer.ltinitgt
this arg of SalesPerson.ltinitgt
this arg of assignEmployees
developer Employee w/ manages
this arg of assignEmployees
this arg of SalesPerson.ltinitgt
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.ltinitgt
this arg of SalesPerson.ltinitgt
this arg of assignEmployees
developer Employee w/ manages
this arg of assignEmployees
this arg of SalesPerson.ltinitgt
salesperson Employee w/ manages
salesperson Employee w/ manages
developer salesperson Employee
restructureCompany
this arg of assignEmployees
developer salesperson w/ manages
40
Role Description

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

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 developers 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
Developer
SalesPerson
46
Multiple Object Data Structures
Employee
manages
Developer
Developer
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
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
51
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
52
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
53
Role Transition Diagram for Socket
Initial Socket
Socket
ServerSocket
Socket w/ address
ServerSocket w/fd
this arg of bind
Garbage
Socket w/fd
bound ServerSocket
this arg of listen
Socket w/o output
Socket w/ input
listening ServerSocket
Socket w/o fd
Socket w/ output
54
Jess
55
Role Transition Diagram
InitialLengthNode
this arg of Node1.ltinitgt this arg of
LengthNode.ltinitgt, this arg of Node.ltinitgt
LengthNode w/ successor engine
1st arg of Successor.ltinitgt
node LengthNode
this arg of Node.freeze
LengthNode w/ successorArray
Jess.run_jess
Garbage
56
Role Description

• Role node LengthNode satisfies
• Class LengthNode
• Heap Aliases Successor.node
• Non-null Fields engine, successor

PLengthNode(o) T PSuccessor.node(o)
T Pengine(o) T Psuccessor(o) T
engine
Successor.node
successor
57
Role Description

• Role LengthNode w/ successorArray satisfies
• Class LengthNode
• Heap Aliases Successor.node
• Non-null Fields engine, successorArray

PLengthNode(o) T PSuccessor.node(o)
T Pengine(o) T PsuccessorArray(o) T
engine
Successor.node
successorArray
58
Jess

• Most nodes have exactly one Successor object
  referring to them

Successor.node

• The MergeNode class has exactly two Successor
  objects referring to it

Successor.node
Successor.node

• No other kinds of nodes

59
Direct-To
60
Role Transition Diagram for Flight
Flight w/ fPlan
Initial Flight
Flight w/ flightID
Flight w/ track
Flight in flightlist
Flight w/ trajectory with nextFix
Flight w/ aircraftType
Flight w/ trajectory
Flight w/ flightType
61
Role Transition Diagram for Flight
Flight w/ fPlan
Initial Flight
Flight w/ flightID
Flight w/ track
Flight in flightlist
Flight w/ trajectory with nextFix
Flight w/ aircraftType
Flight w/ trajectory
Flight w/ flightType
62
Role Transition Diagram for Flight
Flight w/ fPlan
Initial Flight
Flight w/ flightID
Flight w/ track
Flight in flightlist
Flight w/ trajectory with nextFix
Flight w/ aircraftType
Flight w/ trajectory
Flight w/ flightType
63
Role Transition Diagram for Point4d
Initial Point4d
Velocity.vector Point4d
currentPos Point4d
Track.pos Point4d
Point4d in array
Garbage
64
Role Transition Diagram for Point4d
Initial Point4d
Velocity.vector Point4d
currentPos Point4d
Track.pos Point4d
Point4d in array
Garbage
65
Role Transition Diagram for Point4d
Initial Point4d
Velocity.vector Point4d
currentPos Point4d
Track.pos Point4d
Point4d in array
Garbage
66
Role Transition Diagram for Point4d
Initial Point4d
Velocity.vector Point4d
currentPos Point4d
Track.pos 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 (DSouza 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