# Refactoring for Java-Structured Concurrency
## 4 Design
### Program Analysis  
In this section, we will focus on scope analysis. This analysis provides a critical foundation for subsequent refactoring.  
Scope analysis obtains the variables which scopes will change after refactoring. The structured concurrent code is typically contained within a _try-with-resources_ structure. If the method is of type \(k_{2}\) and defines variables in _os_, refactoring to a structured concurrency will reduce the scope of these variables because of the newly added _try-with-resources_ structure. As shown in Figure 1a,c, after refactoring, the _try-with-resources_ structure will include the code from line 5 to line 9 in Figure 1a. This will reduce the scope of _resultList_, as defined on line 6 in Figure 1a. Therefore, the definition of the variable _resultList_ should be moved outside of the _try-with-resources_ structure. Therefore, the purpose of scope analysis is to find these variables.  
Algorithm 2 is the pseudocode for the scope analysis algorithm, with its input parameters being the method \(m\) and the output being a set. _LocalUses_ is used to check the usage of a particular variable. Specifically, a \"local\" object represents a local variable. The _getUsesOf_ method in _LocalUses_ takes a \"local\" object as a parameter. This method yields a set of positional details on the usage of this local variable. The main steps of the algorithm are as follows:  
1. _ReStruct_ defines a collection (_res_) to collect variables which scopes may change after refactoring (line 1);
2. If the method is of type \(K_{1}\), the algorithm returns _res_ directly (lines 2-3) because the methods of type \(k_{1}\) will not introduce any new _try-with-resource_ structures after refactoring. Otherwise, it identifies the sets of subsequent statements in _ss_ and _gs_, denoted as \(set_{1}\) and \(set_{2}\) (lines 4-5). Then, it calculates the difference between \(set_{1}\) and \(set_{2}\), which represents _os_ (line 6);3. If _os_ is empty, it indicates that no variable's scope will change after refactoring, and the algorithm returns _res_ (lines 7-8);
4. Otherwise, it obtains _localUses_ to acquire the location information of where each variable is used. Then, it iterates through _os_ to check whether each statement contains a local variable. If so, it uses the method _localUses.getUsesOf_) to collect the location information of the statements that use the local variable. If this location information intersects with _set\({}_{2}\)_, it indicates that the scope of this local variable will change after refactoring, and this local variable is added to _res_ (lines 9-12). Finally, the algorithm returns _res_ (line 13).  
```
Input: Method: \(m\) Output: A set of variables
1 FunctionscopeAnalysis(\(m\)):
2 res\(\leftarrow\)\(\emptyset\);
3 ifm is an instance of \(K_{1}\)then
4 returnres;
5\(set_{1}\)\(\leftarrow\) stmts after ss in \(m\);
6\(set_{2}\)\(\leftarrow\) stmts after \(gs\) in \(m\);
7\(set_{3}\)\(\leftarrow\)\(set_{1}-set_{2}\);
8 ifset\({}_{3}\)==nullthen
9 returnres;
10 localUses\(\leftarrow\) obtain localUses info in \(m\);
11 foreachst in \(set_{3}\)do
12 ifst contains localthen
13 if\(set_{2}\)\(\cap\)localUses.getUsesOf(local)then
14 res.add(local);
15 returnres;
```  
**Algorithm 2**Scope Analysis