Skip to content
Snippets Groups Projects
Commit b259df67 authored by Jueun Park's avatar Jueun Park
Browse files

Update

parent d55b3d2c
No related branches found
No related tags found
No related merge requests found
Pipeline #11526 passed with warnings
......@@ -42,7 +42,7 @@
\lstdefinelanguage{JRAG}[]{java}{
style=common-style,
morekeywords={abstract,public,private,boolean,aspect,null,syn,inh,coll,eq,with,int,contributes,new,return,for,if,else,this,to,true,false},
morekeywords={abstract,public,private,boolean,aspect,null,syn,inh,coll,eq,with,int,contributes,new,return,for,if,else,this,to,true,false,\&\&},
morecomment=[l]{//}, morecomment=[s]{/*}{*/},
}
......
\chapter{Evaluation}\label{ch:evaluation}
\input{sections/rq2}
\input{sections/rq3}
RQ1 : Can we express approaches from related work? \\
To answer this question, we
- test data structure and mapping \\
- request generation \\
- parameter inference \\
- for future work: more approaches like analysis in RESTler, Constructing Operation Dependency Graph in RESTest, precise inference with stemming algor\\
- \\
- \\
\begin{comment}
- What approaches and techniques exist to test OpenAPI specifications?
this is answered by section 3
- Can RAGs be used test OpenAPI specfications?
- Can the analysis techniques from the literature be expressed with RAGs?
this is answered by sec 4 + 5
- What is the benefit of expressing them with RAGs?
this is in the eval section
\end{comment}
- RQ2 : What makes it easier to use RAGs than normal code, what makes it harder?\\
- attributes for navigation/name resolution \\
- implementing relative bigger and structured codes with small definitions\\
- effort to be used to JastAdd\\
% 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:
\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 equals 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 a 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
\input{sections/rq3}
\ No newline at end of file
......@@ -18,7 +18,7 @@ The follwing code in Listing 5.2 shows how the parameter inference is compiled w
generateRequests();
...
for (ResponseTuple t : getResponseTuples()) {
if (responseCode == 200) {
if (responseCode == 200 \&\& t.getKey().equals("200")) {
SchemaObject respSchema = t.getResponseSchema();
if (respSchema.getType().equals("array"))
writeDictionaryWithArray(respSchema, response.toString());
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment