diff --git a/sections/benefits.tex b/sections/benefits.tex
index 0218de0352f72f89d1435d6c6ac30c55102055c5..d78b70dacbd85be019d45a5a485cd90b91ed5fb8 100644
--- a/sections/benefits.tex
+++ b/sections/benefits.tex
@@ -4,8 +4,7 @@
\item{\textbf{RQ3 : Which advantages can RAG provide with its features at expressing testing approaches?}}
\end{description}
-
-
+% General
% Helpful attributes (Collection, inherited, easier return with =)
During the implementation phase of parameter inference, RAG was beneficial at writing codes. At writing codes for parser and back-transformation, attributes could not be applied, 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:
@@ -37,6 +36,8 @@ eq OpenAPIObject.getPathsObject(int i).inferUrl(){
}
\end{lstlisting}
+% Extension
+
\begin{comment}
> To evaulate how well-suited RAGs are for API testing, we revisit the research questions...
diff --git a/sections/feasibility.tex b/sections/feasibility.tex
index 188adc166e7ff469c8111a04b31f11517f2a01a0..bdcbfd9c0ad5fbe3c79db39c008ae68b5baa0f50 100644
--- a/sections/feasibility.tex
+++ b/sections/feasibility.tex
@@ -17,4 +17,4 @@ Several of them inference parameters or operations or use test model generation.
To determine an answer of this question, we have constructed a data structure for OpenAPI specification in \Cref{ch:rago} to parse OpenAPI documents and validated the parser with 98 commercial APIs, i.e. the parser taken an OpenAPI document returns the same elements except elements with empty values and sibling elements of references in an OpenAPI document. The input and output documents still semantically are same. In \Cref{ch:stm}, we have also implemented two Fuzzing approaches (Random Testing, Parameter Inference). Parameter Inference is motivated by Specification-based Approach\cite{ed2018automatic} and RESTTESTGEN\cite{viglianisi2020resttestgen}, where seperate properties of responses are collected and used as inputs in a parameter with the same schema of a response.
% 3
-Several approaches are based on their own metamodels. It is not clear yet, whether such model-based approaches could be developed in RAGs. While implementing metamodel generations of approaches in RAGs, a JastAdd- and ILP-based framework \cite{gotz2018jastadd} could be helpful to analyze and solve model problems, because it gives an optimized model solution for a problem described in AST model. Particularly, the OpenAPI structure implemented in this work is much smaller than models denied in \cite{gotz2018jastadd}. So, it could produce an interesting result for model problems in OpenAPI testing.
\ No newline at end of file
+Several approaches are based on their own metamodels. It is not clear yet, whether such model-based approaches could be developed in RAGs. For implementing metamodel generations of approaches in RAGs, a JastAdd- and ILP-based framework \cite{gotz2018jastadd} could be helpful to analyze and solve model problems, because it gives an optimized model solution for a problem described in AST model. Particularly, the OpenAPI structure implemented in this work is much smaller than models denied in \cite{gotz2018jastadd}. So, it could produce an interesting result for model problems in OpenAPI testing.
\ No newline at end of file
diff --git a/sections/stm2.tex b/sections/stm2.tex
index fbf428789b81682f3e389f449897df2b2840739e..1268f196d203dc973cd782054bfb326619f54312 100644
--- a/sections/stm2.tex
+++ b/sections/stm2.tex
@@ -66,7 +66,7 @@ syn List<String> ParameterObject.addinfPathParameters(String pathRef,List<String
}
\end{lstlisting}
-Before it starts with the parameter inference, the random testing generator of \Cref{sec:stm1} is executed first (Line 1, Listing~\ref{lst:parameter-inference}). During this execution, the status code of a response is checked if it is a successful response with 200 status code (Line 4, Listing~\ref{lst:parameter-inference}). Afterwards, the response schema of returned values is also checked. If it is in type array, the function "writeDictionary" is iterated, otherwise it only executed once (Listing~\ref{lst:parameter-dict}). The attribute "writeDictionary" saves the returend values of a successful response in seperate properties and write them in a dictionary (e.g. properties "id" and "name" are seperately stored with their value in the dictionary). If the schema of a response provides a reference of a schema object, the field name gets a name of a reference as prefix. Subsequently, this implementation does the similar way of execution in random testing at the generation phase. Firstly, it iterates all parameter objects (Line 14, Listing~\ref{lst:parameter-inference}) and examines whether the parameter type is Path or Query (Line 15-18, Listing~\ref{lst:parameter-inference}). Both attributes return URIs with parameter values inferred by the dictionary and case insensitive comparison (Listing~\ref{lst:parameter-case}). Generated URIs are put in a list. Lastly, the generator attribute sends requests with the URIs and starts with observation (Line 20-21, Listing~\ref{lst:parameter-inference}).
+Before it starts with the parameter inference, the random testing generator of \Cref{sec:stm1} is executed first (Line 1, Listing~\ref{lst:parameter-inference}). During this execution, the status code of a response is checked if it is a successful response with 200 status code (Line 4, Listing~\ref{lst:parameter-inference}). Afterwards, the response schema of returned values is also checked. If it is in type array, the function "writeDictionary" is iterated, otherwise it only executed once (Listing~\ref{lst:parameter-dict}). The attribute "writeDictionary" saves the returend values of a successful response in seperate properties and write them in a dictionary (e.g. properties "id" and "name" are seperately stored with their value in the dictionary). If the schema of a response provides a reference of a schema object, the field name gets a name of a reference as prefix. Subsequently, this implementation does the similar way of execution in random testing at the generation phase. Firstly, it iterates all parameter objects (Line 14, Listing~\ref{lst:parameter-inference}) and examines whether the parameter type is Path or Query (Line 15-18, Listing~\ref{lst:parameter-inference}). Both attributes return URIs with parameter values inferred by the dictionary and case insensitive comparison (Line 4, Listing~\ref{lst:parameter-case}). Generated URIs are put in a list. Lastly, the generator attribute sends requests with the URIs and starts with observation (Line 20-21, Listing~\ref{lst:parameter-inference}).
% Result
As results, the test case generator with parameter inference implemented in this framework could create maximum over 300 acceptable URIs for the parameter petId in the selected API, pet store, at the operation getPetById. It generated also numerous requests denied by the server. After the observation of several execution iterations, it can be assumed that the API with this operation sends 200 or 404 status codes randomly or according to some rules, because a same URI provided status codes in that way.
\ No newline at end of file