![Run-Time Assertion Checking of Data- and
Protocol-Oriented Properties of Java Programs:
An Industrial Case Study
Frank S. de Boer1,2
, Stijn de Gouw1,2
,
Einar Broch Johnsen3
, Andreas Kohn4
, and Peter Y.H. Wong4
1
CWI, Amsterdam, The Netherlands
2
Leiden University, The Netherlands
3
University of Oslo, Norway
4
Fredhopper B.V., Amsterdam, The Netherlands
Abstract. Run-time assertion checking is one of the useful techniques
for detecting faults, and can be applied during any program execu-
tion context, including debugging, testing, and production. In general,
however, it is limited to checking state-based properties. We introduce
SAGA, a general framework that provides a smooth integration of the
specification and the run-time checking of both data- and protocol-
oriented properties of Java classes and interfaces. We evaluate SAGA,
which combines several state-of-the art tools, by conducting an industrial
case study from an eCommerce software company Fredhopper.
1 Introduction
Run-time assertion checking is one of the most useful techniques for detecting
faults, and can be applied during any program execution context, including
debugging, testing, and production [7]. Compared to program logics, run-time
assertion checking emphasizes executable specifications. Assertions in general are
clearly not executable in the sense that one cannot decide whether they hold (in
the presence of unbounded quantification). As a result, for run-time assertion
checking one has to restrict the class of assertions to executable ones. Whereas
program logics are generally applied statically to cover all possible execution
paths, which is in general undecidable, run-time assertion checking is a fully
automated, on-demand validation process which applies to the actual runs of
the program.
By their very nature, assertions are state-based in that they describe proper-
ties of the program variables, e.g. fields of classes and local variables of meth-
ods. In general, assertions as supported for example by the Java programming
language or the Java Modeling Language (JML) [3] cannot be used to specify
the interaction protocol between objects, in contrast to other formalisms such
as message sequence charts and UML sequence diagrams. Consequently, exist-
ing state-of-the-art program logics for Java are not suited for proving protocol
S. Chiba et al. (Eds.): Transactions on AOSD XI, LNCS 8400, pp. 1–26, 2014.
© Springer-Verlag Berlin Heidelberg 2014](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-14-320.jpg)
![2 F.S. de Boer et al.
properties. Moreover state-based assertions cannot be used to specify interfaces
since interfaces do not have a state1
.
The main contribution of this paper is twofold. First, we introduce SAGA
(Software trace Analysis using Grammars and Attributes), a run-time checker
that provides a smooth integration of the specification and the run-time check-
ing of both data- and protocol-oriented properties of Java classes and interfaces.
SAGA combines four different components: a state-based assertion checker, a
monitoring tool, a meta-programming tool, and a parser generator. Aspect-
oriented programming is tailored for monitoring, and in contrast to transforma-
tions source of Java code or debugger-based solutions [9] it is designed for high
performance applications and supports the monitoring of precompiled libraries
for which no source code is available. The tool can be used for run-time check-
ing of any Java program, which requires specific support for the main features
listed in Table 1, as discussed in more detail in the following section. Secondly,
we evaluate SAGA by conducting an industrial case study from the eCommerce
software company Fredhopper.
Table 1. Supported features
Constructors
Inheritance
Dynamic Binding
Overloading
Static Methods
Access Modifiers
The basic idea underlying SAGA is the representation of message sequences as
words of a language generated by a grammar. Grammars allow, in a declarative
and highly convenient manner, the description of the protocol structure of the
communication events. However, the question is how to integrate such grammars
with the run-time checking of assertions, and how to describe the data flow of a
message sequence, i.e., the properties of the data communicated. We propose a
formal modeling language for the specification of sequences of messages in terms
of attribute grammars [14]. Attribute grammars allow the high-level specification
of the data-flow of message sequences (e.g., their length) in terms of user-defined
attributes of non-terminals. SAGA supports the run-time checking of assertions
about these attributes (e.g., that the length of a sequence is bounded). This
involves parsing the generated sequences of messages. These sequences them-
selves are recorded by means of a fully automated instrumentation of the given
program by AspectJ2
.
1
JML uses model variables for interface specifications. However, a separate represents
clause is needed for a full specification, and such clauses can only be defined once
an implementation has been given (and is not implementation independent).
2
www.eclipse.org/aspectj](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-15-320.jpg)
![Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 3
2 The Modeling Framework
Abstracting from implementation details (such as field values of objects), an
execution of a Java program can be represented by its global communication his-
tory: the sequence of messages corresponding to the invocation and completion of
(possibly static) methods. Similarly, the execution of a single object can be rep-
resented by its local communication history, which consists of all messages sent
and received by that object. The behavior of a program (or object) can then be
defined as the set of its allowed histories. Whether a history is allowed depends
in general both on data (the contents of the messages, e.g. parameter and return
values of method calls) and protocol (the order between messages). The question
arises how such allowed sets of histories can be defined conveniently. In this sec-
tion we show how attribute grammars provide a powerful and declarative way
to define such sets. We use the interface of the Java BufferedReader (Figure 1)
as a running example to explain the basic modeling concepts. In particular, we
formalize the following property:
The BufferedReader may only be closed by the same object which cre-
ated it, and reads may only occur between the creation and closing of
the BufferedReader.
interface BufferedReader {
void close();
void mark(int readAheadLimit);
boolean markSupported();
int read();
int read(char[] cbuf, int off, int len);
String readLine();
boolean ready();
void reset();
long skip(long n);
}
Fig. 1. Methods of the BufferedReader Interface
As a naive first step one might be tempted to define the behavior of
BufferedReader objects simply in terms of ‘call-m(T)’ and ‘return-m(T)’
messages of all methods ‘m’ in its interface, where the parameter types T are
included to distinguish between overloaded methods (such as read). However,
interfaces in Java contain only signatures of provided methods: methods where
the BufferedReader is the callee. Calls to these methods correspond to mes-
sages received by the object. In general the behavior of objects also depends on
messages sent by that object (i.e., where the object is the caller), and on the par-
ticular constructor (with parameter values) that created the object. Moreover,](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-16-320.jpg)
![4 F.S. de Boer et al.
it is often useful to select a particular subset of method calls or returns, instead
of using calls and returns to all methods (a partial or incomplete specification).
Finally, in referring to messages it is cumbersome to explicitly list the parameter
types. A communication view addresses these issues.
2.1 Communication View
A communication view is a partial mapping which associates a name to each mes-
sage. Partiality makes it possible to filter irrelevant events and message names
are convenient in referring to messages.
Suppose we wish to specify that the BufferedReader may only be closed
by the same object which created it, and that reads may only occur between
the creation and closing of the BufferedReader. This is a property which must
hold for the local history of all instances of java.util.BufferedReader. The
communication view in Figure 2 selects the relevant messages and associates
them with intuitive names: open, read, and close.
local view BReaderView grammar BReader.g
specifies java.util.BufferedReader {
BufferedReader(Reader in) open,
BufferedReader(Reader in, int sz) open,
call void close() close,
call int read() read,
call int read(char[] cbuf, int off, int len) read
}
Fig. 2. Communication view of a BufferedReader
All return messages and call messages methods not listed in the view are fil-
tered. Note how the view identifies two different messages (calls to the overloaded
read methods) by giving them the same name read. Though the above communi-
cation view contains only provided methods (those listed in the BufferedReader
interface), required methods (e.g., methods of other interfaces or classes) are also
supported. Since such messages are sent to objects of a different class (or inter-
face), one must include the appropriate type explicitly in the method signature.
For example consider the following message:
call void C.m() out
If we would additionally include the above message in the communication view,
all call-messages to the method m of class C sent by a BufferedReader would
be selected and named out. In general, incoming messages received by an ob-
ject correspond to calls of provided methods and returns of required methods.
Outgoing messages sent by an object correspond to calls of required methods](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-17-320.jpg)
![Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 7
S ::= open C1 {assert (open.caller == null || open.caller == C1.c ||
C1.c == null);}
|
C ::= read C1 (C.c = C1.c;)
| close S (C.c = close.caller;)
| (C.c = null;)
Fig. 4. Attribute Grammar which specifies that ‘read’ may only be called in between
‘open’ and ‘close’, and the reader may only be closed by the object which opened it
Assertions can be placed at any position in a production rule and are evalu-
ated at the position they were written. Note that assertions appearing directly
before a terminal can be seen as a precondition of the terminal, whereas post-
conditions are placed directly after the terminal. This is in fact a generalization
of traditional pre- and post-conditions for methods as used in design-by-contract:
a single terminal ‘call-m’ can appear in multiple productions, each of which is fol-
lowed by a different assertion. Hence different preconditions (or post-conditions)
can be used for the same method, depending on the context (grammar produc-
tion) in which the event corresponding to the method call/return appears.
Attribute grammars in combination with assertions cannot express protocol
that depend on data. Such protocols are common, for instance, the method next
of an Iterator may not be called if directly hasNext was called directly before
and returns false. To express protocols depending on data we consider attribute
grammars enriched by conditional productions [18]. In such grammars, a pro-
duction is chosen only when the given condition (a boolean expression over the
inherited attributes) for that production is true. Hence conditions are evaluated
before any of the symbols in the production are parsed, before synthesized at-
tributes of the non-terminals appearing in the production are set and before
assertions are evaluated. In contrast to assertions, conditions in productions af-
fect the parsing process. The Worker.g grammar in the case study contains a
conditional production for the ‘T’ non-terminal.
2.3 Discussion
We now briefly motivate our choice of attribute grammars extended by assertions
as specifications and discuss its advantages over alternative formalisms.
Instead of context-free grammars, we could have selected push-down automata
to specify protocol properties (formally these have the same expressive power).
Unfortunately push-down automata cannot handle attributes. An extension of
push-down automata with attributes results in a register machine. From a user
perspective, the declarative nature and higher abstraction level of grammars
(compared to the imperative and low-level nature of automata) makes them
much more suitable than automata as a specification language. In fact, a push-
down automaton which recognizes the same language as a given grammar is an
implementation of a parser for that grammar.](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-20-320.jpg)
![8 F.S. de Boer et al.
Both the BufferedReader above and the case study use only regular grammars.
Since regular grammars simplify parsing compared to context-free grammars, the
question arises if we can reasonably restrict to regular grammars. Unfortunately
this rules out many real-life use cases. For instance, the following grammar in
EBNF specifies the valid protocol behavior of a stack:
S ::= (push S pop ?)*
It is well known that the language generated by the above grammar is not
regular, so regular grammars (without attributes) cannot be used to enforce the
safe use of a stack. It is possible to specify the stack using an attribute which
counts the number of pushes and pops:
S ::= S1 push (S.cnt = S1.cnt + 1)
| S1 pop (S.cnt = S1.cnt − 1){assert S.cnt = 0; }
| (S.cnt = 0)
The resulting grammar is clearly less elegant and less readable: essentially it en-
codes (instead of directly expresses, as in the grammar above) a protocol-oriented
property as a data-oriented one. The same problem arises when using regular
grammars to specify programs with recursive methods. Thus, although theoreti-
cally possible, we do not restrict to regular grammars for practical purposes.
Ultimately the goal of run-time checking safety properties is to prevent unsafe
ongoing behavior. To do so, errors must be detected as soon as they occur and
the monitor must immediately terminate the system: it cannot wait until the
program ends to detect errors. In other words, the monitor must decide after
every event whether the current history is still valid. The simplest notion of
a valid history (one which should not generate any error) is that of a word
generated by the grammar. One way of fulfilling the above requirement, assuming
this notion of validity, is to restrict to prefix-closed grammars. Unfortunately, it
is not possible to decide whether a context-free grammar is prefix-closed. The
following lemmas formalize this result:
Lemma 1. Let LM be the set of all accepting computation histories3
of a Turing
Machine M. Then the complement LM is a context-free language.
Proof. See [20].
Lemma 2. It is undecidable whether a context-free language is prefix-closed.
Proof. We show how the halting problem for M (which is undecidable) can be
reduced to deciding prefix-closure of LM . To that end, we distinguish two cases:
1. M does not halt. Then LM is empty so LM is universal and hence prefix-
closed.
3
A computation history of a Turing Machine is a sequence C0#C1#C2# . . . of con-
figurations Ci. Each configuration is a triple consisting of the current tape contents,
state and position of the read/write head. Due to a technicality, the configurations
with an odd index must actually be encoded in reverse.](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-21-320.jpg)
![Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 9
2. M halts. Then there is an accepting history h ∈ LM (and h /
∈ LM ). Extend
h with an illegal move (one not permitted by M) to the configuration C,
resulting in the history h#C. Clearly h#C is not a valid accepting history,
so h#C ∈ LM . But since h /
∈ LM , LM is not prefix-closed.
Summarizing, M halts if and only if LM is not prefix-closed. Thus if we could
decide prefix-closure of the context-free language (lemma 1) LM , we could decide
whether M halts.
Since prefix-closure is not a decidable property of grammars (not even if they
don’t contain attributes) we propose the following alternative definition for the
valid histories. A communication history is valid if and only if it and all its
prefixes are generated by the grammar. Note that this new definition naturally
fulfills the above requirement of detecing errors after every event. And further-
more, this notion of validity is decidable assuming the assertions used in the
grammar are decidable. As an example of this new notion of validity, consider
the following modification of the above grammar:
T ::= S {assert S.cnt = 0; }
S ::= S1 push (S.cnt = S1.cnt + 1)
| S1 pop (S.cnt = S1.cnt − 1)
| (S.cnt = 0)
Note that the history push pop is a word generated by this grammar, but not its
prefix pop, which as such will generate an error (as required). Note that thus in
general invalid histories are guaranteed to generate errors. On the other hand,
if a history generates an error all its extensions are therefore also invalid.
Observe that our approach monitors only safety properties (‘prevent bad be-
havior’), not liveness (‘something good eventually happens’). This restriction is
not specific to our approach: liveness properties in general cannot be rejected
on any finite prefix of an execution, and monitoring only checks finite prefixes
for violations of the specification. Most liveness properties fall in the class of
the non-monitorable properties [2,19]. However it is possible to ensure liveness
properties for terminating programs: they can then be reformulated as safety
properties. For instance, suppose we want to guarantee that a method void m()
is called before the program ends. Introduce the following global view:
global view livenessM {
call void C.m() m,
return static void C.main(String[]) main
}
The occurence of the ‘main’ event (i.e., a return of the main method of the
program) signifies the program is about to terminate. Define the EBNF grammar
S ::= | m | m+ main](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-22-320.jpg)
![Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 11
Java objects. Consequently the target language for the parser generator must
be Java, and it must support executing user-defined Java code to define the
attribute value in rule actions. The use of Java code to define attribute values
ensures they are computable. Furthermore, assertions are allowed in-between
any two (non)-terminals, thus the parser generator should support user-defined
actions between arbitrary grammar symbols. Once the parser is generated, it is
triggered whenever the history of an object is updated.
During parsing, the state-based assertion checker proceeds to evaluate the
assertions in the grammar on the newly computed attribute values. The result is
either a parse or assertion error, which indicates that the current communication
history has violated the specification in the attribute grammar, or a parse tree
with new attribute values.
3.2 Implementation
In this section we instantiate each of the four different components (meta-
programming, monitoring tool, parser generator, and state-based run-time as-
sertion checker) with a state-of-the art tool. We report on our experiences with
the particular tools and discuss the extent to which the previously formulated
requirements are fulfilled.
Rascal [13] is a powerful tool-supported meta-programming language tailored
for program analysis, program transformation, and code generation. We have
written a Rascal program of approximately 600 lines in total which generates the
token class for each message in the view, and generates glue code to trigger the
AspectJ and parser at the appropriate times. Overall our experience with Rascal
was quite positive: its powerful parsing, pattern matching, and transforming
concrete syntax features were indispensable in the implementation of SAGA.
As the parser generator we tested ANTLR [17], a state-of-the-art parser gen-
erator. It generates fast recursive descent parsers for Java, has direct support
for both synthesized and inherited attributes, it supports grammars in EBNF
form and most importantly allows a custom stream of token classes. It even sup-
ports conditional productions: such productions are only taken during parsing
whenever an associated Boolean expression (the condition) is true. Attribute
grammars with conditional productions express protocols that depend on data,
and typically are not context-free. The worst-case time complexity any parser
ANTLR generates is quadratic in the number of tokens to parse. The main draw-
backs of ANTLR are that it can only handle LL(*) grammars4
, and its lack of
support for incremental parsing, though support for incremental is planned by
the ANTLR developers. An incremental parser computes a parse tree for the
new history based on the parse trees for prefixes of the history. In our setting,
since the attribute grammar specifies invariant properties of the ongoing behav-
ior, a new parse tree is computed after each call/return, hence parse trees for
all prefixes of the current history can be exploited for incremental parsing [11].
4
A strict subset of the context-free grammars. Left-recursive grammars are not LL(*).
A precise definition can be found in [17].](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-24-320.jpg)
![12 F.S. de Boer et al.
We have not been able to find any Java parser generator which supported general
context-free grammars and incremental parsing of attribute grammars.
We have tested two state-based assertion languages: standard Java assertions
and the Java Modeling Language (JML). Both languages suffice for our pur-
poses. JML is far more expressive than the standard Java assertions, though
its tool support is not ready for industrial usage. In particular, the last stable
version of the JML run-time assertion checker dates back over 8 years, when
for example generics were not supported yet. The main reason is that JML’s
run-time assertion checker only works with a proprietary implementation of the
Java compiler, and unsurprisingly it is costly to update the propietary compiler
each time the standard compiler is updated. This problem is recognized by the
JML developers [4]. OpenJML5
, a new pre-alpha version of the JML run-time
assertion checker integrates into the standard Java compiler, and initial tests
with it provided many valuable input for real industrial size applications. See
the Sourceforge tracker for the kind of issues we have encountered when using
OpenJML.
Fig. 5. SAGA Tool Architecture
Aspects. AspectJ is tailored for monitoring. It can intercept method calls and
returns conveniently with pointcuts, and weave in user-defined code (advices)
which is executed before or after the intercepted call. In our case the pointcuts
correspond to the calls and returns of the messages listed in the communication
view. The advice consists of code which updates the history. The code for the
aspect is generated from the communication view automatically by the Rascal
5
jmlspecs.sourceforge.net](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-25-320.jpg)
![Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 13
meta-program. Advice is woven into Java source code, byte code, or at class
load-time fully automatically by AspectJ. We use the inter-type declarations of
AspectJ to store the local history of an object as a field in the object itself.
This ensures that whenever the object goes out of scope, so does its history
and consequently reduces memory usage. Clearly the same does not hold for
global histories, which are stored inside a separate Aspect class. Figure 6 shows
a generated aspect. The second and third lines specify the relevant method. The
fourth line binds variables (‘clr’, ‘cle’, ...) to the appropriate objects. The fifth
line ensures that the aspect is applied only when Java assertions are turned on.
Assertions can be turned on or off for each communication view individually.
The fifth line contains the advice that updates the history. Note that since the
event came was defined in a local view, the history is treated as a field of the
callee (and will not persist in the program indefinitely but rather is garbage
collected as soon as callee object itself is).
/∗ call int read(char[] cbuf, int off, int len); ∗/
before(Object clr, BufferedReader cle, char[] cbuf, int off, in len):
(call( int *.read(char[], int, int))
this(clr) target(cle) args(cbuf, off, len)
if(BReaderHistoryAspect.class.desiredAssertionStatus() )) {
cle.h.update(new call_push(clr, cle, cbuf, off, len));
}
Fig. 6. Aspect for the event ‘call int read(char[] cbuf, int off, int len)’
We have investigated two alternatives for the monitoring component not based
on aspect-oriented programming: Rascal and Sun’s implementation of the Java
Debugging Interface. With Rascal one can weave advice by defining a transfor-
mation on the actual Java source code of the program to test. This requires
a full Java grammar (which must be kept in sync with the latest updates to
Java). To capture the identity of the callee, parameter values and return value
of a method, one only needs to transform that particular method (i.e., locally).
But inside the method there is no way to access the identity of the caller. Java
does offer facilities to inspect stack frames, but these frames contain only static
entities, such as the name of the method which called the currently executing
method, or the type of the caller, but not the caller itself. To capture the caller,
a global transformation at all call-sites is needed (and in particular one needs to
have access to the source code of all clients which call the method). The same
problem arises in monitoring calls to required methods. Finally, it proved to
quickly get very complex to handle all Java features. We wrote an initial ver-
sion of a weaver in Rascal which already took over 150 lines (over half of the
full checker at the time) without supporting method calls appearing inside ex-
pressions, inheritance and dynamic binding. This approach is also unsuitable for](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-26-320.jpg)
![Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 23
for Java-Like Programs 2010 and appeared in its informal proceedings7
. In the
current paper we apply and evaluate a new version to an industrial case study
and succesfully integrate SAGA into the quality assurance process of Fredhopper.
Based on this application and evaluation we extended our framework to support
a more general class of grammars to specify data-dependent protocol behavior.
Furthermore, The new version features a tighter integration of attribute grammars
and assertions. Finally the support for the features listed in Table 1 is new.
There exist many other interesting approaches to monitoring message se-
quences, none of which address their integration with the general context of
run-time assertion checking. Consequently, all the other approaches only allow
a combination of a very restricted class of data-oriented properties and protocol
properties. For example, Martin et al. [15] introduce a Program Query Language
(PQL) for detecting errors in sequences of communication events. PQL was up-
dated last in 2006 and does not support user-defined properties of data. Allan
et al. [1] develop an extension of AspectJ with a history-based language fea-
ture called Tracematches that enables the programmer to trigger the execution
of extra code by specifying a regular pattern of events in a computation trace.
The underlying pattern matching involves a binding of values to free variables.
Nobakht et al. [16] monitors calls and returns with the same Java Debugger
Architecture we have also evaluated in the implementation section. The debug-
ger is very slow compared to aspect-oriented approaches. Their specification
language is equivalent in expressive power to regular expressions. Because the
grammar for the specifications is fixed, the user cannot specify a convenient
structure themselves, and data is not considered. Chen et al. [5] present Java-
MOP, a run-time monitoring tool based on aspect-oriented programming which
uses context-free grammars to describe properties of the control flow of histories.
However, properties on the data-flow are predefined built-in functions (basically
AspectJ functions such as a ‘target’ to bind the callee and ‘this’ to bind the
caller, comparable to built-in attributes of terminals in our setting). This limits
the expression of data properties. Though, to circumvent this limitation one may
hack general properties into the tool implementation. In contrast, our approach
supports a general methodology to introduce systematically user-defined prop-
erties, by means of attributes of non-terminals. Furthermore, SAGA supports
conditional productions which are essential to specify protocols dependent on
data in a declarative manner. Finally, JavaMOP does not directly support the
specification of local histories (i.e., monitoring the messages sent and received
by a single object). LARVA is developed by Colombo et al. [8]. The specification
language has an imperative flavor: users define a finite state machine to define
the allowed history (i.e., one has to ‘implement’ a regular expression themselves).
It is not possible to directly express context-free protocols. Data properties are
supported, though in a limited manner, by enriching the state machine with con-
ditions on method parameters or return values. It is not possible to specify a local
7
Available in the ACM Digital Library with the title Prototyping a tool environment
for run-time assertion checking in JML with communication histories, authored by
Frank S. de Boer, Stijn de Gouw and Jurgen Vinju](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-36-320.jpg)
![24 F.S. de Boer et al.
history of a single object. DeLine and Fähndrich [10] propose a statically check-
able typestate system for object-oriented programs. Typestate specifications of
protocols correspond to finite state machines (assertions are not considered in
their approach), thus for example a stack cannot be properly specified.
To the best of our knowledge, no other approach integrates protocol-oriented
properties into existing state-based assertion languages. The integration does not
involve an extension of the syntax and semantics of the assertion language itself.
As an important consequence, no change in the implementation of the state-
based assertion checker is needed, in contrast to the following works. Cheon and
Perumandla present in [6] an extension of the JML compiler with call sequence
assertions. Call sequence assertions are regular expressions (proper context-free
grammars cannot be handled) over method names and the data sent in calls
and returns is not considered. Protocol properties (call sequence assertions) are
handled separately from data properties, and as such are not integrated into the
general context of (data) assertions. The proposed extension to call sequence
assertions involves changing the existing JML-compiler (in particular, both the
syntax and the semantics of JML assertions are extended), whereas in our test
suite integrating with JML consists only of a simple pre-processing stage. Con-
sequently in our approach no change in the JML-compiler is needed, and new
versions of the JML-compiler are supported automatically, as long as they are
backwards compatible. Hurlin [12] presents an extension of the previous work to
handle multi-threading, which however is not supported by run-time verification
(instead it discusses static verification). As in the previous work, an integration
of protocol properties with assertions is not considered. Trentelman and Huis-
man [21] describe a new formalism extending JML assertions with Temporal
Logic operators. A translation for a subset of the Temporal Logic formulae back
to standard JML is described, and as future work they intend to integrate their
extension into the standard JML-grammar which requires a corresponding new
compiler.
Future Work. SAGA visualizes the offending history of a Java program that
violates the given attribute grammar in the form of a UML sequence diagram.
For industrial applications the histories (and consequently the corresponding
diagram) can get very large, even when projecting away irrelevant events with
the communication view. In such cases we found it is very useful to (further)
filter events from the diagram, focussing on a specific part of the diagram. For
instance, only showing all events in which a particular object was involved. The
sequence diagram editor used by SAGA provides preliminary support for filtering
using low-level UNIX system-based utilities grep and sed, but more high-level
solutions specifically tailored for sequence diagrams would be even more useful.
Furthermore, for debug purposes it would be convenient to visualize the current
contents of the heap.
Another line of future work concerns offline monitoring. Offline monitoring
serializes and stores the history of a running program in a file. This file is checked
later for correctness, possibly on a different computer. This allows companies to
enable monitoring production code deployed at clients with little performance](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-37-320.jpg)
![Event Modules
Modularizing Domain-Specific Crosscutting RV Concerns
Somayeh Malakuti1
and Mehmet Akşit2
1
Software Technology Group, Technical University of Dresden, Germany
somayeh.malakuti@tu-dresden.de
2
Software Engineering Group, University of Twente, The Netherlands
m.aksit@utwente.nl
Abstract. Runtime verification (RV) facilitates detecting the failures of
software during its execution. Due to the complexity of RV techniques,
there is an increasing interest in achieving abstractness, modularity, and
compose-ability in their implementations by means of dedicated linguis-
tic mechanisms. This paper defines a design space to evaluate the existing
domain-specific languages for implementing RV techniques, and identifies
the shortcomings of a representative set of these languages with respect
to the design space. This paper advocates the need for a language com-
position framework, which offers the necessary mechanisms to achieve
abstractness, modularity, and compose-ability in the implementation of
domain-specific crosscutting concerns such as the concerns of RV tech-
niques. We explain event modules as novel linguistic abstractions for
modular implementation of domain-specific crosscutting concerns. This
paper discusses the implementation of event modules in the EventRe-
actor language, and illustrates the suitability of event modules to imple-
ment RV techniques by means of two complementary examples.
Keywords: runtime verification, domain-specific languages, aspect-
orientation, event-based modularization, event-based composition.
1 Introduction
Runtime verification (RV) [1] aims at checking software against its desired prop-
erties while the software is executed, e.g., during testing or after it is deployed.
Depending on the result of the verification process, various actions may be car-
ried out such as notification, suspending execution, fault recovery, etc. In this
paper, the term RV technique refers to the program that implements the func-
tionality of the runtime verification, and the term base software refers to the
software that is being verified by such a technique.
To apply RV techniques to real-world complex base software, there is a need
for suitable implementation mechanisms/frameworks that ease the implementa-
tion of these techniques for industrial practitioners. One may argue that RV tech-
niques can be implemented directly as an integral part of the base software in
the same general-purpose language (GPL) as the base software. However, this re-
quires programmers to have extensive knowledge about suitable algorithms and
S. Chiba et al. (Eds.): Transactions on AOSD XI, LNCS 8400, pp. 27–69, 2014.
c
Springer-Verlag Berlin Heidelberg 2014](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-40-320.jpg)
![28 S. Malakuti and M. Akşit
mechanisms to implement RV techniques in a GPL. Moreover, the implementa-
tion of both base software and RV techniques can easily become complex and hard
to comprehend. This is because RV techniques usually crosscut [2] the base soft-
ware, meaning that they need to interact with various different parts of the base
software to collect the necessary information and/or to heal them from failures.
The aforementioned problems in implementing RV techniques motivate
language designers to seek suitable linguistic constructs for implementing RV
techniques. A close look at the literature [3–14], lets us observe that achiev-
ing abstractness, modularity, and compose-ability is of interest in the im-
plementation of RV techniques. The abstractness requirement is addressed by
providing suitable domain-specific languages (DSLs) for implementing RV tech-
niques. The modularity requirement is addressed by providing means to modu-
larize individual concerns of RV techniques from each other and from the base
software. The compose-ability requirement is addressed by providing suitable op-
erators to compose individually modularized RV concerns with each other and
with the base software under the specified constraints.
Although several RV DSLs have been introduced in the literature and this
trend seems to be continuing, they fall short of fulfilling the abstractness, mod-
ularity, and compose-ability requirements. To be able to identify the source of
their shortcomings, this paper identifies the concerns that typically appear in
RV techniques, defines a design space for the RV DSLs, and evaluates a repre-
sentative set of current RV DSLs with respect to this design space.
To overcome the identified shortcomings, this paper identifies characteristic
features of RV techniques, and introduces Event Composition Model, which
offers event modules as novel linguistic abstractions to achieve abstractness,
modularity, and compose-ability in the implementation of domain-specific cross-
cutting concerns such as the concerns that exist in RV techniques. This paper
explains EventReactor as a language composition framework that implements
Event Composition Model, and by means of two examples, shows the suitability
of EventReactor for implementing various kinds of RV techniques.
In this paper we extend our previous work [15, 16] in the following ways:
– We study a large number of RV DSLs and derive a conceptual model for RV
techniques.
– We present a mind map of the design space for RV DSLs which facilitates
the comparison of current RV DSLs.
– We evaluate a representative set of RV DSLs and identify their shortcomings
in fulfilling abstractness, modularity, and compose-ability in the implemen-
tation.
– We define a new version of Event Composition Model, in which domain-
specific concerns can be modularized and composed better.
– We present its implementation, EventReactor, which covers the design space.
– We demonstrate the suitability of EventReactor to achieve abstractness,
modularity, and compose-ability in the implementation by means of two
comprehensive examples.
– We present our evaluation of the runtime overhead of EventReactor.](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-41-320.jpg)
![Modularizing Domain-Specific Crosscutting RV Concerns 29
This paper is organized as follows: Section 2 elaborates on the problem state-
ment; Section 3 discusses the requirements for an RV language composition
framework and explains Event Composition Model. Sections 4 and 5 explain the
EventReactor language and its runtime behavior, respectively. Section 6 illus-
trates the expressiveness of event modules by means of an example. Section 7
discusses the runtime overhead of EventReactor, and Sections 8 and 9 outline
the discussion and future work, respectively.
2 Problem Statement
While RV techniques can be implemented in a GPL and can manually be applied
to the base software during the software development process, there is an increas-
ing interest to have DSLs [3–14] for this matter so that the implementation of RV
concerns become more abstract and declarative, and the implementation effort
is reduced. A closer look at the existing RV DSLs lets us observe three require-
ments that are typically considered important in the design of these DSLs: a)
abstractness, b) modularity, and c) compose-ability of implementations.
The abstractness requirement indicates that suitable domain-specific con-
structs are needed to implement various kinds of concerns that appear in RV
techniques in a declarative, concise, and abstract manner; this is in fact one of
the main goals of adopting DSLs instead of GPLs.
In the literature [17], a module is defined as a reusable software unit with
well-defined interfaces, which encapsulates its implementation. The modularity
requirement indicates that a language must facilitate representing individual
concerns that appear in an RV technique as individual modules with well-defined
interfaces. The interfaces express the information that the modules provide and
require from the other modules for the purpose of runtime verification. The
internal implementation of these modules, which is expressed in a DSL, must be
encapsulated. If a language falls short to provide a one-to-one mapping between
a concern of interest and the modules of a program, the implementation of the
concern scatters across and tangles with the implementation of other concerns
in the program [18]. Scattering and tangling are well-known problems in the
aspect-oriented community [2], which reduce the modularity and increase the
complexity of programs.
The compose-ability requirement means that a language must offer suitable
mechanisms to compose individually modularized RV concerns with each other
so that the target RV technique is achieved. The example composition mecha-
nisms are explicit method invocation, implicit invocation by means of events, and
inheritance. The composition may be constrained, and the constraints must also
be modularized and programmed in their DSLs. There are plenty of legacy soft-
ware systems whose functionality must be extended with RV. Thus modularity
and compose-ability must also be considered from the perspective of separating
the implementation of RV concerns from the base software and composing these
two into an executable system.](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-42-320.jpg)
![30 S. Malakuti and M. Akşit
To be able to identify the degree to which the aforementioned requirements
are fulfilled by the current RV DSLs, in this section we first identify the typical
concerns that appear in RV techniques, derive a design space for RV DSLs, and
accordingly, we identify the shortcomings of a representative set of RV DSLs.
Finally, we illustrate the shortcomings by means of an example.
2.1 Typical Concerns in RV Techniques
Our comprehensive study on the current RV techniques and DSLs [3–14, 19, 20],
reveals that four kinds of concerns typically appear in RV techniques: Base Soft-
ware, Observation, Verification, and Action. Figure 1 represents the interactions
among these concerns.
– Base Software is the software whose correctness must be ensured by an RV
technique.
– Observation is the concern that abstracts the necessary information for the
purpose of runtime verification from the base software. This information can
be, for example, the invocation of a method, the value of a variable that is
updated, etc.
– Verification is the concern that checks the expected and/or unexpected prop-
erties of the base software; for this matter, it receives the necessary infor-
mation from the base software. The verification of the specified properties
results in new information, for example, indicating whether the properties
are satisfied or violated.
base
information
verification
information
adaptation
information
base
information
Fig. 1. Typical concerns in RV techniques
– Action represents what needs to be performed as the result of verification.
Typical examples are diagnosing the causes of failure and recovering the
base software from failures [19, 20]. Actions are triggered by the verification
concerns, and may exchange information with the base software, for example,
for the purpose of recovery.
As Figure 1 shows, in general, RV concerns have a crosscutting [2] nature.
For example, the observation concerns may crosscut the base software to receive
the information from various places in the base software. Likewise, actions may](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-43-320.jpg)
![Modularizing Domain-Specific Crosscutting RV Concerns 33
Specification of Observation Concerns: An RV DSL may offer dedicated
constructs to specify the information that must be abstracted from the base
software. This information can be in form of events and/or data values. As Ta-
ble 1 shows, MaCS [3], PQL [11], Polymer [12], JavaMOP [4], Tracematches [13],
RMOR [5], and E-Chaser [10] offer a predefined set of dedicated linguistic con-
structs for this matter. Among these languages, only the constructs offered by
E-Chaser are independent of the language of base software.
TraceContract [14], is an internal DSL [21] which makes use of the libraries
offered by the Scala programming language. In TraceContract, the observable
information is defined as events, and new kinds of events can be defined. However,
as it is inherent for internal DSLs, the specifications are dependent on the GPL
in which the internal DSLs are defined. JASS [6], APP [9], Temporal Rover [7],
and Spec# [8] do not offer any construct to define the specification of observation
concerns. In these languages, the verification concerns and actions are embedded
in the base software, and refer to the variables defined within the base software.
Along the modularity dimension, MaCS facilitates modularizing the specifi-
cations through so-called PEDL (Primitive Event Definition Language) specifi-
cations. In JavaMOP, PQL, and Tracematches, the specification of observation
concerns is separated from the base software; however, these specifications are
tangled with the verification concerns and actions within one module. Polymer
facilitates the modularization of specifications by offering so-called action mod-
ules, which closely resemble Java classes. In RMOR, the specification of observa-
tion concerns can be expressed separately from the specification of verification
concerns and actions. E-Chaser facilitates the modularization of specification
by means of the so-called superimposition specifications. In TraceContract, the
specifications can be modularized using the modularization mechanism offered
by Scala.
With respect to the compose-ability dimension, MaCS facilitates compos-
ing primitive fields and variables via Boolean operators. Tracematches adopts
the pointcut language of AspectJ [22] to express the specification of observa-
tion concerns, and supports Boolean operators to compose pointcut expressions.
Similarly, RMOR offers a pointcut language similar to the one in AspectJ or
AspectC [23], and supports Boolean operators to compose pointcut expressions.
JavaMOP extends the pointcut language of AspectJ with two new predicates;
AspectJ pointcuts can be composed with each other via Boolean operators; the
JavaMOP-specific predicates can be composed with each other and with AspectJ
ones via the conjunction operator. The other languages do not offer constructs
for programming the abstracted information with each other.
Specification of Verification Concerns (Properties): As Table 2 shows,
all investigated RV DSLs offer dedicated formalisms to specify the properties
to be verified. Among these, JavaMOP, E-Chaser, and TraceContract are pro-
grammable with new kinds of formalism. Only MaCS, E-Chaser, RMOR, and
Tracematches facilitate specifying the verification concerns independently from](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-46-320.jpg)
![36 S. Malakuti and M. Akşit
2.4 Illustration of the Shortcomings
Since the existing RV DSLs do not span the full design space, the abstractness,
modularity, and compose-ability requirements cannot be fulfilled in the imple-
mentation of RV techniques if these languages are adopted. In this section, we
illustrate these shortcomings by the example of a document-editing software to
which runtime verification must be applied.
The document-editing software has the three core modules Authentication,
DocumentManager, and Storage. These provide the functionality to authenti-
cate users, to edit a document, and to save its contents on the file system,
respectively. Authentication and DocumentManager are implemented in Java,
and Storage is implemented in C. Figure 3 shows a UML sequence diagram
that depicts the sequence of causally dependent invocations that handle a save
request issued by the user. Here, the user first logs in to the system, by invoking
the method login on the object anAuthentication. Then, eventually, s/he starts
a save operation by invoking the method save on the object aDocumentManager
of type DocumentManager. Subsequently, the functions open, write, and finally
close are invoked on Storage. The user eventually logs out from the application.
For the sake of brevity, we omitted the objects that facilitate inter-language
communication. We assume that each user modifies one document at a given
time, and that the request to modify the document is handled in one causal
thread of execution that spans across anAuthentication, aDocumentManager,
and Storage.
Assume that we would like to verify the sequence of invocations depicted in
Figure 3, to ensure that a request to save a document by an authenticated user
eventually results in storing the document on the file system. There are two kinds
of failure. First, the save request is issued by an un-authenticated user. Second,
after invocation of save by an authenticated user, any of the other invocations
does not occur in the specified order before the user logs out. As recovery actions,
we would like to first log an error message and then prevent the execution of the
method whose invocation violates the specified sequence.
We consider two possibilities for implementing the aforementioned runtime
check using the available RV DSLs: (a) using a single RV DSL, and (b) using a
different RV DSL for each base implementation language.
If we would like to adopt a single RV DSL, the linguistic constructs of the RV
DSL must be sufficiently abstract to express runtime behavior of base programs
implemented in various different languages. As Table 1 shows, only E-Chaser fa-
cilitates abstracting information from the base software implemented in different
languages. However, as we show in [10], E-Chaser cannot preserve the modular-
ity of specifications for the base software implemented in multiple languages.
Moreover, it cannot verify the causal-dependency of the invocations that span
across modules implemented in different languages.
Alternatively, we would like to use a different RV DSL for each language envi-
ronment. To implement the running example, we use JavaMOP for the Java part](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-49-320.jpg)
![Modularizing Domain-Specific Crosscutting RV Concerns 39
Event Composition Model that is a base model for such a framework, and dis-
cusses its suitability for this matter.
3.1 Characteristic Features of RV Concerns
A closer look at the model depicted in Figure 1 and the languages discussed in
the previous section reveals the following characteristic features of RV concerns.
First, the interactions among the concepts of RV techniques have by nature
a transient characteristic, meaning that the changes in the states of a concern
drive the other concerns. For example, the verification concerns observe the
changes that occur in the states of the base software, and verify the state changes
of interest against the specified properties of the base software. Various RV
techniques may require to consider various kinds of state changes; examples are
a time-out value, and an invocation of a method on an object. This implies
that an RV language composition framework must facilitate defining open-ended
kinds of state changes in the base software as well as in RV concerns.
Second, it is not easy or even possible to foresee all kinds of concerns that
appear in the RV techniques of today or in future. For example, some techniques
require to specify and verify the sequence of method invocations in the base
software, whereas some others may require to specify and verify the properties
of operating system processes. The steady development of new RV DSLs that
support new kinds of formalisms to specify the properties is a consequence of this.
Therefore, as the second requirement, we claim that an RV language composition
framework must facilitate implementing open-ended kinds of RV concerns such
that the specifications are modular.
Third, although Figure 1 shows a fixed hierarchy of concerns, in a general
case, the kinds of compositions cannot be fixed. For example, an RV technique
itself may be considered as the base software whose behavior must be checked
at runtime, a specification may be composed of multiple sub-specifications, etc.
This indicates that an RV language composition framework must facilitate im-
plementing open-ended kinds of compositions.
Finally, due to the increasing number of multi-language software systems (e.g.,
embedded software) to which RV techniques must be applied, an RV language
composition framework must support open-ended sets of base languages.
3.2 Event Composition Model
In [15, 16], we introduced Event Composition Model as a model, which respects
the aforementioned characteristic features. In this section, we explain a revised
version of this model whose concepts are shown in Figure 4 via a UML class
diagram.
At a high level of abstraction, Event Composition Model considers the exe-
cution Environment as a set of Events and Event Modules. In software systems,
events typically represent changes in the states of interest and are means for
abstracting the execution trace of programs. As the class Event Type shows,](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-52-320.jpg)
![Modularizing Domain-Specific Crosscutting RV Concerns 41
Two kinds of interfaces, known as input and output, are typically considered
for a module. The former defines the services that a module requires from its
context; the latter specifies the services that a module provides to its context.
A module also has an implementation part, which is bound to its interfaces
to provide the specified interfaces. Modules promote encapsulation by utilizing
interfaces as their interaction points with their context.
As Figure 4 shows, event modules adhere to the above definition of modules
in the following ways. An event module is identifiable and referable by its unique
name. An event module has an Input Interface, an implementation – which is
termed as Reactor Chain–, and an Output Interface; these elements are bound
to each other.
The input interface of an event module specifies the set of events of interest
to which the event module must react. Event Composition Model does not fix
the semantics for selecting the events of interest and for binding them to the
input interface of an event module. One important difference between the input
interface of modules in programming languages and the input interface of event
modules is that in programming languages input interfaces are invoked explicitly,
whereas in event modules invocations are implicit. The explicit invocation means
that programmers write code for invoking the input interface of a module. In
contrast, implicit invocation [24] means that there is no need for such code, and
when an event of interest occurs, the corresponding event module is activated
by the language composition framework.
Figure 4 shows that the implementation of an event module contains a set of
Reactors and Variables. Each reactor processes (a subset of) the events specified
in the input interface of the event module. Reactors are typed entities; a Reactor
Type is a domain-specific type that defines the semantics in processing the events
of interest.
Reactors can be composed with each other within a reactor chain. Such reac-
tors can exchange information among each other via the variables defined within
the corresponding reactor chain. While processing an input event, a reactor may
publish new events, which are termed as reactor events. Via the attribute inner
a reference to the input event being processed by the reactor is maintained.
The output interface of an event module defines the set of events that are
published by the event module to its context. To be able to process events,
event modules are instantiated during the execution of software based on some
Instantiation Strategy; the strategies can be programmed according to the ap-
plication/domain demands.
3.3 Motivations to Adopt Event Composition Model
Event Composition Model respects the characteristic features of RV concerns
identified in Section 3.1 in the following ways. Events are means to implement
the transient nature of RV concerns. Various kinds of RV concerns can uni-
formly be implemented and modularized as event modules. The support for
domain-specific reactor types facilitates expressing the RV concerns of interest](https://image.slidesharecdn.com/2332358-250521170238-3768d12d/85/Transactions-On-Aspectoriented-Software-Development-Xi-1st-Edition-Shigeru-Chiba-54-320.jpg)
Transactions On Aspectoriented Software Development Xi 1st Edition Shigeru Chiba
- 1. Transactions On Aspectoriented Software Development Xi 1st Edition Shigeru Chiba download https://ebookbell.com/product/transactions-on-aspectoriented- software-development-xi-1st-edition-shigeru-chiba-4664716 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Transactions On Aspectoriented Software Development Xii 1st Edition Shigeru Chiba https://ebookbell.com/product/transactions-on-aspectoriented-software- development-xii-1st-edition-shigeru-chiba-5056544 Transactions On Aspectoriented Software Development Vii A Common Case Study For Aspectoriented Modeling Shmuel Katz https://ebookbell.com/product/transactions-on-aspectoriented-software- development-vii-a-common-case-study-for-aspectoriented-modeling- shmuel-katz-52873902 Transactions On Aspectoriented Software Development Viii 1st Edition Suman Roychoudhury https://ebookbell.com/product/transactions-on-aspectoriented-software- development-viii-1st-edition-suman-roychoudhury-2450280 Transactions On Aspectoriented Software Development Vi Special Issue On Aspects And Modeldriven Engineering 1st Edition Lidia Fuentes https://ebookbell.com/product/transactions-on-aspectoriented-software- development-vi-special-issue-on-aspects-and-modeldriven- engineering-1st-edition-lidia-fuentes-2528416
- 3. Transactions On Aspectoriented Software Development V 1st Edition Kenichi Kourai https://ebookbell.com/product/transactions-on-aspectoriented-software- development-v-1st-edition-kenichi-kourai-2532716 Transactions On Aspectoriented Software Development V 1st Edition Kenichi Kourai https://ebookbell.com/product/transactions-on-aspectoriented-software- development-v-1st-edition-kenichi-kourai-4143706 Transactions On Aspectoriented Software Development Vi Special Issue On Aspects And Modeldriven Engineering 1st Edition Lidia Fuentes https://ebookbell.com/product/transactions-on-aspectoriented-software- development-vi-special-issue-on-aspects-and-modeldriven- engineering-1st-edition-lidia-fuentes-4143708 Transactions On Aspectoriented Software Development Viii 1st Edition Suman Roychoudhury https://ebookbell.com/product/transactions-on-aspectoriented-software- development-viii-1st-edition-suman-roychoudhury-4143710 Transactions On Aspectoriented Software Development Ix 1st Edition Dimitri Van Landuyt https://ebookbell.com/product/transactions-on-aspectoriented-software- development-ix-1st-edition-dimitri-van-landuyt-4203246
- 5. Transactions on Aspect-Oriented Software Development XI 123 LNCS 8400 Shigeru Chiba · ÉricTanter Editors-in-Chief Journal Subline Eric Bodden Shahar Maoz Jörg Kienzle Guest Editors
- 6. Lecture Notes in Computer Science 8400 Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Alfred Kobsa University of California, Irvine, CA, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen TU Dortmund University, Germany Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Gerhard Weikum Max Planck Institute for Informatics, Saarbruecken, Germany
- 7. Shigeru Chiba Éric Tanter Eric Bodden Shahar Maoz Jörg Kienzle (Eds.) Transactions on Aspect-Oriented Software Development XI 1 3
- 8. Editors-in-Chief Shigeru Chiba The University of Tokyo, Tokyo, Japan E-mail: chiba@acm.org Éric Tanter University of Chile, Santiago, Chile E-mail: etanter@dcc.uchile.cl Guest Editors Eric Bodden Technical University of Darmstadt, Darmstadt, Germany E-mail: eric.bodden@ec-spride.de Shahar Maoz Tel Aviv University, Tel Aviv, Israel E-mail: maoz@cs.tau.ac.il Jörg Kienzle McGill University, Montreal, Canada E-mail: joerg.kienzle@mcgill.ca ISSN 0302-9743 (LNCS) e-ISSN 1611-3349 (LNCS) ISSN 1864-3027 (TAOSD) e-ISSN 1864-3035 (TAOSD) ISBN 978-3-642-55098-0 e-ISBN 978-3-642-55099-7 DOI 10.1007/978-3-642-55099-7 Springer Heidelberg New York Dordrecht London Library of Congress Control Number: 2014936185 © Springer-Verlag Berlin Heidelberg 2014 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executedonacomputersystem,forexclusiveusebythepurchaserofthework.Duplicationofthispublication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in ist current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)
- 9. Editorial Welcome to Volume XI of the Transactions on Aspect-Oriented Software Development. This volume has two special sections on Runtime Verification and Analysis and on the Best Papers of AOSD 2013. The first section, guest edited by Eric Bodden and Shahar Maoz, has two excellent papers. It highlights runtime verification as a killer application of aspect-orientation. The second section has five papers and is guest edited by Jörg Kienzle, who was Program Committee Chair of the Modularity:aosd 2013 conference held in Fukuoka, Japan. Modularity:aosd 2013 (AOSD 2013 in short) constituted a premier forum for researchers and practitioners to present their work and discuss technical challenges on advanced software modularity and, in particular, aspect-oriented software development. Although the conference pro- ceedings is already a collection of high-quality papers in this area, which are available from ACM digital library, this special section collects longer versions of the best papers presented at the conference. We thank all the guest editors for soliciting submissions, running review processes, and collecting final versions within such a short period. We are pleased to publish this special issue in a timely fashion. We also thank the editorial board members for their continued guidance and input on the policies of the journal, the reviewers for volunteering a significant amount of time despite their busy schedules, and the authors who submitted papers to the journal. February 2014 Shigeru Chiba Éric Tanter Editors-in-Chief
- 10. Guest Editors’ Foreword Special Section on Runtime Verification and Analysis This special section of TAOSD assembles novel contributions that link together the fields of Aspect-Oriented Software Development and Runtime Verification and Analysis. For more than a decade, researchers and practitioners have won- dered about a so-called “killer application” for aspect-oriented programming (AOP). Runtime verification (RV) has turned out to be one of the most con- vincing use cases for AOP. Runtime verification tools typically instrument a program under test with an oracle, defined through a high-level specification language such as a temporal logic or model-based formalism. Prior to the ad- vent of AOP, all of those tools resorted to manual program instrumentation, on source code, bytecode or machine code. This made tools and approaches hard to understand, compare, compose and prove correct. Since then, the advent of AOP has radically changed the way in which tools for RV and dynamic analysis are developed. Nowadays, many tools instrument programs by generating aspects from domain-specific textual descriptions or visual models, or use a program- ming model based on AOP concepts. But research results also flow in the other direction: requirements for RV and dynamic analysis tools have led to novel AOP language constructs improving the performance, modularity and maintainability of the analysis code. This special section presents two thoroughly peer-reviewed papers that give a high-quality example of the synergies that exist between these important fields of research. February 2014 Éric Bodden Shahar Maoz Guest Editors
- 11. Guest Editor’s Foreword Special Section on the Best Papers of AOSD 2013 This special section of TAOSD gathers revised and extended versions of the best papers presented at Modularity:aosd 2013, the 12th International Conference on Modularity and Aspect-Oriented Software Development. The papers were selected based on their evaluation by the Modularity:aosd 2013 Program Com- mittee, of which I served as Program Committee Chair. The authors of the top five papers were invited to submit a revised and extended version of their work. Each revised paper was evaluated both by a member of the Modularity:aosd 2013 PC and by an external reviewer, in order to ensure that the extensions were relevant, consistent, substantial and well-integrated. Four articles were ac- cepted after only one round requesting a minor revision, one paper went through two rounds of revision. Since two of the papers are co-authored by editors-in- chief of the journal, all the reviewing was handled exclusively by myself without involvement of the editors-in-chief. As a result of the constructive effort of both authors and reviewers, this issue is a high-quality snapshot of current state-of-the-art research related to modular- ity, covering topics as varied as formal methods and type systems, static analysis approaches for software architectures, model-driven engineering and model com- position, as well as aspect-oriented programming, event-driven programming, and reactive programming. February 2014 Jörg Kienzle Guest Editor
- 12. Editorial Board Mehmet Akşit University of Twente, The Netherlands Shigeru Chiba The University of Tokyo, Japan Siobhán Clarke Trinity College Dublin, Ireland Robert Filman Google, USA Wouter Joosen Katholieke Universiteit Leuven, Belgium Shmuel Katz Technion-Israel Institute of Technology, Israel Gregor Kiczales University of British Columbia, Canada Gary T. Leavens University of Central Florida, USA Karl Lieberherr Northeastern University, USA Mira Mezini Darmstadt University of Technology, Germany Ana Moreira New University of Lisbon, Portugal Harold Ossher IBM Research, USA Klaus Ostermann University of Marburg, Germany Awais Rashid Lancaster University, UK Douglas C. Schmidt Vanderbilt University, USA Mario Südholt Ecole des Mines de Nantes, France Éric Tanter University of Chile, Chile
- 13. Table of Contents Runtime Verification and Analysis Run-Time Assertion Checking of Data- and Protocol-Oriented Properties of Java Programs: An Industrial Case Study . . . . . . . . . . . . . . . 1 Frank S. de Boer, Stijn de Gouw, Einar Broch Johnsen, Andreas Kohn, and Peter Y.H. Wong Event Modules: Modularizing Domain-Specific Crosscutting RV Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Somayeh Malakuti and Mehmet Akşit Best Papers of AOSD 2013 Method Slots: Supporting Methods, Events, and Advices by a Single Language Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 YungYu Zhuang and Shigeru Chiba Modularity and Dynamic Adaptation of Flexibly Secure Systems: Model-Driven Adaptive Delegation in Access Control Management . . . . . 109 Phu H. Nguyen, Gregory Nain, Jacques Klein, Tejeddine Mouelhi, and Yves Le Traon Effective Aspects: A Typed Monadic Embedding of Pointcuts and Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Ismael Figueroa, Nicolas Tabareau, and Éric Tanter Modular Specification and Checking of Structural Dependencies . . . . . . . 193 Ralf Mitschke, Michael Eichberg, Mira Mezini, Alessandro Garcia, and Isela Macia Towards Reactive Programming for Object-Oriented Applications . . . . . . 227 Guido Salvaneschi and Mira Mezini Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
- 14. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties of Java Programs: An Industrial Case Study Frank S. de Boer1,2 , Stijn de Gouw1,2 , Einar Broch Johnsen3 , Andreas Kohn4 , and Peter Y.H. Wong4 1 CWI, Amsterdam, The Netherlands 2 Leiden University, The Netherlands 3 University of Oslo, Norway 4 Fredhopper B.V., Amsterdam, The Netherlands Abstract. Run-time assertion checking is one of the useful techniques for detecting faults, and can be applied during any program execu- tion context, including debugging, testing, and production. In general, however, it is limited to checking state-based properties. We introduce SAGA, a general framework that provides a smooth integration of the specification and the run-time checking of both data- and protocol- oriented properties of Java classes and interfaces. We evaluate SAGA, which combines several state-of-the art tools, by conducting an industrial case study from an eCommerce software company Fredhopper. 1 Introduction Run-time assertion checking is one of the most useful techniques for detecting faults, and can be applied during any program execution context, including debugging, testing, and production [7]. Compared to program logics, run-time assertion checking emphasizes executable specifications. Assertions in general are clearly not executable in the sense that one cannot decide whether they hold (in the presence of unbounded quantification). As a result, for run-time assertion checking one has to restrict the class of assertions to executable ones. Whereas program logics are generally applied statically to cover all possible execution paths, which is in general undecidable, run-time assertion checking is a fully automated, on-demand validation process which applies to the actual runs of the program. By their very nature, assertions are state-based in that they describe proper- ties of the program variables, e.g. fields of classes and local variables of meth- ods. In general, assertions as supported for example by the Java programming language or the Java Modeling Language (JML) [3] cannot be used to specify the interaction protocol between objects, in contrast to other formalisms such as message sequence charts and UML sequence diagrams. Consequently, exist- ing state-of-the-art program logics for Java are not suited for proving protocol S. Chiba et al. (Eds.): Transactions on AOSD XI, LNCS 8400, pp. 1–26, 2014. © Springer-Verlag Berlin Heidelberg 2014
- 15. 2 F.S. de Boer et al. properties. Moreover state-based assertions cannot be used to specify interfaces since interfaces do not have a state1 . The main contribution of this paper is twofold. First, we introduce SAGA (Software trace Analysis using Grammars and Attributes), a run-time checker that provides a smooth integration of the specification and the run-time check- ing of both data- and protocol-oriented properties of Java classes and interfaces. SAGA combines four different components: a state-based assertion checker, a monitoring tool, a meta-programming tool, and a parser generator. Aspect- oriented programming is tailored for monitoring, and in contrast to transforma- tions source of Java code or debugger-based solutions [9] it is designed for high performance applications and supports the monitoring of precompiled libraries for which no source code is available. The tool can be used for run-time check- ing of any Java program, which requires specific support for the main features listed in Table 1, as discussed in more detail in the following section. Secondly, we evaluate SAGA by conducting an industrial case study from the eCommerce software company Fredhopper. Table 1. Supported features Constructors Inheritance Dynamic Binding Overloading Static Methods Access Modifiers The basic idea underlying SAGA is the representation of message sequences as words of a language generated by a grammar. Grammars allow, in a declarative and highly convenient manner, the description of the protocol structure of the communication events. However, the question is how to integrate such grammars with the run-time checking of assertions, and how to describe the data flow of a message sequence, i.e., the properties of the data communicated. We propose a formal modeling language for the specification of sequences of messages in terms of attribute grammars [14]. Attribute grammars allow the high-level specification of the data-flow of message sequences (e.g., their length) in terms of user-defined attributes of non-terminals. SAGA supports the run-time checking of assertions about these attributes (e.g., that the length of a sequence is bounded). This involves parsing the generated sequences of messages. These sequences them- selves are recorded by means of a fully automated instrumentation of the given program by AspectJ2 . 1 JML uses model variables for interface specifications. However, a separate represents clause is needed for a full specification, and such clauses can only be defined once an implementation has been given (and is not implementation independent). 2 www.eclipse.org/aspectj
- 16. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 3 2 The Modeling Framework Abstracting from implementation details (such as field values of objects), an execution of a Java program can be represented by its global communication his- tory: the sequence of messages corresponding to the invocation and completion of (possibly static) methods. Similarly, the execution of a single object can be rep- resented by its local communication history, which consists of all messages sent and received by that object. The behavior of a program (or object) can then be defined as the set of its allowed histories. Whether a history is allowed depends in general both on data (the contents of the messages, e.g. parameter and return values of method calls) and protocol (the order between messages). The question arises how such allowed sets of histories can be defined conveniently. In this sec- tion we show how attribute grammars provide a powerful and declarative way to define such sets. We use the interface of the Java BufferedReader (Figure 1) as a running example to explain the basic modeling concepts. In particular, we formalize the following property: The BufferedReader may only be closed by the same object which cre- ated it, and reads may only occur between the creation and closing of the BufferedReader. interface BufferedReader { void close(); void mark(int readAheadLimit); boolean markSupported(); int read(); int read(char[] cbuf, int off, int len); String readLine(); boolean ready(); void reset(); long skip(long n); } Fig. 1. Methods of the BufferedReader Interface As a naive first step one might be tempted to define the behavior of BufferedReader objects simply in terms of ‘call-m(T)’ and ‘return-m(T)’ messages of all methods ‘m’ in its interface, where the parameter types T are included to distinguish between overloaded methods (such as read). However, interfaces in Java contain only signatures of provided methods: methods where the BufferedReader is the callee. Calls to these methods correspond to mes- sages received by the object. In general the behavior of objects also depends on messages sent by that object (i.e., where the object is the caller), and on the par- ticular constructor (with parameter values) that created the object. Moreover,
- 17. 4 F.S. de Boer et al. it is often useful to select a particular subset of method calls or returns, instead of using calls and returns to all methods (a partial or incomplete specification). Finally, in referring to messages it is cumbersome to explicitly list the parameter types. A communication view addresses these issues. 2.1 Communication View A communication view is a partial mapping which associates a name to each mes- sage. Partiality makes it possible to filter irrelevant events and message names are convenient in referring to messages. Suppose we wish to specify that the BufferedReader may only be closed by the same object which created it, and that reads may only occur between the creation and closing of the BufferedReader. This is a property which must hold for the local history of all instances of java.util.BufferedReader. The communication view in Figure 2 selects the relevant messages and associates them with intuitive names: open, read, and close. local view BReaderView grammar BReader.g specifies java.util.BufferedReader { BufferedReader(Reader in) open, BufferedReader(Reader in, int sz) open, call void close() close, call int read() read, call int read(char[] cbuf, int off, int len) read } Fig. 2. Communication view of a BufferedReader All return messages and call messages methods not listed in the view are fil- tered. Note how the view identifies two different messages (calls to the overloaded read methods) by giving them the same name read. Though the above communi- cation view contains only provided methods (those listed in the BufferedReader interface), required methods (e.g., methods of other interfaces or classes) are also supported. Since such messages are sent to objects of a different class (or inter- face), one must include the appropriate type explicitly in the method signature. For example consider the following message: call void C.m() out If we would additionally include the above message in the communication view, all call-messages to the method m of class C sent by a BufferedReader would be selected and named out. In general, incoming messages received by an ob- ject correspond to calls of provided methods and returns of required methods. Outgoing messages sent by an object correspond to calls of required methods
- 18. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 5 and returns of provided methods. Incoming call-messages of local histories never involve static methods, as such methods do not have a callee. Besides normal methods, communication views can contain signatures of con- structors (i.e., the messages named open in our example view). Incoming calls to provided constructors raise an interesting question: what would happen if we select such a message in a local history? At the time of the call, the object has not even been created yet, so it is unclear which BufferedReader object receives the message. We therefore only allow return-messages of provided con- structors (clearly required constructors do not pose the same problem, and con- sequently we allow selecting both calls and returns to required constructors), and for convenience omit return. Alternatively one could treat constructors like static methods, disallowing incoming call-messages to constructors in local his- tories altogether. However, this makes it impossible to express certain properties (including the desired property of the BufferedReader) and has no advantages over the approach we take. Java programs can distinguish methods of the same name only if their parame- ter types are different. Communication views are more fine-grained: methods can be distinguished also based on their return type or their access modifiers (such as public). For instance, consider a scenario with suggestively named classes Base and three subclasses Sub1, Sub2, and Sub3, all of which provide a method m. The return type of m in the Base, Sub1 and Sub2 classes is the class itself (i.e., Sub1 for m provided by Sub1). In the Sub3 class the return type is Sub1. To monitor calls to m only with return type Sub1, simply include the following event in the view: call Sub1 C.m() messagename Local communication views, such as the one above, selects messages sent and received by a single object of a particular class, indicated by ‘specifies java.util.BufferedReader’. In contrast, global communication views select mes- sages sent and received by any object during the execution of the Java program. This is useful to specify global properties of a program. In addition to instance methods, calls and returns of static methods can also be selected in global views. Figure 3 shows a global view which selects all returns of the method m of the Ping class or interface or any of its subclasses, and all calls of the Pong class (or interface) or its subclasses. Note that communication views do not distinguish instances of the same class (e.g., calls to ‘Ping’ on two different objects of class ‘Ping’ both get mapped to the same terminal ‘ping’). Different instances can be distinguished in the grammar using the built-in attributes ‘caller’ or ‘callee’. In contrast to interfaces of the programming language, communication views can contain constructors, required methods, static methods (in global views) and can distinguish methods based on return type or method modifiers such as ‘static’, or ‘public’. See Table 1 for a list of supported features.
- 19. 6 F.S. de Boer et al. global view PingPong grammar pingpong.g { return void Ping.m() ping, call void Pong.m() pong } Fig. 3. Global communication view 2.2 Grammars Context-free grammars provide a convenient way to define the protocol behav- ior of the allowed histories. The context-free grammar underlying the attribute grammar in Figure 4 generates the valid histories for BufferedReader, describ- ing the prefix closure of sequences of the terminals ‘open’, ‘read’, and ‘close’ as given by the regular expression (open read* close). In general, the message names form the terminal symbols of the grammar, whereas the non-terminal symbols specify the structure of valid sequences of messages. In our approach, a communication history is valid if and only if it and all its prefixes are generated by the grammar. For a justification of this approach, see the next discussion section. While context-free grammars provide a convenient way to specify the protocol structure of the valid histories, they do not take data such as parameters and return values of method calls and returns into account. Thus the question arises how to specify the data-flow of the valid histories. To that end, we extend the grammar with attributes. Each terminal symbol has built-in attributes named caller, callee and the parameter names for respectively the object identities of the caller, callee and actual parameters. Terminals corresponding to method returns additionally have an attribute result containing to the return value. In summary, the (built-in) at- tributes of terminals are determined from the method signatures. Non-terminals have user-defined attributes to define data properties of sequences of terminals. However, the attributes themselves do not alter the language generated by the attribute grammar, they only define properties of data-flow of the history. We extend the attribute grammar with assertions to specify properties of attributes. For example, in the attribute grammar in Figure 4 a user-defined synthesized attribute ‘c’ for the non-terminal ‘C’ is defined to store the identity of the object which closed the BufferedReader (and is null if the reader was not closed yet). Synthesized attributes define the attribute values of the non-terminals on the left-hand side of each grammar production, thus the ‘c’ attribute is not set in the productions of the start symbol ‘S’. The assertion allows only those histories in which the object that opened (created) the reader is also the object that closed it. Throughout the paper the start symbol in any grammar is named ‘S’. For clarity, attribute definitions are written between parentheses ‘(’ and ‘)’ whereas assertions over these attributes are surrounded by braces ‘{’ and ‘}’.
- 20. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 7 S ::= open C1 {assert (open.caller == null || open.caller == C1.c || C1.c == null);} | C ::= read C1 (C.c = C1.c;) | close S (C.c = close.caller;) | (C.c = null;) Fig. 4. Attribute Grammar which specifies that ‘read’ may only be called in between ‘open’ and ‘close’, and the reader may only be closed by the object which opened it Assertions can be placed at any position in a production rule and are evalu- ated at the position they were written. Note that assertions appearing directly before a terminal can be seen as a precondition of the terminal, whereas post- conditions are placed directly after the terminal. This is in fact a generalization of traditional pre- and post-conditions for methods as used in design-by-contract: a single terminal ‘call-m’ can appear in multiple productions, each of which is fol- lowed by a different assertion. Hence different preconditions (or post-conditions) can be used for the same method, depending on the context (grammar produc- tion) in which the event corresponding to the method call/return appears. Attribute grammars in combination with assertions cannot express protocol that depend on data. Such protocols are common, for instance, the method next of an Iterator may not be called if directly hasNext was called directly before and returns false. To express protocols depending on data we consider attribute grammars enriched by conditional productions [18]. In such grammars, a pro- duction is chosen only when the given condition (a boolean expression over the inherited attributes) for that production is true. Hence conditions are evaluated before any of the symbols in the production are parsed, before synthesized at- tributes of the non-terminals appearing in the production are set and before assertions are evaluated. In contrast to assertions, conditions in productions af- fect the parsing process. The Worker.g grammar in the case study contains a conditional production for the ‘T’ non-terminal. 2.3 Discussion We now briefly motivate our choice of attribute grammars extended by assertions as specifications and discuss its advantages over alternative formalisms. Instead of context-free grammars, we could have selected push-down automata to specify protocol properties (formally these have the same expressive power). Unfortunately push-down automata cannot handle attributes. An extension of push-down automata with attributes results in a register machine. From a user perspective, the declarative nature and higher abstraction level of grammars (compared to the imperative and low-level nature of automata) makes them much more suitable than automata as a specification language. In fact, a push- down automaton which recognizes the same language as a given grammar is an implementation of a parser for that grammar.
- 21. 8 F.S. de Boer et al. Both the BufferedReader above and the case study use only regular grammars. Since regular grammars simplify parsing compared to context-free grammars, the question arises if we can reasonably restrict to regular grammars. Unfortunately this rules out many real-life use cases. For instance, the following grammar in EBNF specifies the valid protocol behavior of a stack: S ::= (push S pop ?)* It is well known that the language generated by the above grammar is not regular, so regular grammars (without attributes) cannot be used to enforce the safe use of a stack. It is possible to specify the stack using an attribute which counts the number of pushes and pops: S ::= S1 push (S.cnt = S1.cnt + 1) | S1 pop (S.cnt = S1.cnt − 1){assert S.cnt = 0; } | (S.cnt = 0) The resulting grammar is clearly less elegant and less readable: essentially it en- codes (instead of directly expresses, as in the grammar above) a protocol-oriented property as a data-oriented one. The same problem arises when using regular grammars to specify programs with recursive methods. Thus, although theoreti- cally possible, we do not restrict to regular grammars for practical purposes. Ultimately the goal of run-time checking safety properties is to prevent unsafe ongoing behavior. To do so, errors must be detected as soon as they occur and the monitor must immediately terminate the system: it cannot wait until the program ends to detect errors. In other words, the monitor must decide after every event whether the current history is still valid. The simplest notion of a valid history (one which should not generate any error) is that of a word generated by the grammar. One way of fulfilling the above requirement, assuming this notion of validity, is to restrict to prefix-closed grammars. Unfortunately, it is not possible to decide whether a context-free grammar is prefix-closed. The following lemmas formalize this result: Lemma 1. Let LM be the set of all accepting computation histories3 of a Turing Machine M. Then the complement LM is a context-free language. Proof. See [20]. Lemma 2. It is undecidable whether a context-free language is prefix-closed. Proof. We show how the halting problem for M (which is undecidable) can be reduced to deciding prefix-closure of LM . To that end, we distinguish two cases: 1. M does not halt. Then LM is empty so LM is universal and hence prefix- closed. 3 A computation history of a Turing Machine is a sequence C0#C1#C2# . . . of con- figurations Ci. Each configuration is a triple consisting of the current tape contents, state and position of the read/write head. Due to a technicality, the configurations with an odd index must actually be encoded in reverse.
- 22. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 9 2. M halts. Then there is an accepting history h ∈ LM (and h / ∈ LM ). Extend h with an illegal move (one not permitted by M) to the configuration C, resulting in the history h#C. Clearly h#C is not a valid accepting history, so h#C ∈ LM . But since h / ∈ LM , LM is not prefix-closed. Summarizing, M halts if and only if LM is not prefix-closed. Thus if we could decide prefix-closure of the context-free language (lemma 1) LM , we could decide whether M halts. Since prefix-closure is not a decidable property of grammars (not even if they don’t contain attributes) we propose the following alternative definition for the valid histories. A communication history is valid if and only if it and all its prefixes are generated by the grammar. Note that this new definition naturally fulfills the above requirement of detecing errors after every event. And further- more, this notion of validity is decidable assuming the assertions used in the grammar are decidable. As an example of this new notion of validity, consider the following modification of the above grammar: T ::= S {assert S.cnt = 0; } S ::= S1 push (S.cnt = S1.cnt + 1) | S1 pop (S.cnt = S1.cnt − 1) | (S.cnt = 0) Note that the history push pop is a word generated by this grammar, but not its prefix pop, which as such will generate an error (as required). Note that thus in general invalid histories are guaranteed to generate errors. On the other hand, if a history generates an error all its extensions are therefore also invalid. Observe that our approach monitors only safety properties (‘prevent bad be- havior’), not liveness (‘something good eventually happens’). This restriction is not specific to our approach: liveness properties in general cannot be rejected on any finite prefix of an execution, and monitoring only checks finite prefixes for violations of the specification. Most liveness properties fall in the class of the non-monitorable properties [2,19]. However it is possible to ensure liveness properties for terminating programs: they can then be reformulated as safety properties. For instance, suppose we want to guarantee that a method void m() is called before the program ends. Introduce the following global view: global view livenessM { call void C.m() m, return static void C.main(String[]) main } The occurence of the ‘main’ event (i.e., a return of the main method of the program) signifies the program is about to terminate. Define the EBNF grammar S ::= | m | m+ main
- 23. 10 F.S. de Boer et al. (where ’+’ stands for one or more repetitions). This grammar achieves the desired effect since the only terminating executions allowed are those containing m. In local views a similar effect is obtained by including the method finalize instead of main. 3 Tool Architecture In this section we describe the tool architecture of the run-time assertion checker. The checker integrates four different components: a state-based assertion checker, a parser generator, a monitoring tool, and a general tool for meta-programming. These components are traditionally used for very diverse purposes and normally do not need to interact with each other. We investigate requirements needed to achieve a seamless integration, motivated by describing the workflow of the run-time checker. Finally, we instantiate the components with actual tools and evaluate them. 3.1 Workflow A user starts executing a Java class with a main statement. Suppose that during execution, a method listed in a communication view is called. The history should be updated to reflect the addition of the method call. Thus the question arises how to represent the history. A meta-program generates for each message in the communication view a class (subsequently called ‘token classes’) containing the following fields: the object identitities of the caller and callee, the actual parameter values, and for return messages additionally a field result to store the return value. The history can then be represented as a Java List of instances of token classes. Next, the monitoring tool should update the history whenever a call or return listed in a view occurs. Thus the monitoring tool should be capable of ex- ecuting user-defined code directly before method calls and directly after method returns. Moreover, it must be able to read the identity of the callee, caller, and parameters/return-value. After the history is updated the SAGA must decide whether it still satisfies the specification (the attribute grammar). Observe that a communication history can be seen as a sequence of tokens (in our setting: communication events). Since the attribute grammar together with the assertions generate the language of all valid histories, checking whether a history satisfies the specification reduces to deciding whether the history can be parsed by a parser for the attribute grammar, where moreover during parsing the assertions must evaluate to true. Therefore the parser generator creates a parser for the given attribute gram- mar. Since the history is a list of token class objects, the parser must support parsing streams of user-defined token types. As the (user-defined) attributes of non-terminals in the grammar are defined in terms of built-in attributes of terminals (recall those are for example, actual parameter values), and clearly the built-in attributes are Java objects, the user-defined attributes must also be
- 24. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 11 Java objects. Consequently the target language for the parser generator must be Java, and it must support executing user-defined Java code to define the attribute value in rule actions. The use of Java code to define attribute values ensures they are computable. Furthermore, assertions are allowed in-between any two (non)-terminals, thus the parser generator should support user-defined actions between arbitrary grammar symbols. Once the parser is generated, it is triggered whenever the history of an object is updated. During parsing, the state-based assertion checker proceeds to evaluate the assertions in the grammar on the newly computed attribute values. The result is either a parse or assertion error, which indicates that the current communication history has violated the specification in the attribute grammar, or a parse tree with new attribute values. 3.2 Implementation In this section we instantiate each of the four different components (meta- programming, monitoring tool, parser generator, and state-based run-time as- sertion checker) with a state-of-the art tool. We report on our experiences with the particular tools and discuss the extent to which the previously formulated requirements are fulfilled. Rascal [13] is a powerful tool-supported meta-programming language tailored for program analysis, program transformation, and code generation. We have written a Rascal program of approximately 600 lines in total which generates the token class for each message in the view, and generates glue code to trigger the AspectJ and parser at the appropriate times. Overall our experience with Rascal was quite positive: its powerful parsing, pattern matching, and transforming concrete syntax features were indispensable in the implementation of SAGA. As the parser generator we tested ANTLR [17], a state-of-the-art parser gen- erator. It generates fast recursive descent parsers for Java, has direct support for both synthesized and inherited attributes, it supports grammars in EBNF form and most importantly allows a custom stream of token classes. It even sup- ports conditional productions: such productions are only taken during parsing whenever an associated Boolean expression (the condition) is true. Attribute grammars with conditional productions express protocols that depend on data, and typically are not context-free. The worst-case time complexity any parser ANTLR generates is quadratic in the number of tokens to parse. The main draw- backs of ANTLR are that it can only handle LL(*) grammars4 , and its lack of support for incremental parsing, though support for incremental is planned by the ANTLR developers. An incremental parser computes a parse tree for the new history based on the parse trees for prefixes of the history. In our setting, since the attribute grammar specifies invariant properties of the ongoing behav- ior, a new parse tree is computed after each call/return, hence parse trees for all prefixes of the current history can be exploited for incremental parsing [11]. 4 A strict subset of the context-free grammars. Left-recursive grammars are not LL(*). A precise definition can be found in [17].
- 25. 12 F.S. de Boer et al. We have not been able to find any Java parser generator which supported general context-free grammars and incremental parsing of attribute grammars. We have tested two state-based assertion languages: standard Java assertions and the Java Modeling Language (JML). Both languages suffice for our pur- poses. JML is far more expressive than the standard Java assertions, though its tool support is not ready for industrial usage. In particular, the last stable version of the JML run-time assertion checker dates back over 8 years, when for example generics were not supported yet. The main reason is that JML’s run-time assertion checker only works with a proprietary implementation of the Java compiler, and unsurprisingly it is costly to update the propietary compiler each time the standard compiler is updated. This problem is recognized by the JML developers [4]. OpenJML5 , a new pre-alpha version of the JML run-time assertion checker integrates into the standard Java compiler, and initial tests with it provided many valuable input for real industrial size applications. See the Sourceforge tracker for the kind of issues we have encountered when using OpenJML. Fig. 5. SAGA Tool Architecture Aspects. AspectJ is tailored for monitoring. It can intercept method calls and returns conveniently with pointcuts, and weave in user-defined code (advices) which is executed before or after the intercepted call. In our case the pointcuts correspond to the calls and returns of the messages listed in the communication view. The advice consists of code which updates the history. The code for the aspect is generated from the communication view automatically by the Rascal 5 jmlspecs.sourceforge.net
- 26. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 13 meta-program. Advice is woven into Java source code, byte code, or at class load-time fully automatically by AspectJ. We use the inter-type declarations of AspectJ to store the local history of an object as a field in the object itself. This ensures that whenever the object goes out of scope, so does its history and consequently reduces memory usage. Clearly the same does not hold for global histories, which are stored inside a separate Aspect class. Figure 6 shows a generated aspect. The second and third lines specify the relevant method. The fourth line binds variables (‘clr’, ‘cle’, ...) to the appropriate objects. The fifth line ensures that the aspect is applied only when Java assertions are turned on. Assertions can be turned on or off for each communication view individually. The fifth line contains the advice that updates the history. Note that since the event came was defined in a local view, the history is treated as a field of the callee (and will not persist in the program indefinitely but rather is garbage collected as soon as callee object itself is). /∗ call int read(char[] cbuf, int off, int len); ∗/ before(Object clr, BufferedReader cle, char[] cbuf, int off, in len): (call( int *.read(char[], int, int)) this(clr) target(cle) args(cbuf, off, len) if(BReaderHistoryAspect.class.desiredAssertionStatus() )) { cle.h.update(new call_push(clr, cle, cbuf, off, len)); } Fig. 6. Aspect for the event ‘call int read(char[] cbuf, int off, int len)’ We have investigated two alternatives for the monitoring component not based on aspect-oriented programming: Rascal and Sun’s implementation of the Java Debugging Interface. With Rascal one can weave advice by defining a transfor- mation on the actual Java source code of the program to test. This requires a full Java grammar (which must be kept in sync with the latest updates to Java). To capture the identity of the callee, parameter values and return value of a method, one only needs to transform that particular method (i.e., locally). But inside the method there is no way to access the identity of the caller. Java does offer facilities to inspect stack frames, but these frames contain only static entities, such as the name of the method which called the currently executing method, or the type of the caller, but not the caller itself. To capture the caller, a global transformation at all call-sites is needed (and in particular one needs to have access to the source code of all clients which call the method). The same problem arises in monitoring calls to required methods. Finally, it proved to quickly get very complex to handle all Java features. We wrote an initial ver- sion of a weaver in Rascal which already took over 150 lines (over half of the full checker at the time) without supporting method calls appearing inside ex- pressions, inheritance and dynamic binding. This approach is also unsuitable for
- 27. 14 F.S. de Boer et al. black-box testing where only byte code is available (limiting the applicability of the tool). In summary, it is possible to implement monitoring by defining a code transformation in Rascal, but this rules out black-box testing and quickly gets complex due to the need for a full (up to date) Java grammar and the complexity of the full Java language. The Sun debugger is part of the standard Java Development Kit, hence main- tenance of the debugger is practically guaranteed. The debugger starts the origi- nal user program in a separate virtual machine which is monitored for occurences of MethodEntryEvent (method calls) and MethodExitEvent (method returns). Whenever such an event occurs the debugger can execute an event handler. How- ever accessing the values of the parameters and return value of events is difficult, one has to use low-level StackFrames. As a major disadvantage, we found that the debugger is very slow (an order of magnitude slower than AspectJ), in fact it was responsible for the majority of the overhead of the run-time checker. Finally, in contrast to AspectJ it not possible to add fields to objects, thus local histories never go out of scope, even if the object itself is already long destroyed. In summary, the use of aspect-oriented programming greatly improved per- formance compared to the debugger-based solution and was much simpler than implementing our own weaver with code transformations, especially to handle intricate language features. 4 Case Study Fredhopper provides the Fredhopper Access Server (FAS). It is a distributed concurrent object-oriented system that provides search and merchandising ser- vices to eCommerce companies. Briefly, FAS provides to its clients structured search capabilities within the client’s data. Each FAS installation is deployed to a customer according to the FAS deployment architecture (See Figure 7). FAS consists of a set of live environments and a single staging environment. A live environment processes queries from client web applications via web services. FAS aims at providing a constant query capacity to client-side web applications. A staging environment is responsible for receiving data updates in XML for- mat, indexing the XML, and distributing the resulting indices across all live environments according to the Replication Protocol. The Replication Protocol is implemented by the Replication System. The Replication System consists of a SyncServer at the staging environment and one SyncClient for each live envi- ronment. The SyncServer determines the schedule of replication, as well as its content, while SyncClient receives data and configuration updates according to the schedule. Replication Protocol The SyncServer communicates to SyncClients by creating Worker objects. Work- ers serve as the interface to the server-side of the Replication Protocol. On the other hand, SyncClients schedule and create ClientJob objects to handle commu- nications to the client-side of the Replication Protocol. When transferring data
- 28. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 15 Live Environment Live Environment Data and Config Updates Configurations changes Staging Environment Data Manager Internet ... Client-side Web App Client-side Web App Client-side Web App Data updates Live Environment ... Load balancer Fig. 7. An example FAS deployment between the staging and the live environments, it is important that the data re- mains immutable. To ensure immutability without interfering the read and write accesses of the staging environment’s underlying file system, the SyncServer cre- ates a Snapshot object that encapsulates a snapshot of the necessary part of the staging environment’s file system, and periodically refreshes it against the file system. This ensures that data remains immutable until it is deemed safe to modify it. The SyncServer uses a Coordinator object to determine the safe state in which the Snapshot can be refreshed. Figure 8 shows a UML sequence diagram concerning parts of the replication protocol with the interaction be- tween a SyncClient, a ClientJob, a Worker, a SyncServer, a Coordinator, and a Snapshot. The diagram also shows a Util class that provides static methods for writing to and reading from Stream. The figure assumes that SyncClient has al- ready established connection with a SyncServer and shows how a ClientJob from the SyncClient and a Worker from a SyncServer are instantiated for interaction. For the purpose of this paper we consider this part of the Replication Protocol as a replication session. 4.1 Specification In this section we show how to modularly decompose object interaction behavior depicted by the UML sequence diagram in Figure 8 using SAGA. Figure 9 shows the corresponding interfaces and classes, note that we do not consider SyncClient as our interest is in object interactions of a replication session, that is after ClientJob.start() has been invoked.
- 29. 16 F.S. de Boer et al. Fig. 8. Replication interaction The protocol descriptions and specifications considered in this case study have been obtained by manually examining the behavior of the existing imple- mentation, by formalizing available informal documentations, and by consulting existing developers on intended behavior. Here we first provide such informal descriptions of the relevant object interactions: – Snapshot: at the initialization of the Replication System, refresh should be called first to refresh the snapshot. Subsequently the invocations of methods refresh and clear should alternate. – Coordinator: neither of methods start and finish may be invoked twice in a row with the same argument, and method start must be invoked before finish with the same argument can be invoked. – Worker: establish must be called first. Furthermore, reg may be called if the input argument of establish is not “LIST” but the name of a specific replication schedule, and that reg must take that name as an input argu- ment. When the reg method is invoked and before the method returns, the Worker must obtain the replication items for that specific replication sched- ule via method items of the Snapshot object. The Snapshot object must be obtained via method snapshot of its SyncServer, which must be obtained via the method server. It must notify the name of each replication item to
- 30. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 17 interface Snapshot { void refresh(); void clear(); ListItem items(String sn); } interface Worker { void establish(String sn); ListItem reg(String sn); void transfer(Item item); SyncServer server(); } interface SyncServer { Snapshot snapshot(); } interface Coordinator { void start(Worker t); void finish(Worker t); } class Util { static void write(String s) { .. } } Fig. 9. Interfaces of Replication System its interacting SyncClient. This notification behavior is implemented by the static method write of the class Util. The method reg also checks for the validity of each replication item and so the method must return a subset of the items provided by the method items. Finally transfer may be invoked after reg, one or more times, each time with a unique replication item, of type Item, from the list of replication items, of type ListItem, returned from reg. Figure 10 specifies communication views. They provide partial mappings from message types (method calls and returns) that are local to individual objects to grammar terminal symbols. Note that the specification of the Worker’s behavior is modularly captured by two views: WorkerHistory and WorkerRegHistory. The view WorkerHistory exposes methods establish, reg, and transfer. Us- ing this view we would like to capture the overall valid interaction in which Worker is the callee of methods, and at the same time the view helps ab- stracting away the implementation detail of individual methods. The view WorkerRegHistory, on the other hand, captures the behavior inside reg. Ac- cording to the informal description above, the view projects incoming method calls and returns of reg, outgoing method calls to server and items, as well as the outgoing static method calls to write. We now define the abstract behavior of the communication views, that is, the set of allowable sequences of interactions of objects restricted to those method calls and returns mapped in the views. Each local view also defines the file containing the attribute grammar, whose termi- nal symbols the view maps method invocations and returns to. Specifi- cally, Figure 11 shows the attribute grammars Snapshot.g, Coordinator.g, Worker.g and WorkerReg.g for views SnapshotHistory, CoordinatorHistory, WorkerHistory and WorkerRegHistory respectively.
- 31. 18 F.S. de Boer et al. local view SnapshotHistory grammar Snapshot.g specifies Snapshot { call void refresh() rf, call void clear() cl } local view CoordinatorHistory grammar Coordinator.g specifies Coordinator { call void start(Worker t) st, call void finish(Worker t) fn } local view WorkerHistory grammar Worker.g specifies Worker { call void establish(String sn) et, call ListItem reg(String sn) rg, return ListItem reg(String sn) is, call void transfer(Item item) tr } local view WorkerRegHistory grammar WorkerReg.g specifies Worker { call ListItem reg(String sn) rg, return ListItem reg(String sn) is, return Snapshot SyncServer.snapshot() sp, call ListItem Snapshot.items(String sn) ls, return ListItem Snapshot.items(String sn) li, call static void Util.write(String s) wr } Fig. 10. Communication Views The simplest grammar Snapshot.g specifies the interaction protocol of Snap- shot. It focuses on invocations of methods refresh and clear per Snapshot ob- ject. The grammar essentially specifies the regular expression (refresh clear)∗. The grammar Coordinator.g specifies the interaction protocol of Coordina- tor. It focuses on invocations of methods start and finish, both of which take a Worker object as the input parameter. These method calls are mapped to ter- minal symbols st and fn, while their inherited attribute is a HashSet, recording the input parameters, thereby enforcing that for each unique Worker object as an input parameter only the set of sequences of method invocations defined by the reqular expression (start finish)∗ is allowed. The grammar Worker.g specifies the interaction protocol of Worker It focuses on invocations and returns of methods establish, reg and transfer. The gram- mar specifies that for each Worker object, establish must be first invoked, then followed by reg, and then zero or more transfer, that is, the regular expression (establish reg transfer∗). We use the attribute definition of the grammar to ensure the following: – The input argument of establish and reg must be the same; – reg can only be invoked if the input argument of establish is not “LIST”;
- 32. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 19 S ::= | rf T T ::= | cl S (a) Snapshot.g S ::= T (T .ts = new HashSet();) T ::= | st {assert ! T .ts.contains(st.t);} (T.ts.add(st.t);) T1 (T1.ts = T.ts;) | fn {assert T .ts.contains(fn.t);} (T.ts.remove(fn.t);) T1 (T1.ts = T.ts;) (b) Coordinator.g S ::= | et T (T .d = et.sn;) T ::= | {!LIST.equals(T.d);}? rg {assert rg.sn.equals(T.d);} U U ::= | is V (V .m = new ArrayDeque(is.result);) V ::= | tr {assert V .m.peek().equals(tr.item);} (V .m.pop();) V1 (V1.m = V .m;) (c) Worker.g /*S accepts call to Worker.reg() and, records */ /*the input schedule name, also S allows */ /*arbitary calls to SyncServer.snapshot() and Util.write() */ S ::= | wr S | sp S | rg T (T .d = et.sn;) /*T accepts and stores the return */ /*snapshot object from SyncServer.snapshot() */ T ::= | sp V (V .d = T .d; U.s = sp.result;) /*U ensures call items() is called on the same snapshot object */ /*U ensures the replication items for the correct schedule */ /*are retrieved */ U ::= | ls {assert ls.callee.equals(U.s); assert ls.sn.equals(U.d);} V (V .s = U.s;) /*V records replication items and their name returned from item() */ V ::= | li W (W.is = new HashSet(li.result); W.ns = new HashSet(); for (Item i :W.is) { W.ns.add(i.name()); }) /*W ensures all replication items are processed */ W ::= | wr (W.ns.remove(wr.s);) W1 (W1.ns =W.ns; W1.is =W.is;) | is {assert W.is.containsAll(is.result); assert W.ns.isEmpty();} X X ::= | sp X | rg X (d) WorkerReg.g Fig. 11. Attribute Grammars
- 33. 20 F.S. de Boer et al. – The return value of reg is a list of Item objects such that transfer is invoked with each of Item in that list from position 0 to the size of that list. The grammar WorkerReg.g specifies the behavior of the method reg of Worker. It focuses on the invocations and returns of method reg of Worker as well as the outgoing method calls and returns of Util.write and SyncServer.snapshot and Snapshot.items. At the protocol level the grammar specifies the regular expression (snapshot items write∗) inside the invocation method reg. We use attribute definition to ensure the following: – Snapshot.items must be called with the input argument of reg and it must be called on the Snapshot object that is identical to the return value of SyncServer.snapshot; – The static method Util.write must be invoked with the value of Item.name for each Item object in the Collection returned from Snapshot.items; – The returned list of Item objects from reg must be a subset of that returned from Snapshot.items. Notice that methods Util.write and SyncServer.snapshot may be invoked outside of the method reg. However, this particular behavioral property does not specify the protocol for those invocations. The grammar therefore abstracts from these invocations by allowing any number of calls to Util.write and SyncServer.snapshot before and after reg. 4.2 Experiment We applied SAGA to the Replication System. The current Java implementation of FAS has over 150,000 lines of code, and the Replication System has approxi- mately 6400 lines of code, 44 classes, and 5 interfaces. We have successfully integrated the SAGA into the quality assurance process at Fredhopper. The quality assurance process includes automated testing that includes automated unit, integration, and system tests as well as manual accep- tance tests. In particular system tests are executed twice a day on instances of FAS on a server farm. Two types of system tests are scenario and functional testing. Scenario testing executes a set of programs that emulate a user and interact with the system in predefined sequences of steps (scenarios). At each step they perform a configuration change or a query to FAS, make assertions about the response from the query, etc. Functional testing executes sequences of queries, where each query-response pair is used to decide on the next query and the assertion to make about the response. Both types of tests require a running FAS instance and as a result we may leverage SAGA by augmenting these two automated test facilities with run-time assertion checking using SAGA. To integrate of SAGA with the system tests, we employ Apache Maven tool6 , an open source Java-based tool for managing dependencies between applications and for building dependency artifacts. Maven consists of a project object model 6 maven.apache.org
- 34. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 21 (a) Violating histories class WKImpl extends Thread implements Worker { final Coordinator c; WKImpl(Coordinator c) { this.c = c; } public void run() { try { .. c.start(this); .. } finally { c.finish(this); .. }}} (b) WKImpl Fig. 12. Incorrect behavior (POM), a set of standards, a project lifecycle, and an extensible dependency management and build system via plug-ins. We use its build system to auto- matically generate and package the parser/lexer of attribute grammars as well as aspects from views and grammars. We expose the packaged aspects, parser, and lexer to FAS instance on the server farm and employ Aspectj using load- time weaver for monitoring method calls/returns during the execution of FAS instances on the server farm. Table 2 shows the number of join point matches during the execution of 766 replication sessions over live client data. Figure 13 shows the exection time of the 766 replication sessions with and without the integration of SAGA in milliseconds. Despite the fact that we cannot control the exact flow of control of the replication sessions (due to dependence on user input), the graph clearly shows that the integration of SAGA has minimal per- formance impact on the execution time. Table 2. Join point matches in 766 replication sessions Join point Terminal Match call static write wr 247446 return snapshot sp 3061 call transferItem tr 1101 return reg (WorkerHistory) is 765 return reg (WorkerRegHistory) is 765 call establish et 766 call reg (WorkerHistory) rg 765 call reg (WorkerRegHistory) rg 765 return items li 765 call start st 766 call finish fn 766 call items ls 765 call refresh rf 766 call clear cl 766
- 35. 22 F.S. de Boer et al. 15000 20000 25000 30000 WithSAGA WithoutSAGA 0 5000 10000 1 21 41 61 81 101 121 141 161 181 201 221 241 261 281 301 321 341 361 381 401 421 441 461 481 501 521 541 561 581 601 621 641 661 681 701 721 741 761 Fig. 13. Comparison of the execution time (milliseconds) of the replication sessions with and without the integration of SAGA During this session we have found an assertion error at join point call finish due to the condition T .ts.contains(fn.t) not being satisfied at non-terminal T of the grammar Coordinator.g. Specifically, the implementation of Worker (WKImpl) that invoke finish before start. Figure 12(a) shows the sequence di- agram automatically generated from the output of SAGA on the invalid histories causing the assertion error. Figure 12(b) shows part of the implementation of WKImpl. It turns out that in the run method of WKImpl, the method start is invoked inside a try block while the method finish is invoked in the correspond- ing finally block. As a result when there is an exception being thrown by the execution preceding the invocation of start inside the try block, for example a network disruption, finish would be invoked without start being invoked. 5 Conclusion We developed SAGA, a run-time checker which fully automatically checks properties of both the protocol behavior and data-flow of message sequences in a declarative manner. We identified the different components of SAGA and evaluated SAGA on an industrial case study of the eCommerce company Fred- hopper. The results of this case study show the feasability of our method for run-time verification in industrial practice (it has already led to the integration of SAGA into the software lifecycle at Fredhopper), in contrast to methods for static verification which require both an in-depth knowledge of the case study and the underlying theorem prover. A beta version of SAGA can be found on http://www.cwi.nl/~cdegouw. Related Work. A preliminary version of a prototype of our tool containing some of the basic underlying ideas was presented at the workshop Formal Techniques
- 36. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 23 for Java-Like Programs 2010 and appeared in its informal proceedings7 . In the current paper we apply and evaluate a new version to an industrial case study and succesfully integrate SAGA into the quality assurance process of Fredhopper. Based on this application and evaluation we extended our framework to support a more general class of grammars to specify data-dependent protocol behavior. Furthermore, The new version features a tighter integration of attribute grammars and assertions. Finally the support for the features listed in Table 1 is new. There exist many other interesting approaches to monitoring message se- quences, none of which address their integration with the general context of run-time assertion checking. Consequently, all the other approaches only allow a combination of a very restricted class of data-oriented properties and protocol properties. For example, Martin et al. [15] introduce a Program Query Language (PQL) for detecting errors in sequences of communication events. PQL was up- dated last in 2006 and does not support user-defined properties of data. Allan et al. [1] develop an extension of AspectJ with a history-based language fea- ture called Tracematches that enables the programmer to trigger the execution of extra code by specifying a regular pattern of events in a computation trace. The underlying pattern matching involves a binding of values to free variables. Nobakht et al. [16] monitors calls and returns with the same Java Debugger Architecture we have also evaluated in the implementation section. The debug- ger is very slow compared to aspect-oriented approaches. Their specification language is equivalent in expressive power to regular expressions. Because the grammar for the specifications is fixed, the user cannot specify a convenient structure themselves, and data is not considered. Chen et al. [5] present Java- MOP, a run-time monitoring tool based on aspect-oriented programming which uses context-free grammars to describe properties of the control flow of histories. However, properties on the data-flow are predefined built-in functions (basically AspectJ functions such as a ‘target’ to bind the callee and ‘this’ to bind the caller, comparable to built-in attributes of terminals in our setting). This limits the expression of data properties. Though, to circumvent this limitation one may hack general properties into the tool implementation. In contrast, our approach supports a general methodology to introduce systematically user-defined prop- erties, by means of attributes of non-terminals. Furthermore, SAGA supports conditional productions which are essential to specify protocols dependent on data in a declarative manner. Finally, JavaMOP does not directly support the specification of local histories (i.e., monitoring the messages sent and received by a single object). LARVA is developed by Colombo et al. [8]. The specification language has an imperative flavor: users define a finite state machine to define the allowed history (i.e., one has to ‘implement’ a regular expression themselves). It is not possible to directly express context-free protocols. Data properties are supported, though in a limited manner, by enriching the state machine with con- ditions on method parameters or return values. It is not possible to specify a local 7 Available in the ACM Digital Library with the title Prototyping a tool environment for run-time assertion checking in JML with communication histories, authored by Frank S. de Boer, Stijn de Gouw and Jurgen Vinju
- 37. 24 F.S. de Boer et al. history of a single object. DeLine and Fähndrich [10] propose a statically check- able typestate system for object-oriented programs. Typestate specifications of protocols correspond to finite state machines (assertions are not considered in their approach), thus for example a stack cannot be properly specified. To the best of our knowledge, no other approach integrates protocol-oriented properties into existing state-based assertion languages. The integration does not involve an extension of the syntax and semantics of the assertion language itself. As an important consequence, no change in the implementation of the state- based assertion checker is needed, in contrast to the following works. Cheon and Perumandla present in [6] an extension of the JML compiler with call sequence assertions. Call sequence assertions are regular expressions (proper context-free grammars cannot be handled) over method names and the data sent in calls and returns is not considered. Protocol properties (call sequence assertions) are handled separately from data properties, and as such are not integrated into the general context of (data) assertions. The proposed extension to call sequence assertions involves changing the existing JML-compiler (in particular, both the syntax and the semantics of JML assertions are extended), whereas in our test suite integrating with JML consists only of a simple pre-processing stage. Con- sequently in our approach no change in the JML-compiler is needed, and new versions of the JML-compiler are supported automatically, as long as they are backwards compatible. Hurlin [12] presents an extension of the previous work to handle multi-threading, which however is not supported by run-time verification (instead it discusses static verification). As in the previous work, an integration of protocol properties with assertions is not considered. Trentelman and Huis- man [21] describe a new formalism extending JML assertions with Temporal Logic operators. A translation for a subset of the Temporal Logic formulae back to standard JML is described, and as future work they intend to integrate their extension into the standard JML-grammar which requires a corresponding new compiler. Future Work. SAGA visualizes the offending history of a Java program that violates the given attribute grammar in the form of a UML sequence diagram. For industrial applications the histories (and consequently the corresponding diagram) can get very large, even when projecting away irrelevant events with the communication view. In such cases we found it is very useful to (further) filter events from the diagram, focussing on a specific part of the diagram. For instance, only showing all events in which a particular object was involved. The sequence diagram editor used by SAGA provides preliminary support for filtering using low-level UNIX system-based utilities grep and sed, but more high-level solutions specifically tailored for sequence diagrams would be even more useful. Furthermore, for debug purposes it would be convenient to visualize the current contents of the heap. Another line of future work concerns offline monitoring. Offline monitoring serializes and stores the history of a running program in a file. This file is checked later for correctness, possibly on a different computer. This allows companies to enable monitoring production code deployed at clients with little performance
- 38. Run-Time Assertion Checking of Data- and Protocol-Oriented Properties 25 penalty: the histories can be checked on dedicated computers at the company instead of at the client. A potential disadvantage of off line monitoring is that it is not possible anymore to stop a running system directly after the attribute grammar is violated (or inspect the content of the heap at that time). Acknowledgements. We wish to express our gratitude to Behrooz Nobakht for his help on the integration with the Java debugger and Jurgen Vinju for the helpful discussions and major contributions to our Rascal tool. References 1. Allan, C., Avgustinov, P., Christensen, A.S., Hendren, L.J., Kuzins, S., Lhoták, O., de Moor, O., Sereni, D., Sittampalam, G., Tibble, J.: Adding trace matching with free variables to aspectj. In: OOPSLA, pp. 345–364 (2005) 2. Bauer, A., Leucker, M., Schallhart, C.: Comparing LTL semantics for runtime verification. J. Log. Comput. 20(3), 651–674 (2010) 3. Burdy, L., Cheon, Y., Cok, D.R., Ernst, M.D., Kiniry, J.R., Leavens, G.T., Leino, K.R.M., Poll, E.: An overview of JML tools and applications. International Journal on Software Tools for Technology Transfer 7(3), 212–232 (2005) 4. Chalin, P., James, P.R., Karabotsos, G.: JML4: Towards an industrial grade IVE for java and next generation research platform for JML. In: Shankar, N., Woodcock, J. (eds.) VSTTE 2008. LNCS, vol. 5295, pp. 70–83. Springer, Heidelberg (2008) 5. Chen, F., Rosu, G.: MOP: an efficient and generic runtime verification framework. In: OOPSLA, pp. 569–588 (2007) 6. Cheon, Y., Perumandla, A.: Specifying and checking method call sequences of java programs. Software Quality Journal 15(1), 7–25 (2007) 7. Clarke, L.A., Rosenblum, D.S.: A historical perspective on runtime assertion check- ing in software development. ACM SIGSOFT Software Engineering Notes 31(3), 25–37 (2006) 8. Colombo, C., Pace, G.J., Schneider, G.: Larva — safer monitoring of real-time Java programs (tool paper). In: SEFM, pp. 33–37 (2009) 9. de Boer, F.S., de Gouw, S.: Run-time verification of black-box components using behavioral specifications: An experience report on tool development. In: Păsăreanu, C.S., Salaün, G. (eds.) FACS 2012. LNCS, vol. 7684, pp. 128–133. Springer, Heidelberg (2013) 10. DeLine, R., Fähndrich, M.: Typestates for objects. In: Odersky, M. (ed.) ECOOP 2004. LNCS, vol. 3086, pp. 465–490. Springer, Heidelberg (2004) 11. Hedin, G.: Incremental attribute evaluation with side-effects. In: Hammer, D. (ed.) CCHSC 1988. LNCS, vol. 371, pp. 175–189. Springer, Heidelberg (1989) 12. Hurlin, C.: Specifying and checking protocols of multithreaded classes. In: ACM Symposium on Applied Computing (SAC 2009), pp. 587–592. ACM Press (2009) 13. Klint, P., van der Storm, T., Vinju, J.: Rascal: a domain specific language for source code analysis and manipulation. In: Walenstein, A., Schupp, S. (eds.) Pro- ceedings of the IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM 2009), pp. 168–177 (2009) 14. Knuth, D.E.: Semantics of context-free languages. Mathematical Systems The- ory 2(2), 127–145 (1968)
- 39. 26 F.S. de Boer et al. 15. Martin, M., Livshits, B., Lam, M.S.: Finding application errors and security flaws using PQL: a program query language. In: OOPLSLA (2005) 16. Nobakht, B., Bonsangue, M.M., de Boer, F.S., de Gouw, S.: Monitoring method call sequences using annotations. In: Barbosa, L.S., Lumpe, M. (eds.) FACS 2010. LNCS, vol. 6921, pp. 53–70. Springer, Heidelberg (2012) 17. Parr, T.: The Definitive ANTLR Reference. Pragmatic Bookshelf (2007) 18. Parr, T.J., Quong, R.W.: Adding semantic and syntactic predicates to LL(k): pred- LL(k). In: Fritzson, P.A. (ed.) CC 1994. LNCS, vol. 786, pp. 263–277. Springer, Heidelberg (1994) 19. Pnueli, A., Zaks, A.: PSL model checking and run-time verification via testers. In: FM, pp. 573–586 (2006) 20. Sipser, M.: Introduction to the theory of computation. PWS Publishing Company (1997) 21. Trentelman, K., Huisman, M.: Extending JML specifications with temporal logic. In: Kirchner, H., Ringeissen, C. (eds.) AMAST 2002. LNCS, vol. 2422, pp. 334–348. Springer, Heidelberg (2002)
- 40. Event Modules Modularizing Domain-Specific Crosscutting RV Concerns Somayeh Malakuti1 and Mehmet Akşit2 1 Software Technology Group, Technical University of Dresden, Germany somayeh.malakuti@tu-dresden.de 2 Software Engineering Group, University of Twente, The Netherlands m.aksit@utwente.nl Abstract. Runtime verification (RV) facilitates detecting the failures of software during its execution. Due to the complexity of RV techniques, there is an increasing interest in achieving abstractness, modularity, and compose-ability in their implementations by means of dedicated linguis- tic mechanisms. This paper defines a design space to evaluate the existing domain-specific languages for implementing RV techniques, and identifies the shortcomings of a representative set of these languages with respect to the design space. This paper advocates the need for a language com- position framework, which offers the necessary mechanisms to achieve abstractness, modularity, and compose-ability in the implementation of domain-specific crosscutting concerns such as the concerns of RV tech- niques. We explain event modules as novel linguistic abstractions for modular implementation of domain-specific crosscutting concerns. This paper discusses the implementation of event modules in the EventRe- actor language, and illustrates the suitability of event modules to imple- ment RV techniques by means of two complementary examples. Keywords: runtime verification, domain-specific languages, aspect- orientation, event-based modularization, event-based composition. 1 Introduction Runtime verification (RV) [1] aims at checking software against its desired prop- erties while the software is executed, e.g., during testing or after it is deployed. Depending on the result of the verification process, various actions may be car- ried out such as notification, suspending execution, fault recovery, etc. In this paper, the term RV technique refers to the program that implements the func- tionality of the runtime verification, and the term base software refers to the software that is being verified by such a technique. To apply RV techniques to real-world complex base software, there is a need for suitable implementation mechanisms/frameworks that ease the implementa- tion of these techniques for industrial practitioners. One may argue that RV tech- niques can be implemented directly as an integral part of the base software in the same general-purpose language (GPL) as the base software. However, this re- quires programmers to have extensive knowledge about suitable algorithms and S. Chiba et al. (Eds.): Transactions on AOSD XI, LNCS 8400, pp. 27–69, 2014. c Springer-Verlag Berlin Heidelberg 2014
- 41. 28 S. Malakuti and M. Akşit mechanisms to implement RV techniques in a GPL. Moreover, the implementa- tion of both base software and RV techniques can easily become complex and hard to comprehend. This is because RV techniques usually crosscut [2] the base soft- ware, meaning that they need to interact with various different parts of the base software to collect the necessary information and/or to heal them from failures. The aforementioned problems in implementing RV techniques motivate language designers to seek suitable linguistic constructs for implementing RV techniques. A close look at the literature [3–14], lets us observe that achiev- ing abstractness, modularity, and compose-ability is of interest in the im- plementation of RV techniques. The abstractness requirement is addressed by providing suitable domain-specific languages (DSLs) for implementing RV tech- niques. The modularity requirement is addressed by providing means to modu- larize individual concerns of RV techniques from each other and from the base software. The compose-ability requirement is addressed by providing suitable op- erators to compose individually modularized RV concerns with each other and with the base software under the specified constraints. Although several RV DSLs have been introduced in the literature and this trend seems to be continuing, they fall short of fulfilling the abstractness, mod- ularity, and compose-ability requirements. To be able to identify the source of their shortcomings, this paper identifies the concerns that typically appear in RV techniques, defines a design space for the RV DSLs, and evaluates a repre- sentative set of current RV DSLs with respect to this design space. To overcome the identified shortcomings, this paper identifies characteristic features of RV techniques, and introduces Event Composition Model, which offers event modules as novel linguistic abstractions to achieve abstractness, modularity, and compose-ability in the implementation of domain-specific cross- cutting concerns such as the concerns that exist in RV techniques. This paper explains EventReactor as a language composition framework that implements Event Composition Model, and by means of two examples, shows the suitability of EventReactor for implementing various kinds of RV techniques. In this paper we extend our previous work [15, 16] in the following ways: – We study a large number of RV DSLs and derive a conceptual model for RV techniques. – We present a mind map of the design space for RV DSLs which facilitates the comparison of current RV DSLs. – We evaluate a representative set of RV DSLs and identify their shortcomings in fulfilling abstractness, modularity, and compose-ability in the implemen- tation. – We define a new version of Event Composition Model, in which domain- specific concerns can be modularized and composed better. – We present its implementation, EventReactor, which covers the design space. – We demonstrate the suitability of EventReactor to achieve abstractness, modularity, and compose-ability in the implementation by means of two comprehensive examples. – We present our evaluation of the runtime overhead of EventReactor.
- 42. Modularizing Domain-Specific Crosscutting RV Concerns 29 This paper is organized as follows: Section 2 elaborates on the problem state- ment; Section 3 discusses the requirements for an RV language composition framework and explains Event Composition Model. Sections 4 and 5 explain the EventReactor language and its runtime behavior, respectively. Section 6 illus- trates the expressiveness of event modules by means of an example. Section 7 discusses the runtime overhead of EventReactor, and Sections 8 and 9 outline the discussion and future work, respectively. 2 Problem Statement While RV techniques can be implemented in a GPL and can manually be applied to the base software during the software development process, there is an increas- ing interest to have DSLs [3–14] for this matter so that the implementation of RV concerns become more abstract and declarative, and the implementation effort is reduced. A closer look at the existing RV DSLs lets us observe three require- ments that are typically considered important in the design of these DSLs: a) abstractness, b) modularity, and c) compose-ability of implementations. The abstractness requirement indicates that suitable domain-specific con- structs are needed to implement various kinds of concerns that appear in RV techniques in a declarative, concise, and abstract manner; this is in fact one of the main goals of adopting DSLs instead of GPLs. In the literature [17], a module is defined as a reusable software unit with well-defined interfaces, which encapsulates its implementation. The modularity requirement indicates that a language must facilitate representing individual concerns that appear in an RV technique as individual modules with well-defined interfaces. The interfaces express the information that the modules provide and require from the other modules for the purpose of runtime verification. The internal implementation of these modules, which is expressed in a DSL, must be encapsulated. If a language falls short to provide a one-to-one mapping between a concern of interest and the modules of a program, the implementation of the concern scatters across and tangles with the implementation of other concerns in the program [18]. Scattering and tangling are well-known problems in the aspect-oriented community [2], which reduce the modularity and increase the complexity of programs. The compose-ability requirement means that a language must offer suitable mechanisms to compose individually modularized RV concerns with each other so that the target RV technique is achieved. The example composition mecha- nisms are explicit method invocation, implicit invocation by means of events, and inheritance. The composition may be constrained, and the constraints must also be modularized and programmed in their DSLs. There are plenty of legacy soft- ware systems whose functionality must be extended with RV. Thus modularity and compose-ability must also be considered from the perspective of separating the implementation of RV concerns from the base software and composing these two into an executable system.
- 43. 30 S. Malakuti and M. Akşit To be able to identify the degree to which the aforementioned requirements are fulfilled by the current RV DSLs, in this section we first identify the typical concerns that appear in RV techniques, derive a design space for RV DSLs, and accordingly, we identify the shortcomings of a representative set of RV DSLs. Finally, we illustrate the shortcomings by means of an example. 2.1 Typical Concerns in RV Techniques Our comprehensive study on the current RV techniques and DSLs [3–14, 19, 20], reveals that four kinds of concerns typically appear in RV techniques: Base Soft- ware, Observation, Verification, and Action. Figure 1 represents the interactions among these concerns. – Base Software is the software whose correctness must be ensured by an RV technique. – Observation is the concern that abstracts the necessary information for the purpose of runtime verification from the base software. This information can be, for example, the invocation of a method, the value of a variable that is updated, etc. – Verification is the concern that checks the expected and/or unexpected prop- erties of the base software; for this matter, it receives the necessary infor- mation from the base software. The verification of the specified properties results in new information, for example, indicating whether the properties are satisfied or violated. base information verification information adaptation information base information Fig. 1. Typical concerns in RV techniques – Action represents what needs to be performed as the result of verification. Typical examples are diagnosing the causes of failure and recovering the base software from failures [19, 20]. Actions are triggered by the verification concerns, and may exchange information with the base software, for example, for the purpose of recovery. As Figure 1 shows, in general, RV concerns have a crosscutting [2] nature. For example, the observation concerns may crosscut the base software to receive the information from various places in the base software. Likewise, actions may
- 44. Modularizing Domain-Specific Crosscutting RV Concerns 31 crosscut the base software, for example, if they need to apply modifications to multiple places in the base software. Not only the execution of the base software be verified, but also the execution of the verification concerns and actions. For this purpose, the notion of base software can be extended to include verification concerns and actions; higher- level verification concerns can, then, observe and manipulate the execution of this extended base software. Such hierarchal organizations are quite common in adaptive control systems, for example, where multiple levels of control systems can be stacked on each other. 2.2 A Design Space for RV DSLs The degree to which the abstractness, modularity, and compose-ability require- ments are fulfilled by the current RV DSLs differs per language. To establish a basis for the comparison of these languages, in Figure 2, we represent a set of possible alternatives in designing a language for implementing an RV Concern. Fig. 2. Design Space of RV DSLs In Figure 2, the dimension fixed means that the implementation of an RV Concern is fixed in an RV DSL, or it is not possible at all to implement the con- cern by the available constructs of the RV DSL; the opposite is programmable. If an RV Concern is programmable, there are two possibilities in its abstractness: domain-specific and general-purpose. The former means that there are dedicated domain-specific constructs to implement the RV Concern, and the latter means that the RV DSL adopts the elements of a GPL for this matter, which natu- rally reduces the abstractness of implementations. If there are domain-specific constructs, they can either be dependent on or independent of the language in which the base software is implemented. RV DSLs usually have limited expres- sion power; this is mainly because they provide constructs that are dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. The dimension expressivity indicates that
- 45. 32 S. Malakuti and M. Akşit the set of offered domain-specific constructs by an RV DSL can be predefined or it can be extendable with new constructs. Supporting a predefined set of constructs may limit the possibility to program various different kinds of RV concerns in an RV DSL. As the dimension modularity shows, a programmable RV concern may be modularized from other RV concerns and the base software; the opposite is tan- gled, meaning that the implementation of a concern is not well separated from the implementation of other concerns. The dimension compose-ability indicates that an RV DSL must offer suitable composition operators so that individual RV concerns can be composed with each other to form the target RV technique. An RV DSL can either fix the available composition operators, or it can make them programmable by offering suitable linguistic constructs for this matter. 2.3 Shortcomings of the Existing RV DSLs w.r.t the Design Space In this part, we evaluate a representative set of RV DSLs with respect to the design space that is shown in Figure 2. The evaluation is performed for the linguistic constructs that an RV DSL offers for defining the specification of ob- servation, verification, and action concerns. Table 1. The design space applied to the specification of observation concern Fixed Programmable Abstractness Modularity Compose-ability DS GP Tangled Mod. Fixed Prog. Language Dep. Expressivity Dep. Indep. Pred. Prog. MaCS + + + + PQL + + + + Polymer + + + + JavaMOP + + + + RMOR + + + + Trace- matches + + + + E-Chaser + + + + TraceContract + + + JASS + APP + Spec# + Temporal Rover +
- 46. Modularizing Domain-Specific Crosscutting RV Concerns 33 Specification of Observation Concerns: An RV DSL may offer dedicated constructs to specify the information that must be abstracted from the base software. This information can be in form of events and/or data values. As Ta- ble 1 shows, MaCS [3], PQL [11], Polymer [12], JavaMOP [4], Tracematches [13], RMOR [5], and E-Chaser [10] offer a predefined set of dedicated linguistic con- structs for this matter. Among these languages, only the constructs offered by E-Chaser are independent of the language of base software. TraceContract [14], is an internal DSL [21] which makes use of the libraries offered by the Scala programming language. In TraceContract, the observable information is defined as events, and new kinds of events can be defined. However, as it is inherent for internal DSLs, the specifications are dependent on the GPL in which the internal DSLs are defined. JASS [6], APP [9], Temporal Rover [7], and Spec# [8] do not offer any construct to define the specification of observation concerns. In these languages, the verification concerns and actions are embedded in the base software, and refer to the variables defined within the base software. Along the modularity dimension, MaCS facilitates modularizing the specifi- cations through so-called PEDL (Primitive Event Definition Language) specifi- cations. In JavaMOP, PQL, and Tracematches, the specification of observation concerns is separated from the base software; however, these specifications are tangled with the verification concerns and actions within one module. Polymer facilitates the modularization of specifications by offering so-called action mod- ules, which closely resemble Java classes. In RMOR, the specification of observa- tion concerns can be expressed separately from the specification of verification concerns and actions. E-Chaser facilitates the modularization of specification by means of the so-called superimposition specifications. In TraceContract, the specifications can be modularized using the modularization mechanism offered by Scala. With respect to the compose-ability dimension, MaCS facilitates compos- ing primitive fields and variables via Boolean operators. Tracematches adopts the pointcut language of AspectJ [22] to express the specification of observa- tion concerns, and supports Boolean operators to compose pointcut expressions. Similarly, RMOR offers a pointcut language similar to the one in AspectJ or AspectC [23], and supports Boolean operators to compose pointcut expressions. JavaMOP extends the pointcut language of AspectJ with two new predicates; AspectJ pointcuts can be composed with each other via Boolean operators; the JavaMOP-specific predicates can be composed with each other and with AspectJ ones via the conjunction operator. The other languages do not offer constructs for programming the abstracted information with each other. Specification of Verification Concerns (Properties): As Table 2 shows, all investigated RV DSLs offer dedicated formalisms to specify the properties to be verified. Among these, JavaMOP, E-Chaser, and TraceContract are pro- grammable with new kinds of formalism. Only MaCS, E-Chaser, RMOR, and Tracematches facilitate specifying the verification concerns independently from
- 47. 34 S. Malakuti and M. Akşit Table 2. The design space applied to the specification of verification concerns Fixed Programmable Abstractness Modularity Compose-ability DS GP Tangled Mod. Fixed Prog. Language Dep. Expressivity Dep. Indep. Pred. Prog. MaCS + + + + PQL + + + + Polymer + + + + JavaMOP + + + + RMOR + + + + Trace- matches + + + + E-Chaser + + + + TraceContract + + + JASS + + + + APP + + + + Spec# + + + + Temporal Rover + + + + the language of base software. JavaMOP is also in this category, except for its raw specifications, which are programmed in the Java language. MaCS offers a dedicated language, called MEDL (Meta Event Definition Lan- guage), for the modular specification of verification concerns; however, the com- position of verification concerns with observation concerns and actions is tangled in MEDL specifications. Polymer does not have a clear distinction between the specification of verification concerns and actions; together they are considered as security policy, and are tangled within one module. In PQL, JavaMOP, and Tracematches also the specification of verification concerns is tangled with the specification of observation concerns and actions. RMOR facilitates modulariza- tion of specifications. TraceContract and E-Chaser facilitate modularizing the specification of verification concerns from the specification of observation con- cerns; however, the specification of actions remains tangled with the specification of verification concerns. In JASS, APP, Spec#, and Temporal Rover, the speci- fications of verification concerns are tangled within the base software. Along the dimension of compose-ability, PQL facilitates programming the composition of properties by means of so-called sub-queries; a complex property is the composition of a set of smaller properties expressed as sub-queries. Poly- mer treats the specifications of policies as Java objects and offer so-called policy combinators to compose multiple policies with each other; new policy combi- nators can be programmed. In TraceContract, properties can be composed in a hierarchical manner through invoking a dedicated function with a variable
- 48. Modularizing Domain-Specific Crosscutting RV Concerns 35 length argument list; properties are provided as arguments to this function. Spec# supports inheritance operator to compose the specifications. The other evaluated languages do not facilitate the composition of verification concerns with each other. Table 3. The design space applied to the specification of actions Fixed Programmable Abstractness Modularity Compose-ability DS GP Tangled Mod. Fixed Prog. Language Dep. Expressivity Dep. Indep. Pred. Prog. MaCS + + + PQL + + + + Polymer + + + + JavaMOP + + + RMOR + + + Trace- matches + + + E-Chaser + + + + TraceContract + + + JASS + + + APP + + + Spec# + Temporal Rover + + + + Specification of Actions: As Table 3 shows, MaCS, JavaMOP, RMOR, Trace- matches, JASS, APP, and Temporal Rover adopt the constructs of the language in which the base software is implemented to express the actions. PQL and Polymer offer a predefined set of dedicated constructs for this matter, which are dependent on the Java language. E-Chaser supports a method invocation as the action, and this is specified independently from the language of base soft- ware. Spec# does not offer dedicated constructs for the specification of actions; it raises an exception if the verification fails. TraceContract by default reports the error trace, but it is also possible to program desired actions in the Scala language. From the perspective of modularity, in all DSLs except MaCS and RMOR the specifications of actions are tangled with the specification of verification con- cerns. From the perspective of compose-ability, PQL offers a predefined operator, i.e., the sequential composition of specifications. Polymer facilitates composing multiple actions by means of policy combinators. E-Chaser does not facilitate the composition of actions. In the languages in which actions are expressed in a GPL, actions can be composed with each other using the adopted GPL.
- 49. 36 S. Malakuti and M. Akşit 2.4 Illustration of the Shortcomings Since the existing RV DSLs do not span the full design space, the abstractness, modularity, and compose-ability requirements cannot be fulfilled in the imple- mentation of RV techniques if these languages are adopted. In this section, we illustrate these shortcomings by the example of a document-editing software to which runtime verification must be applied. The document-editing software has the three core modules Authentication, DocumentManager, and Storage. These provide the functionality to authenti- cate users, to edit a document, and to save its contents on the file system, respectively. Authentication and DocumentManager are implemented in Java, and Storage is implemented in C. Figure 3 shows a UML sequence diagram that depicts the sequence of causally dependent invocations that handle a save request issued by the user. Here, the user first logs in to the system, by invoking the method login on the object anAuthentication. Then, eventually, s/he starts a save operation by invoking the method save on the object aDocumentManager of type DocumentManager. Subsequently, the functions open, write, and finally close are invoked on Storage. The user eventually logs out from the application. For the sake of brevity, we omitted the objects that facilitate inter-language communication. We assume that each user modifies one document at a given time, and that the request to modify the document is handled in one causal thread of execution that spans across anAuthentication, aDocumentManager, and Storage. Assume that we would like to verify the sequence of invocations depicted in Figure 3, to ensure that a request to save a document by an authenticated user eventually results in storing the document on the file system. There are two kinds of failure. First, the save request is issued by an un-authenticated user. Second, after invocation of save by an authenticated user, any of the other invocations does not occur in the specified order before the user logs out. As recovery actions, we would like to first log an error message and then prevent the execution of the method whose invocation violates the specified sequence. We consider two possibilities for implementing the aforementioned runtime check using the available RV DSLs: (a) using a single RV DSL, and (b) using a different RV DSL for each base implementation language. If we would like to adopt a single RV DSL, the linguistic constructs of the RV DSL must be sufficiently abstract to express runtime behavior of base programs implemented in various different languages. As Table 1 shows, only E-Chaser fa- cilitates abstracting information from the base software implemented in different languages. However, as we show in [10], E-Chaser cannot preserve the modular- ity of specifications for the base software implemented in multiple languages. Moreover, it cannot verify the causal-dependency of the invocations that span across modules implemented in different languages. Alternatively, we would like to use a different RV DSL for each language envi- ronment. To implement the running example, we use JavaMOP for the Java part
- 50. Modularizing Domain-Specific Crosscutting RV Concerns 37 anAuthentication aDocumentManager Storage login save open write close aUser logout Fig. 3. The sequence of method invocations to save a document and RMOR for the C part. Listing 1 shows an excerpt of the JavaMOP specification, which defines that the three events login, logout, and save must be abstracted from instances of the Java classes Authentication and DocumentManager. The events login and logout represent the state changes after the execution of the methods login and logout on instances of the class Authentication. The event save represents the state change before the execu- tion of the method save on instances of the class DocumentManager. The regular expression in line 8 indicates that somewhere between the occurrence of login and logout (i.e., only when the user is authenticated), the event save may oc- cur. The specification in lines 9 to 12 indicates that an error message must be shown if the verification of the regular expression fails, and the execution of the corresponding method must be prevented. 1 event login after(Authentication a) : 2 execution(∗ Authentication.login()) target(a) {} 3 event logout after(Authentication a) : 4 execution(∗ Authentication.logout()) target(a) {} 5 event save before(DocumentManager d) : 6 execution(∗ DocumentManager.save()) 7 target(d) {} 8 ere : (login save∗ logout)∗ 9 @fail { 10 System.err.println(”Problem in saving the document!”); 11 SKIP; 12 } Listing 1. A specification of the Java part Listing 2 shows an excerpt of the RMOR specification, which defines that the three events open, write, and close must be abstracted from the C module Storage. The specification of the state machine in lines 4 to 7 indicates that when the event open occurs, a transition to the state Opening must take place,
- 51. 38 S. Malakuti and M. Akşit which expects the event write to be the next event that occurs. If the event write or any other event occurs in the state Opening, there will be a transition to the built-in state error, which indicates that this is an unexpected event. 1 event open = before execution(Storage.c:open); 2 event write = before execution(Storage.c:write); 3 event close = before execution(Storage.c:close); 4 initial state Opening {when open − Opening; when write−error;/∗...∗/} 5 live state Opening {when write − Writing;/∗...∗/} 6 live state Writing {when close − Closing;/∗...∗/} 7 live state Closing {/∗...∗/} Listing 2. A specification of the C part With the state-of-the-art RV DSLs, the specifications are lacking abstractness because they are dedicated to one GPL. This prevents us from specifying the desired properties of the base software in a correct way. For example, we need to specify that the sequence of events specified in lines 4 to 7 of Listing 2 must occur after the event save specified in Listing 1. However, this can neither be specified in JavaMOP nor in RMOR; consequently, we have to provide a third DSL dedicated for expressing the compositions of these specifications, which can be a costly task. It is therefore preferable that an RV DSL offers linguistic constructs that are sufficiently abstract to deal with software implemented in various languages. Since the adopted specification languages make use of the elements of a GPL, we were obliged to sacrifice the modularity of specifications by splitting them based on the implementation language of base software; in our example, the specification of sequence of events is divided in two modules. As a consequence, compose-ability of specifications is reduced since there is no standard linguistic mechanism for composing the specifications that are expressed in various RV DSLs. 3 Towards an RV Language Composition Framework The shortcomings of the current RV DSLs in expressing, modularizing, and com- posing diverse kinds of RV techniques may consequently oblige software engineers to design and implement new RV DSLs. However, the design and implementa- tion of a new RV DSL from scratch requires extensive knowledge of language design, and may be a time-consuming task. Moreover, the existing RV DSLs share several abstractions, unfortunately, without sharing an implementation. To ease the design and implementation of RV DSLs, we advocate the need for a language composition framework, which offers the necessary linguistic mecha- nisms to define new DSLs while providing the mechanisms to achieve modularity and compose-ability in the implementation of domain-specific crosscutting con- cerns. To this aim, this section first identifies the characteristic features of RV concerns that must be respected by such a framework. Afterwards, it explains
- 52. Modularizing Domain-Specific Crosscutting RV Concerns 39 Event Composition Model that is a base model for such a framework, and dis- cusses its suitability for this matter. 3.1 Characteristic Features of RV Concerns A closer look at the model depicted in Figure 1 and the languages discussed in the previous section reveals the following characteristic features of RV concerns. First, the interactions among the concepts of RV techniques have by nature a transient characteristic, meaning that the changes in the states of a concern drive the other concerns. For example, the verification concerns observe the changes that occur in the states of the base software, and verify the state changes of interest against the specified properties of the base software. Various RV techniques may require to consider various kinds of state changes; examples are a time-out value, and an invocation of a method on an object. This implies that an RV language composition framework must facilitate defining open-ended kinds of state changes in the base software as well as in RV concerns. Second, it is not easy or even possible to foresee all kinds of concerns that appear in the RV techniques of today or in future. For example, some techniques require to specify and verify the sequence of method invocations in the base software, whereas some others may require to specify and verify the properties of operating system processes. The steady development of new RV DSLs that support new kinds of formalisms to specify the properties is a consequence of this. Therefore, as the second requirement, we claim that an RV language composition framework must facilitate implementing open-ended kinds of RV concerns such that the specifications are modular. Third, although Figure 1 shows a fixed hierarchy of concerns, in a general case, the kinds of compositions cannot be fixed. For example, an RV technique itself may be considered as the base software whose behavior must be checked at runtime, a specification may be composed of multiple sub-specifications, etc. This indicates that an RV language composition framework must facilitate im- plementing open-ended kinds of compositions. Finally, due to the increasing number of multi-language software systems (e.g., embedded software) to which RV techniques must be applied, an RV language composition framework must support open-ended sets of base languages. 3.2 Event Composition Model In [15, 16], we introduced Event Composition Model as a model, which respects the aforementioned characteristic features. In this section, we explain a revised version of this model whose concepts are shown in Figure 4 via a UML class diagram. At a high level of abstraction, Event Composition Model considers the exe- cution Environment as a set of Events and Event Modules. In software systems, events typically represent changes in the states of interest and are means for abstracting the execution trace of programs. As the class Event Type shows,
- 53. 40 S. Malakuti and M. Akşit Fig. 4. Event Composition Model events are typed entities; Base Event Type and Reactor Event Type are two main specializations. The former represents the events that occur in the base software, and the latter represents the events that are published by so-called event modules that will be explained in the subsequent paragraphs. Event Com- position Model does not fix the event types and events; new kinds of application and/or domain-specific event types and events can be defined in the language composition framework. As the class Attribute in Figure 4 shows, each event type defines a set of attributes for events; these are means to keep the abstracted information from the execution trace of software. The attributes are classified into Static and Dynamic. The former includes the set of attributes whose values do not change and are known at the time an event is defined in the framework. The latter defines the set of attributes whose values are known when an event is published during the execution of software. For example, for an event that corresponds to the invocation of a method, the name and the value of parameters can be defined as static and dynamic attributes of the event, respectively. Event Composition Model considers name, publisher, returnflow, thread, and stacktrace as predefined attributes. These attributes respectively specify the unique name of an event in the framework, the publisher of the event, and the changes that must be applied to the flow of execution of the publisher after an event is successfully processed, the thread of execution in which the event is pub- lished, and a report of the active stack frames at the time the event is published. For the reactor events, the attribute inner keeps a reference to the input event being processed by an event module. More application and/or domain-specific attributes can be defined for each type of event. Event Composition Model introduces Event Module as a means to modularize a group of related events and the reactions to them. In software engineering, a module is usually considered as a referable entity with well-defined interfaces.
- 54. Modularizing Domain-Specific Crosscutting RV Concerns 41 Two kinds of interfaces, known as input and output, are typically considered for a module. The former defines the services that a module requires from its context; the latter specifies the services that a module provides to its context. A module also has an implementation part, which is bound to its interfaces to provide the specified interfaces. Modules promote encapsulation by utilizing interfaces as their interaction points with their context. As Figure 4 shows, event modules adhere to the above definition of modules in the following ways. An event module is identifiable and referable by its unique name. An event module has an Input Interface, an implementation – which is termed as Reactor Chain–, and an Output Interface; these elements are bound to each other. The input interface of an event module specifies the set of events of interest to which the event module must react. Event Composition Model does not fix the semantics for selecting the events of interest and for binding them to the input interface of an event module. One important difference between the input interface of modules in programming languages and the input interface of event modules is that in programming languages input interfaces are invoked explicitly, whereas in event modules invocations are implicit. The explicit invocation means that programmers write code for invoking the input interface of a module. In contrast, implicit invocation [24] means that there is no need for such code, and when an event of interest occurs, the corresponding event module is activated by the language composition framework. Figure 4 shows that the implementation of an event module contains a set of Reactors and Variables. Each reactor processes (a subset of) the events specified in the input interface of the event module. Reactors are typed entities; a Reactor Type is a domain-specific type that defines the semantics in processing the events of interest. Reactors can be composed with each other within a reactor chain. Such reac- tors can exchange information among each other via the variables defined within the corresponding reactor chain. While processing an input event, a reactor may publish new events, which are termed as reactor events. Via the attribute inner a reference to the input event being processed by the reactor is maintained. The output interface of an event module defines the set of events that are published by the event module to its context. To be able to process events, event modules are instantiated during the execution of software based on some Instantiation Strategy; the strategies can be programmed according to the ap- plication/domain demands. 3.3 Motivations to Adopt Event Composition Model Event Composition Model respects the characteristic features of RV concerns identified in Section 3.1 in the following ways. Events are means to implement the transient nature of RV concerns. Various kinds of RV concerns can uni- formly be implemented and modularized as event modules. The support for domain-specific reactor types facilitates expressing the RV concerns of interest
- 55. Another Random Document on Scribd Without Any Related Topics
- 56. You holler ag'in, and I'll strip the clothes off yer back! she hissed. Hold yer tongue, or I'll call Ed. He won't stand no foolin'! Sue struggled fiercely, but it was of no use. The woman shifted her easily to one arm, and with the other hand searched her pocket. Not even a handkerchief! she said. No jew'lry, neither. Well, your mother's got sense, anyway. Hallo! here's a ring, though. Guess I'll take that. Le' go, sis, or I'll hurt ye. It—it's not my ring! gasped Sue, shaking her head free. It's hers— my friend's. Don't take it! Guess it's mine, now! said the woman, with a chuckle. She forced back the girl's slender fingers, and drew off the gold mouse-ring. There! now you can go, dears; and next time, you take my advice, and get some of your folks to take you to the circus. Ah! and be thankful I've left you them pretty hats. I know a little girl as would be pleased to death with that hat with the feathers; but you might take cold if I let ye go bare-headed, and I'm a mother myself. Trembling, half fainting, the girls found themselves outside the tent. The grounds were well-nigh deserted, all the spectators being gone. Here and there a group of stragglers leaned on the railings of the neighboring fence, smoking and talking. Rough-looking men were at work about the tents, and some of them looked curiously at the girls as they hurried along. Neither spoke. Clarice was still whimpering and crying under her breath. Sue's eyes were blazing; her cheeks felt on fire. She ran hastily across the grounds, dragging Clarice after her by the hand. She felt every moment as if they might be seized and carried back to that horrible den. Suppose the man should be coming after them now! He might put them in prison, and her mother would never know where she was. She choked back the sob that rose in her throat. On, on, as fast as feet could fly! At last the palings were reached and passed. Now they could stop to draw breath, for they were on the highroad, and out of sight of the hated inclosure. Panting, Sue leaned against the fence, and waited till she
- 57. should have breath enough to speak some word of encouragement to her companion. No one was in sight; there was no sound save the crickets keeping time in the grass. All was as peaceful and serene as if there were no dreadful things or wicked people in the world. They were not far from the station now, and once in the train for home, with the friendly conductor, who knew her and would take charge of them both— Then, suddenly, a new thought flashed into Sue's mind, and struck ice into the fever of her blood. How long had they been in that dreadful place? How was it that no one was to be seen going toward the station, of all the throng that had come up with them in the train? Clarice! she gasped. I am—afraid—we may miss the train. We must run. It isn't far now. Run as fast as you possibly can! Clarice answered with a sob; but she began to run as well as her foolish dress and shoes would let her. But another answer came at that moment: a whistle, long and clear, loud at first, then growing fainter and fainter till it died away. In desperation the girls flew on along the road—to reach the station and find it empty! The long curve of the rails stretched away toward home. The train was gone!
- 58. CHAPTER X ALL'S WELL THAT ENDS WELL S ix o'clock was supper-time in the little town of Chester, so the usual loungers had left the station as soon as the train departed; and by the time the girls arrived it was deserted, even by the ticket-seller. No one was in sight; at least, they saw no one. They were too much absorbed in their trouble to notice two faces that peeped at them for a moment round the corner of the station, and then vanished. They were alone, six miles from home, with no money. What were they to do? Clarice broke out in tearful reproaches: Sue Penrose, you have brought us to this! It is all your fault! I never should have thought of coming up here if it hadn't been for you. Sue looked at her, but made no reply. Clarice's eyes dropped under the steady look; she faltered, but hurried on: And losing all my money, too! If you hadn't lost my money, I should not have been robbed of my beautiful jewelry—all I had in the world! and it was worth lots and lots. Sue, in bitterness of spirit, thought, How about the diamond chain? but she said nothing. She felt, suddenly, many years older than Clarice. Was this a girl of fifteen, whimpering like a baby? Was this the friend for whom she had given up Mary?
- 59. And how are we ever to get home? asked Clarice, in conclusion. We must walk! said Sue, briefly. Walk! shrieked Clarice. Sue Penrose, are you crazy? It's twenty miles, if it's a step! Nonsense! said Sue. It's a short six miles. That's just as bad! moaned Clarice. You know I should die before we had gone a mile; you know I should, Sue! Isn't there some one we can borrow money from? Can't we go to the hotel and telephone to somebody at home? They might indeed have done this, but in her excited state Sue could not think it possible. Her high-strung, sensitive nature was strained beyond the possibility of sober judgment; she could only act, and the action that began instantly was the only one that she could think of. Besides, to see more strangers, perhaps meet with more insults— never! They must walk home; there was no other way; and they must start this instant. I am sure you can do it, Clarice, she said, speaking as cheerfully as she could. You can take my arm, and lean on me when you are tired; and every little while we can sit down and rest. Come! we must start at once; it will be dark before we get home, as it is. Clarice still protested, but yielded to the stronger will, and the two girls started on their lonely walk. As they turned their backs on the station, a head was cautiously advanced from behind the building; a pair of sharp eyes followed the retreating figures for a few moments, then the head was as cautiously withdrawn. The road from Chester to Hilton was a pleasant one. On one side was the railway, with the river beyond; on the other, green meadows rolling up and away to the distant hills. There were few houses, and these scattered at long distances. To Sue the road was familiar and
- 60. friendly enough; but to Clarice it seemed an endless way stretching through an endless desert. She was thoroughly frightened, and her blood was of the kind that turns to water; very different from the fire that filled Sue's veins and made her ready to meet an army, or charge a windmill or a railway-train, or anything else that should cross her path. Over and over again Clarice lamented that she had ever come to Hilton. Why did I come to this hateful, poky place? she wailed. Aunt Jane didn't want me to come. She said there wouldn't be anybody here fit for me to associate with. Oh! why did I come? I suppose because you wanted to! said Sue; and it might have been Mary that spoke. Come, Clarice, she went on more gently, we might as well make the best of it. Let's tell stories. I'll begin, if you like. Do you know about the Maid of Saragossa? That is splendid! Or Cochrane's 'Bonny Grizzy'? Oh! she had to do much worse things than this, and she never was afraid a bit—not a single bit. Sue told the brave story, and the thrill in her voice might have warmed an oyster; but Clarice was not an oyster, and it left her cold. Grizzy is a horrid, ugly name, she said. And I think it was real unladylike, dressing up that way, so there! Clarice!—Sue's voice quivered with indignation,—when it was to save her father's life! How can you? But perhaps you will care more about the Maid of Saragossa. But after a while Clarice declared that the stories only made her more nervous. She was unconscious of the fact that they had carried her over two miles of the dreaded six. Besides, she said peevishly, I can't hear when you are talking, Sue. Listen! I thought I heard footsteps behind us. I do! Sue
- 61. Penrose, there is some one following us! Sue listened. Yes, there were footsteps, some way behind. But, my dear, she said, this is the highroad! Why should they be following us? People have a right to walk on the road—as good a right as we have. They stopped a moment, instinctively, and listened; and the footsteps behind them stopped too. They went on, and the steps were heard again, light yet distinct, keeping the distance between them, neither more nor less. Clarice grasped Sue's arm. They are tramps or robbers, Sue! We are going to be murdered. Oh, I shall scream! You will not scream! said Sue, grasping her arm in return, and resisting the impulse to shake it. You are talking nonsense, Clarice! I believe—I believe it is nothing in the world but an echo, after all. If it were not for this fog, we could see whether there was any one there. She looked back along the road, but the river-fog was rising white and dense, and closed in behind them like a curtain. They can't see us, anyhow, whoever they are! said Sue. Why, it's exciting, Clarice! It's like the people in the forest in 'Midsummer- Night's Dream.' If we were only sure that these were nice people, we might call, and they could answer, and hunt round for us, and it would be fine. Oh, it's awful! It's just awful! moaned Clarice; and she shook with real terror. And the worst of it is, I can't walk any more. I can't, Sue! It's no use! I am going to faint—I know I am. Nonsense! said Sue, stoutly, though her heart sank. Keep up a little, Clarice, do! There is a watering-trough a little farther on, and we can bathe our feet. That will be a great help; and we must be nearly half-way home now.
- 62. But tight lacing and tight shoes are not nonsense. They are very real things, and poor Clarice was really suffering more than Sue had any idea of. The stitch in her side was not imaginary this time. She stopped involuntarily to draw breath; and the footsteps behind them stopped too, and went on when they did. There was no longer any doubt; the girls were being followed. Clarice began to cry again; and Sue set her teeth, and felt that a crisis was coming. Clarice, she said, let me see if I can carry you! I think I can! I know the way Sir Bedivere did with King Arthur: he made broad his shoulders to receive his weight, you know, and round his neck he drew the languid hands—kind of pickaback, you see. You are not heavy; I think I can do it! And she actually took Clarice on her back, and staggered on perhaps a hundred yards—till they both came to the ground, bruised and breathless. I'm going to die! said Clarice, doggedly. I won't walk another step. I may just as well be murdered as plain die. I—can't see! and the poor girl sank down, really half fainting. Sue set her teeth hard. She dragged Clarice back from the road, and propped her against a tree, then took her stand in front of her. She felt no fear; the quicksilver ran riot in her veins. If she only had her dagger, the good sharp dagger paper-knife that she had worn in her boot for two whole months, while she was playing cow-boy! It hurt a good deal, and made holes in her stockings, so she had given it up. What would she not give for it now! Or if she had something poisoned that she could hand to the people when they came up,— like Lucrezia Borgia,—and see them drop dead at her feet! But she had nothing! Stop! yes! her hat-pin, the hat-pin Uncle James had sent her from Russia! Carefully, with a steady hand, she drew out the long, sharp steel pin, and felt its point; then set her back against the tree, and waited.
- 63. The footsteps behind the fog-curtain hesitated, stopped altogether. There was a silence, but Sue's heart beat so loud, the sound seemed to fill the air. All at once, from the opposite direction came another sound, the sound of horses' hoofs, the rattle of wheels; and, as if at a signal, the footsteps came on again, quickened their pace, were close at hand. Two figures loomed through the white fog; paused, as if reconnoitering in the dim half-light. Then, at sight of Sue standing alone before her prostrate companion, they broke into a run, and came up at racing speed, panting. Anything wrong? asked Tom. Because we're right here! said Teddy. Right here, Quicksilver! said Tom. The hat-pin dropped from Sue's hand. A great sob rose and broke,— only one!—and then—oh! it didn't matter now if she was getting to be a big girl. Her arms were round Tom's neck, and her head was on his good broad brotherly shoulder, and she was crying and laughing and saying, Oh, Tom! Oh, Tom! over and over and over again, till that young gentleman began to be seriously alarmed. I say! he said; I wouldn't, Quicksilver! Come! I wouldn't if I were you! Teddy, you've got the handkerchief, haven't you? I had the peanuts, you know. But Teddy, who was going to be a surgeon, was stooping over Clarice with keen professional interest. We might haul her down to the river and put her head in! he said. This hat won't hold water any more; will yours? I say! don't they still bleed people sometimes, when they haven't got salts and things? My knife is just as sharp! Poor Clarice started up with a faint scream. Altogether, these four were so absorbed that they never heard the approaching wheels, and Mr. Hart almost ran over them before he could pull up his horse.
- 64. Hallo! he said. What upon earth—now, Mary, Mary, do be careful, and wait till I—Dear me, sirs! What a set of children! Stand still, Jupiter! For Mary had scrambled down among wheels and legs, and had thrown herself upon Sue and Tom; and Teddy, abandoning Clarice, exhausted himself in a vain endeavor to get his short arms round the three. Oh, Mary, Mary! is it really you? Can you ever forgive me? Sue! Sue, my Sue, don't talk so, dear! It is all my fault, for not telling Mammy this morning. Oh, Tom, you blessed boy, I might have known you would take care of her! Young people, said Mr. Hart, bending over from the wagon, perhaps if you would kindly get in, it might facilitate matters, and you can continue this highly interesting conversation as we go along. Other girl faint? Hand her here, Tom! Put your arm round my neck, my child—so! there we are! They jogged along in silence for a few minutes. Sue and Mary had nothing to say at first—in words, at least. They sat with their arms round each other's neck and their heads together. Now and then one would make a little murmur, and the other respond; but for the most part they were still, too full of joy to speak. What happened, Tom? asked Mr. Hart, when he thought time enough had elapsed to quiet the excitement a little. Why, sir, said Tom, we saw the girls, of course; but then we lost sight of them after the circus,—I don't know how (Sue shuddered and Clarice moaned),—so we went straight to the station. So when they didn't get there in time for the train, we thought we'd better wait and see how things were. So we followed them along— Oh, Tom, we were so frightened! cried Sue. Of course you didn't know how frightened we were, Tom—but I had my hat-pin all ready to stick into you!
- 65. No! had you? said Tom, chuckling. You young ninny! said his father. Why didn't you join the girls, instead of hanging behind and scaring them half to death? Tom hung his head. I—it was awfully stupid! he said. Because I was a fool, sir, I suppose, and thought— Because I was a fool, Mr. Hart! said Sue. Because I had been wicked and hateful and ungrateful, and a Perfect Pig, and he knew it! Mrs. Hart sat at her window, sewing her seam and listening to the music she loved best, the music of children's voices. There were five of them, her own three and the two Penroses; and they were all sitting on the broad door-step, husking sweet corn and talking. Sue had just come over; she had been helping Katy, who had a lame arm. She looked pale and grave, for the adventure of two days before seemed still very near; yet her eyes were full of light as she looked from one to the other of the children, gazing as if she could not get her fill. Now and then she and Mary held out a hand and exchanged a silent squeeze that meant rivers of speech; but somehow Tom seemed to be doing most of the talking. Look at that! he said, holding up an ear like glossy ivory, every row perfect as a baby's teeth. Isn't that bully? Save the silk, Sue and Lily! We want to make wigs for the harvest feast to-night. Oh, tell me! cried Sue, her eyes kindling. A harvest feast? What fun! Why, hasn't Mary told you? You and Lily are coming to tea, you know, and we thought we would make it a harvest tea. So we are all to wear corn-silk wigs, and we're going to put the candles in Jack-o'- lanterns—little ones, you know; squashes, of course, or apples. Apples will be best! said Mary. I have some pound sweets all picked out. We meant this for a surprise, you know, Tom, but never mind! It's really better fun for us all to know.
- 66. Lots! said Tom. I forgot, though, about the surprise part. And then—it'll be full moon—we'll go out Jack-o'-lanterning, and that'll be no end; and then Mammy says we can roast chestnuts, and Father has the bonfire all ready, and we'll have a celebration. A Quicksilver Celebration, eh, Sue? Oh, Tom! said Sue. Not Quicksilver any more; just stupid, stupid, grubby lead—and rusty, too! Lead doesn't rust, said Teddy, gravely. This lead does! And—I've got something to read to you all. It is part of my penance, Mary. Yes, I will! It isn't all true, but part of it is. She drew a letter from her pocket (it was written on pink paper, scented with cheap scent), and began to read: Miss Clarice Stephanotis Packard presents her compliments to Miss Susan Penrose, and tells her that I am going home to-morrow with my Papa, and I never shall come to this mean place any more. It is all my fault for assoshating with my soshal inpheriars, and if you hadn't have poked your nose into my afairs, Miss Penrose, and put your old candy in my pew, I shoud not have been robbed and most murderd. The girl here says I could have the law of you to get back the money my mouse ring cost,— What girl? asked Mary. Sue blushed hotly. The—the chambermaid, she said. She—Clarice has made a kind of companion of her. She isn't a very nice girl, I'm afraid. Then resuming the reading— but Papa says he will get me a new one, and I shall see that nobody gets that away from me. You never will see me again, Sue, but you will have those common Harts; I supose they will be glad enouf to take up with you again. So I remain, Miss Penrose,
- 67. Yours truly, Miss Clarice Stephanotis Packard. Sue's eyes remained fixed on the paper; her cheeks glowed with shame and mortification; she could not meet her friends' eyes. There was a moment of dead silence; then came a sound that made her look up hastily, blushing still deeper. Why! why, you are all laughing! she cried. My dear, of course we are laughing! cried Mary, catching her in her arms. What should we do but laugh? And we are glad to take up with you again, aren't we, boys? Rather! said Tom. Why, Sue, it's been only half living without our Quicksilver. Have you really missed me? cried poor Sue. Oh, Tom! Of course I know Mary has, because I know how wretched I have been, really, all the time, even at first, when I didn't know it. But you, too, and Teddy? Oh, I am so glad! so glad! And now there are five of us, aren't there, Lily? Lily answered with a warm caress. She knew privately that she was the happiest of the five, but she did not know how to say it. Five of us! echoed Teddy. I say! we ought to have a name. The Frisky Five! No! that isn't good. Somebody else try! The Festive Five! suggested Tom. But Mary shook her head. I have it! she said. Join hands, all! the Faithful Five! Hurrah for us! The five children stood up and held hands, looking at one another with a certain solemnity. The Faithful Five! they repeated. Hurrah for us!
- 68. And Teddy added: But we'll make a toast of it to-night with shrub— lots of shrub! And now we must make the wigs! said Mary. We'll do that in the barn chamber, so that we sha'n't mess with the silk. And then can't we climb a tree? said Sue, plaintively. I haven't climbed a tree for a month, Mary! I will be Isabella of Buchan, if you like, and you can all capture me and put me in the cage in the greening-tree. All right! Hurrah! Come on! The joyous voices died away; and Mrs. Hart took off her glasses and wiped her eyes, but not before a tear had fallen on her work. Bless them! she said. And hurrah for them! This may have been a good thing, after all. An hour later Sue was bending once more over her journal; but this time Mary's arms were round her, and Mary's eyes were looking over her shoulder as she wrote. My troubles are over, and they were all my own fault; but now I am happy, and nothing but death can part me and Mary. I have the dearest and best friends in the world— Oh, don't, Sue! said Mary. I shall! said Sue, and wrote on: And I have told Mamma all about everything, and she has forgiven me, and now we are all different, and she is perfectly lovely, and we understand all about things together, like Mary and her mother. And I hope I am going to be a better girl now all my life; but still the name I shall always love best is that I am Mary's own 'Quicksilver Sue.'
- 69. Transcriber's Note: Obvious typographical errors have been corrected. Inconsistent spelling and hyphenation in the original document have been preserved.
- 70. *** END OF THE PROJECT GUTENBERG EBOOK QUICKSILVER SUE *** Updated editions will replace the previous one—the old editions will be renamed. Creating the works from print editions not protected by U.S. copyright law means that no one owns a United States copyright in these works, so the Foundation (and you!) can copy and distribute it in the United States without permission and without paying copyright royalties. Special rules, set forth in the General Terms of Use part of this license, apply to copying and distributing Project Gutenberg™ electronic works to protect the PROJECT GUTENBERG™ concept and trademark. Project Gutenberg is a registered trademark, and may not be used if you charge for an eBook, except by following the terms of the trademark license, including paying royalties for use of the Project Gutenberg trademark. If you do not charge anything for copies of this eBook, complying with the trademark license is very easy. You may use this eBook for nearly any purpose such as creation of derivative works, reports, performances and research. Project Gutenberg eBooks may be modified and printed and given away—you may do practically ANYTHING in the United States with eBooks not protected by U.S. copyright law. Redistribution is subject to the trademark license, especially commercial redistribution. START: FULL LICENSE
- 71. THE FULL PROJECT GUTENBERG LICENSE
- 72. PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK To protect the Project Gutenberg™ mission of promoting the free distribution of electronic works, by using or distributing this work (or any other work associated in any way with the phrase “Project Gutenberg”), you agree to comply with all the terms of the Full Project Gutenberg™ License available with this file or online at www.gutenberg.org/license. Section 1. General Terms of Use and Redistributing Project Gutenberg™ electronic works 1.A. By reading or using any part of this Project Gutenberg™ electronic work, you indicate that you have read, understand, agree to and accept all the terms of this license and intellectual property (trademark/copyright) agreement. If you do not agree to abide by all the terms of this agreement, you must cease using and return or destroy all copies of Project Gutenberg™ electronic works in your possession. If you paid a fee for obtaining a copy of or access to a Project Gutenberg™ electronic work and you do not agree to be bound by the terms of this agreement, you may obtain a refund from the person or entity to whom you paid the fee as set forth in paragraph 1.E.8. 1.B. “Project Gutenberg” is a registered trademark. It may only be used on or associated in any way with an electronic work by people who agree to be bound by the terms of this agreement. There are a few things that you can do with most Project Gutenberg™ electronic works even without complying with the full terms of this agreement. See paragraph 1.C below. There are a lot of things you can do with Project Gutenberg™ electronic works if you follow the terms of this agreement and help preserve free future access to Project Gutenberg™ electronic works. See paragraph 1.E below.
- 73. 1.C. The Project Gutenberg Literary Archive Foundation (“the Foundation” or PGLAF), owns a compilation copyright in the collection of Project Gutenberg™ electronic works. Nearly all the individual works in the collection are in the public domain in the United States. If an individual work is unprotected by copyright law in the United States and you are located in the United States, we do not claim a right to prevent you from copying, distributing, performing, displaying or creating derivative works based on the work as long as all references to Project Gutenberg are removed. Of course, we hope that you will support the Project Gutenberg™ mission of promoting free access to electronic works by freely sharing Project Gutenberg™ works in compliance with the terms of this agreement for keeping the Project Gutenberg™ name associated with the work. You can easily comply with the terms of this agreement by keeping this work in the same format with its attached full Project Gutenberg™ License when you share it without charge with others. 1.D. The copyright laws of the place where you are located also govern what you can do with this work. Copyright laws in most countries are in a constant state of change. If you are outside the United States, check the laws of your country in addition to the terms of this agreement before downloading, copying, displaying, performing, distributing or creating derivative works based on this work or any other Project Gutenberg™ work. The Foundation makes no representations concerning the copyright status of any work in any country other than the United States. 1.E. Unless you have removed all references to Project Gutenberg: 1.E.1. The following sentence, with active links to, or other immediate access to, the full Project Gutenberg™ License must appear prominently whenever any copy of a Project Gutenberg™ work (any work on which the phrase “Project Gutenberg” appears, or with which the phrase “Project Gutenberg” is associated) is accessed, displayed, performed, viewed, copied or distributed:
- 74. This eBook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. 1.E.2. If an individual Project Gutenberg™ electronic work is derived from texts not protected by U.S. copyright law (does not contain a notice indicating that it is posted with permission of the copyright holder), the work can be copied and distributed to anyone in the United States without paying any fees or charges. If you are redistributing or providing access to a work with the phrase “Project Gutenberg” associated with or appearing on the work, you must comply either with the requirements of paragraphs 1.E.1 through 1.E.7 or obtain permission for the use of the work and the Project Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9. 1.E.3. If an individual Project Gutenberg™ electronic work is posted with the permission of the copyright holder, your use and distribution must comply with both paragraphs 1.E.1 through 1.E.7 and any additional terms imposed by the copyright holder. Additional terms will be linked to the Project Gutenberg™ License for all works posted with the permission of the copyright holder found at the beginning of this work. 1.E.4. Do not unlink or detach or remove the full Project Gutenberg™ License terms from this work, or any files containing a part of this work or any other work associated with Project Gutenberg™. 1.E.5. Do not copy, display, perform, distribute or redistribute this electronic work, or any part of this electronic work, without prominently displaying the sentence set forth in paragraph 1.E.1
- 75. with active links or immediate access to the full terms of the Project Gutenberg™ License. 1.E.6. You may convert to and distribute this work in any binary, compressed, marked up, nonproprietary or proprietary form, including any word processing or hypertext form. However, if you provide access to or distribute copies of a Project Gutenberg™ work in a format other than “Plain Vanilla ASCII” or other format used in the official version posted on the official Project Gutenberg™ website (www.gutenberg.org), you must, at no additional cost, fee or expense to the user, provide a copy, a means of exporting a copy, or a means of obtaining a copy upon request, of the work in its original “Plain Vanilla ASCII” or other form. Any alternate format must include the full Project Gutenberg™ License as specified in paragraph 1.E.1. 1.E.7. Do not charge a fee for access to, viewing, displaying, performing, copying or distributing any Project Gutenberg™ works unless you comply with paragraph 1.E.8 or 1.E.9. 1.E.8. You may charge a reasonable fee for copies of or providing access to or distributing Project Gutenberg™ electronic works provided that: • You pay a royalty fee of 20% of the gross profits you derive from the use of Project Gutenberg™ works calculated using the method you already use to calculate your applicable taxes. The fee is owed to the owner of the Project Gutenberg™ trademark, but he has agreed to donate royalties under this paragraph to the Project Gutenberg Literary Archive Foundation. Royalty payments must be paid within 60 days following each date on which you prepare (or are legally required to prepare) your periodic tax returns. Royalty payments should be clearly marked as such and sent to the Project Gutenberg Literary Archive Foundation at the address specified in Section 4, “Information
- 76. about donations to the Project Gutenberg Literary Archive Foundation.” • You provide a full refund of any money paid by a user who notifies you in writing (or by e-mail) within 30 days of receipt that s/he does not agree to the terms of the full Project Gutenberg™ License. You must require such a user to return or destroy all copies of the works possessed in a physical medium and discontinue all use of and all access to other copies of Project Gutenberg™ works. • You provide, in accordance with paragraph 1.F.3, a full refund of any money paid for a work or a replacement copy, if a defect in the electronic work is discovered and reported to you within 90 days of receipt of the work. • You comply with all other terms of this agreement for free distribution of Project Gutenberg™ works. 1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™ electronic work or group of works on different terms than are set forth in this agreement, you must obtain permission in writing from the Project Gutenberg Literary Archive Foundation, the manager of the Project Gutenberg™ trademark. Contact the Foundation as set forth in Section 3 below. 1.F. 1.F.1. Project Gutenberg volunteers and employees expend considerable effort to identify, do copyright research on, transcribe and proofread works not protected by U.S. copyright law in creating the Project Gutenberg™ collection. Despite these efforts, Project Gutenberg™ electronic works, and the medium on which they may be stored, may contain “Defects,” such as, but not limited to, incomplete, inaccurate or corrupt data, transcription errors, a copyright or other intellectual property infringement, a defective or
- 77. damaged disk or other medium, a computer virus, or computer codes that damage or cannot be read by your equipment. 1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for the “Right of Replacement or Refund” described in paragraph 1.F.3, the Project Gutenberg Literary Archive Foundation, the owner of the Project Gutenberg™ trademark, and any other party distributing a Project Gutenberg™ electronic work under this agreement, disclaim all liability to you for damages, costs and expenses, including legal fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE. 1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you discover a defect in this electronic work within 90 days of receiving it, you can receive a refund of the money (if any) you paid for it by sending a written explanation to the person you received the work from. If you received the work on a physical medium, you must return the medium with your written explanation. The person or entity that provided you with the defective work may elect to provide a replacement copy in lieu of a refund. If you received the work electronically, the person or entity providing it to you may choose to give you a second opportunity to receive the work electronically in lieu of a refund. If the second copy is also defective, you may demand a refund in writing without further opportunities to fix the problem. 1.F.4. Except for the limited right of replacement or refund set forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
- 78. INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PURPOSE. 1.F.5. Some states do not allow disclaimers of certain implied warranties or the exclusion or limitation of certain types of damages. If any disclaimer or limitation set forth in this agreement violates the law of the state applicable to this agreement, the agreement shall be interpreted to make the maximum disclaimer or limitation permitted by the applicable state law. The invalidity or unenforceability of any provision of this agreement shall not void the remaining provisions. 1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation, the trademark owner, any agent or employee of the Foundation, anyone providing copies of Project Gutenberg™ electronic works in accordance with this agreement, and any volunteers associated with the production, promotion and distribution of Project Gutenberg™ electronic works, harmless from all liability, costs and expenses, including legal fees, that arise directly or indirectly from any of the following which you do or cause to occur: (a) distribution of this or any Project Gutenberg™ work, (b) alteration, modification, or additions or deletions to any Project Gutenberg™ work, and (c) any Defect you cause. Section 2. Information about the Mission of Project Gutenberg™ Project Gutenberg™ is synonymous with the free distribution of electronic works in formats readable by the widest variety of computers including obsolete, old, middle-aged and new computers. It exists because of the efforts of hundreds of volunteers and donations from people in all walks of life. Volunteers and financial support to provide volunteers with the assistance they need are critical to reaching Project Gutenberg™’s goals and ensuring that the Project Gutenberg™ collection will
- 79. remain freely available for generations to come. In 2001, the Project Gutenberg Literary Archive Foundation was created to provide a secure and permanent future for Project Gutenberg™ and future generations. To learn more about the Project Gutenberg Literary Archive Foundation and how your efforts and donations can help, see Sections 3 and 4 and the Foundation information page at www.gutenberg.org. Section 3. Information about the Project Gutenberg Literary Archive Foundation The Project Gutenberg Literary Archive Foundation is a non-profit 501(c)(3) educational corporation organized under the laws of the state of Mississippi and granted tax exempt status by the Internal Revenue Service. The Foundation’s EIN or federal tax identification number is 64-6221541. Contributions to the Project Gutenberg Literary Archive Foundation are tax deductible to the full extent permitted by U.S. federal laws and your state’s laws. The Foundation’s business office is located at 809 North 1500 West, Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up to date contact information can be found at the Foundation’s website and official page at www.gutenberg.org/contact Section 4. Information about Donations to the Project Gutenberg Literary Archive Foundation Project Gutenberg™ depends upon and cannot survive without widespread public support and donations to carry out its mission of increasing the number of public domain and licensed works that can be freely distributed in machine-readable form accessible by the widest array of equipment including outdated equipment. Many
- 80. small donations ($1 to $5,000) are particularly important to maintaining tax exempt status with the IRS. The Foundation is committed to complying with the laws regulating charities and charitable donations in all 50 states of the United States. Compliance requirements are not uniform and it takes a considerable effort, much paperwork and many fees to meet and keep up with these requirements. We do not solicit donations in locations where we have not received written confirmation of compliance. To SEND DONATIONS or determine the status of compliance for any particular state visit www.gutenberg.org/donate. While we cannot and do not solicit contributions from states where we have not met the solicitation requirements, we know of no prohibition against accepting unsolicited donations from donors in such states who approach us with offers to donate. International donations are gratefully accepted, but we cannot make any statements concerning tax treatment of donations received from outside the United States. U.S. laws alone swamp our small staff. Please check the Project Gutenberg web pages for current donation methods and addresses. Donations are accepted in a number of other ways including checks, online payments and credit card donations. To donate, please visit: www.gutenberg.org/donate. Section 5. General Information About Project Gutenberg™ electronic works Professor Michael S. Hart was the originator of the Project Gutenberg™ concept of a library of electronic works that could be freely shared with anyone. For forty years, he produced and distributed Project Gutenberg™ eBooks with only a loose network of volunteer support.
- 81. Project Gutenberg™ eBooks are often created from several printed editions, all of which are confirmed as not protected by copyright in the U.S. unless a copyright notice is included. Thus, we do not necessarily keep eBooks in compliance with any particular paper edition. Most people start at our website which has the main PG search facility: www.gutenberg.org. This website includes information about Project Gutenberg™, including how to make donations to the Project Gutenberg Literary Archive Foundation, how to help produce our new eBooks, and how to subscribe to our email newsletter to hear about new eBooks.
- 82. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com