TOWARDS MODEL CHECKING WITH JAVA PATHFINDER

FOR AUTONOMIC SYSTEMS SPECIFIED

AND GENERATED WITH ASSL

Emil Vassev

, Mike Hinchey

and Aaron Quigley

Lero – The Irish Software Engineering Research Centre, University College Dublin, Ireland

Lero – The Irish Software Engineering Research Centre, University of Limerick, Ireland

Keywords: Autonomic Computing, Model Checking, ASSL, Java PathFinder.

Abstract: Autonomic computing has been recognized as a valid approach to the development of large-scale self-

managing complex systems. The Autonomic System Specification Language (ASSL) is an initiative for the

development of autonomic systems where we approach the problem of formal specification, validation, and

code generation of such systems within a framework. As part of our research on ASSL, we have developed

and investigated different approaches to software verification. Currently, the latter is possible via built-in

consistency checking and functional testing where handling logical errors is a daunting task. In this paper,

we discuss our work on model checking with NASA’s Java PathFinder tool, which is an explicit-state model

checker that works directly on the generated Java code. We propose optional automatic generation of test

drivers in the form of PathFinder API calls seeded in the ASSL-generated code.

1 INTRODUCTION

Nowadays software permeates everywhere where

information technology can be useful to some

extent. However, contemporary software faces the

expanding burden of complexity in software

development and of ensuring both its correctness

and reliability. Hence, initiatives such as autonomic

computing (Parashar and Hariri, 2006) have risen to

introduce theories and techniques intended to reduce

the complexity of managing systems through

automation. Moreover a great deal of research effort

is devoted to developing software verification

methods. A promising, and lately popular, technique

for software verification is model checking (Clarke,

Grumberg and Peled, 2002; Baier and Katoen,

2008).

The vision and metaphor of autonomic

computing (AC) (Murch, 2004) is to apply the

principles of self-regulation and complexity hiding

to the design of complex computer-based systems.

However, the very complexity of many systems that

lend themselves well to AC can often imply

difficulty in designing the autonomic system itself.

The ASSL Approach to AC. The Autonomic

System Specification Language (ASSL) (Vassev,

2008) is a framework dedicated to AC. By providing

a powerful formal notation and computational tools,

ASSL helps AC researchers with problem formation,

system design, system analysis and evaluation, and

system implementation. The framework’s tools

allow ASSL specifications to be edited and

validated. The current validation approach in ASSL

is a form of consistency checking performed against

a set of semantic definitions (Vassev, 2008). The

latter form a theory that aids in the construction of

correct autonomic system (AS) specifications. In

addition, from any valid specification, ASSL can

generate an operational Java application skeleton.

As part of the framework validation and in the

course of a new ongoing research project at Lero —

the Irish Software Engineering Research Centre,

ASSL has been successfully used to specify

autonomic properties and generate prototype models

of the NASA ANTS concept mission (Vassev,

Hinchey and Paquet, 2008) and the NASA Voyager

mission (Vassev and Hinchey, 2009).

251

Vassev E., Hinchey M. and Quigley A. (2009).

TOWARDS MODEL CHECKING WITH JAVA PATHFINDER FOR AUTONOMIC SYSTEMS SPECIFIED AND GENERATED WITH ASSL.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 251-256

DOI: 10.5220/0002279902510256

 SciTePress

1.1 Research Problem and Proposed

Solution

ASSL provides automatic code generation, which

ensures consistency between a specification and its

implementation. However, our experience with

ASSL has demonstrated that errors can be easily

introduced while specifying large systems. Although

the ASSL framework takes care of syntax and

consistency errors, it still cannot handle logical

errors.

We are currently working on this, and

investigating a few possible approaches to ensure the

correctness of the ASSL specifications, and that of

the generated autonomic systems:

 We are working on improving the current

ASSL consistency checker with assertion and

debugging techniques, which should allow for

a good deal of static analysis of an ASSL

specification. This approach will improve the

verification process, but will not be sufficient

to assert safety (e.g., freedom from deadlock)

or liveness properties.

 We are investigating model checking as the

most effective approach to software

verification for our purposes.

Model checking is a formal methods technique

that allows formal specifications to be tested

exhaustively (Clarke, Grumberg and Peled, 2002;

Baier and Katoen, 2008). The approach advocates

formal verification tools whereby the formal

specifications are automatically checked for specific

flaws by considering special correctness properties

expressed in temporal logic (Baier and Katoen,

2008).

In the course of this long-term project, we

consider three different possible approaches to

model checking.

 A part of this research is on a model-checking

mechanism that takes an ASSL specification

as input and produces as output a finite state-

transition system (also called a state graph)

such that a specific property in question is

satisfied if and only if the original ASSL

specification satisfies that property (Vassev,

Hinchey and Quigley, 2009).

 Another research direction is towards

mapping ASSL specifications to special

service logic graphs, which support the so-

called reverse model checking (Bakera et al.,

2009).

 In this paper we present our third approach to

model checking with ASSL. The latter

generates operational Java code, which we use

to perform a sort of post-implementation

model checking with the Java PathFinder tool

developed at NASA Ames (Visser et al.,

2000). In this approach, we use Java

PathFinder to verify the generated Java code.

We are at the beginning of our research and

the results presented here are preliminary.

1.2 Why Post-Implementation Model

Checking?

Although it is widely accepted that model checking

should be applied to the design phase rather than to

the implementation phase of the software lifecycle,

we believe that post-implementation model checking

is worthy of investigation and probably well

integrated with ASSL.

In (Vassev, Hinchey, Quigley, 2009) we reveal

the so-called state-explosion problem we are

currently facing with specification-phase model

checking. Due to the highly concurrent nature of the

ASSL-specified ASs, the size of an ASSL state

graph is at least exponential in the number of

running ASs internal concurrent processes. This is

because the state space of the entire AS is built as

the Cartesian product of the local state of these

concurrent processes. Here, our possible solutions to

the state-explosion problem are abstraction

techniques that reduce the number of states to be

tested; i.e., the model checking mechanism does not

explore all the possible paths of execution, but only

those considered important. However, this approach

makes it possible to generate ASs with ASSL that

contain fatal errors (e.g., deadlocks), which cannot

be detected, despite careful specification and the

existence of model checking.

Another good reason for having post-

implementation model checking is the possibility to

verify not only the newly-generated code but also all

consecutively updated versions of the same. Thus,

we can check the code even if it has evolved

following its automatic generation with ASSL.

Paper Organization. The rest of this paper is

organized as follows. In Section 2, we review related

work on post-implementation model checking. As a

background to the remaining sections, Section 3

provides a brief description of the ASSL framework

and the built-in consistency checking mechanism.

Section 4 introduces Java PathFinder and the

proposed post-implementation approach to model

checking by integrating that tool in ASSL. Finally,

Section 5 presents concluding remarks and future

work.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

252

2 RELATED WORK

In the course of this research, we found two

interesting projects targeting post-implementation

model checking, where the implementation language

is C.

In (Ball, T., Podelski. A., Rajamani, S., 2001)

the SLAM project at Microsoft is described. This

project is similar to Java PathFinder in the sense that

it also relies on different techniques to accomplish

model checking. SLAM uses techniques such as

static analysis, abstraction, and symbolic model

checking (Clarke, Grumberg and Peled, 2002; Baier

and Katoen, 2008). A special model checker for

Boolean programs (Ball and Rajamani, 2000) is used

where all the program variables are of the Boolean

type. The idea is to apply abstraction on the original

C program by extracting a state graph and then to

check whether program statements are reachable.

For any reachable statement, the path of instructions

to that statement is symbolically executed on the

original program. If the executed path does not

match the expected path, a Boolean variable is

created to catch the point where the difference

begins. Further, the same process is repeated with a

new Boolean condition (involving the newly created

Boolean variable) that removes the path difference.

Another post-implementation model checker is

the FeaVer tool (Holzmann and Smith, 2000). The

latter is based on the SPIN (Ben-Ari, 2008) model

checker mechanism. FeaVer extracts an abstract

verification model in PROMELA (Iosif, 1998) (a

special verification modeling language) from the C

program, and verifies it against special logic

properties. The process of abstraction is semi-

automated because a special lookup table is used to

translate C code to PROMELA code. Once the

verification model is created, in a series of steps a

complete verification of the model is performed with

the construction of increasingly detailed PROMELA

models. The SPIN model checker is used to perform

model checking on the PROMELA models.

3 ASSL

In general, ASSL considers ASs as composed of

autonomic elements (AEs) interacting over

interaction protocols. To specify ASs, ASSL uses a

multi-tier specification model (Vassev, 2008). By

their nature, the ASSL tiers are abstractions of

different aspects of the AS under consideration, such

as self-management policies, communication

interfaces, execution semantics, actions, etc. There

are three major tiers (abstraction perspectives), each

composed of sub-tiers (cf. Figure 1):

 AS tier — forms a general and global AS

perspective, where we define the general

system rules in terms of service-level objectives

(SLO) and self-management policies,

architecture topology, and global actions,

events, and metrics applied in these rules. Note

that ASSL express policies with special states

called fluents (Vassev, 2008).

 AS Interaction Protocol (ASIP) tier — forms a

perspective that defines the means of

communication between AEs.

 AE tier — forms a unit-level perspective, where

we define interacting sets of individual AEs

with their own behavior.

Figure 1: ASSL multi-tier specification model.

AEs are intelligent agents and the ASSL-

developed ASs are considered multi-agent systems.

Similar to any multi-agent system (Sycara, 1998),

AEs are autonomous entities that interact either

cooperatively or non-cooperatively (on a selfish

base). The interaction though in the ASSL approach

is going over predefined messages. In addition, the

ASSL-developed AEs provide the needed decision-

making capability that underlies autonomy and self-

management. Moreover, ASSL allows for defining

the architecture topology of an AS where AEs can

be grouped into groups forming bigger intelligent

entities (mini ASs). Here, the group formation can

be centralized or GRID-alike (Vassev, 2008).

TOWARDS MODEL CHECKING WITH JAVA PATHFINDER FOR AUTONOMIC SYSTEMS SPECIFIED AND

GENERATED WITH ASSL

253

3.1 Consistency Checking in ASSL

In general, we can group the ASSL tiers into groups

of declarative (or imperative) and operational tiers.

Whereas the former simply describe definitions in

the AS under consideration, the latter not only

describe definitions but also focus on the operational

behavior of that AS. The ASSL framework evaluates

an AS specification formally to construct a special

declarative specification tree needed to perform

both consistency checking and code generation.

Consistency checking (cf. Figure 2) is a

framework mechanism for verifying specifications

by performing exhaustive traversal of the declarative

specification tree. In general, the framework

performs two kinds of consistency-checking

operations: 1) light – checks for type consistency,

ambiguous definitions, etc.; and 2) heavy – checks

whether the specification model conforms to special

correctness properties.

Figure 2: Consistency checking with ASSL.

The correctness properties are ASSL semantic

definitions defined per tier (Vassev, 2008).

Although, these are expressed in First-Order Linear

Temporal Logic (FOLTL) (Baier and Katoen, 2008),

currently, ASSL does not incorporate a FOLTL

engine, and thus, the consistency checking

mechanism implements the correctness properties as

Java statements. Here, the FOLTL operators ∀

(forall) and ∃ (exists) work over sets of ASSL tier

instances. In addition, these operators are translated

by taking their first argument as a logical atom that

contains a single unbound tier variable. Ideally, this

atom has a relatively small number of ground tier

instances, so the combinatorial explosion generally

produced by these statements is controlled.

It is important to mention that the consistency

checking mechanism generates consistency errors or

warnings. Warnings are specific situations, where

the specification does not contradict the correctness

properties, but rather introduces uncertainty as to

how the code generator will handle it. Although

considered efficient, the ASSL consistency checking

mechanism has some major drawbacks:

 It does not consider the notion of time, and

thus, temporal FOLTL operators such as

always, next, eventually, until, waiting-for, etc.,

are omitted. Therefore, ASSL consistency

checking is not able to assert safety (e.g.,

freedom from deadlock) or liveness properties

(e.g., a message sent is eventually received).

 The interpretation of the FOLTL formulas into

Java statements is done in an analytical way

and thus the introduction of errors is possible.

 There is no easy way to add new correctness

properties to the consistency-checking

mechanism.

4 POST-IMPLEMENTATION

MODEL CHECKING

In this section, we present our preliminary work on

model checking with ASSL and Java PathFinder. As

we have already stated, we are at the beginning of

our research on this model checking approach. Thus,

the results presented here are rather theoretical.

4.1 Java PathFinder

Java PathFinder is a post-implementation model

checker tool written in Java and targeting at Java

programs (Visser et al., 2000; Java PathFinder,

2008). It can check Java programs for deadlocks,

invariants and user-defined assertions in the code.

Moreover, properties expressed in Linear Temporal

Logic (Baier and Katoen, 2008) can be checked.

In general, it is claimed that Java PathFinder is

capable of checking any Java program that does not

rely on native methods. However, it is important to

mention that the state-explosion problem limits the

size of the applications that can be checked

effectively up to 10,000 lines of code (Java

PathFinder, 2008).Similar to any regular model

checking tool, Java PathFinder performs exhaustive

testing. The difference is that it works on the real

Java code instead of on a state graph. Here, the basic

technique is multiple execution of the program under

consideration to check all the possible executions for

paths that can lead to property violations, such as

deadlocks or unhandled exceptions. If an error is

found, Java PathFinder reports the execution path

that leads to it. Note that every execution step is

recorded, so we can trace the execution path that

gets to property violation.

Figure 3 depicts the operational model of Java

PathFinder. As depicted, different components

(tools) work by accompanying the execution of the

compiled Java program (in Java bytecode), e.g., an

ASSL-generated AS compiled to Java bytecode with

a regular Java Compiler.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

254

Figure 3: Java PathFinder operational model (elaborated from Java PathFinder, 2008).

As shown by Figure 3, special configurable

search strategies are provided to solve the problem

of state explosion. Because for large (more than

10,000 lines of code) applications the whole state

space cannot be searched effectively, these search

strategies are used to direct the search.

In addition, different state-reduction techniques

can help to reduce the number of states that have to

be stored:

 Special heuristic choice generators are

provided to set possible choices where a certain

state does not have to be complete. These

generators have the form of Java PathFinder

APIs that can be embedded in the tested

applications.

 A special library abstraction per state reduces

the overhead coming from tracking the run-time

data changes taking place in the checked Java

application. Note that all the heap, stack, and

thread changes are stored by default. This can

cause a big overhead if abstraction is not

provided.

4.2 Embedding Java PathFinder in

ASSL

In general, Java PathFinder provides capabilities for

non-deterministic testing via random input data

generators (Java PathFinder, 2008) that can be

embedded in the tested Java application. Special

APIs are provided, which can significantly ease the

creation of test drivers.

Hence, the ASSL framework can automatically

generate such test drivers based on the Java

PathFinder API. ASSL could generate these special

test drives as non-deterministic choices

implemented

in the generated code. Here, to simulate non-

deterministic testing we rely on two Java PathFinder

capabilities – backtracking and state matching.

With backtracking, we use the Java PathFinder

tool to restore previous execution states, which helps

to determine whether there are unexplored choices

left. Therefore, if an end state is reached, backward

steps can be performed to find execution paths that

are still not executed, and thus, the program does not

have to be re-executed from the very beginning.

With state matching, the Java PathFinder checks

whether a specific execution path has already been

explored any time when an ASSL-generated non-

deterministic choice is reached. In such a case,

model checking does not continue along the current

execution path, but does backtracking to reach the

nearest non-explored path that starts from the

nearest non-deterministic choice. For example, the

following run() method could be generated by the

ASSL framework for an autonomic element.

public class AE_WORKER {

...

public void run () {

boolean cond = Verify.getBoolean();

if (cond) { ... }

else { ... }

}

...

}

Note that autonomic elements are generated by

ASSL as Java Threads (Vassev, 2008). Here, a non-

deterministic PathFinder choice point will be

generated (cf. cond = Verify.getBoolean)

to test two different paths of execution of the

autonomic element.Both backtracking and state

matching techniques will be used to trace the two

library

abstractions

choice

generators

listeners

*.class

Search Strate

ies

property

checkers

listeners

Java Virtual Machine

verification report

error path

TOWARDS MODEL CHECKING WITH JAVA PATHFINDER FOR AUTONOMIC SYSTEMS SPECIFIED AND

GENERATED WITH ASSL

255

possible execution path – when cond = true and

when cond = false.

5 CONCLUSIONS

A model checking mechanism will complete the

ASSL framework by allowing for automated system

analysis and evaluation of any ASSL-generated

autonomic system, and thus, it will help to validate

liveness and safety properties of the same.

As a part of our long-term research on model

checking with ASSL, we are currently investigating

post-implementation model checking with NASA’s

Java PathFinder tool. In this paper, we have justified

and presented our approach to applying Java

PathFinder on ASSL-generated autonomic systems.

We propose automatic generation of special

PathFinder choice points in the generated Java

applications. These choice points, together with the

provided backtracking and state matching

PathFinder mechanisms, will allow for possibly

efficient post-implementation model checking.

Future research is concerned with further

development of this approach and experimental

results. Moreover, it is our intention to build an

animation tool for ASSL, which will help to

visualize counterexamples and trace erroneous

execution paths. It is our belief that a model

checking mechanism for ASSL will enable broad-

scale formal verification of ASs. Therefore, it will

make ASSL a better and more powerful framework

for AS specification, validation and code generation.

REFERENCES

Clarke, E., Grumberg, O., and Peled, D., 2002. Model

Checking. MIT Press.

Baier, C., Katoen, J.-P., 2008. Principles of Model

Checking. MIT Press.

Bakera, M., Wagner, C., Margaria, T., Vassev, E.,

Hinchey, M., Steffen, B., 2009. Component-Oriented

Behavior Extraction for Autonomic System Design.

In Proceedings of the First NASA Formal Methods

Symposium (NFM 2009). NASA.

Ball, T., Podelski. A., Rajamani, S., 2001. Boolean and

Cartesian Abstractions for Model Checking C

Programs. In Proceedings of TACAS01: Tools and

Algorithms for the Construction and Analysis of

Systems. Genova, Italy.

Ball, T., Rajamani, S., 2000. Bebop: A symbolic Model

Checker for Boolean Programs. In Proceedings of the

7th International SPIN Workshop. Vol. 1885 of

LNCS, Springer-Verlag.

Ben-Ari, M., 2008. Principles of the Spin Model Checker

(Paperback), Springer.

Holzmann, G., Smith, M. H., 2000. Automating Software

Feature Verification. Bell Labs Technical Journal,

Vol. 5(2), Issue on Software Complexity.

Iosif, R., 1998. The PROMELA Language,

http://www.dai-arc.polito.it/dai-arc/manual/tools/jcat/

main/node168.html, last visited on April 25, 2009.

Java PathFinder, 2008. http://javapathfinder.sourceforge

.net/, last visited on April 25, 2009.

Parashar, M. and Hariri, S. (editors), 2006. Autonomic

Computing: Concepts, Infrastructure and

Applications. CRC Press.

Murch, R., 2004. Autonomic Computing: On Demand

Series. IBM Press, Prentice Hall.

Sycara, K. P., 1998. Multiagent Systems. In AI Magazine,

vol. 19(2). Association for the Advancement of

Artificial Intelligence.

Vassev, E., 2008. Towards a Framework for Specification

and Code Generation of Autonomic Systems. A PhD

Thesis in the Department of Computer Science and

Software Engineering, Concordia University,

Montreal, Canada.

Vassev, E., Hinchey, M., Paquet, J., 2008. Towards an

ASSL Specification Model for NASA Swarm-Based

Exploration Missions. In Proceedings of 23rd Annual

ACM Symposium on Applied Computing (SAC2008) -

AC Track. ACM.

Vassev, E., Hinchey, M., 2009. Modeling the Image-

processing Behavior of the NASA Voyager Mission

with ASSL. In Proceedings of the Third IEEE

International Conference on Space Mission

Challenges for Information Technology (SMC-IT’09).

IEEE Computer Society.

Vassev, E., Hinchey, M., Quigley, A., 2009. Model

Checking for Autonomic Systems Specified with

ASSL. In Proceedings of the First NASA Formal

Methods Symposium (NFM 2009), NASA.

Visser, W., Havelund, K., Brat, G., Park, S.-J., 2000.

Model Checking Programs, In Proceedings of the 15th

IEEE International Conference on Automated

Software Engineering (ASE’00). IEEE Computer

Society.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

256