VirtualBlock Element/en - Versionsgeschichte

Cg: /* When to Use */

2026-04-24T17:44:48Z

When to Use

← Nächstältere Version		Version vom 24. April 2026, 17:44 Uhr
Zeile 3:		Zeile 3:
	A virtual action block is used to specify the interface (number of pins and their [[Datatype\|datatypes]]), but '''not''' its implementation as an action block.		A virtual action block is used to specify the interface (number of pins and their [[Datatype\|datatypes]]), but '''not''' its implementation as an action block.
	It can be placed into a network like any other block.		It can be placed into a network like any other block.

	==When to Use==
	Virtual action steps are useful when different concrete actions are later to be plugged in dynamically.
	For example, assume that you need to read measurement values from devices with different access mechanisms (eg. voltmeters which are accessed via different protocols).
	Then the different concrete mechanisms to read the value are placed into different access libraries, and virtual actions are used in the test project.
	Then dynamically load different libraries (or provide the concrete action via the environment or at the performer pin). This also allows for additional devices to be used in the future.

	==How Does it Work==		==How Does it Work==

Cg: /* How Does it Work */

2026-04-24T17:44:03Z

How Does it Work

← Nächstältere Version		Version vom 24. April 2026, 17:44 Uhr
Zeile 14:		Zeile 14:
	This is done via one of two mechanisms:		This is done via one of two mechanisms:

	==== Explicit, Direct Performer: ====		=== Explicit, Direct Performer: ===

	If the [[DiagramElements-Pin#Performer Input Pin\|performer input pin]] is connected, that pin's value provides a reference to a concrete action. The concrete action must have the virtual action's function ID (fID) specified as its interface.<br>		If the [[DiagramElements-Pin#Performer Input Pin\|performer input pin]] is connected, that pin's value provides a reference to a concrete action. The concrete action must have the virtual action's function ID (fID) specified as its interface.<br>
Zeile 23:		Zeile 23:
	In real-world scenarios, the reference is almost always provided by an environment variable, as described below.		In real-world scenarios, the reference is almost always provided by an environment variable, as described below.

	==== Implicit Performer via a mapping in the Environment: ====		=== Implicit Performer via a mapping in the Environment: ===

	If the performer input pin is not connected, the concrete action is resolved using the dynamic runtime environment, where a mapping from virtual to concrete is expected. The environment must contain either a mapping for the individual action or for a complete [[Virtual Library\|virtual library]].		If the performer input pin is not connected, the concrete action is resolved using the dynamic runtime environment, where a mapping from virtual to concrete is expected. The environment must contain either a mapping for the individual action or for a complete [[Virtual Library\|virtual library]].

Cg: /* Implicit Performer via a mapping in the Environment: */

2026-04-24T17:43:12Z

Implicit Performer via a mapping in the Environment:

← Nächstältere Version		Version vom 24. April 2026, 17:43 Uhr
Zeile 27:		Zeile 27:
	If the performer input pin is not connected, the concrete action is resolved using the dynamic runtime environment, where a mapping from virtual to concrete is expected. The environment must contain either a mapping for the individual action or for a complete [[Virtual Library\|virtual library]].		If the performer input pin is not connected, the concrete action is resolved using the dynamic runtime environment, where a mapping from virtual to concrete is expected. The environment must contain either a mapping for the individual action or for a complete [[Virtual Library\|virtual library]].

	===== Individual Action Mapping: =====		====== Individual Action Mapping: ======

	For this, the environment should contain a mapping from virtual-action-id to concrete action-id. I.e. it must contain a slot where a reference to the virtual action is key, and a reference to the concrete action is the value.		For this, the environment should contain a mapping from virtual-action-id to concrete action-id. I.e. it must contain a slot where a reference to the virtual action is key, and a reference to the concrete action is the value.
	Such mappings cannot be created via the environment editor (as it only creates slots with a string-type namekey), instead, a special block is provided, which creates such a mapping in its surrounding environment.		Such mappings cannot be created via the environment editor (as it only creates slots with a string-type namekey), instead, a special block is provided, which creates such a mapping in its surrounding environment.

	===== Virtual Library Mapping: =====		====== Virtual Library Mapping: ======

	The most convenient way to specify virtual actions is by providing a virtual- to concrete library mapping. For that, a special block is provided, which expects a reference to a virtual library and a reference to a concrete library as inputs. After that mapping has been created, any reference to any virtual block of that library will be resolved using a corresponding concrete block from the concrete library.		The most convenient way to specify virtual actions is by providing a virtual- to concrete library mapping. For that, a special block is provided, which expects a reference to a virtual library and a reference to a concrete library as inputs. After that mapping has been created, any reference to any virtual block of that library will be resolved using a corresponding concrete block from the concrete library.

Cg: /* What is a Virtual Block */

2026-04-24T17:42:17Z

What is a Virtual Block

← Nächstältere Version		Version vom 24. April 2026, 17:42 Uhr
Zeile 4:		Zeile 4:
	It can be placed into a network like any other block.		It can be placed into a network like any other block.

			==When to Use==
⚫	During the execution, [[DiagramElements-Step\|steps]] ~~for~~ virtual ~~actions~~ will determine the real action to be performed ~~dynamically, at execution time~~.
			Virtual action steps are useful when different concrete actions are later to be plugged in dynamically.
			For example, assume that you need to read measurement values from devices with different access mechanisms (eg. voltmeters which are accessed via different protocols).
			Then the different concrete mechanisms to read the value are placed into different access libraries, and virtual actions are used in the test project.
			Then dynamically load different libraries (or provide the concrete action via the environment or at the performer pin). This also allows for additional devices to be used in the future.

			==How Does it Work==
		⚫	During the execution, [[DiagramElements-Step\|steps]] a virtual action's step will dynamically determine the real action to be performed.
	This is done via one of two mechanisms:		This is done via one of two mechanisms:

	==== Explicit, Direct Performer: ====		==== Explicit, Direct Performer: ====

	If the [[DiagramElements-Pin#Performer Input Pin\|performer input pin]] is connected, that pin's value provides a reference to a concrete action. The concrete action must have the virtual action's ID specified as its interface.		If the [[DiagramElements-Pin#Performer Input Pin\|performer input pin]] is connected, that pin's value provides a reference to a concrete action. The concrete action must have the virtual action's function ID (fID) specified as its interface.<br>
	The reference can be provided by another step (dynamically computed), via the environment using an [[DiagramElements-Environment Freeze Value\|environment-freeze value]] or directly as a freeze value. Of course, ~~any~~ environment ~~variables~~ must have been initialized elsewhere before.		The reference can be provided by another step (dynamically computed), via the environment using an [[DiagramElements-Environment Freeze Value\|environment-freeze value]] or directly as a freeze value. Of course, the environment variable must have been initialized elsewhere before.

		⚫	The reference's value can be defined either as an action's fID, or its name. For convenience, actions can be directly dragged from the tree and dropped onto a performer input pin. Obviously, using a constant freeze value as performer-pin input makes the whole virtual mechanism useless, as you could then just place the concrete action. So this is usually only done for testing and demonstration purpose.

⚫	The reference's value can be defined either as ~~the~~ action's ID, or its name. For convenience, actions can be directly dragged from the tree and dropped onto a performer input pin. Obviously, using a constant freeze value as performer-pin input makes the whole virtual mechanism useless, as you could then just place the concrete action. So this is usually only done for testing and demonstration purpose.
	In real-world scenarios, the reference is almost always provided by an environment variable, as described below.		In real-world scenarios, the reference is almost always provided by an environment variable, as described below.

Cg: /* How to use Virtual Blocks */

2020-12-16T15:02:45Z

How to use Virtual Blocks

← Nächstältere Version		Version vom 16. Dezember 2020, 15:02 Uhr
Zeile 50:		Zeile 50:
	# define the virtual block and its pins		# define the virtual block and its pins
	# define a concrete block with the same number of pins having the same data types.		# define a concrete block with the same number of pins having the same data types.
	# copy the virtual blocks ID (either from its documentation-editor tab) or via the copy-ID popup menu function in the element-tree. ~~The~~ paste this ID into the concrete ~~blocks~~ "Interface" field (in the ~~scheme~~-editor-tab). Alternatively, drag & drop a virtual action into this field. This tells expecco, that the concrete action implements that virtual interface.		# copy the virtual blocks ID (either from its documentation-editor tab) or via the copy-ID popup menu function in the element-tree). Then paste this ID into the concrete block's "''Interface''" field (in the schema-editor-tab). Alternatively, drag & drop the virtual action into this field. This tells expecco, that the concrete action implements that virtual interface.
	# place the virtual action as a step into some network. Notice the additional performer pin		# place the virtual action as a step into some network. Notice the additional performer pin
	# create an environment variable to hold the concrete ID		# create an environment variable to hold the concrete ID

Cg: /* When to use Virtual Blocks */

2020-12-16T15:01:19Z

When to use Virtual Blocks

← Nächstältere Version		Version vom 16. Dezember 2020, 15:01 Uhr
Zeile 34:		Zeile 34:
	Use a virtual block, if:		Use a virtual block, if:

	* you have to model a function which is realized using different concrete mechanisms. For example: if multiple communication paths exist to some device, and the one to be used has to be determined dynamically during the test (e.g. connected via USB vs. connected via Serial Line vs. Internet connection).		* you have to model a function which is realized using different concrete mechanisms.
			:For example: if multiple communication paths exist to some device, and the one to be used has to be determined dynamically during the test (e.g. connected via USB vs. connected via Serial Line vs. Internet connection).

	* you have to create a test which has to deal with multiple devices, which use different setups, parameters or protocols. For example: if you have multiple measurement devices in your lab, which require different interface handling, and the test has to determine dynamically, which device is to be used during test execution. This situation is especially common, when expecco is used together with a test automation system, such as expecco ALM, where expecco ALM chooses dynamically which devices are to be used in a test run and passes that information as parameter set.		* you have to create a test which has to deal with multiple devices, which use different setups, parameters or protocols.
			:For example: if you have multiple measurement devices in your lab, which require different interface handling, and the test has to determine dynamically, which device is to be used during test execution. This situation is especially common, when expecco is used together with a test automation system, such as expecco ALM, where expecco ALM chooses dynamically which devices are to be used in a test run and passes that information as parameter set.

	* alternatives are to be configurable by the tester at test-execution time. For example, to select between debug- and non-debug versions of a block, or to select between different test-levels (smoke-test / full-test etc.) and different test-actions are to be performed depending on that choice.		* alternatives are to be configurable by the tester at test-execution time.
			:For example, to select between debug- and non-debug versions of a block, or to select between different test-levels (smoke-test / full-test etc.) and different test-actions are to be performed depending on that choice.

			* you don't know (yet) which UI technology will be needed
			:For example, to write tests before the hardware is available or is even planned. Then place virtual actions into your network and provide a concrete library when the decision is made or the SUT is available.

	==How to use Virtual Blocks==		==How to use Virtual Blocks==

Cg: /* What is a Virtual Block */

2020-12-16T14:57:28Z

What is a Virtual Block

← Nächstältere Version		Version vom 16. Dezember 2020, 14:57 Uhr
Zeile 1:		Zeile 1:
	==What is a Virtual Block==		==What is a Virtual Block==

	A virtual block is used to specify the interface (number of pins and their [[Datatype\|datatypes]]), but '''not''' its implementation as an action block.		A virtual action block is used to specify the interface (number of pins and their [[Datatype\|datatypes]]), but '''not''' its implementation as an action block.
	It can be placed into a network like any other block.		It can be placed into a network like any other block.

Mawalch: title normalization

2018-02-12T18:55:43Z

title normalization

← Nächstältere Version		Version vom 12. Februar 2018, 18:55 Uhr
Zeile 17:		Zeile 17:
	==== Implicit Performer via a mapping in the Environment: ====		==== Implicit Performer via a mapping in the Environment: ====

	If the performer input pin is not connected, the concrete action is resolved using the dynamic runtime environment, where a mapping from virtual to concrete is expected. The environment must contain either a mapping for the individual action or for a complete [[virtual library]].		If the performer input pin is not connected, the concrete action is resolved using the dynamic runtime environment, where a mapping from virtual to concrete is expected. The environment must contain either a mapping for the individual action or for a complete [[Virtual Library\|virtual library]].

	===== Individual Action Mapping: =====		===== Individual Action Mapping: =====

Mawalch am 5. Juni 2017 um 12:01 Uhr

2017-06-05T12:01:00Z

← Nächstältere Version		Version vom 5. Juni 2017, 12:01 Uhr
Zeile 1:		Zeile 1:
	==What is a Virtual Block==		==What is a Virtual Block==

	A virtual block is used to specify the interface (number of pins and their [[Datatype\|datatypes]]), but '''not''' its implementation as an action block.		A virtual block is used to specify the interface (number of pins and their [[Datatype\|datatypes]]), but '''not''' its implementation as an action block.
	It can be placed into a network like any other block.		It can be placed into a network like any other block.

	During the execution, [[DiagramElements-Step\|steps]] for virtual actions will determine the real action to be performed dynamically, st execution time.		During the execution, [[DiagramElements-Step\|steps]] for virtual actions will determine the real action to be performed dynamically, at execution time.
	This is done via one of two mechanisms:		This is done via one of two mechanisms:

	==== Explicit, Direct Performer: ====		==== Explicit, Direct Performer: ====

	If the [[DiagramElements-Pin#Performer Input Pin\|performer input pin]] is connected, that pin's value provides a reference to a concrete action. The concrete action must have the virtual action's ID specified as its interface.		If the [[DiagramElements-Pin#Performer Input Pin\|performer input pin]] is connected, that pin's value provides a reference to a concrete action. The concrete action must have the virtual action's ID specified as its interface.
	The reference can be provided by another step (dynamically computed), via the environment using an [[DiagramElements-Environment Freeze Value\|environment-freeze value]] or directly as a freeze value. Of course, any environment variables must have been initialized elsewhere before.		The reference can be provided by another step (dynamically computed), via the environment using an [[DiagramElements-Environment Freeze Value\|environment-freeze value]] or directly as a freeze value. Of course, any environment variables must have been initialized elsewhere before.

Mawalch: Spelling fixes.

2017-05-18T12:43:12Z

Spelling fixes.

← Nächstältere Version		Version vom 18. Mai 2017, 12:43 Uhr
Zeile 34:		Zeile 34:
	Use a virtual block, if:		Use a virtual block, if:

	* you have to model a function which is realized using different concrete mechanisms. For example: if multiple communication ~~pathes~~ exist to some device, and the one to be used has to be determined dynamically during the test (eg. connected via USB vs. connected via Serial Line vs. Internet connection).		* you have to model a function which is realized using different concrete mechanisms. For example: if multiple communication paths exist to some device, and the one to be used has to be determined dynamically during the test (e.g. connected via USB vs. connected via Serial Line vs. Internet connection).

	* you have to create a test which has to deal with multiple devices, which use different setups, parameters or protocols. For example: if you have multiple measurement devices in your lab, which require different interface handling, and the test has to determine dynamically, which device is to be used during test execution. This situation is especially common, when expecco is used together with a test automation system, such as ~~expeccoALM~~, where ~~expeccoALM~~ chooses dynamically which devices are to be used in a test run and passes that information as parameter set.		* you have to create a test which has to deal with multiple devices, which use different setups, parameters or protocols. For example: if you have multiple measurement devices in your lab, which require different interface handling, and the test has to determine dynamically, which device is to be used during test execution. This situation is especially common, when expecco is used together with a test automation system, such as expecco ALM, where expecco ALM chooses dynamically which devices are to be used in a test run and passes that information as parameter set.

	* alternatives are to be configurable by the tester at test-execution time. For example, to select between debug- and non-debug versions of a block, or to select between different test-levels (smoke-test / full-test etc.) and different test-actions are to be performed depending on that choice.		* alternatives are to be configurable by the tester at test-execution time. For example, to select between debug- and non-debug versions of a block, or to select between different test-levels (smoke-test / full-test etc.) and different test-actions are to be performed depending on that choice.