Querying Business Process Models with VMQL Harald Störrle and Vlad Acretoaie Dept. of Applied Mathematics and Computer Science Technical University of Denmark
[email protected],
[email protected]
ABSTRACT The Visual Model Query Language (VMQL) has been invented with the objectives (1) to make it easier for modelers to query models effectively, and (2) to be universally applicable to all modeling languages. In previous work, we have applied VMQL to UML, and validated the first of these two claims. In this paper, we apply VMQL to the Business Process Modeling Notation (BPMN) to evaluate the second claim. We explore the adaptations required, and re-evaluate the usability of VMQL in this context. We find similar results to earlier work, thus both supporting our claims and establishing the usability of VMQL beyond the realm of UML.
to run. This case is particularly prevalent in ad-hoc onetime-only querying of large models, where a full-text search invariably offers insufficient precision and programming is not economically efficient.
1.2
• VMQL is much easier to use than OCL in the sense that modelers perform substantially better when tested empirically;
Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques—Computer-aided software engineering (CASE), Flow charts
• VMQL imposes less learning effort than OCL; • VMQL can easily be extended to act as a language for constraint definition, thus covering both main application areas of OCL (querying and constraint formulation).
Keywords Model Querying, VMQL, BPMN, OCL, UML, Model Repositories
1. 1.1
INTRODUCTION Motivation
Some of the largest models in the world are process models, e.g., the SAP R/3 Reference Model. Such models store a wealth of information about organizational processes and their implementation, so it is vital that this information be accessible to a great number of people in the respective organization. However, most existing query facilities have not been conceived and implemented with a non-IT savvy user in mind: they offer only full-text search, a set of predefined queries, and/or a full-blown programming interface. We are interested in model users that on the one hand require more than full-text search and predefined queries, yet are not able or willing to program a query that they want
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. BM-FA ’13 July 2, 2013, Montpellier, France c 2013 ACM 978-1-4503-1989-8 ...$15.00. Copyright
Approach
In prior work, we have introduced and evaluated the Visual Model Query Language (VMQL, [22, 23, 24]). We could show that it enjoys a number of desirable properties when compared to the de-facto standard for model querying in the context of UML, the Object Constraint Language (OCL, [17]):
There are also some drawbacks, however, in that VMQL is less expressive than OCL (which is Turing-complete). Also, VMQL has not yet been evaluated with regards to whether it can be implemented in a computationally efficient way; the existing implementation is relatively limited.
2.
OVERVIEW OF VMQL
As its name suggests, VMQL is a predominantly visual language: it pursues the idea of query-by-example, that is, expressing model queries as (annotated) models. A VMQL query on a UML model is, simply put, a UML model fragment that may be annotated by a small number of constraints defined by VMQL. With a particular encoding of base models, such queries can be executed by similaritybased matching of models. By virtue of this architecture, we have argued, it should be easy to apply VMQL to modeling languages other than UML, for instance IDEF, ARIS/EPC, and BPMN, though we have so far not provided evidence to substantiate this claim. We begin by introducing VMQL in its original setting as a query language for UML models. We will call the modeling notation host language and the model to be queried source model in the remainder. The complete set of source models is collected in the model base. Executing a query (that is, a query model ) amounts to finding matching fragments in the source model and thus establishing an injective function
CD Product Catalog Product name: String coverage: float effective: Date
0..* 1..*
LifePlan MedicalPlan
DreadDiseasePlan
cooperate
DentalPlan
AllRoundHealthPlan CompoundProduct
0..*
CompoundHealthPlan GroupPlan
Figure 1: UML Class Diagram representing an insurance company’s product catalog.
from model elements of the query model to model elements of the source model (binding) and values for all free variables in the query (valuation). Finally, results are displayed back to the user in the notation of the host language. Obviously, then, anybody who can model can also read and write queries with virtually no additional learning effort. Since the results are also presented in the host language, there are no semantic gaps between model base, query, and query result. Consider the source model presented in Fig. 1, representing the product catalog of an insurance company. Fig. 2 contains examples of VMQL queries on this model. Query 1 finds all subclasses of the Product class - that is, it answers the question “What insurance products does this company offer?”. The indirect constraint in the query indicates that all transitive subclasses in the hierarchy should be returned. The mclass c o l l e c t N e s t e d ( c l o s e s t P r e c G a t e w a y s ( ) ) −>f l a t t e n ()−> a s S e t ( ) −>i n t e r s e c t i o n ( Task . a l l I n s t a n c e s ( ) −> s e l e c t ( name= ’ c o n s u l t a c c o u n t ’ ) −>c o l l e c t N e s t e d ( c l o s e s t P r e c G a t e w a y s ( ) ) −>f l a t t e n ()−> a s S e t ( ) )
Listing 3: Query 6 expressed in OCL context P r o c e s s d e f : query6 ( ) : Boolean = Task . a l l I n s t a n c e s ( ) −> s e l e c t ( name= ’ send quote t o customer ’ ) −>c o l l e c t N e s t e d ( i n d i r e c t P r e c F l o w N o d e s ( ) −> s e l e c t ( o c l I s T y p e O f ( A c t i v i t y ) ) ) −>f l a t t e n ( ) −>e x i s t s ( oclAsType ( A c t i v i t y ) . d a t a I n p u t s ( ) −>e x i s t s ( name = ’ c o n t r a c t ’ ) )
Listing 4: Query 7 expressed in OCL context P r o c e s s d e f : query7 ( ) : Set ( Task ) = ExclusiveGateway . a l l I n s t a n c e s ( ) −>c o l l e c t N e s t e d ( o u t g o i n g ) −>f l a t t e n ( ) −> c o l l e c t ( t a r g e t R e f ) −> s e l e c t ( o c l I s K i n d O f ( Task ) ) −> c o l l e c t ( oclAsType ( Task ) ) −>a s S e t ( )
Listing 5: Query 8 expressed in OCL context P r o c e s s d e f : query8 ( ) : Boolean = Task . a l l I n s t a n c e s ( ) −> s e l e c t ( name= ’ modify c o v e r a g e l i m i t ’ ) −>c o l l e c t N e s t e d ( i n d i r e c t P r e c F l o w N o d e s ( ) ) −>f l a t t e n ( ) −>e x i s t s ( name= ’ check g e n e r a l c o v e r a g e ’ )
Listing 6: OCL helper operations 1 −− A l l D a t a I n p u t s o f an A c t i v i t y 2 context A c t i v i t y 3 d e f : d a t a I n p u t s ( ) : Set ( DataInput ) = 4 dataInputAssociations 5 −>c o l l e c t N e s t e d ( s o u r c e R e f ) 6 −>f l a t t e n ( ) 7 −> s e l e c t ( o c l I s T y p e O f ( DataInput ) ) 8 −> c o l l e c t ( oclAsType ( DataInput))−> a s S e t ( ) 9 10 −− A l l FlowNodes p r e c e d i n g a FlowNode 11 context FlowNode 12 d e f : i n d i r e c t P r e c F l o w N o d e s ( ) : Set ( FlowNode)= 13 i f ( incoming−>isEmpty ( ) ) then Set {} 14 else 15 incoming 16 −> c o l l e c t ( s o u r c e R e f ) 17 −>union ( 18 incoming 19 −>c o l l e c t N e s t e d ( 20 sourceRef . indirectPrecFlowNodes ( ) ) 21 −>f l a t t e n ( ) 22 )−>a s S e t ( ) 23 endif 24 25 −− The c l o s e s t Gateway p r e c e d i n g a FlowNode 26 context FlowNode 27 d e f : c l o s e s t P r e c G a t e w a y s ( ) : Set ( Gateway ) = 28 i f ( incoming−>c o l l e c t ( s o u r c e R e f ) 29 −>isEmpty ( ) ) then Set {} 30 else 31 i f ( incoming−>c o l l e c t ( s o u r c e R e f ) 32 −>e x i s t s ( o c l I s K i n d O f ( Gateway ) ) ) then 33 incoming−>c o l l e c t ( s o u r c e R e f ) 34 −> s e l e c t ( o c l I s K i n d O f ( Gateway ) ) 35 −> c o l l e c t ( oclAsType ( Gateway))−> a s S e t ( ) 36 else 37 incoming−>c o l l e c t ( s o u r c e R e f ) 38 −>c o l l e c t N e s t e d ( c l o s e s t P r e c G a t e w a y s ( ) ) 39 −>f l a t t e n ()−> c o l l e c t ( 40 oclAsType ( Gateway ) ) 41 −>a s S e t ( ) 1 42 endif 2 43 endif 3 4 5 B. QUESTIONNAIRE SUMMARY 6 Two versions of the questionnaire were handed out to 7 study participants in order to control learning effects. One version begins each task with VMQL questions, while the other begins with OCL questions. To mitigate participant biases about the query languages, VMQL and OCL are referred to as Language X and Language Y, respectively. The questionnaire is structured into the following blocks: • Introduction to BPMN: The BPMN meta model elements appearing in the questionnaire are introduced. • Introduction to the Query Languages: The subsets of VMQL and OCL required to complete the Tasks A and B are introduced. • Task A - Comprehension: Participants are shown eight VMQL and OCL queries, and are asked to select the appropriate plain English interpretation of each.
Figure 8: Question 2 of Task A expressed in VMQL. • Task B - Production: Participants are shown four queries in plain English, and are asked to write down the queries’ VMQL and OCL representations. • Subjective Assessment: Participants provide ratings for the perceived difficulty and effort involved in completing Tasks A and B using a 5-point Likert scale. The purpose of Task A is to determine participants’ understanding of the meaning of VMQL and OCL queries. Participants are asked to view eight queries and select each one’s meaning from a list of four options, the last one being that they do not know the meaning of the query. An example question and its correct answer are also provided. As an example, Fig. 8 presents the VMQL version of Question 2 of Task A. The OCL version of the same question is presented in Listing 7. The queries are equivalent, and their purpose is to identify all Activities executed immediately before the EndEvent of a Process. To answer the question, participants must select one of the following options (of which option C represents the correct answer): A Which Activities are executed more than once? B Which Task precedes the first ExclusiveGateway? C Which Activities are executed immediately before the EndEvent? D I don’t know. Listing 7: Question 2 of Task A expressed in OCL context P r o c e s s d e f : query ( ) : Set ( A c t i v i t y ) = s e l f . f low El em ents −>s e l e c t ( e | e . o c l I s K i n d O f ( A c t i v i t y ) and e . o u t g o i n g −>c o l l e c t ( t a r g e t R e f . o c l I s T y p e O f ( EndEvent ) )−> s i z e > 0 ) In Task B, participants are presented with plain English query descriptions, and must produce VMQL and OCL queries adhering to these descriptions. Participants are instructed not to consult Task A, so that the produced queries are a result of their own understanding of VMQL and OCL. The following four plain English query descriptions were used: A Which Tasks are not connected to the End Event? B Which Parallel Gateways have branches that start with the same task? C What precedes Task A? D What are the Choreography Tasks on which Participant A and Participant B collaborate?
