Rich Interface Theories for Component-based Design Dirk Beyer ┼, Arindam Chakrabarti *, Luca de Alfaro **, Thomas A Henzinger * ┼, Marcin Jurdziński *, Freddy Mang ***, Mariëlle Stoelinga ** ┼ EPFL Lausanne *UC Berkeley **UC Santa Cruz ***Synopsys November 18, 2004 Method availability constraints msg?send! nack? fail! ok!ack? acknacksend msgfailok ack? msg! ok? msgokfail Download Chic 1.1 today !! Chic 1.1 is available as a plug-in for Ptolemy* and JBuilder (* Thanks to Eleftherios Matsikoudis) Composing is a game A winning environment strategy exists if the system is usable in some context. The winning strategy gives the behavior required of the context: Do not provide inputs a,b after outputs x, y respectively. x y aabb a? x,y? 1 a,b? a?b? 2 78 a?b? a? x! y! Node limit = 8 ab interface Abstract data, Local Methods, External Methods, Call assumptions, Abstract local method bodies, Availability constraints Data, method implementations module Methods implemented in this module Methods implemented by the environment Local methods not called transitively Interface states in which a local method is available Software Module Interfaces Resource consumption constraints + a!b? 46 + Node limit = = 10 > Path limit = = = = =22 22>20 (Path limit) Resource Interfaces and Applications Two Synthesis Questions for each class of Resource Interfaces: Strategy Synthesis (e.g. resource scheduler, sensornet routing algorithm): Given a resource bound, how can player Input achieve her objective ? Resource Synthesis (e.g. necessary buffer size, battery capacity): What is the minimum resource requirement so that player Input can achieve her objective ? Game algorithms implemented in Chic can answer both. Two classes of resource interfaces Node Limit Resource Interfaces (e.g. mutex, limited buffer size, limited peak power): Player Input must forever avoid states that exceed the Node Limit. Path Limit Resource Interfaces (e.g. limited battery capacity): Player Input must forever avoid paths that exceed the Path Limit. Motor driver in lego robot 0 stopslowfast 12 fast? slow?stop? slow? fast? stop? slow? fast? A B C D E F G H Value = -9 Resource Synthesis for a Path Limit Game GUI void GUI.paint(G g) not call { GUI.paint } { … } paint calls BUTTON paint void BUTTON.paint(G g) not call { GUI.paint } { … } Call graph constraints Composing is a game msgsend! nack? fail! okack? acknack send ack? Winning environment strategy exists if the system is usable in some context. The winning strategy gives the behavior required of the context: Do not give two nack’s in a row. RadioByte Bug char TOS_COMMAND(RADIO_BYTE_PWR)(char mode){ if(mode == 0){ TOS_CALL_COMMAND(RADIO_SUB_PWR)(0); VAR(state) = 0xff; }else{ TOS_CALL_COMMAND(RADIO_SUB_RX_MODE)(); TOS_CALL_COMMAND(RADIO_SUB_SET_BIT_RATE)(0); VAR(state) = 0; } return 1; } Forgotten call to RADIO_SUB_PWR(1) !! RFM Radio byte Radio Packet UART Serial Packet ADC Tempphoto Active Messages clocks bit byte packet Route map routersensor appln application HW SW Culler et al, ASPLOS 2000 Example: TinyOS Warehouse Transport Service Retail Store Payment Service Customer Vendor Warehouse Vendor Customer Web Service Interfaces and Applications We assume hardware and software platforms never fail, and focus only on problems resulting from service interaction protocol errors. The services are designed and implemented separately, possibly by different companies. However, a system using a set of services has correctness requirements global to the set. E.g. In a web store, Customer must be charged if and only if item is shipped. Any reserved item is eventually released or requested. Specifications can be written in a temporal logic:  ((Payment,FAILURE)  (ShipItem,*)) ( (Payment,SUCCESS))   (ShipItem,SUCCESS)) Our system checks whether a set of services together satisfies a set of correctness requirements.