diff --git a/sections/experimentresults.tex b/sections/experimentresults.tex
index 1b53dd8295a936430d988b00b107dc0d16d1cd4a..06e7e732f6a2396e0e6bc1ffc2a24bc5fa145c4b 100644
--- a/sections/experimentresults.tex
+++ b/sections/experimentresults.tex
@@ -11,6 +11,45 @@
 - attributes for navigation/name resolution \\
 - implementing relative bigger and structured codes with small definitions\\
 - effort to be used to JastAdd\\
-- \\
-- \\
-- \\
\ No newline at end of file
+
+% 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 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 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 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()}]
+syn String InferredParameter.value() = getParameter().substring( getParameter().indexOf("?") + 1 );
+\end{lstlisting} 
+
+\begin{lstlisting}[language=JRAG,label={lst:java-infParam},caption={InferredParameter.value() in Java}]
+public String InferredParameter.value() {
+  return getParameter().substring( getParameter().indexOf("?") + 1 );
+}
+\end{lstlisting} 
+
+\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} 
\ No newline at end of file
diff --git a/sections/ragoGram.tex b/sections/ragoGram.tex
index c34142a65e3b79be3afd15725b8e8f6ced918885..5631776e3b8c441b25c5e96fd3be8bc1f6011b44 100644
--- a/sections/ragoGram.tex
+++ b/sections/ragoGram.tex
@@ -7,7 +7,7 @@ To use OpenAPI in RAG, it is firstly necessary to rewrite the OpenAPI structure
  
 \begin{lstlisting}[language=AST,label={lst:parameter-ast},caption={Parameter Object}]
 abstract ParameterOb;
-ParameterReference : ParameterOb ::= <Ref> <ParameterOb:ParameterOb>;
+ParameterReference : ParameterOb ::= <Ref>;
 ParameterObject : ParameterOb ::= <Name> <In> <Description> <Required:Boolean> <DeprecatedBoolean:Boolean> <AllowEmptyValue:Boolean> <Style> <Explode:Boolean> <AllowReserved:Boolean> [SchemaOb] <Example:Object> ExampleTuple* ContentTuple* Extension*;
 \end{lstlisting}
 
diff --git a/sections/stm2.tex b/sections/stm2.tex
index cbdb9564e68f5af10e57fc4a4aef1c07c0a21dbd..0ec919dc3ea1e25d0b90d2a6f3b84acdb5370690 100644
--- a/sections/stm2.tex
+++ b/sections/stm2.tex
@@ -41,51 +41,11 @@ for (String path : paths)
 
 Before it starts with the parameter inference, the random testing generator of Section 5.1 is executed first (Line 1). During this execution, the status code of a response is checked if it is a successful response with 200 status code (Line 4). 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 (Line 6-9). "writeDictionary" is not attributed, because it would be critical for the rule of RAG that an AST structure must not be edited, while attributes are computed. However, the function "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) and examines whether the parameter type is Path or Query (Line 15-18). Both attributes return URIs with parameter values inferred by the dictionary and case insensitive comparison. Generated URIs are put in a list. Lastly, the generator attribute sends requests with the URIs and starts with observation (Line 20-21).
 
-% 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 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 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 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()}]
-syn String InferredParameter.value() = getParameter().substring( getParameter().indexOf("?") + 1 );
-\end{lstlisting} 
-
-\begin{lstlisting}[language=JRAG,label={lst:java-infParam},caption={InferredParameter.value() in Java}]
-public String InferredParameter.value() {
-  return getParameter().substring( getParameter().indexOf("?") + 1 );
-}
-\end{lstlisting} 
-
-\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
+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.
 
 % Future work
+In the future, this parameter inference can be more precise with more constraints of the schema. In this novel version of Fuzzing tool in RAG, it only has constraints with schema types array, string, integer. Not only constraints that 
 
 \begin{comment}