Concepts/en

Aus expecco Wiki (Version 2.x)
(Weitergeleitet von Concepts)
Wechseln zu: Navigation, Suche


Inhaltsverzeichnis

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 Coder 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 Composer 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 Tester 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 Auditor 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 "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 Activity Diagrams, 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 representation of a workflow. The usual terminology would tell that workflows are made up of so-called Blocks, 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 Tree Elements (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 "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 "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 "Resource Management".

Testsuite and Testsuite Elements

In expecco, test cases are organized in Testsuites, which are composed of Testsuite Elements. 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 Element Navigation Tree. There are five categories of testsuite elements:

  • For workflow creation, arrangement and execution, the Block and Testplan elements are used.
  • For embedded test data (which is not provided by external files, databases, web services etc.), the Attachment element is used.
  • For resource management, the Skill, Resource and Inventory elements are used.
  • For project organization, the Group, Package, Library and Documentation elements are used.
  • For individual adaptation and extension, the Datatype and Class 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 "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 elementary and compound 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 communicated 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, elementary building blocks come into use, which primarily serve for creating the communicative interfaces between expecco and the testing environment.
  • From those, on the second level, abstract compound building blocks are composed, which in turn can contain both types of building blocks.
  • On the third level, test plans 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 test results 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 top-down- as well as a bottom-up-creation of tests is possible. With the bottom-up 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 top-down 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 roles. Essential for the reasonable division of the roles is the black-box concept, 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.

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. </p>

The User Roles

The following paragraphs describe the four distinct user roles introduced by the expecco system:  

  • The Coder Role:
    The Coder provides the basic functionalities and interfaces for tests by creating basical building blocks ("Elementary Blocks", 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 ("Compound Blocks", CB).

PIC Concepts Architecture UserRoles Coder.png

  • The Composer Role:
    The Composer makes use of existing building blocks (like those supplied by the Coder or a library), and generates assembled composite building blocks ("Compound Blocks", 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.

PIC Concepts Architecture UserRoles Composer.png

  • The Tester Role:
    The conducts test preparations and executes concrete Test Runs. 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. Test Results 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.

PIC Concepts Architecture UserRoles Tester.png

  • The Auditor Role:
    The Auditor evaluates the Test Results, creates statistics and trend analyses, and supplies the evidence of quality. All test data are at the Auditor's disposal in a database, which he can evaluate by means of database tools. He generates Test Reports 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.

PIC Concepts Architecture UserRoles Auditor.png

Testsuites and Testsuite Elements

In expecco, test cases are organized in Testsuites. An expecco Testsuite consists of its so-called Testsuite Elements, or often also shortly called Elements, and of nothing more or less 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 not bound to a hierarchical arrangement. Instead, an element's Properties may refer to other elements, as explained later.

Each expecco Testsuite contains exactly one Root Element, which represents the test suite itself PIC GUI IconSymbol ProjectComponent PackageClosed.png. It serves as the base node for all subsequent structures. The Root element also contains the Global Variable Environment for the test suite, which can be accessed by any of the other elements.

Element Categories and Types

Testsuite elements are of different types. The different types serve different needs, which can be grouped into distinct topical categories. These categories are the Workflow Management, the Resource Management, the Testsuite Organization and the Programmatic Modeling.

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:
    • PIC GUI IconSymbol ProjectComponent UnspecifiedAction.png The Block elements 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).
    • PIC GUI IconSymbol ProjectComponent TestPlan.png The Test Plan Elements 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:
    • PIC GUI IconSymbol ProjectComponent Skill.png The Skill Element 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.
    • PIC GUI IconSymbol ProjectComponent Resource.png The Resource Element 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.
    • PIC GUI IconSymbol ProjectComponent Inventory.png The Inventory Element 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:
    • PIC GUI IconSymbol ProjectComponent Group.png The Group (Folder) Element 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.
    • PIC GUI IconSymbol ProjectComponent PackageOpened.png The Package Element 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".
    • PIC GUI IconSymbol LibraryComponent PackageClosed.png The Library Element 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.
    • PIC GUI IconSymbol ProjectComponent Documentation.png The Documentation Element 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.
  • Programmatic Modeling: The elements in this category serve for adaption and creation of proprietary extensions. The category includes the following element types:
    • PIC GUI IconSymbol ProjectComponent Class.png The Class Element 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.
    • PIC GUI IconSymbol ProjectComponent Datatype.png The Datatype Element 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.
  • The Block Element Subtypes:The Block element type is the only expecco element type that has specialized subtypes. 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:
    • PIC GUI IconSymbol ProjectComponent CompoundAction.png The Compound Block Element is the element type used to contain and model Workflows. Each element of this type contains exactly one so-called Internal Workflow, also often called the Internal Network 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.
    • PIC GUI IconSymbol ProjectComponent SmalltalkAction.png The Smalltalk Code Block Element 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 Code Content, which is interpreted according to the Smalltalk/X syntax at runtime.
    • PIC GUI IconSymbol ProjectComponent JavaScriptAction.png The JavaScript Code Block Element 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 Code Content, which is interpreted according to the JavaScript syntax at runtime.
    • PIC GUI IconSymbol ProjectComponent ShellScriptAction.png The Shell Script Block Element 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 Script Content, 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 stdin, stdout, and stderr.
    • PIC GUI IconSymbol ProjectComponent ConsoleCmdAction.png The Console Shell Command Block element 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 Console Command 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 stdin, stdout, and stderr.
    • PIC GUI IconSymbol ProjectComponent DataGeneratorAction.png The Test Data Generator Block element 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 Generic Values List, 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 importing them as the contents of a Library. 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 not possible to modify 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 modify that copy to fit your needs. </p>

Note that the included Libraries each contain an own Root element, which is distinct 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 ".xlib" suffix, while Testsuites have the ".xprj" 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 .xlib only if the author intended it to be a Library. </p>

Arranging Elements

Usually, you work with the Testsuite and with its elements using the expecco GUI Browser, which displays the elements inside the Navigation Tree View. This view displays a tree containing all the elements in an arbitrary hierarchical structure. Arbitrary means that the hierarchical arrangement inside the Tree View does not influence the functionalities of the Testsuite or any of its elements in any way. 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 only be nested directly below one of the following element types: Compound Blocks, Test Plans, Packages, Libraries, or Groups (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 names, which serve to make them distinguishable for the user. The names are a purely associative feature 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 internal ID, which is not only unique inside the project, but also world wide. A special algorithm ensures that two elements that are not identical will never have the same internal ID.

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 must 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.

PIC Concepts Projects TreeComponents.png

Element Properties

The characteristic contents that make up a element are called the Element Properties. 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 not mean things like the name, id, or other internal detail. Property here means a topical unit of information that is characteristic for the element's purpose, and which is editable or at least displayable to the user. </p>

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 element editor pages can be opened in the expecco GUI Browser. A element Page contains the Editors 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>. </p>


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 all element types, except the Group element. It serves to assign each element an individual documentation text. Accessing this Property through the GUI is described in
the chapter "The Documentation Editor" of the expecco GUI Documentation.

Variable Environment Property

applies to Project, Library, Testplan and Compound Block 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 "The Testsuite Environment Editor" and "The Block Environment Editor" of the expecco GUI Documentation.

Schema Definition Property

applies to all Block 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 "The Schema Editor" of the expecco GUI Documentation.

Internal Network Property

applies to Compound Block elements only. It serves to model the internal workflow of a compound block by arranging and interconnecting building blocks called Steps and Connections. Accessing this property through the GUI is described in the chapter "The Internal Network Editor" of the expecco GUI Documentation.

Code Content Property

applies to Coded Elementary Block elements only. It serves to contain executable code in a particular programming language. Accessing this property through the GUI is described in the chapter "The Program Code Editor" of the expecco GUI Documentation.

Script Content Property

applies to Shell Script and Batch Script Block elements. It serves to contain script code in an OS dependent scripting language. Accessing this property through the GUI is described in the chapter "The Script Code Editor" of the expecco GUI Documentation.

Console Command Property

applies to the Shell/Batch Command Block elements only. It serves to contain an OS dependent console command. Accessing this property through the GUI is described in the chapter "The Console Command Editor" of the expecco GUI Documentation.

Generic Values List Property

applies to Test Data Generator 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 "The Generic Values Editor" of the expecco GUI Documentation.

Local Test Network Property

applies to all Block elements, except Test Data Generator 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 "The Block Test Editor" of the expecco GUI Documentation.

Skill Requirements Property

applies to all Block 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 "The Resource Requirement Editor" of the expecco GUI Documentation.

Skill Attributes Property

applies to the Skill 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 "The Skill Definition Editor" of the expecco GUI Documentation.

Resource Definition (Skill Assignments) Property

applies to the Resource 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 "The Resource Definition Editor" of the expecco GUI Documentation.

Inventory (Resources List) Property

applies to the Inventory 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 "The Inventory Definition Editor" of the expecco GUI Documentation.

Testplan (Test Items List) Property

applies to the Test Plan 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 "The Testplan Editor" of the expecco GUI Documentation.

Class Definition Property

applies to the Class element type only. It serves to define the programmatic structure of a Class element.

Type Definition Property

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

The Steps are depicted as graphical building blocks, which can have so-called Pins. The Pins serve to interconnect the Steps with each other inside the Activity Diagram. The Input Pins appear on the left, the Output Pins on the right side of a building block. Output Pins can be connected to Input Pins by placing Connections 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. PIC Concepts Workflows SymbolicActivityDiagram.png Figure 5-1: Symbolic depiction of an Activity Diagram, consisting of Steps and Connections PIC Concepts Workflows StepsReferencingComponents.png Figure 5-2: Steps referencing to Block elements

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 exactly one Block element, but multiple Steps can reference the same Block element. Connections are each referencing exactly one Input Pin and exactly one Output Pin.

Steps are representation instances of Block elements. The Steps themselves are not part of the Testsuite elements. While a Block element is a Testsuite element that exists exactly one time throughout the Testsuite, the Step instances (as well as the Connections) are Workflow elements. 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

Data flow driven execution 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 Activity 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 implicitly at runtime by passing the input values to the Step. Please keep in mind that invoking a Step does not mean that the Step itself is running. The Step inside the Activity Diagram only serves as a value collector and buffer, and as a spawning point 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.

PIC Concepts Workflows DataflowControl.png Figure 5.1-1: The data flow driven execution principle PIC Concepts Workflows MultipleActivities.png Figure 5.1-2: A Step having spawned multiple concurrently running Activities <a href="#cc9ce4a0-117d-11db-a24a-0040c7999506">Figure 5.1-2</a> shows what to understand under the term "Parallelism": 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 identical 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 limit 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. PIC Concepts Workflows MultipleOutputConnections.png Figure 5.1-3: A Step passing an Activity's output value to multiple connected Steps

The Schema Definition

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

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 Input Pins are specified, the Output Pins to the right. Every Pin is assigned a Datatype, 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 name, which is not only used to describe its purpose for the user, but also serves as the referencing name for value access 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.

PIC Concepts Workflows Basical Schemes.png

Figure 5.2-1: Two exemplary Schema Definitions as they appear in the expecco Schema Editor

In addition, with the small grey box to the left, an Triggering Condition Type 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: AND gating requires all consuming inputs to have a value, OR gating requires one or more consuming inputs to have a value, and ANDConnected gating requires all connected consuming inputs to have a value.

PIC Concepts Workflows Basical Network.png

Figure 5.2-2: An exemplary Activity Diagram as it appears in the expecco Workflow Editor

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 Default Pin Configurations of the Block, which allow the user to assign default values to the parameters of each Pin Configuration.

PIC Concepts Workflows SchemaDefinition PinSpecials.png

Figure 5.2-3: Appearance of frozen value, unbuffered Output Pin, and non-consuming Input Pin

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 frozen 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 Environment Variable. 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 Basket Buffer size 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 consuming and non-consuming 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 buffered and unbuffered mode. An unbuffered Output Pin will send a written value immediately to the connected target Pins, while a buffered Pin collects all written values in a queue, 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
<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 Workflow consists of three basical elements: Steps which have Pins, and Connections that interconnect the Pins. The Activity Diagram displays these elements, and allows the user to arrange and modify them. Steps are displayed as building blocks with the according set of graphical endpoints for the Pins, and Connections are displayed as lines 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
<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 Interface Pins 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 Local Test Editor, 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 Test Wrapper 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 Internal Network Editor, is the one that supplies External Pins to the diagram, which represent the Interface Pins of the Block. It is only available for Compound Blocks, which hold an Internal Workflow 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.

PIC Concepts Workflows ActivityDiagrams InterfacePins.png

Figure 5.3.1-1: A Compound Block's Interface Pins in the Internal Workflow's Activity Diagram (schematic)

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). </p>

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.

Arranging Steps

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

PIC Concepts Workflows CreatingSteps.png

Figure 5.3.2-1: Initial Step Creation by Drag & Drop

Another possibility to create Step instances is first to copy an existing Step instance, and then paste 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 complete sub structures of existing Workflows, including all Connections comprised.

PIC Concepts Workflows MovingSteps.png

Figure 5.3.2-2: Positioning Steps

The building blocks can be moved around 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 Connection 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 only be created when the Pins' Datatypes are compatible. Usually, you will connect Data Pins which have the identical Datatype adjusted, but there are some special cases where other combinations are possible: Pins holding the "Any" 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 "Number" Datatype, which allows connections to all Pins holding the "Number", "Integer", or "Float" Datatype.

PIC Concepts Workflows CreatingConnections.png

Figure 5.3.2-3: Creating Pin Connections

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 combining 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 expanding 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 Step Configuration. This comprises the Local Step Configuration for the parameters directly related to the Step instance object, and a set of Local Pin Configurations, 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 Local Pin Configurations, which comprise a set of parameters for each of the Pins. In the Schema Definition of a Block, the Default Pin Configurations 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 overdub 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:

  1. The effective Gating Type is taken directly from the Schema Definition of the Step's Block;
  2. The effective Step Configuration is taken directly from the Step Definition in the Workflow;
  3. The effective Pin Configurations 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 Local Step Configuration comprises parameters that are directly related to the Step object. Because a Step is a Workflow element, 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 names. 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 purely organizational feature 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 Autostart 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 Ignore Exceptions 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 Parallelity Limit 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 Separate Process option allows to give every Activity spawned by this Step an own individual OS process.

The functionality of a Local Pin Configuration is exactly the same as for the Default Pin Configuration, 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 Effective Pin Configuration. 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 not 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 frozen 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 Environment Variable. 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 Basket Buffer size 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 consuming and non-consuming 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 buffered and unbuffered mode. An unbuffered Output Pin will send a written value immediately to the connected target Pins, while a buffered Pin collects all written values in a queue, 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

Triggering Condition denotes the rule that determines when to invoke 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 dataflow driven concept of Activity Diagrams, the decision when this is done is usually made referring to the Input Pins' value occupancies.

Depending on the Gating Type, which can be adjusted in the Schema Editor, and on the effective Input Pin Configurations, the presence of input values 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 Enable Trigger Input Pin, if activated, also has to obtain a value before the Activity instance can be initialized.

In an executing Workflow, the system cyclically performs an occupancy evaluation 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 Input Pin Configuration that plays a role in the evaluation of value occupancies: The non-consuming/non-triggering 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 parametric behaviour. 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 only once (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 Or function, which requires only one of the consuming Pins to have a value. The second one, the And function, requires all of the consuming Pins to have a value. The third one, the AndConnected function, requires all of the connected consuming Pins to have a value; Pins that are not connected are not taken into account. With this function, Pins can remain unconnected, while the And function in contrast would cause the Step never to be invoked if one consuming Pin was unconnected. Since the AndConnected function is most typically used, it is initially selected in new Block's Schema Definitions.

Introducing Triggers

Triggers are a means for synchronisation 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.

Trigger Pin Connections 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 all possible Trigger Pins activated. All Trigger Pins can be activated and deactivated through the Step's Context Menu.

PIC GUI EditorDetail WorkflowTriggersShowAll.png

Figure 5.3.5-1

On top of the representation box, you see three possible Trigger Input Pins, which are (from left to right) the Enable-Input, the Cancel-Input, and the Timelimit-Input trigger pin. At its bottom, you see the two possible Trigger Output Pins, called (from left to right) the Enable-Output, and the Exception-Output trigger pin. Most often used is the Enable-Input/-Output 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:

PIC GUI EditorDetail WorkflowTriggersSampleSerial.png

Figure 5.3.5-2

To the left, you can see a typical serialization sequence use case. Notice the two Connections between the Enable-Trigger 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 "Sequential Execution" 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 Exception-Output pin sends a triggering signal to the Cancel-Input 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 Timelimit-Input, which would then cancel the third Step after that number of seconds.

PIC GUI EditorDetail WorkflowTriggersSampleCancel.png

Figure 5.3.5-3

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 Enable-Input Pin 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 Cancel-Input Pin 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 Timelimit-Input Pin can only be connected to Data Output Pins of a numeric Datatype (Integer, Float, or Number), 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 Enable-Output Pin 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 "Any", but for the average user, this option makes no sense. The usual intention is to use it only with Trigger Input pins.

The Exception-Output Pin 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 "Any", 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 Internal Network Editor, this Editor does not supply any direct execution mechanisms for that Workflow. Instead, the Local Test Editor 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 only intended for the definition of the Internal Workflow Property of a Compound Block, the Local Test Editor allows to model independent trial Workflows, 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 Local Test Editor, the other is through the Test Plan Editor. What both execution models have in common is the Test Wrapper 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 wraps the trial Workflow which has been modeled in its Activity Diagram, while the Test Plan Editor’s Test Wrapper wraps a sequence of implicit Steps. The Test Plan Editor does not supply an Activity Diagram. Instead, when a Test Plan is executed in this editor, the according Steps are implicitly created, 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 Autostart option, 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 Input Pin Evaluation, 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 initializing an Activity is not the same as executing 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 Execution Context, which denotes the executing environment 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 creates its individual Execution Context, but also inherits the properties of its own encapsulating Execution Context.

There are several items which are concerned in the Execution Context inheritance. First is the Variable Environment: 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 Inventory: 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 logging 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

Elementary Blocks provide the basic functionality 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

The Code Block

element is the element type used to implement an elementary functionality block in form of programmatic source code in a particular programming language. Currently, two syntax patterns are supported: <img src="./pictures/PIC_GUI_IconSymbol_ProjectComponent_JavaScriptAction"> JavaScript syntax, and <img src="./pictures/PIC_GUI_IconSymbol_ProjectComponent_SmalltalkAction"> Smalltalk syntax.

Each element of this type contains exactly one Code Content Property, which holds the Source Code Text Content that is interpreted according to the used language’s syntax at runtime. It is also possible to switch the syntax pattern 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 <img src="./pictures/PIC_GUI_IconSymbol_ProjectComponent_ShellScriptAction"></img> Shell Script Block element is the element type used to implement an elementary functionality block in form of shell script source code in an OS dependent scripting language. The code contents are directly passed 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.

Each element of this type contains exactly one Shell Script Content Property, which holds the Shell Script Code Text Content 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.

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 stdin, stdout, and stderr. 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 <img src="./pictures/PIC_GUI_IconSymbol_ProjectComponent_ConsoleCmdAction"></img> Console Shell Command Block element is the element type used to implement an elementary functionality block in form of a console shell command in an OS dependent manner. The command is directly passed to the underlying operating system, so the scope of possible executables to call depends on the platform on which the session is running.

Each element of this type contains exactly one Console Shell Command Property, 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.

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 stdin, stdout, and stderr. 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>.

Test Data Generator Blocks

The <img src="./pictures/PIC_GUI_IconSymbol_ProjectComponent_DataGeneratorAction"></img> Test Data Generator Block element is the element type used to supply artificially generated data values 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 Generic Values List Property, 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’ Data Pin Definitions (which are part of the Schema Definition Property) are fixed, 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 execDir Input Pin takes a String or Filename object that specifies the base directory to which to change when execution starts, also known as the current directory. Relative paths in Script or Batch files are usually interpreted to be relative to this directory.

The command Input Pin is only present at Shell Command Blocks, and takes a String object that specifies the calling path of the executable 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 execDir Input Pin.

The args InputPin takes a StringCollection representing the execution’s arguments, 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 stdin, stdout, and stderr Pins represent the shell and batch typical, OS related stdandard i/o streams. 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 stdin Input Pin, this means that the all input lines have to be collected in total into a string first and initially passed to the stdin Pin for execution. After the Activity is spawned, no further input lines can be supplied to the stdin Pin.

For the stdout and stderr Output Pins, the situation is similar, but still different: By giving values to the outNLines and errNLines Pins, the block size for each output stream can be adjusted. The block size is the number of lines to collect 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 result Output Pin delivers the integer return value 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 Data Generator Block: 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 <img src="./pictures/PIC_GUI_IconSymbol_ProjectComponent_TestPlan"></img> Test Plan element is the element type used to model and execute individual Test Plans. A Test Plan is a sequence of individual Test Items that can be executed. A Test Item is either a Block element, or yet another nested Test Plan element. Each element of this type contains exactly one Test Items List Property, 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 Test Plan Editor. This editor provides the editable representation of the Test Items List 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 dragging 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 selected for execution, i.e. included to or excluded from the execution sequence. Additionally, an individual repetition number 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 own basic level can be seen in the Test Items List. The contents of nested Test Plans can only be modified inside their 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 Test Run denotes a single execution 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 logging information, called its Activity Log. 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 organizational part of the containing Test Plan, the Block elements which are embedded make up the functional 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 implicit Workflow 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 Test Wrapper object is created. The Test Wrapper is an Activity that embraces and processes 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 never receive any values on its Input Pins. Also, values written to the Output Pins are never received by any other Step. 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. Any Block element can be placed as a Test Item, and its according Step will be invoked in any case, 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 Activity Tree, which supplies a browseable overview on all Activities that are currently running or already finished. On the Test Plan’s own basic level, only one 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, no implicit parallelism restrictions are made, so its internal Steps can create concurrent Activities.

The Test Items List does not only allow the arrangement and setup of Test Items, but also displays the according Activity execution states at runtime, as well as their sub Activities, as a hierarchical tree structure. This structure is called the Activity Tree. In this structure, it is possible to browse to any Activity that started execution in the current Test Run, and to access its logging information 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 Test Result is the ordered set of Activity Logs 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 Test Report is a representation of the contents of a Test Result, or of part of it, in the form of a document readable by humans. In expecco, Test Reports can be generated in different output formats. 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 message categories 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 all 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

Resources 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 abilities, for which we use the term Skills. Similar to an interface definition, the elementary Attributes that characterize an ability are summarized in such a Skill object. A Resource is characterized by a set of such Skills, and concretized by assigning values to the Skill's Attributes.

Resources can then be accumulated into Inventories, which represent availability sets of Resources. The Inventory object takes care of the distribution and availability of its Resource entries during runtime. Inventories can be assigned to Workflow execution contexts, then offering their Resources to the Activities that run in that context. Activities claim their need for Resources by specifying according Requirements, 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 Activities during runtime. For each Block element (except for the Test Data Generator Block), Skill Requirements can be specified, which will cause an according Activity to request the Inventory of its Execution Context for Resources that meet the specified demands. An Activity will not execute unless adequate Resources have been reserved, and keeps them reserved until it has finished execution.

A special feature in this context applies to Compound Blocks: Every Activity that relates to a Compound Block gets its own individual Local Inventory. 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 Resource Acquisition Request to the Execution Context's Inventory. When an Inventory receives such a Resource Acquisition Request, it successively checks all of its available Resources for adequacy, 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 <img src="./pictures/PIC_GUI_IconSymbol_ProjectComponent_Skill"></img> Skill element serves to summarize the elementary Skill Attributes that characterize a Skill. It is important that only the nature of the Skill is defined in the form of its Skill Attributes, but no 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 Skill Attributes Property, which serves to set up and configure the Skill Attributes. This is done in expecco using the Skill Definition Editor.

A Skill Attribute consists of two elements: The Attribute Name, which serves as the key of association for the user, and the Attribute Datatype, 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 purely organizational feature 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 Skill Definition Editor, 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 <img src="./pictures/PIC_GUI_IconSymbol_ProjectComponent_Resource"></img> Resource element is used to represent a concrete Resource type. The Resource element itself still does not represent a concrete instance 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 concrete values, 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 Skill Assignments Property, which serves to set up and concretize the list of Skill Assignments. This is done using the Resource Definition Editor.

A Skill Assignment consists of a Skill Reference to the according Skill element, and of a set of Skill AttributeValues, 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 value assignments. For every Skill Attribute of each Skill, a value is given according to the Attribute Datatype 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 Resource Definition Editor, new Skill Assignments can be created simply by dragging 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 PIC GUI IconSymbol ProjectComponent Inventory.png Inventory element 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 Inventories using the Inventory Editor. 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 Resources List Property, which serves to compose and set up the Resource Entries. This is done using the Inventory Definition Editor.

A Resource Entry consists of three elements: The Resource Reference to the according Resource element, the Allocation Block Reference, which specifies a Block of which an Activity shall be executed on allocation of the Resource instance, and the Release Block Reference, which specifies a Block of which an Activity shall be executed when the Resource instance is released.

Internally, implicit Steps are created for the Allocation and Release Blocks at runtime as the basis for spawning the according Activities. Any 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 never 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 never received by any other Step.

In the Inventory Definition Editor, a Resource entry can be created simply by dragging 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 not designate a concrete object of reality, but instead only describes a particular kind 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 <img src="./pictures/PIC_GUI_IconSymbol_ProjectComponent_UnspecifiedAction"></img> Block element - except for the Test Data Generation Block - can be assigned a set of Skill Requirements, which describe the abilities that have to be met 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 allocate suitable Resource objects 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 propagate forward 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 not appear as an expecco Testsuite element. Skill Requirements only appear in the Block's Skill Requirement Property.

Each element of this type contains exactly one Skill Requirements Property, which serves to compose and set up the Skill Requirements. This is done using the Resource Requirement Editor.

A Skill Requirement consists of a Skill Reference to the according Skill element, a set of Skill Attribute Comparisons with one for each Skill Attribute of the referenced Skill, and an Acquisition Configuration.

A Skill Attribute Comparison consists of a Comparison Operator and a Comparison Value. 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 Acquisition Configuration specifies detail on the way how adequate Resources are to be acquired at runtime. For all Block elements, it contains the Requisition Number, 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 Generation Number, and the Request Pass-On Mode. The Generation Number allows to configure implicit creations of Resource instances inside an Activity's local Inventory when the Activity is created. Naturally, this does not make sense when dealing with real objects, because those will not duplicate themselves just because a new Activity is created. It does make sense, however, for abstract immaterial Resources such as semaphores or locks. The Request Pass-On Mode 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 Resource Requirement Editor, Skill Requirements can be created simply by dragging 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

Variable Environments 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 Testsuite element. Because the Testsuite element is the base item of an expecco project, the according Variable Environment acts as the Global Variable Environment of the project, i.e. it is basically valid for all Activities ever executed throughout the project.

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

The Environment Variables declared in such a local Environment overdub those of the global one, as well as those of the own encapsulating Execution Context’s local one. The expecco Environments act totally transparent regarding the inherited Variables, i.e. those declared in the superordinate Execution Contexts: If a Variable is accessed which is not declared locally, the Environment passes 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 scoped Variable Environments, 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 write-protected 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 scope behavior can be inverted. 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 superordinate Environment. The use of this is that you can configure local default values in such a Variable, which are then only used if none of the parental Environments defined a Variable of the same name.

Each Compound Block element as well as the Testsuite element has exactly one Variable Environment Property, which serves to compose and set up the Environment Variables. This is done using the Variable Environment Editor.

An Environment Variable consists of a Variable Name, which serves as the textual key for accessing the Variable, a Write Protection flag, which determines write access to the Variable, a Variable Datatype, determining of what type the Variable's values can be, an Initialization Mode, specifying how to preset the Variable at the Environment's initialization, and an Initialization Value, 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 Overdubbing Mode 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.


Copyright © 2014-2016 eXept Software AG