Part III Tool Support & Case Study
9.2 User Interface
The user interface as seen by domain and application engineers is shown in Fig. 9.1. At the top, there is a toolbar with buttons needed for workflow editing and execution. Furthermore, the user interface is divided into three areas: 1) the area of the workflow editor; 2) an area at the bottom in which the user can see the content of different tabs, such as documentation, database editor, or log viewer; 3) an area on the left showing the contents of a workflow warehouse. The usage of each of these areas is described in turn.
1) Workflow Editor
2) Database Editor 3) Workflow
Warehouse
Fig. 9.1. Screenshot of the DWE as seen by domain and application engineers.
9.2.1 The Workflow Editor
The workflow editor can be in one of two modes: editing mode or execution mode. The editing mode is used in domain design to model the workflow. The execution mode is used for testing purposes in domain design, as well as in application realization to enact the workflow and construct an information product.
9.2 User Interface 151 Editing Mode
In this mode, the workflow editor is used to draw or delete the places, transi-tions, arcs, and tokens of a QX net interactively with the mouse. It supports zoom-in/zoom-out and grouping of subnets; for the combination of existing workflow models with the currently edited workflow, the DWE uses join op-erators that are similar to those introduced in [PS05a].
The editor automatically assigns a ID number to each place or transition, which is unique in the currently edited model. Labels with a textual descrip-tion can be attached by the user to places or transidescrip-tions. For each transidescrip-tion, additional properties can be specified (as demanded in Def. 7.5): pre-SQL and post-SQL queries, a path to a program that is executed when the respective transition occurs, and parameters for the program, which can also be queried from the database. More details on properties are discussed in Sect. 9.3.1.
The designer is responsible that the workflow model can only construct information products with feature configurations allowed by the conceptual product line model. The DWE supports the designer in various ways to achieve this goal. The designer can reuse workflow patterns (e.g., as in Fig. 7.6) or predefined workflow modules, which are both stored in the workflow warehouse (Sect. 9.2.3). In addition, the DWE offers the possibility to create a marking graph based on the edited workflow1. There are additional in-editing-checks that make sure that the workflow model has also the properties of a workflow net (see Def. 7.4); for example, the user is presented in the toolbar traffic lights that signalize either in red or green if the respective properties are satisfied, and the execution mode is enabled or disabled accordingly.
Execution Mode
When the DWE is in execution mode, it supports the enactment of the QX net according to the occurrence rule for QX nets specified in Sect. 7.2.3. Based on the occurrence rule, an internal scheduler determines all transitions that are enabled under the current marking, and execution is done in the following way:
• if no transition is enabled, the execution stops;
• if exactly one transition is enabled, the transition is scheduled to occur (i.e., the associated SQL queries and the program are executed);
• if a conflict situation arises in which more than one transition is enabled at the same time, then the user is asked to chose exactly one of the enabled transitions to occur (see Fig. 9.2). In this situation, the user decides how the control flow should go on.
1Remark: there is an upper bound of displayable vertices depending on the avail-able memory.
Fig. 9.2. When more than one transition is enabled under a given marking in execution mode, the user is asked to chose one of the enabled transitions to occur.
When the scheduling is done in the aforementioned way, there are no tran-sitions that are executed concurrently, and the execution of such trantran-sitions is “serialized”. Throughout the execution, the DWE automatically creates a system log which shows the order of occurrence of transitions (see Fig. 9.3).
Fig. 9.3. The DWE automatically records a log of occurring transitions.
The DWE stops the execution of a workflow in case of exceptions, e.g., if a program that is to be executed throws exceptions, or if SQL queries cannot be executed because of constraint violations in the database. The system log can be used in such cases to trace back the origin of the exceptions.
9.2 User Interface 153 9.2.2 The Database Editor
The database editor provides a graphical interface to the database manage-ment system (DBMS) that is seamlessly integrated into the DWE. The DBMS is based on HSQLDB [ST05], which is a full-fledged relational DBMS imple-mented in Java, and its functionality is available within the DWE. The reader is referred to the handbook of HSQLDB [ST05] for details on features of the HSQLDB.
A specific database with its relations and integrity constraints is always associated to a specific QX net whose control flow is shown in the workflow editor, and the database is opened and saved together with the QX net2. Within the database editor, a user can execute SQL DDL commands [ST05]
to create a database schema with appropriate constraints, or insert data tuples into the relational database. All names of existing relations in the database are shown within the database tab on the left side. A relation name can be selected with the mouse, and the content of the respective relation will be displayed with the attributes and values in a tabular form (Fig. 9.1).
For testing purposes, a user can also execute SQL selection commands [ST05] and display the results. Modification of tuples can be done via SQL update statements [ST05], or via the graphical user interface where the at-tribute values of a tuple can be modified by clicking on them and entering a new value. Such an easy update of data is important for application engi-neering, as pre-configured values defined in domain engineering remain easily adaptable in application engineering.
For example, a file path specification defined as an attribute value in a tuple can be adapted in the aforementioned way, and if the path value is queried inside one or more transitions during execution (e.g., to be passed as a parameter to some program), the updated value will be received. The advantage of separating such data from the internals of the control flow is that a domain engineer can specify the control flow in the workflow editor and initial parameter data in the database, while an application engineer is able to modify the data more easily in application engineering, without having to look at all internals of the construction process.
9.2.3 The Workflow Warehouse
The workflow warehouse acts as a repository for predefined workflow modules or workflow patterns, and is independent of the currently edited QX net or database. The workflow warehouse can be saved and exchanged separately, and thus supports the reuse of frequently needed process parts (the usage scenario will be discussed in Sect. 9.4).
Inside the workflow warehouse, the user can define a hierarchical structure of folders which can contain workflow modules or other folders. A workflow
2The DWE even saves the workflow net and the database in the same file.
module in the warehouse is created by marking in the workflow editor a subnet and duplicating it into the warehouse; the DWE automatically stores also the properties of the respective places and transitions in the warehouse. It is also possible to copy places and transitions with empty properties, so that the created workflow module represents a workflow pattern that can be extended later. To reuse a workflow module from the warehouse, it has to be selected by the user and copied to the editor area. The DWE inserts the module into the edited workflow; at first, it is placed on an empty area and stays disconnected, and the DWE reassigns its IDs of places and transitions so that they do not collide with existing ones. Thereafter, the user has to make the desired connections between the existing workflow and the inserted module.
The easy creation and access of the documentation of workflow modules is vital for their reuse. The DWE supports this with the documentation tab at the bottom area, which shows the documentation of the currently highlighted folder or workflow module in the workflow warehouse (Fig. 9.4). It is also possible to edit and modify the documentation right away; it is finally stored together with the workflow warehouse.
Paste workflow module into workflow editor area
Visible documentation synchronized according
to selection
Fig. 9.4. The integrated documentation of the workflow warehouse.