For program analysis of Java in software engineering, control-flow, data dependence, control dependence, and method call relationships are often required. Existing tools provide features to extract the required information, however, it is difficult to use the tools for users who are unfamiliar with algorithms for program analysis. SOBA (Simple Objects for Bytecode Analysis) is a class library that is easy to use without detailed knowledge of program analysis. This paper introduces main features, design policy, and example programs of SOBA.
Remarkable improvements on SAT solvers over the last decade have led the success of SAT-based solvers. However, existing SAT-based solvers cannot efficiently solve optimization and enumeration problems since those solvers invoke SAT solvers multiple times from scratch and do not reuse search information such as learnt clauses. Recently, incremental SAT method has been proposed to efficiently solve these problems. In addition, such incremental SAT API is proposed in SAT Race 2015. In this paper, we propose iSAT, an extended incremental SAT API, and describe its application. This proposed API allows users to implement SAT-based systems concisely and within Java. We show the effectiveness of using iSAT through experimental results on shop-scheduling, N-queens, and Hamiltonian cycle problems.
The goal of this paper is to develop the GUI library for the functional programming language Haskell. There are several GUI toolkits for functional programming languages but they are based on the object-oriented programming languages such as C++ and Java. Therefore functional GUI programs often take form of imperative codes, and cannot use their functional competence fully. In Haskell, the GUI library called Phooey was developed based on the GUI library wxHaskell to make use of the features of the functional language, but the development of Phooey has been stopped before it reaches to the stage of practical use. In this paper, we improve Phooey and implement the new GUI library called Neooey. Specifically, we divide GUI into layout and process and define them separately to increase the expressiveness of GUI. We also show how to make GUI codes by Neooey. Furthermore, we mention the efficacy of Neooey by use of GUI examples Phooey is not able to express.
To improve the quality of the source code, a various static checkers have been developed. It is important to check and fix source code repeatedly when we use static checkers. However, the alerts reported by static checker include false-positive and those are reported repeatedly. In this paper, we propose a tool to manage the alerts. Our tool records the check rule, the alert message, the target line of source code, and developer's mark for ignoring such as false-positive. We use the blame function of version control system to trace the target code and suppress the alerts marked as the false-positive. Therefore, developer does not need to check the same alerts repeatedly.
This paper gives an overview of verification methods for the security of cryptosystems from basic concepts of cryptography to advanced topics on computer-aided security proofs. The security of cryptosystems is formalized using probabilities and computational complexity of attacks while the mathematical proofs for such security tend to be complicated and error prone. To obtain rigorous security proofs there have been many studies on formalizing and machine-checking proofs using formal methods. Among various verification tools EasyCrypt is the most successful tool that can rigorously construct security proofs more easily than previous tools. In this paper we introduce a method for defining the security of cryptosystems as games among probabilistic polynomial-time (PPT) Turing machines and proving it by game transformation techniques. Then we explain how to formalize such security proofs in the framework of probabilistic relational Hoare logic (pRHL) and to write and machine-check proofs using EasyCrypt. Note that readers do not need to be familiar with cryptography or interactive theorem provers.
Different XML formats are widely used for data exchange and processing, being often necessary to mutually convert between them. Standard XML transformation languages, like XSLT or XQuery, are unsatisfactory for this purpose since they require writing a separate transformation for each direction. Existing bidirectional transformation languages mean to cover this gap, by allowing programmers to write a single program that denotes both transformations. However, they often 1) induce a more cumbersome programming style than their traditionally unidirectional relatives, to establish the link between source and target formats, and 2) offer limited configurability, by making implicit assumptions about how modifications to both formats should be translated that may not be easy to predict. This paper proposes a bidirectional XML update language called BiFluX (BIdirectional FunctionaL Updates for XML), inspired by the Flux XML update language. Our language adopts a novel bidirectional programming by update paradigm, where a program succinctly and precisely describes how to update a source document with a target document in an intuitive way, such that there is a unique "inverse" source query for each update program. BiFluX extends Flux with bidirectional actions that describe the connection between source and target formats. We introduce a core BiFluX language, and translate it into a formally verified bidirectional update language BiGUL to guarantee a BiFluX program is well-behaved.
The steering law is a robust model for expressing the relationship between movement time and task difficulty. Recently, a corrected model to calculate the steering time difference between narrowing and widening tunnels was proposed. However, the previous work only conducted a user study with straight paths. This paper presents an investigation of steering performance in narrowing and widening circular tunnels to confirm the corrected model as being either adequate or a limitation. The results show that the steering law achieves a good fit (R2>.98) without the corrected model, thereby indicating the limited benefit of employing the corrected model.