RoleBased Design Discovery for ObjectOriented Programs

1
Role-Based Design Discovery for Object-Oriented
Programs

• Brian Demsky and Martin Rinard
• MIT Laboratory for Computer Science

2
goal

• Extract design information for program
• Object models
• Related abstractions
• How object states change in response to program
  actions
• Assumptions program actions make about object
  states
• Key challenges
• synthesizing meaningful set of object states
• mapping objects into sets
• relating object states to program actions
• presenting information to developer

3
basic approach
Instrument using FLEX compiler
Program
Instrumented Binary
Execute Binary
Trace of heap operations
Analysis
Synthesize set of object states
Store referencing relationships between states
Relate states to program actions
4
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

5
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
6
choosing predicates

• Predicates capture aspects of roles that objects
  might play
• 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 strategies are designed to represent

7
direct-to prototype

• ATC tool
• Helps controllers understand implications of
  shortcuts
• Also used to resolve conflicts on default routes
• Prototype developed at MIT
• Java implementation
• Cristian Cadar, Tudor Leu
• Start with Point4d objects

8
example of point4d objects used as tracks,
trajectories, and velocities
9
heap alias predicates

• Designed to classify objects based on data
  structure participation
• Captures if a given field of a given class points
  to the object
• Formal Predicate
• Pc.f(o) is true if an instance of c has a field f
  that refers to o

10
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 field 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

11
how this information is useful

• Structural Constraints a Point4d object used as
  a velocity should never be used as a position
• Functional Constraints the program actions that
  are allowed on a Point4d object may depend on its
  role
• Program may only perform a scalar multiplication
  by time on Point4d objects with a velocity role
• Program may only plot Point4d objects on a radar
  screen if that object is used as part of a
  position

12
extracted information
13
role transition diagram for point4d
Initial Point4d
vector Point4d
pos Point4d
Point4d in array
Garbage
14
role transition diagram for point4d
Initial Point4d
1st argument of Track initializer
vector Point4d
pos Point4d
Point4d in array
Garbage
15
role transition diagram for point4d
Initial Point4d
vector Point4d
pos Point4d
Point4d in array
Garbage
16
role transition diagram for point4d
Initial Point4d
vector Point4d
pos Point4d
Point4d in array
Garbage
17
role transition diagram for point4d
Initial Point4d
vector Point4d
pos Point4d
Point4d in array
Garbage
18
role relationship diagram for point4d
Object array
Initial Point4d
Point4d in array
Track w/ vel pos
track Track w/ vel pos
vel
vel
pos
vel Velocity w/ vector
pos
vector
pos Point4d
vector Point4d
19
role relationship diagram for point4d
Object array
Initial Point4d
Point4d in array
Track w/ vel pos
track Track w/ vel pos
vel
vel
pos
vel Velocity w/ vector
pos
vector
pos Point4d
vector Point4d
20
interactive support

• Graphical web-based interface
• Diagrams and navigation
• Role transition diagrams for each class
• A role relationship diagram
• Links to the appropriate role descriptions

21
role relationship diagram for point4d
Object array
Initial Point4d
Point4d in array
Track w/ vel pos
track Track w/ vel pos
vel
vel
pos
vel Velocity w/ vector
pos
vector
pos Point4d
vector Point4d
22
role relationship diagram for point4d
Object array
Initial Point4d
Point4d in array
Track w/ vel pos
track Track w/ vel pos
vel
vel
pos
vel Velocity w/ vector
pos
vector
pos Point4d
vector Point4d
vector Point4d
23
role description

• Role vector Point4d satisfies
• Class Point4d
• Heap Aliases Velocity.vector

Velocity.vector
24
role description

• Role vector Point4d satisfies
• Class Point4d
• Heap Aliases Velocity.vector

Point4d
Velocity.vector
25
role transition diagram for point4d
Initial Point4d
vector Point4d
pos Point4d
Point4d in array
Garbage
26
role transition diagram for point4d
Initial Point4d
vector Point4d
pos Point4d
Point4d in array
pos Point4d
Garbage
27
role description

• Role pos Point4d satisfies
• Class Point4d
• Heap Aliases Track.pos

Track.pos
28
extensions
29
role subspaces

• Need for multiple design views
• Different levels of detail relevant for different
  tasks
• Different parts of design relevant for different
  tasks
• Role subspaces
• Manage application of role separation predicates
• Role subspace uses subset of role separation
  criteria
• Can work with multiple role subspaces
  simultaneously

30
multiple object data structures
Trajectory
p
ArrayList
Array
Point4d
Point4d
Point4d
Point4d
31
multiple object data structures
Trajectory
p
Point4d
Point4d
Point4d
Point4d
32
customization

• Need to customize presentation of information
• Quickly explore multiple aspects of a programs
  behavior
• Easily focus on interesting aspects
• Our web-based interface allows the developer to
• Navigate through linked diagrams
• Manage role subspaces
• Create new subspaces
• Combine subspaces

33
direct-to
34
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
35
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
36
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
37
other benchmarks

• JhttpServer
• PlainSocketImpl class has two different purposes
• Each different purpose has a distinct usage
  pattern
• Jess
• Discovered and understood graph freezing
  optimization
• Discovered two different structures of nodes

38
lessons learned

• Role transition diagrams were useful for
  understanding the relation between the states of
  objects and program actions
• Role relationship diagrams were useful for
  understanding the relations between objects
• Managing complexity and abstraction is critical
  for design extraction tools

39
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

40
Dynamic Conformance Checking and Enforcement

• Brian Demsky and Martin Rinard
• MIT Laboratory for Computer Science

41
introduction

• Developers express design information using
  object model
• Specify a translation from data structures to
  model
• Tool processes translation specification and
  object model
• Checks that data structures conform to design
• Enforces constraints from object model

42
architecture
Broken Abstract Model
Repaired Abstract Model
Design Constraints
External Consistency Properties
Model Definition Translation
Broken Bits
1011100110001111011 1010101011110011101 1010111000
111101110
1010011110001111011 1010110101110011010 1010111011
001100010
Repaired Bits
43
architecture rationale

• Why go through the abstract model?
• Simple, uniform structure
• Sets of objects
• Relations between objects
• Simplifies both
• Expression of consistency properties
• Design enforcement algorithm
• Enables system to support full range of
  efficient, heavily encoded data structures

44
file system example
abst
intro

0
2
1

-5

1

-1
Directory Entries
Disk Blocks
struct Disk Entry dirNumEntries Block
blockNumBlocks Disk D

• struct Entry
• byte nameLength
• int firstBlock
• struct Block
• int nextBlock
• data byteBlockSize

45
model definition

• Sets of objects
• set blocks of integer partition used free
• Relations between objects values of object
  fields, referencing relationships between objects
• relation next used, used

blocks
used
free
next
46
model translation

• Bits translated to sets and relations in abstract
  model using statements of the form
• Quantifiers, Condition ? Inclusion Constraint
• for i in 0..NumEntries, 0 ? D.diri.firstBlock
  and
• D.diri.firstBlock lt NumBlocks ?
• D.diri.firstBlock in used
• for b in used, 0 ? D.blockb.nextBlock and
  D.blockb.nextBlock lt NumBlocks ?
  ?b,D.blockb.nextBlock? in next
• for ?b,n? in next, true ? n in used
• for b in 0..NumBlocks, not (b in used) ? b in free

47
model in example
abst
intro

0
2
1

-5

1

-1
Directory Entries
Disk Blocks
blocks
used
0
next
free
1
3
next
2
48
design constraints

• Quantifiers, Body
• Body is first-order property of basic
  propositions
• Inequality constraints on values of numeric
  fields
• V.R E, V.R lt E, V.R ? E, V.R ? E, V.R gt E
• Presence of required number of objects
• size(S) C, size(S) ? C, size(S) ? C
• Topology of region surrounding each object
• size(V.R) C, size(V.R) ? C, size(V.R) ? C
• size(R.V) C, size(R.V) ? C, size(R.V) ? C
• Inclusion constraints V in S, V1 in V2.R,
  ?V1,V2? in R
• Example for b in used, size(next.b) ? 1

49
design constraint violations

• Evaluate consistency properties, find violations
• for b in used, size(next.b) ? 1 is false for b 1

blocks
used
0
next
free
1
3
next
2
50
enforcing design constraints

• Violation provides binding for quantified
  variables
• Convert Body to disjunctive normal form
• (p1 ? ? pn ) ? ? (q1 ? ? qm )
• p1 pn , q1 qm are basic propositions
• Choose a conjunction to satisfy
• Repair violated basic propositions in conjunction

51
satisfying basic propositions

• Inequality constraints on values of numeric
  fields
• V.R E, V.R lt E, V.R ? E, V.R ? E, V.R gt E
• Compute value of expression, assign field
• Presence of required number of objects
• size(S) C, size(S) ? C, size(S) ? C
• Remove or insert objects from/to set
• Topology of region surrounding each object
• size(V.R) C, size(V.R) ? C, size(V.R) ? C
• size(R.V) C, size(R.V) ? C, size(R.V) ? C
• Remove or insert pairs from/to relation
• Inclusion constraints V in S, V1 in V2.R,
  ?V1,V2? in R
• Remove or add the object or pair from/to set or
• relation

52
design enforcement in example
for b in used, size(next.b) ? 1 is false for b
1 Must repair size(next.1) ? 1 Can remove either
?0,1? or ?2,1? from next
blocks
used
0
next
free
1
3
next
2
53
design enforcement in example
for b in used, size(next.b) ? 1 is false for b
1 Must repair size(next.1) ? 1 Can remove either
?0,1? or ?2,1? from next
blocks
used
0
next
free
1
3
2
54
external consistency constraints

• Quantifiers, Condition ? Body
• Body of form V E, V.F E, V.FI E
• Example
• for b in free, true ? D.blockb.nextBlock -2
• for ?i,j? in next, true ? D.blocki.nextBlock
  j
• for b in used, size(b.next) 0 ?
  D.blockb.nextBlock -1
• Repair simply performs assignments
• Translates model repairs to bit repairs

55
design enforcement in example
Inconsistent File System
Repaired File System
56
when to check for design conformance

• Persistent data structures
• checking can be independent activity, or
• checking performed when data written out or read
  in
• Volatile data structures in running program
• Under programmer control
• Transaction-based approach
• Identify transaction start and end
• Checking at start, end, or both
• Failure-based approach
• Wait until program fails
• Design enforced and restart from latest safe point

57
experience

• CTAS (air-traffic control tool)
• We developed a partial specification for CTAS
• Very little development time (days, not weeks)
• Inserted errors into implementation
• Ran CTAS with and without design enforcement

58
CTAS

• Set of air-traffic control tools
• Traffic management
• Arrival planning
• Flow visualization
• Shortcut planning
• Deployed in centers around country (Dallas/Ft.
  Worth, Los Angeles, Denver, Miami,
  Minneapolis/St. Paul, Atlanta, Oakland)
• Approximately 1 million lines of C/C code

59
CTAS screen shot
60
results

• Workload recorded radar feed from DFW
• Fault insertion
• Simulate error in flight plan processing
• Bad airport index in flight plan data structure
• Without design enforcement
• System crashes segmentation fault
• With design enforcement
• Aircraft has different origin or destination
• System continues to execute
• Anomaly eventually flushed from system

61
aspects of CTAS

• Lots of independent subcomputations
• System processes hundreds of aircraft problem
  with one should not affect others
• Multipurpose system (visualization, arrival
  planning, shortcuts, ) problem in one purpose
  should not affect others
• Sliding time window anomalies eventually flushed
• Rebooting ineffective system will crash again
  as soon as it sees the problematic flight plan

62
what we learned

• Dynamic design conformance allows the developer
  to find discrepancies between a program and its
  design
• Design enforcement was effective in improving the
  reliability of our benchmarks
• Believe that design enforcement is a way to
  improve the reliability of programs

63
where we are going

• Expressing different types of constraints
• Generating a larger class of repairs
• Compiling and optimizing design checking
• Gaining more experience using the tool to capture
  design constraints in CTAS and other programs

64
conclusion

• Design enforcement is an interesting way to
  (potentially) improve reliability
• Specification-based approach promises to make
  technique more widely applicable
• Moving towards more robust, probabilistic,
  continuous concept of system behavior

65
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)

66
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)

67
related work

• Hand-coded repair
• Lucent 5ESS switch
• IBM MVS operating system
• Self-stabilizing algorithms
• Log-based recovery for database systems
• Recovery-oriented computing
• Recursive restartability
• Undo framework