Six (Im)possible Things before Breakfast? : Building-Blocks and Design-Principles for Wise Computing (Work-in-progress report) Assaf Marron1 , Brit Arnon1 , Achiya Elyasaf1 , Michal Gordon4 , Guy Katz2 , Hadas Lapid1 , Rami Marelly1 , Dana Sherman1 , Smadar Szekely1 , Gera Weiss3 , and David Harel1 1 Weizmann Inst., 2 Stanford U., 3 Ben Gurion U., 4 Holon Inst. Abstract. Despite many advances in automating system and software engineering, the knowledge, skills and experience of human engineers and domain experts are, and will continue to be, critical factors in the success of complex system development projects. In a new research direction we term towards wise computing we aim to make some of these abilities available to all project-team members, at any time, by adding several radically-new ca- pabilities to the development environment. For example, the development environment will be able to, on its own, notice and suggest a required ac- tion for, an unexpected, unspecified, emergent system property. A report on the ultimate wise-computing vision and an initial demonstration of the desired functions have been published separately. Clearly, advanced tools, such as formal verification and synthesis, machine learning and automatic reasoning, which were not previously available, are now maturing and will be essential to wise computing. Yet, a comprehensive feasibility plan was not shown until now, and despite the above arsenal of tools, a challenge is often presented: is it indeed possible to automate some critically relevant abilities of humans, like free association, applying general knowledge to a wide variety of specific cases, or “thinking outside the box” to find a solu- tion to a problem. In this report we outline research directions for several software capabilities and design principles that we have begun to work on, and which we believe can remove key remaining obstacles to feasibility of wise computing. 1 The Wise-Computing Challenge Rich knowledge and sophisticated skills, acquired by experienced engineers over years of training and hard-earned practical lessons, are key ingredients, and even critical success factors, in complex software and system engineering projects. In a new research vision that we term towards wise computing, we aim to endow the software development environment with those engineering abilities that are particularly considered unique to humans and make them available to the project team at all times. Some of the relevant capabilities we are most interested in are: – Free association: i.e., when an event can trigger a distantly related action – Applying engineering and domain expertise: e.g., to new and varied situations – Noticing irregularities: e.g., answering “what’s wrong with this picture?” ? With apologies to Lewis Carroll 2 Marron et al. – Creative problem solving: i.e., “thinking-outside-the-box” – Seeing a bigger picture: e.g., considering problems, causes, work methods, etc. – Adapting to new demands: e.g., new work methods due to cyber risks As a specific example, in developing an autonomous car, a wise development environment will be able to do the following spontaneously: (1) identify the mod- ules participating in a communication protocol and apply model-checking to that part of the system only, in order to verify its correctness; (2) notice, in testing or in final use, without it having been specified for the system, that the car oc- casionally slows down, slightly, but still unnecessarily, and then search for causes and solutions; and (3) use domain-specific information, such as classical mechan- ics or applicable traffic laws, in code generation, in test generation and in formal verification. A description of the full vision of wise computing, as well as an initial proof- of-concept demonstration of the capabilities that such a wise development envi- ronment will have, has been published separately [4, 5]. Related work is presented later in this section. Wise computing will rely on advanced computationally-intensive capabilities, such as formal verification using model-checking and SAT/SMT solving, program synthesis, machine learning, pattern recognition, AI planning and reasoning, pro- gram static analysis, and automatic test generation. These sophisticated tools, which were not previously available, are now maturing and will play a central role in wise computing. Yet, a comprehensive feasibility plan for wise computing was not shown until now, and despite the availability of the above arsenal of tools, a challenge is often presented: can the human skills described above, and others that are required for accomplishing the wise computing vision, really be auto- mated? Do we know enough about the human mind to even start pursuing such an ambitious goal? The purpose of this short paper is to describe elements of our present re- search, which show that in the area of software and system engineering (“SE” hereafter) this is indeed feasible, and that such human activity can be mimicked, independently of the need to understand the biology and psychology behind it. In a nutshell, we believe that to harness and integrate into a development en- vironment (“DE” hereafter) the latest analytical tools and the not-yet-formalized knowledge and skills of humans, will require the development of new structural and behavioral principles. These will involve issues in system modeling, in knowl- edge representation, and in the languages used by humans and machines to con- verse about systems. As part of our broader research plan for wise computing, this paper is dedicated to these enabling building blocks. In the following sections we briefly present several of these as particular research directions, discuss their merits and feasibility, and describe preliminary results supporting their continued pursuit. Related Work. Due to space constraints we refer the reader to [11] for a detailed discussion of related work. Automating unique human competencies has been a goal of several research projects, most prominently, the Programmers Ap- prentice and Requirements Apprentice projects at MIT (ended early 1990s) [10, 9]. There, the computer was intended to automatically generate code from re- quirements where specific text patterns (clichés) were recognized. A paper pub- lished in 2015 by the same team shows a renewed interest in these concepts, and Building-Blocks Research Directions for Wise Computing 3 demonstrates capabilities in natural language processing, domain-specific knowl- edge, and code generation [2]. Another related recent work is [8], where natural language specifications are used to synthesize and iteratively develop a reactive robot controller, while predicting and discussing desired and undesired behaviors. The main contributions of the wise computing vision and of the feasibility plan presented here are the breadth of target system applicability, range of human skills addressed, and the search for fundamental game-changing engineering concepts that would streamline this undertaking. 2 Integrative Cross-function Models Common development practices and methodologies often rely on different models and languages for requirements, specifications, actual system code, test scenar- ios, simulation results, bug reports, and system documentation. We propose to research a method for modeling all the above artifacts in a consistent way that connects all of them throughout the project life-cycle, in a single model or few closely integrated ones. Combined with extended aggregation and reflection capa- bilities, discussed in Sec. 3, this will help in application of knowledge in multiple contexts, and in “seeing the bigger picture” of the system, the domain, and the methods and tools used in development. Externally-specified connections between artifacts, heuristic searches and systematic explorations of such models will be able to exhibit behavior that may mimic the human ability for free association. To that end, we propose to research integration of statecharts [3] and scenario- based programming (abbr. SBP hereafter, a.k.a behavioral programming; see in- troduction of SBP in Sec. 5 and in [1, 6, 7]). Statecharts have been shown to be an excellent modeling and coding medium from design to final code, and SBP is par- ticularly geared to describing the inter-object scenarios common in requirements specification, testing and the like. Our goal here is a unified visual and textual modeling language (and associated semantics) that includes the capabilities of both and any additional enhancements needed for wise computing. Specifically, we plan to endow statecharts with the semantics unique to SBP, including must vs. may transitions, associating statechart states with events that should be considered for triggering and/or are forbidden in the state, and, system- wide enforcement of event order subject to all concurrent scenarios. This work has started and a draft specification of the integration is available in [11]. As an interim step we integrated a statecharts development-and-simulation tool with the PlayGo SBP tool, allowing not only exchange of events between the two systems, but also a common, integrated user-interface, and a well-defined semantics for joint execution [11]. Moreover, such a model immediately suggests a very useful approach to knowl- edge representation: describe it in scenarios that capture the application of the knowledge, similar to how the program itself is specified. This way, a particular unit of knowledge constantly tries to apply itself wherever it is relevant, perhaps in more than one way. An example of this approach is demonstrated in our prelim- inary result of a scenario-based biological model for the intra-cellular citric-acid cycle (a.k.a. Krebs cycle) [11]. Disparate chemical reactions are modeled as sepa- rate scenarios, oblivious of each other, comparable to how they might be written in a chemistry book. Yet, they all a work together, yielding a model that can 4 Marron et al. then influence other components, such as a model of a disease or a treatment thereof. Sec. 3 describes an example of scenario-based knowledge representation and aggregation, in a use-case for home-assistant robot. This kind of knowledge representation can also help in detection of emergent properties or missing elements, complementing machine learning methods, with explicit, much simpler scenarios that look for behavior patterns or checklists of elements that must be present. 3 Enhanced Aggregation and Reflection Two of the most attractive features of statecharts are their intuitive and power- ful aggregation of states, and the ability to reference states of any object from anywhere. We propose to extend these two capabilities to other system entities, such as scenarios, and to also allow a single entity to be contained in multiple containers, which themselves are first-class citizens in the model. Flexible hierarchy and reflection will help in creating contexts for scenarios, and then applying rules to entire contexts—e.g., day-time vs. night-time behaviors of a home-assistant robot, or separating the robot’s self-maintenance activities from house duties. They will also simplify the application of external knowledge: e.g., the knowledge that a baby needs a certain number of hours of sleep, can, among others things, be reflected in a scenario that forbids the robot from doing any of the actions previously tagged or identified as noisy, when the baby is asleep. External reference to scenario states will also be valuable in refinement and repair of existing behavior. Aggregation may also enable the DE to exhibit what may be perceived as cre- ative behavior, or “thinking outside the box”. As is often advised in innovation workshops, one should try to expand his or her “box”, namely, by having a list of generic solutions whose applicability should be considered. Flexible aggrega- tion enables the categorizing of certain system elements, as, e.g., “concurrency related”, or “safety-critical”, thus enabling automated examination of generic so- lutions such as a variety of locking and serialization mechanisms for the former, or added sensors-and-alerts or human supervision for the latter. We have already prepared an initial specification for adding hierarchy and ag- gregation to SBP in the context of live sequence charts (LSC) [11]. An interesting observation is that, when SBP is finally fully integrated within statecharts, as pro- posed in Sec. 2, aggregation of inter-object scenarios and the ability to externally refer to scenario states will be readily implementable. 4 An Extensible Text-based Interface In addition to any visual modeling and classical programming tools for the above, we propose to provide an extensible textual language with precise, unambiguous semantics for creating and discussing the models. A key feature of the language is that its statements are aligned with how human experts would prefer to converse, with people and with the DE, about the above systems—focusing on one fact at a time, in arbitrary order. Each of the statements can thus be viewed as a stand- alone entity, and their order or organization will not carry additional semantics. A highly relevant preliminary result is our group’s work on programming sce- narios in controlled natural language with precise semantic rules—which may Building-Blocks Research Directions for Wise Computing 5 thus be considered as a form of a domain-specific language (DSL). We have also created interfaces for displaying LSCs as English sentences. Our experience has shown that while a picture (say, of an LSC) is “worth a thousand words”, a concise statement such as “when the driver presses the brake pedal, the brake light turns on” is both useful and convenient. Such an approach, based on stand-alone state- ments, is common also in declarative programming (e.g., Prolog), in text encoding of UML models (e.g., UML/P), or in assertions to SAT/SMT solvers (e.g., CVC4 and Z3). As for a DSL for statement-based description of statecharts, extend- ing the above is straightforward, especially in the presence of existing text-based encoding of statecharts such as SCXML. Thus, since all system entities, environment knowledge and meta information can be described in statecharts and scenarios, we are confident that we now have a good basis for a natural interface for the two-way text-based interaction of a wise DE and its users. 5 Self-Integrating Behavior We introduce a design principle, termed self-integrating behavior (SIB), which we believe can dramatically accelerate the endowing of DEs with new knowledge and analytical abilities. We propose that it be adopted for specifications, actual system modeling and code, DEs, domain knowledge and other SE artifacts. SIB-designed components “take care of themselves”. They seek out their in- puts, and make their outputs available to all other components. But, most im- portantly, they are also prepared to comply with constraints specified by other components. They can thus join or leave complex processes in an incremental, self- standing way with little or no change to existing components. The latter would be more difficult in common OO designs, where existing modules have to be modified with calls of relevant methods or for discovery of configuration changes1 . One implementation we propose for SIB-design is that of scenario-based pro- gramming (SBP) [1, 6, 7], which we feel is particularly apt as a basis for it. It was first introduced with the visual language of live sequence charts (LSC), and later implemented in standard languages such as Java and C++. SBP calls for spec- ifying system behavior as inter-object scenarios, aligned with how people often describe such behavior in, say, a requirements document or a user manual. Each scenario specifies some facet of system behavior with the events that may, must, or must not occur at each point. During execution, the scenarios run concurrently: the execution environment selects the next event to be triggered, by considering the entire specification according to well-defined composition semantics, and then advances all the scenarios accordingly. The capabilities and advantages of SBP have been demonstrated in a variety of sample application areas, including au- tonomous vehicles, industrial automation, a web server, and biological modeling. As an example of SIB, consider a game-playing program where rules and play- ing strategies are each specified as a separate scenario, much as they would be when described verbally, or appear, say, in paragraphs of the printed instructions without having any program explicitly invoking all these modules in some order 1 Aspect-oriented programming (AOP) provides limited, and somewhat fragile, SIB ca- pabilities in standard programming languages, and indeed, some SBP implementations use AspectJ internally. For additional discussion of SBP and AOP see [7]. 6 Marron et al. (see, e.g., our group’s paper in EMSOFT’13 on compositionality in SBP). Another SIB example, focused on knowledge representation, is our preliminary-result mod- eling of the Krebs cycle, described in Sec. 2. We propose to further investigate SIB. E.g., see whether any additional se- mantics are required for accomplishing it, beyond the native SBP principles. One such candidate is adding a context scope to the event-blocking idiom, limiting its otherwise global and unilateral effect. Another direction is to identify any special properties SIB may have, such as its communication or module-complexity costs, its possibly-improved succinctness under certain conditions, or its allowance of accelerated formal verification using, say, assume/guarantee techniques. A most intriguing research direction would be to measure the contribution of SIB and aggregation to tackling state explosion. As mentioned above, wise-computing will incorporate, and appropriately ex- tend, a broad range of SE ideas and tools. We intend to find ways to allow existing tools and automated techniques to be embedded in the framework of SIB, in order to allow DEs to harness their power smoothly and efficiently. Finally, as in parts of the PoC in [5] we propose to integrate the DE and the system, using SBP and SIB, thus enabling a variety of intelligent ways to monitor systems and proactively guide their execution. This can be done both in development, say, in testing and simulation, and as part of the deployment and run-time environment, for, say, diagnosis and recovery from failures. 6 Conclusion Since the early days of computing, the software engineering community has been aspiring for a development environment that can automate some of the more sophisticated tasks carried out by human experts. We presented four research di- rections: a single cross-function model for all aspects of development, flexible and extensible aggregation and reflection, a text-based interface based on stand-alone statements, and building models, systems, and development environments from units of self-integrating behavior. We believe that these can form important as- pects of future system and development-environment design, and help integrate the most advanced tools and human knowledge and skills in SE and related dis- ciplines, thus beginning to suggest the feasibility of the wise-computing dream. References 1. W. Damm and D. Harel. LSCs: Breathing Life into Message Sequence Charts. J. on Formal Methods in System Design, 2001. 2. H. Davis, B. Shrobe, and R. Katz. Towards a Programmer’s Apprentice (Again). Center for Brains, Minds and Machines, 2015. CBMM Memo No. 030. 3. D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Program- ming, 8(3):231–274, 1987. 4. D. Harel, G. Katz, R. Marelly, and A. Marron. Wise Computing: Towards Endowing System Development with True Wisdom, 2015. Tech Report. http://arxiv.org/abs/1501.05924. 5. D. Harel, G. Katz, R. Marelly, and A. Marron. An Initial Wise Development Environment for Behavioral Models. In MODELSWARD, 2016. 6. D. Harel and R. Marelly. Come, Let’s Play: Scenario-Based Programming Using LSCs and the Play-Engine. Springer, 2003. 7. D. Harel, A. Marron, and G. Weiss. Behavioral Programming. Comm. of the ACM, 2012. 8. C. Lignos, V. Raman, C. Finucane, M. Marcus, and H. Kress-Gazit. Provably Correct Reactive Control from Natural Language. Autonomous Robots, 38(1):89–105, 2015. 9. H. Reubenstein and R. Waters. The Requirements Apprentice: Automated Assistance for Re- quirements Acquisition. IEEE Transactions on Software Engineering, 17(3):226–240, 1991. 10. C. Rich and R. Waters. The Programmer’s Apprentice: A Res. Overview. IEEE Computer, 1988. 11. Supplementary Material. http://www.b-prog.org/Models16PosterSupplemental.