1. A Case Study in Using ACL2 for Feature-Oriented Verification Kathi Fisler and Brian Roberts WPI Computer Science

2. Configurations of Features decrypt encrypt auto-respond filter signing forward verify signature mailhost remail addressbook [Hall, 2000]

3. Feature-Oriented Design Modules encapsulate features, not objects Command loop User Pref Database Incoming Messages Outgoing Messages auto-reply set-msg, enable response check/send reply encryption set-key, enable key check encrypted encrypt message Components FeaturesFeatures

4. Feature-Rich Systems Telecommunications industry Telecommunications industry NASA’s next-generation software base NASA’s next-generation software base Symbian Symbian Aspects Aspects Still greatly lacking in verification tools

5. Verification Challenges Exponential number of possible products! Exponential number of possible products! –verify individual features once –verify compositions cheaply Feature interactions Feature interactions –does voice mail always engage after 4 rings? Features can share data Features can share data

6. The Case Study Model an email system with four features Model an email system with four features –Host/postmaster (report unknown users) –Auto-response (aka vacation) –Encryption –Decryption Determine lemmas to modularly Determine lemmas to modularly –prove properties of individual features –confirm properties and detect interactions

7. A Basic Email System simulate-network (hostenv, userenv, actions) do-actions (…)do-mail

8. Modeling Features One function for each extension to the system add new actions add new actions add user info add user info add processing on incoming messages add processing on incoming messages add processing on outgoing messages add processing on outgoing messages Command loop User Pref Database Incoming Messages Outgoing Messages auto-reply set-msg, enable response check/send reply encryption set-key, enable key check encrypted encrypt message

9. A Basic Email System simulate-network (hostenv, userenv, actions) do-actions (…)do-mail do-initdo-senddo-deliverdo-command email-auto-initemail-auto-incoming …… host-incoming

10. Customizing Products (defconst *features-present* '(auto encrypt)) (defund do-init (user) (let-seq user (let-seq user (fif encrypt (email-encrypt-init user) user) (fif encrypt (email-encrypt-init user) user) (fif decrypt (email-decrypt-init user) user) (fif decrypt (email-decrypt-init user) user) (fif auto (email-auto-init user) user) (fif auto (email-auto-init user) user) user)) user))

11. Verifying Features Needs –init and -incoming functions Needs –init and -incoming functions Verify against product containing base system and auto-response feature Verify against product containing base system and auto-response feature –theorem refers to simulate-network –not really modular If user has auto-response enabled and sender not in prev-recip list, send message

12. Lightweight Product Verification Add host to product with auto-response: prove auto-response property still holds build (new) product including host feature build (new) product including host feature prove simulate-network theorem again prove simulate-network theorem again Lightweight means proof shouldn’t require unanticipated lemmas Ideally warn of likely feature interactions

13. Detecting Feature Interactions Sample interaction: Sample interaction: Auto-reply message sent to postmaster Often violates no properties of features Often violates no properties of features Incompleteness makes more difficult Incompleteness makes more difficult Capture interaction as theorem, determine lemmas needed to confirm Capture interaction as theorem, determine lemmas needed to confirm –Hope: failure to prove under lemmas indicates likely interaction

14. Supporting Modular Verification Lemmas about individual features crucial Lemmas about individual features crucial –make product verification lightweight –help detect feature interactions Four kinds of lemmas helpful Four kinds of lemmas helpful –type/format of inputs and outputs –environment info that might/won’t change –conditions characterizing changes –lifting lemmas through call-graph hierarchy Ideally automate lemma creation Ideally automate lemma creation

15. Why Modularity? Reviewer: modularity irrelevant for ACL2 We disagree modularity key part of design process modularity key part of design process features provide new form of modularity features provide new form of modularity Research goal goes beyond ACL2 Research goal goes beyond ACL2

16. Reflections on ACL2 Procedural-style natural match for features Procedural-style natural match for features –features capture functional/behavioral information First-order limitation inhibits plug-and-play First-order limitation inhibits plug-and-play –Implementations use higher-order functions/classes Macros crucial Macros crucial –generate products and standard lemmas Books too restrictive for some feature lemmas Books too restrictive for some feature lemmas Hands-off and disable hints simulate modular environment Hands-off and disable hints simulate modular environment

17. Questions for Experts Better way to achieve plug-and-play? Better way to achieve plug-and-play? Way to use books for all feature lemmas? Way to use books for all feature lemmas? Results on lemma generation that we should know about? Results on lemma generation that we should know about?