1. Model Checking Publish-Subscribe Software Architectures David Garlan Carnegie Mellon University

2. Carnegie Mellon: The Rare Glitch Project2David Garlan Research Approach Specification and analysis of software architectures  Components and their interactions  Architectural styles (e.g., client-server, pipe-filter, publish-subscribe)  Architectural frameworks (e.g. for specific domains and product lines) Why?  Architectural design is a critical design artifact  Can explore system properties before implementation  A good level of abstraction for reasoning about system properties -- especially quality attributes  State of arch practice is informal - needs formalism  Amortized effort when architecture used by many systems

3. Carnegie Mellon: The Rare Glitch Project3David Garlan Specific Thrusts Past research  Specification languages for software architecture Wright -- based on CSP  Analysis of specific architectural frameworks High-level architecture for distributed simulation Enterprise JavaBeans JavaPhone  Tools for software architects Current research  Specification and analysis of publish-subscribe software architectures (today’s talk)  Compositional mechanisms for component interactions  Self-configuring systems

4. Carnegie Mellon: The Rare Glitch Project4David Garlan Publish-Subscribe Architectures An architectural style  components: objects, processes, functions  connectors: event registration  computational model: event announcement triggers invocation of the zero or more methods/tasks that are registered for that event Features  Anonymous multi-cast supports decoupling between components Hence easy to modify and maintain  Widely used UIs, Prog envts, JavaBeans, Visual Basic, JINI, CORBA, robots  Many variants synch/asynch, dispatch policies, concurrency, shared state

5. Carnegie Mellon: The Rare Glitch Project5David Garlan Examples Set-Counter  Set (S) has operations insert/delete  Counter (C) has operations inc/dec  Establish “invariant” |S| = C Distributed Simulation (HLA)  Arbitrary number of simulations publish values of objects that they simulate  Run-time infrastructure (RTI) maintains state (e.g., ownership of objects), mediates protocols of interaction  Many invariants (e.g., each object is owned by a single simulation) SetCounter Sim 1 Sim n … RTI

6. Carnegie Mellon: The Rare Glitch Project6David Garlan More Examples (State-based duals) Shared-variable triggered systems  Aka “continuous query” systems  State changes trigger computations  Components read/write shared variables, but are otherwise independent Real-time periodic tasks  Tasks placed in periodically-scheduled buckets  Tasks consume values of certain variables; produce values of other variables  Tasks within bucket must complete before bucket period Comp 1 Comp 2 Sensor/Actuator Variables Task 1,1 Task n,1 Shared Variables Task 1,2 Task n,2 Task n,3

7. Carnegie Mellon: The Rare Glitch Project7David Garlan Pub-Sub Systems are Hard to Reason About Burden of correctness falls to system integrator Lots of inherent non-determinism  Order of invocation of multiple event recipients  In-transit events  Non-determinism in “dispatch” mechanism Questions that are hard to answer  What do we want to say about such systems? What’s an “invariant”?  Do the components announce the events that they should announce?  What will be the effect of announcing a particular event?  Are there the correct event subscriptions?  If a new component is added, will it break what is already there?

8. Carnegie Mellon: The Rare Glitch Project8David Garlan Technical Approach - Foundations Key ideas  Events have semantics  Explicit specification of non-interference conditions  Compositionality via component environment specn Rely-guarantee verification framework  Joint work with Juergen Dingel, Somesh Jha [Din98b]  Based on Jones rely-guarantee approach  Results: It works, but is hard to use, and often requires stronger invariants than are necessary Temporal logic verification framework  Explicit modeling of dispatcher [Din98a]  Properties expressed in LTL  Results: Properties are more naturally expressed

9. Carnegie Mellon: The Rare Glitch Project9David Garlan Technical Approach - Tools Features  Based on (LTL) foundations mentioned earlier  Specifications translated to Cadence SMV Model Checker input  Attempts to reduce cost of (a) building a system model and (b) specifying the properties to check Provides a Parameterized Model Generator Supports certain Built-in Checks  Currently in early stages of development and experimentation

10. Carnegie Mellon: The Rare Glitch Project10David Garlan Parameterized Model Generator Generate most of the run-time event delivery and dispatch mechanisms  Greatly reduce cost of constructing model for pub-sub systems Support common dispatcher alternatives  Allow easy exploration of alternatives  Delivery options Asynchronous: immediate return from announcement Synchronous: return after event completely processed  Concurrency options Single thread per component Multiple threads per component  Dispatch order FCFS, Prioritized, Lossy, etc.

11. Carnegie Mellon: The Rare Glitch Project11David Garlan Model Architecture Environment (external event source) Shared state Delivery Policy Dispatcher Interface Comp 1 Interface Comp N … Event Announcement Data Exchange Event Delivery

12. Carnegie Mellon: The Rare Glitch Project12David Garlan Shared Environment (external event source) Shared state Delivery Policy Dispatcher Interface Comp 1 Interface Comp N … Event Announcement Data Exchange Event Delivery

13. Carnegie Mellon: The Rare Glitch Project13David Garlan Built-in Checks Provide many of the common sanity checks  Move towards push-button tools Special cases  Model-view topology  UI event model  Idempotent systems  Procedure call pairs General consistency/completeness checks  Components respect event semantics  Events that are published, but not subscribed to  Events that are subscribed to, but not published  Liveness properties  Race conditions

14. Carnegie Mellon: The Rare Glitch Project14David Garlan Next Steps (and opportunities for collaboration) Tool development  More built-in checks, parameterization options  Alternative model-checker substrates Applications  Realistic problems  Pub-sub “bridges”  Current plan is to work on part of NASA remote agent architecture Better linkage to code  Auto generation of component models?  Counterexample explanation New specification capabilities  Dynamism, timing, real-time Bridge C2C1D2D1

15. Carnegie Mellon: The Rare Glitch Project15David Garlan More information ABLE Project web site: www.cs.cmu.edu/~able Papers: [All98] Formal Modeling and Analysis of the HLA Component Integration Standard. R. Allen, D. Garlan, and J. Ivers. Proc of the 6th International Symposium on the Foundations of Software Engineering (FSE-6), Nov 1998. [Din 98a] Reasoning About Implicit Invocation. J. Dingel, D. Garlan, S. Jha, and D. Notkin. Proc of of the Sixth International Symposium on the Foundations of Software Engineering (FSE-6), Nov 1998. [Din 98b] Towards a Formal Treatment of Implicit Invocation using Rely/Guarantee Reasoning," J. Dingel, D. Garlan, S. Jha, and D. Notkin. Formal Aspects of Computing 10, 1998.