1. Design-Directed Programming Martin Rinard Daniel Jackson MIT Laboratory for Computer Science

2. Standard Approach Program Analysis Program Program + Information Transformation System Improved Program Software Engineering Tool Information

3. Our Approach Program Analysis Program Program + Relevant, Precise Information Transformation System Program with Intended Behavior Software Engineering Tool Relevant Information and Guarantees Design

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 Functionality (Java Program) Shared Object Space Design (Object Models) Object Referencing Relationships Interactions Between Components Deployment, Failure Responses Program Analysis System (Design Conformance) Program Transformation System (Design Direction) Inserts Code for Distribution, Communication, Reconfiguration Engineer Provides Guarantee that Program Implements Design Transformed Program for Distributed Embedded Systems Engineer Obtains

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 event imagesoundstep pending event store incident log containsrecords involves

16. Data Model Invariants “Different pending event stores are disjoint” all s1, s2 : pending event store | s1 != s2 -> 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 -> 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 event imagesoundstep pending event store incident log containsrecords involves camera controller microphone controller seismic controller event manager manages maintains filtersdetectsidentifies reportsTo controller within component across components log manager notifies

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) -> new i : image in c; see(i : image in c : camera controller) -> i moves to c.reportsTo; c drops i; notice(i : image, s : step in e : event manager) -> i, s moves to e.notifies; e drops i, s; expire(i : incident in l : log manager) -> 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 Design Interpretation Program Analysis System Program Transformation System Design Conformance Design Direction Efficient, Robust Execution

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 Alloy Design Interpretation Java Program Flex Internal Representation + Flex Analysis Abstractions Flex Design Abstractions Flex Program Analysis and Transformation System Code Generator Executable