• automated analysis & definition of requirements
• computer-aided design of software
• implementation with intelligent IDEs
• automated testing and verification
• computer-aided bug finding
• aiding program understanding by mining latent specifications from existing software
• advanced debugging & profiling techniques
• computer-aided refactoring and documentation

The course webpage contains a rough outline of the topics that we have planned but at this point we are still open for suggestions, as long as they fit the general topic.

It’s a great feeling to get this weight of my shoulders. 311 pages were not easy to manage in the end… Many thanks to everyone who contributed to the document, especially to Jan Sinscheck, who still found quite a few typos and misplaced commata in the end. The thesis will shortly be available through eScholarship@McGill and through ProQuest (as PDF and in print).

Here are two photos of the event.

Lots of people commented on my slides and so I thought that I should put them online. Here is an extended version of the talk, which I presented in Darmstadt. Available for Keynote (25 MB) and as PDF (93 MB – yes I do like using lots of pictures). The slides give information about both the Clara framework and the Nop-Shadows Analysis.

The CASED research cluster is actually doing quite some exciting research. Folks here conduct research on all levels of security, from low-level hardware issues to secure architectures.

For me, nothing else will change, really. My main task will, fortunately, still remain pursuing fun (and hopefully useful) research. Just to let you know so that nobody is getting confused about my new affiliation…

What else is happening? Since I finished writing up my thesis in Montreal, I have been busy getting settled in Germany again and refilling the paper pipeline. Next week I will be back to Montreal for my thesis defense. Wednesday is the day to keep your fingers crossed for me.

I just uploaded a new Technical Report. The report (currently under submission) describes a novel typestate analysis, called Nop-Shadows Analysis,  that I implemented for my doctoral dissertation. The analysis is certainly one of my dissertation’s major technical contributions. I implemented the Nop-Shadows Analysis in the Clara framework, which means that you are welcome to download it, try it out or extend it.

Continuation-equivalent states

So what are these continuation-equivalent states that appear in the title? We say that two automaton states s1 and s2 are continuation-equivalent if, given the current code location and all possible continuations of the execution after this location we either will or won’t reach a violating typestate regardless of whether we are in s1 or s2. Maybe an example is in order… (taken from the paper)

Assume that we want to evaluate the “ConnectionClosed” property that is depicted by the state machine on the right. The property says that it is an error to write to a closed Connection (where connections can alternate between an “connected” and a “closed” state through “close” and “reconnect” operations. Next, assume that we want to statically evaluate this property on the following simple program…

The figure on the right shows a program that is annotated with the analysis information that the Nop-Shadows Analysis computes. The example program violates the connection property by closing the connection (even twice, at lines 5 and 6), and then writing to the connection (line 7). Note, though, that all other statements in this program are irrelevant to the property violation. In particular, one does not need to monitor the “close” and “reconnect” operations at lines 3 and 4 because they precede the violating fragment of the run. Conversely, the operations at lines 8 to 10 follow this fragment, and hence do not need to be monitored either. A little more subtle, even of the the two“close” events at lines 5 and 6, it is correct to omit monitoring one of them. (But not
both!) The static analysis that we present in the paper will eliminate the instrumentation at exactly those shadows that we just identified as irrelevant—“nop shadows”, as we call them. Instrumentation will only remain in lines 5 and 7, or 6 and 7—an optimal result for this program.

The Nop-Shadow Analysis uses a deterministic finite-state machines for the mirror language of the original automaton’s language (see Figure 4b) to construct for every statement a partitioning of automaton states. States that are in the same class of the partition are continuation-equivalent. For instance, at line 3, which transitions from state 0 to 1, states {0,1,2} are all continuation-equivalent. Therefore there is no need to monitor the transition at this line – the transition is irrelevant!

Results

The analysis has several nice properties. Firstly, it is relatively efficient, and it is precise (see Figure). Also, it seems to be the first analysis of its kind (a flow-sensitive typestate analysis generating residual runtime monitors) that is sound. Unfortunately, we found an unsoundness problem in two analyses that we and others published earlier. The paper describes this problem in the related-work section. For my dissertation, I proved the novel Nop-Shadows Analysis sound, which was relatively easy because the analysis follows a relatively simple design.

Typestate properties aid program understanding, and one can even define type systems that prevent programmers from causing typestate errors, or derive static typestate analyses that try to determine whether a given program violates typestate properties. Unfortunately, the typestate-analysis problem is generally undecidable. Researchers have therefore proposed a hybrid approach that uses
static-analysis results to generate a residual runtime monitor. This monitor captures actual property violations as they occur, but only updates its internal state at relevant statements, as determined through static analysis.

Clara allows researchers to implement such hybrid typestate analyses with a minimal amount of code.

For Researchers, Clara offers:

• a convenient specification format for typestate properties, called Dependency State Machines,
• an extensible framework to implement static typestate analyses quickly and with high quality,
• automatic support for generating residual runtime monitors, even for collaborative runtime verification, and
• a platform to share specifications and compare analysis results.

For Developers, Clara offers:

• tool support to precisely define the behavioral interface of an application,
• tool support to check whether client code fulfills these specifications, and if not
• the possibility to have a residual runtime monitor that deals with property violations just-in-time.

We wish to extend Clara in the future. Please join our mailing list if you want to stay tuned on further developments. Or, if you even feel like extending Clara with your own analyses, download the tool and, if you feel like it, drop us a line.

Details about the Clara framework

Clara’s major design goal is to de-couple the code-generation for efficient runtime monitors from the static analyses that convert these monitors into faster, residual monitors. The figure to the right gives an overview of Clara. With Clara, the researcher first defines a set of typestate properties, denoting each property as an annotation to an AspectJ aspect that implements a runtime monitor for the same property. Annotations directly encode a non-deterministic finite-state machine. In my dissertation, I show how researchers can even use runtime- monitoring approaches like tracematches, JavaMOP, and others, to generate these annotated aspects automatically from high-level monitor specifications.

Clara weaves the monitoring aspect into the program under test and emits helper classes that implement the run- time monitor as defined by the aspect. Clara extends the  AspectBench Compiler for this purpose. Clara then invokes its static-typestate-analysis engine. Researchers can add a number of static analyses to Clara and have them applied in any order. These analyses obtain, through the finite-state machine defined in the aspect’s annotation, enough in- formation about the typestate property to precisely approximate the set of relevant instrumentation points. When an analysis determines that an instrumentation point is irrelevant to a property, i.e., the program can neither violate the property nor prevent a property violation at this point, then Clara automatically disables the instrumentation for this property at this point. The result is an optimized instrumented program that updates the runtime monitor only at program points at which instrumentation remains enabled.

Clara originated as Eric Bodden’s doctoral-thesis project at the Sable Research Group. The design and implementation of Clara was greatly influenced by the work of this group and the Programming Tools Group at the University of Oxford, specifically Laurie Hendren, Patrick Lam, Oege de Moor, Pavel Avgustinov and Julian Tibble. Clara uses technogies from the AspectBench Compiler, Soot, JastAdd, polyglot and other open-source projects.

Through his strong track record, I got to know Feng early on in my research career. When Feng and his supervisor Grigore Rosu invited me over to Urbana Champaign in 2007, we also became friends. Since then, we have integrated our work, co-authored a paper, and actually were planning to further extend our collaboration in the future.

UIUC has set up a memorial fund to allow Feng’s family to visit his funeral.

My thoughts are with Feng’s family and fiancée right now, and of course with Feng himself. May his soul rest in peace.

Update: Mehr hier!

2.Update: Und hier zum Selbermachen!