Query by Drawing Examples of UML Model

Xuelin Zhang∗†, Tian Zhang1∗† and Xuandong Li∗†∗State Key Laboratory for Novel Software Technology, Nanjing University†Department of Computer Science and Technology, Nanjing University

Nanjing, Jiangsu, P.R. China 210046Email:zhangxl@seg.nju.edu.cn, {ztluck,lxd}@nju.edu.cn

Abstract—With the development of model driven architec-ture(MDA), the number of models being used and producedis increasing. Comprehending and reusing models face a realchallenge. Model query is put forward to solve these problems.Most people chose using OCL as the query language. However,OCL is a textual query language, it isn’t powerful enoughand always generates very complex query statements even fora simple query. We think that a graphical representation tospecify queries on UML models could facilitate the softwaredevelopers’ comprehension on what a query pattern looks like,because of that it is easier to be understood and much morevisual. In this paper, we propose a model query method whichis queried by drawing examples of the UML model. This querymethod is based on the graphical representation we presentedin this paper.

Keywords-Model Query; Query by Drawing Example;Graphical Representation; Query Language;

I. INTRODUCTION

Unified Modelling Language(UML) [12] has been widely

used for modeling, and models are becoming increasingly

important in the software development process. As a conse-

quence, an increasingly large number of models are being

produced and used by software organizations. Models are

becoming too complex to be comprehended. At the same

time, the reuse problem is extended to models in addition

to code and other artifacts, because of that the difficulties in

finding reusable models are greater. In order to overcome

these handicaps, model query is put forward. Querying

models can not only help to comprehend and reuse models of

the system but also have an important educational benefit for

students and teachers, allowing learners to find good or bad

examples that can then be used to improve the acquisition

of knowledge and provide hints at solutions [2].

However, methods to realize model query are various.

The Object Constraint Language (OCL) is a precise text

language that provides constraints and object query expres-

sions on UML model that cannot otherwise be expressed

by diagrammatic notation [11]. Since the specification of

the OCL mentions ”query language” as one of its possible

applications, lots of researchers try to form a query language

based on OCL and extensions to it [3] [4] [5] [7] [8]. In view

of the fact that OCL was originally designed specifically

1 Corresponding author

for expressing constraints about an UML model, it is not

a specialized language for querying models. What’s more,

using OCL as the query language would generate very

complex expressions even when defining a relatively small

number of selection criteria.

We have proposed an UML model query method which

is based on structure pattern matching not long ago. In that

method, we use a textual model query language which is

designed by us to specify queries on UML models. Although

we have made great efforts to make the query language more

concise, it still needs lots of statements to define a query

pattern.

It is obvious that using a textual query language, just like

OCL or the query language we designed, will lead to very

complex query statements ineluctably. And it is very difficult

to comprehend the queries which the textual query language

specifies. We think that a graphical representation to specify

and visualize the model queries is an inevitable trend of

MDA. Dominik gave a graphical notation to specify model

queries for MDA transformations on UML models using

JPDDs [6]. A graphical representation of selection queries

could facilitate the software developers’ comprehension on

what a query pattern looks like, because of that it is much

more visual. And it is very clear and easy to be understood,

it doesn’t like the textual query language that would quickly

turn out to generate very complex expressions even for

simple queries.

In this paper, we propose a model query method which

is queried by drawing examples of UML model. This query

method is based on the graphical representation we presented

in this paper, and it is the improvement of the query method

we proposed before. With the graphical representation, we

can draw the query patterns first, and then query by the

drawn examples, that is very similar with the ideas of Zloof’s

Query-By-Example, like OOQBE [10] and UQBE [9]. It

is necessary to mention that we put forward the graphical

representation of queries on UML models is for the purposes

of describing the query patterns in a more visual and

comprehensible way and building the foundation for drawing

examples. The query pattern here is acted as the input or

the target model in our query method. Query by drawing

examples could leave more freedom and convenience to

users. By this way, model query will not be so difficult and

Postgraduate Symposium

2012 19th Asia-Pacific Software Engineering Conference

1530-1362/12 $26.00 © 2012 IEEEDOI 10.1109/APSEC.2012.65

154

2012 19th Asia-Pacific Software Engineering Conference

1530-1362/12 $26.00 © 2012 IEEE

DOI 10.1109/APSEC.2012.65

154

Figure 1. Model Query Framework

complex any more. We will briefly describe our model query

method presented before in the background, and then present

the graphical representation, show that how to specify the

query patterns in a graphical way and how to query by

drawing examples.

The rest of this paper is organized as follows: In section

II, we briefly sketch the background that the query method

we proposed before. Section III describes how to present

the query patterns in a graphical way. Section IV gives a

case study to show that how to query by drawing examples,

taking advantages of the graphical representation. Section V

concludes the paper and presents our plans for future work.

II. BACKGROUND

Because of the fact that a large number of models have

been produced, comprehending models and finding reusable

models in a mass of system models are becoming much more

difficult. The concept of model query is put forward in this

background. Most of the researchers propose using OCL

as a query language. However, query expressions formed

with OCL even don’t have the same expression power as

those formed with relational algebra [1]. And it can’t satisfy

all kinds of query patterns. For example, a pure structure

pattern which doesn’t have any feature values or names, just

a structure, can’t be treated as the input pattern or the target

query model with OCL query language. In order to make the

query language more general and support for more queries,

we proposed an UML model query method which is based

on structure pattern matching. It is a much more general

method, which can satisfy most queries.

Our model query method is much different from that

queried by OCL. The kernel of our query method is the

structure pattern matching. Before that, two things should

be prepared, one is the target model pattern and the other

one is the system model which will be queried from. And

another thing should be done is that extracting necessary

model elements from the model file according to the OMG’s

DTD standard [13]. We do the extraction because of that the

model file is very complex and has lots of information we

don’t need. We can see the query framework from figure 1.

We designed a textual model query language to describe

the query pattern. Although it is very clear and easy to

understand, it still needs too many statements to specify

Figure 2. Graphical Representation of Attribute

a query because of that it is a textual query language. In

order to make specifying queries be much easier and more

visual, we decide to use a graphical representation to specify

the query pattern. We think that a graphical representation

of queries is much more clear and easier to be understood.

With the graphical representation, we can query by drawing

examples of the UML model. It is such a wonderful thing.

III. GRAPHICAL REPRESENTATION

The graphical representation is mainly for the purpose of

describing the query pattern in a visual way. By this way,

the query pattern can be more comprehensible. A graphical

representation can be formed through various ways, such as

edited by the UML tools and draw it directly. We think that

drawing directly is much more convenient and acceptable

in model query. In the following, we will present that how

the core model elements in UML represented in a graphical

way.

A. Classifier Graphical Representation

In the graphical representation of query patterns, the

model elements are much similar with that in the UML

model for the purpose that the model elements presented in

the graphical way are easy to be understood and identified.

In the case of Class, the graphical representation is just like

the Class element in the class diagram of UML. And all the

elements such as Attributes and Operations are in the same

graph, which can be seen from figure 2.

1) Attribute: Figure 2 mainly show the graphical repre-

sentation of the Attribute in Class. As we know, an attribute

has several properties such as ’name’, ’type’, ’visibility’,’scope’, ’initial value’ and ’multiplicity’. An attribute can be

selected by one or multiple of them. And all these properties

could be reflected in the graphical representation of the

Attribute.

In the second grid of figure 2, two different kinds of

attributes are presented. Each element in the graph has its

own meaning, indicating different properties in the attribute.

For example, the two numbers in the little box on the left

of the first attribute are corresponding to the multiplicityproperty. One of the two numbers is the lower bound and

the other one is the upper bound. And the symbol ’+’

following the multiplicity property indicates that this is a

public attribute. Each attribute may belong to one of three

kinds of visibility, they are public, protect and private. Next

Postgraduate Symposium

155155

Figure 3. Operation Graphical Representation

to the visibility property are name, type and initial value.

The underline shows the static scope of the attribute. At last,

note that any property you want to be the query criterion,

just add a red confirmed symbol right above that property.

2) Operation: The Operation’s graphical representation

can be seen in the third grid of figure 3. As usual an Opera-tion has several properties too, they are ’name’, ’visibility’,’scope’, ’return value’ and ’parameter number’. As we can

see from figure 3, the graphical representation of Operationis almost the same with that in the UML model, such as the

visibility symbol ’+’ means that this is a public operation.

Next to the visibility property is the operation name. And the

values between parentheses are the parameters list. Though,

of course, you just need to provide the parameters that you

know and use ’. . . ’ to take the place of the parameters that

be omitted. The number of parameters can be marked in the

bottom right corner out of the parentheses. The last property

on the rightmost of the operation is the return type. Much

similar with the Attribute, the Operation also demonstrates

that whether it is static or not through an underline, and add

a red confirmed symbol right above the property to let it be

the query criterion.

B. Relationship Graphical Representation

Relationships are various such as ’Generalization’, ’De-

pendency’, ’Realization’, ’Abstract’ and so on. They are

the relations between classes in the class diagram. We

found some interesting phenomena during modeling using

the UML class diagram.

1) Phenomenon One: One of the interesting phenomena

is that one class may don’t have a relation with another class

directly, but it may keep a relation with that class through

many layers, for example a class may inherit from another

class through multiple generalization relationship. In this

situation, we just need to let ’R’ in figure 4(a) be ’N’ in

the graphical representation. By this way, we can deal with

this situation during the query process.

2) Phenomenon Two: In some cases, a developer can’t

remember the detail structure of model clearly, for example

he doesn’t know the relationship between two classes, but

he wants to regard these two classes and the relationship

between them as a query pattern. However, he doesn’t know

how to represent this relationship. In this situation, let ’R’be ’*’ which indicates that it could be any relationship. By

this way, the fuzzy query can be processed well.

Figure 4. Relationship Graphical Representation

Figure 5. System Model Segment

3) Phenomenon Three: Sometimes, multiple classes may

have the same relationship with another one. In consideration

of this, we take some measures to deal with this case. The

’OP’ in figure 4(b) can be set different logical values such

as ’AND’ and ’OR’ which means different combinations. If

the value of ’OP’ is ’AND’, that means all the classes must

have the same relationship at the same time. Otherwise, if it

is ’OR’, just need part of them have this relationship. This

symbol ’OP’ makes it much more convenient to deal with

some complex relations during the query process.

Although we can’t list all the situations about relationships

in modeling, the graphical symbols have been presented

can deal with some cases already. If we discover some

new phenomena, we will take some new measures to deal

with that later. All symbols in the graphical representation

of relationships are selected through adding a confirmed

symbol right beside it just like that in figure 4.

IV. CASE STUDY

In order to verify that our query method based on structure

pattern matching is effective, vast of experiments have

been done. We also did experiments on some open source

projects, like Vuze, which is the most powerful bittorrent app

on earth.

Here we will demonstrate that how to query by drawing

examples. One of the system model segments can be seen

in figure 5. Now we want to query a model structure of the

Adapter design pattern which is on the left side of figure 6.

And four elements are considered as the selection criteria,

Postgraduate Symposium

156156

Figure 6. Graphical Representation of Query Pattern and The Query Result

they are ’Generalization’, ’Dependency’, one attribute name

’ tasks’ and its type ’HashMap’. So we just need draw three

classes and mark the four elements with a confirmed symbol.

It is obvious that we can get one result which is on the right

side of figure 6, after processing and querying. Although we

don’t query the drawn example in the experiment actually,

we believe that it isn’t very difficult to implement and it

demonstrates that our method is feasible and convenient

more or less. It shows that query by drawing examples using

the graphical representation of query patterns can do a good

job. If it can be adopted into the process of model query, it

is really an exciting and interesting thing.

V. CONCLUSION

In this paper, we proposed a model query method which

is queried by drawing examples of the UML model. And

this query method is based on the graphical representation

we presented. First of all, we showed that a textual query

language isn’t powerful enough, it always generates very

complex query statements even for a simple query. This is

the reason that we put forward a query method that queried

by drawing examples taking advantages of the graphical

representation. Then, in the background we briefly described

our previous work about an UML model query method

which is based on structure matching. In that work we

designed a textual model query language which is different

from OCL to describe the query patterns. However, it has

the same shortcomings with other textual query language.

So, we think out the graphical representation of queries to

help describing the query patterns. In the following of this

paper, we introduced the graphical representation in detail.

After that we gave a case to show how to query by drawing

examples of UML model using the graphical representation

and thought that it is a wonderful thing.

Although we have put forward a query method that

queried by drawing examples of the UML model and given

some graphical representation in UML models, they are not

all-inclusive, lots work have to be done in the future. We

think that we could focus on these aspects in the future: one

is that we should give the entirety of graphical representation

as possible as we can. Now we don’t have a graphical

interface for drawing the query pattern, that will be done

later. Although it may be a little difficult to parse the drawn

examples of model, we believe that we can realize the idea

of Query-By-Example in the near future. At last, all the work

above have finished, we can transfer this approach to other

model languages and make it general.

ACKNOWLEDGMENT

This work is supported by the National Natural Science

Foundation of China (No.61003025, 91118002), and by the

Jiangsu Province Research Foundation(BK2010170).

REFERENCES

[1] David H. Akehurst, Behzad Bordbar: On Querying UML DataModels with OCL. The Unified Modeling Language - UML ,91-103 (2001)

[2] Daniel Lucrdio, Renata P. de M. Fortes, Jon Whittle:MOOGLE: a metamodel-based model search engine. Softwareand System Modeling - SOSYM , vol. 9, no. 3, 1-26, (2010)

[3] Piotr Habela, Krzysztof Kaczmarski, Krzysztof Stencel, Kaz-imierz Subieta: OCL as the Query Language for UML ModelExecution. International Conference on Computational Science- ICCS , 311–320 (2008)

[4] Maxim Grinev, Sergei D. Kuznetsov: UQL: A UML-basedQuery Language for Integrated Data. Programming and Com-puter Software , vol. 28, no. 4, 189-196, (2002)

[5] Dominik Stein, Stefan Hanenberg, Rainer Unland: Query Mod-els. The Unified Modeling Language - UML , 98-112, (2004)

[6] Dominik Stein, Stefan Hanenberg, Rainer Unland: A GraphicalNotation to Specify Model Queries for MDA Transformationson UML Models. Model Driven Architecture Foundations andApplications - MDAFA, 77-92, (2004)

[7] Luis Mandel, Marła Victoria Cengarle: On the ExpressivePower of OCL. World Congress on Formal Methods - FM, 854-874, (1999)

[8] Ahmed Gaafar, Sherif Sakr: Towards a Framework for Map-ping Between UML/OCL and XML/XQuery. The UnifiedModeling Language - UML , 241-259, (2004)

[9] Miguel A. Sicilia Urban, Elena Garcıa Barriocanal, Juan Bear-do: Towards a Unified Query-by-Example (UQBE): UML as aBasis for a Generic Graphical Query Language. InternationalWorkshop on Distributed Object Management/Workshop onObject-Oriented Database Systems - IWDOM/OODBS, 185-196, (2000)

[10] Staes F., Tarantino L.: OOQBE: An Intuitive Graphical QueryLanguage with Recursion. Human-Computer Interaction - HCI,603-608, (1993)

[11] Object Management Group: Object Constraint Language ver-sion 2.0 (May 2006), http://www.omg.org/cgi-bin/doc?formal/2006-05-01

[12] Object Management Group: Unified Modelling LanguageSpecification, version 1.3, formal/2001-09-67, http://www.omg.org/spec/UML/1.3/PDF

[13] Object Management Group: XML Metadata Interchange, X-MI 1.1 RTF UML DTD http://www.omg.org/cgi-bin/doc?ad/99-10-05

Postgraduate Symposium

157157