Difference between revisions of "Statemachine DSL"

From OS.bee documentation
Jump to: navigation, search
Line 41: Line 41:
 
*'''guard''' - A condition that must evaluate to true that the following transistion will be processed.
 
*'''guard''' - A condition that must evaluate to true that the following transistion will be processed.
  
===Keywords===
+
====Syntax====
 +
 
 +
=====package definition=====
 +
 
 +
► '''Syntax''':
 +
<syntaxhighlight lang="java">
 +
package <package name>  {
 +
    import <import models/class name>
 +
    ...
 +
 
 +
    table ... [using datamart <datamart name>
 +
    {
 +
        axis...[details{...}]
 +
        [events{...}]
 +
        [actions{...}]
 +
    }]
 +
    ...
 +
}
 +
</syntaxhighlight>
 +
 
 +
=====table=====
 +
 
  
 
== Copyright Notice ==
 
== Copyright Notice ==
 
{{Copyright Notice}}
 
{{Copyright Notice}}

Revision as of 07:01, 27 September 2017

Introduction

State Machine

State Machine or extended finite-state machine (EFSM) is a mathematical model of computation and represents an abstract machine that can be in exactly one of a finite number of states at any given time. The State Machine can change from one state to another in response to external events. The change from one state to another is called a transition. A EFSM is defined by a list of its states, its initial state, and the conditions for each transition. The condition for a transition is called guard. There can be many guards protecting a transition to be triggered. Every guard is joined with a logical AND operation, so every guard must evaluate to true, to trigger a protected transition. Data operations can occur before a transition. They are called actions. Actions prepare the indicated state of the transition, calculate things or display information. The StatemachineDSL described in the following implements an EFSM where the FSM-block is represented by states, the A-block is called actions and the E-block is called guards.

Further reading

https://en.wikipedia.org/wiki/Finite-state_machine

https://en.wikipedia.org/wiki/Extended_finite-state_machine

https://en.wikipedia.org/wiki/UML_state_machine


Statemachine DSL

Statemachine DSL implements the state pattern (https://en.wikipedia.org/wiki/State_pattern) and interconnects UI model, FunctionLibrary, DTO and peripheral services like JavaPOS, ZVT protocol and others.

The main semantic elements of the StatemachineDSL are:

  • package - The root element that contains all the other elements. A model can contain multiple packages.
  • import declarations - Used to import external models or other Java classes.
  • statemachine - The container for the implementation of the EFSM following the state pattern.
  • events - Contains all user defined events.
  • event - Defines a single event by id. Events build the interconnection elements between controls and transitions.
  • controls - The container for all type of beans (https://en.wikipedia.org/wiki/JavaBeans) to be controlled by the state machine.
  • scheduler - A type of bean that can be triggered to emit a defined event after a defined delay.
  • keypad - A type of bean that builds a keypad containing one or more buttons to emit a defined event when pressed.
  • fields - A type of bean that holds data of input fields or labels from UI.
  • dataProvider - A type of bean that retrieves and stores data based on DTO.
  • peripheral - A type of bean that controls input/output operations with peripheral units. Peripheral units can be printers, displays or other external devices following the JavaPOS standard (http://www.javapos.com/). Peripheral units can also emit events representing its current state or error.
  • attribute - Defines different types for usage with control.
  • states - The container for all state definitions of this state machine.
  • state - A single state the machine can be at a point in time.
  • triggers - The container for all possible event processing blocks inside a state.
  • trigger - The action block following this trigger will be executed when one of its events occur.
  • actions - The container for all process instructions to be done in sequence inside this block. Optionally an action block can follow a transition.
  • transistion - The transition will be executed when all actions of this block were processed successfully.
  • guards - The container for guards protecting the following transistion.
  • guard - A condition that must evaluate to true that the following transistion will be processed.

Syntax

package definition

Syntax:

package <package name>  {
    import <import models/class name>
    ...

    table ... [using datamart <datamart name>
    {
        axis...[details{...}]
        [events{...}]
        [actions{...}]
    }]
    ...
}
table

Copyright Notice

All rights are reserved by Compex Systemhaus GmbH. In particular, duplications, translations, microfilming, saving and processing in electronic systems are protected by copyright. Use of this manual is only authorized with the permission of Compex Systemhaus GmbH. Infringements of the law shall be punished in accordance with civil and penal laws. We have taken utmost care in putting together texts and images. Nevertheless, the possibility of errors cannot be completely ruled out. The Figures and information in this manual are only given as approximations unless expressly indicated as binding. Amendments to the manual due to amendments to the standard software remain reserved. Please note that the latest amendments to the manual can be accessed through our helpdesk at any time. The contractually agreed regulations of the licensing and maintenance of the standard software shall apply with regard to liability for any errors in the documentation. Guarantees, particularly guarantees of quality or durability can only be assumed for the manual insofar as its quality or durability are expressly stipulated as guaranteed. If you would like to make a suggestion, the Compex Team would be very pleased to hear from you.

(c) 2016-2024 Compex Systemhaus GmbH