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:[email protected], {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