Computing change of invariants to support software evolution

Software is always evolving. In the recent years, the development community has shifted towards Agile development paradigm resulting in faster release cycle. This emphasis on speed is, generally, accompanied by an increase in the number of bugs and reduced focus on updating non-functional software artifacts like specification document. Recent studies have found that developers find it difficult to determine whether a change might break code elsewhere in the program, resulting in 25% of bugs fixes to be incorrect or buggy. A method to capture the semantic changes between different versions of a program is vital in understanding the impact of the change and in preventing bugs. An invariant is a condition that is always true at a given program point. Invariants are used to specify the requirements and desired behavior of a program at any program point. The difference in invariants between different program versions can be used to capture the changes made to the program. In this thesis, we use the change of invariants as a way to capture the semantic changes over different program versions. We designed a static demand-driven algorithm for automatically computing the change of invariants between different versions of a program. To evaluate the algorithm and its ability to capture semantic changes over different program versions, we built a prototype framework called Hydrogen. Our experimental results show that Hydrogen is able to compute the change of invariants between different versions of the programs, and the computed change of invariants can be used for understanding changes and generating assertions to prevent similar bugs in future

Formal Specification and Verification for Automated Production Systems

Complex industrial control software often drives safety- and mission-critical systems, like automated production plants or control units embedded into devices in automotive systems. Such controllers have in common that they are reactive systems, i.e., that they periodically read sensor stimuli and cyclically execute the same program to produce actuator signals. The correctness of software for automated production is rarely verified using formal techniques. Although, due to the Industrial Revolution 4.0 (IR4.0), the impact and importance of software have become an important role in industrial automation. What is used instead in industrial practice today is testing and simulation, where individual test cases are used to validate an automated production system. Three reasons why formal methods are not popular are: (a) It is difficult to adequately formulate the desired temporal properties. (b) There is a lack of specification languages for reactive systems that are both sufficiently expressive and comprehensible for practitioners. (c) Due to the lack of an environment model the obtained results are imprecise. Nonetheless, formal methods for automated production systems are well studied academically---mainly on the verification of safety properties via model checking. In this doctoral thesis we present the concept of (1) generalized test tables (GTTs), a new specification language for functional properties, and their extension (2) relational test tables (RTTs) for relational properties. The concept includes the syntactical notion, designed for the intuition of engineers, and the semantics, which are based on game theory. We use RTTs for a novel confidential property on reactive systems, the provably forgetting of information. Moreover, for regression verification, an important relational property, we are able to achieve performance improvements by (3) creating a decomposing rule which splits large proofs into small sub-task. We implemented the verification procedures and evaluated them against realistic case studies, e.g., the Pick-and-Place-Unit from the Technical University of Munich. The presented contribution follows the idea of lowering the obstacle of verifying the dependability of reactive systems in general, and automated production systems in particular for the engineer either by introducing a new specification language (GTTs), by exploiting existing programs for the specification (RTTs, regression verification), or by improving the verification performance

Oracle-based Differential Operational Semantics (long version)

Program dierences are pervasive in software development and understanding them is crucial. However, such changes are usually represented as textual dierences with no regard to the syntactic nature of programs or their semantics. Such a representation may be hard to read or reason about and often fails to convey insight on the semantic implications of a change. In this paper, we propose a formal framework to characterize the dierence of behavior between two close programs equivalent or notin terms of their small-step semantics. To this end, we introduce small-step-prediction oracles that consume one reduction step of one program and produce a sequence of reduction steps of the other. Such oracles are operational, handle diverging or stuck computations, and are well-suited for describing local changes, while expressive enough to describe arbitrary ones. They can also be composed, to characterize a dierence as a sequence of simpler dierences. Last but not least, small-prediction-step oracles can be explained to programmers in terms of evaluation of the compared programs. We illustrate this framework by instantiating it on the Imp imperative language, with oracles ranging from trivial equivalence-preserving syntactic transformations to characterized semantic dierences. Through these examples, we show how our framework can be used to relate syntactic changes with their eect on the semantics, or to describe higher-level changes by abstracting away from the small-step semantics presentation. We have dened and proved the framework and the presented examples in the Coq proof assistant, and implemented a proof-of-concept inference tool for the Imp language

Semantic Analyses to Detect and Localize Software Regression Errors

Ph.DDOCTOR OF PHILOSOPH

Organization Global Software Development Challenges of Software Product Quality

Leaders of global software development (GSD) processes in organizations have been confronting low software product quality. Managers of these processes have faced challenges that have been affecting customer satisfaction and that have resulted in negative social impacts on public safety, business financial performance, and global economic stability. The purpose of this qualitative exploratory multiple case study was to discover a common understanding shared by managers in Canadian GSD organizations of how to meet software product quality goals and enhance customer satisfaction. The conceptual framework for the study was based on Deming\u27s 14 principles of quality management. The purposeful sample included 30 knowledgeable participants who worked in Canada as GSD managers. Semistructured interviews conducted through telephone and audioconference tools, along with the review of related documents, were used to gather data. Eight themes emerged from the data analysis: developing a clear purpose and work principles, improving processes and employee skills, developing adequate personnel management strategies, promoting autonomy and personal worker development, formulating life cycle and development techniques, identifying challenges, formulating solutions, and focusing on product quality. The research findings have implications for positively influencing social change through the provision of methods and process knowledge to GSD organizational leaders. This information consists of best management and industry practices that can be applied to achieve software product quality and customer satisfaction, create management systems, maintain a competitive advantage, and prevent global software development project failures

Software Change Contracts

Software errors often originate from incorrect changes, including incorrect program fixes, incorrect feature updates, and so on. Capturing the intended program behavior explicitly via contracts is thus an attractive proposition. In our recent work, we had espoused the notion of "change contracts" to express the intended program behavior changes across program versions. Change contracts differ from program contracts in that they do not require the programmer to describe the intended behavior of those program features which are unchanged across program versions. In this work, we present the formal semantics of our change contract language built on top of the Java modeling language (JML). Our change contract language can describe behavioral as well as structural changes. We evaluate the expressivity of the change contract language via a survey given to final-year undergraduate students. The survey results enable to understand the usability of our change contract language for purposes of writing contracts, comprehending written contracts, and modifying programs according to given change contracts. Finally, we develop both dynamic and static checkers for change contracts, and show how they can be used in maintaining software changes. We use our dynamic checker to automatically suggest tests that manifest violations of change contracts. Meanwhile, we use our static checker to verify that a program is changed as specified in its change contract. Apart from verification, our static checker also performs various other software engineering tasks, such as localizing the buggy method, detecting/debugging regression errors, and classifying the cause for a test failure as either error in production code or error in test code

Software change contracts

10.1145/2393596.2393622Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering, FSE 201

Expressing and checking intended changes via software change contracts

Software errors often originate from incorrect changes, including incorrect program fixes, incorrect feature updates and so on. Capturing the intended program behavior explicitly via contracts is thus an attractive proposition. In our recent work, we had espoused the notion of change contracts to express the intended program behavior changes across program versions. Change contracts differ from program contracts in that they do not require the programmer to describe the intended behavior of program features which are unchanged across program versions. In this work, we present the formal semantics of our change contract language built on top of the Java Modeling Language (JML). Our change contract language can describe behavioral as well as structural changes. We evaluate the expressivity of the change contract language via a survey given to final year undergraduate students. The survey results enable us to understand the usability of our change contract language for purposes of writing contracts, comprehending written contracts, and modifying programs according to given change contracts. Finally, we discuss the tool support developed for our change contract language. The tool support enables (i) test generation to witness contract violation, as well as (ii) automated repair of certain tests which are broken due to program changes. ?? 2013 ACM