Download presentation
Presentation is loading. Please wait.
Published byGabriel Nash Modified over 9 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.