Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
Monitoring Software Requirements using Instrumented Code
William N. Robinson
Department of Computer Information Systems
Georgia State University
Atlanta, GA 30301-4015 USA
wrobinson@gsu.edu http://cis.gsu.edu/~wrobinso
Abstract
Ideally, software is derived from requirements whose
properties have been established as good. However, it is dif-
ficult to define and analyze requirements. Moreover, deriva-
tion of software from requirements is error prone. Finally,
the installation and use of compiled software can introduce
errors. Thus, it can be difficult to provide assurances about
the state of a software's execution.
We present a framework to monitor the requirements of
software as it executes. The framework is general, and
allows for automated support. The current implementation
uses a combination of assertion and model checking to
inform the monitor.
We focus on two issues: (1) the expression of “suspect
requirements”, and (2) the transparency of the software and
its environment to the monitor. We illustrate these issues
with the widely known problems of the Dinning Philoso-
phers and the CCITT X.509 authentication. Each are repre-
sented as Java programs which are then instrumented and
monitored.
1. Introduction
Software is pervasive. So too are software bugs. Such
glitches in the execution of software can cause millions of
dollars in lost revenue, as evidenced by recent denial of ser-
vice attacks[16].
Sometimes the environment causes the software to act in
unpredictable ways. For example, a space probe is designed
to receive various updates as it orbits a planet. However,
during orbital insertion, the probe must do many tasks—so
many, that it cannot also receive updates during orbital
insertion. Unfortunately, this interaction between the orbit-
ing requirements and the insertion requirements was not
made apparent until a fault occurred during a mission. Yet,
these are significant problems. As Lutz reports, NASA soft-
ware had to be “patched” post-launch due to changes in
requirements[27]. Many of the software requirements
changes arose due to: (1) unexpected or rare events, and (2)
recovery from hardware faults or limitations. Thus, the orig-
0-7695-1435-9/02 $17.00 (c) 2002 IEEE
Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
inal software requirements did not address the full range of
environmental behaviors that the software encountered.
The problem is one of properly specifying requirements.
Perhaps, the engineers specifying the orbital insertion soft-
ware should have worked more closely with the engineers
specify the orbiting software. Even so, to find the error at
design-time would require that engineers have an accurate
model of the environment. One could say, they should have
known that the combination of orbital insertion calculations
and the orbital maintenance would overcome the processing
capability of the probe. However, this is a slippery slope.
Eventually, one comes to see that the engineers must be able
to understand all combinations of events that could occur in
all environments that the software is placed. This can be
intractable.
As a staring point, we offer a general research question.
• Research question R1: How can assurances be provided
for running software?
The research question R1 is aimed at addressing prob-
lems such as encountered by the NASA probe software.
Software development involves descriptions in the follow-
ing form: E, I ⇒ R. It states that, the software implementa-
tion, I, within environment E, exhibits the required
behaviors, R. There has been substantial supporting work in
program verification. That is, providing assurances that the
software development process maintains that I ⇒ R. How-
ever, there is less research on providing assurances that the
requirements are still being satisfied within the real environ-
ment; that is, providing assurances that E, I ⇒ R is main-
tained.
We are currently working under the assumption that
external monitoring software can provide appropriate assur-
ances.
• Working hypothesis H1: Assurances can be provided
by monitoring the running software
We suggest the following formulation of software devel-
opment for requirements critical software systems: E, I, M
⇒ R ∨ (¬R ∧ N). It states that, the software implementa-
tion, I, within the scope of environment E and monitor M,
exhibits the required behaviors, R, or a notification N is pro-
vided. Thus, either the software does what it is intended to
1
 Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
do, or a notification is provided, via the monitor.
Within the scope of our requirements monitor, herein we
are concerned with two issues: (1) the expression of “sus-
pect requirements”, and (2) the transparency of the software
and its environment to the monitor.
1.1 Expressing suspects
One issue concerns the relationship between a require-
ment, R, and its notification, N. A requirement mandates
that the system exhibit a behavior—if not, a notification
should occur (e.g., R ∨ (¬R ∧ N)). Yet, we assume require-
ments monitoring can be costly. Thus, only some, so called
suspect requirements, will be marked for monitoring.
Still, a notification that a suspect requirement failed may
not be particularly helpful. For example, a notification that
“the rocket has veered into the atmosphere” may not arise in
time to begin an appropriate action. Instead, we prefer to
allow for the monitoring of requirements and their weaken
conditions. Thus, given that requirement satisfaction entails
certain conditions, monitoring of those conditions seems
appropriate. So, if ¬R ⇒ C1⇒ C2 ⇒ C3 ... ⇒ Cn, it may
be helpful to be notified when Cn first occurs, when C1 later
occurs, and finally when ¬R occurs. Monitoring suspect
conditions will provide for a series of increasingly urgent
notifications prior to the failure of a requirement.
One can apply rules to generate weakened conditions
from requirements to serve as suspect conditions[6]. How-
ever, if a condition is left out or incorrectly specified, then a
requirement can still fail without warning. So, it would be
helpful to automatically determine if a requirement could
fail, given the current state of the system.
We will explore these issues using the two illustrative
examples of sections 4 and 5.
1.2 Run-time environments
Another monitoring issue concerns the transparency of
the running software and its environment. Ideally, the moni-
tor should have an accurate model of the software and its
environment. More likely, the software will provide a log of
events that have occurred, while the environment may pro-
vide no information other than that which can be inferred
via the software log. In a cooperative environment, one is
more likely to adequately instrument both the required soft-
ware and its environment. As we shall see in section 5, a
competitive environment may hamper—or even purposely
interfere with—the progress of the monitor.
2. Requirements monitoring of running
software
Requirements analysis and software testing typically end
0-7695-1435-9/02 $17.00 (c) 2002 IEEE
Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
after the software is deployed. If testing does continue, it is
done “at the factory”, rather than at the customer’s installa-
tion site. Yet, many software errors arise due to changing or
unforeseen circumstances found at the installation site. Per-
petual testing aims to address this gap.
Perpetual testing promises to leave the testing phase of
software unbounded. Testing may continue long into
deployment, and thereby, make use of data collected during
the normal use of the software[5]. Currently, the perpetual
testing research is addressing issues closer to software
design than the high-level software requirements. For exam-
ple, Butkevich et. al., describes an extension to Java that
enables static and dynamic checking of object interaction
protocols (i.e., sequence diagrams) as part of a Java pro-
gram[3].
Researchers in requirements monitoring aim to fill the
gap between requirements analysis and perpetual testing. In
requirements monitoring, systems requirements are the
focus of study. The goal is to continually analyze require-
ments, from development through deployment to eventual
system retirement. An important requirements monitoring
activity concerns the run-time monitoring of requirements.
2.1 Execution monitoring of requirements
Execution monitoring of requirements is a technique that
tracks the run-time behavior of a system and notes when it
deviates from its design-time specification. Requirements
monitoring is useful when it is too difficult (e.g., intractable)
to prove system properties. To aid analysis, assumptions are
made as part of the requirements definition activity. The
requirements and assumptions are monitored at run-time.
Should any such conditions fail, a procedure can be invoked
(e.g., notification to the designer). Note, such monitoring is
different from exception handling in that it: (1) considers the
combined behavior of events occurring in multiple threads
or processes over time, (2) links run-time behavior with the
actual design-time requirements, and (3) provides (poten-
tially) sufficient information to allow for the run-time recon-
figuration of software.
Fickas and Feather proposed requirements monitoring to
track the satisfaction of requirements during system execu-
tion as part of an architecture to allow the dynamic reconfig-
uration of component software[13]. Feather has produced a
working system, called FLEA, that allows one to monitor
events defined in a requirements monitoring lan-
guage[11][12]. FLEA captures interesting events as asser-
tions in a database. When a monitored condition occurs, its
defined action is executed. Thus, monitoring mainly con-
sists of the translation of requirements monitoring descrip-
tions to database triggered actions.
Fickas and Feather illustrate the execution monitoring of
requirements in the context of monitoring the requirements
2
 Proceedings of the 35th Hawaii International Conference on System Sciences - 2002

of a software license server. When the license server fails to natural language text; however, the framework assumes
satisfy its requirements (e.g., a user shall be granted a some formal definitions of desired predicates over objects
license in 90% of their requests) due to a change in the sys- and relationships. More specifically, requirements that refer
tem environment, the system notifies an administrator. to conditions on states are most easily analyzed. For exam-
Emmerich et. al. (and others [33]) have since illustrated how ple, the KAOS language can be used for this purpose[7].1
the technique may be used to monitor process compli- The following Avoid[FourHeldLeftForks] goal illus-
ance[9]; for example, organizational compliance to ISO trates one such KAOS requirement.2 The goal states that the
9000 or IEEE process descriptions[29]. system should avoid four forks, each held in a philosopher’s
Feather has gone on to analyze log files of a completed left hand. Four held left forks is bad in a system of four phi-
program[10]. Similarly, log files have been analyzed for for- losophers, as it will deadlock the system. (Section 4 presents
mal properties using a customized tool [32], as well as a col- this example problem in more detail.)
lection of state machines[1][2]. There is also related SafetyGoal Avoid[FourHeldLeftForks]
research on event-based debugging[17][21][37] and deriva- InformalDef
“Avoid four philosophers simultaneous
tion of test oracles from precise specifications [30][31]. holding their left fork.”
Girgensohn et. al. created expectation agents to monitor FormalDef
∀ p1, p2, p3, p4 : Philosopher,
the actual use of a system[14]. Developers define software f1, f2, f3, f4 :Fork
user expectations, such as, “validate the customer address
¬ (HoldingLeft(p1,f1) ∧
HoldingLeft(p2,f2) ∧
before configuring the customer’s services”. Then, agents HoldingLeft(p3,f3) ∧
monitor the system’s use. When use of the system does not HoldingLeft(p4,f4))
match the defined expectations, “agents may perform the Monitoring the satisfaction of such high-level requirements
following actions: (1) notify developers of the discrepancy; is the purpose of the framework.
(2) provide users with an explanation based on developers’
rationale, (3) solicit a response to or comment about the 3.2 Analysis and design
expectation.”[14] In this manner, expectation agents moni-
tor the satisfaction of developer requirements (expectations) The framework assumes that the high-level software
during the system. requirements will be translated into a more development-
oriented analysis and design model. For example, the Uni-
2.2 Article overview fied Modeling Language (UML) can be used as the model-
This article describes research that builds on prior work
Define Key
in requirements monitoring. A goal of this research is to Requirements Process flow
continually analyze requirements during the run-time execu- (with information)

tion of software. Next, we present our overall requirements Information flow

monitoring framework for software execution. An important Analysis &

Design
contribution of this work concerns the continual checking of
running software. Section 4 illustrates requirement and sus-
pect condition checking with an example. The transparency
Implementation & Monitoring &
of the software and its environment are considered in sec- Instrumentation Checking
tion 5. This article concludes that a combination of assertion
checking and model checking can provide substantial sup-
port for monitoring requirements during the run-time execu-
Execution
tion of software.

3. A Requirements monitoring framework Figure 1. An illustration of a framework for run-time

requirements monitoring.
Figure 1 illustrates our requirements monitor for execut-
ing software (RMon) framework. It is essentially a refine-
ment of the model described in [11]. Each of the major
activities are described in the following subsections.
3.1 High-level requirements
The framework relies on the description of high-level
software requirements. These requirements may include
1
KAOS formal definitions use temporal logic operators[28].
Here, o means in the next state. Other operators are included for
the previous state (•), some time in the future (◊), some time in
the past (), always in the future (
), always in the past ().
2
This goal is simply used to illustrate how a safety property
can be monitored. Here, this common example and simple goal
are introduced so that the reader may focus on the monitoring
framework, rather than the details of the domain. More complex
goals may be formed using linear temporal logic.For example,
one could use disjunction to define a goal of avoiding either all
right or all left forks being taken.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE 3

Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
 Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
ing language. This intermediate (UML) model facilitates
traceability between the high-level requirements and the
software. Such linkage allows the execution monitor to
describe software failures in terms of requirements or the
UML model. Since developers are familiar with UML, and
it can have a direct correspondence to the software, we have
found this intermediate representation useful. However, as
long as one can maintain traceability between code and
requirements, it is not necessary to have the intermediate
UML model.
3.3 Implementing and instrumenting
The framework assumes that the high-level requirements
will be implemented in software. Moreover, there must be
static traceability between the software objects and the
requirements. For example, a KAOS agent definition, such
as the following Philosopher, can be traced to its Java class
definition.
// KOAS definition...
Agent Philosopher
Has
left_fork : Fork
right_fork: Fork
status : {ready, running,
suspended, dead}
// Java class definition (manually) derived
KAOS definition...
class Philosopher extends Thread {
private Fork left;
private Fork right;
In addition to the static traceability of definitions, there
must be dynamic traceability of class instances. When the
software executes, the monitor must be able to distinguish
the different instances of the defined classes. For example,
the monitor must be able to distinguish the actions of two
instances of the same agent type (e.g., knowing that
Philosopher1 actions are different from Philosopher2
actions). 3
Instrumentation can enable a monitor to track the activi-
ties of relevant objects. Instrumentation is the insertion of
informative statements into software for the purpose of
monitoring. Later, when the instrumented software exe-
cutes, the informative statements provide a stream of infor-
mation which can be interpreted by the monitor.
Typically, the source code of software is instrumented.
However, it is also possible to instrument compiled code
(e.g., [15]). For example, our implementation of the RMon
framework uses Joie to instrument Java class files (compiled
Java files)[4].
Instrumenting compiled code does provide for monitor-
3 For similar reasons, Wile added the id notation to Dynamic
Acme to reason about instances distinctly from Software Archi-
tecture[39].
0-7695-1435-9/02 $17.00 (c) 2002 IEEE
Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
ing of software without source code. However, there is still
the problem of interpreting the monitored stream. For exam-
ple, given the monitored stream of actions concerning the
compiled Java classes, methods, and variables, one must
map those names back to the software requirements in order
to interpret the actions.
3.4 Monitoring
The monitor must continually view the stream of (instru-
mented) activities and interpret their meaning. It is impor-
tant that the monitor notice when the software: 1) has
violated a requirement, or 2) is about to violate a require-
ment, or 3) may be about to violate a requirement. However,
this can be difficult given the tiny stream of information it
receives. For example, the following stream is output from
an instrumented dinning philosophers program.
Philosopher[0].eat()V
Fork[0].take()V
Philosopher[1].eat()V
Fork[1].take()V
Philosopher[2].eat()V
Fork[2].take()V
Philosopher[3].eat()V
Fork[3].take()V
Each line is of the following format: classname[instance
number].method(parameters)returnType. No doubt, it’s not
clear (yet) that the above monitor stream shows a deadlock
of four dinning philosophers.
To interpret the monitor stream, the monitor can use a
model. In our implementation of the RMon framework,
assertion checking is used to monitor specific suspect condi-
tions, while model checking is used in certain circumstances
to determine if a requirement could fail later. In both cases, a
formal automata-based model is used. This model is gener-
ated automatically from the Java source code.
3.4.1 Assertion checking
A suspect condition can be considered as a system invari-
ant. That is, given ¬R ⇒ C1, one can check that C1 never
occurs in any state of the system. If it does, a notification
should be generated.
Consider the following suspect, ThreeHeldLeftForks.
Goal Avoid[ThreeHeldLeftForks]
InformalDef
“Avoid three philosophers simultaneous
holding their left fork.”
FormalDef
∀ p1, p2, p3 : Philosopher,
f1, f2, f3 :Fork

¬ (HoldingLeft(p1,f1) ∧
HoldingLeft(p2,f2) ∧
HoldingLeft(p3,f3))
Four left forks held entail three left forks held. That is,
FourHeldLeftForks ⇒ ThreeHeldLeftForks.4 So,
to provide prior warning that Avoid[FourHeldLeft-
4
 Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
Forks] may be about to fail, the monitor can check if
ThreeHeldLeftForks exists. This is done by checking if
ThreeHeldLeftForks occurs during system execution.
If,
Assert(!ThreeHeldLeftForks)
fails during any state of execution, then a notification is
raised. In this way, the monitor can provide prior notifica-
tion before a high-level requirement is violated.
The goal Avoid[ThreeHeldLeftForks] illustrates
how a weakening of a requirement may be described for
monitoring. Of course, ThreeHeldLeftForks and many
similar suspect conditions can be specified. Deriving sus-
pect conditions from high-level requirements is a research
topic[6]. For example, it may be desirable to raise a warning
when “two adjacent left forks are held”, or even “one left
fork is held”. Such suspect conditions allow for a range of
warnings indicating minor to severe conditions that can lead
to a requirement failure.
Suspect conditions may be explicitly incorporated into
the high-level requirements. For example, rather than call
Avoid[ThreeHeldLeftForks] a suspect condition, one
could consider it a high-level requirement, just as
Avoid[FourHeldLeftForks]is a requirement. However,
considering all cases, even if possible, can make the require-
ments, requirements analysis, and software unwieldy, if not
intractable. Moreover, the resulting system would intermin-
gle the core system and the monitor system into one non-
cohesive system. This may impair the ability to incremen-
tally add functionality or monitors.
3.4.2 Model checking
A model checking monitor can determine if a high-level
requirement can fail in the future without the need to explic-
itly specify suspect conditions. Model checking is an opera-
tional exploration of a state-based model. Such analysis can
prove that specified logic conditions will, or will not, occur
in a modeled state of a system satisfying the requirements.
Thus, if the program and its current state of execution can be
represented as a state-based model, then the model checker
can determine if a suspect requirement can fail, in any way,
in the future.
Model checking of requirements is typically applied as
follows: 1) a portion of the requirements specification is
translated into a formal automata-based model, 2) important
requirements, such as safety properties, are defined as logi-
cal properties of the model, 3) a model checker (e.g.,
Spin[18]) is used to exhaustively check all states of the
4 6
If multi-threading is used, then philosophers can simulta-
neously acquire all left forks. So, there may be no recourse.
However, fork acquisition can be serialized through a resource
manager, so notification of ThreeHeldLeftForks can be
used to prevent FourHeldLeftForks.
0-7695-1435-9/02 $17.00 (c) 2002 IEEE
Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
model for violations of the specified properties.
To anticipate requirement failures, our implementation of
the RMon framework can model check the running pro-
gram. It does so by translating the program source code into
a state-based model. As the program executes, a log of
events is recorded. Together, the event log and state-based
model represent the current state of the running program.
That monitor model can be checked to determine if the cur-
rent execution is on a path that can lead to a requirement
failure.
Together, assertion checking and model checking are
used to monitor suspect conditions and requirements. Asser-
tion checking is more efficient, but requires the (correct)
specification of requirement weakenings. Model checking is
less efficient, but does not require the specification of
requirement weakenings.
3.4.3 The monitoring procedure
Our current implementation of the RMon framework is
called ReqMon. The following procedure is used to generate
a monitor and then monitor a program’s execution for
requirements failure.
(1) Requirements are defined.
(2) A UML model design is derived from the requirements.
(3) A Java program is derived the UML model.5
(4) The compiled Java classes are instrumented to generate
a stream of events that the monitor can interpret.
(5) Periodically, a monitor model is generated from the pro-
gram source code and the monitored program event log.
(a)The monitored program event log is translated into
Java statements that capture the sequence of method
calls in the original Java program. Thus, this “stream-
lined” Java source code has no loops or conditionals.
It simply represents the sequence of method calls that
have occurred. In the case of multi-threading, it is
necessary to define such a sequence for each thread.
(b)To generate the state-based model, a Promela model is
semi-automatically derived from the modified Java
source code of step 5a. A program, java2spin does this
translation[8].6
(c)The resulting Promela model is checked for the failure
of suspect conditions and requirements. To check a
suspect condition, the model checker determines if
Assert(!suspect_condition) holds. (It is not
necessary to check the future states of a suspect condi-
tion, since it represents a condition that leads to a re-
quirement failure; that is, ¬ R ⇒ Ci.) To check the
more abstract requirements, all future states of the
model are checked for each requirement. That is,
5
Our current, and next, implementation use software tools that
require Java code.
java2spin does not handle all Java program constructs.
Where it can, this process is fully automated. Our next version of
ReqMon will use Java Path Finder[38]. That model check works
directly on Java byte-code.Thus, it can model check a wider
range of program behavior.
5
 Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
Thread
(fro m la n g )
P hilos opher Fork
is_free : boolean
- ri ght -left
P hilos opher()
eat() Fork ()
think () tak e()
run() l eave()
Figure 2. UML class diagram representing
Philosopher and Fork classes.
Never (!requirement) is determined.
(6) Failures determined in step 5 are reported by the moni-
tor. For both the (current) failure of a suspect condition
or (predicted) failure of a requirement, a sequence of pro-
gram states can be presented to show how the failure can
occur.
4. Dinning philosophers
The widely known problem of the dinning philosophers
will serve as an exemplar for our approach to RMon frame-
work. This problem is especially useful, as it demonstrates
troubles that can occur among multiple processes with
shared resources.
Consider four philosophers sitting around a table. The
philosophers can either eat or think. Thinking does
not require a resource, whereas eating requires two
forks. There are only four forks; each is between a
pair of philosophers. A philosopher can only share the
use of forks that are immediately to his left or right.
The problem is to guarantee mutually exclusive
access to the forks, while preventing deadlock or star-
vation. A deadlock can occur when all philosophers lift
up their left fork, and then deadlock as they try to lift
up the right fork that is already taken.
4.1 High-level requirements
The main high-level requirement we will focus on is the
Avoid[FourHeldLeftForks] of section 3.1. In combina-
tion with our design, it will ensure that the system will not
become deadlocked.
4.2 Analysis and design
Figure 2 shows a UML Java design model of the dinning
philosophers. Figure 3 shows UML collaboration diagram
illustrating how the four instances of philosophers and forks
are related. (The lines are links that indicate communication
among the objects.) Note that this design (and resulting Java
program) specifies the number of philosophers and forks a
priori.
It is possible to directly model check the UML design
0-7695-1435-9/02 $17.00 (c) 2002 IEEE
Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
John Fork1 Anna
left right
left
ri ght
Fork2
Fork4
left right
Sara Fork 3 Peter
right left
the
Figure 3. UML collaboration diagram representing the
connections among Philosopher and Fork objects.
model. For example, the vUML tool can derive a Spin
model and present failures in terms of UML[24]. However,
such analysis is only available for smaller models (like the
dining philosophers). Larger models, entailing larger state-
spaces, cannot be sufficiently explored by model checkers
(e.g., [25]). In contrast, the assertion checking (a.k.a., his-
tory checking) of one specific run of a program is very effi-
cient. In similar fashion, model checking for requirement
failure can be more efficient after some execution of a pro-
gram has occurred. This occurs because as a program exe-
cutes, it selects a path at each choice point, and thereby
reduces the remaining state space to be checked. So, check-
ing suspects and requirements can be more efficient at run-
time, than design-time.
Checking a program trace is still a complex process.
Each program state must be checked for compliance with
linear temporal logic (LTL) formulas[28]. An LTL formula
is more abstract than a program state; it may reference
abstract and arbitrary program states, as well as various
times. Yet, a model checker can efficiently analyze any
properly instrumented program.
Rather than use a general model checker, one might add
program assertions to provide assurances about a running
program’s behavior[26]. Assertions can be complex and
abstract. Program state information can be tracked by spe-
cialized “assertions”, thereby allowing LTL references. In
fact, one can custom build an LTL model checker for a spe-
cific program's execution using assertions. However, it is
easier, more reliable, and more general to use a general
checking tool for that purpose. Rather than custom tailor a
program with assertions, one can simply express LTL's and
then automatically instrument and check the program.
4.3 Implementing and instrumenting
The Java class definitions for the philosopher and fork
are shown in figure 4. The main program that executes,
includes the following statements to initialize the program.
6
 Proceedings of the 35th Hawaii International Conference on System Sciences - 2002

phil1 = new Philosopher(fork1, fork2); public class TraceMixin {

phil2 = new Philosopher(fork2, fork3); // The current count of object (instances)
phil3 = new Philosopher(fork3, fork4); that are being traced.
phil4 = new Philosopher(fork4, fork1); private static int OIDcount = 0;
phil1.start(); // The object's ID.
phil2.start(); private int OID;
phil3.start();
phil4.start(); public void init () {
After the Philosopher and Fork classes were compiled, setToCurrentOIDcount();
incrementOIDcount();
they were instrumented using Joie. Figure 5 shows the Java }
class information what was added to the Philosopher and // More defintitions (elided)...
Fork classes. Notice that, as part of the mixin, an initializa- public void traceMsg(String s) {
tion method was added. This init() method tracks the spe- System.out.println(this.getClass().get-
class Philosopher extends Thread { Name() + "[" + OID + "]" + s);
private Fork left; }
private Fork right; }
Philosopher(Fork f1, Fork f2) Figure 5. The Java definition of the TraceMixin class.
{ These definitions were added to each class in the compiled
left = f1;
right = f2; class Ph1 extends Philosopher
} {
public void eat() Ph1(Fork f1, Fork f2)
{ {
left.take(); super(f1,f2);
right.take(); }
} public void run()
public void think() {
{ eat();
left.leave(); // Other steps follow here...
right.leave(); }
} }
public void run()
Figure 6. An updated Java philosopher definition for
{
philosopher 1.
while (true) {
eat(); cific instances of a class via a unique object number. This
think(); number is referenced in the traceMsg method. Thus, the val-
} ues appear in the output of section 3.4.
}
}
class Fork
4.4 Monitoring
private boolean is_free;
Fork() To monitor, the monitor program continually checks the
{ program event log. For this simple example, the program
is_free = true; event log is simply text output to standard out. (See the
} traceMsg method of figure 5.) Additionally, ReqMon also
public synchronized void take()
has a mixin that outputs the events to a database.
{ The monitor continually checks the output by creating a
while (!is_free) modified Java program and then checking it in Spin. To
try { modify the program, a program (monitorLog2Java) gener-
wait(); ates updated Java definitions from the program event log.
} catch (InterruptedException e)
{return;} Figure 6 shows an updated definition for instance number
is_free = false; one of the Philosopher class. Note, it is necessary to define
} subclasses (extends) of Philosopher because we need to
public synchronized void leave() define the prior monitored actions of an instance of the Phi-
{
is_free = true;
losopher class. The other subclasses of Philosopher (Ph1 to
notify(); Ph4) are similarly defined.
} To check the requirements on the program execution, the
} java2spin program is used to create a Promela definition of
the modified Java program. Finally, this monitor model is
Figure 4. The Philosopher and Fork Java class definition.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE 7

Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
 Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
checked. To do so, each suspect condition and requirement
must be added to the model. However, the Spin model
checker cannot understand requirement based properties,
such as ThreeHeldLeftForks (§3.1). Instead, such prop-
erties must be manually mapped to definitions in the under-
lying state-based model as created by java2spin. (This can
be difficult, as the java2spin model can be non-intuitive.)
Consider translating the ThreeHeldLeftForks sus-
pect condition. This first must be specified in terms of the
monitor model definitions. In the example of our Promela
(Spin) model, the following terms are used.
#define p0HoldF0
(def_Philosopher_left[0].i_no] == 0)
#define p1HoldF1
(def_Philosopher_left[1].i_no] == 1)
#define p2HoldF2
(def_Philosopher_left[2].i_no] == 2)
#define p3HoldF3
(def_Philosopher_left[3].i_no] == 3)
#define threeHeldLeftForks
((p0HoldF0 && p1HoldF1 && p2HoldF2) ||
(p0HoldF0 && p1HoldF1 && p3HoldF3) ||
(p3HoldF3 && p1HoldF1 && p2HoldF2) ||
(p0HoldF0 && p3HoldF3 && p2HoldF2))
Once so defined, Spin can test for the violation of three-
HeldLeftForks, using an assertion checking process:
proctype monitor() { assert(!threeHeldLeft-
Forks)}.
If the requirement Avoid[FourHeldLeftForks] were
not weakened to the suspect condition threeHeldLeft-
Forks, then Avoid[FourHeldLeftForks] would have to
be checked directly. Moreover, we would not only want to
know if the requirement had failed, but we would also want
to know if the requirement could fail in the future. (Suspect
conditions provide this predictive information for those con-
ditions that are specified.) To determine if a requirement can
fail, given the current state of execution, the current monitor
model is model checked for the requirement (like three-
HeldLeftForks shown above).
Note, model checking can involve single state-based
properties, such as fourHeldLeftForks. However, it can
also include temporal properties that concern sequences of
states. For example, one could check that “if property P
occurs, then property Q must occur in a subsequent state.”
The following section will illustrate one such analysis.
As a result of checking the assertion threeHeldLeft-
Forks, a violation of the suspect condition was found for
the program output shown in section 3.4. Thus, as the sys-
tem neared deadlock, the monitor detected that the require-
ment Avoid[FourHeldLeftForks] could fail as part of
the future program execution.
5. Authentication
Monitoring can be an efficient means to determine
requirement satisfaction. However, the transparency of the
0-7695-1435-9/02 $17.00 (c) 2002 IEEE
Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
software and its environment to the monitor is critical.
Consider the CCITT X.509 (1989) protocol for signed
secure communication between two parties[19]. It can be
used to establish session keys that allow for authenticated
and confidential communication. A goal of the protocol is to
prevent the occurrence of an agent, A, sending a message to
an agent C, while intending to send the message to agent B.
However, proving that this goal is always met is difficult.
The protocol has only three messages. These are illus-
trated below (in simplified form):
Type Message flow Nonces Signed By
Init Request B→A Kb-1
I A→B Na Ka-1
II B→A Na, Nb Kb-1
III A→B Nb Ka-1
Above, consider A as a client and B as a server. The
sequence of messages of type I through type III causes client
A to be authenticated with server B.The messages use pub-
lic and private keys (RSA) to ensure the privacy of message
contents. A nonce (a unique random number depicted as Na)
is used to ensure that, once communication is started, no
other agent can intervene in the two agent communication
protocol.
The CCITT X.509 protocol appears secure enough; how-
ever, it is susceptible to a reply attack.
• Replay of message to gain authentication. An imposter,
C, can intercept messages between agents A and B so as
to make B believe it is communicating with A, when it is
really communicating with C. C begins the attack by cap-
turing and resending an old message sent from A to B.
The message is then sent from C to B.
Imposter Message: I) C → B : A, { Na}Kb-1
If the imposter’s message is sufficiently close to A’s type
I message to B, then B will not notice the reuse of the
message. Specifically, the reused nonce, Na, will not be
checked, so the reuse goes undetected. Next, B will reply
with a new message intended for A.
Message: II) B → C: B, {Na, Nb}Kb-1
Next, C can request that A authenticate with C. In reply
to A’s new message, C will reply with B’s nonce, Nb (the
type II message above). Finally, A will reply to C using
the signature needed for C to send a new message to B.
Here, we are not concerned with all the details of this attack.
Rather, we are concerned with how it might be detected.
Detecting such a flaw in the authentication protocol at
design-time is quite difficult. One must define the two coop-
erating agents, each of which must obey the protocol Addi-
tionally, one must define the intruder agent. It may carry out
any action allowed in the environment, such as the capture
and reply of messages. Once the agents and environment are
represented, one can answer questions such as “Can an
8
 Proceedings of the 35th Hawaii International Conference on System Sciences - 2002

agent, A, send a message to agent C, while intending to send when two clients are authenticating with a server at the same
the message to agent B?” However, checking the effect of a time.
malicious agent on a protocol can be intractable. For exam- The critical element of the replay attack is the reuse of
ple, Josang estimates that checking the CCITT X.509 proto- the nonce, Na, by the intruder. We would like the model
col for the Replay Attack will involve approximately 1019 checker to look for an occurrence of two type I messages
states[20]. Thus, automated model checking is not practical. with the same nonce:
However, monitoring may be a practical solution. Message1(I, Nx), Message2(I, Ny) | Nx = Ny
After specifying, coding, and running the three agents However, model checkers are more appropriate for checking
(two CCITT X.509 agents and a reply attack intruder), the the occurrence of events (e.g., Assert (!generateServ-
following output was generated.
erReplyFromClient)) than the comparison of data over
Client[0].run()V
Server[0].run()V time. For such analyses, ReqMon stores a fixed buffer of the
Server[0].requestAuthorization()V program event log to a database and uses database triggers
Client[0].replyToAuthorizationRequest(LMessage;)V
Server[0].replyToTypeIRequest(LMessage;)V
to monitor for a violation.
Intruder[0].run()V
Intruder[0].generateSpoofedTypeI(LMessage;)V 6. Future research
Server[0].replyToTypeIRequest(LMessage;)V
Intruder[0].generateClientAuthorization- There are a number of directions this research is proceed-
Request(LMessage;)V
Client[0].replyToTypeIIRequestMessage(LMessage;)V ing, including the following.
Client[0].replyToAuthorizationRequest(LMessage;)V • Improve translations between requirements representa-
Intruder[0].generateReplyToClient(LMessage;)V tion and the monitor.
Client[0].replyToTypeIIRequestMessage(LMessage;)V Currently, these translations are manual (§4.4). We
Intruder[0].generateServerReplyFromClient(LMes- would like to provide some automated assistance.
sage;)V
• Improve the explanations.
Again, like the output of section 3.4, it may be difficult to A model checker can provide a trace of events showing
see, but the requirement of private communication has been how a property fails; however, these explanations must
violated. However, ReqMon can determine this requirement be translated from the monitor model back to the design
failure. or requirements model.
• Assist in the generation of suspect conditions.
The transparency of the software makes it easy to deter- Given a requirement, R, one may automatically apply
mine that the requirement has failed. Given some knowl- patterns to generate various weakened requirements,
edge of the source code, a suspect condition can be specified WR1 .. WRn[6]. Then, the failures of these suspect con-
for the case that the intruder completes the replay attack pro- ditions can be monitored to allow for a range of “warning
cess. Above, this occurs when the intruder executes the lights”.
generateServerReplyFromClient message. However, • Facilitate the evolution of a running system.
few intruders will be so helpful as to provide their source, or Eventually, we would like to provide sufficient feedback
compiled, code. to guide automate program modification as a means to
overcome systematic requirement failures.
The monitor needs to check temporal relationships
among messages in the following sequence. One could Solutions to the above issues will improve requirements
Type Message flow Nonces Signed By monitoring. As ReqMon becomes more usable, it will be
Init Request B→A Kb-1 applied to case studies. Future studies will include e-com-
I A→B Na Ka-1 merce protocols, such as the secure transaction protocol
I C→B Na Ka-1 (STP)[36].
II B→C Na, Nb Kb-1
Init Request C→A Kc-1 7. Conclusions
I A→C Na′ Ka-1
We have presented a requirements monitoring framework
II C→A Nb, Na′ Kc-1
for the monitoring of executing software. We have described
III A→C Nb Ka-1
automated tool support that simplifies the application of the
III C→B Nb Ka-1
framework. In doing so, we have described how model
checking can provide substantial support for requirements
watch for the following sequence of message types: I, II, I, monitoring.
II, III. Such a sequence results from the interleaving of a real The CCITT X.509 signed secure communication proto-
authentication and a replay attack. However, it also occurs col consists of only three messages. Yet, it illustrates how

0-7695-1435-9/02 $17.00 (c) 2002 IEEE 9

Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
 Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
difficult it can be to prove that one has discovered all sce-
narios for a successful attack. Requirements monitoring is a
practical alternative to complete a prior requirements analy-
sis. In particular, requirements monitoring can be an effi-
cient means to provide assurances on run-time behavior.
In the case of X.509 authentication, monitoring requires
knowledge of multiple agents and their message history
(nonce usage). Tracking this within agents via assertions
poorly mixes individual agent protocol function with gen-
eral protocol security—a non-cohesive design. Instead, the
behaviors can be monitored in a separate “security agent”
that relies on the sound and general reasoning of a model
checker.
Requirements monitoring will become a necessity as
more relationships are managed through on-line transac-
tions. In the past, much effort was placed on ensuring that a
transaction completed properly. Thus, the two-phase com-
mit protocol is common place in databases. However, more
elements of transactions are being distributed across the
internet. This has led to protocols to ensure secure transac-
tions, such as STP[36]. In the future, more of us may be
depending on agents that employ complex negotiation pro-
tocols on our behalf[34][35]. Hence, we may also be
depending on security agents to ensure appropriate behav-
ior.
8. References
[1] James H. Andrews and Yingjun Zhang, "Broad-Spectrum Studies of
Log File Analysis" Proceedings of the 22nd International Conference
on Software Engineering (ICSE 2000), Limerick, Ireland, June 2000.
[2] J. H. Andrews. Testing using log file analysis: Tools, methods and
issues. In Proceedings of the 1998 International Conference on Auto-
mated Software Engineering (ASE'98), Honolulu, Hawaii, October
1998.
[3] Sergey Butkevich, Marco Renedo, Gerald Baumgartner, and Michal
Young, "Compiler and Tool Support for Debugging Object Protocols,
14 pp. (OSU-CISRC-3/00-TR10), Ohio State University.
[4] Geoff Cohen, Jeff Chase, and David Kaminsky, Automatic Program
Transformation with JOIE by in Proceedings of the 1998 USENIX
Annual Technical Symposium.
[5] Lori A. Clarke, Leon J. Osterweil, Continous Self-Evaluation for the
Self-Improvement of Software, Springer Verlag Lecture Notes in
Computer Science #1936, Proceedings of the 1st International Work-
shop on Self Adaptive Software (IWSAS 2000), pp. 27-29, April
2000, Oxford, England.
[6] Darimont, R, van Lamsweerde, A., Formal Refinement Patterns for
Goal-Driven Requirements Elaboration, ACM SIGSOFT, Fourth
Symposium on the Foundations of Software Engineering, San Fran-
cisco, CA, October 16-18, 1996.
[7] Dardenne, A., van Lamsweerde, A., Fickas, S., Goal-Directed
Requirements Acquisition, Science of Computer Programing, 20
1993, 3-50.
[8] C. Demartini, R. Iosif, R. Sisto A Deadlock Detection Tool for Con-
current Java Programs Software - Practice and Experience, Vol. 29,
No. 7, July 1999, pp. 577-603, Wiley
[9] Emmerich, W., Finkelstein, A., Montangero, C. & Stevens, R. "Stan-
dards Compliant Software Development" in Proc. International Con-
ference on Software Engineering Workshop on Living with
Inconsistency, (IEEE CS Press), 1997
[10] M. S. Feather. Rapid application of lightweight formal methods for
consistency analyses. IEEE Transactions on Software Engineering,
24(11), November 1998.
[11] Feather, M.S., Fickas, S., van Lamsweerde, A., Ponsard, C., Recon-
ciling System Requirements and Runtime Behavior, Proceedings of
the International Workshop on Software Specification and Design
0-7695-1435-9/02 $17.00 (c) 2002 IEEE
Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02)
0-7695-1435-9/02 $17.00 © 2002 IEEE
(IWSSD’98), Isobe, IEEE CS Press, April, 1998.
[12] Feather, M.S., FLEA : Formal Language for Expressing Assumptions
Language Description, June 25, 1997.
[13] Fickas, S., Feather, M.S., Requirements Monitoring in Dynamic
Environments, Proceedings of the 2nd International Symposium on
Requirements Engineering, IEEE Computer Society Press, York,
England (March 1995) 140-147.
[14] A. Girgensohn, D. Redmiles, and F. Shipman, Agent-Based Support
for Communication between Developers and Users in Software
Design. In Proceedings of the 9th Knowledge-Based Software Engi-
neering (KBSE-94) Conference, Monterey, CA: IEEE Computer
Society Press, pp. 22-29, 1994.
[15] Han Bok Lee and Benjamin G. Zorn. BIT: A Tool for Instrumenting
Java Bytecodes. In The USENIX Symposium on Internet Technolo-
gies and Systems, pages 73–82, 1997.
[16] Ann Harrison and Kathleen Ohlson, Surviving Costly Web Strikes,
ComputerWorld, IDG.com, February 21, 2000.
[17] D. Heimbold and D. Luckham. Debugging Ada tasking programs.
IEEE Software, 2(2):47{57, March 1985.
[18] Holzmann, G.J., The Model Checker Spin, IEEE, Transactions on
Software Engineering, 23, 1997, pp. 279-295.
[19] International Telecommunication Union (ITU), X.509, The Directory
- Authentication Framework, CCITT, 1989.
[20] A. Jøsang, Security protocol verification using SPIN, in J-Ch. Gre-
goire, editor, Proceedings of the First SPN Workshop, INRS-Tele-
communications, Montreal, Canada, 1995
[21] T. Kunz, J. Black, D. Taylor, and T. Basten. Poet: Target-system-inde-
pendent visualizations of complex distributed-application executions.
The Computer Journal, 40(8):499{512, September 1997.
[22] Leffingwell, D., Widrig, D., Managing Software Requirements: A
Unified Process, Addison Wesley Longman Inc., 2000.
[23] Leveson, N. G., Safeware: System Safety and Computers, Addison-
Wesley Pub. Co. Inc., 1995.
[24] J. Lilius and I. Porres Paltor. vUML: a tool for verifying UML mod-
els. Technical Report 272, Turku Centre for Computer Science, 1999.
[25] Johan Lilius and Iván Porres Paltor, The Production Cell: An Exercise
in the Formal Verification of a UML Model, TUCS Technical Report
No. 288, May 1999
[26] D. Luckham and F. vonHenke. An Overview of Anna, a Specification
language for Ada. IEEE Software, 2(2):9--22, March 1985.
[27] Lutz, R., Evolution of Safety-Critical Requirements Post-Launch,
Proceedings of the Fifth International Symposium on Requirements
Engineering, IEEE, Toronto, Canada, August 27-31, 2001, (to
appear).
[28] Manna, Z., Prueli, A., The Temporal Logic of Reactive and Concur-
rent Systems, Springer-Verlag 1992.
[29] Mazza, C., Fairclough, J., Melton, B., De Pablo, D., Scheffer, A.,
Stevens, R., Software Engineering Standards, Prentice Hall, 1994.
[30] T. O. O'Malley, D.J.Richardson, and L. K. Dillon. Efficient specica-
tion-based oracles for critical systems. In Proceedings of the Califor-
nia Software Symposium, 1996.
[31] D. K. Peters and D. L. Parnas. Using test oracles generated from pro-
gram documentation. In Proceedings of the International Symposium
on Software Testing and Analysis, 1984.
[32] S. Qiao and H. Zhang. An automatic log le analyzer for parallel pro-
grams. In H. R. Arabnia, editor, Proceedings of the International Con-
ference on Parallel and Distributed Processing Techniques and
Applications, Vol. III, pages 1371{1376, Las Vegas, Nevada, USA,
1999.
[33] Robinson, W.N., Pawlowski, S., Managing Requirements Inconsis-
tency with Development Goal Monitors, IEEE, Transactions on Soft-
ware Engineering, November/December, 1999.
[34] Robinson, W.N., Volkov, S., Supporting the Negotiation Life-Cycle,
ACM, Communications of the ACM, May 1998, pp. 95-102.
[35] Rosenschein, J., Zlotkin, G., Rules of Encounter, The MIT Press,
1994.
[36] Douglas H. Steves, Chris Edmondson-Yurkanan, Mohamed Gouda, A
Protocol for Secure Transactions, Proceedings of the Second
USENIX Workshop on Electronic Commerce (EC96) Oakland, Cali-
fornia, November 18-21, 1996.
[37] K.-C. Tai, R. H. Carver, and E. E. Obaid. Debugging concurrent Ada
programs by deterministic execution. IEEE Trans. Softw. Engineer-
ing, 17(1):45{63, January 1991.
[38] W. Visser ,K. Havelund, G. Brat and S. Park. Model Checking Pro-
grams. International Conference on Automated Software Engineer-
ing. September 2000.
[39] Wile, D., Residual Requirements and Architectural Residues, Pro-
ceedings of the Fifth International Symposium on Requirements Engi-
neering, IEEE, Toronto, Canada, August 27-31, 2001, (to appear).
10