1 / 15

Model Checking Publish-Subscribe Software Architectures

Model Checking Publish-Subscribe Software Architectures. David Garlan Carnegie Mellon University. Research Approach. Specification and analysis of software architectures Components and their interactions Architectural styles (e.g., client-server, pipe-filter, publish-subscribe)

lynnortega
Download Presentation

Model Checking Publish-Subscribe Software Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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. 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. 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. Set Counter RTI … Sim1 Simn 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)

  6. Sensor/ActuatorVariables Comp1 Comp2 Shared Variables Task1,1 Taskn,1 Task1,2 Taskn,2 Taskn,3 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 completebefore bucket period

  7. 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. Technical Approach - Foundations • Key ideas • Events have semantics • Explicit specification of non-interference conditions • Compositionality via component environmentspecn • 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. 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. 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. Interface Comp 1 Interface Comp N Model Architecture Environment (external event source) Event Announcement DeliveryPolicy Dispatcher Data Exchange Event Delivery … Shared state

  12. Environment (external event source) Event Announcement DeliveryPolicy Dispatcher Data Exchange Event Delivery Interface Comp 1 Interface Comp N … Shared state Shared

  13. 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. C1 D1 C2 D2 Bridge 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

  15. 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.

More Related