DesignDirected Programming

1
Design-Directed Programming

• Martin Rinard
• Daniel Jackson
• MIT Laboratory for Computer Science

2
Standard Approach
3
Our Approach
Design
Program
Program Analysis
Program Relevant, Precise Information
Transformation System
Software Engineering Tool
Program with Intended Behavior
Relevant Information and Guarantees
4
Application Domain

• Software for distributed embedded systems
• Multiple embedded devices
• All cooperating on same task

5
Software Development Issues

• Basic Functionality
• What computation does the software perform?
• What are relationships between data structures?
• Distribution
• Where does each piece of data reside?
• Where does each piece of software execute?
• Communication
• How do the devices synchronize and exchange data?
• Reconfiguration
• What happens when devices are deployed or fail?

6
Current Approach

• Software Structure Matches Hardware Structure
• Code base for each device
• Code implements functionality for that device
• Code explicitly controls communication,
  distribution, reconfiguration for that device
• Inappropriate Decomposition
• Counterproductive Interactions
• Distribution affects functionality code
• Reconfiguration affects communication code
• Issues cross device boundaries
• Functionality, communication, reconfiguration
  involve multiple devices

7
Our Approach
Engineer Provides
Engineer Obtains
Functionality (Java Program) Shared Object Space
Program Analysis System (Design Conformance)
Guarantee that Program Implements Design
Design (Object Models) Object Referencing
Relationships Interactions Between
Components Deployment, Failure Responses
Program Transformation System (Design
Direction) Inserts Code for Distribution,
Communication, Reconfiguration
Transformed Program for Distributed Embedded
Systems
8
Single Shared Object Space

• Objects distributed and replicated across devices
• Communication implicit in object accesses
• Great for expressing functionality
• Implementation issues
• When does communication take place?
• How do objects flow through system?
• Residual dependences and failures

9
Example
10
Distributed Sensing System

• Cameras

11
Distributed Sensing System

• Cameras
• Microphones

12
Distributed Sensing System

• Cameras
• Microphones
• Seismic Sensors
• Sensors Filter Data
• Generate Events

13
Distributed Sensing System

• Cameras
• Microphones
• Seismic Sensors
• Sensors Filter Data
• Generate Events
• Recorded by Event Processors
• Event Processors Detect Incidents

14
Design

• Data Model
• Objects in system
• Relationships between objects
• Component Model
• Software components of system
• Which relationships cross components
• Action Model
• Communication in response to events

15
Data Model
pending event store
incident log
contains
records
involves
event
incident
image
sound
step
16
Data Model Invariants

• Different pending event stores are disjoint
• all s1, s2 pending event store
• s1 ! s2 -gt no (s1.contains s2.contains)
• Pending event stores and incidents are disjoint
• all s pending event store, i incident
• no (s.contains i.involves)
• Different incidents are disjoint
• all i1, i2 incident
• i1 ! i2 -gt no (i1.involves i2.involves)

17
Design Conformance for Data Models

• Goal
• Check that program references match relations in
  model (including invariants)
• Interpretation of Model

• Model
• Sets (boxes)
• Relations (arrows)

• Program
• Sets of Objects
• References
• Groups of References

18
Data Model Analysis

• Extended form of pointer analysis
• Graph-based abstraction of heap
• Augmented with escape information
• Augmented with property annotations
• Use of design information enables
• Modular, compositional analysis (design
  provides starting context)
• Targeted Analysis
• Appropriate precision and efficiency
• More general semantic relations

19
Component Model

• Basic issues
• Decomposition of System into Software Components
• Distribution of Components onto Devices
• Residence and sharing relationships between
  components and objects
• Failure propagation relationships

20
Component Model
within component
notifies
event manager
log manager
maintains
across components
pending event store
incident log
manages
contains
records
involves
reportsTo
event
incident
image
sound
step
filters
detects
identifies
camera controller
microphone controller
seismic controller
controller
21
Component Interpretations

• Object
• Interpretation
• Relations between components and sets
• Interpreted As
• References between corresponding objects

• Executable Code
• Interpretation
• Component is
• Collection of Software
• Unit of Distribution
• Unit of Instantiation
• Unit of Failure

22
Actions

• acquire(c camera controller) -gt new i image
  in c
• see(i image in c camera controller) -gt
• i moves to c.reportsTo c drops i
• notice(i image, s step in e event manager)
  -gt
• i, s moves to e.notifies e drops i, s
• expire(i incident in l log manager) -gt
• l drops i.involves l drops i

23
Action Interpretation

• Actions
• New Clauses
• Moves to Clauses
• Drops Clauses

• Method Executions
• Object Creations
• Object Transmissions
• Assertions about live references to dropped
  objects

• Implications
• Design Conformance for New and Drops Clauses
• Design Direction for Moves to Clauses

24
Action and Component Models

• Interaction between action model and component
  model
• Component model specifies which references go
  across components
• Actions determine which cross-component
  references are created
• Consistency check between action and component
  models

25
Failure Implications

• Cross component reference from A to B implies
  that A depends on B
• A shares fate with B
• A requires a connection to B
• Analyze consequences of failures
• Residual dependences
• Distributed garbage collection
• Consistency protocols
• Naming

26
System in Operation
Program Analysis System
Design Conformance
Program Transformation System
Efficient, Robust Execution
Design Direction
27
Why This Approach?

• Separates functionality from distribution
• Code is smaller, easier to understand, modify,
  port, and reuse
• Appropriate abstractions for different
  development tasks
• Enables exploitation of design information
• More information for analysis and transformation
  system
• Analysis and transformation system is more
  effective, does more of work
• Can trust design because it is checked

28
Foundations

• MIT Flex System
• For Java in Java (130,000 Lines of Code)
• IR Supports Analyses, Transformations
• Pointer and Escape Analysis
• Event-Driven Transformation
• Standard Analyses (CSE, CP, etc)
• Lots of Tools
• Call Graphs, Visitor Classes, Inliners
• Back Ends - StrongARM, C, Byte Code
• Precise and Conservative GC Support

29
Foundations

• Alloy
• Object Modeling Language
• Expressive, Graphical Sublanguage
• Clean Semantics
• Suitable for analysis and manipulation
• Alloy concepts map well to Java concepts
• Alcoa (Alloy Constraint Analyzer)
• Model Checking of Alloy Models

30
System Structure
Interpretation
Flex Internal Representation Flex
Analysis Abstractions
Flex Design Abstractions
Alloy Design
Java Program
Code Generator
Flex Program Analysis and Transformation System
Executable