This paper proposes a static analysis technique for detecting many recently discovered application vulnerabilities such as SQL injections, cross-site scripting, and HTTP splitting attacks. These vulnerabilities stem from unchecked input, which is widely recognized as the most common source of security vulnerabilities in Web applications. We propose a static analysis approach based on a scalable and precise points-to analysis. In our system, user-provided specifications of vulnerabilities are automatically translated into static analyzers. Our approach finds all vulnerabilities matching a specification in the statically analyzed code. Results of our static analysis are presented to the user for assessment in an auditing interface integrated within Eclipse, a popular Java development environment. Our static analysis found 29 security vulnerabilities in nine large, popular open-source applications, with two of the vulnerabilities residing in widely-used Java libraries. In fact, all but one application in our benchmark suite had at least one vulnerability.Context sensitivity, combined with improved object naming, proved instrumental in keeping the number of false positives low. Our approach yielded very few false positives in our experiments: in fact, only one of our benchmarks suffered from false alarms.

The agile software development process called Extreme Programming (XP) is a set of best practices which, when used, promises swifter delivery of quality software than one finds with more traditional methodologies. In this paper, we describe a large software development project that used a modified XP approach, identifying several unproductive practices that we detected over its two-year life that threatened the swifter project completion we had grown to expect. We have identified areas of trouble in the entire life cycle, including analysis, design, development, and testing. For each practice we identify, we discuss the solution we implemented to correct it and, more importantly, examine the early symptoms of those poor practices (“bad smells”) that project managers, analysts, and developers need to look out for in order to keep an XP project on its swifter track.

Mock Objects is an extension to Test-Driven Development that supports good Object-Oriented design by guiding the discovery of a coherent system of types within a code base. It turns out to be less interesting as a technique for isolating tests from third-party libraries than is widely thought. This paper describes the process of using Mock Objects with an extended example and reports best and worst practices gained from experience of applying the process. It also introduces jMock, a Java framework that embodies our collective experience.

We present two little languages implemented in Scheme: SchemeUnit, a language for writing unit tests, and SchemeQL, a language for manipulating relational databases. We discuss their design and implementation and show how the features of functional languages in general, and Scheme in particular, contribute to the ease of use and implementation of our languages.

Abstract. Aspect-oriented programming languages promise to provide better modularity than pure object-oriented decomposition. A typical benefit of increased modularity is ease of maintenance, evolution and reuse. However, it has been noted by various researchers that many of the first generation aspect languages do not provide the degree of reusability initially hoped for. In this paper, we argue that the problem is due to a lack of support for aspect genericity, respectively to a lack of support for a sufficiently powerful kind of genericity. We introduce the concept of uniform genericity for aspect languages and discuss in which ways it goes beyond previous approaches to generic aspects. Then we present LogicAJ, a uniformly generic aspect language. Using LogicAJ as an example, we show how uniform aspect genericity recommends itself for implementing reusable solutions of various problems discussed in literature, ranging from the generic replacement of object instantiation, over verification of constraints and conventions, to the generic implementation of design pattern variants. We believe uniform genericity to be an important ingredient for second generation aspect languages whose aspects are only loosely coupled to base programs, thus easing aspect reuse and independent evolution of aspects and base programs. 1

Programmers tend to understand programs by thinking of concrete examples. Example Centric Programming seeks to add IDE support for examples throughout the process of programming. Instead of programmers interpreting examples in their head, the examples are written down and the IDE interprets them automatically. Advanced UI techniques are used to present the results closely integrated with the code. Traditionally distinct programming tools (the editor, Read-Eval-Print-Loop, debugger, and test runner) are unified into a single tool that might be called an example-enlightened editor. This is expected to benefit a wide spectrum of programming activities, for both novice and experienced programmers. Some novel methods for testing and development are suggested. A prototype has been implemented for Java in Eclipse.

Software testing has been commonly used in assuring the quality of database applications. It is often prohibitively expensive to manually write quality tests for complex database applications. Automated test generation techniques, such as Dynamic Symbolic Execution (DSE), have been proposed to reduce human efforts in testing database applications. However, such techniques have two major limitations: (1) they assume that the database that the application under test interacts with is accessible, which may not always be true; and (2) they usually cannot create necessary database states as a part of the generated tests. To address the preceding limitations, we propose an approach that applies DSE to generate tests for a database application. Instead of using the actual database that the application interacts with, our approach produces and uses a mock database in test generation. A mock database mimics the behavior of an actual database by performing identical database operations on itself. We conducted two empirical evaluations on both a medical device and an open source software system to demonstrate that our approach can generate, without producing false warnings, tests with higher code coverage than conventional DSE-based techniques.

Simulation is a common means for validating requirements models. Simulating formal models is state-of-the-art. However, requirements models usually are not formal for two reasons. Firstly, a formal model cannot be generated in one step. Requirements are vague in the beginning and are refined stepwise towards a more formal representation. Secondly, requirements are changing, thus leading to a continuously evolving model. Hence, a requirements model will be complete and formal only at the end of the modeling process, if at all. If we want to use simulation as a means of continuous validation during the process of requirements evolution, the simulation technique employed must be capable of dealing with semi-formal, incomplete models. In this paper, we present an approach how we can handle partial models during simulation and use simulation to support evolution of these models. Our approach transfers the ideas of drivers, stubs, and regression from testing to the simulation of requirements models. It also uses the simulation results for evolving an incomplete model in a systematic way towards a more formal and complete one. 1.

Unit testing is a technique of testing a single unit of a program in isolation. The testability of the unit under test can be reduced when the unit interacts with its environment. The construction of high-covering unit tests and their execution require appropriate interactions with the environment such as a file system or database. To help set up the required environment, developers can use mock objects to simulate the behavior of the environment. In this paper, we present an empirical study to analyze the use of mock objects to test file-system-dependent software. We use a mock object of the FileSystem API provided with the Pex automatic testing tool in our study. We share our insights gained on the benefits of using mock objects in unit testing and discuss the faced challenges. 1

Traditional formal methods and modern agile methods are separated more by limitations of current technology than by fundamental intellectual differences. A mixed interpreter that executes mixed programs, comprising both declarative specification statements and regular imperative statements, might bridge the gap. This paper explores how such an interpreter might be used, showing by example how it might support a variety of development activities.