diff --git a/sections/stm2.tex b/sections/stm2.tex
index 828a07228124b01ed872b7ee95478705dad9772a..34ce478921c2670facf70ab810d65c5ed71a5a4a 100644
--- a/sections/stm2.tex
+++ b/sections/stm2.tex
@@ -11,27 +11,25 @@ To solve this problem, most of REST API testing approaches use a stateful proces
 \end{itemize}
 
 % Process
-In our implementation, case insensitive comparison and id completion are utilized to create the basic functionality. Stemming algorithm can be also extended in the future. \\
-The code in Listing 5.2 shows how the parameter inference performs with predefined attributes:
+In the implementation of this work, case insensitive comparison and id completion are utilized to create the basic functionality. Stemming algorithm can be also extended in the future. \\
+The follwing code in Listing 5.2 shows how the parameter inference is compiled with predefined attributes:
 
 \begin{lstlisting}[language=JRAG,label={lst:parameter-inference},caption={Parameter Inference}]
 generateRequests();
 ...
 for (ResponseTuple t : getResponseTuples()) {
   if (responseCode == 200) {
-  SchemaObject respSchema = t.getResponseSchema();
-  if (respSchema.getType().equals("array"))
-    writeDictionaryWithArray(respSchema, response.toString());
-  else
-    writeDictionary(respSchema, response.toString());
+    SchemaObject respSchema = t.getResponseSchema();
+    if (respSchema.getType().equals("array"))
+      writeDictionaryWithArray(respSchema, response.toString());
+    else
+      writeDictionary(respSchema, response.toString());
   }
 }
 ...
 List<String> paths = new ArrayList<>();
 for (ParameterOb o : operationObject.getParameterObs()) {
   ParameterObject p = o.parameterObject();
-  SchemaObject s = p.getSchemaOb().schemaObject();
-
   if (p.getIn().equals("path"))
     paths = p.addinfPathParameters(pathRef, paths);
   else if (p.getIn().equals("query"))
@@ -41,32 +39,22 @@ for (String path : paths)
   connectGET(path);
 \end{lstlisting} 
 
-
+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 (e.g. properties "id" and "name" are seperately stored with their value in the dictionary). 
 
 % Result
 asdfasdfsdafasdf
 
+% Future work
+
 \begin{comment}
 
 - Process \\
 - writeDictionary, writeDictionaryWithArray
-- Collection \\
+- Collection (Listing) \\
 - Algorithms \\
 - Case insensitive  \\
 
 - Results
-
-
-generateRequests();
-//
-for (ResponseTuple t : getResponseTuples()) {
-  if (t.getKey().equals("200") \& \& responseCode == 200) {
-  SchemaObject respSchema = t.getResponseSchema();
-  if (respSchema.getType().equals("array"))
-    writeDictionaryWithArray(respSchema, response.toString());
-  else
-    writeDictionary(respSchema, response.toString());
-  }
-}
-//
+maximal over 300 akzeptierte paths fuer petid generierbar 
+in pet store api werden pets zufaellig dauernd erstellt und geloescht vermutlich. nach mehreren iterationen ist es beobachtbar dass diese operation zufaellig oder nach regeln 200 und 404 erzeugen.
 \end{comment}
\ No newline at end of file