role-based exploration of object-oriented programs brian demsky and martin rinard mit laboratory for...

Role-Based Explorationof Object-Oriented Programs

Brian Demsky and Martin RinardMIT Laboratory for Computer

Science

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

Basic Approach

• Automatically examine execution of program

• Extract information about states and actions

• Graphically and interactively present information

Outline

• Challenges• Example

• Roles and Object States• Extracted Information• Presenting Information to Developer

• Extensions and Customization• Experience• Related Work• Conclusion

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

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

Role Separation Predicates:Set of Predicates

State

Objects

ra rb rc

P1(o1)=TP2(o1)=TP3(o1)=T

P1(o2)=FP2(o2)=TP3(o2)=T

P1(o3)=FP2(o3)=TP3(o3)=T

P1(o4)=TP2(o4)=FP3(o4)=T

P1(o5)=TP2(o5)=FP3(o5)=T

o1 o2 o3 o4 o5

Choosing Predicates

• Each predicate should capture some aspect of some conceptual role that an object might play

• One obvious category of predicatesPredicates 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

Example

Employee

Salesperson Developersalesperson

developer

managesmanages

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?

Examples of Employees Playing Developer and Salesperson

Roles

Employee

Developer

developer

Employee

SalesPerson

salesperson

Employee

Developer

developer

Employee

SalesPerson

salesperson

Employee

SalesPerson

salesperson

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 cExample:

PDeveloper.developer(o) is true if o is a developer

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

More Properties

• Property: Only managers are sent to management training seminars

• How can we identify managers?

Instances of an Employee Playing Managing and Non-

managing Roles

Employee

Vector ofDeveloper &SalesPerson

Employee

manages


Employee

manages


Employee

manages

Employee

Employee

Solution

Non-null field predicates:Capture what references an object has

to other objectsFormal 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

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

Role Description

Role developer Employee w/manages

Class: EmployeeHeap Aliases: Developer.developer, Non-null Fields: manages

managesDeveloper.developer

PEmployee(o) =TPDeveloper.developer(o)=TPmanages(o) = T

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

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

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

managesVector w/

elementData

manages elementData

Class: java.lang.Vector

Roles and Functional Properties

Role Transition DiagramInitial

EmployeedeveloperEmployee

salespersonEmployeethis arg of

Developer.<init>this arg ofSalesPerson.<init>

developerEmployee w/

manages

this arg ofassignEmployees

salesperson Employee w/

managesdeveloper & salespersonEmployee

developer & salesperson w/

manages

this arg ofSalesPerson.<init>



restructureCompany

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

Enhanced Method Interface

Developer.<init>(Developer, Employee)Calling Context:

(InitialDeveloper, InitialEmployee)Return Context:

(Developer, developer Employee)

Role Changes:InitialDeveloper -> DeveloperInitialEmployee -> developer Employee

Structural Properties

Role Relationship Diagram

developerEmployee


manages

developer & salesperson

Employee

developer & salespersonEmployee w/

managesDeveloper

developer

developer

developer

developer

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


developerEmployee


manages


Employee


managesDeveloper

developer

developer

developer

developer


developerEmployee


manages


Employee


managesDeveloper

developer

developer

developer

developer


manages

Role Description

Role developer Employee w/manages satisfiesClass: EmployeeHeap Aliases: Developer.developerNon-null Fields: manages

managesDeveloper.developer

Role developer Employee w/manages satisfiesClass: EmployeeHeap Aliases: Developer.developerNon-null Fields: manages

Role Description

manages

Employee

Developer.developer






manages





manages




restructureCompany






manages





manages




restructureCompany


manages

Role Description

Role salesperson Employee w/manages satisfiesClass: EmployeeHeap Aliases: SalesPerson.salespersonNon-null Fields: manages

SalesPerson.salesperson manages

Extensions

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

Role Subspaces

Role Subspace {

Class: Employee

Non-null Fields: manages

}

PEmployee(o)

Pmanages(o)

PDeveloper.developer(o)

PSalesPerson.salesperson(o).

.

.

Role Transition Diagram

InitialEmployee

Employee w/ manages

this arg of assignEmployee

Multiple Object Data Structures

Employee

manages

Developer Developer

Array

Developer SalesPerson

Vector

Multiple Object Data Structures

Employee

manages

Developer Developer

Developer SalesPerson

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

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

JhttpServer

Role Transition Diagram for SocketInitial 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

Role Transition Diagram for SocketInitial 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

Garbagethis arg of

bind

this arg oflisten

Role Transition Diagram

InitialLengthNode

LengthNode w/ successor & engine

node LengthNode

LengthNode w/ successorArray

Garbage

1st arg of Successor.<init>

this arg of Node.freeze

Jess.run_jess

this arg of Node1.<init>this arg of LengthNode.<init>,this arg of Node.<init>

Role Description

Role node LengthNode satisfiesClass: LengthNodeHeap Aliases: Successor.nodeNon-null Fields: engine, successor

engine

successor

Successor.node

PLengthNode(o) =TPSuccessor.node(o) = TPengine(o) = TPsuccessor(o) = T

Role Description

Role LengthNode w/ successorArray satisfies

Class: LengthNodeHeap Aliases: Successor.nodeNon-null Fields: engine, successorArray

engine

successorArray

Successor.node

PLengthNode(o) =TPSuccessor.node(o) = TPengine(o) = TPsuccessorArray(o) = T

Jess• Most nodes have exactly one Successor

object referring to them

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

Successor.node

Successor.node

Successor.node

• No other kinds of nodes

Direct-To

Role Transition Diagram for Flight

Initial Flight

Flight w/flightID

Flight inflightlist

Flight w/aircraftType

Flight w/flightType

Flight w/fPlan

Flight w/track

Flightw/ trajectory with nextFix

Flightw/ trajectory

Role Transition Diagram for Point4dInitial Point4d

Track.pos Point4d

Velocity.vector Point4d

currentPos Point4d

Point4d in array

Garbage

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

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)

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)

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

role-based exploration of object-oriented programs brian demsky and martin rinard mit laboratory for...

Documents

developer o

developer slide

developer extensions

role slide

present information

object objects

computer science slide

different states of