Model-driven generation of runtime checks for system properties

Abstract

Creating runtime monitors for interesting properties is an important research problem. Existing approaches to runtime verification require specifications that not only define the property to monitor, but also contain details of the implementation, sometimes even requiring the implementation to add special variables or methods for monitoring. Often intuitive properties such as “event X should only happen when objects A and B agree” have to be translated by developers into complex specifications, for example, pre- and post-conditions on several methods that only in concert express this simple property. In most specification languages, the result of this manual translation are specifications that are so strongly tailored to the program at hand and the objects involved that, even if the property occurs again in a similar program, the whole translation process has to be repeated to create a new specification. In this paper, we introduce the concept of property templates. Property templates are pre-defined constraints that can be easily reused in specifications. They are part of a model-driven framework that translates high-level specifications into runtime monitors specialized to the problem at hand. The framework is extensible: Developers can define property templates for constraints they often need and can specialize the code generation when the default implementation is not satisfactory. We demonstrate the use of the framework in some case studies using a set of functional and structural constraints that we developed through an extensive study of existing software specifications. The key innovations of the approach we present are three. First, the properties developed with this approach are reusable and apply to a wide range of software systems, rather than being ad hoc and tailored to one particular program. Second, the properties are defined at a relatively high level of abstraction, so that no detailed knowledge of the implementation is needed to decide whether a given property applies. Third, we separate the definition of precise assertions for properties, and the use of properties. That way, experts can determine which assertions are needed to assure properties, and other developers can easily use these definitions to annotate systems.

Appendix A Property template catalog

With the language for the formal semantics defined in Sect. 3, we can now fully and formally describe our property templates. The property template catalog in this section lists the example set of property templates we identified, describes their semantics, and defines the assertions used to detect violations of the properties.

1.1 A.1 Comparable

The comparable property (Fig. 8) addresses the case where language frameworks and libraries provide consistent sets of container classes following a common super interface, or as is more often the case, assume that classes using the framework implement a set of well-defined comparison methods, denoted $M$. This is a special case of explicit $\mathtt{< }$ I $\mathtt{> }$, because instead of requiring an explicit interface, it checks for the existence of a set of methods.

Fig. 8

Catalog entry for comparable

For example, in the Java Collection Framework, $M$ would contain equals() and hashCode(). The precise contents of $M$ are language and framework dependent; hence, they have to be specified by the transformation, and not as part of the high-level semantics.

1.2 A.2 Explicit $\mathtt{< }$ I $\mathtt{> }$

The explicit property (Fig. 9) declares that annotated classifiers must directly implement the interface I. By directly, we mean that the classifier must provide its own implementation of the interfaces methods. This property is violated if the classifier only inherits the interface’s methods from a superclass.

Fig. 9

Catalog entry for explicit

A good example for when this property is useful is in implementations of the AbstractFactory or FactoryMethod design patterns [32]. The patterns are centered around the concept of concrete classes explicitly implementing an abstract method or interface that decouple concrete implementations from client code.

This property is particular in the sense that at a first glance it appears that checks for implicit implementation would best be done statically by a compiler. However, even though technically this is possible, to the best of our knowledge, no programming language provides declarative means to specify this property. Furthermore, it would be even harder to statically enforce this property across library and component boundaries. The compiled binaries would have to contain enough information to enable static checking of clients, which requires additional infrastructure to be used by the developers of the components and the final system, while runtime checks of this property only require additional infrastructure deployed together with the final system.

1.3 A.3 Immutable

The immutable property (Fig. 10) declares that instances of annotated classifiers must not change their visible state after creation or the invocation of an explicit locking operation. If no locking operation is specified, the object must not change its visible state after instance construction completes. The latter is inspired by Unkel and Lam’s research, which indicates that immutable behavior after explicit locking or from a certain location in the code on is typical for many kinds of programs [42]. The current implementation considers the constructor to be the locking operation.

Fig. 10

Catalog entry for immutable

1.4 A.4 Initialized

The initialized property (Fig. 11) implies that classifier-specific initialization has completed before any references to instances of the classifier are used. The basic semantics for a classifier $C$ annotated with initialized state that whenever a method that is not a constructor or the specified initializer is executed, then initialization must have occurred. Note that this refers only to method executions, not to field accesses. The rationale for this is that typical idioms in object-oriented languages suggest that fields be only accessible through dedicated accessor methods. Many languages, for example, Objective C [43] and Groovy [44], even generate accessor methods automatically if programmers do not specify them explicitly, hence making direct field access unnecessary.

Fig. 11

Catalog entry for initialized

To allow for various design patterns that require initialization of objects outside the object constructor, the initialized property takes an optional parameter that specifies a dedicated initialization operation. initializer methods are exempt from the rule that instances of the classifier have to be initialized before operations can be used. If there is no explicit initializer defined on an initialized classifier, the constructor is considered the initializer. In this case, initialized is merely a tag with no effect.

We discuss an example of this property in Sect. 4.2.

1.5 A.5 Language $\mathtt{< }$ L $\mathtt{> }$

The language property (Fig. 12) declares that a visible string value must match a regular language L. Formally, the annotation language $\mathtt{< }$ L $\mathtt{> }$ on a method parameter $p$ or class attribute $a$ denotes that $p \in \mathtt {L}$ or $a \in \mathtt {L}$, respectively. Since we require that L be a regular language, we use common regular expressions to specify L. The assertions shown in Fig. 12 should be considered an exclusive choice. If and only if the annotation is placed on a parameter, then the assertions with the method call pointcut is used, and vice versa.

Fig. 12

Catalog entry for language $\mathtt{< }$ L $\mathtt{> }$

This property effectively defines method pre-conditions or class invariants. As such it is at the same abstraction level as the implementation. However, the actual constraint to be expressed can stem from system-level requirements, like in the example in Sect. 4.2, or from implementation-specific choices, and thus represent both high- and low-level constraints.

1.6 A.6 Notnull

The notnull property (Fig. 13) constrains parameters or return values not to be null. Even though the concept of null values exists only at the implementation level, this property emerged from the definition of more abstract properties, such as initialized, and has proven itself to be useful for debugging and quality assessment in component-based software (see the nanoxml case study in Sect. 4.2).

Fig. 13

Catalog entry for notnull

1.7 A.7 Singleton

The singleton property (Fig. 14) checks that a class maintains the semantics of the Singleton design pattern, that is, there is only one instance of the class in the entire system.

Fig. 14

Catalog entry for singleton

Even though the pattern is structurally simple, concurrent programs and language-specific issues can introduce corner cases that are easily missed by implementers. For example, the naive implementation in Fig. 15 is not thread safe. Given two threads $T1$ and $T2$, the sequence $T1.8,T2.8,T$1.9-11, $T$2.9-11 leads to two instances of the same class being created and returned to the respective callers.

Fig. 15

Naive Singleton implementation

Other, language-specific factors, for example, the time and order of static variable creation and class loading, can also introduce subtle problems with straightforward implementations of this pattern.

1.8 A.8 Unique

The unique property (Fig. 16) declares that instances of a given type must be unique within some context. The context is determined by the annotated model element. An annotation on a classifier declares that instances of this type must be globally unique. An annotation on an association declares that instances must be unique within the context of the annotated association relation. Uniqueness of an instance is determined by an attribute of the involved classifiers. By default, the hashCode of instances is used. If this is not appropriate, the optional parameter uniquenessProperty declares which property of the classifier determines uniqueness.

Fig. 16

Catalog entry for unique

Intuitively, monitoring tracks potential changes to the uniqueness attribute and evaluates the assertions every time a change occurred. For unique, annotations placed on classifiers, the context, and thus the container is the entire heap rather than a specific association.⁸

Treatment of annotated classifiers is straightforward. Instance creation and destruction are monitored, and every new instance is compared against all currently existing instances.

Handling of annotated associations is more involved, because the context of the association must be included. First, associations may only be annotated if they are 1-to-$n$ or a $n$-to-$m$ relationships. Instances participating in 1-to-1 relationships are naturally unique and no monitoring is necessary. Additionally, the container must expose operations to query its contents, so that the generated assertions have access to this state information. Defaults can be based on common implementation patterns, or alternatively, property template users could specify the relevant operations through parameters to the annotation (this is not expressed in the above semantics and not yet implemented). For the semantics above, null values are not considered objects and they are skipped in the checks for uniqueness.