Semantic Blueprints of Discrete Dynamic Systems

Semantic Blueprints of Discrete Dynamic Systems: Challenges and Needs in Computational Modeling of Complex Behavior⋆ Roozbeh Farahbod and Uwe Gl¨asser Software Technology Lab School of Computing Science Simon Fraser University Burnaby, British Columbia, Canada

Abstract. How can one cope with the notorious problem of establishing the correctness and completeness of abstract functional requirements in the design of control-intensive software systems prior to actually building the system? The answer given here explores abstract state machines (ASMs): a universal mathematical framework for semantic modeling of discrete dynamic systems. Combining common abstraction principles from computational logic and discrete mathematics, ASMs provide a universal model of computation and an effective instrument for analyzing and reasoning about complex semantic properties of real-world systems. Widely recognized applications include semantic foundations of virtually all kinds of architectures, languages and protocols. In this paper we focus on empirical aspects in modeling concurrent and reactive behavior.

1 Introduction Abstraction and formalization provide effective instruments for establishing critical system requirements by modeling the construction of software designs prior to coding so that one can analyze and reason about design choices and their implications [1]. To this end, computational logic and discrete mathematics help eliminating typical deficiencies that often remain hidden in informal requirements—such as ambiguities, loose ends and inconsistencies. Mathematical precision typically leads to a clearer understanding of the problem to be solved, thus reducing the risk of making premature decisions with fatal consequences [2]. In that respect, controlintensive software systems, like communications software, distributed protocol architectures, and software for distributed embedded systems, are particularly demanding. Such systems are characterized by their concurrent and reactive behavior, making it difficult to predict dynamic system properties with sufficient detail and precision under all circumstances [3]. This situation gives rise to the following question: how can one cope with the notorious problem of establishing the correctness and completeness of abstract functional requirements in the design of control-intensive software systems prior to actually building the system? The answer given here explores the abstract state machine (ASM) formalism [4], a universal mathematical framework for semantic modeling of abstract system requirements. In addition to core semantic issues in formalizing concurrent and reactive behavior, we address and exemplify the use of abstraction principles as an effective means for revealing a clear architectural view of the system under design. Abstract state machines are known for their versatility in semantic modeling of algorithms, architectures, languages, protocols and virtually all kinds of sequential, parallel and distributed systems. The ASM formalism has been studied extensively by researchers in academia and industry for more than 15 years with the intention to bridge the gap between formal and empirical approaches. Leaning toward practical applications of formal methods, this work resulted ⋆

Part of the research presented here was supported by NSERC Discovery Grant No. 611365.

in a solid methodological foundation for building ASM ground models [5]. Intuitively, an ASM ground model may be considered a semantic ‘blueprint’ of the key system requirements that need to be established in a precise and reliable form without compromising any conceivable refinements [6]. The role and nature of ground models, as discussed in [5], leads itself to the conclusion that the concept of ground model is inevitably present in every system design, but often not in an explicit form. Thus, the origin and motivation for the development of ASM specification, validation and verification techniques [7] has been the desire to make ground models visible and inspectable by analytical means and empirical techniques, exploiting machine assistance where appropriate. Widely recognized applications include semantic foundations of industrial system design languages, like the ITU-T standard for SDL [8–11], the IEEE language VHDL [12, 13] and its successor SystemC [14], programming languages like JAVA [15, 16], C# [17] and Prolog [18, 19], Web service description languages [20–22], communication architectures [23, 24], embedded control systems [25–27], et cetera.1 Beyond the natural ASM habitat of hardware/software systems, computational modeling of social systems and cognitive behavior [28, 29] addresses the broader scope of discrete dynamic systems that the very original definition of ASMs intended to capture [30]. Model-based systems engineering demands for abstract executable specifications as a tool for design exploration and experimental validation through simulation and testing. Building on experiences with two generations of ASM tools, a novel executable ASM language, called CoreASM, is being developed [31, 32]. Exploring the problem space for the purpose of writing an initial specification calls for a language that emphasizes freedom of experimentation and supports the evolutionary nature of design being a creative activity. Such a language must allow writing highly abstract and concise specifications by minimizing the need for encoding in mapping the problem space to a formal model. The principle of minimality, in combination with robustness of the underlying mathematical framework, at the same time, makes easy modifiability feasible, effectively supporting the highly iterative nature of specification and design. The remainder of this paper is organized as follows. Section 2 discusses the asynchronous ASM computation model, dealing with concurrent and reactive behavior as well as real-time aspects. Section 3 exemplifies the effective use of ASM abstraction principles for modeling complex distributed real-time systems in the context of Web Services for business process models. Section 4 outlines new developments for ASM tool support. Section 5 concludes the paper.

2 Abstract State Machines A central problem in computing science and discrete mathematics is the question of how to precisely define the notion of algorithm. Traditionally, Turing machines have been used in the study of the theory of computation as a formal model of algorithm [33]. While their original meaning was limited to the formalization of the notion of computable function according to the Church-Turing thesis, it is now agreed that any algorithm can be simulated by a Turing machine with only polynomial slowdown. For the study of semantic issues, however, this model of computation is totally inappropriate, as there typically is a huge gap between the abstraction level of an algorithm and the low-level computation of a Turing machine simulating this algorithm. The origin of the ASM formalism was the following question. Can one generalize Turing machines so that any algorithm, never mind how abstract, can be modeled by a generalized machine at its natural level of abstraction? 1

See also the ASM website at www.eecs.umich.edu/gasm/ and the overview in [4].

Theoretical foundations of ASM computation models show that sequential ASMs capture the notion of sequential algorithms in the aforementioned sense [34, 35]. Likewise, parallel ASMs (a.k.a. the basic ASM model) capture parallel algorithms [36]. For the asynchronous computation model of distributed ASMs, a generalization of the two other models, a formal proof that this model captures distributed algorithms is not known. While there is considerable empirical evidence from practical applications that the asynchronous ASM model faithfully reflects the intuitive understanding of the notion of distributed algorithm in many cases, there are still open questions. In the remainder of this paper, we restrict our attention to the asynchronous ASM computation model. The following subsections briefly explain the formal semantic framework using common notions and structures from discrete mathematics and computing science. For further details, we refer to [4, 30]. 2.1 Concurrency, Reactivity and Time The asynchronous computation model of distributed abstract state machine (DASM), originally proposed in [30] (where ASMs are called evolving algebras), defines concurrent and reactive behavior, as observable in distributed computations performed by any finite number of autonomously operating computational agents, in terms of partially ordered runs. A DASM M is defined over a given vocabulary V by its program PM and a non-empty set IM of initial states. V consists of a finite collection of symbols denoting mathematical objects and their relation in the formal representation of M, where we distinguish domain symbols, function symbols and predicate symbols. Symbols that have a fixed interpretation regardless of the state of M are called static; those that may have different interpretations in different states of M are called dynamic. A state S of M results from a valid interpretation of all the symbols in V and constitutes a variant of a first-order structure, one in which all relations are formally represented as Boolean-valued functions. Concurrent control threads in an execution of PM are modeled by a dynamic set AGENT of autonomously operating computational agents. This set may change dynamically over runs of M as required to deal with varying computational resources. Agents of M interact with one another, and possibly also with the operational environment of M, by reading and writing shared locations of a global machine state. The underlying semantic model regulates such interactions so that potential conflicts are resolved according to the definition of partially ordered runs (see Sect. 2.2). PM consists of a statically defined collection of agent programs PM1 , ..., PMk , k ≥ 1, each of which defines the behavior of a certain type of agent in terms of state transition rules. The canonical rule consists of a basic update instruction of the form f (t1 , t2 , ..., tn ) := t0 , where f is an n-ary dynamic function symbol and the ti ′ s (0 ≤ i ≤ n) are terms. An update instruction specifies a pointwise function update, i.e., an operation that replaces an existing function value by a new value to be associated with the given function arguments. Complex rules are inductively defined by a number of simple rule constructors allowing the composition of rules in various ways (as will be seen from the examples in Sect. 3). A computation of an individual agent of M, executing program PMj , is modeled by a finite or infinite sequence of state transitions of the form S0

∆S0 (PMj )

−→

S1

∆S1 (PMj )

−→

S2

∆S2 (PMj )

−→

··· ,

such that Si+1 is obtained from Si , for i ≥ 0, by firing ∆Si (PMj ) on Si , where ∆Si (PMj ) denotes a finite set of updates computed by evaluating PMj over Si . Firing an update set means that all the updates in this set are fired simultaneously in one atomic step. The result of firing an update set is defined if and only if the set does not contain conflicting updates (attempting to assign different values to the same location). Finally, M models interactions with a given environment through actions and events as observable at external interfaces, formally represented by externally controlled functions. Of particular interest are monitored functions. Such functions change their values dynamically over runs of M, although they cannot be updated internally by agents of M. A typical example is the abstract representation of global time. In a given state S of M, the global time (as measured by some external clock) is given by a monitored unary function now taking values in a linearly ordered domain TIME. Values of now increase monotonic over runs of M. 2.2 Partially Ordered Runs A DASM M performs a computation step whenever one of its agents performs a computation step. In general, one or more agents may participate in the same computation step of M. A single computation step of an individual agent is called a move. In this model, moves are atomic. Naturally, conflicting moves must be ordered so that they do not occur in the same step of M. A partially ordered run ρ of M is given by a triple (Λ, A, σ) satisfying the following four conditions (adopted from [30, Sect. 6.5]): 1. Λ is a partially ordered set of moves, where each move has only finitely many predecessors. 2. A is a function on Λ associating agents to moves such that the moves of any single agent of M are linearly ordered. 3. σ assigns a state of M to each initial segment X of Λ, where σ(X) is the result of performing all moves in X. 4. Coherence condition: If x is a maximal element in a finite initial segment X of Λ and Y = X − {x}, then A(x) is an agent in σ(Y ) and σ(X) is obtained from σ(Y ) by firing A(x) at σ(Y ). A partially ordered run defines a class of admissible runs of M rather than a particular run. In general, it may require more than one (even infinitely many) partially ordered runs to capture all admissible runs of M. From the coherence condition it follows that all linearizations of the same finite initial segment of a run of M have the same final state.2 Some implications of the partially-ordered-run semantics are illustrated by means of two simple but meaningful application examples. Example 1: Consumer-Producer Problem Assume a single producer agent and two or more consumer agents operating concurrently on a globally shared data structure. The data structure is linearly organized with the producer adding items at the one end while the consumers remove items from the opposite end. For accessing and manipulating the data structure, operations head, tail, newItem are used with an obvious meaning. In the initial state, itemList is empty. head : I TEM L IST → I TEM , tail : I TEM L IST → I TEM L IST , newItem :→ I TEM 2

Intuitively, a finite initial segment of a partially ordered run ρ is a finite subset of Λ corresponding to a (finite) prefix of ρ.

Producer/Consumer Programs

≡ itemList := itemList ⌢ newItem

ProducerProgram

≡ if itemlist 6= empty then item := head(itemList) itemList := tail(itemList)

ConsumerProgram

Whenever the list of items is non-empty, two or more consumers potentially compete for the same item. While all consumers update the data structure in a consistent way by removing the head item, any attempt to consume the same item more than once would produce a logical conflict. The semantics of partially ordered runs excludes conflicting runs, since the resulting state can not be reached by linearizations of such a run. So it does what one would expect. Example 2: Door and Window Manager Assume two propositional variables, door and window, where door = true means that ‘the door is open’ and window = true means that ‘the window is open’. There are two distinct agents: a door-manager d and a window-manager w. Door/Window Managers

≡ if ¬window then door := true

//

move x

≡ if ¬door then window := true

//

move y

DoorManager

WindowManager

Initially (in state S0 ) both the door and the window are closed. Then there are only two possible runs, and in each run only one of the agents makes a move. We cannot have x < y because w is disabled in the state Sx obtained from S0 by performing x. Also, we cannot have y < x because d is disabled in the state Sy obtained from S0 by performing y. Finally, we cannot have a run where x and y are incomparable, that is neither x < y nor y < x. By the coherence condition, the final state Sx,y of such a run would be obtained from either Sx by performing y or from Sy by performing x; either case is impossible. Why would a parallel execution of x, y not be a natural choice as such a run does not cause any logical conflict? Arguably, the coherent constraint seems too restrictive in this case and leads to an inconclusive result, not reflecting the intuitive meaning of concurrency.

3 Web Services Architecture In this section, we illustrate the application of ASM abstraction principles to modeling of complex distributed systems by means of examples from an abstract operational semantics for one of the leading business process specification languages for the Web Services architecture. The main focus here is on architectural aspects of our DASM model, not on a comprehensive representation of the language semantics. For further technical details, we refer the interested reader to our previous work [37–39, 21]. With the Web being used as a widespread platform for automated application-to-application interactions and integration of business-partner applications, Web services composition becomes

an important issue. The Business Process Execution Language for Web Services (BPEL) is the most prominent Web services composition language. It provides distinctive expressive means for describing the process interfaces of Web based business protocols and builds on existing standards and technologies for Web Services; specifically, it is defined on top of the service interaction model of W3C’s Web Services Description Language (WSDL) [40]. The following sections briefly outline the overall architecture of an abstract machine model used for formalizing the dynamic properties of BPEL. The pick activity serves as a concrete example of a structured activity involving concurrency and real-time, among other aspects. 3.1 The BPEL Abstract Machine In [37–39, 21], we present the most comprehensive formal semantic model of BPEL known so far. Our BPEL abstract machine, called BPELAM , provides a concise and robust semantic framework for establishing the key language attributes in a precise and well defined form. The concurrent and reactive nature of Web services and the need for dealing with time related aspects in coordinating distributed activities call for an asynchronous execution model with an abstract notion of real time. Thus, the semantic foundation for the BPELAM model is a distributed real-time ASM. The resulting model captures the dynamic properties of the key BPEL language constructs defined in the language reference manual [41], henceforth called LRM, including concurrent control structures, dynamic creation and termination of service instances, communication primitives, message correlation, event handling, and fault and compensation handling. The goal of our work is twofold. First and foremost, BPELAM provides a firm semantic foundation, a blueprint of the language design, for checking consistency and validity of semantic properties. Formalization is crucial for identifying and eliminating deficiencies that easily remain hidden in the informal language definition of the LRM. The presented approach will allow us to “reason about the current specification and related issues” and to “uncover issues that would otherwise go unnoticed” [42, Issue #40]. Second, we address pragmatic issues resulting from previous experience with other industrial standards, including the ITU-T language SDL [8] and the IEEE language VHDL [12]. An important observation is that sensible use of formal techniques and supporting tools for practical purposes such as standardization calls for a gradual formalization of abstract requirements with a degree of detail and precision as needed [8]. To avoid a gap between the informal language definition and the formal semantics, the ability to model the language definition as is without making compromises is crucial. Consequently, we adopt here the LRM view and terminology, effectively formalizing the intuitive understanding of BPEL as directly as possible and in a comprehensible and objectively verifiable form. Our BPELAM provides what is called an ASM ground model [4, 5] of BPEL. Constructing such a ground model demonstrates the practicability of the formalization approach. The dynamic nature of standardization calls for flexibility and robustness of the formalization approach. To this end, we feel that the ASM formalism and abstraction principles offer a good compromise between practical relevance and mathematical elegance — already proven useful for practical purposes in other standardization contexts [8]. 3.2 Architecture of BPELAM The BPELAM architecture is composed of three basic building blocks, referred to as core, data handling extension, and fault and compensation extension. The core handles dynamic process

creation/termination, communication primitives, message correlation, concurrent control structures, as well as the main activities of BPEL. The core does not consider data handling, fault handling, and compensation behavior of BPEL; rather these aspects are treated as extensions to the core. Together with the core, the extensions form the complete BPELAM . To deal with the complexity of the BPELAM and the required expansions to cover data handling and fault and compensation handling behavior, we introduce a two dimensional refinement approach: – vertical refinement which provides step by step elucidation using a combination of data refinement and procedural refinement in a three level structure, and – horizontal refinement which facilitates behavioral decomposition using conservative (incremental) extensions.

BPEL Informal Documentation

The core of the BPEL Abstract Machine

BPEL Formal Model Overview Formal Documentation Abstract Model Intermediate Model Executable Model

Fault/Compensation extension

Data Handling extension

Fig. 1. Vertical and Horizontal Organization of BPELAM

Figure 1 illustrates the structure of the enhanced BPELAM . Based on this approach, the BPELAM comprises three basic building blocks reflecting its horizontal organization: core, data handling extension, and fault and compensation extension. The core does not deal with data handling issues, faults or compensation behavior. The data handling extension adds BPEL variables and data handling behavior to the core thus enables business processes to create and manipulate message values. The fault and compensation extension complements the model by providing fault handling and compensation behavior. For a comprehensive description of these extensions see [39]. Vertically, the architecture is organized into three levels of abstraction, called abstract model, intermediate model and executable model, as illustrated in Figure 1. The vertical organization provides step by step elucidation using abstraction levels. The abstract model formally sketches the behavior of the key BPEL constructs and introduces the overall organization of the abstract machine architecture. The intermediate model, obtained as the result of the first refinement step, provides a comprehensive formalization as required for establishing of and reasoning about key language properties. Finally, the executable model provides an abstract executable semantics implemented in AsmL [24]. A graphical user interface (GUI) facilitates experimental validation through simulation and animation of abstract machine runs. To this end, the BPELAM forms a hierarchy of three DASM ground models [4, 43] obtained as the result of stepwise refinements of the abstract model.

A BPEL document abstractly defines a Web service consisting of a collection of business process instances. A business process in BPEL is mainly defined by (1) a list of its business partners, i.e. Web services that this process interacts with, (2) a set of variables that keep the state of the process, and (3) a BPEL activity defining the logic of interactions between the process and its partners. The main activity of a BPEL process usually is a sequence activity which includes a sequence of activities that together define the behavior of the business process. Activities that can be performed by a business process are categorized into basic activities, structured activities and scope-related activities. Basic activities perform simple operations like receive, reply, invoke and others. Structured activities impose an execution order on a collection of activities and can be nested. Scope-related activities serve for defining logical units of work and encapsulating the reversible behavior of each such unit. The LRM presents a flat view of BPEL processes and their activities. To properly model dynamic execution of a BPEL process, one intuitively needs to deal with two dimensions. One is the collaboration of activities and the other one is the lifecycle of each individual activity. These aspects are not explicitly addressed in the reference manual, while they are implicitly present in the description of the language and its constructs. We model these two dimensions by introducing Process Execution Trees, hence revealing the collaboration of activities in a process instance, and by eliciting the Execution Lifecycle of activities. Process Execution Tree Intuitively, the execution of a process instance is decomposed into a collection of execution lifecycles for the individual BPEL activities. We therefore introduce activity agents, created dynamically by process agents, for executing structured activities. Each activity agent dynamically creates additional activity agents for executing nested, structured activities. Similarly, it creates auxiliary activity agents for dealing with concurrent control threads (like in flow and pick. For instance, to concurrently execute a set of activities, a flow agent assigns each enclosed activity to a separate flow thread agent [22]. At any time during the execution of a process instance, the DASM agents running under control of this process agent form a tree structure where each of the sub-agents monitors the execution of its child agents (if any) and notifies its parent agent in case of normal completion or fault. This structure provides a general framework for execution of BPEL activities. The DASM agents that model BPEL process execution are jointly called kernel agents. They include process agents and subprocess agents. In the core, however, subprocess agents are identical to activity agents. Figure 2 sketches the process execution tree of the BPELAM . Activity Execution Lifecycle Figure 3 illustrates the normal activity execution lifecycle of kernel agents in the BPELAM core. When created, a kernel agent is in the Started mode. After initialization, the kernel agent starts executing its assigned task by switching its mode to Running. Upon completion, the agent switches its mode to Activity-Completed and decides (based on the nature of the assigned task) to either return to the Running mode or finalize the execution and become Completed. Activity agents that may execute more than one activity (like sequence) or execute one activity more than once (like while) can switch back and forth between the two modes Activity-Completed and Running. 3.3 Pick Activity: An Example A pick activity identifies a set of possible events and associates with each of these events a certain activity. Intuitively, it waits on any of these events to occur and then performs the associated activity; upon the occurrence of the first event, the pick activity no longer accepts any

Process Agent Root Process Sub-Process Agent

Sub-Process Agent

Sub-Process Agent

Completed, Exited, and Faulted Notifications

Parent Agent

Sub-Process Agent

Sub-Process Agent

Termination Notification Parent Agent

Sub-Process Agent

Sub-Process Agent

Sub-Process Agent

Fig. 2. Process Execution Tree

Completed

Execution is completed

There is nothing to be executed

Started

There is more to be executed / Fetch next activity

Activity Completed

Initialization

Running

Execution of the enclosed activity is completed

Fault Handling

It is a scope agent / Start fault handler agent.

Fault handler completed successfully Fault handler throws a fault

Exited

Executing activity

A fault occurs

Execution Fault It is not a scope agent / Notify parent agent.

Faulted

Fig. 3. Activity Execution Lifecycle in BPELAM

other event. There are basically two different types of events: onMessage events and onAlarm events. An onMessage event occurs as soon as a related message is received, whereas an onAlarm event is triggered by a timer mechanism waiting ‘for’ a certain period of time or ‘until’ a certain deadline is reached. In BPELAM , each pick activity is modeled by a separate activity agent, called pick agent. A pick agent is assisted by two auxiliary agents, a pick message agent that is waiting for a message to arrive, and a pick alarm agent that is watching a timer. We formalize the semantics of the pick activity in several steps, each of which addresses a particular property, and then compose the resulting DASM program, called PickProgram, in which self refers to any pick agent executing the program. Pick Agent

≡ case execMode(self ) of emStarted → PickAgentStarted emRunning → PickAgentRunning emActivityCompleted → FinalizePickAgent emCompleted → stop self

PickProgram

When created, the pick agent is in the Started mode and initializes its execution by creating a pick alarm agent and a pick message agent. It then switches its mode to Running and waits for an event to occur — either a message arrives or a timer expires. Pick Agent

≡ if normalExecution(self ) then onsignal s : AGENT COMPLETED execMode(self ) := emActivityCompleted otherwise if chosenAct(self ) = undef then choose dsc ∈ occurredEvents(self ) with MinTime(dsc) chosenAct(self ) := onEventAct(edscEvent(dsc)) // onEventAct is the activity associated with an event else ExecuteActivity(chosenAct(self )))

PickAgentRunning

Depending on the event type, either the pick message agent or the pick alarm agent notifies the pick agent by adding an event descriptor to the occuredEvents set of the pick agent. An event descriptor contains information on the event such as the time of its occurrence. When an event occurs, the pick agent updates the function chosenAct (with initial value undef) with the activity associated with the event. Once the activity is chosen (chosenAct(self) 6= undef), the pick agent performs the chosen activity and remains Running until the execution of the chosen activity is completed as indicated by a predicate chosenActCompleted. It then switches its execution mode to Activity-Completed. A Pick Alarm Agent acts as a collection of timers. In its running mode, it waits until one of the onAlaram events triggers, in which case it sends an event notification to its parent agent (pick agent) and switches to Activity-Completed mode for termination. If a message event occurs while pick alarm agent is waiting on alarm events, pick alarm agent terminates by switching to Activity-Completed mode.

Pick Alaram Agent

≡ if normalExecution(self ) then if messageEventOccured then execMode(self ) := emActivityCompleted else forall e ∈ triggeredAlarms // create an event descriptor & add it to occuredEvents(parent) GenerateEventNotification(e, triggerT ime(e, startT ime(self ))) execMode(self ) := emActivityCompleted where messageEventOccured ≡ ∃e ∈ occuredEvents(parentAgent(self )) triggeredAlarms ≡ {e | e ∈ onAlarmEventSet(activity(self )) ∧ triggerT ime(e, startT ime(self )) ≤ now} PickAlarmAgentRunning

Finalizing a running pick agent includes informing its parent agent that the execution is completed and changing the execution mode to Completed. As illustrated in Figure 3, the Completed mode leads to the agent’s termination. For a complete description, also including the definitions of PickAgent-Started as well as FinalizePickAgent and the program of pick message agents, see [39, 20].

4 ASM Tool Support Machine assistance plays an increasingly important role in making practical systems design feasible. Thus it is not surprising that there is a variety of executable ASM languages that have been developed over the years. The most prominent one is AsmL [44], developed by the FSE group at Microsoft Research. Other ASM tool environments, like the ASM Workbench [45], Xasm [46] and AsmGofer [47], as well, were recognized beyond academic circles and used for industrial system design, for instance, in the FALKO project at Siemens, Munich [27]. Besides practical tool development, conceptual frameworks for more systematic implementations have been devised, such as the evolving algebra abstract machine (EAM) [48], leading to an improved understanding of fundamental aspects in making ASMs executable on real machines. AsmL is a strongly typed language based on the concepts of ASMs but also incorporates numerous object-oriented features and constructs for rapid prototyping of component-oriented software, thus departing in that respect from the theoretical model of ASMs; rather it comes with the richness of a fully fletched programming language. At the same time, it lacks any built-in support for dealing with distributed systems. Being deeply integrated with the software development, documentation, and runtime environments of Microsoft, its design was shaped by practical needs of dealing with fairly complex requirements and design specifications for the purpose of software testing; as such, it is oriented toward the world of code. This has made it less suitable for initial modeling at the peak of the problem space and also restricts the freedom of experimentation. Building on experiences with existing ASM languages and tools, a novel executable ASM language, called CoreASM [31], and supporting tool architecture is being developed at Simon Fraser University in collaboration with the University of Pisa. The CoreASM project [32] aims at the design of a lean language for high-level design, experimental validation and formal verification (where appropriate) of abstract machine models. CoreASM encourages rapid prototyp-

ing of abstract requirements and design specifications, starting with mathematically-oriented, abstract and untyped models that can be gradually refined using the refinement techniques exploited in [6]. Focusing on the early phases of the software design process, primary concerns are toward the world of problems, addressing the needs of that part of the software development process that is closest to the problem space, as illustrated in Figure 4.

Problem

CoreASM

Construction

AsmL, XASM, …

Coding

Ground model Refinement

…

Design

Abstract Software Model

Detailed ground model

Implementation

Code

Fig. 4. Background and Motivation

The CoreASM environment [49] consists of a platform-independent engine for executing the language and a GUI for interactive visualization and control of simulation runs. The engine comes with a sophisticated and well defined interface, thereby enabling future development and integration of complementary tools, e.g., for symbolic model checking [50] and automated test generation [51]. Sophisticated ASM specifications frequently introduce special backgrounds3, often with non-standard operations. Thus, flexible mechanisms for extending the core language are vital in order to preserve the freedom of experimentation that has proved so fruitful in the development of ASM concepts. To this end, the CoreASM tool architecture is designed around a concept of plug-ins that allows to customize the language to specific application needs [31]. The design of CoreASM is novel and the underlying principles are unprecedented among the existing executable ASM languages. Almost all of these languages build on predefined type concepts rather than the untyped language underlying the theoretical model of ASMs; none of these languages comes with a run-time system supporting the execution of distributed ASM models; only Xasm is designed for systematic language extensions and in that respect is similar to our approach; however, the Xasm language itself diverts from the original definition of ASMs and seems closer to a programming language.

5 Lessons Learned We explore here, from the perspective of applied research with formal methods, the role of the ASM formalism as a practical instrument for analyzing and reasoning about abstract requirements of concurrent and reactive systems. The vast number and variety of genuine applications in academia and industry suggest that this mathematical framework for semantic modeling of dynamic system properties is specifically appealing for bridging the gap between empirical and formal approaches. But what exactly is it that makes this formalism such a versatile tool? 3

We call background a collection of related domains and relations packaged together as a single logical unit.

While there seems to be no single short answer, it is apparent that a sensible balance between mathematical elegance and practical relevance is crucial for building reliable ground models of complex system requirements. To this end, practical needs call for an agile formalization approach, one that allows to model a system as is, without making any compromises. More specifically, there seem to be two main aspects contributing to the flexibility required to cope with complex requirements, which often come in the form of a moving target. The first one is the natural abstraction provided by the asynchronous ASM computation model: viewing distributed computations as interaction between concurrent control threads manipulating a globally shared state is convenient because it minimizes the need for encoding of communication. Abstractly, distributed systems have global states, albeit it may be impossible for an individual observer to monitor in detail how a global state evolves over time. The second aspect pertains to the problem of gradually devising and refining a clear architectural view of a system that, in the early phases of the design process, is mainly characterized by abstract requirements. The concept of a virtual machine provides a systematic framework for a clear separation of concerns as required in any attempt to develop a well defined, modular and robust structure. Likewise, it also simplifies the process of rediscovering such a structure in re-engineering of legacy systems with no documentation other than the code itself. Finally, the ASM formalism and abstraction principles provide a proven paradigm for teaching how to separate specification and design (problem solving) from construction and coding (engineering), a cornerstone in computer science education [52].

Acknowledgments The second coauthor expresses his sincere appreciation to the Heinz Nixdorf Institute, and specifically to Franz Rammig, for encouraging and supporting over several years the work on the formal semantics of the ITU-T language SDL, leading to a new formal definition of the language as part of the international ITU-T standard for SDL. This work was carried out in the vibrant and inspiring research atmosphere of the DFG Collaborative Research Centre 376.

References 1. Berry, D.: Formal Methods: The Very Idea. Science of Computer Programming 42 (2002) 511–27 2. Huckle, T.: Collection of software bugs. Technical report, Technical University Munich (2004) Last visited Sep. 2005, http://www5.in.tum.de/ huckle/bugse.html. 3. Manna, Z., Pnueli, A.: The Temporal Logic of Reactive and Concurrent Systems: Specifcation. Springer-Verlag (1992) 4. B¨orger, E., St¨ark, R.: Abstract State Machines: A Method for High-Level System Design and Analysis. Springer-Verlag (2003) 5. B¨orger, E.: The ASM ground model method as a foundation for requirements engineering. In: Verification: Theory and Practice. (2003) 145–160 6. B¨orger, E.: The ASM Refinement Method. Formal Aspects of Computing (2003) 237–257 7. B¨orger, E.: The Origins and the Development of the ASM Method for High Level System Design and Analysis. Journal of Universal Computer Science 8 (2002) 2–74 8. Gl¨asser, U., Gotzhein, R., Prinz, A.: The formal semantics of SDL-2000: status and perspectives. Comput. Networks 42 (2003) 343–358 9. R. Eschbach and U. Gl¨asser and R. Gotzhein and M. von L¨owis and A. Prinz: Formal Definition of SDL-2000: Compiling and Running SDL Specifications as ASM Models. Journal of Universal Computer Science 7 (2001) 1024–1049 10. Eschbach, R., G¨asser, U., Gotzhein, R., Prinz, A.: On the Formal Semantics of SDL-2000: A Compilation Approach Based on an Abstract SDL Machine. In Y. Gurevich and P. Kutter and M. Odersky and L. Thiele, ed.: Abstract State Machines: Theory and Applications. Volume 1912 of LNCS., Springer-Verlag (2000) 242–265 11. ITU-T Recommendation Z.100 Annex F (11/00): SDL Formal Semantics Definition. International Telecommunication Union. (2001) 12. B¨orger, E., Gl¨asser, U., M¨uller, W.: Formal Definition of an Abstract VHDL’93 Simulator by EA-Machines. In Delgado Kloos, C., Breuer, P.T., eds.: Formal Semantics for VHDL. Kluwer Academic Publishers (1995) 107–139

13. B¨orger, E., Gl¨asser, U., M¨uller, W.: The Semantics of Behavioral VHDL’93 Descriptions. In: EURO-DAC’94. European Design Automation Conference with EURO-VHDL’94, Los Alamitos, California, IEEE CS Press (1994) 500–505 14. M¨uller, W., Ruf, J., Rosenstiel, W.: An ASM based SystemC simulation semantics. In M¨uller, W., Ruf, J., Rosenstiel, W., eds.: SystemC - Methodologies and Applications, Kluwer Academic Publishers (2003) 15. St¨ark, R., Schmid, J., B¨orger, E.: Java and the Java Virtual Machine: Definition, Verification, Validation. Springer-Verlag (2001) 16. E. B¨orger and W. Schulte: A Practical Method for Specification and Analysis of Exception Handling: A Java/JVM Case Study. IEEE Transactions on Software Engineering 26 (2000) 872–887 17. B¨orger, E., Fruja, N.G., Gervasi, V., St¨ark, R.F.: A high-level modular definition of the semantics of C#. Theoretical Computer Science 336 (2005) 235–284 18. B¨orger, E.: A Logical Operational Semantics for Full Prolog. Part I: Selection Core and Control. In B¨orger, E., Kleine B¨uning, H., Richter, M.M., Sch¨onfeld, W., eds.: CSL’89. 3rd Workshop on Computer Science Logic. Volume 440 of LNCS., Springer (1990) 36–64 19. B¨orger, E.: A Logical Operational Semantics of Full Prolog. Part II: Built-in Predicates for Database Manipulation. In Rovan, B., ed.: Mathematical Foundations of Computer Science. Volume 452 of LNCS. Springer (1990) 1–14 20. Farahbod, R., Gl¨asser, U., Vajihollahi, M.: Abstract Operational Semantics of the Business Process Execution Language for Web Services. Technical Report SFU-CMPT-TR-2005-04, Simon Fraser University (2005) Revised version of SFUCMPT-TR-2004-03, April 2004. 21. Farahbod, R., Gl¨asser, U., Vajihollahi, M.: A formal semantics for the business process execution language for Web Services. In Bevinakoppa, S., et al., eds.: Web Services and Model-Driven Enterprise Information Systems, Portugal, INSTICC Press (2005) 144–155 22. Farahbod, R., Gl¨asser, U., Vajihollahi, M.: Specification and Validation of the Business Process Execution Language for Web Services. In Zimmermann, W., Thalheim, B., eds.: Abstract State Machines 2004. Advances In Theory And Practice: 11th International Workshop (ASM 2004), Germany, Springer-Verlag (2004) 23. Gl¨asser, U., Gu, Q.P.: Formal description and analysis of a distributed location service for mobile ad hoc networks. Theoretical Computer Science 336 (2005) 285–309 24. Gl¨asser, U., Gurevich, Y., Veanes, M.: Abstract communication model for distributed systems. IEEE Trans. on Soft. Eng. 30 (2004) 458–472 25. B¨orger, E., Riccobene, E., Schmid, J.: Capturing Requirements by Abstract State Machines: The Light Control Case Study. Journal of Universal Computer Science 6 (2000) 597–620 26. Beierle, C., B¨orger, E., Durdanovic, I., Gl¨asser, U., Riccobene, E.: Refining Abstract Machine Specifications of the Steam Boiler Control to Well Documented Executable Code. In Abrial, J.R., B¨orger, E., Langmaack, H., eds.: Formal Methods for Industrial Applications. Specifying and Programming the Steam-Boiler Control. Number 1165 in LNCS. Springer (1996) 62–78 27. B¨orger, E., P¨appinghaus, P., Schmid, J.: Report on a Practical Application of ASMs in Software Design. In Y. Gurevich and P. Kutter and M. Odersky and L. Thiele, ed.: Abstract State Machines: Theory and Applications. Volume 1912 of LNCS., Springer-Verlag (2000) 361–366 28. Brantingham, P.L., Gl¨asser, U., Kinney, B., Singh, K., Vajihollahi, M.: A Computational Model for Simulating Spatial Aspects of Crime in Urban Environments. In: Proc. IEEE International Conference on Systems, Man and Cybernetics. IEEE Press (2005) 3667–3674 29. Brantingham, P.L., Gl¨asser, U., Kinney, B., Singh, K., Vajihollahi, M.: Modeling Urban Crime Patterns: Viewing MultiAgent Systems as Abstract State Machines. In D. Beauquier, E.B., Slissenko, A., eds.: Proc. 12th International Workshop on Abstract State Machines. University Paris 12 (2005) 101–117 30. Gurevich, Y.: Evolving Algebras 1993: Lipari Guide. In B¨orger, E., ed.: Specification and Validation Methods. Oxford University Press (1995) 9–36 31. Farahbod, R., Gervasi, V., Gl¨asser, U.: CoreASM: An extensible ASM execution engine. In Beauquier, D., B¨orger, E., Slissenko, A., eds.: Proc. of the 12th Int’l Workshop on Abstract State Machines. (2005) 153–165 32. Farahbod, R., et al.: The CoreASM Project. (2005) http://www.coreasm.org. 33. Sipser, M.: Introduction to the Theory of Computation. PWS Publishing Company (1997) 34. Gurevich, Y.: Sequential Abstract State Machines Capture Sequential Algorithms. ACM Transactions on Computational Logic 1 (2000) 77–111 35. Reisig, W.: On Gurevich’s Theorem on Sequential Algorithms. Acta Informatica 39 (2003) 273–305 36. Blass, A., Gurevich, Y.: Abstract State Machines Capture Parallel Algorithms. ACM Transactions on Computation Logic 4 (2003) 578–651 37. Farahbod, R., Gl¨asser, U., Vajihollahi, M.: Specification and Validation of the Business Process Execution Language for Web Services. Technical Report SFU-CMPT-TR-2003-06, Simon Fraser University (2003) 38. Vajihollahi, M.: High level specification and validation of the business process execution language for web services. Master’s thesis, Simon Fraser University, Burnaby, Canada (2004) 39. Farahbod, R.: Extending and refining an abstract operational semantics of the web services architecture for the business process execution language. Master’s thesis, Simon Fraser University, Burnaby, Canada (2004) 40. W3C: Web Services Description Language (WSDL) Version 1.2 Part 1: Core Language. (2003) Last visited May 2004, http://www.w3.org.

41. Andrews, T., et al.: Business process execution language for web services version 1.1 (2003) Last visited Feb. 2005, http://ifr.sap.com/bpel4ws/. 42. Organization for the Advancement of Structured Information Standards (OASIS): WS BPEL issues list. (2004) http://www.oasis-open.org. 43. Benczur, A., Gl¨asser, U., Lukovszki, T.: Formal Description of a Distributed Location Service for Ad Hoc Mobile Networks. In B¨orger, E., Gargantini, A., Riccobene, E., eds.: Abstract State Machines 2003 - Advances in Theory and Practice. Volume 2589., Springer (2003) 204–217 44. Microsoft FSE Group: The Abstract State Machine Language. (2003) Last visited June 2003, http://research.microsoft.com/fse/asml/. 45. Del Castillo, G.: Towards Comprehensive Tool Support for Abstract State Machines. In Hutter, D., Stephan, W., Traverso, P., Ullmann, M., eds.: Applied Formal Methods — FM-Trends 98. Volume 1641 of LNCS., Springer-Verlag (1999) 311– 325 46. Anlauff, M.: XASM – An Extensible, Component-Based Abstract State Machines Language. In Y. Gurevich and P. Kutter and M. Odersky and L. Thiele, ed.: Abstract State Machines: Theory and Applications. Volume 1912 of LNCS., Springer-Verlag (2000) 69–90 47. Schmid, J.: Executing ASM Specitications with AsmGofer. (2005) Last visited Sep. 2005, www.tydo.de/AsmGofer/. 48. Del Castillo, G., Durdanovi´c, I., Gl¨asser, U.: An Evolving Algebra Abstract Machine. In B¨uning, H.K., ed.: Proceedings of the Annual Conference of the European Association for Computer Science Logic (CSL’95). Volume 1092 of LNCS., Springer (1996) 191–214 49. Farahbod, R., Gervasi, V., Gl¨asser, U.: Design and Specification of the CoreASM Execution Engine. Technical report, Simon Fraser University (2005) Revised version of SFU-CMPT-TR-2005-02, February 2005. 50. Del Castillo, G., Winter, K.: Model Checking Support for the ASM High-Level Language. In Graf, S., Schwartzbach, M., eds.: Proceedings of the 6th International Conference TACAS 2000. Volume 1785 of LNCS., Springer-Verlag (2000) 331–346 51. Gargantini, A., Riccobene, E., Rinzivillo, S.: Using Spin to generate tests from ASM specifications. In: Abstract State Machines 2003, Springer (2003) 263–277 52. B¨orger, E.: The asm method: A cornerstone in computer science education. In Beauquier, D., B¨orger, E., Slissenko, A., eds.: Proc. of the 12th Int’l Workshop on Abstract State Machines. (2005) 49–56