Backward conditioning: A new program specialisation technique and its application to program comprehension

This paper introduces backward conditioning. Like forward conditioning (used in conditioned slicing), backward conditioning consists of specialising a program with respect to a condition inserted into the program. However, whereas forward conditioning deletes statements which are not executed when the initial state satisfies the condition, backward conditioning deletes statements which cannot cause execution to enter a state which satisfies the condition. The relationship between backward and forward conditioning is reminiscent of the relationship between backward and forward slicing. Forward conditioning addresses program comprehension questions of the form `what happens if the program starts in a state satisfying condition c?`, whereas backward conditioning addresses questions of the form `what parts of the program could potentially lead to the program arriving in a state satisfying condition c?' The paper illustrates the use of backward conditioning as a program comprehension assistant and presents an algorithm for constructing backward conditioned programs

An Empirical Investigation of Code Smell ‘Deception’ and Research Contextualisation through Paul’s Criteria

Code smells represent code decay and as such should be eradicated from a system to prevent future maintenance problems. A range of twenty smells described by Fowler and Beck each require varying numbers and combinations of refactorings in order to be eradicated — but exactly how many are needed when we consider related, nested refactorings is unclear. In this paper, we enumerate these refactorings when categorised according to Mantyla’s smell taxonomy. We then show how, ironically, the ‘smelliest’ of smells (and hence most difficult to eradicate) are actually those best understood by developers. So, code smells are not only unpleasant to have around, but are deceptive in their nature and make-up. The study is thus a warning against attempting to eradicate what are seemingly easily eradicated smells — these are often the smells the developer needs to be most wary of. Finally, we incorporate the answers to six questions suggested by Paul for ‘How to write a paper properly’ to position the paper in a reflective way

Package Evolvability and its Relationship with Refactoring

In this paper, we address a set of research questions investigating trends in changes to an open-source system (OSS). An interesting âpeak and troughâ effect trend was found to exist in the system studied, suggesting that developer activity comprises of a set of high and low periods. Trends in overall changes applied to the system were complemented with empirical evidence in refactoring data for the same system; this showed a similar peak and trough effect but at different versions of the same system. This result suggests a contrasting motivation between regular maintenance practice and that of refactoring. Our analysis of high-level package trends informed some interesting cross-comparisons with refactoring practice, and some insights into why refactoring might be applied after a burst of regular change activity, rather than consistently. We use data extracted from seven Java OSS as a basis for our refactoring analysis

Evolutionary testing supported by slicing and transformation

Evolutionary testing is a search based approach to the automated generation of systematic test data, in which the search is guided by the test data adequacy criterion. Two problems for evolutionary testing are the large size of the search space and structural impediments in the implementation of the program which inhibit the formulation of a suitable fitness function to guide the search. In this paper we claim that slicing can be used to narrow the search space and transformation can be applied to the problem of structural impediments. The paper presents examples of how these two techniques have been successfully employed to make evolutionary testing both more efficient and more effective

Message from A-MOST 2020 Chairs

yesWelcome to the 16th edition of the Advances in Model-Based Testing Workshop (A-MOST 2020) held on March 23rd, 2020 in Porto as part of ICST 2020, the IEEE International Conference on Software Testing, Verification and Validation

A post-placement side-effect removal algorithm

Side-effects are widely believed to impede program comprehension and have a detrimental effect upon software maintenance. This paper introduces an algorithm for side-effect removal which splits the side-effects into their pure expression meaning and their state-changing meaning. Symbolic execution is used to determine the expression meaning, while transformation is used to place the state-changing part in a suitable location in a transformed version of the program. This creates a program which is semantically equivalent to the original but guaranteed to be free from side-effects. The paper also reports the results of an empirical study which demonstrates that the application of the algorithm causes a significant improvement in program comprehension

Effect of angiotensin-converting enzyme inhibitor and angiotensin receptor blocker initiation on organ support-free days in patients hospitalized with COVID-19

IMPORTANCE Overactivation of the renin-angiotensin system (RAS) may contribute to poor clinical outcomes in patients with COVID-19. Objective To determine whether angiotensin-converting enzyme (ACE) inhibitor or angiotensin receptor blocker (ARB) initiation improves outcomes in patients hospitalized for COVID-19. DESIGN, SETTING, AND PARTICIPANTS In an ongoing, adaptive platform randomized clinical trial, 721 critically ill and 58 non–critically ill hospitalized adults were randomized to receive an RAS inhibitor or control between March 16, 2021, and February 25, 2022, at 69 sites in 7 countries (final follow-up on June 1, 2022). INTERVENTIONS Patients were randomized to receive open-label initiation of an ACE inhibitor (n = 257), ARB (n = 248), ARB in combination with DMX-200 (a chemokine receptor-2 inhibitor; n = 10), or no RAS inhibitor (control; n = 264) for up to 10 days. MAIN OUTCOMES AND MEASURES The primary outcome was organ support–free days, a composite of hospital survival and days alive without cardiovascular or respiratory organ support through 21 days. The primary analysis was a bayesian cumulative logistic model. Odds ratios (ORs) greater than 1 represent improved outcomes. RESULTS On February 25, 2022, enrollment was discontinued due to safety concerns. Among 679 critically ill patients with available primary outcome data, the median age was 56 years and 239 participants (35.2%) were women. Median (IQR) organ support–free days among critically ill patients was 10 (–1 to 16) in the ACE inhibitor group (n = 231), 8 (–1 to 17) in the ARB group (n = 217), and 12 (0 to 17) in the control group (n = 231) (median adjusted odds ratios of 0.77 [95% bayesian credible interval, 0.58-1.06] for improvement for ACE inhibitor and 0.76 [95% credible interval, 0.56-1.05] for ARB compared with control). The posterior probabilities that ACE inhibitors and ARBs worsened organ support–free days compared with control were 94.9% and 95.4%, respectively. Hospital survival occurred in 166 of 231 critically ill participants (71.9%) in the ACE inhibitor group, 152 of 217 (70.0%) in the ARB group, and 182 of 231 (78.8%) in the control group (posterior probabilities that ACE inhibitor and ARB worsened hospital survival compared with control were 95.3% and 98.1%, respectively). CONCLUSIONS AND RELEVANCE In this trial, among critically ill adults with COVID-19, initiation of an ACE inhibitor or ARB did not improve, and likely worsened, clinical outcomes. TRIAL REGISTRATION ClinicalTrials.gov Identifier: NCT0273570