From f3308f01d1ef83e3605136ca866bf1c2eee98e2a Mon Sep 17 00:00:00 2001
From: Jueun Park <s5616012@mailbox.tu-dresden.de>
Date: Thu, 14 Oct 2021 02:45:39 +0900
Subject: [PATCH] Update
---
sections/stm2.tex | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/sections/stm2.tex b/sections/stm2.tex
index ac9bf95..cbdb956 100644
--- a/sections/stm2.tex
+++ b/sections/stm2.tex
@@ -45,9 +45,9 @@ Before it starts with the parameter inference, the random testing generator of S
During the implementation phase of parameter inference, RAG was beneficial at writing codes. At writing codes for parser and backtransformation, attributes could not be applicated, because the functional parts change the structure of AST, which conflicts to the definition of attribute and also in JastAdd. So, it could not be realized that attributes can be practical. But, following attributes and features of JastAdd were helpful to construct the generators and implement them:
\begin{itemize}
-\item As long as a returned type can be called or storable in primitive way, the syntax in RAG is reduced with an equlas sign and simpler than in common programming language. Therefore, the source codes are compact. To compare how RAG could be implemented effectively, see the implementation of an attribute in this work in Listing 5.3 and how this attribute is defined in common Java description in Listing 5.4.
+\item As long as a returning value can be called or storable in primitive way, the syntax in RAG is reduced with an equlas sign and simpler than in common programming language. Therefore, the source codes are compact. To compare how RAG could be implemented effectively, see the implementation of an attribute in this work in Listing 5.3 and how this attribute is defined in common Java description in Listing 5.4.
\item To iterate all paths available in OpenAPI, an inherited attribute facilitated the writing effort. Paths Objects are child nodes of OpenAPI Object, so, all that should have been done was only two lines of code instead of writing an extra for loop. See Listing 5.5.
-\item Collection attributes
+\item As its name, Reference Attribute Grammar, every AST node can be referenced by an attribute. For instance, with an collection attribute. A reference defined in Listing 4.1 contains only a String variable named Ref, it still could provide its Object like in Listing 5.6.
\end{itemize}
\begin{lstlisting}[language=JRAG,label={lst:attribute-infParam},caption={Attribute InferredParameter.value()}]
@@ -60,13 +60,29 @@ public String InferredParameter.value() {
}
\end{lstlisting}
-\begin{lstlisting}[language=JRAG,label={lst:java-infParam},caption={InferredParameter.value() in Java}]
+\begin{lstlisting}[language=JRAG,label={lst:inherited},caption={Inherited Attribute in Paths Object}]
inh boolean PathsObject.inferUrl();
eq OpenAPIObject.getPathsObject(int i).inferUrl(){
...
}
\end{lstlisting}
+\begin{lstlisting}[language=JRAG,label={lst:coll-param},caption={Collection Attribute in Parameter Object}]
+coll List<ParameterTuple> OpenAPIObject.parameterTuples() [new ArrayList<>()] root OpenAPIObject;
+ ParameterTuple contributes this
+ to OpenAPIObject.parameterTuples();
+...
+syn ParameterObject ParameterOb.parameterObject();
+eq ParameterObject.parameterObject() = this;
+eq ParameterReference.parameterObject() {
+ for( ParameterTuple t : root().parameterTuples() ){
+ if( t.getKey().equals(getRef().substring(getRef().lastIndexOf("/")+1, getRef().length())) )
+ return t.getParameterOb().parameterObject();
+ }
+ return new ParameterObject();
+}
+\end{lstlisting}
+
% Result
% Future work
--
GitLab