Yoonsik Cheon’s research while affiliated with The University of Texas at El Paso and other places

An assertion is a Boolean expression embedded in a program that must hold during the execution. Executable assertions are a simple but practical way to check assumptions and code logic at runtime. Assertions are written by referring to concrete program states. In this paper, we recognize a variety of assertions that we call design assertions. These are assertions written to ensure design constraints and properties, not detailed implementation decisions, and thus can detect major problems in the implementation such as design drift or corrosion. However, they are written by referring to concrete program states, thus causing readability and maintenance problems. To address these problems, we propose to write design constraints at a higher abstraction level by referring to abstract program states. We explain our approach using the Dart/Flutter platform, but it should work in other languages and platforms with similar assertion facilities.

A formal correctness proof of code containing loops such as while statements typically uses the technique of proof-by-induction, and often the most difficult part of carrying out an inductive proof is formulating a correct induction hypothesis, a specification for a loop statement. An incorrect induction hypothesis will surely lead to a proof failure. In this paper we propose a systematic way for identifying specifications of while statements. The key idea of our approach is to categorize and document common patterns of while statements along with their specifications. This is based on our observation that similarly-structured while statements frequently have similarly-structured specifications. Thus, a catalog of code and specification patterns can be used as a good reference for finding and formulating a specification of a while statement. We explain our approach using functional program verification in which a program is viewed as a mathematical function from one program state to another, and a correctness proof is done by comparing two functions, the implemented and the specified. However, we believe our approach is applicable to other verification techniques such as Hoare logic using pre- and post-conditions.

In Cleanroom-style functional program verification, a program is viewed as a mathematical function from one program state to another, and the program is verified by comparing two functions, the implemented and the expected behaviors. The technique requires a minimal mathematical background and supports forward reasoning, but it does not support assertions such as class invariants. However, class invariants are not only a practical programming tool but also play a key role in the correctness proof of a program by specifying conditions and constraints that an object has to satisfy and thus defining valid states of the object. We suggest a way to integrate the notion of class invariants in functional program verification by using CleanJava as a specification notation and a verification framework as well; CleanJava is a formal annotation language for Java to support Cleanroom-style functional program verification. We propose a small extension to CleanJava to specify class invariants and to its proof logic to verify the class invariants. Our extension closely reflects the way programmers specify and reason about the correctness of a program informally. It allows one to use class invariants in the framework of Cleanroom-style functional specification and verification.

The CleanJava language is a formal annotation language for Java to support functional program verification. In functional verification, a program is viewed as a mathematical function that maps one program state to another, and thus proving the correctness of a program is essentially comparing two mathematical functions, the function implemented by the program and its specification. Since the CleanJava notation is based on Java expressions with extensions such as mathematical structures like sets and sequences, its vocabulary is limited that of Java. In this paper, we propose to make the CleanJava language more expressive by enhancing its extension mechanism. Our approach is to support user-defined mathematical functions, functions introduced by the user for the purpose of writing annotations. They not only enrich the vocabulary of CleanJava but also allow one to tune the abstraction level of CleanJava annotations. The user-defined mathematical functions are polymorphic---meaning that they may be applied to values of different types---and the signatures of the functions need not be declared. Both the signatures of user-defined functions and the types of CleanJava expressions are inferred statically. Polymorphic functions allow one to write generic and reusable functions, and resulting annotations become more concise and writable. One contribution of our work is bringing polymorphic functions and type inference, found in functional programming languages like SML and Haskell, to object-oriented programming languages like Java in the context of writing annotations, thus blending the benefits of two programming paradigms.

Unlike a Hoare-style program verification, a functional program verification supports forward reasoning by viewing a program as a mathematical function from one program state to another and proving its correctness by essentially comparing two mathematical functions, the function computed by the program and its specification. Since it requires a minimal mathematical background and reflects the way programmers reason about the correctness of a program informally, it can be taught and practiced effectively. However, there is no formal notation supporting the functional program verification. In this paper, we propose a formal notation for writing functional program specifications for Java programs. The notation, called Clean Java, is based on the Java expression syntax and is extended with a mathematical toolkit consisting of sets and sequences. The vocabulary of Clean Java can also be enriched by introducing user-specified definitions such as user-defined mathematical functions and specification-only methods. We believe that Clean Java is a good notation for writing functional specifications and expect it to promote the use of functional program verifications by being able to specify a wide range of Java programs.

Pairwise testing is a combinatorial testing technique that tests all possible pairs of input values. Although, finding a smallest set of test cases for pairwise testing is NP-complete, pairwise testing is regarded as a reasonable cost-benefit compromise among combinatorial testing methods. In this paper we formulate the problem of finding a pairwise test set as a search problem and apply a genetic algorithm to solve it. We also describe an open-source tool called PWiseGen for generating pairwise test sets. PWiseGen produces competitive results compared with existing pairwise testing tools. Besides, it provides a framework and a research platform for generating pairwise test sets using genetic algorithms; it is configurable, extensible, and reusable.

The Java Modeling Language (JML) is a formal interface specification language to document the behavior of Java program modules and has been used in many research and industrial projects. However, its inability to support Java 5 features such as generics is reducing its user base significantly. Besides, the JML compiler is on average 8.5 times slower than the javac Java compiler. In this paper, we present a new JML compiler built on the Eclipse Java compiler to support Java 5 features. We used a technique called AST merging to implement coarse-grained incremental compilation. In our experiments we observed a significant improvement in compilation speed; the new compiler is 3 to 4.5 times faster than the current one.

This document gives a quick tutorial introduction to a functional program verification. In the functional program verification, a program is viewed as a mathematical function from one program state to another, and proving its correctness is essentially comparing two mathematical functions, the function computed by the program and the specification of the program, called an intended function. The reader is assumed to have some programming experience and to be familiar with such mathematical concepts as sets and functions. I.

Random testing can eliminate subjectiveness in construct- ing test data and increase the diversity of test data. How- ever, one difficult problem is to construct test oracles that de- cide test results—test failures or successes. Assertions can be used as test oracles and are most effective when derived from formal specifications such as OCL constraints. If fully auto- mated, random testing can reduce the cost of testing dramat- ically. In this paper we propose an approach for automating Java program testing by combining random testing and OCL. The key idea of our approach is to use OCL constraints as test oracles by translating them to runtime checks written in AspectJ. We realize our approach by adapting existing frame- works for translating OCL to AspectJ and assertion-based random testing. We evaluate the effectiveness of our approach through case studies and experiments. Our approach can de- tect errors in implementations and OCL constraints, as well, and provide a practical means for using OCL in design and programming.