There is no consensus definition of acute renal failure (ARF) in critically ill patients. More than 30 different definitions have been used in the literature, creating much confusion and making comparisons difficult. Similarly, strong debate exists on the validity and clinical relevance of animal models of ARF; on choices of fluid management and of end-points for trials of new interventions in this field; and on how information technology can be used to assist this process. Accordingly, we sought to review the available evidence, make recommendations and delineate key questions for future studies. We undertook a systematic review of the literature using Medline and PubMed searches. We determined a list of key questions and convened a 2-day consensus conference to develop summary statements via a series of alternating breakout and plenary sessions. In these sessions, we identified supporting evidence and generated recommendations and/or directions for future research. We found sufficient consensus on 47 questions to allow the development of recommendations. Importantly, we were able to develop a consensus definition for ARF. In some cases it was also possible to issue useful consensus recommendations for future investigations. We present a summary of the findings. (Full versions of the six workgroups' findings are available on the internet at http://www.ADQI.net
 ) Despite limited data, broad areas of consensus exist for the physiological and clinical principles needed to guide the development of consensus recommendations for defining ARF, selection of animal models, methods of monitoring fluid therapy, choice of physiological and clinical end-points for trials, and the possible role of information technology.

/pdf/acute-renal-failure-definition-outcome-measures-animal-3m4l0j5jsf.pdf

Acute renal failure - definition, outcome measures, animal models, fluid therapy and information technology needs: the Second International Consensus Conference of the Acute Dialysis Quality Initiative (ADQI) Group.

Social Network Analysis

To support bursty traffic on the Internet (and especially WWW) efficiently, optical burst switching (OBS) is proposed as a way to streamline both protocols and hardware in building the future generation Optical Internet. By leveraging the attractive properties of optical communications and at the same time, taking into account its limitations, OBS combines the best of optical circuit-switching and packet/cell switching. In this paper, the general concept of OBS protocols and in particular, those based on Just-Enough-Time (JET), is described, along with the applicability of OBS protocols to IP over WDM. Specific issues such as the use of fiber delay-lines (FDLs) for accommodating processing delay and/or resolving conflicts are also discussed. In addition, the performance of JET-based OBS protocols which use an offset time along with delayed reservation to achieve efficient utilization of both bandwidth and FDLs as well as to support priority-based routing is evaluated.

Optical burst switching (OBS) - a new paradigm for an optical Internet

ing WS1S Systems to Verify Parameterized Networks . . . . . . . . . . . . 188 Kai Baukus, Saddek Bensalem, Yassine Lakhnech and Karsten Stahl FMona: A Tool for Expressing Validation Techniques over Infinite State Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 J.-P. Bodeveix and M. Filali Transitive Closures of Regular Relations for Verifying Infinite-State Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Bengt Jonsson and Marcus Nilsson Diagnostic and Test Generation Using Static Analysis to Improve Automatic Test Generation . . . . . . . . . . . . . 235 Marius Bozga, Jean-Claude Fernandez and Lucian Ghirvu Efficient Diagnostic Generation for Boolean Equation Systems . . . . . . . . . . . . 251 Radu Mateescu Efficient Model-Checking Compositional State Space Generation with Partial Order Reductions for Asynchronous Communicating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Jean-Pierre Krimm and Laurent Mounier Checking for CFFD-Preorder with Tester Processes . . . . . . . . . . . . . . . . . . . . . . . 283 Juhana Helovuo and Antti Valmari Fair Bisimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Thomas A. Henzinger and Sriram K. Rajamani Integrating Low Level Symmetries into Reachability Analysis . . . . . . . . . . . . . 315 Karsten Schmidt Model-Checking Tools Model Checking Support for the ASM High-Level Language . . . . . . . . . . . . . . 331 Giuseppe Del Castillo and Kirsten Winter Table of

Tools and Algorithms for the Construction and Analysis of Systems. Proc. TACAS 2009

A program slice consists of the parts of a program that (potentially) affect the values computed at some point of interest Such a point of interest is referred to as a slicing criterion, and is typically specified by a location in the program in combination with a subset of the program’s variables The task of computing program slices is called program slicing The original definition of a program slice was presented by Weiser in 1979 Since then, various slightly different notions of program slices have been proposed, as well as a number of methods to compute them An important distinction is that between a static and a dynamic slice Static slices are computed without making assumptions regarding a program’s input, whereas the computation of dynamic slices relies on a specific test case This survey presents an overview of program slicing, including the various general approaches used to compute slices, as well as the specific techniques used to address a variety of language features such as procedures, unstructured control flow, composite data types and pointers, and concurrency Static and dynamic slicing methods for each of these features are compared and classified in terms of their accuracy and efficiency Moreover, the possibilities for combining solutions for different features are investigated Recent work on the use of compiler-optimization and symbolic execution techniques for obtaining more accurate slices is discussed The paper concludes with an overview of the applications of program slicing, which include debugging, program integration, dataflow testing, and software maintenance

/pdf/a-survey-of-program-slicing-techniques-1u546ok1jr.pdf

A Survey of Program Slicing Techniques.

This paper presents a technique to select a representative set of test cases from a test suite that provides the same coverage as the entire test suite. This selection is performed by identifying, and then eliminating, the redundant and obsolete test cases in the test suite. The representative set replaces the original test suite and thus, potentially produces a smaller test suite. The representative set can also be used to identify those test cases that should be rerun to test the program after it has been changed. Our technique is independent of the testing methodology and only requires an association between a testing requirement and the test cases that satisfy the requirement. We illustrate the technique using the data flow testing methodology. The reduction that is possible with our technique is illustrated by experimental results.

A methodology for controlling the size of a test suite

As a result of modifications to a program during the maintenance phase, the size of a test suite used for regression testing can become unmanageable. The authors present a technique that selects from a test suite a representative set of test cases that provides the same measure of coverage as the test suite. This selection is performed by the identification of the redundant and obsolete test cases in the test suite. The representative set can be used to reduce the size of the test suite by substituting for the test suite. The representative set can also be used to determine those test cases that should be rerun to test the program after it has been changed. The technique is independent of the testing methodology and only requires an association between each testing requirement and the test cases that satisfy the requirement. The technique is illustrated by means of the data flow testing methodology. Experimental studies are being performed that demonstrate the effectiveness of the technique. >

/pdf/a-methodology-for-controlling-the-size-of-a-test-suite-4o0eq8rull.pdf

Typically debugging begins when during a program execution a point is reached at which an obviously incorrect value is observed. A general and powerful approach to automated debugging can be based upon identifying modifications to the program state that will bring the execution to a successful conclusion. However, searching for arbitrary changes to the program state is difficult due to the extremely large search space. In this paper we demonstrate that by forcibly switching a predicate's outcome at runtime and altering the control flow, the program state can not only be inexpensively modified, but in addition it is often possible to bring the program execution to a successful completion (i.e., program produces the desired output). By examining the switched predicate, also called the critical predicate, the cause of the bug can then be identified. Since the outcome of a branch can only be either true or false, the number of modified states resulting by predicate switching is far less than those possible through arbitrary state changes. Thus, it is possible to automatically search through modified states to find one that leads to the correct output. We have developed an implementation based upon dynamic instrumentation to perform this search through program re-execution -- the program is executed from the beginning and a predicate's outcome is switched to produce the desired change in control flow. To evaluate our approach, we tried our technique on several reported bugs for a number of UNIX utility programs. Our technique was found to be practical (i.e., acceptable in time taken) and effective (i.e., we were able to automatically identify critical predicates). Moreover we show that bidirectional dynamic slices of critical predicates capture the faulty code.

/pdf/locating-faults-through-automated-predicate-switching-e69mj7wfhp.pdf

Locating faults through automated predicate switching

The authors present a novel approach to data-flow-based regression testing that uses slicing type algorithms to explicitly detect definition-use pairs that are affected by a program change. An important benefit of the slicing technique is that, unlike previous techniques, no data flow history is needed nor is the recomputation of data flow for the entire program required to detect affected definition-use pairs. The program changes drive the recomputation of the required partial data flow through slicing. Another advantage is that the proposed technique achieves the same testing coverage as a complete retest of the program without the need for maintaining and updating a test suite. >

/pdf/an-approach-to-regression-testing-using-slicing-574ivjcxio.pdf

An approach to regression testing using slicing

To guarantee typesafe execution, Java and other strongly typed languages require bounds checking of array accesses. Because array-bounds checks may raise exceptions, they block code motion of instructions with side effects, thus preventing many useful code optimizations, such as partial redundancy elimination or instruction scheduling of memory operations. Furthermore, because it is not expressible at bytecode level, the elimination of bounds checks can only be performed at run time, after the bytecode program is loaded. Using existing powerful bounds-check optimizers at run time is not feasible, however, because they are too heavyweight for the dynamic compilation setting.ABCD is a light-weight algorithm for elimination of Array Bounds Checks on Demand. Its design emphasizes simplicity and efficiency. In essence, ABCD works by adding a few edges to the SSA value graph and performing a simple traversal of the graph. Despite its simplicity, ABCD is surprisingly powerful. On our benchmarks, ABCD removes on average 45% of dynamic bound check instructions, sometimes achieving near-ideal optimization. The efficiency of ABCD stems from two factors. First, ABCD works on a sparse representation. As a result, it requires on average fewer than 10 simple analysis steps per bounds check. Second, ABCD is demand-driven. It can be applied to a set of frequently executed (hot) bounds checks, which makes it suitable for the dynamic-compilation setting, in which compile-time cost is constrained but hot statements are known.

/pdf/abcd-eliminating-array-bounds-checks-on-demand-mds58njh39.pdf

Rajiv Gupta

Papers

A methodology for controlling the size of a test suite

A methodology for controlling the size of a test suite

Locating faults through automated predicate switching

An approach to regression testing using slicing

ABCD: eliminating array bounds checks on demand