Finite state machine patterns

Dharmesh, 2020

The Braitenberg vehicles and the line following algorithms (Chap. 3) demonstrate reactive behavior, where the action of the robot depends on the current values returned by robot's sensors, not on events that happened previously. In Sect. 4.1 we present the concept of state and finite state machines (FSM). Sections 4.2 and 4.3 show how certain Braitenberg vehicles can be implemented with FSMs. Section 4.4 discusses the implementation of FSMs using state variables. 4.1 State Machines The concept of state is very familiar. Consider a toaster: initially, the toaster is in the off state; when you push the lever down, a transition is made to the on state and the heating elements are turned on; finally, when the timer expires, a transition is made back to the off state and the heating elements are turned off. A finite state machine (FSM) 1 consists of a set of states s i and a set of transitions between pairs of states s i , s j. A transition is labeled condition/action: a condition that causes the transition to be taken and an action that is performed when the transition is taken. FSMs can be displayed in state diagrams: off on lever down turn heat on timer expired turn heat off off = toaster off on = toaster on A state is denoted by a circle labeled with the name of the state. States are given short names to save space and their full names are given in a box next to the state 1 Finite state machines are also called finite automata.

2010

State Machines are the basic mechanism used to specify the behaviour of objects in UML based object models and admit the possibility of direct animation or execution of a model. Tools that exploit this potential offer the promise of both supporting early validation of a model under development and allowing generation of final code directly from the model. Recently, we have made some new proposals on how state machines are used to model behaviour: firstly, that complex object behaviour can be best modelled by the parallel composition of multiple state machines; and secondly, that a formal distinction can be made between purely event driven machines and those whose states are derived from other information in the model. We illustrate the advantages of this approach with a small example that shows how it can help reduce redundancy and promote simplicity.

2003

The systems engineering method proposed in this book, which is based on Abstract State Machines (ASMs), guides the development of software and embedded hardware-software systems seamlessly from requirements capture to actual implementation and documentation. The method bridges the gap between the human understanding and formulation of real-world problems and the deployment of their algorithmic solutions by code-executing machines.

Scenario models and hierarchical state machines play key roles in current object-oriented modeling methodologies. Our work maily focuses on a systematic transition between these two models. In this paper, we argue for the need to develop a catalog of design patterns (18,19) for state machine implementation. The originality of our proposal stems from having these patterns rooted in spe- cific behavior observed in the scenarios they originate from. We briefly contrast this approach with the work of Douglass (1).

2005

In this paper we model as Abstract State Machines (ASMs) some object-oriented design patterns, which have been introduced in [12] in the context of object-oriented programmming principles. We hope to trigger by this work some investigation of genuine modeling patterns, which are placed at a higher level of abstraction than object-oriented class structures and related programming structures.

1997

A small and simple language for sequential design is introduced. 0. INTRODUCTION Synchronous state-machine design is often expressed using graphical notations such as Algorithmic State Machine (ASM) charts 7] and state transition diagrams. An alternative is to use common hardware description languages such as VHDL 2] or Verilog 6]. For both teaching and design purposes, neither approach is satisfactory. ASM charts and similar notations invite unstructured designs and allow parallelism only at the outermost level. Educational implementations appear not to exist. VHDL and Verilog are geared toward asynchronous behaviour | in expressing synchronous designs the clock signals must be made explicit. Also they are large, complex languages with complex semantic foundations. Small (State Machine Algol-Like Language) is a small and simple imperative programming language, designed speci cally for hardware implementation. It bears roughly the same relationship to ASM charts as Algol-like software languages bear to owcharts.

1998

When designing and implementing complex computer sys tems powerful description techniques are needed that allow the repre sentation of hardware and software components at various abstraction levels and support re nement during the development process These techniques should be formal in order to support mathematical reason ing about systems properties while at the same time they should be operational so as to facilitate comprehension and implementation of the system In this paper we propose Object based Abstract State Machines ObASM an extension of Abstract State Machines ASM ASM are an operational formalism that has been successfully applied to the description of hard ware and software systems ObASM are adding a notion of locality of state and the concept of communication between loosely coupled agents These extensions are designed to be minimal additions to the traditional ASM formulation preserving their simplicity while at the same time signi cantly enhancing their modeling powe...

2000

One of the most crucial and complicated phases of real-time system development lies in the transition from system behavior (generally specified using scenario models) to the behavior of interacting components (typically captured by means of communicating hierarchical finite state machines). It is commonly accepted that a systematic approach is required for this transition. We overview such an approach, which we root in a hierarchy of “behavior integration patterns” we have elaborated. The proposed patterns guide the structuring of a component's behavior and help in integrating the behavior associated with new scenarios into the existing hierarchical finite state machine of a component. One of these patterns is discussed at length

This report explains basic notions and concepts of Abstract State Machines (ASM) as well as notation for defining ASM models. The objective here is to provide an intuitive understanding of the formalism; for a rigorous definition of the mathematical foundations of ASM, the reader is referred to [2] and [3]. Further references on ASM-related material can be found on the ASM Web Pages [1].

Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development, 2015

Most modelling languages support full state machine modelling, including especially composite states. Existing approaches to programming with states (state design patterns) either represent composite states by means of inheritance between state classes, or do not support composite states, and instead use inheritance for specialization of extensible state machines. In this paper, we present 1) a state design pattern using delegation to support composite states and inheritance together with virtual classes to support extensible state machines, and 2) a framework, implemented in Java, which also supports history and entry/exit actions. Together, these form the basis for developing support for state machines in a combined modelling and programming language.