Improving the Usability of OCL as an Ad-hoc Model Querying Language

Abstract

The OCL is often perceived as di cult to learn and use. In previous research, we have de ned experimental query languages exhibiting higher levels of usability than OCL. However, none of these alternatives can rival OCL in terms of adoption and support. In an attempt to leverage the lessons learned from our research and make it accessible to the OCL community, we propose the OCL Query API (OQAPI), a library of query-predicates to improve the user-friendliness of OCL for ad-hoc querying. The usability of OQAPI is studied using controlled experiments. We nd considerable evidence to support our claim that OQAPI facilitates user querying using OCL.

Introduction

Interactive querying by modelers is an important task in many model-based practices (cf. [ 1 ]). Where the full-text search and prede ned queries provided by many tools are not expressive and exible enough, the Object Constraint Language (OCL, [ 2 ]) is an obvious choice as a model query language. However, OCL has a reputation as being \hard", and we have observed many a modeler struggle with OCL, both in industry and academia. This has even been quoted as the main obstacle to adopting OCL in industry: \OCL has not yet been broadly adopted by practitioners because they nd it di cult to de ne OCL expressions " (cf. [3, p. 665]).

In previous research, we had hypothesized that there might be at least two different factors contributing to the usability of model query languages (see Fig. 1). First, we hypothesized that there is a \language gap" between a textual model query language and a visual modeling language; providing a visual query language instead of a textual one (such as OCL) would avoid this gap, and contribute to usability. Thus we have de ned the Visual Model Query Language (VMQL, see [ 4 ]), and could indeed show that it is easier to use than OCL.

Evaluating the participant feedback from this initial study revealed, however, that there is a second factor, namely, a \semantic" or \concept gap" between the concepts modelers use and the concepts provided by a low-level query language such as OCL. Since, inadvertently, VMQL closed both of these gaps at the same time, we could not identify the respective contributions of these two factors. Thus, we have de ned the Model Query and Constraint Language (MOCQL, [ 5 ]), a language that shares the high level concepts of VMQL, but not the visual syntax. Again, we could demonstrate higher usability than OCL|but also higher usability than VMQL. This leads to two predictions. First, it suggests that closing the concept gap has (much) more impact than closing the language gap. If this is correct, the Visual OCL [ 6 ] would exhibit essentially the same level of usability than OCL. Second, equipping OCL with similar query concepts as de ned in VMQL and MOQCL would improve the usability of OCL. In this paper, we are testing the second prediction by introducing the OCL Query API (OQAPI), a library of OCL querying predicates emulating the query concepts o ered by VMQL and MOQCL, and test its usability.

high

Query Concepts

MOCQL OCL+OQAPI

c o n c e p t low

OCL p VMQL a g g a p

vOCL e g a u g n a l textual visual

Notation Type methods whose name starts with 'set"' (i.e., all setters). Since these operations are so frequent, OQAPI provides speci c support for them. As a concrete example, consider nding all classes in a model that have the name \Address". Using OQAPI this query might be expressed as query (1a), while bare OCL would require something like (1b). (1a) classes() -> named('Address') (1b) Class.allInstances() -> select(c | c.name == 'Address')

Unfortunately, solution (1b) works only in some contexts, but not, say, for selecting Actions of a given name, since allInstances is only de ned for Classifier, and does not cover sub-meta-classes. So, action.allInstances() is not proper OCL code, and even if it were, no instances of subclasses of Action would be found. Since there are no type variables in OCL, we cannot implement a generic lookup function: def lookup(<T> <: Element) : Set(<T>)= -- not possible in OCL! model->collect(x|x.isOclTypeOf(<T>)).

Thus, OQAPI provides explicit lookup-functions for all (!) relevant meta classes, i.e., classes(), actions(), useCases, and so on. It also provides matching lters, i.e., is class(), is action(), is useCases etc. 2.2

Attribute value selection

In (1b), we have used select for selecting by attribute values, but there is also the OCL function collect that allows more compositional selection: OCL allows to use collect(a=v) for searching for model elements with a speci c value v in a given attribute a (see [2, p. 32]). Of course, such clauses can be cascaded. For instance, query (2) below looks for abstract classes called \Address". (2) classes()->collect(name='Address')->collect(isAbstract=true)

For the most frequent meta-attributes, speci c selection predicates are provided, in particular named. Besides exact matching, however, wild-card matching is frequently called for. Currently, there is no such feature in OCL. Using the substring functions of the OCL standard library, it is easy to implement a named like function for the simplest cases with only one '*' wild card. match(s:String, pattern:String): Boolean = let star = pattern.indexOf('*'), head = pattern.substring(0,star-1), tail = pattern.substring(star+1,l-1) in

match_tl(s, tail) and match_hd(s, head) match_tl(s, pattern) = pattern = s.substring(s.length()-pattern.length(),s.length()-1) match_hd(s, pattern) = pattern = s.substring(0,pattern.length()-1) Clearly, anything up to and including linguistic and phonetic search would be possible, too. 2.3

Association

One of the properties of OCL is that it re ects immediately the structure of the underlying meta-model. This can be understood as a feature (degree of control), but also as a bug (lack of abstraction). Since the UML meta-model encodes many relationships that are quite clear and intuitive to modelers in unobvious and complicated ways, we think the latter point of view is more accurate. This is probably best demonstrated using association (but applies similarly to generalization, and containment). Consider rst a case where we want to nd the actors involved in a given use case named \edit address data". Using OQAPI, we can issue the following query. (3) actors()->associated_to()->(is_useCase()

and named_like('edit address data') )

OQAPI o ers the simple is associated to predicate to replace the cumbersome navigation made necessary by the complex encoding in the UML metamodel. In bare OCL, simply checking that a given Classi er C1 is associated to another given Classi er C2 makes us navigate to the respective ownedMembers of C1 and C2, then nd an Association A that refers ownedMembers of C1 and C2 by its memberEnd meta-attribute. In OCL, this reads as follows. let End1 = C1.ownedMember,

End2 = C2.ownedMember,

Ass = Association.allInstances() in collect(a | Ass->includes(a) and a.memberEnd->intersects(End1) and a.memberEnd->intersects(End2) )->notEmpty()

The clear and simple concept of an association is lost in this expression. OQAPI, on the other hand, provides the function associated hiding all the UML complexity behind an intuitive name, and the query simply becomes E1.is associated to().contains(E2). 2.4

Other relationships

Another relationships that is treated in a similar way is containment. While the UML meta-model encodes it by the meta-attribute ownedMember, OQAPI o ers the functions owns and is part of. Likewise for generalization: the UML metamodel encodes this relationship as a part of the specialization that points to the generalization, OQAPI o ers the terms specializes and is generalized by and so on. Observe that OQAPI o ers both the active and the passive form, both for generalizes and specializes, such as to not impose stylistic restrictions on the modeler. Likewise, overloading is used to de ne both set and elementbased variants of predicates.

As a third example, consider a process model expressed by activity diagrams. Suppose, we are looking for Activities that contain Actions unconnected to the initial node. Using OQAPI, this could be expressed by query (4). Concept Main Predicate Syntactic Sugar Predicates type selection classes(),... is class(),... association associates to() associated to(), associated to(INTV), ... element name named() named like() containment owns() is owned by(), contains(), is part of(), owns(INTV), ... generalization generalizes() specializes(), is generalized by(), inherits(), owns(INTV), ... control ow comes after() comes before(), precedes(), succeeds(), is preceded by(), precedes(INTV), ... inclusion includes() is included by(), is included by(INTV), ... extension extends() is extended by(), is extended by(INTV), ... (4) This example also illustrates another aspect: namely these concepts are often intuitively understood as being transitive, while writing recursive queries is a major challenge to many modelers.

Also, notice the (optional) parameter of this predicate: It speci es the length of the path between the nodes in the precedence-relationship. If this parameter is omitted, a distance of one is assumed, i.e., direct precedence. Other values include minimal and maximal distances (see [ 9 ] for more details). 3

Usability Evaluation

In a series of controlled experiments, we analyzed the performance of modelers when using di erent model query languages. In this paper, we report only on the results obtained for two model query languages, the OCL and OCL with OQAPI. Results on other model query languages are reported in [ 5 ] and [ 4 ]. Study Design We created sets of twelve queries (\stimuli") in OCL with and without OQAPI, and a list of 32 plain English descriptions of queries (\responses"). In the rst task, subjects were given ten stimuli and asked to nd matching responses, with zero to four matches being applicable to each stimulus. In the second task, subjects were asked given twelve groups of one stimulus and three alternative responses, one of which was correct. In the third task, subjects were given four responses and asked to create the correct stimulus. In the fourth task, subjects were asked to asses the readability and writability of the query languages, and the subjective e ort and con dence.

The languages in the experiment were named as A to D.1 The instructions were given in print, after completing one task, subjects were instructed not to 1 Recall, that these experiments included not just OCL and OCL+OQAPI. OCL (n=18) Understandability 3.76 1.80 Writability E ort turn back to previous tasks. Subjects were asked to provide additional comments on the questionnaires and in unstructured follow-up interviews.

Observations Probably the most striking observation is that some subjects refused to work on tasks involving the OCL treatment; thus the substantially smaller number of participants for the OCL condition, in particular for the writing task, see Table 2. One of the participants remarked \after [the other] languages, it's hard to get yourself to work on [OCL]. [It] is rather, well, relatively complicated, I kept thinking, jeez, why does it have to be quite as complicated. [The others] are quite easy in comparison, these are easy to understand." Other participant made similar remarks, such as: \All in all it was ok...I found OCL horrible" or \[the other language] was ok, but [OCL] is di cult to understand, you have to follow the algorithm. That's ok, it works, but it's more e ort." Probably the most poignant comment was \[OCL] was really pissing me o ".

Coming to the objective measures (see Table 2), we see that subjects perform better when using OQAPI: subjects score almost 30% better when using OQAPI as compared to using bare OCL. At the same time, the reported e ort (a measure for cognitive load) goes down almost 30%. Most strikingly, the con dence in the correctness of the result increases by almost 60%. Surprisingly, we also see that in the \OQAPI" condition, variances generally increase as when compared to the \bare OCL" condition. For understandability scores, this is only a slight increase that may not be signi cant. However, for con dence, we see an increase of over 60%, and for e ort, we even see an increase of over 80%. Interpretation The observations of the di erent performance scores and load measures are consistent, as are the impressions from the post experiment interviews. The di erences between the two treatments are statistically signi cant, and demonstrate a medium to large e ect size of using OQAPI, in the conventional terminology of Cohen. Together, this implies strong support for our initial hypothesis.

We interpret the massive increase in variance as a sign that there is a strong di erence between individuals in the capacity to take advantage of the support o ered by OQAPI. In other words, on average, everybody bene ts from using OQAPI, but it is easier to use for some people than for others.

Threats to validity While it is always desirable to have larger numbers of data points to achieve better p-values, the e ect size of the phenomenon studied here is such that even the modest n we provide in our study is su cient to achieve statistically signi cant results. A larger threat to validity is the relatively small number of queries sampled in our evaluation. Moreover, we cannot claim that they are representative with any degree of certainty. Clearly, this would require a generally accepted body of sample queries, or a benchmark, both of which are not present in the case of OCL. In fact, as we have remarked earlier, there does not seem to be a single OCL library or API that is published.

Probably the most signi cant threat to validity is the high degree of mortality in this study, that is, the large number of subjects that completed the procedure only partially as described as the beginning of Section 3 above: for the writing task, mortality was 100%. However, in itself this is testament to the very low degree of usability that bare OCL provides, as compared to using OQAPI. 4

Related Work

Many model query languages have been de ned beyond those discussed in this paper, the rst being Constraint Diagrams [ 10 ], Query Models, and Join Point Designation Diagrams [ 11, 12 ]. In the area of business process modeling, there have been many new proposals in the last decade, e.g., the BPQL [ 13 ], BP-QL [ 14 ], BPMN-VQL [ 15 ], BQL [ 16 ], and BPMN-Q [ 17 ]. To our knowledge, none of these have been evaluated with a view to usability.

In contrast to the general interest in de ning new query languages, there seems to be no interest in improving OCL by providing query libraries: Despite our best e ort, we could not nd any published libraries of OCL functions, or de nitions of APIs, for any purpose. We have contacted three leading experts from the OCL community who con rmed this observation. Chimiak [ 3 ] claims to have de ned 50 libraries with 4.5kLOC combined, but these are not published.

The OCL Standard library [ 2 ] de nes only low level functions and operations on container types. The UML standard [ 18 ] does de ne some predicates that appear in OQAPI, but de nes them in an unsystematic way and scattered over the whole UML standard document. The QVT standard [ 19 ] mentions a UmlUtilities library with operations such as getAllAbstractBaseActors (p. 70) and getAllDerivedClasses (p. 72) but there is no reference to or listing of the library as such. QVT also de nes a Standard Library with some useful functions (see [19, pp. 107]) rather similar to those included in the UML. Again, they are not presented as coherent API and su er from the same shortcomings found in the function de nitions of the UML standard. 5

Relevance of OQAPI

Since OCL has existed for almost twenty years now without any libraries published for it, we think it necessary raise the question if relevance: if nobody needed libraries such as OQAPI so far, why now? First of all, APIs are obviously in wide spread use in programming and enjoy great popularity, so it is intuitive to us to assume that OCL users would bene t from similar facilities. In fact, Chimiak [ 3 ] has argued for the extension of OCL to better support the use of libraries like OQAPI, too, highlighting reuse, modularity, and separation of concerns as the main bene ts of such libraries.

Secondly, some people argue that usability is not a major issue, since OCL is supposed to be used only by experts. However, this is not the position of the OMG, which declare usability a major concern: \The disadvantage of traditional formal languages is that they are usable to persons with a strong mathematical background, but di cult for the average business or system modeler to use. OCL has been developed to ll this gap. It is a formal language that remains easy to read and write. It has been developed as a business modeling language [...] " (cf. [2, p. 5]).

Thirdly, it could be argued that the comparison of OCL with and without OQAPI is unfair in a sense, since OCL is primarily a model constraint language targeted at expert modelers. Indeed, some seem to believe that OCL was never intended as a model query language, e.g., \OCL was originally designed speci cally for expressing constraints about a UML model " (cf. [20, p. 91]) and \OCL was not originally designed to be a query language " (cf. [20, p. 102]). However, the OCL standard itself makes it quite clear that OCL has indeed been created with both constraining and querying models in mind: \[OCL] expressions typically specify invariant conditions [...] or queries over objects described in a model." (cf. [2, p. 5]).

Finally, and rather ironically, more evidence for the relevance of OQAPI is provided by the UML and QVT standards themselves: when inspecting these documents closely, we found a sizable number of instances where auxiliary functions are de ned that perform a part or a special case of an OQAPI function (see Table 3). In some cases, these functions were de ned repeatedly, sometimes under di erent names. 6

Discussion

In previous research, we created several model query languages, each of which provided higher usability than OCL. None of these, however, is a practical alternative to OCL, due to the lack of supportive materials, mature tool implementations, existing knowledge base and so on. In this paper, we apply the lessons learned from our previous work to de ning the OCL Query Library (OQAPI). A conservative extension to OCL such as this does not share the weaknesses of our previous approaches: it is easy to deploy wherever OCL is already in use. Thus, OQAPI trades reduced usability for extended usage scenarios.

[ 3 ] has clearly identi ed the need for OCL libraries. Still, however, it seems that no such libraries have been published, ever: none of the OCL experts we have consulted was aware of any such library. So, OQAPI is a rst step to addressing a practical need, and our evaluation demonstrates the bene t of using OQAPI in an empirical way. En passant, it provides evidence to the common perception that OCL is di cult to use.

References

1. Dijkman , R. , Rosa , M.L. , Reijers , H.A. : Editorial: Managing large collections of business process models-Current techniques and challenges . Comput. Ind . 63 ( 2 ) ( February 2012 ) 91 { 97

2. OMG: UML 2.2 OCL Speci cation (formal/2010-02-01). Technical report , Object Management Group ( February 2010 )

3. Chimiak-Opoka , J.: OCLLib, OCLUnit, OCLDoc: Pragmatic Extensions for the Object Constraint Language . In Schurr, A. , Selic , B., eds. : Proc. 12th Intl. Conf. Model Driven Engineering Languages and Systems (MoDELS'09). Number 5795 in LNCS . Springer Verlag ( 2009 ) 665 { 669

4. Storrle, H.: VMQL: A Visual Language for Ad-Hoc Model Querying . J. Visual Languages and Computing 22 ( 1 ) ( February 2011 )

5. Storrle, H.: MOCQL: A Declarative Language for Ad-Hoc Model Querying . In Van Gorp, P. , Ritter , T. , Rose , L.M., eds.: Eur. Conf. Proc. Modelling Foundations and Applications (ECMFA) , Springer Verlag ( 2013 ) 3 { 19

6. Bottoni , P. , Koch , M. , Parisi-Presicce , F. , Taentzer , G.: A Visualisation of OCL Using Collaborations . [ 21 ] 257 { 271

7. Storrle, H.: A PROLOG-based Approach to Representing and Querying UML Models . In Cox , P. , Fish , A. , Howse , J., eds. : Intl. Ws. Vis. Lang. and Logic (VLL'07) . Volume 274 of CEUR-WS ., CEUR ( 2007 ) 71 { 84

8. Storrle, H.: A logical model query interface . In Cox, P. , Fish , A. , Howse , J., eds. : Intl. Ws. Visual Languages and Logic (VLL'09) . Volume 510 ., CEUR ( 2009 ) 18 { 36

9. Storrle, H., Acretoaie , V. : Querying Business Process Models with VMQL . In Roubtsova, E., Kindler , E. , McNeile , A. , Aksit , M., eds. : Proc. 5th ACM SIGCHI Ann. Intl. Ws. Behaviour Modelling { Foundations and Applications , ACM ( 2013 )

10. Kent , S.: Constraint Diagrams: Visualizing Invariants in Object-Oriented Models . In: Proc. 12th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications. OOPSLA'97 , ACM ( 1997 ) 327 { 341

11. Stein , D. , Hanenberg , S. , Unland , R.: Query Models . In Baar, T., Strohmeier , A. , Moreira , A. , Mellor , S.J., eds. : Proc. 7th International Conference on the Uni ed Modeling Language (UML'04) . Volume 3273 of LNCS., Springer ( 2004 ) 98 { 112

12. Stein , D. , Hanenberg , S. , Unland , R.: Join Point Designation Diagrams: A Graphical Representation Of Join Point Selections. Int. J. Softw. Eng. Knowl. Eng . 16 ( 3 ) ( June 2006 ) 317 { 346

13. Momotko , M. , Subieta , K. : Process Query Language: A Way to Make Work ow Processes More Flexible . In Benczur, A. , Demetrovics , J. , Gottlob , G., eds. : Proc. 8th East Eur. Conf. Advances in Databases and Information Systems , Springer Verlag ( 2004 ) 306 { 321

14. Beeri , C. , Eyal , A. , Kamenkovich , S. , Milo , T. : Querying business processes with BP-QL . Inf. Syst . 33 ( 6 ) ( September 2008 ) 477 { 507

15. DiFrancescomarino , C. , Tonella , P. : Crosscutting Concern Documentation by Visual Query of Business Processes . In Ardagna, D., Mecella , M. , Yang , J., eds. : Bus. Proc. Mgmt , Ws., Springer Verlag ( 2009 ) 18 { 31

16. Jin , T. , Wang , J. , Wen , L. : Querying Business Process Models Based on Semantics . In Yu, J.X. , Kim , M.H. , Unland , R., eds. : Proc. 16th international conference on Database systems for advanced applications (DASFAA'11): Part II. Volume 6588 of LNCS ., Springer ( 2011 ) 164 { 178

17. Awad , A. , Sakr , S. : On e cient processing of BPMN-Q queries . Comp. Ind . 63 ( 9 ) ( 2012 ) 867 { 881

18. OMG: OMG Uni ed Modeling Language (OMG UML) , Superstructure, V2 .2 ( formal /2009-02-02). Technical report , Object Management Group ( February 2009 )

19. OMG: Meta Object Facility (MOF) 2 .0 Query/View/Transformation Speci cation Version 1.1. Final Adopted Speci cation (ptc/09-12-05) . Technical report , Object Management Group ( December 2009 )

20. Akehurst , D.H. , Bordbar , B. : On Querying UML Data Models with OCL . [ 21 ] 91 { 103

21. Gogolla , M. , Kobryn , C., eds. : Proc. 4th Intl. Conf. Uni ed Modeling Language ( UML '01) . In Gogolla, M. , Kobryn , C., eds. : Proc. 4th Intl. Conf. Uni ed Modeling Language ( UML '01). Number 2185 in LNCS , Springer Verlag ( 2001 )