We present the Argos graphical synchronous language for the description of reactive systems, and the Argonaute environment associated with it. Systems like communication protocols, real time process controllers or man/machine interfaces contain a reactive kernel. Its behaviour can be described in a convenient manner by an automaton , for formal validation purposes. But, in general, complex systems cannot be described directly as automata. The Statecharts [4,5] and Argos [7,8] are automata-based languages. The high level constructs of the language deal with states and transitions directly. A consequence of this choice is the graphical syntax, since the best representation of small automata is graphical. A consequence of this graphical syntax is the need for graphical constructs: the constructs of the language must allow the decomposition of a system into small parts that can be represented directly by automata, and they must be given a readable graphical syntax. 1 Introduction The term ...

The science of computation has systematically abstracted away the physical world. Embedded software systems, however, engage the physical world. Time, concurrency, liveness, robustness, continuums, reactivity, and resource management must be remarried to computation. Prevailing abstractions of computational systems leave out these "non-functional" aspects. This chapter explains why embedded software is not just software on small computers, and why it therefore needs fundamentally new views of computation. It suggests component architectures based on a principle called "actor-oriented design," where actors interact according to a model of computation, and describes some models of computation that are suitable for embedded software. It then suggests that actors can define interfaces that declare dynamic aspects that are essential to embedded software, such as temporal properties. These interfaces can be structured in a "system-level type system" that supports the sort of design-time and run-time type checking that conventional software benefits from.

Reactive animation combines state-of-the-art reactivity and state-of-the-art animation by linking advanced tools in the two areas. Architects of complex reactive systems and front-end designers then have a bridge between a system’s appearance and what it does. Complex systems come in many varieties. Some are transformational, of an inputprocess-output type, repeatedly carrying out their prescribed work for each new set of inputs. The complexity of these systems stems from their computations and from data flow, and is in the range of what existing tools can manage. A far more problematic class of complex systems comprises large systems that are heavily control- or event-driven. Such systems—dubbed reactive 1,2 because their role is to react to various kinds of

Argos belongs to the family of synchronous languages, designed for programming reactive systems: (Lustre

Abstract—This paper addresses the problem of automatically distributing reactive systems. We first show that the use of synchronous languages allows a natural parallel description of such systems, regardless of any distribution problems. Then, a desired distribution can be easily specified, and achieved with the algorithm presented here. This distribution technique provides distributed programs with the same safety, test, and debug facilities as ordinary sequential programs. Finally, the implementation of such distributed programs only requires a very simple communication protocol (“first in first out ” queues), thereby reducing the need for large distributed real-time executives. Index Terms—Asynchronous communications, distributed processing, reactive systems, automatic distribution, synchronous languages. ————————— — F ——————————

The Argonaute system is specifically designed to describe, specify and verify reactive systems such as communication protocols, real-time applications, man-machine interfaces, . . . It is based upon the Argos graphical language, whose syntax relies on the Higraphs formalism by D. Harel [HAR88], and whose semantics is given by using a process algebra. Automata form the basic notion of the language, and hierarchical or parallel decompositions are given by using operators of the algebra. The complete formalization of the language inherits notions from both classical process algebras such as ccs [MIL80], and existing programming languages used in the same field such as Esterel [BG88] or the Statecharts formalism [HAR87]. Concerning complex system description, Argos allows to describe intrinsic states directly --- with the basic automaton notion --- and only them: connections between components need no extra-state. The Argonaute system allows to describe reactive systems graphically, to spe...

ions that can be used include the event-based model of Java Beans, semaphores based on Dijkstra's P/V systems [21], guarded communication [40], rendezvous, synchronous message passing, active messages [84], asynchronous message passing, streams (as in Kahn process networks [45]), dataflow (commonly used in signal and image processing), synchronous/reactive systems [10], Linda [18], and many others. These abstractions partially or completely define a model of computation, the modular organizational and operational principles of a system. Applications are built on a model of computation, whether the designer is aware of this or not. Each possibility has strengths and weaknesses. Some guarantee determinacy, some can execute in bounded memory, and some are provably free from deadlock. Different styles of concurrency are often dictated by the application, and the 6 choice of model of computation can subtly affect the choice of algorithms. While dataflow is a good match for signal processi...

The author describes his dream about freeing ourselves from the straightjackets of programming, making the process of getting computers to do what we want intuitive, natural, and also fun. He recommends harnessing the great power of computing and transforming a natural and almost playful means of programming so that it becomes fully operational and machine-doable. Nine years ago, I sat down to write about a dream, one that would allow us to go from intuitively “played-in ” scenarios to running code. Some of its most technically challenging parts were stated without providing too much support for their feasibility. Hence the choice of the term “dream. ” Ever since that paper was first published in 2000, 1 not only hasn’t the dream evaporated, but it has continued to have a nagging presence, looming even larger in my mind, and getting broader and more elaborate by the year. More significant is the fact that quite a bit of work has been carried out since then, which, while still a far cry from justifying the replacement of a dream by a plan, does now seem to offer some preliminary evidence of feasibility. Consequently, I’ve decided to revisit the topic and to describe the dream anew, or, more correctly (but possibly not very wisely), to propose a more dramatic and sweeping version thereof. I should apologize to the reader at the start that this article doesn’t get very specific or technical at all. Moreover, with the exception of the sidebar, it might read like the ramblings of a crazed, or dazed, individual. I should also point out that this article’s title is, of course, intended to be a catchy take on the title of John Backus’s wonderful Turing Award lecture and paper, “Can Programming

Abstract not found

This paper describes the analysis, modeling, and simulation of a notional air defense system using SMOOCHES (State Machines for Object-Oriented, Concurrent, Hierarchical Engineering Specifications) . SMOOCHES is an object-oriented environment based on hierarchical state machines and extensions to Statecharts, specifically developed as an environment to specify, model, simulate and analyze / evaluate distributed, reactive systems. I. INTRODUCTION In this paper, we use SMOOCHES, an object-oriented environment developed for the hierarchical state modeling and simulation of distributed, reactive systems, to specify, model, simulate and analyze a notional air defense system. SMOOCHES [1] considers real world systems development as an iterative and interactive process, wherein system requirements and subsystem functionalities are not completely pre-defined as part of the initial requirements specification, but evolve along with the system development process. Moreover, SMOOC...