Case description: apply proofread comments from Filip

docs/case/.gitignore

@@ -3,3 +3,5 @@
 *.log
 *.out
 *.fls
+*.bbl
+*.blg

docs/case/bibliography.bib

+@inproceedings{hinkel_ttc_2018,
+	address = {Toulouse, France},
+	title = {The {TTC} 2018 {Social} {Media} {Case}},
+	volume = {2310},
+	url = {http://ceur-ws.org/Vol-2310/paper5.pdf},
+	abstract = {To cope with the increased complexity, models are used to capture what is considered the essence of a system. Models are often analyzed to obtain insights on the modeled system. Often, these analyses have a heuristical nature and need to be adjusted according to updated requirements and are therefore a subject of maintenance activities. It is thus necessary to support writing model queries with adequate languages. However, in order to stay meaningful, the analysis results need to be refreshed as soon as the underlying models change. Therefore, a good execution speed is mandatory in order to cope with frequent model changes. In this paper, we propose a benchmark to assess model query technologies in the presence of model change sequences in the domain of social media.},
+	language = {en},
+	booktitle = {Proceedings of the 11th {Transformation} {Tool} {Contest}},
+	publisher = {CEUR-WS.org},
+	author = {Hinkel, Georg},
+	month = jun,
+	year = {2018},
+	pages = {39--43},
+	file = {Hinkel - The TTC 2018 Social Media Case.pdf:/home/antonio/.zotero/zotero/lo4gxuop.default/zotero/storage/8ZS692NG/Hinkel - The TTC 2018 Social Media Case.pdf:application/pdf}
+}
+
+@inproceedings{gotz_quality-based_2018,
+	address = {Toulouse, France},
+	title = {Quality-based {Software}-{Selection} and {Hardware}-{Mapping} as {Model} {Transformation} {Problem}},
+	volume = {2310},
+	url = {http://ceur-ws.org/Vol-2310/paper1.pdf},
+	abstract = {In this TTC case, we describe the computation of an optimal mapping from software implementations to hardware components for a given set of user requests as a model transformation problem. Further, contracts specify dependencies between components in terms of non-functional properties. Different approaches of this case can be compared in terms of their validity, performance, scalability and, quality w.r.t. the real optimal deployment.},
+	language = {en},
+	booktitle = {Proceedings of the 11th {Transformation} {Tool} {Contest}},
+	publisher = {CEUR-WS.org},
+	author = {Götz, Sebastian and Mey, Johannes and Schöne, René and Aßmann, Uwe},
+	month = jun,
+	year = {2018},
+	pages = {3--11},
+	file = {Götz et al. - Quality-based Software-Selection and Hardware-Mapp.pdf:/home/antonio/.zotero/zotero/lo4gxuop.default/zotero/storage/B8QHPZVC/Götz et al. - Quality-based Software-Selection and Hardware-Mapp.pdf:application/pdf}
+}
+
+@inproceedings{anjorin_families_2017,
+	address = {Marburg, Germany},
+	title = {The {Families} to {Persons} {Case}},
+	volume = {2026},
+	url = {http://ceur-ws.org/Vol-2026/paper2.pdf},
+	abstract = {The Families to Persons case is a well-known example problem for bidirectional transformations. This paper proposes an implementation of this case within the recently developed Benchmarx framework [2], based on previous conceptual work [1].},
+	language = {en},
+	booktitle = {Proceedings of the 10th {Transformation} {Tool} {Contest}},
+	publisher = {CEUR-WS.org},
+	author = {Anjorin, Anthony and Buchmann, Thomas and Westfechtel, Bernhard},
+	month = jul,
+	year = {2017},
+	pages = {27--34},
+	file = {Anjorin et al. - The Families to Persons Case.pdf:/home/antonio/.zotero/zotero/lo4gxuop.default/zotero/storage/F29LELN9/Anjorin et al. - The Families to Persons Case.pdf:application/pdf}
+}
+
+@inproceedings{hinkel_ttc_2017,
+	address = {Marburg, Germany},
+	title = {The {TTC} 2017 {Outage} {System} {Case} for {Incremental} {Model} {Views}},
+	volume = {2026},
+	url = {http://ceur-ws.org/Vol-2026/paper1.pdf},
+	abstract = {To cope with the increased complexity, physical systems are more and more supported by software systems consisting of multiple subsystems. Usually, each of the subsystems uses standards relevant to the subsystem for interoperability with other tools. Thus, one faces the problem that information about the system as a whole is distributed across multiple models. To solve this problem, model views can be introduced to combine these models and extract application-specific knowledge. As an example, the smart grid is a cyber-physical system where one is interested to detect, manage and prevent system outages. The information necessary to do this is split among the standards IEC 61970/61968, IEC 61850 and IEC 62056. This paper presents a benchmark case and evaluation framework for joining information spread across multiple models into a single view, based on a model-based outage management system for smart grids. Because cyber-physical systems often require very fast response times to changes of underlying models, the benchmark focuses especially on the incremental computation of model views.},
+	language = {en},
+	booktitle = {Proceedings of the 10th {Transformation} {Tool} {Contest}},
+	publisher = {CEUR-WS.org},
+	author = {Hinkel, Georg},
+	month = jul,
+	year = {2017},
+	pages = {3--12},
+	file = {Hinkel - The TTC 2017 Outage System Case for Incremental Mo.pdf:/home/antonio/.zotero/zotero/lo4gxuop.default/zotero/storage/NUJ688D8/Hinkel - The TTC 2017 Outage System Case for Incremental Mo.pdf:application/pdf}
+}
+
+@inproceedings{fleck_class_2016,
+	address = {Vienna, Austria},
+	title = {The {Class} {Responsibility} {Assignment} {Case}},
+	volume = {1758},
+	url = {http://ceur-ws.org/Vol-1758/paper1.pdf},
+	abstract = {This paper describes a case study for the ninth Transformation Tool Contest (TTC’16)1. The case is aimed at the production of high-quality designs for object-oriented systems and presents the problem of finding a good class diagram for a given set of methods and attributes with functional and data relationships among them. In order to obtain such a class diagram, dedicated quality metrics that have been defined in the context of the class responsibility assignment problem need to be optimized. Therefore, the focus of this case study is not on the definition of the necessary set of rules, but rather on the orchestration of such rules in order to find the optimal class diagrams. The evaluation of the produced transformation is driven by the quality of the produced models, the complexity of the rule orchestration as well as by the flexibility of the solution and its performance.},
+	language = {en},
+	booktitle = {Proceedings of the 9th {Transformation} {Tool} {Contest}},
+	publisher = {CEUR-WS.org},
+	author = {Fleck, Martin and Troya, Javier},
+	month = jul,
+	year = {2016},
+	pages = {1--8},
+	file = {Fleck et al. - The Class Responsibility Assignment Case.pdf:/home/antonio/.zotero/zotero/lo4gxuop.default/zotero/storage/HZVQQB9A/Fleck et al. - The Class Responsibility Assignment Case.pdf:application/pdf}
+}
+
+@inproceedings{getir_state_2017,
+	address = {Marburg, Germany},
+	title = {State {Elimination} as {Model} {Transformation} {Problem}},
+	volume = {2026},
+	url = {http://ceur-ws.org/Vol-2026/paper4.pdf},
+	abstract = {State elimination has been proposed in the literature as a viable technique for transforming finite state automata (or finite state machines) into equivalent regular expressions. In this TTC case, we consider this well-known technique as a model transformation problem, aiming at evaluating the suitability, performance and scalability of dedicated model transformation techniques w.r.t. this problem.},
+	language = {en},
+	booktitle = {Proceedings of the 10th {Transformation} {Tool} {Contest}},
+	publisher = {CEUR-WS.org},
+	author = {Getir, Sinem and Vu, Duc Anh and Peverali, Francois and Struber, Daniel and Kehrer, Timo},
+	month = jul,
+	year = {2017},
+	pages = {65--73},
+	file = {Getir et al. - State Elimination as Model Transformation Problem.pdf:/home/antonio/.zotero/zotero/lo4gxuop.default/zotero/storage/Z5FDISFM/Getir et al. - State Elimination as Model Transformation Problem.pdf:application/pdf}
+}
+
+@Misc{live2017,
+  author =    {Georg Hinkel},
+  title =     {The {TTC 2017} Live Contest on Transformation Reuse in the Presence of Multiple Inheritance and Redefinitions},
+  howpublished = {\url{https://www.transformation-tool-contest.eu/2017/solutions_livecontest.html}},
+  month =     jul,
+  year =      {2017},
+  note =      {Last accessed on 2017-05-10. Archived on \url{http://archive.is/gHEys}},
+}
+
+@Misc{live2016,
+  author =    {Antonio García-Domínguez},
+  title =     {{TTC'16} Live Contest Case Study: execution of dataflow-based model transformations},
+  howpublished = {\url{https://www.transformation-tool-contest.eu/2016/livecontest.html}},
+  month =     jul,
+  year =      {2016},
+  note =      {Last accessed on 2017-05-10. Archived on \url{http://archive.is/gHEys}},
+}
+
+@Misc{atlzoo,
+  author =    {{Eclipse Foundation}},
+  title =     {{ATL} Transformations},
+  howpublished = {\url{https://www.eclipse.org/atl/atlTransformations/}},
+  month =     jul,
+  year =      {2019},
+  note =      {Last accessed on 2017-05-10. Archived on \url{http://archive.is/HdoHM}},
+}
+

docs/case/case-description.tex

@@ -17,6 +17,9 @@
 
 \usepackage[pdftex,colorlinks=true]{hyperref}
 
+\usepackage{listings}
+\lstset{columns=flexible}
+
 \newcommand*{\class}[1]{\textsc{#1}}
 \newcommand*{\feature}[1]{\emph{#1}}
 \newcommand*{\file}[1]{\texttt{#1}}
@@ -43,22 +46,24 @@
 Past editions of the Transformation Tool Contest have focused on a variety of
 topics:
 \begin{itemize}
-\item In 2018, the Quality-based Software Selection and Hardware-Mapping case
-  discussed optimisation-oriented model transformations (with a combination of
-  performance and solution quality). The Social Media Live Case considered
-  performance in updating model views as models changed (with a strong
-  preference for approaches supporting incrementality).
-
-\item In 2017, the Smart Grid case focused on incrementality, the Families to
-  Persons case discussed bidirectional transformations, State Elimination
-  focused on performance and the live case on Transformation Reuse discussed
-  mechanisms to share complex logic across multiple versions of a
-  transformation.
+\item In 2018, the Quality-based Software Selection and Hardware-Mapping
+  case~\cite{gotz_quality-based_2018} discussed optimisation-oriented model
+  transformations (with a combination of performance and solution quality). The
+  Social Media Live Case~\cite{hinkel_ttc_2018} considered performance in
+  updating model views as models changed (with a strong preference for
+  approaches supporting incrementality).
+
+\item In 2017, the Smart Grid case focused on
+  incrementality~\cite{hinkel_ttc_2017}, the Families to Persons case discussed
+  bidirectional transformations~\cite{anjorin_families_2017}, State Elimination
+  focused on performance and the live case on Transformation
+  Reuse~\cite{live2017} discussed mechanisms to share complex logic across
+  multiple versions of a transformation.
 
 \item In 2016, optimisation-oriented model transformations were discussed in
-  considerable breadth through the Class Responsibility Assignment case, and an
-  alternative dataflow-based notation for model transformation was evaluated in
-  the live case study.
+  considerable breadth through the Class Responsibility Assignment
+  case~\cite{fleck_class_2016}, and an alternative dataflow-based notation for
+  model transformation was evaluated in the live case study~\cite{live2016}.
 \end{itemize}
 
 While these were notable examples of realistic transformations, they were
@@ -66,21 +71,20 @@ narrowly focused on a specific topic,and their inherent complexity discouraged
 some attendees from trying their hand with their own research agenda on the
 transformation.
 
-In this case, we propose a broader contest that welcomes all active lines of
-work on model transformation, based on a simpler, well-known transformation from
-the ATL Zoo\footnote{\url{https://www.eclipse.org/atl/atlTransformations/}}: the
-TT2BDD (Truth Tables to Binary Decision Diagrams) example transformation.
-Striving for raw performance is an option, but the case welcomes approaches that
-focus on other attributes of interest to a high-quality model transformation.
-This includes attributes such as verifiability, traceability, bidirectionality,
-or understandability, but solution providers are welcome to propose their own
+This year, we propose a broader contest that welcomes all active lines of work
+on model transformation. It is based on a simpler, well-known transformation
+from the ATL Zoo~\cite{atlzoo}: TT2BDD (Truth Tables to Binary Decision
+Diagrams). Striving for raw performance is an option, but the case welcomes
+approaches that focus on other attributes of interest of a high-quality model
+transformation: for example, verifiability, traceability, bidirectionality, or
+understandability. Solution providers are welcome to propose their own
 attributes of interest. In general, this case is proposed as a showcase of the
 current variety of model transformation tools.
 
 The rest of the document is structured as follows:
 Section~\ref{sec:transf-descr} describes the TT2BDD transformation.
-Section~\ref{sec:task-suggestions} suggests several tasks of interest that could
-be tackled in a solution (authors are free to propose their own tasks of
+Section~\ref{sec:task-suggestions} several tasks of interest that
+should be tackled in a solution (authors are free to propose their own tasks of
 interest). Section~\ref{sec:benchmark-framework} mentions the benchmark
 framework for those solutions that focus on raw performance. Finally,
 Section~\ref{sec:evaluation} mentions an outline of the initial audience-based
@@ -124,8 +128,8 @@ outline of an implementation.
   \label{tab:tt-example}
 \end{table}
 
-The input metamodel is shown on Figure~\ref{fig:tt-metamodel}. A
-\class{Truth\-Table} object acts as the root of the model, and contains a
+The input metamodel is shown on Figure~\ref{fig:tt-metamodel}. The
+\class{Truth\-Table} class is as the root of the model, and contains a
 collection of \class{Port}s and \class{Row}s. \class{Port}s come in two types:
 \class{Input\-Port}s and \class{Output\-Port}s. \class{Row}s contain sequences
 of \class{Cell}s, which assign values to the \class{Input\-Port}s and
@@ -161,7 +165,7 @@ $B$ are 0, then $S$ should be 0.
       level 7/.style={level distance=2em},
       port/.style={circle, draw},
       value/.style={draw},
-      assignment/.style={ellipse, fill=blue!20},
+      assignment/.style={fill=blue!20},
   ]
     \node[port] {$A$}
     child[grow=left] {
@@ -245,8 +249,8 @@ $B$ are 0, then $S$ should be 0.
   \label{fig:bdd-equivalent}
 \end{figure}
 
-The output metamodel is shown on Figure~\ref{fig:bdd-metamodel}. A \class{BDD}
-object acts as the root of the model, and contains the root of the \class{Tree}
+The output metamodel is shown on Figure~\ref{fig:bdd-metamodel}. The \class{BDD}
+class is the root of the model, and contains the root of the \class{Tree}
 and a collection of \class{Port}s. Similarly to the Truth Tables metamodel,
 there are \class{Input\-Port}s and \class{Output\-Port}s.
 
@@ -260,7 +264,7 @@ to each of the available \class{Output\-Port}s.
 The equivalent BDD for the truth table on Table~\ref{tab:tt-example} is shown on
 Figure~\ref{fig:bdd-equivalent}. \class{Subtree}s are represented by the circle
 referencing an \class{Input\-Port} and their subtrees for when the port takes a
-0 or 1 value. \class{Assignment}s are represented by the shaded nodes that
+0 or 1 value. \class{Assignment}s are represented by the highlighted nodes that
 provide values to the \class{Output\-Port}s.
 
 \subsection{Process Outline}
@@ -308,8 +312,8 @@ which points to the equivalent BDD \class{Input\-Port} and has two
 This simple approach does not necessarily ensure a minimal subtree, as in some
 points there may be multiple ports to choose from. It may require improvements
 for cases where there are no input ports which are defined in all available
-rows. Authors are welcome to try and implement a more efficient or optimal
-approach in their solutions.
+rows. Authors are welcome to implement a more efficient or optimal approach in
+their solutions.
 
 \section{Main Task}
 \label{sec:task-suggestions}
@@ -350,7 +354,11 @@ languages.
 \section{Benchmark Framework}
 \label{sec:benchmark-framework}
 
-If focusing on performance, the solution authors should integrate their solution with the provided benchmark framework. It is based on that of the TTC 2017 Smart Grid case\footnote{\url{https://www.transformation-tool-contest.eu/2017/solutions_smartGrid.html}}, and supports the automated build and execution of solutions. For this specific case study, the visualisation of the results is currently disabled.
+If focusing on performance, the solution authors should integrate their solution
+with the provided benchmark framework. It is based on that of the TTC 2017 Smart
+Grid case~\cite{hinkel_ttc_2017}, and supports the automated build and execution
+of solutions. For this specific case study, the visualisation of the results is
+currently disabled.
 
 The benchmark consists of three phases:
 
@@ -379,12 +387,21 @@ standard output a line with the following fields, separated by semicolons
   nanoseconds.
 \end{itemize}
 
+\lstinputlisting[
+  float,frame=tb,numbers=left,
+  caption={\file{solution.ini} file for the reference ATL solution},
+  label=lst:ini-atl
+]{../../solutions/EMFSolutionATL/solution.ini}
+
 To enable automatic execution by the benchmark framework, solutions should add a
 subdirectory to the \file{solutions} folder of the benchmark with a
-\file{solution.ini}q file stating how the solution should be built and how it
-should be run. Solution authors will want to study the available
-\file{solution.ini} for the sample ATL solution, and adjust its settings in
-order to run the appropriate commands for building and running their solutions.
+\file{solution.ini} file stating how the solution should be built and how it
+should be run. As an example, the \file{solution.ini} file for the reference ATL
+solution is shown on Listing~\ref{lst:ini-atl}. In the \file{build} section, the
+\file{default} option specifies the command to build and test the solution, and
+the \file{skipTests} option specifies the command to build the solution while
+skipping unit tests. In the \file{run} section, the \file{cmd} option specifies
+the command to run the solution.
 
 The repetition of executions as defined in the benchmark configuration is done
 by the benchmark. For 5 runs, the specified command will be called 5 times,
@@ -448,4 +465,7 @@ the evaluation will operate on two dimensions:
   research areas may be awarded.
 \end{itemize}
 
+\bibliographystyle{plain}
+\bibliography{bibliography}
+
 \end{document}

metamodels/ttc2019.metamodels/models/BDD.aird

@@ -189,17 +189,17 @@
         </edges>
         <edges xmi:type="notation:Edge" xmi:id="_OVWsAHKKEemby9dK47XbYQ" type="4001" element="_OUMOYHKKEemby9dK47XbYQ" source="_OUzSYHKKEemby9dK47XbYQ" target="_OUty03KKEemby9dK47XbYQ">
           <children xmi:type="notation:Node" xmi:id="_OVXTEHKKEemby9dK47XbYQ" type="6001">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVXTEXKKEemby9dK47XbYQ" x="-33" y="-10"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVXTEXKKEemby9dK47XbYQ" x="-29" y="-10"/>
           </children>
           <children xmi:type="notation:Node" xmi:id="_OVXTEnKKEemby9dK47XbYQ" type="6002">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVXTE3KKEemby9dK47XbYQ" x="8" y="18"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVXTE3KKEemby9dK47XbYQ" x="9" y="18"/>
           </children>
           <children xmi:type="notation:Node" xmi:id="_OVX6IHKKEemby9dK47XbYQ" type="6003">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVX6IXKKEemby9dK47XbYQ" x="-24" y="10"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVX6IXKKEemby9dK47XbYQ" x="18" y="10"/>
           </children>
-          <styles xmi:type="notation:ConnectorStyle" xmi:id="_OVWsAXKKEemby9dK47XbYQ" routing="Tree"/>
+          <styles xmi:type="notation:ConnectorStyle" xmi:id="_OVWsAXKKEemby9dK47XbYQ" routing="Rectilinear"/>
           <styles xmi:type="notation:FontStyle" xmi:id="_OVWsAnKKEemby9dK47XbYQ" fontName="Ubuntu" fontHeight="8"/>
-          <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_OVWsA3KKEemby9dK47XbYQ" points="[0, 0, 229, -53]$[0, 27, 229, -26]$[-144, 27, 85, -26]$[-144, 52, 85, -1]"/>
+          <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_OVWsA3KKEemby9dK47XbYQ" points="[0, 0, 229, -53]$[0, 27, 229, -26]$[-74, 27, 155, -26]$[-74, 62, 155, 9]$[-126, 62, 103, 9]"/>
           <sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_OVYhMHKKEemby9dK47XbYQ" id="(0.5,1.0)"/>
           <targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_OVYhMXKKEemby9dK47XbYQ" id="(0.13333333333333333,0.02)"/>
         </edges>
@@ -253,49 +253,49 @@
         </edges>
         <edges xmi:type="notation:Edge" xmi:id="_OVfO4nKKEemby9dK47XbYQ" type="4001" element="_OUUKMHKKEemby9dK47XbYQ" source="_OUty03KKEemby9dK47XbYQ" target="_OUzSYHKKEemby9dK47XbYQ">
           <children xmi:type="notation:Node" xmi:id="_OVfO5nKKEemby9dK47XbYQ" type="6001">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVf18HKKEemby9dK47XbYQ" x="-8" y="-10"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVf18HKKEemby9dK47XbYQ" x="-6" y="-10"/>
           </children>
           <children xmi:type="notation:Node" xmi:id="_OVf18XKKEemby9dK47XbYQ" type="6002">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVf18nKKEemby9dK47XbYQ" x="5" y="57"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVf18nKKEemby9dK47XbYQ" x="-20" y="57"/>
           </children>
           <children xmi:type="notation:Node" xmi:id="_OVf183KKEemby9dK47XbYQ" type="6003">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVf19HKKEemby9dK47XbYQ" x="-51" y="10"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVf19HKKEemby9dK47XbYQ" x="-50" y="-12"/>
           </children>
           <styles xmi:type="notation:ConnectorStyle" xmi:id="_OVfO43KKEemby9dK47XbYQ" routing="Rectilinear"/>
           <styles xmi:type="notation:FontStyle" xmi:id="_OVfO5HKKEemby9dK47XbYQ" fontName="Ubuntu" fontHeight="8"/>
-          <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_OVfO5XKKEemby9dK47XbYQ" points="[-14, 0, -199, 52]$[-14, -70, -199, -18]$[126, -70, -59, -18]"/>
+          <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_OVfO5XKKEemby9dK47XbYQ" points="[-14, 0, -199, 52]$[-14, -75, -199, -23]$[126, -75, -59, -23]"/>
           <sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_OViSMHKKEemby9dK47XbYQ" id="(0.5,0.0)"/>
           <targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_OViSMXKKEemby9dK47XbYQ" id="(0.5,1.0)"/>
         </edges>
         <edges xmi:type="notation:Edge" xmi:id="_OViSMnKKEemby9dK47XbYQ" type="4001" element="_OUVYUHKKEemby9dK47XbYQ" source="_OUty03KKEemby9dK47XbYQ" target="_OUzSYHKKEemby9dK47XbYQ">
           <children xmi:type="notation:Node" xmi:id="_OVkHYHKKEemby9dK47XbYQ" type="6001">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVkHYXKKEemby9dK47XbYQ" x="25" y="-10"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVkHYXKKEemby9dK47XbYQ" x="27" y="-10"/>
           </children>
           <children xmi:type="notation:Node" xmi:id="_OVkHYnKKEemby9dK47XbYQ" type="6002">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVkHY3KKEemby9dK47XbYQ" x="3" y="-60"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVkHY3KKEemby9dK47XbYQ" x="-30" y="-60"/>
           </children>
           <children xmi:type="notation:Node" xmi:id="_OVkucHKKEemby9dK47XbYQ" type="6003">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVkucXKKEemby9dK47XbYQ" x="-39" y="15"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVkucXKKEemby9dK47XbYQ" x="-42" y="-15"/>
           </children>
           <styles xmi:type="notation:ConnectorStyle" xmi:id="_OViSM3KKEemby9dK47XbYQ" routing="Rectilinear"/>
           <styles xmi:type="notation:FontStyle" xmi:id="_OViSNHKKEemby9dK47XbYQ" fontName="Ubuntu" fontHeight="8"/>
-          <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_OViSNXKKEemby9dK47XbYQ" points="[-49, 0, -234, 52]$[-49, -102, -234, -50]$[126, -102, -59, -50]"/>
+          <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_OViSNXKKEemby9dK47XbYQ" points="[-49, 0, -234, 52]$[-49, -105, -234, -53]$[126, -105, -59, -53]"/>
           <sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_OVkucnKKEemby9dK47XbYQ" id="(0.5,0.0)"/>
           <targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_OVkuc3KKEemby9dK47XbYQ" id="(0.5,1.0)"/>
         </edges>
         <edges xmi:type="notation:Edge" xmi:id="_OVkudHKKEemby9dK47XbYQ" type="4001" element="_OUWmcHKKEemby9dK47XbYQ" source="_OUqvgHKKEemby9dK47XbYQ" target="_OUzSYHKKEemby9dK47XbYQ">
           <children xmi:type="notation:Node" xmi:id="_OVlVgHKKEemby9dK47XbYQ" type="6001">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVlVgXKKEemby9dK47XbYQ" x="29" y="-10"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVlVgXKKEemby9dK47XbYQ" x="36" y="-10"/>
           </children>
           <children xmi:type="notation:Node" xmi:id="_OVl8kHKKEemby9dK47XbYQ" type="6002">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVl8kXKKEemby9dK47XbYQ" x="-99" y="-34"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVl8kXKKEemby9dK47XbYQ" x="-101" y="-34"/>
           </children>
           <children xmi:type="notation:Node" xmi:id="_OVl8knKKEemby9dK47XbYQ" type="6003">
-            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVl8k3KKEemby9dK47XbYQ" x="67" y="-17"/>
+            <layoutConstraint xmi:type="notation:Bounds" xmi:id="_OVl8k3KKEemby9dK47XbYQ" x="69" y="-12"/>
           </children>
           <styles xmi:type="notation:ConnectorStyle" xmi:id="_OVkudXKKEemby9dK47XbYQ" routing="Rectilinear"/>
           <styles xmi:type="notation:FontStyle" xmi:id="_OVkudnKKEemby9dK47XbYQ" fontName="Ubuntu" fontHeight="8"/>
-          <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_OVkud3KKEemby9dK47XbYQ" points="[-1, 0, -551, 212]$[-1, -280, -551, -68]$[491, -280, -59, -68]"/>
+          <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_OVkud3KKEemby9dK47XbYQ" points="[-1, 0, -551, 212]$[-1, -295, -551, -83]$[491, -295, -59, -83]"/>
           <sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_OVl8lHKKEemby9dK47XbYQ" id="(0.5,0.0)"/>
           <targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_OVl8lXKKEemby9dK47XbYQ" id="(0.5,1.0)"/>
         </edges>
@@ -468,7 +468,8 @@
     <ownedDiagramElements xmi:type="diagram:DEdge" xmi:id="_OUMOYHKKEemby9dK47XbYQ" sourceNode="_OTTdkHKKEemby9dK47XbYQ" targetNode="_OTOlEHKKEemby9dK47XbYQ">
       <target xmi:type="ecore:EClass" href="BDD.ecore#//Subtree"/>
       <semanticElements xmi:type="ecore:EClass" href="BDD.ecore#//Subtree"/>
-      <ownedStyle xmi:type="diagram:EdgeStyle" xmi:id="_OUNcgHKKEemby9dK47XbYQ" targetArrow="InputClosedArrow" routingStyle="tree">
+      <ownedStyle xmi:type="diagram:EdgeStyle" xmi:id="_OUNcgHKKEemby9dK47XbYQ" targetArrow="InputClosedArrow" routingStyle="manhattan">
+        <customFeatures>routingStyle</customFeatures>
         <description xmi:type="style:EdgeStyleDescription" href="platform:/plugin/org.eclipse.emf.ecoretools.design/description/ecore.odesign#//@ownedViewpoints[name='Design']/@ownedRepresentations[name='Entities']/@defaultLayer/@edgeMappings[name='EC%20ESupertypes']/@style"/>
         <beginLabelStyle xmi:type="diagram:BeginLabelStyle" xmi:id="_OUNcgXKKEemby9dK47XbYQ" showIcon="false">
           <labelFormat>italic</labelFormat>