The Object Constraint Language (OCL) is a textual, declarative language used as part of the UML standard for specifying constraints and queries on models. As such, generating code from OCL expressions is part of an end-to-end model-driven development process. Certainly, this is the case for database-centric application development, where integrity constraints and queries can be naturally specified using OCL. Not surprisingly, there have already been several attempts to map OCL into SQL. In this case study, we invite participants to implement, using their own model-transformation methods, one of these mappings, called OCL2PSQL. We propose this case study as a showcase for diferent methods to prove their readiness for coping with moderately complex model transformations, by showing the usability, conciseness, and ease of understanding of their solutions when implementing a non-trivial subset of OCL2PSQL.
translated. In particular, [
The Structured Query Language (SQL) [
These are routines stored in the database that may execute loops using the so-called cursors.
In the context of model-driven engineering, there exist
several proposals for translating OCL into SQL [
1The letter “P” in OCL2PSQL stands for pure. The idea is that OCL2PSQL only uses the declarative features of SQL for mapping OCL expressions. TEMP_left returns the size of its subquery, aliased TEMP_src, which is the translation of the sub-expression Car.allInstances(). □ OCL is a contextual language: its expressions are written in the context provided by a data model. Consequently, the input metamodel for OCL2PSQL can be seen as the union of two, inter-related metamodels: namely, the metamodel for data models and the metamodel for OCL expressions.
The full recursive definition of OCL2PSQL can be
found in [
The correctness of the mapping is formulated as follows. 2.1.1. Input metamodel for data models Let be an OCL expression (with no free variables) and let be a scenario of its context model. Then, the evaluation For OCL2PSQL, a data model contains classes and associof the expression in the scenario should return the ations. A class may have attributes and associations-ends. same result that the execution of the query OCL2PSQL(), The multiplicity of an association-end is either ‘one’ or i.e., the SQL query generated by OCL2PSQL from , in the ‘many’. database OCL2PSQL(), i.e., the database corresponding The data model metamodel for OCL2PSQL is shown to according to OCL2PSQL. 2 in Figure 1. DataModel is the root element and contains a
The TTC 2021 OCL2PSQL case welcomes participants set of Entitys. Each Entity represents a class in the data to implement the subset of OCL2PSQL mapping provided model: it contains a set of Attributes and a set of Associn Appendix A using their own model-transformation iationEnds. Each Attribute represents an attribute of methods. This case study can serve as a showcase for a class: it has a name and a type. Each AssociationEnd diferent methods to prove their readiness to cope with represents an association-end: it has a name, an assomoderately complex model-transformations, by showing ciation class name association and a Multiplicity the usability, conciseness, and understandability of their value. Each AssociationEnd is also linked to its opposite solutions when implementing the subset of OCL2PSQL. AssociationEnd, and with its target Entity. More information about the main task will be provided in Section 3.
All resources for this case are available on Github [7].
Please follow the description in the footnote and create a pull request with your own solution after you have submitted your description to EasyChair.
The rest of the document is structured as follows: Section 2 describes the input and output of OCL2PSQL transformation. Section 3 provides the main task that should be tackled in a solution. Finally, Section 4 proposes the case evaluation scheme for the contest.
OCL2PSQL is a recently proposed mapping from OCL
to SQL [
Next, we give a detailed description of the input and output metamodels for the TTC 2021 OCL2PSQL case. The input metamodels represent the part of OCL language that is covered in this competition. The output metamodel represents the part of the SQL language that is used by OCL2PSQL to translate the aforementioned part of OCL language.
2The OCL2PSQL mapping rests on an underlying mapping
between data models and SQL database schema. The full definition of
this mapping is also provided in [
The definition of the OCL mapping presented in
Appendix A only covers a subset of the OCL language. For
the OCL expressions involved in this competition, we
have simplified the metamodel for OCL expressions to
the minimum. For interested readers and solution
authors who would like to extend or implement their own
implementation, the class diagram of the OCL expression
can be found in its specification document in [
The OCL2PSQL metamodel for OCL expressions in this competition is shown in Figure 2. Readers who are not familiar with the OCL can refer to Appendix C for a more detail description of our metamodel.
For the sake of illustration, we show in Figure 3 the object diagram of OCL expression in Example 1.1. It is an expression of class OperationCallExp with = as the referredOperation. In this expression, • The source is also an expression of class
OperationCallExp with size() as the referredOperation, representing the sub-expression Car.allInstances()→size(). Furthermore, in the aforementioned sub-expression, the source is yet another expression of class OperationCallExp with allInstances() as the referredOperation, representing the subexpression Car.allInstances(). Finally, in the aforementioned sub-expression, the source is a Figure 3: TypeExp, representing the sub-expression Car, Car.allInstances()→size() = 1. which refers to the Car entity of the data model. • The argument is an expression of type Integer
LiteralExp with 1 as the integerValue.
For OCL2PSQL, a SQL query is a basic SQL-select state- WHERE c.color IS NULL ment, which may contain subselects, WHERE clauses, GROUP BY clauses, and JOINs.
This is a SelectStatement with a PlainSelect as selectBody. The PlainSelect contains:
• A SelectItem element that represents the clause (SELECT) COUNT(*) > 0 AS res. It contains a GreaterThanExpression expression, in which the leftExp is a CountAllFunction expression, and the rightExp is a LongValue expression with value 0. Furthermore, it has an Alias named res.
The object diagram of OCL expression
The main task for the participants in the TTC 2021 OCL2PSQL case is to implement the subset of OCL2PSQL mapping defined in Appendix A using their own modeltransformation methods. Participants are free to extend or modify the OCL2PSQL mapping, or even to propose their own mapping from OCL to SQL, in which case they should also provide convincing arguments that their solution is correct with respect to the semantics of OCL and SQL. 3
During the contest, the participants will be presented with diferent challenges of increasing complexity. Each challenge will be an OCL2PSQL OCL expression, i.e., an instance of the OCL2PSQL metamodel for OCL expressions. The context for all the challenges will be an OCL2PSQL data model, i.e., an instance of OCL2PSQL metamodel for data models. Then, the participants will be asked to generate the solutions for these challenges, applying their own transformation rules. Very importantly: (i) each solution should be a valid SQL-select statement in the database schema corresponding to the given data model, according to the definition of the OCL2PSQL mapping; moreover, (ii) each solution should be a SQL-select statement returning a result-table with (at least) a column res. When executing the solution for a challenge
3For the participants who would like to extend their
implementation beyond the subset of OCL language provided for our
competition, please revise the full version of our OCL2PSQL mapping in [
For the participants’ convenience, we have grouped the challenges into diferent stages. Each stage contains challenges that apply similar OCL2PSQL mapping rules, particularly: • The folder models contains the challenges listed in challenges.txt in XMI format. More specifically, each file StageChallenge.xmi contains the representation of the challenge within the stage in the file challenges.txt in XMI format.
In the same folder, the file CarPerson.xmi contains the data model CarPerson in XMI-format. • In the folder metamodels, the file ocl.ecore contains the EMF implementation of OCL2PSQL metamodel for OCL expressions. Also in the same folder, the file sql.ecore contains the EMF implementation of OCL2PSQL metamodel for SQLselect statements.
For the purpose of testing, the participants can find the following material in the case materials repository: • Stage0 only requires the mapping rule for literals.
The OCL expressions in this stage are contextfree. • Stage1 is similar to Stage1, with additional mapping rules for OperationalCallExp (operator: equality and conjunction). The OCL expressions in this stage are also context-free. • Stage2 requires the mapping rules for
OperationalCallExp (operator allInstances) and TypeExp. From this stage on, the OCL expressions are context-dependent, i.e., the underlying context model will be needed. • Stage3 is similar to Stage2, with additional mapping rules for OperationalCallExp (operator: Figure 6: The CarPerson data model. size and =). • Stage4 is similar to Stage3, with additional mapping rules for VariableExp and IteratorExp (kind: collect). • Stage5 is similar to Stage4, with additional map- 4. Benchmark framework ping rules for PropertyCallExp. • Stage6 is similar to Stage5, with additional map- The case resources on GitHub [7] include an automated ping rules for AssociationClassCallExp. benchmark framework for systematic measurement of • Stage7 is similar to Stage5 and Stage6, with ad- the performance and correctness of the various solutions. ditional mapping rules for IteratorExp (kind: It is based on the framework of the TTC 2017 Smart Grid exists). case [9], without the visualisation components. Solution • Stage8 is a more complex version of Stage7, with authors are recommended to adapt their solutions to this nested IteratorExp of kind exists. framework to allow for easier integration and comparison of the various solutions.
The configuration of the benchmark framework for the TTC 2021 OCL2PSQL case is stored in the file • In the docs folder, the file challenges.txt con- config.json inside the folder config. This file includes tains a list of challenges grouped in the afore- the definitions of the various stages and challenges, the mentioned stages. Each stage has a unique num- name of the tools to be run, the number of repetitions ber, and each challenge within a stage has also to be applied, the timeout in milliseconds for each exa unique number. The greater the number of ecution and the connection information for the local a stage, the greater its complexity. The context MySQL database. Currently, the file config.json has for all challenges in challenges.txt is the data already contained the stages and challenges listed in the model CarPerson shown in Figure 6. ifle challenges.txt.
In the same folder, the file scenarios.txt con- In the folder docker, the Dockerfile contains the intains a list of scenarios. Each scenario de- struction to build a MySQL 5.7 Docker image that conscribes an instance of the data model CarPerson. tains all the SQL data scenarios of the CarPerson database Then, for each scenario, and each (relevant) corresponding to the ones listed in scenarios.txt. This stage/challenge listed in challenges.txt, the image is currently used for building databases to test the ifle scenarios.txt contains the correct result: correctness of the reference solution. Solution authors i.e., the expected SQL result that corresponds to can use either the image we provide or their own local the evaluation of the given stage/challenge in MySQL database installation, in which they would need the given scenario. to change the information in the config. Listing 1: solution.ini file for the ReferenceXMI solu
tion [ build ] default = mvn compile skipTests = mvn compile [ run ] cmd = mvn -f pom . xml -quiet -Pxmi exec : exec
All solutions must be forks of the main Github project, and should be submitted as pull requests after the descriptions have been uploaded to EasyChair.
All solutions should be in a subdirectory of the solutions folder, and inside this subdirectory they should include a solution.ini file describing how the solution should be built and run. As an example, Listing 1 shows the file for the reference solution. The build section provides the default and skipTests fields for specifying how to build and test, and how to simply build, respectively. In the run section, the cmd field specifies the command to run the solution.
Solutions should print to their standard output streams a sequence of lines with the following fields, separated by semicolons: • Tool: name of the tool. • Stage: integer with the stage within the case whose challenge is being solved. • Challenge: integer with the challenge within the stage which is being solved. • RunIndex: integer with the current repetition of the transformation. • MetricName: may be “TransformTimeNanos”, “TestTimeNanos”, or “ScenarioID ” where ID is the identifier of the scenario under test. • MetricValue: the value of the metric: The repetition of the transformation is handled by the framework. Moreover, for every repetition, the framework provides the following information in environment variables: the run index, stage number and challenge number, the OCL expression corresponding to the challenge in plaintext, as well as the file path of that expression in XMI-format, and the file path of the context of the challenge, also in XMI-format. More specifically, the available environment variables are: • MySQLUsername: the username of the local MySQL database system on which the statement will be run. • MySQLPassword: the password of the given user. • MySQLPort: the port number of the local
MySQL database system. • StageIndex: the index of the stage whose challenge is to be run. • ChallengeIndex: the index of the challenge within the stage which will be run. • OCLQuery: the OCL expression, in text-format, corresponding to the challenge to be run. • PathToOCLXMI: the absolute path to the file containing the OCL expression, in XMI-format, corresponding to the challenge to be run. • PathToSchemaXMI: the absolute path to the ifle containing the SQL schema, in XMI-format, corresponding to the context (data model) of the challenges to be run. • RunIndex: the index of the repetition to be run. • Tool: the name of the tool (the name of the solutions subfolder).
The benchmark framework needs Python 3.3 or later to be installed, and the reference solution requires Maven 3 and Java 8 or later. Solution authors are free to use alternative frameworks and programming languages, as long as these dependencies are explicitly documented. For the final evaluation, it is planned to construct a Docker image with all solutions, and this will require installing those dependencies into the image.
If all dependencies are installed, the benchmark can be run with python scripts/run.py (potentially python3 if Python 2.x is installed globally in the same system).
For the submitted solutions that strictly follow the proposed mapping, the benchmark framework will provide independent measurements of the correctness, completeness, and time usage of these solutions, then based on the evaluation outcome, the 1st/2nd/3rd place award will be rewarded.
For other solutions, that modify or extend the proposed mapping, besides the aforementioned criteria, attendees to the contest will also evaluate the usability, conciseness, and understandability of the transformation rules that deifne the diferent solutions, as well as the other attributes of interest that the solution providers may want to focus on. In this regard, although some solutions may not be entirely complete or may be hard to understand, or may not share the common interest, they may still serve as examples of active research areas within model transformations that the community may wish to showcase. To recognize these contributions, an audience-driven “Most Promising” award will be given.
The mapping OCL2PSQL is defined recursively over the structure of OCL expressions. To describe the key idea underlying its definition, and to illustrate it with the presentation of some recursive cases, we need to introduce some notations first.
Notation. Let qry be a SQL query. Let db be a SQL database. Then, we denote by Exec(qry , db) the result of executing qry on db. Let be an OCL expression.
Then, we denote by FVars() the set of variables that occur free in , i.e., that are not bound by any iterator. Let be an OCL expression, and let be a variable introduced in by an iterator expression →iter ( | ). Then, we denote by src() the source of in . Let be an OCL expression and let ′ be a subexpression of . Then, we denote by SVars(′) the set of variables which (the value of) ′ depends on, and is defined as follows: Let be an OCL expression, let ′ be a subexpression of .att as res, . Then, we denote the SQL query corresponding to ′ TEMP_obj.val as val, by map(′), according to OCL2PSQL. TEMP_obj.ref_′ as ref_′, for each ′ ∈ SVars()
Definition: key idea and some cases. The difer- FROM (map()) as TEMP_obj ent recursive cases follow the same design principle: LEFT JOIN namely, let be an OCL2PSQL-expression, let ′ be ON TEMP_obj.ref_ = ._id AND TEMP_obj.val = 1 a subexpression of , and let be a scenario. Then, Exec(map(′), map()) returns a table, with a col- Association-ends expressions umn res, a column val, and, for each ∈ SVars(′), a column ref_. Informally, for each row in this table: (i) Let be an OCL expression. Let ′ be a subexpression of the columns ref_ contain a valid “instantiation” for the . Let ′ = .ase, where is a variable of class-type , iterator variables of which the evaluation of ′ depends and ase is an association-end of the class . on (if any); (ii) the column val contains 0 when evaluat- Let Assoc(ase) be the association to which ase being the expression ′, with the “instantiation” represented longs, and let Oppos(ase) be the association-end at the by the columns ref_, evaluates to the empty set; other- opposite end of ase in Assoc(ase). Then, wise, the column val contains 1; (iii) when the column val contains 1, the column res contains the result of evaluating the expression ′ with the “instantiation” represented by the columns ref_; when the column val contains 0, the value contained in the column res is not meaningful.
We define the recursive definition of OCL2PSQL mappings that will be used in our competition. The definition here was taken from the original paper and has already included the corrigenda in Appendix B. map(.ase) = SELECT
Assoc().ase as res, CASE Assoc(ase).Oppos(ase) IS NULL
WHEN 1 THEN 0
ELSE 1 END as val,
TEMP_src.ref_′ as ref_′, for each ′ ∈ SVars() FROM (map()) as TEMP_src LEFT JOIN Assoc(ase) ON TEMP_src.ref_ = Assoc(ase).Oppos(ase) Let be an OCL expression. Let ′ be a subexpression of size-expressions . Let ′ = , where is a variable. Then,
Let be an OCL expression. Let ′ be a subexpression of . Let ′ = , where is a string literal. Then, map() = SELECT as res, 1 as val
map() = SELECT
TEMP_dmn.res as res, TEMP_dmn.res as ref_, TEMP_dmn.val as val, TEMP_dmn.ref_′ as ref_′,
for each ′ ∈ SVars(src()) FROM (map(src())) as TEMP_dmn
Let be an OCL expression. Let ′ be a subexpression of . Let ′ = .att , where is a variable of class-type and att is an attribute of the class . Then, map(.att ) = SELECT
Let be an OCL expression. Let ′ be a subexpression of . Let ′ = .allInstances(), where is a class type. Then, map(.allInstances())= SELECT _id as res, 1 as val FROM Let be an OCL expression. Let ′ be a subexpression of . Let ′ = →size(). We need to consider the following cases: • FVars(′) = ∅. Then, map(→size()) = SELECT
COUNT(*) as res, 1 as val
FROM (map()) AS TEMP_src. • FVars(′) ̸= ∅, Then, map(→size()) = SELECT
CASE TEMP_src.val = 0
WHEN 1 THEN 0 ELSE COUNT(*) END as res, TEMP_src.ref_ as ref_,
for each ∈ SVars() 1 as val FROM (map()) AS TEMP_src GROUP BY
TEMP_src.ref_,
for each ∈ SVars(),
TEMP_src.val =-expressions (correspondingly, and-expressions) Let be an OCL expression. Let ′ be a subexpression of . Let ′ = (=). For our competition, we only need to consider the following cases: • FVars() = FVars() = ∅. Then, map(=) = SELECT
TEMP_left.res = TEMP_right.res as res, 1 as val FROM (map()) AS TEMP_left, (map()) AS TEMP_right • FVars() ̸= ∅, SVars() ⊆ SVars(). Then, map(=) = SELECT
TEMP_left.res = TEMP_right.res as res, CASE
TEMP_left.val = 0 OR TEMP_right.val = 0 WHEN 1 THEN 0
ELSE 1 END as val, TEMP_left.ref_ as ref_,
for each ∈ SVars() FROM (map()) AS TEMP_left [LEFT] JOIN (map()) AS TEMP_right [ON TEMP_left.ref_ = TEMP_right.ref_,
for each ∈ SVars() ∩ SVars()] collect-expressions Let be an OCL expression. Let ′ be a subexpression of . Let ′ = →collect( | ). For our competition, we only need to consider the following case: • ∈ FVars() and FVars(′) = ∅.
SELECT TEMP_body.res as res,
TEMP_body.val as val,
FROM (map()) as TEMP_body • ̸∈ FVars(). Similarly, but the source and the body would need to be joined using a JOIN-clause. Let be an OCL2PSQL-expression. Let ′ be a subexpression of . Let ′ = →exists( | ). For our competition, we only need to consider the following cases: • ∈ FVars() and FVars(′) = ∅. Then
SELECT
COUNT(*) > 0 as res, 1 as val FROM (map()) as TEMP_body
WHERE TEMP_body.res = 1 • ∈ FVars() and FVars(′) ̸= ∅. Then
SELECT
CASE TEMP_body.ref_ IS NULL
WHEN 1 THEN 0
ELSE TEMP_body.res END as res, 1 as val, TEMP_src.ref_′ as ref_′,
for each ′ ∈ SVars(), TEMP_body.ref_′ as ref_′,
for each ′ ∈ SVars() ∖ SVars() ∖ {} FROM (map()) as TEMP_src LEFT JOIN (
SELECT COUNT(*) > 0 as res,
TEMP_body.ref_′ as ref_′,
for each ′ ∈ SVars() FROM (map()) as TEMP_body WHERE TEMP_body.res = 1 GROUP BY TEMP_body.ref_′,
for each ′ ∈ SVars() ∖ {} ) as TEMP_body ON TEMP_src.ref_′ = TEMP_body.ref_′,
for each ′ ∈ SVars() • ̸∈ FVars(). Similarly, but the source and the body would need to be joined using a JOIN-clause without the group-clause (and possibly, changing left join to simple join, if there are no common variables between source and body).
In [6, Section 4.3], in the second case considered in the definition of the mapping for Exists-expressions instead of: • ∈ FVars() and FVars(′) ̸= ∅. Then
SELECT
CASE TEMP_src.ref_ IS NULL
WHEN 1 THEN 0
ELSE TEMP.res END as res, . . .
In a nutshell, OclExpression is the root element. It is The SelectStatement is the root element: it contains an abstract class. An OclExpression can be either a lit- a PlainSelect, which represents the body of the SQLeral expression, a CallExp, a VariableExp, or a TypeExp. select statement.
Next, we describe each of these classes. A PlainSelect may contain the following objects: a
A literal expression represents a literal value. In list of selItems elements, each of type SelectItem; a our case, it can be either an IntegerLiteralExp, a fromItem element of type FromItem; a whereExp element StringLiteralExp, or a BooleanLiteralExp. Each of of type Expression; a list of joins elements of type Join; these classes contains an attribute to represent an integer, and a groupBy element of type GroupByElement. Next, a string, or a Boolean literal value, respectively. we describe each of these classes:
A TypeExp represents a type expression. It contains a A SelectItem represents a column that the select-statereference referredType of type Entity, which belongs ment retrieves. It contains an Expression element and to the OCL2PSQL metamodel for data models. an Alias element.
A VariableExp represents a variable expression. A FromItem element represents the table or subselect A CallExp represents an expression that consists of from which the SQL-select statement retrieves informacalling a feature over a source, which is represented by tion. It is an interface. A FromItem element can be either an OclExpression. CallExp is an abstract class: it can a Table or a SubSelect. The former represents a table. be either an OperationCallExp, a PropertyCallExp, an The latter represents a subselect. This element will be creAssociationClassCallExp, or an IteratorExp. ated on the fly, i.e., when the FROM-clause is encountered.
An OperationCallExp represents an expression that A whereExp reference of type Expression represents calls an operation over its source, possibly with argu- a where-clause. ments. For our competition, we only consider the equality A Join element represents a join with a rightItem of comparison, i.e., =; conjunctive operation, i.e., AND; and type FromItem, possibly according to its element onExp two operations on collections, i.e., allInstances() and of type Expression. size(). A GroupByElement element represents a groupby
A PropertyCallExp represents an expression that calls clause. It contains groupByExps, a list of objects of type an attribute of a source object. The former is repre- Expression that defines how the rows are to be grouped. sented by an Attribute and the latter is represented by Expression is an interface element which plays many an Entity; both belong to the OCL2PSQL metamodel for roles in a SQL-select statement. For the sake of simplicity, data models. OCL2PSQL only supports PropertyCallExp the realizations of Expression are hidden from Figure 4. Next, we describe these realizations which our cases will need.
A LongValue and a StringValue represent an integer literal and a string literal in SQL, respectively.
A Column represents a column of a table in SQL.
A BinaryExpression represents a binary expression in SQL. It contains a leftExp element and a rightExp element, both of type Expression. BinaryExpression is an abstract class. It can be either a logical expression, (OrExpression or AndExpression) , or a comparison expression (EqualsToExpression or GreaterThanExpression).
An IsNullExpression represents an IS NULL expression in SQL. It contains an Exp element of type Expression.
A CountAllFunction represents a COUNT(*) expression in SQL.
A CaseExpression represents a CASE-expression in SQL. It contains whenClauses, a list of objects of type WhenClause, representing WHEN clauses in SQL.
A SubSelect represents a subselect-expression in SQL.
It contains a selectBody of type PlainSelect .