Tree Elements/en - Versionsgeschichte

Sv: Weiterleitung nach Kategorie:Tree Elements/en erstellt

2014-04-03T08:39:00Z

Weiterleitung nach Kategorie:Tree Elements/en erstellt

Cg: /* Test Data Generator Block */

2014-04-01T16:16:13Z

Test Data Generator Block

← Nächstältere Version		Version vom 1. April 2014, 16:16 Uhr
Zeile 94:		Zeile 94:
	A virtual block is used to place a step whose execution is defined dynamically at runtime. Similar to a virtual function in programming languages, only the block's interface is defined in a network. At execution time, one of multiple concrete actions is choosen to be actually executed.		A virtual block is used to place a step whose execution is defined dynamically at runtime. Similar to a virtual function in programming languages, only the block's interface is defined in a network. At execution time, one of multiple concrete actions is choosen to be actually executed.

	==== [[Test Data Generator Block]] ====		==== [[TestDataGeneratorBlock_Element\|Test Data Generator Block]] ====

	A test data generator block is used to generate simple tabular data for a test.		A test data generator block is used to generate simple tabular data for a test.

Cg: /* Virtual Block */

2014-04-01T16:15:35Z

Virtual Block

← Nächstältere Version		Version vom 1. April 2014, 16:15 Uhr
Zeile 90:		Zeile 90:
	A compound block is a block which is defined by an internal activity diagram. This diagram contains blocks which themself are either elementary or compound. This makes every block highly reusable, as arbitrary complex hierarchies of actions are possible. Semantically, these diagrams are similar to petri nets or UML activity diagrams: the flow of information between blocks is via data flow: outgoing values are forwarded to other blocks via connections. Blocks are activated and executed, whenever its required inputs are arriving.		A compound block is a block which is defined by an internal activity diagram. This diagram contains blocks which themself are either elementary or compound. This makes every block highly reusable, as arbitrary complex hierarchies of actions are possible. Semantically, these diagrams are similar to petri nets or UML activity diagrams: the flow of information between blocks is via data flow: outgoing values are forwarded to other blocks via connections. Blocks are activated and executed, whenever its required inputs are arriving.

	==== [[Virtual Block]] ====		==== [[VirtualBlock_Element\|Virtual Block]] ====

	A virtual block is used to place a step whose execution is defined dynamically at runtime. Similar to a virtual function in programming languages, only the block's interface is defined in a network. At execution time, one of multiple concrete actions is choosen to be actually executed.		A virtual block is used to place a step whose execution is defined dynamically at runtime. Similar to a virtual function in programming languages, only the block's interface is defined in a network. At execution time, one of multiple concrete actions is choosen to be actually executed.

Cg: /* Compound Block */

2014-04-01T16:15:21Z

Compound Block

← Nächstältere Version		Version vom 1. April 2014, 16:15 Uhr
Zeile 86:		Zeile 86:
	Elementary blocks are usually provided by programmers or by eXept, as part of their standard or plugin libraries. They are typically used to implement low-level functionality, helper blocks or communication interfaces which are required by higher level test scenarios. Most of the elementary block's code consists of a few lines of code. The code of elementary blocks is stored within a suite and can be inspected (and even changed) at any time - even during a test suite's execution. There is no need to recompile, link or even shut down the expecco system, when an elementary block's code is changed.		Elementary blocks are usually provided by programmers or by eXept, as part of their standard or plugin libraries. They are typically used to implement low-level functionality, helper blocks or communication interfaces which are required by higher level test scenarios. Most of the elementary block's code consists of a few lines of code. The code of elementary blocks is stored within a suite and can be inspected (and even changed) at any time - even during a test suite's execution. There is no need to recompile, link or even shut down the expecco system, when an elementary block's code is changed.

	==== [[Compound Block]] ====		==== [[CompoundBlock_Element\|Compound Block]] ====

	A compound block is a block which is defined by an internal activity diagram. This diagram contains blocks which themself are either elementary or compound. This makes every block highly reusable, as arbitrary complex hierarchies of actions are possible. Semantically, these diagrams are similar to petri nets or UML activity diagrams: the flow of information between blocks is via data flow: outgoing values are forwarded to other blocks via connections. Blocks are activated and executed, whenever its required inputs are arriving.		A compound block is a block which is defined by an internal activity diagram. This diagram contains blocks which themself are either elementary or compound. This makes every block highly reusable, as arbitrary complex hierarchies of actions are possible. Semantically, these diagrams are similar to petri nets or UML activity diagrams: the flow of information between blocks is via data flow: outgoing values are forwarded to other blocks via connections. Blocks are activated and executed, whenever its required inputs are arriving.

Cg: /* Elementary Block */

2014-04-01T16:14:48Z

Elementary Block

← Nächstältere Version		Version vom 1. April 2014, 16:14 Uhr
Zeile 81:		Zeile 81:
	== Action Blocks ==		== Action Blocks ==

	==== [[Elementary Block]] ====		==== [[ElementaryBlock_Element\|Elementary Block]] ====
	Elementary blocks describe actions which are implemented as low-level primitives. These are either implemented in a scripting programming languge (such as JavaScript, Smalltalk, Shell, Batch, Perl or Ruby) or by calling an existing function written in any language in a DLL or via a remote procedure call (SOAP, XML-RPC, REST etc.).		Elementary blocks describe actions which are implemented as low-level primitives. These are either implemented in a scripting programming languge (such as JavaScript, Smalltalk, Shell, Batch, Perl or Ruby) or by calling an existing function written in any language in a DLL or via a remote procedure call (SOAP, XML-RPC, REST etc.).

Cg: /* Blocks */

2014-04-01T16:14:26Z

Blocks

← Nächstältere Version		Version vom 1. April 2014, 16:14 Uhr
Zeile 79:		Zeile 79:
	Virtual libraries allow for the behavior of a group of actions to be determined and changed at runtime. Similar to abstract functions in an OO-programming language, virtual blocks only define the interface (number and types of pins) of a block, but no concrete implementation. A virtual library is a collection of such virtual blocks. Its components can be used and placed like any other block with a test scenario. However, for execution, a concrete library needs to specified, which contains concrete implementations for every virtual block. The choice of a concrete library can be done statically or even dynamically at execution time (for example, to dynamically determine which communication protocol is required, and associate corresponding implementation blocks at the time the system under test is investigated).		Virtual libraries allow for the behavior of a group of actions to be determined and changed at runtime. Similar to abstract functions in an OO-programming language, virtual blocks only define the interface (number and types of pins) of a block, but no concrete implementation. A virtual library is a collection of such virtual blocks. Its components can be used and placed like any other block with a test scenario. However, for execution, a concrete library needs to specified, which contains concrete implementations for every virtual block. The choice of a concrete library can be done statically or even dynamically at execution time (for example, to dynamically determine which communication protocol is required, and associate corresponding implementation blocks at the time the system under test is investigated).

	== Blocks ==		== Action Blocks ==

	==== [[Elementary Block]] ====		==== [[Elementary Block]] ====

Cg: /* Common Attributes of all Tree Items */

2014-04-01T16:13:39Z

Common Attributes of all Tree Items

← Nächstältere Version		Version vom 1. April 2014, 16:13 Uhr
Zeile 4:		Zeile 4:
	== Common Attributes of all Tree Items ==		== Common Attributes of all Tree Items ==

	=== Name ===		==== Name ====

	You can give tree items an arbitrary name. This name is not used within expecco for referencing to an item (see "IDs"-Section below). Thus, you can change the name of any item at any time without a need to search for uses of the item.		You can give tree items an arbitrary name. This name is not used within expecco for referencing to an item (see "IDs"-Section below). Thus, you can change the name of any item at any time without a need to search for uses of the item.
	The name can be further translated by a model language translation table, so that both the user interface of expecco and the names attached to items are translated. This makes it possible to present the same model to team users speaking different languages.		The name can be further translated by a model language translation table, so that both the user interface of expecco and the names attached to items are translated. This makes it possible to present the same model to team users speaking different languages.

	=== IDs ===		==== IDs ====

	Each element in the project has two special IDs (Identifiers). One is the so called "Functional-ID" which is assigned once, when the element is created initially and never changed thereafter. The other is the "Version-ID". This is reassigned with every modification. Inside expecco, elements are referred to by their ID, not by name. This makes it easy to change the name at any time later without a need to change other parts of the suite.		Each element in the project has two special IDs (Identifiers). One is the so called "Functional-ID" which is assigned once, when the element is created initially and never changed thereafter. The other is the "Version-ID". This is reassigned with every modification. Inside expecco, elements are referred to by their ID, not by name. This makes it easy to change the name at any time later without a need to change other parts of the suite.
Zeile 19:		Zeile 19:
	The name of a tree element is not used by the system to identity elements; this is only used for presentation to the user.		The name of a tree element is not used by the system to identity elements; this is only used for presentation to the user.

	=== Tags ===		==== Tags ====

	Symbolic tags can be attached to tree elements. The main use of a tag is to group items by function and make finding items in search boxes easier (the search functions provide a check box to enable/disable search by tag). In addition, tags can be used to filter tests for execution or to associate colors. For example, the diagram settings dialog allows for particular colors to be attached to particular tags. You can use this to mark critical, obsolete, input/output related or other items by color both in the tree and in activity diagrams.		Symbolic tags can be attached to tree elements. The main use of a tag is to group items by function and make finding items in search boxes easier (the search functions provide a check box to enable/disable search by tag). In addition, tags can be used to filter tests for execution or to associate colors. For example, the diagram settings dialog allows for particular colors to be attached to particular tags. You can use this to mark critical, obsolete, input/output related or other items by color both in the tree and in activity diagrams.

Cg: /* Tests */

2014-04-01T16:13:22Z

Tests

← Nächstältere Version		Version vom 1. April 2014, 16:13 Uhr
Zeile 23:		Zeile 23:
	Symbolic tags can be attached to tree elements. The main use of a tag is to group items by function and make finding items in search boxes easier (the search functions provide a check box to enable/disable search by tag). In addition, tags can be used to filter tests for execution or to associate colors. For example, the diagram settings dialog allows for particular colors to be attached to particular tags. You can use this to mark critical, obsolete, input/output related or other items by color both in the tree and in activity diagrams.		Symbolic tags can be attached to tree elements. The main use of a tag is to group items by function and make finding items in search boxes easier (the search functions provide a check box to enable/disable search by tag). In addition, tags can be used to filter tests for execution or to associate colors. For example, the diagram settings dialog allows for particular colors to be attached to particular tags. You can use this to mark critical, obsolete, input/output related or other items by color both in the tree and in activity diagrams.

	== ~~Tests~~ ==		== Test Items ==
	[[Bild:Tree_Elements.PNG\|thumb\|164px\|All tree elements]]		[[Bild:Tree_Elements.PNG\|thumb\|164px\|All tree elements]]

Cg: /* Tags */

2014-04-01T16:13:03Z

Cg: /* IDs */

2014-04-01T16:12:44Z

IDs

← Nächstältere Version		Version vom 1. April 2014, 16:12 Uhr
Zeile 2:		Zeile 2:
	Tree elements are all elements in a [[Testsuite\|testsuite]]. They are displayed and managed in the so-called project tree, which is shown on the left of the expecco application.		Tree elements are all elements in a [[Testsuite\|testsuite]]. They are displayed and managed in the so-called project tree, which is shown on the left of the expecco application.

			== Common Attributes of all Tree Items ==
⚫	== IDs ==

			=== Name ===

			You can give tree items an arbitrary name. This name is not used within expecco for referencing to an item (see "IDs"-Section below). Thus, you can change the name of any item at any time without a need to search for uses of the item.
			The name can be further translated by a model language translation table, so that both the user interface of expecco and the names attached to items are translated. This makes it possible to present the same model to team users speaking different languages.

		⚫	=== IDs ===

	Each element in the project has two special IDs (Identifiers). One is the so called "Functional-ID" which is assigned once, when the element is created initially and never changed thereafter. The other is the "Version-ID". This is reassigned with every modification. Inside expecco, elements are referred to by their ID, not by name. This makes it easy to change the name at any time later without a need to change other parts of the suite.		Each element in the project has two special IDs (Identifiers). One is the so called "Functional-ID" which is assigned once, when the element is created initially and never changed thereafter. The other is the "Version-ID". This is reassigned with every modification. Inside expecco, elements are referred to by their ID, not by name. This makes it easy to change the name at any time later without a need to change other parts of the suite.