Konzepte: Unterschied zwischen den Versionen

Aus expecco Wiki (Version 2.x)
Zur Navigation springen Zur Suche springen
(Content is an exact duplicate of Concepts/en. Replace with redirect.)
Zeile 1: Zeile 1:
#REDIRECT[[Concepts/en]]
[[Category:Incomplete]]
[[Category:Work In Progress]]
[[Category:Marked for Deletion]]


[[Category:Temporary short redirect]]
== Introduction ==

=== The Situation ===

Since graphical and interactive modeling came up in computer science, a remarkable number of tools have been developed to facilitate the generative creation of products, especially high-technology products.
For a long period of time, big attention has been turned to the automated '''generation''' of products, but less attention was spent towards the automation of product '''testing''', especially in the development phase (less so in manufacturing).

Classic testing was - and still is - more than often the unstructured sum of multiple individual, partial tests, in most cases performed by the developers themselves, and often inconsequently conducted due to the lack of time. This usually leads to using proprietary testing systems, which in addition are incompletely and sometimes erroneously implemented, and for all aspects of the testing, the collaboration or support of an expert is required.

Today, the steadily increasing complexity of high technology products, together with the continuous shortage of development cycle times, but also the expectations of the customers regarding quality and reliability, let testing become one of the major issues of modern product development. Also the markets for which products are generated are changing - Increasing concurrence and economical challenge raise the need for reusable work. Internationalization and outsourcing bring up new requirements for logistics and communication. Accordingly, also decentralized tests have to be well organized, and a division of the testing process into distinct testing roles becomes indispensable.

=== The Solution ===

The German-based eXept Software AG was one of the first and earliest software companies to take this topic serious and, as a result of many years of development, the expecco system is a professional approach to this issue. Utilizing the newest technologies of the current UML 2.0 standard, and extending them by a set of powerful special features, expecco is the state-of-the-art solution for modeling, executing and evaluating tests efficiently. Using standard interfaces, existing tests and testing systems can easily be embedded into the expecco test workflow on one side, and expecco itself can be embedded in existing frameworks. This allows a seamless integration of expecco into almost any existing infrastructure.

expecco is a modern, element based, modular test and quality ensurance platform, which aims at the consolidation of tests and partial test systems into an automated, interactive test center, and making them accessible to wider person subgroups dependent on their particular role in the test events.

The concept of test modeling introduced by expecco decisively eases the development, execution and evaluation of even most complex test scenarios. This leads to a significant productivity improvement at the creation and maintenance of test scenarios. The integrated versioning of test sequences and test results, the concise library concept, the generally intelligible representation of test scenarios, the wide debug features, and flexible enterprise integration, are additional considerable features.

By introducing different roles for the people involved, it also - and especially - suits complex and distributed test scenarios. The usage of built-in as well as self-defined libraries is the basis for the exchangeability and extensive reuse of your work. Sophisticated standard libraries provide you with the typical elements that are frequently used.

== Overview and Structure of this Document ==

This chapter will give a brief overview on the topical categories of the expecco system, and on the most important terms which apply to them. In the subsequent chapters, each of the mentioned categories will be discussed, explaining each of the according elements individually, as well as the way they are used in cooperation in the expecco System.

=== User Roles ===
Users of expecco may take different ''roles'' during the testing operation. Depending on the project size and other factors, it is both possible that a single person takes any of these roles, or that a group of persons is split and assigned the distinct roles:

* The <span class="KEYWD">'''Coder'''</span> is responsible for the generation of building blocks for the test scenario. These building blocks are typically elementary blocks, which are either programmed explicitly, or which invoke existing procedures of the system under test via some communication mechanism like Shell commands, RPC, SOAP, DLL-calls, Java-method calls etc. Typically, the Coder is a programmer. In many companies, Coders are also part of the product-development team, and they provide low-level interfacing function blocks to the testers in form of a library which is maintained and versioned with the product being developed.
* The <span class="KEYWD">'''Composer'''</span> is creating test scenarios by arranging elementary building blocks into higher level networks of activity diagrams. There is no need for the composer to be a programmer, which does not say, that he often is and the distinction between Coder and Composer roles is always present. Typically, the composer has broad domain knowledge of the system under test, knows typical usage scenarios, has an understanding of possible failures and is well informed about the systems overall requirements.
* The <span class="KEYWD">'''Tester'''</span> is executing tests. Typically, he has to stage the hardware environment of the test, like posing and connecting measurement units and probes, and care for configuration details, such as hostnames, IP addresses, measurement device specifics etc. Very often, the Tester is also the Composer of the test, and often even the Coder.
* The <span class="KEYWD">'''Auditor'''</span> is interpreting test results. He evaluates the test results and generates reports for these results. Typically, the analyzer is the interface to the project-, quality- and product-management.

These user roles are described in detail in the chapter [[ Concepts/en#Architecture and User Roles | "Architecture and User Roles" ]].

=== Dataflow Modeling and Activity Diagrams ===

The expecco System makes use of ''Activity Diagrams'' as they are known from the UML 2.0 standard. Although there are many other possible kinds for process modeling in the UML specification, Activity Diagrams offer the best approach to model ''dataflow'' driven processes. This is a fundamental difference to the other diagram types in the UML specification, which are all more or less controlflow driven.

However, dataflow modeling is the easiest modeling technique for humans to understand, because it resembles most to the way humans use to think and act. The process pattern is divided into distinct blocks, which represent associated subject parts of the process to be modeled. Instances of these blocks are supplied with data, which causes them to execute, and produce resulting data, which can be passed to other block instances or otherwise evaluated. To illustrate this, think of a person that works somewhere in an office: an information is coming in (in his input-basket or todo-list), the person acts due to this information, and supplies the resulting information when the job is done (sends it out via an output basket, email or whatever).

Another important issue in this context is ''parallelism'': Launching activities in a dataflow model is not achieved by explicit calls, instead the presence of the required information is initiating the activity. From a controlflow style diagram, if at all parallelism can be created with it, it is not easy for humans to anticipate the parallelism behavior of the model, especially when the diagram gets more complex. In a dataflow diagram on the other hand, parallel behavior is directly visible and almost always obvious. Using a real world picture, think of parallel execution as having multiple desks, each with its input and output baskets, and multiple workers doing their work on these jobs (tasks).

=== Workflows, Blocks, Steps, Activities ===

The major task to create test scenarios in expecco is the creation of ''Workflows''.
Using the expecco GUI, these Workflows are modeled in the form of <span class="KEYWD">Activity Diagrams</span>, as mentioned before.
activity diagrams are not the only way to create workflows, neither are they the same thing.
While a workflow is an abstract executable network, an activity diagram is a graphical, possibly editable <span class="EMPH">representation</span> of a workflow.
The usual terminology would tell that workflows are made up of so-called <span class="KEYWD">Blocks</span>, but to be more precise, the following distinction has to be made:


* An '"'Action Block"'' (also hereafter often referred to as "block" or "action") is the '''representation and definition''' of an operation (or part of it) to be modeled. Inside an expecco project, blocks are organized in a tree as so-called <span class="KEYWD">Tree Elements</span> (or occasionally "Tree Items"). Blocks are abstract generalizations of activities, i.e. they are never executed directly, instead they provide a '''blueprint for the behavior of activities''' that are spawned from them. Thus an action describes a possible activity. It becomes a real activity, once it is performed.

* A ''"Step"'' is a '''modeling instance''' of an action block. In a workflow, steps are placed and interconnected to model the desired behavior. While blocks are unique objects within a project, '''any number''' of according steps can be embedded in any workflow, each representing an '''individual instance of the block's blueprint'''. The steps inside a workflow mark the spawning points for the activities which are created from the according blocks when the workflow is executed.

* An ''"Activity"'' is a '''concrete executing instance''' of a step, and exists only as long as it is being executed. Multiple activities can be spawned concurrently from the same step or different steps which are associated with the same or different action blocks. Activities are created when a step inside a workflow is being invoked (i.e. activated or triggered).

Since workflows can, in their entireness, also be regarded as assembled blocks, there is a special type of block in expecco which contains such a (sub-)workflow. These so-called ''"Compound Blocks"'' can then in turn be integrated into other workflows. Compound blocks are the key to the unlimited flexibility and reusability of the expecco workflow system. They allow not only to organize, but also to easily re-organize activity patterns, divide existing patterns into partial ones, and even to automatically generate new patterns out of arbitrary subsets of existing ones. This helps to create intuitively associable structures, and to rearrange them with ease whenever needed.

In contrast, the so-called ''"Elementary Blocks"'' do not combine other blocks, but instead are used for basic data processing, and to provide access to the operating system and to the interfaces of the real world. They are needed to exchange information with the testing environment outside the system, e.g. to exchange signals, obtain measurement values, display dialogs, etc. This is achieved either by programmatic, scripting or dll call access, or by remote invocation methods like RPC, SOAP, DCOM, DCE, OLE, or CORBA.

Workflows and activity diagrams are described in detail in the chapter [[Concepts#Workflows and Activity Diagrams|"Workflows and Activity Diagrams"]].

=== Tests, Test Plans, Test Runs, and Test Results ===

A ''"Test Case"'', (or "''Test''" for short) in terms of the expecco system, is a block which can either fail or succeed when executed. A ''"Test Plan"'' is a set of individual tests which are sequentially processed when the test plan is processed. A ''"Test Run"'' designates the execution of a test plan or a single test case, providing tracing and logging information on each step of the execution and an overall result status, called the test's "''verdict''". A verdict is simple OK/not-OK information, whereas a ''"Test Result"'', is the collection of the overall verdict PLUS all individual (sub-)results PLUS the set of collected log messages, tracing data, execution times etc. of a test run.

Test results can be stored either in a database (Oracle, SQL, Access, etc.), or as a standardized XML file or in one of the common formats which are understood by other third party tools (Jenkins, JUnit, CSV/Excel, etc.). This information can be further processed, and be used to generate reports, statistics, etc., which can finally be stored as PDF or HTML viewable files.

Because the desired appearance of a report usually depends on company-specific style guides, these reports are customized in level of detail and graphical appearance via a set of customizable rules. A standard default set of rules is included in the expecco release, either to work with immediately, or as a starting point for your own, personalized reports. In addition, arbitrary transformations are possible for experienced users, by taking the XML report file and processing it via standard XSLT rulesets.

Tests, test plans, test runs, and test results are described in detail in the chapter [[Concepts#Using Elementary Blocks|"Using Elementary Blocks"]].

=== Resources, Skills, Requirements and Inventories ===

Notice: to begin using expecco, you will probably not need to deal with shared resources, skills and inventories and may want to skip this section. It is not required for expecco's operation, but a very useful feature, when your test infrastructure becomes more complex.


In addition to its input data values, a block may also require a set of ''"Resources"'' for its activity to be started. Possible resources could be human operators, machinery, measurement devices, hardware resources or database locks.

To honor the fact that some resources (especially humans) can take different roles, a resource is defined by a set of ''"Skills"''. A skill is a pattern for a particular kind of ability or feature. A block may define a set of ''"Requirements"'' which are necessary for its processing, and an activity can only be spawned from it if enough resources can be allocated to meet the needs hereby defined.

Besides the obvious use of resources to model skills and availability of humans or devices, they can also be very useful for process synchronization. Semaphores, database locks, mutual exclusion and limiting parallel execution can all be easily modeled using resources.

Resources are managed and held by ''"Inventories"''. Whenever an activity is started, the matching resources are allocated (fetched) from the assigned inventory and moved into a temporary inventory, which is held by the activity during execution. When the activity is finished, all allocated resources are returned to the inventory they were taken from.

Inventories form a hierarchy, where sub-inventories allocate resources from a parent inventory. Thus, during test execution, resources are requested from a temporary execution inventory, which requests its resources from a lab inventory, which may even request more resources from a department inventory.

When used in isolation (e.g. without expecco ALM), the maintenance of the inventory is done completely within the executing expecco, and the tester will maintain and configure its contents. However, when used in a department infrastructure, resources must be maintained on a broader scale, to prevent shared (mis-)use when testers start their tests on their personal machine. For this, expecco ALM maintains such inventories and locks non-sharable resources while tests are running.

Resources, skills, requirements and inventories are described in detail in the chapter [[Concepts#Resource Management|"Resource Management"]].

=== Testsuite and Testsuite Elements ===

In expecco, test cases are organized in <span class="KEYWD">Testsuites</span>, which are composed of <span class="KEYWD">Testsuite Elements</span>. You can think of the testsuite elements as the basical units of association when working with expecco: editing a testsuite means editing one or more of its elements. In the expecco GUI, testsuite elements are kept and arranged in the <span class="KEYWD">Element Navigation Tree</span>. There are five categories of testsuite elements:

* For workflow creation, arrangement and execution, the <span class="KEYWD">Block</span> and <span class="KEYWD">Testplan</span> elements are used.
* For embedded test data (which is not provided by external files, databases, web services etc.), the <span class="KEYWD">Attachment</span> element is used.
* For resource management, the <span class="KEYWD">Skill</span>, <span class="KEYWD">Resource</span> and <span class="KEYWD">Inventory</span> elements are used.
* For project organization, the <span class="KEYWD">Group</span>, <span class="KEYWD">Package</span>, <span class="KEYWD">Library</span> and <span class="KEYWD">Documentation</span> elements are used.
* For individual adaptation and extension, the <span class="KEYWD">Datatype</span> and <span class="KEYWD">Class</span> elements are used.

There are no further types of testsuite elements that you need to know. However, some of the listed element types include different specialized subtypes.

Testsuite management concepts are described in detail in the chapter [[Concepts#Testsuites and Testsuite Elements|"Testsuites and Testsuite Elements"]].

== Architecture and User Roles ==

A common truth in the context of the development of complex processes, is that they are ideally characterized by generalization and modularization. The development of test software is no exception to this and good practices well-known in the software development world also apply to the development of tests.

While low-level elements are tested with the built-in means of the language (usually written in the development language by the developers themselves), high-level tests (acceptance, system- and end-to-end tests) are tested by constructing more complex scenarios out of existing building blocks.

A test essentially is a simulation of some real world behavior and checking the System Under Test (SUT) for its correct behavior inside such scenarios. The simulation consists of artificial stimulations (triggering, parameterization, value passing) and the verification of programmed checking (database checks, physical and time measurements, GUI verification).

It is this basical level on which the expecco architecture is based. It's about the dissociation of <span class="EMPH">elementary</span> and <span class="EMPH">compound</span> actions, as the prerequisite for intuitive abstraction and modularization. The SUT is not longer understood just as a surrounding subject, but instead comprehended as a discrete unit, which can be <span class="EMPH">communicated</span> with from inside the integrated testing system.

This view also directly clarifies the question for which types of tests expecco
is applicable: for all test scenarios whose parameters relevant for the evaluation
can be retrieved by use of computers, and whose stimulations required for
the operation can be created by use of computers. In the last consequence,
this can also simply be done by using dialogs, so that in principle, '''any'''
test scenario that is '''evaluatable''' by use of computers,
can be engaged with expecco.

The modeling architecture of expecco is made up of four consecutive levels.
* The first level is the one that connects the system under test to the testing system. At this point, <span class="KEYWD">elementary building blocks</span> come into use, which primarily serve for creating the communicative interfaces between expecco and the testing environment.
* From those, on the second level, abstract <span class="KEYWD">compound building blocks</span> are composed, which in turn can contain both types of building blocks.
* On the third level, <span class="KEYWD">test plans</span> are generated that combine one or more blocks for sequential execution, and which can also be nested (test plan in test plan). When executing, the <span class="KEYWD">test results</span> are generated, which
* on the fourth layer are logged as result files or documents, or can be made available in a database or a QM tool (expecco ALM, Polarion, JIRA, Quality Center etc.)

With expecco, a <span class="KEYWD">top-down</span>- as well as a <span class="KEYWD">bottom-up</span>-creation of tests is possible. With the <span class="KEYWD">bottom-up</span> approach, the basic functionalities for communication with the system under test and the measurement devices are created first. From these basical building blocks, more complex building blocks are then composed. With the <span class="KEYWD">top-down</span> approach, in contrast, the test scenarios are created very early and on high level. This is even possible when the system under test or the interfaces to it do not yet exist. Though such a test scenario can not yet execute, it however documents the system behaviour already in an early project phase, and can serve concurrently as requirement and as documentation.

=== The expecco Role Model ===

The persons involved in the integrated testing environment take different
<span class="KEYWD">roles</span>. Essential for the reasonable division of
the roles is the <span class="KEYWD">black-box concept</span>, which permits
every subject of one of these roles to act independent of the others. Black-box
means, that for the usage of building blocks, not their internal structure,
but only the interface to the outside, has to be known.<BR>

Depending on the extent and complexity of the conceptual formulation, the
roles can also overlap, one person can cover multiple roles, or one role can
be covered by multiple distinct persons. However, the pivotal thing is that
the division of the roles allows a well defined limitation of the required
skills, as well as the competencies of the people involved.

=== The User Roles ===
The following paragraphs describe the four distinct user roles introduced by the expecco system:
&nbsp;

* The Coder Role:<br>The <span class="KEYWD">Coder</span> provides the basic functionalities and interfaces for tests by <span class="EMPH">creating basical building blocks</span> ("<span class="KEYWD">Elementary Blocks</span>", EB). The Coder implements them in programming languages like Smalltalk, Java, C, JavaScript, Perl, Shell, etc. Also direct invocations of existing programs are possible in the form of EBs, on the local platform as well as remotely via RPC, SOAP, DCOM, DCE or CORBA. Preparatively for the Composer, the Coder can also combine EBs into composite building blocks ("<span class="KEYWD">Compound Blocks</span>", CB).
[[Datei:PIC_Concepts_Architecture_UserRoles_Coder.png]]

* The <span class="KEYWD">Composer</span> Role:<br>The <span class="KEYWD">Composer</span> makes use of existing building blocks (like those supplied by the Coder or a library), and <span class="EMPH">generates assembled composite building blocks</span> ("<span class="KEYWD">Compound Blocks</span>", CB) by interconnection of those existing EBs and CBs. They can in turn be combined into more complex CBs or test lists. In a CB, required resources like e.g. measuring devices or personnel can be declared. With top-down development, the Composer will usually define the demands for the Coder by modularization. The Composer solely needs domain knowledge, but usually no special programming proficiency.
[[Datei:PIC_Concepts_Architecture_UserRoles_Composer.png]]

* The <span class="KEYWD">Tester</span> Role:<br>The <span class="KEYWD"></span> conducts test preparations and <span class="EMPH">executes concrete</span> <span class="KEYWD">Test Runs</span>. The preparations typically include the setup of the testing environment, as well as configuration details like IP addresses, measuring unit parameters, etc. The Tester either starts the tests manually, or he enrolls them for time guided execution. Before execution of the test, the system assists the Tester to make available all required resources. <span class="KEYWD">Test Results</span> are displayed to the Tester and in addition stored in a database. The Tester needs domain knowledge only as far as it is necessary for the setup of the testing environment.
[[Datei:PIC_Concepts_Architecture_UserRoles_Tester.png]]

* The <span class="KEYWD">Auditor</span> Role:<br>The <span class="KEYWD">Auditor</span> evaluates the <span class="KEYWD">Test Results</span>, creates statistics and trend analyses, and <span class="EMPH">supplies the evidence of quality</span>. All test data are at the Auditor's disposal in a database, which he can evaluate by means of database tools. He generates <span class="KEYWD">Test Reports</span> out of the collected data, which he typically forwards to the quality-insurance-, project- or product-management. He needs domain knowledge only as far as it is necessary for the understanding of the evaluation.
[[Datei:PIC_Concepts_Architecture_UserRoles_Auditor.png]]

== Testsuites and Testsuite Elements ==

In expecco, test cases are organized in <span class="KEYWD">Testsuites</span>.
An expecco Testsuite consists of its so-called <span class="KEYWD">Testsuite Elements</span>,
or often also shortly called <span class="KEYWD">Elements</span>, and of
<span class="EMPH">nothing more or less</span> than these. Note that the elements
are depicted as free, unbound units, that are not structured in their appearance.
Although the GUI provides a hierarchical view on Testsuite elements, they
are <span class="EMPH">not</span> bound to a hierarchical arrangement. Instead,
an element's <span class="KEYWD">Properties</span> may <span class="EMPH">refer</span>
to other elements, as explained later.

Each expecco Testsuite contains
exactly one <span class="KEYWD">Root Element, which represents the test suite itself</span> [[Bild:PIC_GUI_IconSymbol_ProjectComponent_PackageClosed.png]].
It serves as the <span class="EMPH">base node</span> for all
subsequent structures. The Root element also contains the <span class="KEYWD">Global Variable Environment</span> for the test suite, which can be accessed by any
of the other elements.

=== Element Categories and Types ===

Testsuite elements are of different <span class="KEYWD">types</span>. The different types serve different needs, which can be grouped into distinct topical <span class="KEYWD">categories</span>. These categories are the <span class="EMPH">Workflow Management</span>, the <span class="EMPH">Resource Management</span>, the <span class="EMPH">Testsuite Organization</span> and the <span class="EMPH">Programmatic Modeling</span>.

The following list gives an overview on the elements type categories, briefly explaining the role of each elements type, and introducing the icon which is used for it in the expecco GUI:

* Workflow Management: The elements in this category serve for creation, arrangement and execution of Workflows. The category includes the following elements types:
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_UnspecifiedAction.png]] The <span class="KEYWD">Block elements</span> is the elements type used to contain and to model Workflows and elementary functionalities. There are several different subtypes of this elements type, each having a different icon, but all of those have the same frame as the empty one depicted here (the different subtypes are listed separately below).
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_TestPlan.png]] The <span class="KEYWD">Test Plan Elements</span> is the element type used to model and execute test sequences. A Test Plan can contain references to Block elements, as well as to other Test Plan elements to be processed as nested sub sequences of the superordinate Test Plan.
* Resource Management: The elements in this category serve for definition, assignment / requirement, and housekeeping of Resources. The category includes the following element types:
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Skill.png]] The <span class="KEYWD">Skill Element</span> is the element type used to define and represent a particular type of ability (regarding a resource). Skill elements consist of an attribute list, while the attributes are not assigned any values yet.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Resource.png]] The <span class="KEYWD">Resource Element</span> is the element type used to model and represent a particular real or formal resource. A Resource is defined by a set of Skills, to each of which are given concrete values for the Skill's attributes. The Resource element itself does not yet represent a concrete instance of a resource, but instead serves as a pattern for those instances.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Inventory.png]] The <span class="KEYWD">Inventory Element</span> is the element type used to instantiate and govern concrete instances of Resources. Arbitrary numbers of instances of the according Resource elements can be registered in an Inventory. The Inventory can then be assigned to a Test Plan or other Workflow execution, serving as the pool for the Resources available to the Activities in this execution.
* Testsuite Organization: The elements in this category serve for organization and overall documentation of Testsuite elements. The category includes the following element types:
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Group.png]] The <span class="KEYWD">Group (Folder) Element</span> is the element type used to accumulate elements that are belonging together associatively. The Group element has no other functionality or use other than this. It is the only element that has no element Properties assigned.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_PackageOpened.png]] The <span class="KEYWD">Package Element</span> is the element type used to accumulate Testsuites or Libraries. The Package element is usually created automatically, not by hand. For example, if you include one or more Libraries in your Testsuite, those Libraries will be nested into a self-generated Package named "imports".
** [[Datei:PIC_GUI_IconSymbol_LibraryComponent_PackageClosed.png]] The <span class="KEYWD">Library Element</span> is the Root element of an imported Library (or Testsuite). It does not only serve as a hierarchical root node, but also provides the sub-global Variable Environment for the subject elements in its scope, in the same way as the Root element does it for the Testsuite. Elements below this type cannot be modified or moved, but however can be copied and pasted.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Documentation.png]] The <span class="KEYWD">Documentation Element</span> is the element type used to write down documentation contents that are not bound to a particular Testsuite element. Every element type in expecco already has a Documentation Property (except for the Group element), but each of those Properties is bound to its owning element. The Documentation element is free of this restriction, supplying the Documentation Property as the only one for its type.
* <span class="EMPH">Programmatic Modeling</span>: The elements in this category serve for adaption and creation of proprietary extensions. The category includes the following element types:
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Class.png]] The <span class="KEYWD">Class Element</span> is the element type used to create and represent own or imported programmatical classes. These classes can then be used to introduce according Datatypes, in the same manner as a Datatype can be assigned an existing standard class.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Datatype.png]] The <span class="KEYWD">Datatype Element</span> is the element type used to select additional data types which are not available in the standard default set of provided data types. Datatype elements are referencing to existing, build-in or self-created classes. When a new Datatype is specified, it will from then on be available in all dropdown choosers concerning data types.
* <span class="EMPH">The Block Element Subtypes</span>:The Block element type is the only expecco element type that has specialized <span class="EMPH">subtypes</span>. In the list above, only the abstract Block element type was introduced. The following list shows the concrete subtypes of the Block element type, again briefly explaining the role of each, and introducing the icon which is used for it in the expecco GUI:
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_CompoundAction.png]] The <span class="KEYWD">Compound Block Element</span> is the element type used to contain and model Workflows. Each element of this type contains exactly one so-called <span class="KEYWD">Internal Workflow</span>, also often called the <span class="KEYWD">Internal Network</span> of the Block. There are no further subtypes of the Compound Block element type. All other Block element types are called Elementary Blocks, because in contrast they have no Internal Network, instead implementing elementary functionality blocks.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] The <span class="KEYWD">Smalltalk Code Block Element</span> is the element type used to implement an elementary functionality block in form of Smalltalk style source code. Each element of this type contains exactly one so-called <span class="KEYWD">Code Content</span>, which is interpreted according to the Smalltalk/X syntax at runtime.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] The <span class="KEYWD">JavaScript Code Block Element</span> is the element type used to implement an elementary functionality block in form of JavaScript style source code. Each element of this type contains exactly one so-called <span class="KEYWD">Code Content</span>, which is interpreted according to the JavaScript syntax at runtime.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_ShellScriptAction.png]] The <span class="KEYWD">Shell Script Block Element</span> is the element type used to implement an elementary functionality block in form of Shell Script code. Each element of this type contains exactly one so-called <span class="KEYWD">Script Content</span>, which is interpreted according to a shell or batch script syntax at runtime. Since the content is directly piped to the underlying OS, and is not interpreted by the expecco engine, the executability of the contents depends on the local platform at execution time. The element type also supplies the typical streams from and to the OS process, like <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span>.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_ConsoleCmdAction.png]] The <span class="KEYWD">Console Shell Command Block element</span> is the element type used to implement an elementary functionality block in form of a console command. Each element of this type contains exactly one so-called <span class="KEYWD">Console Command</span> setup, which is executed directly by the underlying OS, as if it had been typed into an OS console window. The executability of the command depends on the local platform at execution time. The element type also supplies the typical streams from and to the OS process, like <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span>.
** [[Datei:PIC_GUI_IconSymbol_ProjectComponent_DataGeneratorAction.png]] The <span class="KEYWD">Test Data Generator Block element</span> is the element type used to supply artificially generated data values during runtime. Its purpose is to substitute data inputs which are not yet, or temporarily not available, to enable the user to however run his tests for trial. Each element of this type contains exactly one so-called <span class="KEYWD">Generic Values List</span>, which takes time-value-pairs that are used at runtime to generate each value at its particular generation time and supply it to the output interface.

=== Including Libraries ===

Besides the possibility to create Testsuite elements on your own, it is
also possible to integrate existing elements from other Testsuites, simply
by <span class="EMPH">importing</span> them as the contents of a <span class="KEYWD">Library</span>.
These elements can then be used inside your own project in the same manner
as those that you created on your own, but it is <span class="EMPH">not possible
to modify</span> those in-lib elements. The reason for this is to keep the
Library’s version consistent, so changing one of the lib’s elements is only
possible when working directly inside its project. However, if desired, you
can still make a copy of an in-lib element, and <span class="EMPH">modify
that copy</span> to fit your needs.

Note that the included Libraries each contain an <span class="EMPH">own</span>
Root element, which is <span class="EMPH">distinct</span> from the current
project’s Root element. Each of those carries an own Variable Environment,
which is thus valid for all - and only - the elements inside the Library’s
scope.

By their nature, Libraries are nothing else than Testsuites: a collection
of Testsuite elements. The differences to a practical Testsuite are as regards
content: While the regular Testsuite aims on provision of concretely executable
items, a Library aims on provision of frequently used standard elements.
On the file system, expecco Libraries usually have the "<span class="CODE">.xlib</span>"
suffix, while Testsuites have the "<span class="CODE">.xprj</span>" suffix.
Technically seen, this is the only difference between them, and you can use
both for import, also your own projects. A Testsuite will be named <span class="CODE">.xlib</span>
only if the author intended it to be a Library.

=== Arranging Elements ===


Usually, you work with the Testsuite and with its elements using the expecco GUI Browser, which displays the elements inside the <span class="KEYWD">Navigation Tree View</span>. This view displays a tree containing all the elements in an arbitrary hierarchical structure. <span class="EMPH">Arbitrary</span> means that the hierarchical arrangement inside the Tree View does <span class="EMPH">not</span> influence the functionalities of the Testsuite or any of its elements <span class="EMPH">in any way</span>. The only reason to supply a hierarchically arrangeable view for the elements, is to allow the user to group and arrange elements according to his subjective associations.

Although the arrangement of the elements is technically
arbitrary, some restrictions have been made to the arrangements
possible in the Tree View. The base node of the tree always
is the Root element of the Testsuite. Furthermore, elements
can <span class="EMPH">only</span> be nested directly below
one of the following element types: <span class="KEYWD">Compound
Blocks</span>, <span class="KEYWD">Test Plans</span>, <span class="KEYWD">Packages</span>,
<span class="KEYWD">Libraries</span>, or <span class="KEYWD">Groups</span>
(which will all be explained later). Below a Compound Block,
for example, usually other Blocks are placed that are used
only or mainly inside that Compound Block, while below a Test
Plan there might be placed other partial Test Plans or Inventories.
A Group, for example, could serve to embrace a group of Skills
and Resources, or Datatypes and Classes. Apart from these
restrictions, you can arrange your elements by free will.

Testsuite elements
have <span class="EMPH">names</span>, which serve to make
them distinguishable for the user. The names are a <span class="EMPH">purely
associative feature</span> for the user. The expecco system
does not need them for operation, neither for distinguishing
the elements from each other. Internally, the expecco system
uses other information to do this: Every Testsuite element
has a unique <span class="EMPH">internal ID</span>, which
is not only unique inside the project, but also <span class="EMPH">world
wide</span>. A special algorithm ensures that two elements
that are not identical will <span class="EMPH">never</span>
have the same internal ID.<BR>

The user usually
doesn’'t get in touch with the internal ID, and it is neither
wanted nor possible by normal means of usage in the expecco
system. Thus, the user <span class="EMPH">must</span> use
the associative names to distinguish the elements. Although
it is possible to give the same name to several distinct elements,
this doesn’t make much sense, because it will only lead to
confusion for the user: When a element is referenced in
another element's Property Editor, it will be labeled with
the associative name rather than with its ID.

[[Bild:PIC_Concepts_Projects_TreeComponents.png]]

=== Element Properties ===
The characteristic contents that make up a element are called the <span class="KEYWD">Element Properties</span>. There are many different types of element properties, but individual element type owns only some of them, according to the kind of element.

It is important at this point to understand the correct meaning of what is
called "Property" here. A Property in the current context does <span class="EMPH">not</span>
mean things like the name, id, or other internal detail. Property here means
a <span class="EMPH">topical unit of information</span> that is characteristic
for the element's <span class="EMPH">purpose</span>, and which is editable
or at least displayable to the user.

A element never has two properties of the same type, and properties are
never shared between elements, i.e. an element property always belongs
to exactly one element only. When duplicating testsuite elements by copy-paste, the duplicate's properties will initially have the same values, but each of the copies will hold its own,
individual set of properties. (technically, the properties of the pasted elements are
deep copies of the copied one's, so modifying a property of a pasted element
will never affect the properties of the source element or other pasted elements).

For each element, one or more <span class="KEYWD">element editor pages</span>
can be opened in the expecco <span class="KEYWD">GUI Browser</span>. A element
Page contains the <span class="KEYWD">Editors</span> appropriate for the element
to which the Page refers, as depicted in Figure
4.4-2. The GUI Editors are used to access and modify the element Properties,
and for each Property type, there is one specialized Editor. Only one of the
Editors is visible at a time in one Page, but Editors can be switched by using
the rider tags on top of the element Page. Changes on a element’s Properties
are accepted or rejected as a whole, so changes in several Editors can be
made before storing its new state. You get detailed information on the GUI
Browser's Page and Editor management in <a href="./DOC_eXpeccoUserGuide_GUI.html#b1f2aa20-f609-11da-9610-0040c7999506">expecco
GUI Documentation/Chapter 3: The GUI Browser Window</a>.


Below, you find a list giving a brief
description of each individual Property type, each containing a link to the
explanation of the according GUI Editor that is used to modify the Property.

===== Documentation Property =====
applies to <span class="EMPH">all</span>
element types, <span class="EMPH">except</span> the <span class="KEYWD">Group</span>
element. It serves to assign each element an individual documentation
text. Accessing this Property through the GUI is described in<br>
the chapter [[expecco GUI Documentation#The Documentation Editor|"The Documentation Editor"]] of the [[expecco GUI Documentation]].

===== Variable Environment Property =====
applies
to <span class="KEYWD">Project</span>, <span class="KEYWD">Library</span>, <span class="KEYWD">Testplan</span> and <span class="KEYWD">Compound Block</span> elements. It serves to create and preset a scoped variable environment which is then accessible by all subordinated block elements. Accessing this Property through the GUI is described in the chapters [[expecco GUI Documentation#The Testsuite Environment Editor|"The Testsuite Environment Editor"]] and [[expecco GUI Documentation#The Block Environment Editor|"The Block Environment Editor"]] of the [[expecco GUI Documentation]].

===== Schema Definition Property =====
applies
to <span class="EMPH">all</span> <span class="KEYWD">Block</span>
element types. It serves to define the data inputs and outputs
of a block element; i.e. its "outside view" when placed as a step into a network. Accessing this property through the GUI
is described in the chapter [[expecco GUI Documentation#The Schema Editor|"The Schema Editor"]] of the [[expecco GUI Documentation]].

===== Internal Network Property =====
applies to <span class="KEYWD">Compound Block</span> elements only.
It serves to model the internal workflow of a compound block by
arranging and interconnecting building blocks called <span class="KEYWD">Steps</span> and Connections.
Accessing this property through the GUI is described in the chapter [[expecco GUI Documentation#The Internal Network Editor|"The Internal Network Editor"]] of the [[expecco GUI Documentation]].

=====Code Content Property =====
applies to <span class="KEYWD">Coded Elementary Block</span> elements only. It serves to contain executable code in a particular programming
language. Accessing this property through the GUI is described
in the chapter [[expecco GUI Documentation#The Program Code Editor|"The Program Code Editor"]] of the [[expecco GUI Documentation]].

====== Script Content Property ======
applies to <span class="KEYWD">Shell Script and Batch Script Block</span> elements.
It serves to contain script code in an OS dependent scripting
language. Accessing this property through the GUI is described
in the chapter [[expecco GUI Documentation#The Script Code Editor|"The Script Code Editor"]] of the [[expecco GUI Documentation]].

====== Console Command Property ======
applies to the <span class="KEYWD">Shell/Batch Command Block</span> elements only.
It serves to contain an OS dependent console command. Accessing this property through the GUI is described in the chapter [[expecco GUI Documentation#The Console Command Editor|"The Console Command Editor"]] of the [[expecco GUI Documentation]].

===== Generic Values List Property =====
applies to <span class="KEYWD">Test Data Generator</span> elements only. It serves to set up a list of typed values, and time
offsets at which those values should be yielded. Accessing this
property through the GUI is described
in the chapter [[expecco GUI Documentation#The Generic Values Editor|"The Generic Values Editor"]] of the [[expecco GUI Documentation]].

===== Local Test Network Property =====
applies to <span class="EMPH">all</span> <span class="KEYWD">Block</span>
elements, <span class="EMPH">except</span> <span class="KEYWD">Test
Data Generator</span> elements. It serves to model and execute
a trial workflow which is held local with the element. Accessing
this property through the GUI is described
in the chapter [[expecco GUI Documentation#The Block Test Editor|"The Block Test Editor"]] of the [[expecco GUI Documentation]].

===== Skill Requirements Property =====
applies to <span class="EMPH">all</span> <span class="KEYWD">Block</span>
elements. It serves to define the set of skills which the block needs for its execution. The resource manager will search for resources which have those skills, allocate and lock them for the execution and finally release them back into the inventory.
Accessing this property through the GUI is
described in the chapter [[expecco GUI Documentation#The Resource Requirement Editor|"The Resource Requirement Editor"]] of the [[expecco GUI Documentation]].

===== Skill Attributes Property =====
applies to the <span class="KEYWD">Skill</span> element Type only. It serves to define the typed attributes that characterize a Skill object.
Accessing this Property through the GUI is described in the chapter [[expecco GUI Documentation#The Skill Definition Editor|"The Skill Definition Editor"]] of the [[expecco GUI Documentation]].

===== Resource Definition (Skill Assignments) Property =====
applies
to the <span class="KEYWD">Resource</span> element type only.
It serves to assign one or more Skills to the Resource element
and concretizing them with typed values. Accessing this Property
through the GUI is described
Accessing this Property through the GUI is described in the chapter [[expecco GUI Documentation#The Resource Definition Editor|"The Resource Definition Editor"]] of the [[expecco GUI Documentation]].

===== Inventory (Resources List) Property =====
applies to
the <span class="KEYWD">Inventory</span> element type only.
It serves to define the set of Resources that the Inventory element
shall contain for disposition on Skill requirement requests. Accessing
this Property through the GUI is described
Accessing this Property through the GUI is described in the chapter [[expecco GUI Documentation#The Inventory Definition Editor|"The Inventory Definition Editor"]] of the [[expecco GUI Documentation]].

===== Testplan (Test Items List) Property =====
applies to
the <span class="KEYWD">Test Plan</span> element type only.
It serves to set up and arrange a sequence of test items, and
provides the execution wrapper to process that sequence. Accessing
this Property through the GUI is described
Accessing this Property through the GUI is described in the chapter [[expecco GUI Documentation#The Testplan Editor|"The Testplan Editor"]] of the [[expecco GUI Documentation]].

===== Class Definition Property =====
applies to
the <span class="KEYWD">Class</span> element type only. It serves
to define the programmatic structure of a Class element.

===== Type Definition Property =====
applies to
the <span class="KEYWD">Datatype</span> element type only. It
serves to select a data type which is not included by default
to be represented by the Datatype element.

== Workflows and Activity Diagrams ==

The peculiarity of expecco is the <span class="KEYWD">Workflow Management</span>, which allows the combination of elementary programmatical elements (working steps) into a composite <span class="KEYWD">Workflow</span>. This is done in form of UML-2.0 compliant, so-called <span class="KEYWD">Activity Diagrams</span>. Activity Diagrams consist of building blocks called the <span class="KEYWD">Steps</span>, and of <span class="KEYWD">Connections</span> which interconnect those Steps with each other. Activity Diagrams are <span class="EMPH">data flow driven</span>, which corresponds most to the way in which humans use to think and act: an <span class="EMPH">input</span> is coming in, causing us to perform some particular <span class="EMPH">activity</span>, which in turn yields a resulting <span class="EMPH">output</span>.

The Steps are depicted as graphical building blocks, which can have so-called <span class="KEYWD">Pins</span>. The Pins serve to <span class="EMPH">interconnect</span> the Steps with each other inside the Activity Diagram. The <span class="KEYWD">Input Pins</span> appear on the left, the <span class="KEYWD">Output Pins</span> on the right side of a building block. Output Pins can be connected to Input Pins by placing <span class="KEYWD">Connections</span> between them.

In this manner, Steps can interactively be assembled to more complex networks. The likewise created building blocks can then in turn be stored as Compound Block elements, and be used as Steps inside other Workflows again. Like this, complex processes can be graphically modelled and modified in an easily understandable manner, and thus get significantly more transparent, maintainable, and flexible.
[[Bild:PIC_Concepts_Workflows_SymbolicActivityDiagram.png]]
<SPAN class="PICTUREENUM">Figure 5-1: Symbolic depiction of an Activity Diagram, consisting of Steps and Connections</SPAN>
[[Bild:PIC_Concepts_Workflows_StepsReferencingComponents.png]]
<SPAN class="PICTUREENUM">Figure 5-2: Steps referencing to Block elements</SPAN>

In an expecco Activity Diagram, Steps are created by drag & drop, i.e. by dragging a Block element from the element Navigation Tree and dropping it to the diagram view of a Workflow Editor. <a href="#15846120-1237-11db-a24a-0040c7999506">Figure 5-2</a> shows the relations between the Steps and the according Block elements: Every Step is referencing <span class="EMPH">exactly one</span> Block element, but multiple Steps can reference the <span class="EMPH">same</span> Block element. Connections are each referencing exactly <span class="EMPH">one</span> Input Pin and exactly <span class="EMPH">one</span> Output Pin.

Steps are <span class="EMPH">representation instances</span> of Block elements. The Steps themselves are not part of the Testsuite elements. While a Block element is a <span class="KEYWD">Testsuite element</span> that exists exactly one time throughout the Testsuite, the Step instances (as well as the Connections) are <span class="KEYWD">Workflow elements</span>. When a Block element is modified, the changes affect all Steps that reference that Block, also those that have been instantiated before the modification.
=== Data Flow Driven Execution ===

<span class="KEYWD">Data flow driven execution</span> means that the invocation of a Step takes place in the moment when the data that is required for execution is present. When invoked, the Step takes the required portion of data from the inputs and launches an <span class="KEYWD">Activity</span> instance that uses those data. Input data can be buffered on the Step's inputs, and on invocation, the Step only fetches the first value from each input, leaving the rest of the queue in the buffer for subsequent invocations.

One of the big advantages of this approach is that you never have to directly implement the creation of Activity instances; this is done <span class="EMPH">implicitly</span> at runtime by passing the input values to the Step. Please keep in mind that invoking a Step does <span class="EMPH">not</span> mean that the Step <span class="EMPH">itself</span> is running. The Step inside the Activity Diagram only serves as a value collector and buffer, and as a <span class="EMPH">spawning point</span> for its Activities.

<a href="#47e3a0e0-10ca-11db-a24a-0040c7999506">Figure 5.1-1</a> symbolically displays the data flow driven execution principle for a Step instance, which for a better overview is isolated from its surrounding Activity Diagram:

The Step is present inside of some Workflow, acting as a spawning point for its Activities. The Step has a data input interface in form of Input Pins to the left, and a data output interface in form of Output Pins to the right.

The Input Pins successively receive input data values, buffering them in a queue on the according Input Pin. Input values are collected and never consumed unless an Activity is launched. As long as not all of the Input Pins relevant for execution obtain a value, no Activity is launched by the Step.

When the set of required values is complete, the Step initializes a new Activity instance for execution. The Activity is created, but not instantly executed. Note that the Activity object is an internal object of the expecco Execution Engine, which is never displayed inside the Activity Diagram.

The Step fetches the data values available on the Input Pins, but only the very first value from every Pin. This set of values is then assigned to the input values of the newly spawned Activity. The other values remain inside the buffering queue, advancing one position in the queuing sequence. E.g., a value that was second in the Pin's queue will advance to first, a third value to second, etc. In addition, the Step sets a reference to itself inside the Activity object, so the Activity knows by which Step instance it had been spawned.

Finally, the spawned Activity is beginning execution, thereby being able to access the values that were previously assigned to it by the Step as a set of values. The Activity operates on the input data and possibly generates new output data, which it can assign to the Step's Output Pins using the previously registered reference to the Step object. The values are then passed to further Steps that are connected to this Step's Output Pins. Although only a fixed set of input values is available to the Activity, it can produce an arbitrary number of output values, provided that at least one Output Pin exists for the Step.

[[Bild:PIC_Concepts_Workflows_DataflowControl.png]]
<SPAN class="PICTUREENUM">Figure 5.1-1: The data flow driven execution principle</SPAN>
[[Bild:PIC_Concepts_Workflows_MultipleActivities.png]]
<SPAN class="PICTUREENUM">Figure 5.1-2: A Step having spawned multiple concurrently running Activities</SPAN>
<a href="#cc9ce4a0-117d-11db-a24a-0040c7999506">Figure 5.1-2</a> shows what to understand under the term "<span class="KEYWD">Parallelism</span>": Steps can spawn new Activities regardless of the execution state of any previously spawned Activities, assumed that parallelism is enabled. Activities spawned by the same Step can execute concurrently without directly influencing each other.

However, it is important to take into account that the output values, generated by different Activities spawned from the same Step, will be passed to the <span class="EMPH">identical</span> Output Pins of that very Step. The order in which the output data values will appear on the Step's Output Pins depends on the points of time when they are yielded. It is possible to <span class="EMPH">limit</span> parallelism individually for each single Step instance, without influencing any other Step referencing to the same Block element.

The next thing that is important to be considered in this context is the way output values are passed along the Connections. In principle, any number of Connections can be assigned to a Pin, irrespectively whether it is an Input or Output Pin.

When an Output Pin has more than one Connection, a value that is yielded on that Output Pin will be copied once for each of the Connections, and one copy is then passed along each Connection. This means that every Input Pin of a Step which is connected to this Output Pin, will receive its individual copy of the yielded value.
[[Bild:PIC_Concepts_Workflows_MultipleOutputConnections.png]]
<SPAN class="PICTUREENUM">Figure 5.1-3: A Step passing an Activity's output value to multiple connected Steps</SPAN>
=== The Schema Definition ===

Every building block inside an expecco Activity Diagram is characterized by its <span class="EMPH">input and output interface</span>, which is specified in its associated Block element's <span class="KEYWD">Schema Definition</span> Property. The Schema Definition consists of an ordered set of <span class="KEYWD">Input</span> and <span class="KEYWD">Output Pin Definitions</span>. Note that it does <span class="EMPH">not</span> consist of Pins directly, because Pins occur on a <span class="KEYWD">Step</span> instance only. The Block element, meanwhile, just holds the Pins' <span class="EMPH">definitions</span>.

According to the black-box concept, the internal implementation of the Block is irrelevant for the integration into a Workflow. You can even embed Steps of a Block which internally is not implemented at all, and make up for the implementation at a later point of time (top-down creation). Meanwhile, you can already use the Block to instantiate Steps in a Workflow, because the data flow interface is already specified. <a href="#cfbea310-0b53-11db-a24a-0040c7999506">Figure 5.2-1</a> shows two exemplary Schema Definition depictions as they appear in the according Editor in the expecco GUI Browser:

To the left, the <span class="KEYWD">Input Pins</span> are specified, the <span class="KEYWD">Output Pins</span> to the right. Every Pin is assigned a <span class="KEYWD">Datatype</span>, which is displayed as a keyword directly besides each Pin, and which determines the kinds of values that can be received, or transmitted, respectively. Each Pin can be given a textual <span class="EMPH">name</span>, which is not only used to describe its purpose for the user, but also serves as the <span class="EMPH">referencing name for value access</span> from inside a Code Block's or Shell Script Block's code.

There are some few Block types that have restrictions on creating or removing Pins: The Shell Script Block and Shell Command Block elements have fixed Pins that can't be modified at all, and the Data Generator Block allows creation of Output Pins only. For all other Block elements, Pins can be freely edited.

[[Bild:PIC_Concepts_Workflows_Basical_Schemes.png]]

<SPAN class="PICTUREENUM">Figure 5.2-1: Two exemplary Schema Definitions as they appear in the expecco Schema Editor</SPAN>

In addition, with the small grey box to the left, an <span class="KEYWD">Triggering Condition Type</span> can be selected. The gating type determines in which way the presence of input values should be evaluated to decide when a Step spawns an Activity: <span class="MENU">AND</span> gating requires <span class="EMPH">all</span> consuming inputs to have a value, <span class="MENU">OR</span> gating requires <span class="EMPH">one or more</span> consuming inputs to have a value, and <span class="MENU">ANDConnected</span> gating requires <span class="EMPH">all connected</span> consuming inputs to have a value.

[[Bild:PIC_Concepts_Workflows_Basical_Network.png]]

<SPAN class="PICTUREENUM">Figure 5.2-2: An exemplary Activity Diagram as it appears in the expecco Workflow Editor</SPAN>

When the Schema is defined, Step instances of the according Block elements can be placed into Activity Diagrams, and interconnected, as depicted in <a href="#fdfe3c90-0b53-11db-a24a-0040c7999506">Figure 5.2-2</a>. The expecco Workflow Editor displays not only the Pins, but also their names inside the building block.

A special type of Pin is available only inside the Activity Diagrams: The various Trigger Pins, used for sequencing, interrupting, limiting or delaying Activity executions. The Trigger Pins are individually switched on or off for each Step instance, and no parameters can be defined for them in the Schema Definition.

In the Schema Editor, additional configuration features are available for the Pins. For example, you can supply a preset value to a Pin, limit the value buffer, set several modes, etc. These settings for the Data Pins are called the <span class="KEYWD">Default Pin Configurations</span> of the Block, which allow the user to assign <span class="EMPH">default values</span> to the parameters of each Pin Configuration.

[[Bild:PIC_Concepts_Workflows_SchemaDefinition_PinSpecials.png]]

<SPAN class="PICTUREENUM">Figure 5.2-3: Appearance of frozen value, unbuffered Output Pin, and non-consuming Input Pin</SPAN>

Every Step uses the Default Pin Configuration of its Block, which, however, can be locally overwritten inside an Activity Diagram. The Pin Configuration settings affect only the behavior of Steps to the outside, it does not affect the internal functionality of a Block or any of its Steps. The below list gives an overview on the adjustable features:

To assign a globally fixed value to an Input Pin, the Pin can be <span class="KEYWD">frozen</span> to that value. A frozen Pin always acts as if the specified value had been received, which is fetched on Activity spawn, but never consumed. When freezing a Pin, a text field is displayed besides it, containing a textual representation of the fixed value. Frozen Input Pins cannot be connected to any Output Pins, and are not taken into account by the Triggering Condition of its Step.

Similar to freezing a Pin to a constant value, Input Pins can also be frozen to an <span class="KEYWD">Environment Variable</span>. While a directly assigned value never changes during runtime, an Environment Variable may change its contents. When a Pin is frozen to an Environment Variable, a spawned Activity will get its current value that it holds in the moment of the Activity's creation.

You can set a limit for the <span class="KEYWD">Basket Buffer size</span> for each Input Pin. The implicit default value for this setting is “unlimited”. The purpose of this setting is to limit the number of values that can be queued on an Input Pin. When the limit is reached, no further values are taken into the queue from any delivering Connection. Depending on the mode of the Output Pin that sent the value, this can cause the yielding Step to cease execution until the value has been removed from the Connection.

For each Input Pin, you can toggle between <span class="KEYWD">consuming</span> and <span class="KEYWD">non-consuming</span> mode. When a consuming Pin obtains a value, this value is taken away from the input queue. A non-consuming Pin leaves the value at the first queue position. Since non-consuming Input Pins would trigger forever, they are implicitly excluded from the Trigger Gating. Consuming Input Pins are displayed as hollow square boxes, while non-consuming Input Pins are displayed as solid squares.

For each Output Pin, you can toggle between <span class="KEYWD">buffered</span> and <span class="KEYWD">unbuffered</span> mode. An unbuffered Output Pin will send a written value <span class="EMPH">immediately</span> to the connected target Pins, while a buffered Pin collects all written values in a <span class="EMPH">queue</span>, which will finally be sequentially sent, but only if the Activity terminates successfully. Buffered Output Pins are displayed as hollow square boxes, while unbuffered Pins are displayed as solid squares.

The Editor used by the expecco GUI Browser to edit Schema Definitions is described in detail in<br> <a href="./DOC_eXpeccoUserGuide_GUI.html#179d0da0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.5: The Schema Editor</a>.

=== Using Activity Diagrams ===

A <span class="KEYWD">Workflow</span> consists of three basical elements: <span class="KEYWD">Steps</span> which have <span class="KEYWD">Pins</span>, and <span class="KEYWD">Connections</span> that interconnect the Pins. The <span class="KEYWD">Activity Diagram</span> displays these elements, and allows the user to arrange and modify them. Steps are displayed as <span class="EMPH">building blocks</span> with the according set of <span class="EMPH">graphical endpoints</span> for the Pins, and Connections are displayed as <span class="EMPH">lines</span> between the Pins’ endpoints.

This chapter describes how Activity Diagrams are structured, and which features apply to the distinct modeling elements. Because the features are numerous, each topical issue is discussed in an individual subchapter. A description of the Editor used to handle Activity Diagrams is available under<br> <a href="./DOC_eXpeccoUserGuide_GUI.html#18c89550-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.10: The Workflow Editor</a>.

==== The Interface Pins ====

There are two types of Workflow Editors in the expecco system, which are almost the same. The only difference between these two variants is that the one type supplies <span class="KEYWD">Interface Pins</span> to the Activity Diagram, while the other one does not. The reason for this is the different purpose of the two variants:

The first variant, called the <span class="KEYWD">Local Test Editor</span>, applies to all Block elements, to Elementary Blocks as well as to Compound Blocks. Its purpose is to allow the user to model one trial network for each Block element, which is kept individually by that element. It supplies a <span class="KEYWD">Test Wrapper</span> object, which embeds the Workflow defined in this editor. Since the Test Wrapper object has no input or output interface, no External Pins are needed.

The second variant, called the <span class="KEYWD">Internal Network Editor</span>, is the one that supplies External Pins to the diagram, which represent the <span class="KEYWD">Interface Pins</span> of the Block. It is only available for Compound Blocks, which hold an <span class="KEYWD">Internal Workflow</span> Property. These Pins are the Interface Pins of the according Schema Definition of the Block. The Block’s Input Pins are displayed on the left side of the Activity Diagram, and act like Output Pins inside of it. Vice versa, the Block’s Output Pins are displayed to the right, and act like Input Pins inside the Diagram. <a href="#e8a5c2b0-1561-11db-9ca4-0040c7999506">Figure 5.3.1-1</a> shows a Compound Block's Interface Pins, as defined in the Schema Definition, appearing as External Pins in the Internal Workflow's Activity Diagram.

[[Bild:PIC_Concepts_Workflows_ActivityDiagrams_InterfacePins.png]]

<SPAN class="PICTUREENUM">Figure 5.3.1-1: A Compound Block's Interface Pins in the Internal Workflow's Activity Diagram (schematic)</SPAN>

Note that inside the Activity Diagram, the Interface Pins have the opposite
behavior as when used from the outside: The Input Interface Pins behave as
Output Pins (because they pass the incoming values from the outside to the
Workflow), and the Interface Output Pins behave as Input Pins (because they
pass the outgoing values from the Workflow to the outside).

Also note that Interface Pins can also be added and deleted directly inside
this Editor, without first having to switch to the Schema Editor. The Interface
Pins' settings can also be edited directly from within the Internal Network
Editor, the context menu for the Interface Pins supplies the identical functionality
as it does in the Schema Definition Editor. However, frozen values are not
displayed here, and the Triggering Condition Type can't be modified from here
either.<BR>

==== Arranging Steps ====

Steps can be added to the Workflow in several ways. The most usual way is to select a Block element in the <span class="KEYWD">element Navigation Tree</span>, and to simply <span class="EMPH">drag</span> its symbol into the Activity Diagram Area. This creates a new Step instance in the Workflow, which is then depicted as a <span class="EMPH">building block</span> with the appropriate Pins in the Activity Diagram. Such a new Step initially has the Pin Configuration specified in the Block's Schema Definition.

[[Bild:PIC_Concepts_Workflows_CreatingSteps.png]]

<SPAN class="PICTUREENUM">Figure 5.3.2-1: Initial Step Creation by Drag & Drop</SPAN>

Another possibility to create Step instances is first to <span class="EMPH">copy</span> an existing Step instance, and then <span class="EMPH">paste</span> it into the same or into another Activity Diagram. Multiple Steps can also be copied at once, and can be pasted as a whole. It is not possible to copy and paste single Connections, but when copying multiple Steps at a time, the Connections which are between them are also copied. This allows to copy and paste <span class="EMPH">complete sub structures</span> of existing Workflows, including all Connections comprised.

[[Bild:PIC_Concepts_Workflows_MovingSteps.png]]

<SPAN class="PICTUREENUM">Figure 5.3.2-2: Positioning Steps</SPAN>

The building blocks can be <span class="EMPH">moved around</span> solely or in groups inside the Activity Diagram. To do so, one or more building blocks are selected, and then dragged to a different location with the mouse. Connections that are inbetween two of the moved building blocks will be moved directly with them, Connections between moved and non-moved building blocks will be rerouted automatically.

To create a <span class="KEYWD">Connection</span> between two Pins, you simply click on one of the Pins, and drag the mouse pointer to the other one. This creates a Connection object in the Workflow which is then displayed as an angled line between the Pins in the Activity Diagram.

Note that you can only interconnect a Data Input Pin to a Data Output Pin, or also a Data Output Pin to some kinds of Trigger Input Pins, depending on the Datatype the Trigger Input Pin expects. A Data Pin Connection can <span class="EMPH">only</span> be created when the Pins' Datatypes are <span class="EMPH">compatible</span>. Usually, you will connect Data Pins which have the <span class="EMPH">identical</span> Datatype adjusted, but there are some special cases where other combinations are possible: Pins holding the "<span class="CODE">Any</span>" Datatype can always be connected to any other Pin (presumed the valid direction), regardless of the Datatype adjusted at the other Pin. In addition, some Datatypes may address different subtypes of itself, like the "<span class="CODE">Number</span>" Datatype, which allows connections to all Pins holding the "<span class="CODE">Number</span>", "<span class="CODE">Integer</span>", or "<span class="CODE">Float</span>" Datatype.

[[Bild:PIC_Concepts_Workflows_CreatingConnections.png]]

<SPAN class="PICTUREENUM">Figure 5.3.2-3: Creating Pin Connections</SPAN>

A more sophisticated way to create new Steps is the possibility to either create new Compound Blocks out of existing Step structures of a Workflow, or to expand the Step structure inside a Compound Block from an existing Step of that Block. In both cases, the selected Steps are removed, and replaced with the according substitute:

When <span class="EMPH">combining</span> Steps, a new Compound Block is created which obtains the selected sub structure as its Internal Workflow, providing a masking Interface Pin for each Pin of the former sub structure that was connected to Pins not comprised in that sub structure. The structure is substituted with a new Step instance of the new Block, and the semi-internal Connections are replaced with Connections to or from the masking Interface Pins. This keeps the connective functionality unchanged, so no further corrections are necessary.

When <span class="EMPH">expanding</span> a Step, no new Block elements are generated. Only Steps that refer to Compound Blocks can be expanded. The Step is removed and replaced by a copy of the according Compound Block's Internal Workflow. The complete Workflow is copied, including all internal Connections between the Steps. Connections to the Interface Pins of the expanded Block are replaced by Connections to those Pins of the target Workflow that previously were connected to the substituted Step.

==== Step Configurations ====

Inside a Workflow, every Step has an individual <span class="KEYWD">Step Configuration</span>. This comprises the <span class="KEYWD">Local Step Configuration</span> for the parameters directly related to the Step instance object, and a set of <span class="KEYWD">Local Pin Configurations</span>, which hold overdubbing parameters for each of the Data Pins. The Step Configuration can be edited inside the Activity Diagram, using the functions provided by the appropriate context menus.

Every Step inside a Workflow holds its individual set of <span class="KEYWD">Local Pin Configurations</span>, which comprise a set of parameters for each of the Pins. In the Schema Definition of a Block, the <span class="KEYWD">Default Pin Configurations</span> for those parameters are specified, which are initially applied to every new Step instance. The Step’s local Pin Configuration starts as an empty Pin Configuration, which can then be filled individually. When local settings are applied to a Data Pin, they <span class="EMPH">overdub</span> the Block’s according Default Pin Configuration settings, without affecting any of the other Steps in any Workflow. When changes are made to the Block's Schema Definition, those are immediately affecting all according Step instances, but however the individual local Pin Configuration remains in effect.

The Schema Editor allows editing of the Triggering Condition Type, the Data Pin Definitions, and the Default Pin Configurations
(left column). The Workflow Editor allows, for each Step, editing of the Local
Step Configuration and the Local Pin Configurations (center column). The effective
Step Configuration is then assembled like this:<br>
# The <span class="EMPH">effective Gating Type</span> is taken directly from the Schema Definition of the Step's Block;
# The <span class="EMPH">effective Step Configuration</span> is taken directly from the Step Definition in the Workflow;<br>
#The <span class="EMPH">effective Pin Configurations</span> are first taken from the Default Pin Configurations of the Schema Definition, but are then overdubbed with the values from the Local Pin Configurations given in the Step Definition of the Workflow.

The Effective Step Configuration determines how input and output values are handled, and under wchich conditions Activities are spawned. The following two paragraphs give an overview on the settings comprised int the Local Step Configuration and the Local Pin Configuration; all of the mentioned Step specific options are accessible through the Step's Context Menu, as described in <a href="./DOC_eXpeccoUserGuide_GUI.html#f46d3890-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.10.4: Step Specific Options (Context Menu)</a>.

The <span class="KEYWD">Local Step Configuration</span> comprises parameters that are directly related to the Step object. Because a Step is a <span class="KEYWD">Workflow element</span>, the only possibility to edit these settings in the GUI is through the Workflow Editor for the Workflow object that contains the Step. The following list gives an overview on the adjustable settings:

Steps can (but don’t have to) carry individual <span class="KEYWD">names</span>. If no name is set for the Step, the headline of the according building block will display the name of the Block only. If a name is set, it is displayed first, followed by a colon and the Block’s name. Like with the Block elements, the name of a Step is a <span class="EMPH">purely organizational feature</span> for the user. The expecco system doesn’t need the names for operation, instead it uses unique internal IDs.

Every Step inside a Workflow can be assigned the <span class="KEYWD">Autostart</span> option. Steps with this option on are started automatically each time the Workflow is executed. This is useful to initially invoke certain Steps which are at the beginning of the data flow, or to invoke Steps that have no Input Pins or are intended to run with frozen input values.

For trial runs that shall overrun certain Exceptions, an <span class="KEYWD">Ignore Exceptions</span> mode is available for each Step. When this option is on, exceptions will be ignored and not lead to a failure signal at runtime.

The <span class="KEYWD">Parallelity Limit</span> option is used to adjust a maximum number for the Activities executed in parallel. When this parameter is set to a number, only that number of Activities will be executed, while later Activities will be created, but not executed until other executing Activities of that Step finish their execution. The created Activities are held on a special stack and are fetched for execution in the sequence of their creation.

The <span class="KEYWD">Separate Process</span> option allows to give every Activity spawned by this Step an own individual OS process.

The functionality of a <span class="KEYWD">Local Pin Configuration</span> is exactly the same as for the <span class="KEYWD">Default Pin Configuration</span>, which is accessible in the Schema Editor. The overdubbing mechanism works on a per-parameter level: When a parameter is set to a value in the Local Pin Configuration, then this value is taken into account for the <span class="KEYWD">Effective Pin Configuration</span>. Parameters for which no value is specified in the Local Pin Configuration will be assigned the value that is given in the Default Pin Configuration. The Pin Configuration affects only the Step's behaviour towards the comprising Workflow, but does <span class="EMPH">not</span> affect the internal functionality. There are four settings for Input Pins, and one setting for Output Pins:

To assign a globally fixed value to an Input Pin, the Pin can be <span class="KEYWD">frozen</span> to that value. A frozen Pin always acts as if the specified value had been received, which is fetched on Activity spawn, but never consumed. When freezing a Pin, a text field is displayed besides it, containing a textual representation of the fixed value. Frozen Input Pins cannot be connected to any Output Pins, and are not taken into account by the Triggering Condition of its Step.

Similar to freezing a Pin to a constant value, Input Pins can also be frozen to an <span class="KEYWD">Environment Variable</span>. While a directly assigned value never changes during runtime, an Environment Variable may change its contents. When a Pin is frozen to an Environment Variable, a spawned Activity will get its current value that it holds in the moment of the Activity's creation.

You can set a limit for the <span class="KEYWD">Basket Buffer size</span> for each Input Pin. The implicit default value for this setting is “unlimited”. The purpose of this setting is to limit the number of values that can be queued on an Input Pin. When the limit is reached, no further values are taken into the queue from any delivering Connection. Depending on the mode of the Output Pin that sent the value, this can cause the yielding Step to cease execution until the value has been removed from the Connection.

For each Input Pin, you can toggle between <span class="KEYWD">consuming</span> and <span class="KEYWD">non-consuming</span> mode. When a consuming Pin obtains a value, this value is taken away from the input queue. A non-consuming Pin leaves the value at the first queue position. Since non-consuming Input Pins would trigger forever, they are implicitly excluded from the Trigger Gating. Consuming Input Pins are displayed as solid square boxes, while non-consuming Input Pins are displayed as hollow squares.

For each Output Pin, you can toggle between <span class="KEYWD">buffered</span> and <span class="KEYWD">unbuffered</span> mode. An unbuffered Output Pin will send a written value <span class="EMPH">immediately</span> to the connected target Pins, while a buffered Pin collects all written values in a <span class="EMPH">queue</span>, which will finally be sequentially sent, but only if the Activity terminates successfully. Buffered Output Pins are displayed as solid square boxes, while unbuffered Pins are displayed as hollow squares.

==== Triggering Condition ====

<span class="KEYWD">Triggering Condition</span> denotes the <span class="EMPH">rule</span> that determines <span class="EMPH">when to invoke</span> a Step. Invoking a Step means spawning an Activity, and comprises creating it, supplying it with the appropriate input values, and putting it to the Activity execution queue. According to the <span class="EMPH">dataflow driven</span> concept of Activity Diagrams, the decision <span class="EMPH">when</span> this is done is usually made referring to the Input Pins' <span class="EMPH">value occupancies</span>.

Depending on the <span class="KEYWD">Gating Type</span>, which can be adjusted in the Schema Editor, and on the effective <span class="KEYWD">Input Pin Configurations</span>, the <span class="EMPH">presence of input values</span> on certain Input Pins decides about the readiness of the Step for being invoked. However, one more input plays a role in this decision: The <span class="KEYWD">Enable Trigger Input Pin</span>, if activated, also has to obtain a value before the Activity instance can be initialized.

In an executing Workflow, the system cyclically performs an <span class="EMPH">occupancy evaluation</span> on each of the Workflow's Step instances, which analyzes the value occupancies of the Data Input Pins according to the adjusted Triggering Condition Type. When the relevant occupancies meet the Gating Type's demands, and the Enable Trigger - if activated - also holds a value, the Step will initialize a new Activity instance.

There is one parameter inside the effective <span class="KEYWD">Input Pin Configuration</span> that plays a role in the evaluation of value occupancies: The <span class="KEYWD">non-consuming/non-triggering</span> mode of the Pin, which can be adjusted in the Schema Editor, and overdubbed for each Step in the Workflow Editor. When this option is off, the occupancy of the according Pin is relevant for the evaluation. If not, the occupancy of that Pin is not taken into account.

Non-consuming inputs are intended to have <span class="EMPH">parametric behaviour</span>. In the terms of Activity Diagrams, this means that the value is not taken from the input queue of the Pin, instead each Activity obtains an individual copy of the value. Like this, the parametric value has to be supplied <span class="EMPH">only once</span> (e.g. by another Step that yields the value on an Output Pin), instead of having to supply it for each invocation. Also, no queue is present for the input values, instead the current value is replaced by a new one as soon as the new value is received by the Pin.

There are three Gating Types available, of which one can be selected at a time, and which is valid for all Steps of the according Block. The most simple one is the <span class="MENU">Or</span> function, which requires <span class="EMPH">only one of the consuming Pins</span> to have a value. The second one, the <span class="MENU">And</span> function, requires <span class="EMPH">all of the consuming Pins</span> to have a value. The third one, the <span class="MENU">AndConnected</span> function, requires <span class="EMPH">all of the connected consuming Pins</span> to have a value; Pins that are not connected are <span class="EMPH">not</span> taken into account. With this function, Pins can remain unconnected, while the <span class="MENU">And</span> function in contrast would cause the Step <span class="EMPH">never</span> to be invoked if one consuming Pin was unconnected. Since the <span class="MENU">AndConnected</span> function is most typically used, it is initially selected in new Block's Schema Definitions.
==== Introducing Triggers ====

Triggers are a means for <span class="KEYWD">synchronisation</span> of Steps in a Workflow Chart. They allow execution gating and intentional serialization, as well as conditional and timelimit dependent canceling. Although regarded theoretically, everything of these could also be done by using only the Data Input/Output Pins, the use of Triggers facilitates handling and structuring of the Workflow, and improves associative overview of the Workflow Chart.

<span class="KEYWD">Trigger Pin Connections</span> are handled in a very similar manner as the Data Pin Connections, and all that is said about the wiring options and display properties of those Connections also applies to the Trigger Pin Connections. Trigger Pins can be selected in the same way as Data Pins are selected, and they use the same Context Menu, although differing in the availability of some entries.

There are five kinds of Trigger Pins, which can be activated and deactivated individually for each Step. The picture to the right shows a sample Step having <span class="EMPH">all possible</span> Trigger Pins activated. All Trigger Pins can be activated and deactivated through the Step's Context Menu.

[[Bild:PIC_GUI_EditorDetail_WorkflowTriggersShowAll.png]]

<SPAN class="PICTUREENUM">Figure 5.3.5-1</SPAN>

On top of the representation box, you see three possible <span class="KEYWD">Trigger Input Pins</span>, which are (from left to right) the <span class="KEYWD">Enable-Input</span>, the <span class="KEYWD">Cancel-Input</span>, and the <span class="KEYWD">Timelimit-Input</span> trigger pin. At its bottom, you see the two possible <span class="KEYWD">Trigger Output Pins</span>, called (from left to right) the <span class="KEYWD">Enable-Output</span>, and the <span class="KEYWD">Exception-Output</span> trigger pin. Most often used is the <span class="KEYWD">Enable-Input/-Output</span> pin pair. Its major use is to determine the activation sequence of (in regard to synchronisation) equitable Steps, or to trigger execution of trailing activities when a superposed activity has finished. The other pins usually serve for exception handling and conditional branching.

Here are some abstract examples for the typical use of the different triggers:

[[Bild:PIC_GUI_EditorDetail_WorkflowTriggersSampleSerial.png]]

<SPAN class="PICTUREENUM">Figure 5.3.5-2</SPAN>

To the left, you can see a typical serialization sequence use case. Notice the two Connections between the <span class="KEYWD">Enable-Trigger</span> pins, the second one selected (red).

However all of the Steps have their inputs supplied with values, only the first Step is launched immediately; when it is finished, it sends an Enable-Trigger signal to the second Step, which is thereupon launched, and when it is finished, it triggers the third Step in turn.

It is possible to automatically serialize Steps with Enable-Triggers, by multiselecting the Steps to be involved, and from the Context Menu, choosing the "<span class="MENU">Sequential Execution</span>" option. This creates the needed Trigger Pins and Connections to build an expectedly sequence.

To the right, you can see some typical canceling / exception handling use cases. To the beginning, all of the Steps are launched at the same time, when getting the Data Input value.

In the case that the first Step fails, its <span class="KEYWD">Exception-Output</span> pin sends a triggering signal to the <span class="KEYWD">Cancel-Input</span> pin of the second Step, causing it to immediately stop execution (if still running), while the third Step would continue execution normally.

If the first Step is terminating successful, however, no signal is sent along the Exception-Output pin, and the second Step would continue execution normally. Instead, an Integer value from a regular Data Output pin would be transmitted to the third Step's <span class="KEYWD">Timelimit-Input</span>, which would then cancel the third Step after that number of seconds.

[[Bild:PIC_GUI_EditorDetail_WorkflowTriggersSampleCancel.png]]

<SPAN class="PICTUREENUM">Figure 5.3.5-3</SPAN>

Trigger Inputs can not only be connected to Trigger Outputs, but also to Data Outputs in some cases, and Trigger Outputs can be connected to Trigger Inputs as well as to Data Inputs in some cases. The following lineup will discuss the possibilities of each trigger type in detail:

The <span class="KEYWD">Enable-Input Pin</span> can be connected to any Trigger or Data Output Pin. There are no restrictions to the Output Pin's Datatype, neither to its buffering state. The Enable-Input Pin will trigger the Step-internal enable flag each time a value is received, but the value itself will not be used. Thus, the Datatype is not relevant.

The <span class="KEYWD">Cancel-Input Pin</span> can be connected to any Trigger or Data Output Pin. There are no restrictions to the Output Pin's Datatype, neither to its buffering state. The Cancel-Input Pin will cancel the execution of any Activities launched from its Step each time a value is received, but the value itself will not be used. Thus, the Datatype is not relevant.

The <span class="KEYWD">Timelimit-Input Pin</span> can only be connected to Data Output Pins of a numeric Datatype (<span class="CODE">Integer</span>, <span class="CODE">Float</span>, or <span class="CODE">Number</span>), or given a preset value of one of those Datatypes. It cannot be connected to the Trigger Output pins. When a value is received, the Timelimit-Input Pin will wait for that number of seconds, and after that it will cancel the execution of any Activities launched from its Step.

The <span class="KEYWD">Enable-Output Pin</span> can only be connected to the Enable-Input and Cancel-Input pin. It sends a trigger signal each time an Activity launched by the Step finishes execution successfully. It is also possible to connect it to a Data Input pin of type "<span class="CODE">Any</span>", but for the average user, this option makes no sense. The usual intention is to use it only with Trigger Input pins.

The <span class="KEYWD">Exception-Output Pin</span> can only be connected to the Enable-Input and Cancel-Input pin. It sends a trigger signal each time an Activity launched by the Step finishes execution with failure. It is also possible to connect it to a Data Input pin of type "<span class="CODE">Any</span>", but for the average user, this option makes no sense. The usual intention is to use it only with Trigger Input pins.

All Trigger Pins can be activated and deactivated through the Step's Context Menu, as described in <a href="./DOC_eXpeccoUserGuide_GUI.html#f46d3890-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.10.4: Step Specific Options (Context Menu)</a>.

==== Workflow Execution ====

Although the Internal Workflow of a Compound Block is modeled inside the <span class="KEYWD">Internal Network Editor</span>, this Editor does <span class="EMPH">not</span> supply any direct execution mechanisms for that Workflow. Instead, the <span class="KEYWD">Local Test Editor</span> is used for modeling trial situations for a particular Block. In the Local Test Editor, Steps of arbitrary Blocks can be combined to a separate Workflow, which can then be executed directly from within that editor. The reason for this extra editor is obvious: While the Internal Network Editor is <span class="EMPH">only</span> intended for the <span class="EMPH">definition</span> of the <span class="KEYWD">Internal Workflow Property</span> of a Compound Block, the Local Test Editor allows to model <span class="EMPH">independent trial Workflows</span>, which don’t affect the Block's own behavior, and which in addition are also available to Elementary Blocks.

In the expecco GUI, there are only two possibilities to execute Workflows: One is through the <span class="KEYWD">Local Test Editor</span>, the other is through the <span class="KEYWD">Test Plan Editor</span>. What both execution models have in common is the <span class="KEYWD">Test Wrapper</span> object. It encapsulates the Workflow to be executed, and serves as the starting point which receives the user's control signals. During execution, Activity Logs are created and kept for later evaluation. In the case of Test Plan executions, the Test Wrapper contains the implicitly generated Workflow as its Internal Workflow Property.

The difference between these two possibilities is, that the Local Test Editor’s Test Wrapper directly <span class="EMPH">wraps the trial Workflow</span> which has been modeled in its Activity Diagram, while the Test Plan Editor’s Test Wrapper <span class="EMPH">wraps a sequence of implicit Steps</span>. The Test Plan Editor does not supply an Activity Diagram. Instead, when a Test Plan is executed in this editor, the according Steps are <span class="EMPH">implicitly created</span>, and automatically sequenced by Enable Triggers. This causes the sequence to stop when one of the spawned Activities fails on execution.

There are two different events that can cause a Step to initialize an Activity: The first is the <span class="KEYWD">Autostart option</span>, which can be set as a Step Configuration parameter inside the according Activity Diagram. When the Autostart option is set for a Step, the Step will initialize exactly one Activity instance each time the comprising Workflow is beginning an execution. The second is the <span class="KEYWD">Input Pin Evaluation</span>, which analyzes the value occupancies of the Data Input Pins according to the adjusted Triggering Condition Type. The Gating Type can be adjusted in the Schema Editor. When the relevant input values meet the Gating Type's demands, and the Enable Trigger - if activated - also holds a value, the Step will initialize a new Activity instance.

It is important to know that <span class="EMPH">initializing</span> an Activity is <span class="EMPH">not</span> the same as <span class="EMPH">executing</span> an Activity. When an Activity is initialized, only the internal object is prepared, and the according set of input values is attached to that object. Execution can however start at a later point of time, depending on parallelity limitation of the Step, and on the Activity's position in the execution queue. This means that the values that the internal functionality of the Activity will work on are the first values present at the Step's Input Pins in the moment of the invocation (= Activity initialization), and changes in the value constitution (especially on the parametric Input Pins) are not recognized by the Activity when its execution starts.

Another important issue when executing Workflows is the so-called <span class="KEYWD">Execution Context</span>, which denotes the <span class="EMPH">executing environment</span> of an Activity. Activities, meanwhile, can only be spawned from Steps, and Steps can only exist inside of Workflows. Executing a Workflow means executing Activities of the Steps inside. This especially affects Compound Block Steps, because these have own Workflows as their internal functionalities. When a Compound Block Step's Activity is executed, it constitutes the Execution Context for all Activities spawned from its internal Steps. The special thing about it is that the Activity not only <span class="EMPH">creates</span> its individual Execution Context, but also <span class="EMPH">inherits</span> the properties of its own encapsulating Execution Context.

There are several items which are concerned in the Execution Context inheritance. First is the <span class="KEYWD">Variable Environment</span>: Each Compound Block defines an own Variable Environment, possibly overdubbing parts or all of the Variable Environment inherited from its encapsulating Execution Context. Second is the <span class="KEYWD">Inventory</span>: Also, each Compound Block defines an own Local Inventory, that may pass Resource Acquirement Requests to the Inventory of its encapsulating Execution Context. Third, but not of great interest to the user, is the internal <span class="EMPH">logging</span> mechanism: Activity Logs are always attached to the superordinate Activity Log instance in their Execution Context after the Activity has finished execution.

=== Using Elementary Blocks ===

<span class="KEYWD">Elementary Blocks</span> provide the <span class="EMPH">basic functionality</span> of an expecco project. They are used to model basical calculation or logical combination units, or to query and control external devices. These can be local or remote processes as well as hardware devices that are attached by some kind of hardware interface.

In contrast to the Compound Block, an Elementary Block does not contain an Internal Workflow Property. Instead, each specialized Elementary Block type has a particular Property according to that type.

==== Code Blocks ====

<DIV ALIGN="LEFT" STYLE="border:0px solid"> The <span class="KEYWD">Code Block element</span> is the element type used to implement an elementary functionality block in form of programmatic <span class="EMPH">source code</span> in a particular <span class="EMPH">programming language</span>. Currently, two syntax patterns are supported: [[Datei:PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction.png]] JavaScript syntax, and [[Datei:PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction.png]] Smalltalk syntax.

Each element of this type contains exactly one <span class="KEYWD">Code Content Property</span>, which holds the <span class="KEYWD">Source Code Text Content</span> that is interpreted according to the used language’s syntax at runtime. It is also possible to <span class="EMPH">switch the syntax pattern</span> for already implemented Code Blocks, causing the code to be automatically converted to that particular syntax style.

The Code Block element type offers all functionalities that are needed to make full programmatic use of the underlying operating system, including access to interfaces, file systems, and other processes, by providing appropriate objects for use inside the code.

Inside the code, the Data Pins of the Block can be directly accessed using the Pin’s name, and used as if they were code variables. A single restriction exists for this access, according to the nature of the Data Pins: Reading values is only possible for the Input Pins’ variables, while writing is only possible for the Output Pins’ variables.

==== Shell Script Blocks ====

The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_ShellScriptAction.png]] <span class="KEYWD">Shell Script Block element</span> is the element type used to implement an elementary functionality block in form of <span class="EMPH">shell script source code</span> in an OS dependent scripting language. The code contents are <span class="EMPH">directly passed</span> to the underlying operating system, so the scope of possible shell or batch script dialects depends on the platform on which the session is running.<br>

Each element of this type contains exactly one <span class="KEYWD">Shell Script Content Property</span>, which holds the <span class="KEYWD">Shell Script Code Text Content</span> that is passed to the operating system at runtime. The features that are available to the script code depend on the used dialect. An Activity of this Block type will only run if the used dialect can be interpreted by the OS. Since the OS interprets the code in a process spawned by expecco, the current OS variable environment of the expecco session also is the initial OS variable environment for the
shell process.<BR>

Inside the code, no direct access to the Data Pins is available. The reason is the nature of the shell and batch execution schema: The according process is running inside a shell, and communicates with the outside via the standard streams <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span>. However, the output of the command can be captured by connecting the according Pins to some evaluating Steps.

The Shell Script Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Script Content Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#181f0ee0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.7: The Script Code Editor</a>.

==== Shell Command Blocks ====

The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_ConsoleCmdAction.png]] <span class="KEYWD">Console Shell Command Block element</span> is the element type used to implement an elementary functionality block in form of a <span class="EMPH">console shell command</span> in an OS dependent manner. The command is <span class="EMPH">directly passed</span> to the underlying operating system, so the scope of possible executables to call depends on the platform on which the session is running.<BR>

Each element
of this type contains exactly one <span class="KEYWD">Console Shell Command Property</span>, which holds the command that is passed to the operating system at runtime. An Activity of this Block type will only run if the specified command can be executed by the OS. Since the OS runs the code in a process spawned by expecco, the current OS variable environment of the expecco session also is the initial OS variable environment
for the shell process.<BR>

For the executing process, no direct access to the Data Pins is available. The reason is the nature of the command execution schema: The according process is running inside a shell, and communicates with the outside via the standard streams <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span>. However, the output of the command can be captured by connecting the according Pins to some evaluating Steps.

The Shell Command Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Script Content Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#185a9140-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.8: The Console Command Editor</a>.<BR>

==== Test Data Generator Blocks ====

The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_DataGeneratorAction.png]] <span class="KEYWD">Test Data Generator Block element</span> is the element type used to <span class="EMPH">supply artificially generated data values</span> to other Steps. This is useful especially for simulating elements that are usually delivering the values, but are not always or not yet available. A second purpose for this Block type is to control the execution flow by yielding time scheduled values.

Each element of this type contains exactly one <span class="KEYWD">Generic Values List Property</span>, which holds a chronologically sorted list of Generic Values Entries. Every entry in that list consists of a Generation Time declaration, and for each Output Pin which is defined in the Block's Schema Definition, possibly one Generic Value. It is not obligatory to assign a Value to every Output Pin per Entry, but if, only one Value per Pin and Entry is possible.

When an Activity of this Block type is started, time is measured by the Activity from that moment on. When an entry’s Generation Time declaration is reached, the according values are sent to the specified Output Pins. The Data Generator Block has no further programmatic or OS specific functions.

The Data Generator Block element has restrictions regarding its Data Pin Definitions. These restrictions are described in <a href="#0b0a0611-17b4-11db-9ca4-0040c7999506">Chapter 5.4.5: Schema Definition Restrictions</a>. Accessing the Generic Values List Property through the GUI is described in <a href="./DOC_eXpeccoUserGuide_GUI.html#189947f0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.9: The Generic Values Editor</a>.


==== Schema Definition Restrictions ====

Unlike the Code Block, the Script and Shell Command Blocks’ <span class="KEYWD">Data Pin Definitions</span> (which are part of the Schema Definition Property) are <span class="EMPH">fixed</span>, i.e. no Data Pins can be added or removed. However, the Pin Configurations can be modified, and preset values can be given to the Input Pins. The fixed set of Pins comprises just the objects and parameters that are involved in a typical shell/batch or console command call:

The <span class="CODE">execDir</span> Input Pin takes a String or Filename object that specifies the base directory to which to change when execution starts, also known as the <span class="EMPH">current directory</span>. Relative paths in Script or Batch files are usually interpreted to be relative to this directory.

The <span class="CODE">command</span> Input Pin is only present at Shell Command Blocks, and takes a String object that specifies the <span class="EMPH">calling path of the executable</span> to be called. If the calling path is given as a relative path, the system will try to find the executable relative to the current directory, as specified with the <span class="CODE">execDir</span> Input Pin.

The <span class="CODE">args</span> InputPin takes a StringCollection representing the execution’s <span class="EMPH">arguments</span>, s they would be specified when calling an analogous script from the command line. While command line arguments are separated by whitespace, the arguments here are passed as a collection of string objects. Thus, unlike in command line calls, no quotation marks are needed as delimiters when whitespace are used inside an argument string.

The <span class="CODE">stdin</span>, <span class="CODE">stdout</span>, and <span class="CODE">stderr</span> Pins represent the shell and batch typical, OS related <span class="EMPH">stdandard i/o streams</span>. However, in this Block type, they are not directly accessible as the stream objects that are used by the operating system. Instead, the String datatype is used, which collects all of the lines in a single string object.

For the <span class="CODE">stdin</span> Input Pin, this means that the all input lines have to be collected <span class="EMPH">in total</span> into a string first and initially passed to the <span class="CODE">stdin</span> Pin for execution. After the Activity is spawned, <span class="EMPH">no further input lines</span> can be supplied to the <span class="CODE">stdin</span> Pin.

For the <span class="CODE">stdout</span> and <span class="CODE">stderr</span> Output Pins, the situation is similar, but still different: By giving values to the <span class="CODE">outNLines</span> and <span class="CODE">errNLines</span> Pins, the block size for each output stream can be adjusted. The block size is the <span class="EMPH">number of lines to collect</span> before the collecting string object is passed to the output pins, and a new collecting string is initialized. If no block size is specified for an output stream, the complete output is collected in a single string object, and not passed until successful termination of the Activity.

The <span class="CODE">result</span> Output Pin delivers the <span class="EMPH">integer return value</span> of the process, which is directly the return value delivered to the caller by the operating system. The meaning of return values differs between platforms, but most usual, a succeeding call delivers a 0, while errors are indicated with a particular number.

An individual restriction applies to the <span class="KEYWD">Data Generator Block</span>: Because no input values are ever needed in this Block type, no Input Pin Definitions can be created in the Block’s Schema Definition. Output Pins can be defined as usual, including assignment of the Datatype and other Output Pin specific settings.

== Test Plans and Test Results ==

The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_TestPlan.png]] <span class="KEYWD">Test Plan element</span> is the element type used to <span class="EMPH">model and execute</span> individual <span class="KEYWD">Test Plans</span>. A Test Plan is a <span class="EMPH">sequence</span> of individual <span class="KEYWD">Test Items</span> that can be executed. A Test Item is either <span class="EMPH">a Block</span> element, or yet another <span class="EMPH">nested Test Plan</span> element. Each element of this type contains exactly one <span class="KEYWD">Test Items List Property</span>, which serves to set up and arrange the sequence of Test Items. When a Test Plan is processed, its Test Items are processed one by one along their arrangement sequence in the Test List.

In the expecco GUI, arrangement and execution of Test Plans are performed in a single editor type, the <span class="KEYWD">Test Plan Editor</span>. This editor provides the editable representation of the <span class="KEYWD">Test Items List</span> Property, as well as the user interface needed to start, halt, stop, or debug the Test Plan’s execution. Accessing the Test Items List Property and executing Test Plans through the GUI is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#1abf5c40-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.17: The Testplan Editor</a>.

=== Test Lists and Test Items ===

Inside the Test Plan Editor, Test Items can be created simply by <span class="EMPH">dragging</span> the desired element from the element Navigation Tree to the Test Items List area in the Test Plan Editor. The dragged element can be either a Block element, or another Test Plan element. When dropping a Test Plan into the Test List, its contents will not be expanded, nor visible. Nested Test Plan items are handled in the same way as the Block element items are.

Inside a Test Plan, Test Items can be individually <span class="EMPH">selected for execution</span>, i.e. included to or excluded from the execution sequence. Additionally, an individual <span class="EMPH">repetition number</span> can be assigned to every Test Item, causing it to be repeated that number of times consecutively. This makes it possible to repeat a single Test Item, without having to create numerous equal Test Item entries.

Only the Blocks on the Test Plan’s <span class="EMPH">own</span> basic level can be seen in the Test Items List. The contents of <span class="EMPH">nested</span> Test Plans can only be modified inside <span class="EMPH">their</span> own Test Items Lists. Thus, it is not possible to directly modify the inclusion or repetition numbers for Test Items that are inside a nested Test Plan.

=== Test Runs and Activity Logs ===

A <span class="KEYWD">Test Run</span> denotes a <span class="EMPH">single execution</span> of a Test Plan. Like for all other Workflow executions, the Test Run also performs by executing Activities.

When an Activity is executed, it locally holds its individual <span class="EMPH">logging information</span>, called its <span class="KEYWD">Activity Log</span>. An Activity Log consists of a chronological list of input and output value events, and of the Notice, Warning, and Error messages that are generated during the Activity's execution.

While a nested Test Plan element is only an <span class="EMPH">organizational</span> part of the containing Test Plan, the Block elements which are embedded make up the <span class="EMPH">functional</span> part of it. However, it would not be precise to say that the “Blocks” were executed; when a Test Plan is about to be executed, an <span class="EMPH">implicit Workflow</span> is created first, which simply creates one Step instance for each included Block in the sequence, and then chains these Steps using Enable Triggers to arrange the modeled sequence.

In addition to the Workflow, a <span class="KEYWD">Test Wrapper</span> object is created. The Test Wrapper is an Activity that <span class="EMPH">embraces and processes</span> the given Test Item sequence. This artificially generated Workflow is then assigned to the Test Wrapper object, which is also created in the beginning of the execution. Items that are not activated for execution will not produce an implicit Step inside the Test Wrapper object’s Internal Workflow. Finally, the Test Wrapper is started and executes the Workflow.

Note that when dropping a Block element to the Test List, the according implicitly generated Step at execution time does <span class="EMPH">never receive any values</span> on its Input Pins. Also, values written to the Output Pins are <span class="EMPH">never received by any other Step</span>. For usual, Blocks that are intended to represent Test Items will be designed without Data Pins, or the Data Pins will serve for assigning frozen values only. For most of the cases, Blocks used to represent Test Items will be Compound Blocks. However, this is not a rule. <span class="EMPH">Any</span> Block element can be placed as a Test Item, and its according Step will be invoked in <span class="EMPH">any case</span>, regardless to the Gating Type and Pin Configuration given in the Block's Schema Definition.

When the Test Plan is executed, for each of its Test Items and their repetitions an Activity is created, which executes the Test Item's internal functionality. During this Test Run, the Test Items List also serves to display the <span class="KEYWD">Activity Tree</span>, which supplies a browseable overview on all Activities that are currently running or already finished. On the Test Plan’s own basic level, <span class="EMPH">only one</span> Activity can be active at a time, because Test Plan execution always performs sequentially. However, there can be multiple concurrently executing sub Activities below a basic level Activity’s node, if the Activity refers to a Compound Block. Inside the Compound Block, <span class="EMPH">no implicit parallelism restrictions</span> are made, so its internal Steps can create concurrent Activities.

The Test Items List does not only allow the <span class="EMPH">arrangement and setup</span> of Test Items, but also displays the according <span class="EMPH">Activity execution states</span> at runtime, as well as their sub Activities, as a hierarchical tree structure. This structure is called the <span class="KEYWD">Activity Tree</span>. In this structure, it is possible to browse to any Activity that started execution in the current Test Run, and to <span class="EMPH">access its logging information</span> by selecting it. This Activity Tree can also be browsed during runtime, making it possible to keep track on the current execution state. When a repetition number is configured for the Test Item, that many Activity entries will appear as sub Activity entries below the Test Item’s node at runtime.

=== Test Results and Test Reports ===

A <span class="KEYWD">Test Result</span> is the <span class="EMPH">ordered set of Activity Logs</span> that was created during a Test Run. Test Results can be stored to the file system or to a database, and can be reloaded for inspection at a later point of time. To prevent Test Results from getting too large, especially when large tests are conducted launching hundreds or thousands of Activities, the maximum number of kept Activity Logs can be limited. When exceeding the limit, Activity Logs of previously executed Activities are deallocated, but only if no errors occurred inside of them. The reason for this is that, when lots of Activities are running, usually no one will be wanting to read all the logging information that was generated from successful Activities. Instead, normally only the erroneous Activities are of interest, and are thus kept in memory until the end of the Test Run.

A <span class="KEYWD">Test Report</span> is a representation of the contents of a Test Result, or of part of it, in the form of a <span class="EMPH">document readable by humans</span>. In expecco, Test Reports can be generated in different <span class="EMPH">output formats</span>. The formats currently supported by expecco are the HTML and PDF formats. Style sheets can also be used to adapt the document to enterprise specific style guides.

When filing out a Test Report, different <span class="EMPH">message categories</span> can be included to or excluded from the output. For example, you could want to only print out error messages, or warnings or notices only, or some kind of combination of these. The Test Result, however, always holds <span class="EMPH">all</span> relevant logging information of the Test Run. When a Test Report is generated, the different message categories which should be comprised in the report can be selected individually, but that does not affect the contents of the Test Result.

== Resource Management ==

<span class="KEYWD">Resources</span> play a significant role in the flow control of automated processes. In particular such tests that require the employment of external hardware, like measuring units, controllers, etc., make the consideration of the availability of resources indispensable. This is valid even more when operations shall be executed in parallel. With the expecco Resource Management, you can register your material allegations, be it devices, materials, persons, or also availabilities of immaterial nature. Because the managed resources do not have to relate to real objects obligatorily, you can also implement abstract limitation structures like semaphores or locks with them.

In expecco, Resources are defined in reference to their <span class="EMPH">abilities</span>, for which we use the term <span class="KEYWD">Skills</span>. Similar to an interface definition, the elementary <span class="KEYWD">Attributes</span> that characterize an ability are summarized in such a Skill object. A <span class="KEYWD">Resource</span> is characterized by a set of such Skills, and concretized by assigning <span class="EMPH">values</span> to the Skill's Attributes.

Resources can then be accumulated into <span class="KEYWD">Inventories</span>, which represent <span class="EMPH">availability sets</span> of Resources. The Inventory object takes care of the distribution and availability of its Resource entries during runtime. Inventories can be assigned to <span class="EMPH">Workflow execution contexts</span>, then offering their Resources to the Activities that run in that context. Activities claim their need for Resources by specifying according <span class="KEYWD">Requirements</span>, and try to reserve an adequate Resource by requesting the Inventory for the according concrete Skills.

The acquisition of Resources, finally, is performed by the <span class="KEYWD">Activities</span> during runtime. For each Block element (except for the Test Data Generator Block), <span class="KEYWD">Skill Requirements</span> can be specified, which will cause an according Activity to request the Inventory of its <span class="KEYWD">Execution Context</span> for Resources that meet the specified demands. An Activity will <span class="EMPH">not</span> execute unless adequate Resources have been reserved, and keeps them reserved until it has finished execution.

A special feature in this context applies to <span class="KEYWD">Compound Blocks</span>: Every Activity that relates to a Compound Block gets its own individual <span class="KEYWD">Local Inventory</span>. Here, a preoccupation of certain amounts of Resources can be configured, and additional Resource instances can be created repeatedly for each of these Activities. The Local Inventory will then be used as the first level Inventory for all sub Activities that run in this Activity's execution context.

When an Activity is created, each Skill Requirement of the according Block's Skill Requirements Property causes a <span class="KEYWD">Resource Acquisition Request</span> to the Execution Context's Inventory. When an Inventory receives such a Resource Acquisition Request, it successively checks all of its available Resources for <span class="EMPH">adequacy</span>, until a fitting Resource instance is found or the end is reached. Adequacy refers to the Skill Requirement that caused the request: The Inventory first looks whether the Resource contains a Skill Assignment that corresponds to the given Skill Requirement, i.e. an Assignment that references the same Skill element as the Requirement does. If so, for each Skill Attribute, the Attribute Comparison is evaluated, using the currently checked Resource's corresponding Attribute Value. If all of the comparisons evaluate to true, the Resource is assumed to be adequate.

If an adequate Resource instance could be found, the Inventory marks it as being acquired by the requesting Activity. If no adequate Resource instance is present or available, the request is passed to the Inventory belonging to the next higher execution context. For Compound Blocks, a restriction can be configured to the request passing when using preallocation: If the same Skill element as that of the request is also registered in the Compound Block's own Skill Requirements, the configured Request Pass-On Mode decides whether the request is passed upwards, or whether the Resource could exclusively be acquired from this Inventory.

=== Defining Skills ===

The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Skill.png]] <span class="KEYWD">Skill element</span> serves to summarize the elementary <span class="KEYWD">Skill Attributes</span> that <span class="EMPH">characterize</span> a Skill. It is important that only the <span class="EMPH">nature</span> of the Skill is defined in the form of its Skill Attributes, but <span class="EMPH">no</span> concrete values are ever assigned directly to the Skill. Later on, one or more Skills can be assigned to a Resource, which is then concretizing them by <span class="EMPH">value assignments</span>. These specifications are taken into account during runtime to decide about the suitability of a Resource for a particular usage purpose.

Each element of this type contains exactly one <span class="KEYWD">Skill Attributes Property</span>, which serves to set up and configure the Skill Attributes. This is done in expecco using the <span class="KEYWD">Skill Definition Editor</span>.

A <span class="KEYWD">Skill Attribute</span> consists of two elements: The <span class="KEYWD">Attribute Name</span>, which serves as the key of association for the user, and the <span class="KEYWD">Attribute Datatype</span>, which determines what kind of value can be assigned to the Attribute. The user can add and remove Skill Attributes, set the Attribute Names, and select the Attribute Datatypes. Internally, the Skill Attributes are ordered as a sequence, which also determines the appearance sequence of the Skill Attributes in other editors when concerned.

Note that the Attribute Name is a <span class="EMPH">purely organizational feature</span> for the user to associate the Attributes to real world's properties. Theoretically, multiple Attributes can have the same name. However, this is not recommended, because it will only lead to confusion for the user.

As mentioned, the Skill Attributes do not get any values assigned. The Skill element serves only as a pattern for concrete abilities. For example, one could define a Skill named "Voltage Measure Range", which could carry Attributes like "Lower Limit" and "Upper Limit". Different real measure devices could have different voltage measure ranges, but however, the same Skill element can be used to classify them. The Resource element is then responsible to concretize the Attributes with values.

In the <span class="KEYWD">Skill Definition Editor</span>, a new Skill Attribute can be created simply by clicking the according button. The editor provides a list with one row for each Skill Attribute. Two of the columns have editable fields, allowing to specify the Attribute Name by typing into a text field, and to select the Attribute Datatype by selecting from a dropdown box.

The Skill Definition Editor is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#19a19030-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.13: The Skill Definition Editor</a>.

=== Defining Resources ===

The [[Datei:PIC_GUI_IconSymbol_ProjectComponent_Resource.png]] <span class="KEYWD">Resource element</span> is used to represent a concrete Resource <span class="EMPH">type</span>. The Resource element itself still does <span class="EMPH">not</span> represent a concrete <span class="EMPH">instance</span> of a Resource; this is achieved in a later step when setting up an Inventory. The Resource element however defines the type of the Resource using <span class="EMPH">concrete values</span>, thereby allowing to specify concrete Resource types, like e.g. a particular measurement unit model, a certain controller type, etc.

Each element of this type contains exactly one <span class="KEYWD">Skill Assignments Property</span>, which serves to set up and concretize the list of Skill Assignments. This is done using the <span class="KEYWD">Resource Definition Editor</span>.

A <span class="KEYWD">Skill Assignment</span> consists of a <span class="KEYWD">Skill Reference</span> to the according Skill element, and of a set of <span class="KEYWD">Skill AttributeValues</span>, one for each Skill Attribute of the referenced Skill. Like this, the Resource is assigned one or more of the Skills that were defined in advance, concretizing them by <span class="EMPH">value assignments</span>. For every Skill Attribute of each Skill, a value is given according to the <span class="KEYWD">Attribute Datatype</span> that was defined for the Skill Attribute. These specifications are taken into account later to decide about the suitability of the Resource for a particular usage purpose.

When a Resource instance is checked for adequacy for a particular Skill Requirement in a Resource Acquisition Request, the Attribute Values defined in the corresponding Skill Assignment are used for comparison against the Requirement's demands. Only if all of the comparisons evaluate to true, the Resource will be assumed adequate to meet the requesting Activity's needs.

In the <span class="KEYWD">Resource Definition Editor</span>, new Skill Assignments can be created simply by <span class="EMPH">dragging</span> a Skill element from the element Navigation Tree to the Skill Assignments List area. Note that only one Skill Assignment entry can be contained in the list for a particular Skill element.

The Resource Definition Editor is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#19e1cd80-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.14: The Resource Definition Editor</a>.

=== Defining Inventories ===

The [[Bild:PIC_GUI_IconSymbol_ProjectComponent_Inventory.png]] <span class="KEYWD">Inventory element</span> serves to represent a set of resources that can be used during a Test Run. An Inventory can be assigned to the context of a Test Run, thus making the Resources that it comprises available to the Activities in the context of the Test Run. One special purpose of Inventories is that when using them, you do not have to define congenerous instances of your resources multiple times. Instead, you can accumulate an arbitrary number of different resources into <span class="KEYWD">Inventories</span> using the <span class="KEYWD">Inventory Editor</span>. By simply assigning an Inventory to a Test Run, you can quickly adjust the flow to the real-world conditions.

Each element of this type contains exactly one <span class="KEYWD">Resources List Property</span>, which serves to compose and set up the Resource Entries. This is done using the <span class="KEYWD">Inventory Definition Editor</span>.

A <span class="KEYWD">Resource Entry</span> consists of three elements: The <span class="KEYWD">Resource Reference</span> to the according Resource element, the <span class="KEYWD">Allocation Block Reference</span>, which specifies a Block of which an Activity shall be executed on <span class="EMPH">allocation</span> of the Resource instance, and the <span class="KEYWD">Release Block Reference</span>, which specifies a Block of which an Activity shall be executed when the Resource instance is <span class="EMPH">released</span>.

Internally, implicit Steps are created for the Allocation and Release Blocks at runtime as the basis for spawning the according Activities. <span class="EMPH">Any</span> Block element type can be used to act as the Allocation or Release Block. However, it has to be taken into account that the according Activities <span class="EMPH">never</span> receive any input values on their Input Data Pins, except frozen or environment values when defined in the Block's Schema Definition. Also, values written to the Output Pins are <span class="EMPH">never</span> received by any other Step.

In the <span class="KEYWD">Inventory Definition Editor</span>, a Resource entry can be created simply by <span class="EMPH">dragging</span> a Resource element from the element Navigation Tree to the Resources List area. Note that the same Resource element can be dragged multiple times to the same Inventory, as well as to other Inventories, each time generating a new Resource entry in the Inventory's Resources List. This is because the Resource element does <span class="EMPH">not</span> designate a <span class="EMPH">concrete</span> object of reality, but instead only describes a particular <span class="EMPH">kind</span> of object, which in turn can exist in reality multiple times.

The Inventory Definition Editor is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#1a205d20-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.15: The Inventory Definition Editor</a>.

=== Defining Resource Requirements ===

Each [[Datei:PIC_GUI_IconSymbol_ProjectComponent_UnspecifiedAction.png]] <span class="KEYWD">Block element</span> - except for the Test Data Generation Block - can be assigned a set of <span class="KEYWD">Skill Requirements</span>, which describe the <span class="EMPH">abilities that have to be met</span> by a Resource to make it suitable for the Block's functionality. Resources are never directly addressed by a Block's Skill Requirements; instead, these define only what Skills a Resource should meet, and the requested Inventory decides about which Resource fits best and will be reserved for the particular Activity.

An Activity that refers to a Block element which has Skill Requirements assigned, will always first try to find and <span class="EMPH">allocate suitable Resource objects</span> in the Inventory of its surrounding context, before it starts its execution. Requirements of Blocks referred to by internal Steps of a Network (be it a user defined or an implicitly generated Network) thereby <span class="EMPH">propagate forward</span> to the top, and allocated resources are not released unless the execution of the Activity has finished. Note that in contrast to the Skill element, a Skill Requirement does <span class="EMPH">not</span> appear as an expecco Testsuite element. Skill Requirements <span class="EMPH">only</span> appear in the Block's Skill Requirement Property.

Each element of this type contains exactly one <span class="KEYWD">Skill Requirements Property</span>, which serves to compose and set up the Skill Requirements. This is done using the <span class="KEYWD">Resource Requirement Editor</span>.

A <span class="KEYWD">Skill Requirement</span> consists of a <span class="KEYWD">Skill Reference</span> to the according Skill element, a set of <span class="KEYWD">Skill Attribute Comparisons</span> with one for each Skill Attribute of the referenced Skill, and an <span class="KEYWD">Acquisition Configuration</span>.

A <span class="KEYWD">Skill Attribute Comparison</span> consists of a <span class="KEYWD">Comparison Operator</span> and a <span class="KEYWD">Comparison Value</span>. The Attribute Comparison is used during runtime to evaluate whether a Resource's Skill Assignment fits the needs of the Skill Requirement, or not.

An <span class="KEYWD">Acquisition Configuration</span> specifies detail on the way how adequate Resources are to be acquired at runtime. For all Block elements, it contains the <span class="KEYWD">Requisition Number</span>, which is the number of adequate Resource instances to be acquired in respect to the particular Skill Requirement. Especially for Compound Blocks, this can be used to reserve a certain number of adequate Resources in advance.

For Compound Blocks only, which have an implicit local Inventory at runtime, two other values can be configured: The <span class="KEYWD">Generation Number</span>, and the <span class="KEYWD">Request Pass-On Mode</span>. The <span class="KEYWD">Generation Number</span> allows to configure <span class="EMPH">implicit creations</span> of Resource instances inside an Activity's local Inventory when the Activity is created. Naturally, this does <span class="EMPH">not</span> make sense when dealing with <span class="EMPH">real</span> objects, because those will not duplicate themselves just because a new Activity is created. It <span class="EMPH">does</span> make sense, however, for abstract immaterial Resources such as <span class="EMPH">semaphores</span> or <span class="EMPH">locks</span>. The <span class="KEYWD">Request Pass-On Mode</span> determines whether, in case that no adequate Resource can be acquired from the local Inventory, the request should be passed on upwards to the next Execution Context's Inventory, or not.

In the <span class="KEYWD">Resource Requirement Editor</span>, Skill Requirements can be created simply by <span class="EMPH">dragging</span> a Skill element from the element Navigation Tree to the Skill Requirements List area. Multiple Skill Requirement entries can be contained in the list for a particular Skill element.

The Resource Requirement Editor is described in detail in <a href="./DOC_eXpeccoUserGuide_GUI.html#1a5f13d0-f60c-11da-9610-0040c7999506">expecco GUI Documentation/Chapter 6.16: The Resource Requirement Editor</a>.

== Variable Environments ==

<span class="KEYWD">Variable Environments</span> provide a means for supplying general - but however scope dependent - variables, as typically known from most computer operating systems like UNIX, Linux, Windows, macOS, etc. The concept of Variable Environments is widely spread and has proven its usefulness throughout the years, and it also is a basic paradigm for most scripting languages, as well as for some programming languages. The interactive modeling environment that expecco constitutes, also supports a corresponding mechanism.

In expecco, Variable Environments can be defined in multiple locations. The first possible location to do so is the <span class="KEYWD">Testsuite element</span>. Because the Testsuite element is the <span class="EMPH">base item</span> of an expecco project, the according Variable Environment acts as the <span class="KEYWD">Global Variable Environment</span> of the project, i.e. it is basically valid for all Activities ever executed throughout the project.

However, the second possible location allows to <span class="EMPH">alter</span> the Environment’s behavior: For every <span class="KEYWD">Compound Block</span> element, an <span class="EMPH">own</span> Variable Environment can be defined. When a Compound Block Activity is created, a <span class="KEYWD">Local Variable Environment</span> is initialized along that definition. This local Environment is then valid for the <span class="KEYWD">Execution Context</span> which this Activity constitutes for its subordinate Activities.

The Environment Variables declared in such a local Environment <span class="EMPH">overdub</span> those of the global one, as well as those of the own encapsulating Execution Context’s local one. The expecco Environments act totally <span class="EMPH">transparent</span> regarding the <span class="EMPH">inherited</span> Variables, i.e. those declared in the superordinate Execution Contexts: If a Variable is accessed which is not declared locally, the Environment <span class="EMPH">passes</span> the access request to the Environment of its own encapsulating Execution Context, and so on. For the Activity itself (and thus also for the user, for instance inside a Code or Script content), the access always appears as if only one Environment was present.

Like this, it is possible to model <span class="EMPH">scoped Variable Environments</span>, which act and behave in the same manner as those used by computer operating systems: They offer the same inheritance mechanism, allow for overwriting and local creation of Variables, and Variable referencing is done by textual keys, allowing them to be accordingly used inside the Code and Shell Script Block elements. In addition, Environment Variables in expecco can be <span class="EMPH">write-protected</span> individually, so Activities can read from, but not write to the protected Variable. Also, writing to an Environment Variable only affects a superordinate Environment if the Variable definition is not locally overdubbed.

One additional option is included in the expecco Environments, which is unique to expecco, and not found in any other Environment conceptions so far: For each Variable inside a Compound Block's Variable Environment, the <span class="EMPH">scope behavior can be inverted</span>. This means that, although a Variable is declared in a Local Variable Environment, the Environment can however prefer to access the Variable of the same name inside its <span class="EMPH">superordinate</span> Environment. The use of this is that you can configure local default values in such a Variable, which are then only used if <span class="EMPH">none</span> of the parental Environments defined a Variable of the same name.

Each Compound Block element as well as the Testsuite element has exactly one <span class="KEYWD">Variable Environment Property</span>, which serves to compose and set up the Environment Variables. This is done using the <span class="KEYWD">Variable Environment Editor</span>.

An <span class="KEYWD">Environment Variable</span> consists of a <span class="KEYWD">Variable Name</span>, which serves as the textual key for accessing the Variable, a <span class="KEYWD">Write Protection</span> flag, which determines write access to the Variable, a <span class="KEYWD">Variable Datatype</span>, determining of what type the Variable's values can be, an <span class="KEYWD">Initialization Mode</span>, specifying how to preset the Variable at the Environment's initialization, and an <span class="KEYWD">Initialization Value</span>, which acts - dependent on the Initialization Mode - either as a fixed value, or as an evaluatable expression that delivers a value.

There is one additional element in the Variable Environment Property, which only applies to Compound Block elements: The <span class="KEYWD">Overdubbing Mode</span> flag, which determines the direction of overdubbing for the Variable. If the flag is set, name resolution tries to find the Variable in the upmost Environment first. If it is not set, name resolution will forward the accessing request to its parental Environments first, and use its own variable only if no resulting Variable instance was delivered.

Version vom 21. Februar 2018, 13:35 Uhr

Weiterleitung nach:


Copyright © 2014-2024 eXept Software AG

Abgerufen von „https://doc.expecco.de/w2.x/index.php?title=Konzepte&oldid=10575“