=Paper=
{{Paper
|id=Vol-1092/schuetze
|storemode=property
|title=Tool-Supported Step-By-Step Debugging for the Object Constraint Language
|pdfUrl=https://ceur-ws.org/Vol-1092/schuetze.pdf
|volume=Vol-1092
|dblpUrl=https://dblp.org/rec/conf/models/SchutzeWD13
}}
==Tool-Supported Step-By-Step Debugging for the Object Constraint Language==
https://ceur-ws.org/Vol-1092/schuetze.pdf
Tool-Supported Step-By-Step Debugging
for the Object Constraint Language
Lars Schütze, Claas Wilke, and Birgit Demuth
Technische Universität Dresden
Software Technology Group, Dresden, Germany
{lars.schuetze|claas.wilke|birgit.demuth}@tu-dresden.de
Abstract. Although originally designed as an extension for the Uni ed
Modeling Language (UML), the Object Constraint Language (OCL) has
been broadly adopted in the context of UML as well as other modeling
and domain-speci c languages. However, appropriate tooling, supporting
software developers on using OCL is still scarce and lacks debugging
support. As OCL constraints are likely to become rather complex for real
world examples, it is typically hard to comprehend the in uence of single
OCL expressions on the result of an evaluated OCL constraint. Therefore,
debugging is of topmost importance for both constraint comprehension
and maintenance. In this paper, we evaluate existing debugging tools for
OCL and come to the conclusion that no real step-by-step debugger for
OCL exist, yet. Therefore, we analyze requirements for OCL debuggers
and present an OCL debugger implementation for Dresden OCL.
Keywords: OCL, Debugging, Tracing, IDE4OCL.
1 Introduction
Within the last 20 years, the Object Constraint Language (OCL) [1] has become
a widely adopted constraint language used in the context of the Uni ed Mod-
eling Language (UML) [2] as well as transformation languages like Query View
Transformation (QVT) [3], and other domain-speci c modeling languages [4].
However, for the further acceptance of OCL in research and industrial appli-
cation, adequate tooling for an IDE4OCL is still missing [5]. An online survey
conducted by Chimiak-Opoka et al. among more than 100 OCL users in 2009
and 2010 revealed, that the most-wanted features for such integrated develop-
ment environments (IDEs) comprise adequate OCL debugging and refactoring
support [6].
Whereas refactoring focuses on the maintenance and optimization of OCL
expressions, debugging allows for their systematic execution, and therefore, the
identi cation of implementation faults within OCL constraints [5]. Although
OCL refactoring has been investigated and implemented for existing tooling
recently [7,8], accurate support for OCL debugging is still an open task. First ap-
proaches support OCL evaluation tracing [9], butto the best of our knowledge
no real step-by-step debugging for OCL exist, yet. Thus, in this paper, we present
73
a step-by-step debugger for OCL, implemented for an open-source OCL tool,
namely Dresden OCL . We identify requirements for OCL debugging and eval-
1
uate existing OCL tools w.r.t. their support for OCL debugging. Afterwards, we
present our implementation of a step-by-step debugger for Dresden OCL.
The remainder of this paper is structured as follows. In Sect. 2 we de ne
the term OCL debugging as understood in this paper. Afterwards, in Sect. 3
we identify requirements and useful features for step-by-step OCL debuggers.
Following, we investigate OCL and OCL-related tools in Sect. 4 w.r.t. the iden-
ti ed requirements for OCL debugging functionality. Finally, Sect. 5 outlines our
implementation for OCL debugging and Sect. 6 concludes this paper.
2 Background
The use of debugging has a long tradition in electronics and computer science.
Thus, various de nitions and understandings of the term debugging exist. Since
the 1960s, debugging is recognized as a process of nding and correcting bugs
(errors, defects) in computer programs. However, debugging is often explained
as the process of correcting syntactic and logical errors, detected during coding
only [10]. Within the same meaning, Sommerville emphasizes in his software
engineering text book [11] that debugging and defect testing are dierent pro-
cesses: defect testing establishes the existence of defects; debugging is concerned
with locating and correcting these defects. A state-of-the-art debugging tool,
mostly called a debugger , generally provides both functionalities. It is used to
test and debug programs [12], and oers functions such as
Step-by-step execution of a program one at a time: therewith the pro-
line
grammer may examine the state of related data, before and after execution
of a particular line of code,
Breaking or stopping the program to examine the current state at a speci ed
instruction by means of a breakpoint,
Tracing the values of variables,
Modifying the program state while it is running,
Logging of debugging activities,
(Semi-)Automating test case generation out of logged debugging results.
Although some of these debugging aspects can be considered as being highly
related to imperative languages (e.g., step-by-step execution of a program exe-
cuting one line at a time), similar functionality is also required for declarative
and side-eect free languages such as the OCL. Although each OCL constraint or
query may be expressed as one single line of code, this line of code can comprise
many tree-structured OCL expressions which are evaluated during interpretation
in a visitor-based manner. Thus, for OCL programmers it is helpful in analyzing
bugs to know the immediate results of each subsequent constituent of an OCL
expression. Therefore, we test and debug individual OCL expressions instead
1
http://www.dresden-ocl.org/
2
74
1 context Person:
2 inv: getChildren()->size() >= 0
Listing 1. An example OCL constraint.
1 context Person def: getAge() : Integer =
2 self.age + (if self.hadBirthday then 1 else 0 endif)
Listing 2. A constraint with an if expression.
of imperative program statements that are typically coded by one statement
per (code) line. Besides step-by-step execution of OCL sub-expressions, OCL
programmers are interested in tracing the values of variables as well as using
conditional breakpoints in an expression to examine their current state. We call
this technique .
step-by-step debugging
3 Requirements
In the following, we discuss requirements and useful features for step-by-step
OCL debuggers. The requirements emerge from the debugging features described
by Zeller [12] outlined above, as well as from an analysis of the functionality pro-
vided by existing OCL debuggers such as USE [9] and debug tools for imperative
programming languages such as the Eclipse Java development tools (JDT) . 2
/R1/ Step-by-step debugging A step-by-step OCL debugger should support
step-wise debugging of OCL expressions. The debugger should suspend its OCL
evaluation when reaching a breakpoint de ned on an OCL expression. Such a
breakpoint could be either de ned on the respective OCL expression in an OCL
editor (concrete syntax), or by marking the respective OCL expression in a tree-
based presentation of nested OCL expressions (abstract syntax).
As OCL is a
declarative language, a single line of OCL code in concrete syntax is likely to
/R1.1/ Highlighting the currently interpreted OCL expression
contain several OCL expressions (e.g., the OCL constraint given in Listing 1 con-
sists of three operation call expressions, one integer literal expression and one
implicit variable call expression referring to the variable). Thus, if an OCL
debugger is suspended during interpretation, it should highlight the currently
self
evaluated OCL expression within an OCL editor, or within a tree-base represen-
tation of its abstract syntax, or optimally, both. For the given example, either
one operation call, the integer literal or the whole constraint (at the beginning
or the end of the constraint's interpretation) should be highlighted.
2
http://projects.eclipse.org/projects/eclipse.jdt
3
75
Tree-based: :ExpressionInOcl Stack-based:
>= : OperationCallExp
source parameters
size() : OperationCallExp 0 : IntegerLiteralExp
source
size() : OperationCallExp
getChildren() : OperationCallExp
>= : OperationCallExp
source
self : VariableExp :ExpressionInOcl
Legend: Interpretation Started Current Position of Interpreter Interpretation Not Yet Started
Fig. 1. Tree- and stack-based representation of an OCL constraint during debugging.
Existing debuggers (e.g., debuggers based on the Eclipse
debugging framework) support dierent kinds of stepping for step-by-step de-
/R1.2/ Stepping support
bugging; namely , and
step into step over . OCL debuggers shouldstep return
support these three kinds of debugging steps. For example, for the if expression
shown in line 2 of Listing 2 and the current position of the interpretation be-
ing after the evaluation of the to , a
condition self.hadBirthday step into
would continue the evaluation and suspend again in front of the expression
true
, whereas a and a would both result in a suspension in
then
step over step return
front of the the operation.
1
+
/R2/ Visualization of the visited OCL expressions During OCL inter-
pretation, nested OCL expressions are evaluated in a visitor-like manner. To
visualize the currently evaluated OCL expressions, OCL debuggers should visu-
alize the visited OCL expressions either in a tree-based or stack-based manner.
For example, for the OCL invariant shown in Listing 1 and the interpretation
being suspended at the operation call, the tree- and stack-based repre-
sentations of the currently evaluated OCL constraint are shown in Fig. 1.
size()
/R3/ Visualization of results for evaluated OCL expressions Although
the visualization of the currently evaluated OCL expressions in a tree- or stack-
based manner can ease the understanding of OCL interpretation, an OCL de-
bugger should visualize the results of already evaluated nested OCL expressions,
giving an overview on all evaluated expressions and their results, and thus, the
causes for the sub-expressions being evaluated in the following (e.g., for an if ex-
pression this visualization would show the evaluated condition as well as whether
the or the branch have been evaluated). If a tree-based visualization for
the currently evaluated OCL expression is used (/R2/), the same visualization
then else
can be used by annotating the nodes in the tree with their evaluation results.
4
76
Although the tree-based visualiza-
tion may be helpful to further understand the evaluation of an OCL expression,
/R3.1/ Filtering of evaluated sub-expressions
it can also contain too much information in some scenarios. Therefore, OCL de-
buggers can provide support ltering the expression trace (e.g., sub-expressions
causing the nal result to be instead of could be shown exclusively
to detect bugs in invariants) [9].
false true
Similar to other interpreters,
OCL interpreters can be optimized to skip the evaluation of sub-expressions hav-
/R3.2/ Visualization of unnecessary sub-expressions
ing no impact onto the nal result of a nested OCL expression (e.g., for the eval-
uation of an expression , has not to be evaluated, if results in ).
Further examples are iterators whose interpretation can be cancelled if one vis-
(a or b) b a true
ited element ful lls the iterator's condition (e.g., for the iterator). However,
it can be helpful to fully interpret such OCL expressions and to present their
any
results in the tree-based evaluation trace, as the evaluated expressions letting
their evaluation being super uous may contain bugs as well [9].
/R4/ Tracing of variable values During debugging, the values of currently
visible and accessible variables should be presented, to ease the understanding
of the current program state. For OCL debuggers, all variables de ned in ex-
pressions as well as possible parameters emerging from the constraint's context
let
(e.g., when interpreting a or constraint of an operation having argu-
ments) should be visualized. Besides, already evaluated expressions should be
pre post
visualized as well. For example, consider the interpretation of the expression
shown in line 2 of Listing 2, being suspended after interpreting the
if
condition
of the expression. At this point in time, the evaluated value of the condition
should be visualized as well to ease the understanding for the user why either
if
the interpretation of the expression, or the expression will follow. Fur-
thermore, the the variable for the currently interpreted constraint should
then else
be visualized; as well as further prede ned variables (e.g., the variable, if
self
a constraint is interpreted).
result
post
/R5/ Conditional breakpoints For existing debuggers (e.g., the Java debug-
ger of the JDT), it is very common to provide conditional breakpoints. Thus,
breakpoints can be annotated with Boolean conditions, specifying whether or
not the debugger should suspend, when the breakpoint is reached. For OCL de-
buggers, these conditions should support references to variables, operations and
properties visible at the OCL expression(s) corresponding to the breakpoint.
/R6/ Watch expressions Besides conditional breakpoints, existing debug-
gers support watch expressions. Watch expressions are additional expressions
being evaluated for the current context of an interpretation. For example, if
the debugger is suspended during the interpretation of a constraint de ned on
a Person class, a watch expression could contain a call to an operation of this
5
77
/R1/ /R1.1/ /R1.2/ /R2/ /R3/ /R3.1/ /R3.2/ /R4/ /R5/ /R6/ /R7/
USE - - - X X X X X - - -
SQUAM OCL - - - - X - - - - - -
QVT-O (X) - - X - - - X X X -
MDT/OCL - - - - - - - - - - -
Dresden OCL X X X X X (X) - X - - -
Table 1. OCL (related-)tools and the requirements they support for OCL debugging.
class (e.g., ). The expression could help the user to further evaluate the
current state of the objects being interpreted, besides the variables visible in the
getAge()
variables view.
/R7/ Program and program state modi cation As introduced in Sect. 2,
debugging can include the modi cation of the debugged program, while it is run-
ning. For example, the JDT Java debugger allows hot code replacement during
debugging. In the context of OCL, several dierent modi cations while debug-
ging an OCL constraint are possible. First, the debugged constraint itself can be
modi ed to x bugs while debugging the constraint in a certain context (e.g.,
a Boolean literal could be xed to be instead). Second, besides the
constraint, the model, the constraint is referring to can be modi ed (e.g., an
false true
operation's semantics given in the model could be modi ed during debugging).
Third, the state of the model instance, in which context the constraint is cur-
rently debugged, can be modi ed (e.g., the ) of a being the context of
a constraint could be modi ed). Finally, the modi cation of visualized variables'
age Person
values or the evaluation results of individual OCL expressions in the tree-based
evaluation view could be supported, to check the direct impact of other values
during debugging.
4 Related Work
Besides Dresden OCL, other OCL and OCL-related tools exist (e.g., the UML-
based Speci cation Environment (USE), the Systematic Quality Assessment of
Models OCL Tool (SQUAM OCL), Eclipse MDT/OCL, and QVT-O). In the
following, we investigate these tools regarding their support for OCL debugging,
and name the requirements supported by our current implementation of an OCL
debugger for Dresden OCL. A summary of the requirements supported by all
tools discussed below is given in Table 1.
USE oers an
3 visualizing the evaluation of OCL ex-
evaluation browser
pressions as a tree [9]. The evaluation browser can be considered as an OCL
debugger (without support for step-wise OCL debugging), supporting the re-
quirements /R3/ and /R2/. Besides, the evaluation browser can be ltered (e.g.,
3
http://sourceforge.net/projects/useocl/
6
78
to show failed evaluations only and to examine the root cause of the failure or
unexpected result), supporting the requirements /R3.1/ and /R3.2/. Apart from
that USE provides variable tracing /R4/.
SQUAM OCL oers the ability to trace the evaluation of selected OCL
4
expressions on a single model element. The trace is presented as text output on
the console listing all evaluation steps and their results. Therefore, SQUAM OCL
OCL can be considered as supporting the requirement /R3/ in a text-based
manner.
Although the QVT-O tools of the Eclipse modeling tools do not support
5
OCL debugging, they support debugging of QVT-O expressions, which can be
considered as rather similar functionality, as QVT-O includes OCL expressions.
The QVT-O debugger is integrated into the Eclipse environment and oers a
large subset of debugging functionality for QVT-O such as stepping /R1/, a
variables view /R4/, conditional breakpoints /R5/, and watch expressions /R6/.
However, although the QVT-O debugger supports line-based stepping, stepping
at the OCL expression level (/R1.1/ and /R1.2/) is not supported, as stepping
is only possible for individual lines of QVT-O code in the QVT-O editor.
Another widely used OCL tool is MDT/OCL provided by the Eclipse model-
ing tools . MDT/OCL currently does not oer interactive debugging support. At
6
best, its OCL Console can be used to evaluate partial OCL expressions. However,
OCL debugging is planned to be realized for subsequent releases . 7
Following, we shortly name the requirements supporty by our implementation
of an OCL debugger for Dresden OCL presented in the subsequent section. Our
solution supports step-by-step debugging /R1/ (including its sub-requirements
and the visualization of visited OCL expressions /R2/. Besides, variable trac-
ing /R4/ and expression tracing /R3/ are supported. The sub-requirement for
ltering /R3.1/ is partly supported, as expressions can be ltered w.r.t.
and values. The evaluation of unnecessary OCL expressions /R3.2/ is not
true
supported. Conditional breakpoints /R5/, watch expressions /R6/ and program
false
state modi cation /R7/ are targets for enhancements in future works.
Apart from debuggers for OCL, debuggers for other declarative languages
exist. Cabellero et al. present a debugging framework for SQL views [13]. Their
tool visualizes the computation of an SQL view as a computation tree (similar
to a tree-based representation of OCL expressions), allowing users to inspect
the computation results of individual nodes within the computation tree and
mark their results as being either correct or incorrect to detect sub statements
or nested views causing the erroneous result of an SQL view. A more advanced
SQL debugging tool is proposed by Herschel et al. [14]. Their Eclipse-based tool
allows for inspection why speci c tuples do not appear within a result set by
computing the missing relations for the expected results.
4
http://squam.info/?p=142
5
http://www.eclipse.org/mmt/?project=qvto
6
http://www.eclipse.org/modeling/mdt/?project=ocl
7
http://wiki.eclipse.org/MDT/OCL/Debugger
7
79
5 Implementation
As outlined above, based on the identi ed requirements for OCL debuggers, we
built a ready-to-use OCL debugger for Dresden OCL [15]. Although tree-based
debuggers such as the USE debugger can help to visualize the interpretation
results of OCL expressions, we argue that for real debugging, step-by-step de-
bugging including the highlighting of OCL expressions in a textual OCL editor
is required. Especially for the debugging of more complex OCL statements (e.g.,
iterator or even nested iterator expressions), a simple tree-based presentation is
insu cient, as the text editor integration further increases the understanding of
evaluation results for individual nested OCL expressions.
The existing OCL interpreter of Dresden OCL was extended by an OCL
debugger that suspends on breakpoints and propagates variable traces to the
Eclipse UI. To provide native look and feel for Eclipse-integrated debugging, the
OCL debugger was realized with the Eclipse debugging framework and was fully
integrated with the EMFText-based OCL editor and parser of Dresden OCL [16].
During debugging, breakpoints can be de ned in the OCL editor and respective
expressions are highlighted when stopping on a breakpoints during debugging.
Currently, our OCL debugger supports step-by-step debugging /R1/, the visual-
ization of currently interpreted OCL expressions as an expression stack /R2/, as
well as viewing the debugged expression trace /R3/ and variable tracing /R4/.
Support for conditional breakpoints /R5/, watch expressions /R6/, and program
state modi cation /R7/ are planned features for future works.
Figure 2 shows a screenshot of the debugger in the Eclipse debug perspec-
tive, while debugging a constraint from the Royal & Loyal example by Warmer
and Kleppe [17]. At the top left, the expression stack of the currently debugged
constraint is visible. Besides, on the right, the variables view illustrates the cur-
rently visible variables. At the currently reached breakpoint, after the evaluation
of the property call , the variable is the only visible variable. How-
ever, the variables view also contains the source and the result of the interpreted
levels self
expression call named as and and the result of the
currently interpreted constraint , which is an empty by now but
oclSource oclPropertyValue
may by lled during the interpretation of the and iterators yet
oclResult Set
to be debugged and interpreted. Below, in the center, the OCL editor visualizes
select collect
the currently debugged constraints and OCL expressions. Below, at the bottom
of the screen, a tracer view illustrates the expression trace of yet debugged OCL
expressions and their results in a tree-like manner.
6 Conclusion
In this paper, we identi ed requirements for OCL debugging and evaluated exist-
ing OCL tools w.r.t. debugging support. We showed that none of the investigated
tools fully supports step-by-step debugging for OCL, yet. Although, OCL debug-
ging has been highlighted as one of the most-wanted features in related work [6].
Therefore, we presented our solution for a step-by-step OCL debugger that is
8
80
Fig. 2. The OCL debugger, while debugging the Royal & Loyal example from [17].
based on the Eclipse debugging framework and extends the existing interpreter
of Dresden OCL. The OCL debugger has been extensively tested and is pub-
licly available . To the best of our knowledge, this is the rst tool supporting
8
step-by-step debugging for OCL. In future works we plan to address the missing
features discussed in Sect. 3 such as conditional breakpoints, watch expressions
and program state modi cation. With our step-by-step OCL debugger, OCL
tooling is another step further on its way towards an IDE4OCL as envisioned
by Chimiak-Opoka et al. [5].
Acknowledgements
This research has been co-funded within the project ZESSY #080951806, by
the European Social Fund (ESF) and Federal State of Saxony. We would like
to thank every person being or having been involved in the development and
maintenance of Dresden OCL.
8
http://www.dresden-ocl.org/
9
81
References
1. Object Management Group (OMG): Object Constraint Language. Version 2.3.1.
Online available speci cation (January 2012)
2. Object Management Group (OMG): Uni ed Modeling Language. Version 2.4.1.
Online available speci cation (August 2011)
3. Object Management Group (OMG): Meta Object Facility (MOF) 2.0
Query/View/Transformation, Version 1.1. Online available speci cation (January
2011)
4. Heidenreich, F., Johannes, J., Karol, S., Seifert, M., Thiele, M., Wende, C., Wilke,
C.: Integrating OCL and Textual Modelling Languages. In: Models in Software
Engineering. Volume 6627 of Lecture Notes in Computer Science., Berlin / Heidel-
berg, Springer (2011) 349363
5. Chimiak-Opoka, J.D., Demuth, B., Silingas, D., Rouquette, N.F.: Requirements
analysis for an integrated OCL development environment. Electronic Communi-
cations of the EASST 24 (2010)
6. Chimiak-Opoka, J., Demuth, B., Awenius, A., Chiorean, D., Gabel, S., Hamann, L.,
Willink, E.: OCL Tools Report based on the IDE4OCL Feature Model. Electronic
Communications of the EASST 44 (2011)
7. Correa, A., Werner, C.: Refactoring object constraint language speci cations. Soft-
ware & Systems Modeling 6(2) (2007) 113138
8. Reimann, J., Wilke, C., Demuth, B., Muck, M., Aÿmann, U.: Tool Supported OCL
Refactoring Catalogue. In: Proceedings of the 12th Workshop on OCL and Textual
Modelling, New York, ACM (2012) 712
9. Brüning, J., Gogolla, M., Hamann, L., Kuhlmann, M.: Evaluating and Debugging
OCL Expressions in UML Models. In: Test and Proofs. Volume 7305 of Lecture
Notes in Computer Science., Berlin / Heidelberg, Springer (2012) 156162
10. Adrion, W.R., Branstad, M.A., Cherniavsky, J.C.: Validation, veri cation, and
testing of computer software. ACM Computing Surveys 14(2) (June 1982) 159
192
11. Sommerville, I.: Software Engineering. 8th edn. Addison Wesley, Boston, MA
(2007)
12. Zeller, A.: Why programs fail - a guide to systematic debugging. Elsevier (2006)
13. Caballero, R., Garcí-Ruiz, Y., Sá¡enz-Pérez, F.: Algorithmic Debugging of SQL
Views. In: Perspectives of Systems Informatics. Volume 7162 of Lecture Notes in
Computer Science., Berlin / Heidelberg, Springer (2012) 7785
14. Herschel, M., Hernández, M.A., Tan, W.C.: Artemis: A System for Analyzing
Missing Answers. In: 35th International Conference on Very Large Data Bases
(VLDB'09), New York, ACM (2009)
15. Schütze, L.: OCL Debugging for Dresden OCL. Bachelor's thesis, Technische
Universität Dresden (2013)
16. Aÿmann, U., Bartho, A., Bürger, C., Cech, S., Demuth, B., Heidenreich, F., Jo-
hannes, J., Karol, S., Polowinski, J., Reimann, J., et al.: DropsBox: the Dresden
Open Software Toolbox. Software & Systems Modeling 11 (2012) 137
17. Warmer, J., Kleppe, A.: The Object Constraint Language - Getting Your Models
Ready for MDA. 2nd edn. Pearson Education Inc., Boston, MA (2003)
10
82