6.6 Graphical Concrete Syntax and Edit Operations
6.6.3 Graphical Concrete Syntax for the Process Model
This section provides the graphical concrete syntax of the process model and its
6.50
abstract syntax, respectively (cf. Figure6.7). While the most of the elements of the abstract syntax can be mapped in a similar way as shown before, some elements can not be mapped to graphical concrete syntax elements in such a straight forward manner.
As stated by Ehrig et al. [Ehr+05, Sec. 2.2], the disadvantage of the graphical
6.51
model editor generation based on GMF is that the underlying metamodel (i.e., the Ecore model) strongly influence the structure of the visual language alphabet. As indicated by the already shown mappings, a containment relation in the abstract syntax is always expressed as a compartment construct in the graphical concrete syntax. With respect to the abstract syntax of the Process element, mobile application modelers must follow a containment structure while modeling a Process. At first, they must create a startTask, which is usually a Sequence, and add body and follower tasks as compartment elements of the corresponding sequence. The reordering, insertion, and deletion of tasks are not supported by the GMF-generated graphical model editor, making the modeling process very inconvenient. Mobile application modelers usually prefer a freehand modeling method, being able to create all nodes (e.g., tasks) first and then combining them with edges (e.g., body and follower relations). In particular, edges should be flexibly assignable to modify the modeled process.
In order to circumvent the limitations of GMF, three solutions are conceivable:
6.52
First, editing operations could be implemented to support the reordering, insertion,
6.53
and deletion of process elements. This could be implemented in a manual or a tool- supported way, e.g., by specifying model transformations [Tae+07]. However, in both cases, the editing operations change the existing layout of a diagram because rearranged model elements will also rearrange the diagram elements. Indeed, editing operations may affect several diagram elements (e.g., all tasks of a process) and thus might not be convenient for mobile application modelers because the layout will be lost.
Second, the metamodel, i.e., the domain-specific modeling language, could be
6.54
changed in order to provide a more easy-to-use graphical model editor. This is the most frequently applied solution, especially if the metamodel is not used by other artifacts (e.g., code generators). However, a redesign of the abstract syntax is not favored during this work, because both the graphical model editor and the code generators should have no influence on the domain-specific modeling language and will be developed independently.
Third, an additional metamodel could be defined to provide a convenient graphical
6.55
model editor while the domain-specific modeling language definition remains unchanged. This solution requires a model-to-model transformation that serves as a kind of a model parser (e.g., parse visual subsentences – cf. Costagliola et al.
[Cos+05b] [Cos+05a]). The additional model is used only for editing and will be
parsed to the initial process model. As a result, the graphical model editor and the code generators can be developed independently referring only to their common
6.6. Graphical Concrete Syntax and Edit Operations 85 domain-specific modeling language. In practice, the additional metamodel consists of the existing metamodel and includes some extensions, hence it could called extended process model.
6.6.3.1 Extended Process Model
The extended process model, shown in Figure6.14, contains the classes Variable, 6.56
Process, and Task, which are derived from the equally named classes in the initial process model (cf. Figure6.7). The first extension is the containment feature allTasks of the class Process. This feature provides the creation of multiple tasks inside a process compartment without using a Sequence task to combine the tasks. In order to combine tasks, the next added feature RefTrue can be used. The RefTrue class acts as a directed edge between two tasks and denotes the preceding and succeeding task respectively. The classes If1, IfElse1, and While1 correspond to the similarly named classes in the initial process model but require no body (or elseBody). The RefTrue and RefFalse classes are used to model the accepting and rejecting path after such conditional tasks. Besides, the introduced conditional nodes and the Assign1 element accept a textual condition, captured in the condition (or rhs) attribute. This will be used later to combine textual and graphical editing (cf. Section6.7).
ConditionalNode Assign1 rhs:String If1 condition:String IfElse1 condition:String While1 condition:String Task Variable Process RefFalse RefTrue allRefsTrue 0..* allRefsFalse 0..* allTasks 0..* pre 1 suc 1 suc 1 pre 1 lhs 1
FIGURE6.14: The extended process model (showing extension only)
To sum up, the extended process model provides a syntax structure that allows 6.57
graph-based editing, rather than tree-based editing, inside the graphical model editor. The extended process model is parsed to the initial process model when the mobile application modeler saves a newly created extended process model. The parser removes the additionally introduced classes, i.e., the corresponding objects, thus creating a tree-based structure of tasks. However, this is not always possible if mobile application modelers create cycles or multiple edges. The parser provides trivial error-handling (e.g., ignoring multiple edges, multiple initial tasks) but does not yet provide a visual feedback or error location (cf. Tuovinen [Tuo00]). This
trade-off between freehand and syntax-directed editing is well discussed in the literature [KM00].
After extending the initial process model with these few elements, a more conve-
6.58
nient model editor based on GMF can be generated. We will now introduce the graphical concrete syntax for the extended process model.
6.6.3.2 Graphical Concrete Syntax for the Extended Process Model
Tables6.13to6.29show the mapping of the abstract syntax (AS) (cf. Figure6.7) to
6.59
the graphical concrete syntax (GCS).
TABLE6.13: Mapping of the abstract syntax element ProcessContainer
AS The abstract syntax element ProcessContainer forms the
diagram canvas and thereby directly or indirectly con- tains all other graphical concrete syntax elements.
GCS (Type) Canvas
GCS (Example) not applicable
Context none
Edit operations
Diagram operations
The Canvas element provides the creation of Process elements.
Property settings
The properties editor provides no further property settings.
TABLE6.14: Mapping of the abstract syntax element Process
AS The abstract syntax element Process and its contained elements like Variables and Tasks shape the graphical concrete syntax element Process.
GCS (Type) Node with compartments and label
GCS (Example)
(A) Empty Process
(B) Partially modelled
Process (C) Fully modelled Process
Process(node)
Process.name
Process.variables(compartment) Process.allTasks(compartment) Process.returns(compartment)
Context Arbitrarily often inside a ProcessContainer compartment
Edit operations
Diagram operations
The Process element provides the creation of Vari- ables and Tasks. Variables can be global parameter variables, local variables, and return variables.
Property settings
The properties editor supports the setting of the feature name.
6.6. Graphical Concrete Syntax and Edit Operations 87
TABLE6.15: Mapping of the abstract syntax element Variable
AS The abstract syntax element Variable is mapped to the graphical concrete syntax element Variable.
GCS (Type) Node with label
GCS (Example) (A) Global Variable (B) Local Variable (C) Return Variable Variable(node) Variable.name
Context Arbitrarily often inside a Process.variables compartment or Pro- cess.returns compartment
Edit operations
Diagram operations
The elements provide no further edit operations within the diagram.
Property settings
The properties editor supports the setting of the features name, changeable, defaultValue, scope, value, and eType (inherited from ETypedElement).
TABLE6.16: Mapping of the abstract syntax element ProcessSelector
AS The abstract syntax element ProcessSelector is mapped to the
graphical concrete syntax element ProcessSelector.
GCS (Type) Node with compartment and label
GCS (Example) ProcessSelector(node) ProcessSelector.name ProcessSelector.permission (compartment) ProcessSelector.page.name’:’ ProcessSelector.page.type ProcessSelector.processes
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the creation of Permissions.
Property settings
The properties editor supports the setting of the features page, processes, and name.
TABLE6.17: Mapping of the abstract syntax element Create
AS The abstract syntax element Create is mapped to the graphical concrete syntax element Create.
GCS (Type) Node with compartment and label
GCS (Example) Create(node) Create.name Create.permissions (compartment) Create.eClass.name Create.return.name’:’ Create.return.type
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the creation of Permissions.
Property settings
The properties editor supports the setting of the features anchor, eClass, return, and name.
TABLE6.18: Mapping of the abstract syntax element Read
AS The abstract syntax element Read is mapped to the graphical
concrete syntax element Read.
GCS (Type) Node with compartment and label
GCS (Example) Read(node) Read.name Read.permissions (compartment) Read.object.name’:’ Read.object.type Read.return.name’:’ Read.return.type
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the creation of Permissions.
Property settings
The properties editor supports the setting of the features object, return, and name.
TABLE6.19: Mapping of the abstract syntax element Delete
AS The abstract syntax element Delete is mapped to the graphical concrete syntax element Delete.
GCS (Type) Node with compartment and label
GCS (Example) Delete(node) Delete.name Delete.permissions (compartment) Delete.object.name’:’ Delete.object.type
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the creation of Permissions.
Property settings
The properties editor supports the setting of the features object and name.
TABLE6.20: Mapping of the abstract syntax element Assign
AS The abstract syntax element Assign is mapped to the graphical concrete syntax element Assign.
GCS (Type) Node with compartment and label
GCS (Example) Assign(node) Assign.name Assign.permissions (compartment) Assign.rhs Assign.lhs
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the creation of Permissions.
Property settings
The properties editor supports the setting of the features rhs, lhs, and name.
6.6. Graphical Concrete Syntax and Edit Operations 89
TABLE6.21: Mapping of the abstract syntax element InvokeOperation
AS The abstract syntax element InvokeOperation is mapped to the
graphical concrete syntax element InvokeOperation.
GCS (Type) Node with compartment and label
GCS (Example) InvokeOperation(node) InvokeOperation.name InvokeOperation.permissions (compartment) InvokeOperation.argumentsa InvokeOperation.operation InvokeOperation.context InvokeOperation.return.name’:’ InvokeOperation.return.type a not used here
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the creation of Permissions.
Property settings
The properties editor supports the setting of the features arguments, context, long, operation, return, and name.
TABLE6.22: Mapping of the abstract syntax element InvokeGUI
AS The abstract syntax element InvokeGUI is mapped to the graph- ical concrete syntax element InvokeGUI. The second labeled icon in the lower compartment indicates which type of page is referred (e.g., SL for SelectableList).
GCS (Type) Node with compartment and label
GCS (Example)
InvokeGUI(node) InvokeGUI.name
InvokeGUI.permissions (compartment) InvokeGUI.outputData.name’:’ InvokeGUI.outputData.type InvokeGUI.page.type(Icon) InvokeGUI.page.name InvokeGUI.inputData.name’:’ InvokeGUI.inputData.type
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the creation of Permissions.
Property settings
The properties editor supports the setting of the features input, outputData, inputData, return, and name.
TABLE6.23: Mapping of the abstract syntax element InvokeProcess
AS The abstract syntax element InvokeProcess is mapped to the
graphical concrete syntax element InvokeProcess.
GCS (Type) Node with compartment and label
GCS (Example) InvokeProcess(node) InvokeProcess.name InvokeProcess.permissions (compartment) InvokeProcess.argumentsa InvokeProcess.subProcess InvokeProcess.return.name’:’ InvokeProcess.return.type a not used here
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the creation of Permissions.
Property settings
The properties editor supports the setting of the features arguments, return, subProcess, synchronized, and name.
TABLE6.24: Mapping of the abstract syntax element CRUDGui
AS The abstract syntax element CRUDGui is mapped to the graph-
ical concrete syntax element CRUDGui.
GCS (Type) Node with compartment and label
GCS (Example) CrudGui(node) CrudGui.name CrudGui.permissions (compartment) CrudGui.privileges CrudGui.contain
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the creation of Permissions.
Property settings
The properties editor supports the setting of the features anchor, contain, privileges, and name.
TABLE6.25: Mapping of the abstract syntax element Permission
AS The abstract syntax element Permission is mapped to the graph- ical concrete syntax element Permission.
GCS (Type) Node with label
GCS (Example)
Permission(node)
Permission.name
Context Arbitrarily often inside a Task.permission compartment; except the task types If1, IfElse1, and While1
Edit operations
Diagram operations
The element provides no further edit operations within the diagram.
Property settings
The properties editor supports the setting of the features name and permission.
6.6. Graphical Concrete Syntax and Edit Operations 91
TABLE6.26: Mapping of the abstract syntax elements RefTrue and RefFalse
AS The abstract syntax element RefTrue and RefFalse are mapped
to equally named elements of the graphical concrete syntax.
GCS (Type) Edge
GCS
(Example) (A) RefTrue element (B) RefFalse element
RefTrue(edge) RefFalse(edge)
Context Arbitrarily often inside a Process.allTasks compartment; The element RefTrue may start from any kind of task, while the RefFalse element only starts from ConditionalNodes.
Edit operations
Diagram operations
The elements provide the creation of Tasks, which are selected as suc value.
Property settings
The properties editor supports the setting of the features pre, suc, and name.
TABLE6.27: Mapping of the abstract syntax elements If1
AS The abstract syntax element If1 is mapped to the graphical
concrete syntax element If1.
GCS (Type) Node with label
GCS (Example)
(A) If1 element (not connected)
(B) If1 element (fully connected) If1(node)
If1.condition
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the connection of RefTrue and RefFalse elements (edges).
Property settings
The properties editor supports the setting of the features condition and name.
TABLE6.28: Mapping of the abstract syntax elements IfElse1
AS The abstract syntax element IfElse1 is mapped to the graphical concrete syntax element IfElse1.
GCS (Type) Node with label
GCS (Example)
(A) IfElse1 element (not connected)
(B) IfElse1 element (fully connected) IfElse1(node)
IfElse1.condition
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the connection of RefTrue and RefFalse elements (edges).
Property settings
The properties editor supports the setting of the features condition and name.
TABLE6.29: Mapping of the abstract syntax elements While1
AS The abstract syntax element While1 is mapped to the graphical concrete syntax element While1.
GCS (Type) Node with label
GCS (Example)
(A) While1 element (not connected)
(B) While1 element (fully connected) While1(node)
While1.condition
Context Arbitrarily often inside a Process.allTasks compartment
Edit operations
Diagram operations
The element provides the connection of RefTrue and RefFalse elements (edges).
Property settings
The properties editor supports the setting of the features condition and name.
The abstract syntax element Expression is not mapped to a graphical syntax element:
6.60
it is mapped to textual syntax as presented in the next paragraph.