Skip to main content Accessibility help
×
Hostname: page-component-7bb8b95d7b-fmk2r Total loading time: 0 Render date: 2024-09-30T11:25:59.594Z Has data issue: false hasContentIssue false

6 - Exploring and Analyzing Finite Model Programs

Published online by Cambridge University Press:  02 March 2010

Jonathan Jacky
Affiliation:
University of Washington
Margus Veanes
Affiliation:
Microsoft Research, Redmond, Washington
Colin Campbell
Affiliation:
Modeled Computation LLC, Seattle, Washington
Wolfram Schulte
Affiliation:
Microsoft Research, Redmond, Washington
Get access

Summary

In this chapter we introduce exploration our primary technique for analyzing model programs. Exploration generates a finite state machine (FSM) from a model program. The FSM can then be used for visualization, analysis, and offline lest generation.

In this chapter we show how model-based analysis reveals the design errors in the reactive system we discussed in Chapter 3, by exploring the model program we developed in Chapter 5, Section 5.7. We explain and demonstrate safety analysis that identifies unsafe (forbidden) states and liveness analysis that identifies dead states from which goals cannot be reached. Dead states indicate deadlocks (where the program seems to stop running and stops responding to events) or livelocks (where the program keeps running but can't make progress).

In this chapter we also introduce the mpv (Model Program Viewer) tool for visualization and analysis, and explain how to use the modeling library features that support analysis.

Finite state machines

In this section we motivate and explain FSMs.

Simulation is the most limited and labor-intensive model-based analysis technique because it only considers one run at a time (Chapter 5, Section 5.5). To perform more thorough analyses – to detect the design errors discussed in Chapter 3, for example – we need to consider many different runs. The obvious way would be to code a large number of runs, but this is not a practical solution. In order to get good coverage of program behaviors, we would usually have code a great many runs, and some would be very long. But the collection of runs would be redundant. The same sequences of actions would appear again and again in different runs, and even within a single run.

Type
Chapter
Information
Publisher: Cambridge University Press
Print publication year: 2007

Access options

Get access to the full version of this content by using one of the access options below. (Log in options will check for institutional or personal access. Content may require purchase if you do not have access.)

Save book to Kindle

To save this book to your Kindle, first ensure coreplatform@cambridge.org is added to your Approved Personal Document E-mail List under your Personal Document Settings on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part of your Kindle email address below. Find out more about saving to your Kindle.

Note you can select to save to either the @free.kindle.com or @kindle.com variations. ‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi. ‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.

Find out more about the Kindle Personal Document Service.

Available formats
×

Save book to Dropbox

To save content items to your account, please confirm that you agree to abide by our usage policies. If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account. Find out more about saving content to Dropbox.

Available formats
×

Save book to Google Drive

To save content items to your account, please confirm that you agree to abide by our usage policies. If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account. Find out more about saving content to Google Drive.

Available formats
×