This paper presents Korat, a novel framework for automated testing of Java programs. Given a formal specification for a method, Korat uses the method precondition to automatically generate all nonisomorphic test cases bounded by a given size. Korat then executes the method on each of these test cases, and uses the method postcondition as a test oracle to check the correctness of each output. To generate test cases for a method, Korat constructs a Java predicate (i.e., a method that returns a boolean) from the method’s precondition. The heart of Korat is a technique for automatic test case generation: given a predicate and a bound on the size of its inputs, Korat generates all nonisomorphic inputs for which the predicate returns true. Korat exhaustively explores the input space of the predicate but does so efficiently by monitoring the predicate’s executions and pruning large portions of the search space. This paper illustrates the use of Korat for testing several data structures, including some from the Java Collections Framework. The experimental results show that it is feasible to generate test cases from Java predicates, even when the search space for inputs is very large. This paper also compares Korat with a testing framework based on declarative specifications. Contrary to our initial expectation, the experiments show that Korat generates test cases much faster than the declarative framework.

TestEra is a framework for automated specification-based testing of Java programs. TestEra requires as input a Java method (in sourcecode or bytecode) , a formal specification of the pre- and post-conditions of that method, and a bound that limits the size of the test cases to be generated. Using the method's pre-condition, TestEra automatically generates all nonisomorphic test inputs up to the given bound. It executes the method on each test input, and uses the method postcondition as an oracle to check the correctness of each output. Specifications are first-order logic formulae. As an enabling technology, TestEra uses the Alloy toolset, which provides an automatic SAT-based tool for analyzing first-order logic formulae. We have used TestEra to check several Java programs including an architecture for dynamic networks, the Alloy-alpha analyzer, a fault-tree analyzer, and methods from the Java Collection Framework.

Abstract. A large genomics project involves a significant number of researchers and technicians performing dozens of tasks, either manual (e.g. performing laboratory experiments), computer assisted (e.g. looking for genes in the GENBANK database), or sometimes performed entirely automatically by the computer (e.g. sequence assembly). It has become apparent that managing such projects poses overwhelming problems and may lead to Disk results of lower or even unacceptable quality, or possibly drastically increased project costs. In this paper, we present Followed a design and an initial implementation of a distributed workflow system created to schedule and support activities in a genomics laboratory. The focus of the activities in the laboratory is the discovery of protein-protein interactions of fungi, specifically Neurospora crassa. We present our approach of developing, adapting and applying workflow technology in the genomics lab and illustrate it using one distinct part of a larger workflow to discover proteinprotein interactions. Novel features of our system include the ability to monitor the quality and timeliness of the results and if necessary, suggesting and incorporating changes to the selected tasks and their scheduling.

A software architecture is the key artifact in software design, describing the main elements of a software system and their interrelationships. We present a method for automatically analyzing the quality of an architecture by searching for architectural and design patterns from it. In addition to approximating the quality of the design, the extracted patterns can also be used for predicting the quality of the actual system. The method is demonstrated by an industrial case over

Developers often lack the time or knowledge to profoundly understand the performance issues in largescale component-oriented enterprise applications. This situation is further complicated by the fact that such applications are often built using a mix of in-house and Commercial-Off-The-Shelf (COTS) components. This paper presents a methodology for understanding and predicting the performance of component-oriented distributed systems both during development and after they have been built. The methodology is based on three conceptually separate parts: monitoring, modelling and performance prediction. Performance predictions are based on UML models created dynamically by monitoring-and-analysing a live or under-development system. The system is monitored using non-intrusive methods and run-time data is collected. In addition, static data is obtained by analysing the deployment configuration of the target application. UML models enhanced with performance indicators are created based on both static and dynamic data, showing performance hot spots. To facilitate the understanding of the system, the generated models are traversable both horizontally at the same abstraction level between transactions, and vertically between different layers of abstraction using the concepts defined by the Model Driven Architecture. The system performance is predicted and performance-related issues are identified in different scenarios by generating workloads and simulating the performance models. Work is under way to implement a framework for the presented methodology with the current focus on the Enterprise Java Beans technology. 1.

Knowing which associations are compositions is important in a tool for the reverse engineering of UML class diagrams. Firstly, recovery of composition relationships bridges the gap between design and code. Secondly, since composition relationships explicitly state a requirement that certain representations cannot be exposed, it is important to determine if this requirement is met by component code. Verifying that compositions are implemented properly may prevent serious program flaws due to representation exposure.

Modeling languages, like programming languages, need to be designed if they are to be practical, usable, accepted, and of lasting value. We present principles for the design of modeling languages. To arrive at these principles, we consider the intended use of modeling languages. We conject that the principles are applicable to the development of new modeling languages, and for improving the design of existing modeling languages that have evolved, perhaps through a process of unification. The principles are illustrated and explained by several examples, drawing on object-oriented and mathematical modeling languages. 1 Introduction The key difficulty in producing quality software is specifying and designing the conceptual construct that underlies the software [2]. This conceptual construct is usually complex. Complexity is an essential difficulty that cannot be dealt with by using more powerful programming languages or tools, or by using modeling languages that abstract it away. Comple...

Minimally Adequate Synthesizer (MAS) is an interactive algorithm that synthesizes UML statechart diagrams from sequence diagrams. It follows Angluin's framework of minimally adequate teacher to infer the desired statechart diagram by consulting the user. To minimize the consultations needed, MAS keeps track of the interaction with the user. Together with its general knowledge about sequence diagrams, this allows MAS to operate without user's help in most of the cases. A synthesized statechart diagram is a generalization, which accepts additional behavior to that described in the sequence diagrams given as input. During the synthesis process MAS asks the user if certain generalizations are allowed or not. We sketch the usage of two different kinds of inaccurate answers the user can provide. We allow Probably yes and Probably no answers, i.e. weak Yes and No answers. The information obtained from these answers is considered less significant than that obtained from normal, definite answers. The user can also postpone answering by saying later. 1.

Configurable Computing Machines (CCMs) have emerged as a technology with the computational benefits of custom ASICs as well as the flexibility and reconfigurability of general-purpose microprocessors. Significant effort from the research community has focused on techniques to move this reconfigurability from a rapid application development tool to a run-time tool. This requires the ability to change the hardware design while the application is executing and is known as Run-Time Reconfiguration (RTR). Widespread acceptance of run-time reconfigurable custom computing depends upon the existence of high-level automated design tools. Such tools must reduce the designers effort to port applications between different platforms as the architecture, hardware, and software evolves. A Java implementation of a high-level application framework, called Janus, is presented here. In this environment, developers create Java classes that describe the structural behavior of an application. The framework allows hardware and software modules to be freely mixed and interchanged. A compilation phase of the development process analyzes the structure of the application and adapts it to the target platform. Janus is capable of structuring the run-time behavior of an application to take advantage of the memory and computational resources available.

Abstract. Writing specifications using Java Modeling Language has been accepted for a long time as a practical approach to increasing the correctness and quality of Java programs. However, the current JML testing system (the JML and JUnit framework) can only generate skeletons of test fixture and test case class. Writing codes for generating test cases, especially those with a complicated data structure is still a labor-intensive job in the test for programs annotated with JML specifications. This paper presents JMLAutoTest, a novel framework for automated testing of Java programs annotated with JML specifications. Firstly, given a method, three test classes (a skeleton of test client class, a JUnit test class and a test case class) can be generated. Secondly, JMLAutoTest can generate all nonisomorphic test cases that satisfy the requirements defined in the test client class. Thirdly, JMLAutoTest can avoid most meaningless cases by running the test in a double-phase way which saves much time of exploring meaningless cases in the test. This method can be adopted in the testing not only for Java programs, but also for programs written with other languages. Finally, JMLAutoTest executes the method and uses JML runtime assertion checker to decide whether its post-condition is violated. That is whether the method works correctly. 1