Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "VIATRA2/Examples/VTCL/ASM"

< VIATRA2‎ | Examples‎ | VTCL
(Simple rules)
(Abstract State Machines)
Line 42: Line 42:
 
}
 
}
 
</source>
 
</source>
 +
 +
=== User defined ASM rules ===
 +
 +
Users can define ASM rules as means for encapsulating certain functionality as a reusable operation.
 +
A user-defined ASM rule has an arbitrary number of parameters with the following directions:
 +
* '''in''': input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.
 +
* '''out''': output parameter, which means that  (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule
 +
* '''inout''': input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.
 +
 +
An optional '''type''' can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).
 +
 +
<source lang="text">
 +
import datatypes;
 +
machine callrules_01{
 +
rule test(in X:String , out Y, inout Z) = seq {
 +
update Y = X+Z;
 +
print(X + Y + Z); // prints "aacc"
 +
}
 +
rule main() = seq{
 +
call test("a", "b", "c");
 +
}
 +
}
 +
</source>
 +
  
 
=== Simple rules ===
 
=== Simple rules ===
Line 66: Line 90:
  
 
=== Composite rules ===
 
=== Composite rules ===
 
=== User defined ASM rules ===
 

Revision as of 09:27, 20 February 2009

Abstract State Machines

Abstract state machines (ASMs) provide a high-level means for assembling complex transformation programs.

ASM functions

ASM functions provide a non-persistent map to store values. Each ASM function needs to be declared prior to its first use. Initial values can also be set when defining an ASM function. The values stored at a certain location of an ASM function can be updated using the update ASM construct (see later).

machine asmFuns {
 asmfunction team / 2 {
      // Initialization
	(1, "real") = "Casillas";
	(7, "real") = "Raul";
	// Any values are allowed to be used in the untyped version
	(7.1, 6) = 2;
 }
 
 asmfunction anotherFun / 1; // An ASM function without initialization
}

In the new (upcoming) VIATRA2 version, types can also be defined for ASM functions as follows.

// Import is needed if types are intended to be used by local names
import datatypes;
machine asmFuns {
 asmfunction team(Integer, datatypes.String) : String  { // FQNs can always be used for defining types
	(1, "real") = "Casillas";
	(7, "real") = "Raul";
	// The following initialization would be a type error
	// (7.1, 6) = 2;
 }
 
 rule main() = seq 
 {
	update team(1, "mu") = "van der sar";
 }
}

User defined ASM rules

Users can define ASM rules as means for encapsulating certain functionality as a reusable operation. A user-defined ASM rule has an arbitrary number of parameters with the following directions:

  • in: input parameter, which means (i) the parameter should be non-empty when calling the rule, and (ii) all updates of the corresponding parameter (variable) within the rule will be lost after the completion of the ASM rule.
  • out: output parameter, which means that (i) the value passed as input to an output parameter is ignored, but the effects of updates of an output variable are reflected after the completion of ASM rule
  • inout: input-output parameter, which means that an input value is passed to the ASM rule, and the effects of updates are reflected upon completion.

An optional type can be associated to each parameter of a user-defined ASM rule, which refers to an existing model element within the model space (i.e. existing at compile time).

import datatypes;
machine callrules_01{
 rule test(in X:String , out Y, inout Z) = seq { 
	update Y = X+Z;
	print(X + Y + Z); // prints "aacc"
 } 
 rule main() = seq{
	call test("a", "b", "c"); 
 }
}


Simple rules

Simple rules include the following elementary ASM control structures:

  • skip: no operation
  • fail: execution is terminated along the given path (with a failure)
  • print(X), println(X): prints term X (simply, or as a separate line). Buffered output can be initiated by print(B, X) and println(B, X), where buffer variable B should be initialized by a previous call to getBuffer/1.
  • log(Sev, X): prints term X to the error log with severity Sev (error, info, warning, debug, fatal)
  • update X = Y, update fun(X) = Y: assigns a new value Y to variable X or ASM function location fun(X)
  • call asmRule(X): calls user-defined ASM rule with actual parameter X
machine simple_rules {
 rule main(in X) = seq {
	skip; 
	print("abc"); 
	log(error, "Error");
	update X = "sec";
 }
}

Composite rules

Back to the top