Article Preview
Top1. Introduction
The development of large reactive software systems is an expensive and error-prone undertaking. Deliverables will often fail, resulting in unintended software behavior, exceeded budgets and breached time schedules. One of the key reasons for this difficulty is the growing complexity of many kinds of reactive systems, which increasingly prevents the human mind from managing a comprehensive picture of all their relevant elements and behaviors. Moreover, of course, the state-explosion problem typically prevents us from exhaustively analyzing all possible software behaviors. While major advances in modeling tools and methodologies have greatly improved our ability to develop reactive systems by allowing us to reason on abstract models thereof, specific solutions are quickly reaching their limits, and resolving the great difficulties in developing reliable reactive systems remains a major, and critical, moving target.
Over the years it has been proposed, in various contexts, e.g., (Cerf, 2014; Harel, Katz, Marelly, & Marron, 2015; Reubenstein & Waters, 1991; Rich & Waters, 1988), that a possible strategy for mitigating these difficulties could lay in changing the role of the computer in the development process. Instead of having the computer serve as a tool, used only to analyze or check specific aspects of the code as instructed by the developer, one could seek to actually transform it into a member of the development team — a proactive participant, analyzing the entire system and making informed observations and suggestions. This way, the idea goes, the computer’s superior capabilities of handling large amounts of code could be manifested. Combined with human insight and understanding of the system’s goals, this synergy could produce more reliable and error-free systems.
In this paper we follow this spirit, and present a methodology and an interactive framework for the modeling and development of complex reactive systems, in which the computer plays a proactive role. Following the terminology of (Harel, Katz, Marelly, & Marron, 2015), and constituting a very modest initial effort along the lines of the Wise Computing vision outlined there, we term this framework a wise framework. Intuitively, a truly wise framework should provide the developer with an interactive companion for all phases of system development, “understand” the system, draw attention to potential errors and suggest improvements and generalizations; and this should be done via two-way communication with the developer, which will be very high-level, using natural (perhaps natural-language-based) interfaces. The framework presented here is but a first step in that direction, and focuses solely on providing an interactive development assistant capable of discovering interesting properties and drawing attention to potential bugs; still, it can already handle non-trivial programs, as we later demonstrate through a case-study.
Various parts of this approach have been implemented by a variety of researchers in other forms, as described in the Related Work section. A main novel aspect of our approach, however, is in the coupling of the notion of a proactive and interactive framework with a modeling language called behavioral programming (Harel, Marron, & Weiss, 2012) — a scenario-based language, in which systems are modeled as sets of independent scenarios that are interleaved at runtime. This formalism makes it possible for our interactive development framework to repeatedly and quickly construct abstract executable models of the program, and then analyze them in order to reach meaningful conclusions. It is now widely accepted that a key aspect in the viability of analysis tools and environments is that they are sufficiently lightweight to be integrated into the developer’s workflow without significantly slowing it down (Cristiano et al., 2015; Sadowski, Gogh, Jaspan, Söederberg, & Winter, 2015). We attempt to achieve this by leveraging scenario-based modeling. As demonstrated in later sections, the proactiveness of our approach and its tight integration into the development cycle can lead to early detection of bugs during development, when they are still relatively easy and cheap to fix.