ArCode: Facilitating the Use of Application Frameworks to Implement Tactics and Patterns
AArCode: Facilitating the Use of ApplicationFrameworks to Implement Tactics and Patterns
Ali Shokri
Rochester Institute of Technology
Rochester, NY, United [email protected]
Joanna C. S. Santos
Rochester Institute of Technology
Rochester, NY, United [email protected]
Mehdi Mirakhorli
Rochester Institute of Technology
Rochester, NY, United [email protected] ©2021 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, includingreprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, orreuse of any copyrighted component of this work in other works.
Abstract —Software designers and developers are increasinglyrelying on application frameworks as first-class design con-cepts. They instantiate the services that frameworks provideto implement various architectural tactics and patterns. Oneof the challenges in using frameworks for such tasks is thedifficulty of learning and correctly using frameworks’ APIs. Thispaper introduces a learning-based approach called A R C ODE to help novice programmers correctly use frameworks’ APIsto implement architectural tactics and patterns. A R C ODE hasseveral novel components: a graph-based approach for learningspecification of a framework from a limited number of trainingsoftware, a program analysis algorithm to eliminate erroneoustraining data, and a recommender module to help programmersuse APIs correctly and identify API misuses in their program. Weevaluated our technique across two popular frameworks: JAASsecurity framework used for authentication and authorizationtactic and Java RMI framework used to enable remote methodinvocation between client and server and other object orientedpatterns. Our evaluation results show (i) the feasibility of usingA R C ODE to learn the specification of a framework; (ii) A R C ODE generates accurate recommendations for finding the next APIcall to implement an architectural tactic/pattern based on thecontext of the programmer’s code; (iii) it accurately detects APImisuses in the code that implements a tactic/pattern and providesfix recommendations. Comparison of A R C ODE with two priortechniques (MAPO and GrouMiner) on API recommendationand misuse detection shows that A R C ODE outperforms theseapproaches.
Index Terms —Software Framework, Architectural Tactics, APISpecification, API Usage Model, API Recommendation, APIMisuse Detection
I. I
NTRODUCTION
To satisfy performance, security, reliability and other qualityconcerns, architects need to compare and carefully choosea combination of architectural patterns, styles or tactics. Inthe subsequent development phase, these architectural choicesmust be implemented completely and correctly in order toavoid a drift from envisioned design. Prior work [1] by Cer-vantes, Velasco-Elizondo, and Kazman confirms that softwaredesigners and developers are increasingly relying on appli-cation frameworks as first-class design concepts to facilitateimplementation of architectural tactics and patterns.
Softwareframeworks are reusable software elements that provide keyfunctionalities, addressing recurring concerns across a rangeof applications. They incorporate many architectural patternsand tactics to prevent software designers and developers from implementing software from scratch [1], [2]. For instance,the architecture of most contemporary enterprise applicationsrelies on the
Spring Framework that provides pre-packagedsolutions to implement various architectural concepts rangingfrom
Model-View-Controller (MVC) patterns to authentication and authorization security tactics [3], [4].Developers use Application Programming Interfaces (APIs)to import and use the frameworks’ functionalities [2], [5].Therefore, programs’ quality largely depends on using theseAPIs correctly [6]. Multiple studies have shown that proper useof a framework’s API requires an in-depth understanding ofits underlying architectural patterns and tactics, class structure,and set of tacit sequence calls, data-flows as well as interfacesthat need to be implemented [1], [6]–[8]. Recent qualitativeand quantitative studies have reported that implementing ar-chitectural tactics is more complex compared to deliveringsoftware functionalities, and novice and non-architecture savvydevelopers struggle in implementing architectural tactics andpatterns [4], [6]. Previous paper by Soliman, Galster, andRiebisch published at ICSA [9] has indicated that developersrely on sources such as Q&A websites (e.g. StackOverflow) tofind information on how to use frameworks, implement tacticsand patterns for specific quality attributes [10]. However, priorresearch have also shed a light that snippets on acceptedanswers of Q&A websites can contain design flaws, bugs orvulnerabilities that get reproduced across multiple softwaresystems that reused that code snippet “as is” [11], [12].The prior work on framework API recommendations [13]–[17], [17]–[19], [19]–[31] focus on low level, local datastructure related concerns and basic utility frameworks usedto implement various data structures. This line of work fallshort of addressing the challenges of implementing tactics andpatterns and has not fully studied frameworks used to bring anew architectural tactic or pattern into a given system design.Other researchers have attempted to develop recommendersystems to assist programmers in implementing architecturaltactics and patterns [4], [32], [33]. However, prior work doesnot support implementing architectural tactics and patternsusing frameworks. In this paper, we aim to study frame-works with architectural implications that address tactics orpatterns. We propose an approach entitled A R C ODE to helpprogrammers implement an architectural tactic or pattern usingAPI recommendations. A R C ODE leverages a novel learning a r X i v : . [ c s . S E ] F e b echnique to infer an accurate and explicit API specificationmodel which will be used for generating recommendations.The significance of the contribution made by this paper isbriefly described below: • To the best of our knowledge, this is the first study focusingon inferring and using API specification of a softwareframework with architectural implications (e.g., frameworksimplements architectural tactics and patterns). • We present a program analysis approach to reverse engineera novel G RAPH - BASED F R AMEWORK A PI U S A GE M ODEL ( GRAAM ), which is an abstract and semi-formal represen-tation of how a framework’s API is being used in a givenprogram to implement tactics and patterns. • An automated approach to detect projects that violate frame-works API properties. We release a program analysis methodthat analyze the byte code of frameworks and extract anexplicit usage model of framework APIs using a conceptnamed I NTER - F RAMEWORK D EPENDENCY ( IFD ) model.Later the IFD can be used to identify projects that violatea framework’s implicit API order constraints. • A novel inference algorithm called A R C ODE to constructthe framework API specification model from a repositoryof
GRAAMs . A R C ODE is an inter-procedural context-, andflow- sensitive static analysis approach to automatically infera specification model of frameworks from two sources,limited sample programs and a framework source code. • An empirical investigation of the usefulness of the pro-posed approach to recommend APIs and detect API mis-uses for tactics’ implementation on two popular Java-basedframeworks. We use Java Authentication and AuthorizationServices (JAAS) and Remote Method Invocation (RMI)as case studies. JAAS framework is used to implement authentication and authorization security tactics [4], whileRMI framework is used as a building block to implement anumber of object oriented patterns such as client-server andremote method call. We demonstrate that A R C ODE can helpdevelopers implement tactics and patterns via an accurateAPI recommendation and API misuse detection when suchframeworks are used.The remainder of this paper is organized as follows. Sec-tion II provides an overview of our approach. Section IIIbriefly describes data collection phase. Section IV presentsour graph-based API usage model (GRAAM) for a program.Section V describes A R C ODE , our automated approach forinferring a framework API specification model from extractedGRAAMs. An experimental evaluation of the approach ispresented in Section VII. Section VIII discusses threats tovalidity of the approach. Section IX reviews related work.Lastly, Section X concludes this paper.II. O
VERVIEW A R C ODE is designed to perform API recommendation andmisuse detection for application frameworks used to imple-ment architectural tactics and patterns. In particular, theseframeworks express a great degree of inter-process commu-nication and API interactions beyond a single class, module or process [4]. A R C ODE aims to help novice developers,and non-architecture savvy developers to use frameworks.A R C ODE learns the API specification of frameworks fromlimited sound program examples. A program is considered sound if it uses the framework API correctly to implementthe tactic. As shown in Figure 1, the approach has four phases:
We create acode repository of programs that incorporate the frame-work of interest. Section VII use learning saturation asa measure of indicating how many training projects arerequired.
Given the training data, we perform a context- , path- , and flow-sensitive static analysis to create an inter-procedural graph-based representation of API usages foreach program. In this phase, we ensure that only soundtraining programs will be included in our training data.To guarantee the syntax correctness, we first compile pro-grams and generate their jar files. Moreover, to verify thata program is semantically error free (w.r.t. API usages),we use a novel technique to extract I NTER - F RAMEWORK D EPENDENCY ( IFD ) model from the framework’s in-ternal source code. This model encompasses mandatoryorder constraints of APIs that are enforced by the frame-work and must be preserved in any given program. Thisapproach identifies and rules out incorrect API usages andAPI violations. Leveraging the IFD model, we separatesound programs from those that violate implicit rules ofAPI usage required by the framework.
For each sound program, we create its G raph-based F r amework A PI Us a ge M odel (GRAAM)which is an abstract model demonstrating how the frame-work API was used in a given validated training data.Finally, via a recursive learning method the frameworkAPI specification model is created from a set of generatedGRAAMs. : The learnt model is used inthis phase to implement a recommender system guidingprogrammers in using APIs. Specifically, this systemanalyzes the program under development and recommendswhat APIs should be considered and how they should beused in that program to correctly implement a tactic or apattern. Furthermore, if there are API misuses, ARCODEwill detect and recommend fixes.III. D ATA C OLLECTION AND P REPARATION P HASE
The first phase of this approach is focused on collectinga set of projects that uses a framework of interest. Theseprojects should match the following criteria: (i) it imports anduses the framework API, and (ii) it is syntactically correct.For checking the first condition, we scan the source code andcheck for API statements in the code. To guarantee the syntaxcorrectness (second condition), we compile the programs togenerate their JAR files. earch for Projects that uses the Framework
Version 4
Projects(JAR files)Framework Source Code
Static Analysis of the Frameworks’ Source Code to Extract API Strict Orders
Inter-framework Dependencies (IFD)
Primary API Usage Graphs ExtractionSoundness Investigation & GRAAMs Generation Primary API Usage Graphs Sound GRAAMsInferred Framework API Specification Model Framework API Specification Inference API RecommendationAPI Misuses Detection
RepositoriesTutorials
Fig. 1: Overview of our approach (A R C ODE )IV. T
RAINING D ATA P ROCESSING AND V ALIDATION P HASE
In the previous phase, we obtained collected projects thatuse a framework API and are compilable. However, these twocharacteristics do not guarantee these projects to be sound .Therefore, this second phase focuses on finding sound projectsthat can be used for training.Distinguishing sound and unsound projects require a so-phisticated program representation model that can capturefundamental information regarding the usage of the frameworkAPIs including but not limited to object instantiation, staticand non-static method calls, as well as static and non-staticfield accesses. These constructs can be scattered over multiplemethods, which requires an inter-procedural analysis of theprogram. Such a representation must also capture implemen-tation of interfaces and inheritances of abstract classes of theframework. Moreover, this model shall be able to representrelationships between the framework APIs, allowable data de-pendencies between these methods, the logical and a usecase-driven order of method calls, and semantically equivalentsequences of API calls.In this phase, we present an approach to pre-process thetraining data to (1) extract the above elements, and (2) validatethe training data so projects which incorrectly implementtactics/patterns can be eliminated from the training process.
A. Motivating Examples
Listing 1 and Listing 2 show two real-world code snippetsof the authentication tactic [3] implemented using the JAASframework. The correct implementation of this security tacticrequires a careful sequence of API calls and manipulationsof data objects. Although these two code snippets implementauthentication tactic in a different code structure, they both:create a
Subject object and an object that implements the
CallbackHandler interface and pass them to the constructor ofthe instantiated
LoginContext object; and then call the login() method from
LoginContext .In addition to the above statements, the code in Listing 2goes further and calls the getSubject() method from a
Login-Context object (line 11) and calls the getPrincipal() methodfrom a
Subject object (line 12).From these two examples, we observe the followings: -
Observation
Only a subset of statements in a program(the highlighted lines) are related to the framework of interestand should be part of a framework API specification model.-
Observation
The framework-related statements couldbe scattered across multiple methods. Thus, the frameworkAPI specification model shall be able to interconnect thesestatements that are within different scopes.-
Observation
Multiple (sub) programs with the samebehavior might be written slightly different. For instance, bothcode snippets in Listing 1 and Listing 2 create
Subject and
CallbackHandler objects to be passed to the constructor of
LoginContext . Although the order of object instantiation intwo code snippets is different, it does not change the behaviorof the program.
1. public class TestJaasAuthentication {2. public static void main(String[] args) {3. String user = System.getProperty("user");4. String pass = System.getProperty("pass");5. boolean loginStatus = true;6. try {8. LoginContext loginContext = getLoginContext(user,pass);9. loginContext.login();10. } catch (LoginException e) { loginStatus = false; }11. if(loginStatus) System.out.println("Login Successful.");12. else System.out.println("Login Failed.");13. }14. private static LoginContext getLoginContext(String u, String p) throwsLoginException{15. CallbackHandler handler = new RanchCallbackHandler(u, p);16. Subject subject = new Subject();17. LoginContext lc = new LoginContext("RanchLogin", subject, handler)};18. return lc;19. }20. }
Listing 1:
Sample
1. public class LoginUsecase {2. private static Logger LOGGER = Logger.getLogger(LoginUsecase.class);3. public static void main(String[] args){4. BasicConfigurator.configure();5. LoginContext lc = null;6. System.setProperty("java.security.auth.login.config", "jaas2.config");7. try{8. Subject subject = new Subject();9. lc = new LoginContext("rainyDay2", subject, new JAASCallbackHandler("user1", "pass1"));10. lc.login();11. Subject subject = lc.getSubject();12. subject.getPrincipals();13. LOGGER.info("established new logincontext");14. }15. catch (LoginException e){16. LOGGER.error("Authentication failed " + e);17. }18. }19. }
Listing 2:
Sample herefore, it is necessary to develop an API usage rep-resentation model that adequately captures correct usages offrameworks’ APIs while taking these concerns into account.We developed a novel
Graph-based Framework API UsageModel (GRAAM) to address these concerns.
B. Pre-Processing and Validation
This pre-processing step identifies APIs that are used to im-plement tactics and patterns in a program, validates their usagebased on several ground-truths obtained from the framework’ssource code, and creates
Graph-based Framework API UsageModels (GRAAMs) for correct API usages.We follow a four-step process: (1)
System DependenceGraph (SDG) extraction, (2)
Slicing of the SDG, (3)
Removalof API usage violations, and (4)
Generation of Graph-basedFramework API Usage Models (GRAAMs).
1) System Dependence Graph (SDG) Extraction:
First, weperform an inter-procedural static analysis on a program andextract its context-sensitive
Call Graph using 1-CFA algo-rithm. A call graph is a directed graph representing relation-ships between caller and callee methods in a program [34]. A1-CFA context-sensitive callgraph [35] distinguishes betweensituations where a method m is being called from m or m .This type of call graph considers the possibility of differentbehaviors of the program in callee method (e.g. m ) basedon different caller methods (e.g. m or m ). For the sake ofscalability, we did not choose a higher sensitivity of context(i.e., n-CFA for n > ).Next, we compute the System Dependence Graph (SDG)of the program under analysis. An SDG is a directed graphrepresenting a whole program [36]. The nodes in this graphare statements in the program and the edges are either data or control dependencies between nodes.Since we incorporate a context-sensitive call graph, theconstructed SDG holds the following characteristics:– flow-sensitive : it accounts the order of execution of state-ments in the program being analyzed;– context-sensitive : it distinguishes different call sites. Thesame method m can be invoked by different methods (callsites). As a result, m is analyzed differently based on itscorresponding call site.– inter-procedural : it represents the system as a whole, inter-connecting statements within different methods based on thecaller-callee relationships;We use T. J. Watson Libraries for Analysis (WALA) toconstruct SDGs with the aforementioned attributes. We choseWALA over other tools (e.g. Soot [37]) because it providesbuilt-in supports for extracting SDGs from a 1-CFA call graphas well as different versions of Java language (e.g. Java 8).
2) Slicing the Extracted SDG:
In this second step, we com-pute a slice of the program p under analysis that includes allstatements s in the SDG that are either (i) a framework-related http://wala.sourceforge.net A program slice includes only the set of statements that may affect a pointof interest of the program (referred as the slice criterion) [38]. statement; or (ii) that may be affected by a framework-relatedstatement or (iii) that affects a framework-related statement.
Framework-related Statements are the statements s f thatmatch the conditions (a)-(f) listed below. Each statement s f can be related with the framework either directly (cases a , b ,and c ) or indirectly via inheritance (cases d , e , and f ):(a) it invokes a method from a framework data type (classesor interfaces declared in the framework);(b) it instantiates an object from a framework data type ;(c) it accesses a field from a framework data type ;(d) it invokes a method implemented by an application classthat inherits or implements a framework data type ;(e) it instantiates an object from an application class thatinherits or implements a framework data type ;(f) it accesses a field from an application class that inheritsor implements a framework data type ;After computing a slice of the SDG, we remove all the nodes(statements) in the remained graph that are not framework-related yet keeping the direct and indirect dependencies be-tween framework statements. The outcome of this processis the program’s Primary API Usage Graph g = ( V, E ) ,which is a directed labelled sub-graph of the SDG, with nodes v ∈ V and edges e ∈ E where E ⊆ V × V . The set of nodes V in a primary API usage graph is partitioned into three types:start node V start , end nodes V end and framework API usagenodes V f :(1) A start node v start ∈ V start represents the begining of theframework usage in a program. Each primary API usagegraph starts with a single start node ;(2) Each end node v end ∈ V end indicates the termination ofthe framework usage. Each primary API usage graph endswith one or more end node(s) ;(3) Each framework API usage node v f ∈ V f denotes aframework-related statement in a program (i.e., V f = S f ).Each v f has an associated instruction type type ( v f ) (i.e. object instantiation , field access or method invocation ).Furthermore, each v f has a target framework data type target ( v f ) , that depends on the instruction type. In caseof object instantiations, target ( v f ) is the framework classtype of the object; for method invocations, target ( v f ) isthe target of the call; and for field accesses, the target ( v f ) is the framework type that contains the field.The edge set E in a primary API usage graph has twopartitions: sequence edges E s ⊆ ( V start × V f ) ∪ ( V f × V end ) ∪ ( V f × V f ) and data dependency edges E d ⊆ V f × V f :(1) A data dependency edge e data = v src data −−−→ v dst indicatesthat v dst uses data that has been defined by v src .(2) A sequence dependency e seq = v src seq. −−→ v dst indicatesthat v dst is used after v src in the program.Figure 2a and Figure 2b show the primary API usage graphsfor the code snippets in Listing 1 and 2. We use solid edges toshow data dependencies and dashed edges to indicate sequencedependencies. For example, since the CallbackHandler ob-ject is used in the
LoginContext ’s constructor, there is adata dependency edge between init CallbackHandler and init a) Primary API usagegraph for Listing 1
Start NodeEnd NodeSubject.getPrincipals()LoginContext.getSubject()LoginContext.login()Init LoginContext(…)Init CallbackHandler(…)Init Subject(…) (b) Primary API usagegraph for Listing 2
Fig. 2: Extracted primary API usage graphs from sample codesnippets
LoginContext nodes in the primary API usage graphs. Nodeswith a lighter background represent statements that are relatedwith the framework indirectly (via inheritance).
3) Removing API Usage Violations:
We explained so farhow we analyze a project to extract its API usage informationand represent it as a primary API usage graph. However, wewant to eliminate any erroneous API usages in our trainingcorpus. Therefore, we need a reliable ground truth to identifysuch incorrect usages in a code repository and filter them outfrom the training data.A R C ODE analyzes the framework’s source codes and cap-tures the API usage rules that are not visible to the developers,but are implicitly reflected in the source code of frameworks.To do so, it performs a static analysis of the framework’ssource code to capture implicit data dependencies betweenAPIs of a framework. Since this information is obtaineddirectly from the framework, not from programs that usethe framework, it could be considered as a ground truth foridentifying API misuses.The main idea is to leverage reader-writer roles of APImethods inside a framework to find dependencies betweenthem. Using these dependencies, one can find partial API strictorders that must be followed in a program. As a results, APImisuses in a program could be identified with confidence byfinding violations from these strict orders.
Writer and
Reader methods are defined as:–
Writer method:
A method is considered as a writer regardinga specific class field if it changes the value of that specific fieldsomewhere in its body.–
Reader method:
A method is considered as a reader regard-ing a specific class field if it uses the value of that specificfield somewhere in its body.As an example, Figure 3 shows three methods from
Login-Context class in the JAAS framework. This class has var-ious fields including subject and loginSucceeded . Whilemethod login() assigns values ( writes ) to subject and login- ……… W r i t e r R e a d e r W r i t e r W r i t e r W r i t e r R e a d e r R e a d e r R e a d e r Fig. 3: Extracting Inter-framework Dependencies betweengetSubject(), logout(), and login() methods which are threeAPI methods inside LoginContext class (JAAS framework)
Version 4
LoginContext.login() LoginContext.getSubject()LoginContext.logout() L o g i n C o n t e x t . s ub j e c t L o g i n C o n t e x t . s ub j e c t L o g i n C o n t e x t . l o g i n S u cc ee d e d Fig. 4: IFD Model based on Fig. 3
Succeeded fields, methods getSubject() and logout() use( read ) these fields’ values. As a result, getSubject() and logout() methods are dependent to some data generated in login() method. We extract these information and create our
Inter-Framework Dependency (IFD) model. The IFD builtfor the framework’s code shown in Figure 3 is depicted inFigure 4.We use IFD model for identifying incorrect programs w.r.t.a framework usage. If a programmer has a framework-relatedstatement s in a program before API s while based on IFDmodel s reads data generated by s ( s data −−→ s ), then, thatprogram is considered as an incorrect program.
4) Generating Graph-based Framework API Usage Models(GRAAM):
The last step of pre-processing and data validationphase focuses on creating a representation of each trainingdata, a Graph-based Framework API Usage Model (GRAAM),which can be used by A R C ODE ’s learning algorithm. Weprovide a definition for a GRAAM further in this section.As discussed earlier, it is possible that two programs withdifferent sequences of framework-related statements imple-ment the same tactic. For example, although Listing 1 andListing 2 implement the same use case, the instantiation orderof
Subject and
CallbackHandler in their programs and so,in their corresponding primary API usage graphs (Figure 2aand Figure 2b) is different. We call these sequences of APIusage nodes as
Semantically Equivalent API Sequences .Two sequences of framework usage nodes, seq and seq , aresemantically equivalent if both conditions are true: • there is a bijection between the nodes in seq and seq .Each paired nodes s ∈ seq and s ∈ seq have the same type and target framework type , i.e. type ( s ) = type ( s ) and target ( s ) = target ( s ) ; and • the two sequences are isomorphic considering only the datadependency between APIs in each sequence.As a result, a Graph-based Framework API UsageModel (GRAAM) is a directed graph g which has the same tart NodeEnd NodeInit CallbackHandler(…)Init LoginContext(…)Init Subject(…)LoginContext.login() Start NodeEnd NodeInit CallbackHandler(…)Init LoginContext(…)Init Subject(…)LoginContext.login()LoginContext.getSubject()Subject.getPrincipals() Same sub-GRAAMs (a) (b)
Fig. 5: Built GRAAMs for programs in (a) Listing 1 and(b) Listing 2. Since both programs use semantically the same
API sequences for creating a
LoginContext object and calling login() method, their corresponding Sub-GRAAMs confinedby the purple dashed line are isomorphically the same.set of nodes as a primary API usage graph , but a different edgetype:
API Order Constraint edges. Semantically equivalentAPI sequences have a single representative in a GRAAM.In other words, two different programs with the same be-havior (w.r.t. APIs of the same framework) have isomorphicGRAAMs.For example, parts of the programs in Listing 1 and List-ing 2 including instantiation of
Subject , CallbackHandler , LoginContext , and calling login() method, implement thesame tactic (authenticate actors). Thus, their correspondingsub-GRAAMs are the same. This property of GRAAM enablesus to have the same representation for semantically equivalentAPI usages in different programs. Hence, when we look at acode repository, we can correctly identify the same API usagesand compute their frequencies.To create a GRAAM, we (i) start with a validated primaryAPI usage graph, (ii) remove all the sequence edges exceptedges from start node and edges to end node(s), and (iii) add relevant edges from IFD model to the graph. To bemore specific, this graph is built based on framework-relatedstatements identified in the program, their data dependencies captured from the program, plus data dependencies minedfrom the framework’s source code. The reasoning behindremoving sequence edges and keeping data edges is that ifthe data produced in an API call a is not being used by anAPI call a , it means that calling a before a in the programis not required, i.e., the order of a and a does not affect theprogram’s behavior. We reflect this non-restriction situation inour GRAAM by eliminating this order constraint between a and a .Figure 5 shows the created GRAAMs for the examplesin Listing 1 and 2. These GRAAMs are created based onthe primary API usage graphs depicted in Figure 2 and theIFD model shown in Figure 4. For instance, the edge be-tween LoginContext.login() and
LoginContext.getSubject() in Figure 5b comes from data dependency between
LoginCon-
Start NodeEnd NodeInit CallbackHandler(…)Init LoginContext(…)Init Subject(…)LoginContext.login()LoginContext.getSubject()Subject.getPrincipals()
End Node
Fig. 6: Built Framework API Specification Model (FSpec)from depicted GRAAMs in Figure 5a and Figure 5b text.login() and
LoginContext.getSubject() captured in IFDmodel depicted in Figure 4. As shown in Figure 5, parts ofprograms in Listing 1 and Listing 2 that implement the samething have the same sub-GRAAMs.V. T
RAINING P HASE : I
NFERRING A F RAMEWORK
APIS
PECIFICATION M ODEL (FS
PEC )A R C ODE uses the repository of created GRAAMs to inferthe Framework API Specification Model (FSpec).
A. Framework API Specification Model (FSpec)
We use the collected sound GRAAMs to build a unifiedgraph-based Framework API Specification Model (FSpec)which represents correct ways to use the framework. Thismodel aims to (a) reflect only possible correct combinationsof API calls, (b) to contain only paths that represent acorrect framework’s API call sequence, and (c) to create onerepresentative for all the semantically equivalent API usages.Figure 6 shows a Framework API Specification model(FSpec) built from the GRAAMs shown in Figure 5a andFigure 5b. Similar to a GRAAM, an FSpec encompasses threetypes of nodes: start node , end node , and framework-relatednode . An FSpec has the same edge type as a GRAAM, APIorder constraint edge. This type of edge represents the strictorders of framework APIs one should follow to correctlyincorporate that framework in a program. However, FSpechas a new label on each edge: frequency . Frequency of asub-graph of FSpec represents the number of times that thecorresponding API usage was observed in the code repositoryof sound programs.For instance, all edges between the start node and login() node in Figure 6 are labeled with frequency of . That means,there were two (semantically) equivalent API usages observedin the code repository that both (i) instantiated objects of Subject and
CallbackHandler , (ii) used those objects toinstantiate an object of LoginContext , and then, (iii) called login() method of
LoginContext . After the login() node,however, the frequencies are changed to 1. It means thathere was a program that has not used any other APIs ofJAAS framework after login() method. In addition to that, themodel shows that there was a program that continued callingframework APIs and had two more API calls.FSpec represents semantically equivalent
API usages in asingle representation. This property shows the generalizability of A R C ODE in the sense that when it visits an instance ofcorrect API usage in a program, a representative of all thesemantically equivalent API usages to the originally visitedone would be added to the FSpec under construction.
B. Inferring a FSpec Model from Sound GRAAMs
To infer a framework’s API specification model (FSpec),A R C ODE finds mergeable parts of created sound
GRAAMs.We will define mergeable parts of GRAAMs later in thissection. Through the inference process, if A R C ODE findsmeargable part of a GRAAM similar to one that was pre-viously added to the FSpec model, then, it increases thefrequencies of the corresponding edges in FSpec. Otherwise,it adds the corresponding new nodes to the model and setstheir edge frequency to 1.To guarantee that all paths from start to end nodes representsa correct framework usage, we have provided inference rulesto identify
Mergeable sub-GRAAMs . Two sub-GRAAMsare mergeable if (i) both include the start node, and (ii) their corresponding sequences are semantically equivalent .Assuming that there are two GRAAMs g and g , we explainhow the merging algorithm works such that g merges into g . • We first identify all the mergeable sub-GRAAM pairs from g and g ; • Amongst the identified merging candidates, the pair with thehighest number of nodes is selected; • The frequency of edges from sub − g increments by thefrequency of corresponding edges from sub − g ; • The remained parts of g which are not included in sub − g will be added to g ; • We repeat this process until there are no more mergeablesub-GRAAM pairs from g and g . This process guaranteesthat in the end, no semantically equivalent sequences existsin the start node’s children list.To clarify this algorithm, there are three different parts inFigure 7 that could be a candidate for merging purposes. The upper part starts with the root (e.g. node from g and node from g ) of the graph and may (or may not) contain somesuccessors of the root. The middle part does not contain rootnor any end nodes. The lower part contains at least one endnode and may (or may not) include predecessors of the endnode. To merge two GRAAMs g and g , the algorithm onlyconsiders their upper parts to avoid the emergence of incorrectpaths. Figure 7 provides an example of this situation. Assumethat → → → and → → → are two correct APIsequences. Upon merging g and g from their middle part,two incorrect paths ( → → → and → → → )are appeared in the merged graph. Fig. 7: Emergence of un-expected and unsound se-quences by merging g and g from their middle parts Upper partLower partMiddle part g g Merged graph
VI. R
ECOMMENDATION P HASE
Once A R C ODE is trained and a FSpec model is built,it can be used to help programmers correctly implementarchitectural patterns and tactics through providing correctAPI recommendations. The recommendation system has thefollowing steps:1)
Process Partial Program: it takes in a partial programwritten by a programmer and creates its GRAAM;2)
Context Based Recommendation: the recommender en-gine finds the most similar semantically equivalent
APIusages inside the FSpect to the given GRAAM. Then itfinds changes needed to be performed on the GRAAM tomake it a correct implementation of a tactic or pattern.3)
Ranked List : the outcome is provided in the form ofranked list of API recommendations (e.g. remove, add,replace). The rank of each recommendation in the list isdetermined based on the frequency of its correspondingedges in the FSpec.A R C ODE can identify the next APIs required to be called ina program to make it a complete and correct implementation.It also is able to detect misuses of APIs in a program andrecommend fixes for it. Some API misuses are not detectablein the compile time since it does not violate syntax of thelanguage. However, these are serious semantic bugs which cancompromise the entire objective of a tactic/pattern.VII. E
XPERIMENTAL S TUDY
To show the practical usefulness of our approach for com-plex software systems, we used it in experimental studiesof JAAS (Java Authentication and Authorization Services)and RMI (Remote Method Invocation) frameworks to gen-erate recommendations for projects that incorporate themto implement tactic and patterns. JAAS addresses securityarchitectural concerns in applications, and RMI supports inter-actions between different modules and methods in distributedsystems. In these two studied frameworks (i) we investigatewhether A R C ODE can learn correct ways framework APIs areinvoked to implement tactics/patterns. We rely on a learningsaturation experiment; (ii) we evaluate the accuracy of
APIrecommendation to help programmers implement tactics andpatterns, and (iii) we analyze ArCode’s performance in
APImisuse detection .Additionally, we compare A R C ODE ’s performance withMAPO [21] and GrouMiner [39], two approaches which wereeveloped for API recommendation and misuse detection, butnot evaluated on frameworks with architectural implications . A. Data Collection
To create the training data for A R C ODE , we identified alarge number of popular open-source projects using JAASand RMI frameworks. These projects were collected fromdifferent public and open-source code repositories includingGitHub, BitBucket and Maven. A team of three memberspeer reviewed programs and compiled them to generate theirbytecode. The purpose of reviewing programs was to makesure that each selected program implemented authenticationand authorization tactics and inter-process communicationpatterns and had more than one API call in its code. Thefinal repository contains projects that uses JAAS, and projects that uses RMI. This repository has a total lines of code (Java files), classes and methods. B. Finding API Usages in Programs
We created GRAAMs for projects in the code repositorybased on the approach discussed in this paper (Section IV).We also created API usages for GrouMiner, and MAPOapproaches accordingly. It is worth mentioning that a programmay have more than one entrypoint . Therefore, it is possiblethat more than one API usage can be found per program.One issue we encountered in our experiments was failureof GrouMiner when the number of nodes in its API usagegraph (i.e. graph-based object usage model) precedes 19. Sinceauthors of GrouMiner provided their source code, and to stayfaithful to the code, we did not make any changes to its sourcecode. Therefore, we exclude API usage graphs with more than19 nodes from our experiment. C. A R C ODE
Learning Saturation
To investigate the learning capability of A R C ODE , we createits learning curve . This curve represents the rate of newknowledge added to FSpec comparing to the size of newGRAAMs it visits. In the case that A R C ODE has a goodlearning ability, the rate of growth of FSpec should decreaseby visiting more GRAAMs.Figure 8a and Figure 8b show learning curve of A R C ODE while creating FSpec for JAAS and RMI frameworks in thetraining phase. Blue curves represent the cumulative size of k visited GRAAMs by ArCode. Orange curves show the size ofFSpec after visiting k GRAAMs. To conduct this experiment,we first sort the GRAAMs based on the number of theirnodes. Then, we feed A R C ODE starting with bigger chunks ofinformation. While there is an increase in the number of FSpecnodes in the initial steps, after visiting 24 GRAAMs of JAAS-based programs, we observe reaching 90% completion of thefinal FSpec model. It means that after this point, there wouldbe only 10% new information learnt by FSpec. Likewise,A R C ODE reaches 90% completion of its FSpec after visiting Frameworks used to implement tactics or patterns A program’s entrypoint is the first method invoked once it starts executing(e.g. the main() method). o f N o d e s Total %95 Saturation%90 Saturation (a) ArCode learning curvewhile visiting 51 JAAS-basedsound GRAAMs o f N o d e s Total %95 Saturation%90 Saturation (b) ArCode learning curvewhile visiting 89 RMI-basedsound GRAAMs
Fig. 8: Model saturation while creating FSpecs of JAAS andRMI frameworks51 GRAAMs of RMI-related projects. The A R C ODE learningcurve indicates that:
Finding 1:
Two case studies of RMI and JAAS indicatethat there are limited correct ways that developers incor-porated these frameworks in their program; A R C ODE ’slearning technique was able to enumerate and learn allthese possible sound usages of the frameworks.
D. API Recommendation to Implement Tactics/Patterns
To evaluate the quality of recommendations, we randomlyselect 80% of the projects of each framework in the coderepository as training and the remaining 20% as testing dataset. We use the same train and test data sets for A R C ODE ,GrouMiner, and MAPO approaches to make a fair comparisonbetween their performance.To generate labeled test cases for this experiment, we firstcreate GRAAMs of each program in the test data set andthen, we remove the last node of each GRAAM. Since a rec-ommendation system is expected to recommend the removedAPI, that API would be used as the label of that test case.Next, we ask the recommendation system to return a rankedlist of recommendations for each test case. Finally, basedon the position of the correct recommendation in the rankedlist, we compute the top-K accuracy of the recommendations( k : 1 → ). Though, since we expect only one correctanswer for each test case, the results for top-K precision andtop-K recall would be the same as top-K accuracy in ourexperiments.We also computed the top-K accuracy of recommendationsfor MAPO and GrouMiner approaches. Figure 9 shows theresult of this experiment. In the case of JAAS framework (Fig-ure 9a), A R C ODE achieved a 59% accuracy while consideringonly the top ranked (top-1) API recommendation. However, ifwe consider top-2 recommendations, the accuracy improvesto 84%. Finally, if we consider top-8 APIs (or beyond),the accuracy of recommendations provided by A R C ODE tops94%. Compared to A R C ODE , the accuracy of MAPO andGrouMiner reaches 50% and 41% for JAAS-based programs.For RMI-based programs, ArCode provides 91% accuracy for A cc u r a c y o f T o p - K R e c o mm e nd a t i o n s ( % ) Top-K Recommendations
ArCode MAPO GrouMiner 945041 (a) JAAS-based projects A cc u r a c y o f T o p - K R e c o mm e nd a t i o n s ( % ) Top-K Recommendations
ArCode MAPO GrouMiner (b) RMI-based projects
Fig. 9: Accuracy of A R C ODE , GrouMiner, and MAPO fornext API recommendations on JAAS and RMI experimentstop-2 recommendations and beyond. The highest accuracy forMAPO and GrouMiner is 43% and 17%. Based on our obser-vation, the diversity of API usages in JAAS-based programs isfewer compared to those of RMI-based programs. As a result,all approaches have their best performance in JAAS-basedrepository. Nevertheless, A R C ODE still outperforms MAPOand GrouMiner in both JAAS- and RMI-based tests.These results bring us to the following observation:
Finding 2:
ArCode’s next API recommendation outper-forms the prior work significantly (40% and more). Inboth case studies top-2 recommendations were reliable(85% in JAAS and 95% in RMI), however ArCode top-1recommendations in RMI were more reliable than JAAS.
E. API Misuse: Detecting a Missed API
One of common API missuses is missing a criticalAPI call while implementing a tactic. Authenticating userswith
LoginContext.login() without first calling
HttpSes-sion.invalidate() [4] or checking the role of a user beforegranting access are just some of many examples.To examine the accuracy of our approach in identifyingsuch cases of API misuse in programs, similar to the APIrecommendation experiment (Section VII-D), we generatelabeled test cases for this experiment. To do so, we randomlyremove an API call from each program in an iterative manner.We were able to generate 77 test cases for JAAS-based and 80test cases for RMI-based experiments. Please note that thesetest cases are generated only from test projects. Then, we askthe system to identify the missed API and recommend a fixfor it.Figure 10 depicts the result of this experiment. In the caseof the JAAS framework (Figure 10a), A R C ODE achieved a78% accuracy considering only the top ranked (top-1) APIrecommendation. Top-2 recommendation shows 91% accuracyand finally, the accuracy of recommendations provided by A R -C ODE tops 95% for top-8 recommendations and beyond. Com-paring to A R C ODE , the accuracy of MAPO and GrouMinerreaches 34% and 28% respectively. This test scenario is morecomplicated compared to the previous test case (next APIrecommendation) because, in addition to the ancestors, the A cc u r a c y o f T o p - K R e c o mm e nd a t i o n s ( % ) Top-K Recommendations
ArCode MAPO GrouMiner 953428 (a) JAAS-based projects A cc u r a c y o f T o p - K R e c o mm e nd a t i o n s ( % ) Top-K Recommendations
ArCode MAPO GrouMiner (b) RMI-based projects
Fig. 10: Accuracy of A R C ODE , GrouMiner, and MAPO formissed API recommendations on JAAS and RMI experimentsdescendants of the provided recommendation and the correctanswer should match as well. Therefore, the accuracy ofpattern-based approaches decreases in this usecase.Based on the results of this experiment we found:
Finding 3:
ArCode can identify a missed API in im-plementation of tactics/patterns and provide a recom-mendation to fix it. ArCade’s top-2 recommendationaccuracy in JAAS and RMI case studies are above 90%.Furthermore, ArCode outperforms prior work with 60%and more, making it a more reliable approach for APIrecommendations to implement tactics and patterns usingframeworks.
F. API Misuse: Wrong API Usage
Another type of misusing APIs in a program includes callingAPIs in a wrong order in that program. Although such aprogram might not show a compile time error, the expectedtactic is not implemented correctly. In this experiment, wecreate test cases that include an incorrect API usage in eachproject (e.g. incorrect order of APIs). Then, we ask the systemto first, identify this API misuse and second, recommend a fixto make that API usage correct. To create such test cases, wego over all APIs in each program iteratively, selecting tworandom APIs and swapping them to generate incorrect usagesof APIs. Following this approach, we were able to generate432 test cases for JAAS and 246 test cases for RMI framework.Then, we ask the system to identify this API misuse andrecommend a fix for it. Like the two other test scenarios,the system returns a ranked recommendation and we computeaccuracy for top-k ( k : 1 → ) recommendations.The result of this experiment is demonstrated in Fig-ure 11. In the case of JAAS framework, A R C ODE shows 77%accuracy for top-1 recommendations. Also, if we consider8-top returned recommendations (or beyond), the accuracyof A R C ODE tops 97%. The results show that MAPO andGrouMiner reach 7% and 4% accuracy respectively. This testscenario is the most complicated case compared to the previ-ous experiments. Since we are swapping two APIs, ancestorsand descendants of both the first and second APIs shouldbe matched against those that are recommended. Thus, we A cc u r a c y o f T o p - K R e c o mm e nd a t i o n s ( % ) Top-K Recommendations
ArCode MAPO GrouMiner 9774 (a) JAAS-based projects A cc u r a c y o f T o p - K R e c o mm e nd a t i o n s ( % ) Top-K Recommendations
ArCode MAPO GrouMiner (b) RMI-based projects
Fig. 11: Accuracy of A R C ODE , GrouMiner, and MAPO forfix recommendations on JAAS and RMI experimentsobserve accuracy degrading for MAPO and GrouMiner insuch experiments. Based on the results of this experiment,we observed that:
Finding 4:
ArCode accurately detects wrong API usagesand generates fix recommendation for them. Wrong APIusages are more complicated that finding a missed APIcall in a tactic/pattern. In these complex misuses, ArCodewith a large difference (60% to 90%) outperformed twoof the prior work (GrouMiner and MAPO).VIII. T
HREATS TO V ALIDITY A R C ODE aims to filter out incorrect API usages froma code repository and then, learn correct API usages fromthe remained programs. While the learnt framework APIspecification model (FSpec) does not include incorrect APIusages, we can not claim that it covers all the possible correctAPI usages. Another notable point is that A R C ODE leveragesconservative merging rules while creating an FSpec. Althoughit can guarantee that no incorrect API usage emerges in thefinal FSpec, it can affect the efficiency of the training phaseas well as the size of the final FSpec adversely. Moreover, theInter-framework Dependency (IFD) model introduced in thispaper is created based on static analysis over the source codeof the framework to find reader-writer roles of API methodsinside that framework. However, some modern frameworksuse dynamic features of object oriented languages (e.g. reflec-tions) to implement the framework. In these cases, performingdynamic analysis alongside static analysis would result incapturing more accurate dependencies between APIs.Concerning the evaluation of A R C ODE provided in thispaper, we used two popular Java based frameworks, JAAS andRMI. For generality purposes, conducting experiments withmore frameworks would be advised.IX. R
ELATED W ORK
There have been numerous works on identifying frame-works’ API specifications and creating models that enable APIrecommendation and misuse detection systems. The aim ofthese systems is to help programmers correctly use API callsand prevent incorrect usage of APIs in their programs [40], [41]. Many researchers define patterns of
API co-occurrences in the same scope of a program as an API specification. Worksin this category find the frequency of co-appearance of APIsin the same context and use it to create API co-occurrencepatterns. While most of the approaches in this category findsuch patterns within a method [26], [27], [29], [42]–[48], somego beyond and find patterns in a bigger scope (e.g. classor program) [18], [49]. We have found these works usefulfor simple API recommendation or misuse detection tasks.However, they become impractical when the problem getsmore complex as to accurately (i) identify an incorrect API order in a code, or (ii) recommend the next
API based on theorder of other APIs in a sequence .To address the aforementioned issues, more sophisticatedapproaches find
API sequence patterns in a code repository.This is an important specification needed for a correct API rec-ommendation or misuse detection. The developed techniquesin this category range from finding partial API usage patternsand creating rule-based specifications [13], [31], [50] to min-ing a complete sequence of API usage patterns [14], [16],[17], [21]–[24], [51]–[53]. As an example, MAPO [21], oneof the most respected API specification miners, aims to createpatterns of API usage sequences and leverage that to findrelevant code samples for programmers. Although sequentialAPI specification miners take API order into account, theyare not able to: (i) provide more API-related information in aprogram (e.g. data dependency) than the order of appearancein the code, and (ii) distinguish between two semanticallyequivalent sequences (Section IV).
Graph-based API pattern finders are the most advancedmethods developed to cover sequence-based API pattern min-ers shortcomings and create more detailed API specifications(e.g. data dependency between APIs). Specifically, these worksaim to track the usage of APIs related to a single object [15],[39], [54]–[56] or multiple objects [19], [25], [57]–[59] in aspecific scope in programs. For instance, GrouMiner [39], awell-appreciated graph-based API pattern miner, finds rela-tionships between APIs of the same type in a method. Whilethe mentioned works present more detailed API specifications,they still: (i) do not track dependencies across different scopes(inter-procedural), (ii) can not represent the whole contextof an API usage, and (iii) can not identify semanticallyequivalent, yet in different order, API usages in programs. A R C ODE performs an inter-procedural program analysisand infers a context-sensitive graph-based API specificationfor frameworks. This approach produces isomorphically thesame graphs for API usages that have different sequences butare semantically equivalent.X. C
ONCLUSION & F
UTURE W ORK
Obtaining API specification of a framework can enable thecorrect implementation of architectural tactics and patterns.This paper introduces A R C ODE , a novel approach for inferringframeworks’ API specification from limited projects. It relieson a Graph-based Framework API Usage model (GRAAM),hich is an inter-procedural context-, and flow-sensitive rep-resentation of APIs in a program. Furthermore, A R C ODE alsoextracts inter-framework dependencies between APIs fromframework source code and uses them to identify incorrect APIusages in programs. It uses an inference algorithm to combineall extracted GRAAMs into a framework specification model.In a series of experiments, we demonstrated that it is possi-ble to infer a framework specification model that accuratelycaptures correct API usage to implement tactics and patterns.Moreover, recommendation systems empowered by the createdframework specification model are able to provide accurateAPI recommendations, identify API misuses and provide a fixrecommendation. Future work includes exploration of addi-tional frameworks with regard to our technique and leveragingdynamic analysis alongside static analysis to extracting inter-framework dependencies.A
CKNOWLEDGMENTS
This work was partially funded by the US National ScienceFoundation (NSF) under grant number CCF-1943300, CNS-1816845 and CNS-1823246.R
EFERENCES[1] H. Cervantes, P. V. Elizondo, and R. Kazman, “A principled way to useframeworks in architecture design,”
IEEE Software , vol. 30, no. 2, pp.46–53, 2013. [Online]. Available: https://doi.org/10.1109/MS.2012.175[2] H. Cervantes, R. Kazman, J. Ryoo, J. Cho, G. Cho, H. Kim, and J. Kang,“Data-driven selection of security application frameworks during ar-chitectural design,” in
Proceedings of the 52nd Hawaii InternationalConference on System Sciences , 2019.[3] L. Bass, P. Clements, and R. Kazman,
Software Architecture in Practice ,3rd ed. Addison-Wesley Professional, 2012.[4] J. C. S. Santos, A. Peruma, M. Mirakhorli, M. Galstery, J. V. Vidal,and A. Sejfia, “Understanding software vulnerabilities related to archi-tectural security tactics: An empirical investigation of chromium, phpand thunderbird,” in , April 2017, pp. 69–78.[5] I. J. Mujhid, J. C. S. Santos, R. Gopalakrishnan, and M. Mirakhorli,“A search engine for finding and reusing architecturally significantcode,”
Journal of Systems and Software
Proceedings of the 40th International Conference onSoftware Engineering , 2018, pp. 117–127.[7] M. P. Robillard, “What makes apis hard to learn? answers from devel-opers,”
IEEE software , vol. 26, no. 6, pp. 27–34, 2009.[8] R. E. Johnson, “Documenting frameworks using patterns,” in
ConferenceProceedings on Object-oriented Programming Systems, Languages, andApplications , ser. OOPSLA ’92. New York, NY, USA: ACM, 1992, pp.63–76. [Online]. Available: http://doi.acm.org/10.1145/141936.141943[9] M. Soliman, M. Galster, and M. Riebisch, “Developing an ontologyfor architecture knowledge from developer communities,” in , 2017, pp.89–92.[10] M. Soliman, M. Galster, A. R. Salama, and M. Riebisch, “Architecturalknowledge for technology decisions in developer communities: Anexploratory study with stackoverflow,” in . IEEE Computer Society, 2016, pp. 128–133. [Online].Available: https://doi.org/10.1109/WICSA.2016.13[11] S. Baltes and S. Diehl, “Usage and attribution of stack overflow codesnippets in github projects,”
Empirical Software Engineering , vol. 24,no. 3, pp. 1259–1295, 2019. [12] F. Fischer, K. Böttinger, H. Xiao, C. Stransky, Y. Acar, M. Backes, andS. Fahl, “Stack overflow considered harmful? the impact of copy&pasteon android application security,” in . IEEE, 2017, pp. 121–136.[13] M. Acharya, T. Xie, J. Pei, and J. Xu, “Mining api patterns as partialorders from source code: from usage scenarios to specifications,” in
Proceedings of the the 6th joint meeting of the European softwareengineering conference and the ACM SIGSOFT symposium on Thefoundations of software engineering . ACM, 2007, pp. 25–34.[14] S. Shoham, E. Yahav, S. J. Fink, and M. Pistoia, “Static specificationmining using automata-based abstractions,”
IEEE Transactions on Soft-ware Engineering , vol. 34, no. 5, pp. 651–666, 2008.[15] S. Mover, S. Sankaranarayanan, R. B. P. Olsen, and B.-Y. E. Chang,“Mining framework usage graphs from app corpora,” in . IEEE, 2018, pp. 277–289.[16] J. Fowkes and C. Sutton, “Parameter-free probabilistic api mining acrossgithub,” in
Proceedings of the 2016 24th ACM SIGSOFT InternationalSymposium on Foundations of Software Engineering . ACM, 2016, pp.254–265.[17] Y. Dang, J. Wang, K. Chen, H. Zhang, T. Xie, and D. Zhang, “Api usagepattern mining,” Aug. 11 2015, uS Patent 9,104,525.[18] Y. Lamba, M. Khattar, and A. Sureka, “Pravaaha: Mining androidapplications for discovering API call usage patterns and trends,” in
Proceedings of the 8th India Software Engineering Conference . ACM,2015, pp. 10–19.[19] S. Amann, H. A. Nguyen, S. Nadi, T. N. , Nguyen, and M. Mezini,“Investigating next steps in static API-misuse detection,” in . IEEE, 2019, p. (To appear).[20] H. Zhong and H. Mei, “An empirical study on api usages,”
IEEETransactions on Software Engineering , pp. 1–1, 2018.[21] H. Zhong, T. Xie, L. Zhang, J. Pei, and H. Mei, “Mapo: Mining andrecommending api usage patterns,” in
European Conference on Object-Oriented Programming . Springer, 2009, pp. 318–343.[22] S.-K. Hsu and S.-J. Lin, “Macs: Mining api code snippets for codereuse,”
Expert Systems with Applications , vol. 38, no. 6, pp. 7291–7301,2011.[23] M. A. Saied, H. Sahraoui, E. Batot, M. Famelis, and P.-O. Talbot,“Towards the automated recovery of complex temporal api-usage pat-terns,” in
Proceedings of the Genetic and Evolutionary ComputationConference , 2018, pp. 1435–1442.[24] M. A. Saied, E. Raelijohn, E. Batot, M. Famelis, and H. Sahraoui,“Towards assisting developers in api usage by automated recovery ofcomplex temporal patterns,”
Information and Software Technology , vol.119, p. 106213, 2020.[25] X. Gu, H. Zhang, and S. Kim, “Codekernel: A graph kernel based ap-proach to the selection of api usage examples,” in .IEEE, 2019, pp. 590–601.[26] F. Thung, “Api recommendation system for software development,” in . IEEE, 2016, pp. 896–899.[27] W. Zheng, Q. Zhang, and M. Lyu, “Cross-library api recommendationusing web search engines,” in
Proceedings of the 19th ACM SIGSOFTsymposium and the 13th European conference on Foundations of soft-ware engineering . ACM, 2011, pp. 480–483.[28] X. Ren, J. Sun, Z. Xing, X. Xia, and J. Sun, “Demystify official apiusage directives with crowdsourced api misuse scenarios, erroneous codeexamples and patches,” pp. 1407–1410, 2020.[29] M. Monperrus and M. Mezini, “Detecting missing method calls as viola-tions of the majority rule,”
ACM Transactions on Software Engineeringand Methodology (TOSEM) , vol. 22, no. 1, p. 7, 2013.[30] S. Amann, H. A. Nguyen, S. Nadi, T. N. Nguyen, and M. Mezini, “Asystematic evaluation of static api-misuse detectors,”
IEEE Transactionson Software Engineering , 2018.[31] A. Wasylkowski, A. Zeller, and C. Lindig, “Detecting object usageanomalies,” in
Proceedings of the the 6th joint meeting of the Europeansoftware engineering conference and the ACM SIGSOFT symposium onThe foundations of software engineering . ACM, 2007, pp. 35–44.[32] M. Mirakhorli, H. Chen, and R. Kazman, “Mining big data for detecting,extracting and recommending architectural design concepts,” in , L. Baresi, T. Menzies,. Metzger, and T. Zimmermann, Eds. IEEE Computer Society, 2015,pp. 15–18. [Online]. Available: https://doi.org/10.1109/BIGDSE.2015.11[33] M. Bhat, C. Tinnes, K. Shumaiev, A. Biesdorf, U. Hohenstein,and F. Matthes, “Adex: A tool for automatic curation of designdecision knowledge for architectural decision recommendations,” in
IEEE International Conference on Software Architecture Companion,ICSA Companion 2019, Hamburg, Germany, March 25-26, 2019 .IEEE, 2019, pp. 158–161. [Online]. Available: https://doi.org/10.1109/ICSA-C.2019.00035[34] D. Grove, G. DeFouw, J. Dean, and C. Chambers, “Call graph con-struction in object-oriented languages,” in
Proceedings of the 12thACM SIGPLAN conference on Object-oriented programming, systems,languages, and applications , 1997, pp. 108–124.[35] O. Shivers, “Control-flow analysis of higher-order languages,” Ph.D.dissertation, PhD thesis, Carnegie Mellon University, 1991.[36] S. Horwitz, T. Reps, and D. Binkley, “Interprocedural slicing usingdependence graphs,”
ACM Transactions on Programming Languagesand Systems (TOPLAS) , vol. 12, no. 1, pp. 26–60, 1990.[37] R. Vallée-Rai, P. Co, E. Gagnon, L. Hendren, P. Lam, and V. Sundaresan,“Soot: A java bytecode optimization framework,” in
CASCON FirstDecade High Impact Papers , 2010, pp. 214–224.[38] M. Weiser, “Program slicing,” in
Proceedings of the 5th internationalconference on Software engineering . IEEE Press, 1981, pp. 439–449.[39] T. T. Nguyen, H. A. Nguyen, N. H. Pham, J. M. Al-Kofahi, and T. N.Nguyen, “Graph-based mining of multiple object usage patterns,” in
Proceedings of the the 7th joint meeting of the European softwareengineering conference and the ACM SIGSOFT symposium on Thefoundations of software engineering . ACM, 2009, pp. 383–392.[40] M. P. Robillard, E. Bodden, D. Kawrykow, M. Mezini, and T. Ratchford,“Automated API property inference techniques,”
IEEE Trans. SoftwareEng. , vol. 39, no. 5, pp. 613–637, 2013.[41] H. Zhong and H. Mei, “An empirical study on api usages,”
IEEETransactions on Software Engineering , 2017.[42] Z. Li and Y. Zhou, “Pr-miner: automatically extracting implicit program-ming rules and detecting violations in large software code,” in
ACMSIGSOFT Software Engineering Notes , vol. 30, no. 5. ACM, 2005, pp.306–315.[43] E. Moritz, M. Linares-Vásquez, D. Poshyvanyk, M. Grechanik,C. McMillan, and M. Gethers, “Export: Detecting and visualizing apiusages in large source code repositories,” in .IEEE, 2013, pp. 646–651.[44] M. A. Saied, O. Benomar, H. Abdeen, and H. Sahraoui, “Mining multi-level api usage patterns,” in . IEEE,2015, pp. 23–32.[45] M. A. Saied, H. Abdeen, O. Benomar, and H. Sahraoui, “Could we inferunordered api usage patterns only using the library source code?” in .IEEE, 2015, pp. 71–81.[46] A. T. Nguyen, M. Hilton, M. Codoban, H. A. Nguyen, L. Mast,E. Rademacher, T. N. Nguyen, and D. Dig, “Api code recommendationusing statistical learning from fine-grained changes,” in
Proceedings ofthe 2016 24th ACM SIGSOFT International Symposium on Foundationsof Software Engineering . ACM, 2016, pp. 511–522.[47] R. Xie, X. Kong, L. Wang, Y. Zhou, and B. Li, “Hirec: Api recom-mendation using hierarchical context,” in . IEEE, 2019,pp. 369–379.[48] H. Niu, I. Keivanloo, and Y. Zou, “Api usage pattern recommendationfor software development,”
Journal of Systems and Software , vol. 129,pp. 127–139, 2017.[49] P. T. Nguyen, J. Di Rocco, D. Di Ruscio, L. Ochoa, T. Degueule,and M. Di Penta, “Focus: A recommender system for mining apifunction calls and usage patterns,” in . IEEE, 2019, pp. 1050–1060.[50] C. Liu, E. Ye, and D. J. Richardson, “Ltrules: an automated softwarelibrary usage rule extraction tool,” in
Proceedings of the 28th interna-tional conference on Software engineering , 2006, pp. 823–826.[51] C. Zhang, J. Yang, Y. Zhang, J. Fan, X. Zhang, J. Zhao, and P. Ou,“Automatic parameter recommendation for practical api usage,” in
Pro-ceedings of the 34th International Conference on Software Engineering .IEEE Press, 2012, pp. 826–836. [52] J. Wang, Y. Dang, H. Zhang, K. Chen, T. Xie, and D. Zhang, “Miningsuccinct and high-coverage api usage patterns from source code,” in .IEEE, 2013, pp. 319–328.[53] M. Asaduzzaman, C. K. Roy, K. A. Schneider, and D. Hou, “CSCC:Simple, efficient, context sensitive code completion,” in . IEEE,2014, pp. 71–80.[54] H. A. Nguyen, T. T. Nguyen, G. Wilson Jr, A. T. Nguyen, M. Kim, andT. N. Nguyen, “A graph-based approach to api usage adaptation,”
ACMSigplan Notices , vol. 45, no. 10, pp. 302–321, 2010.[55] A. T. Nguyen, H. A. Nguyen, T. T. Nguyen, and T. N. Nguyen, “Grapacc:a graph-based pattern-oriented, context-sensitive code completion tool,”in .IEEE, 2012, pp. 1407–1410.[56] M. Ghafari and A. Heydarnoori, “Towards a visualized code recommen-dation for apis enriched with specification mining,” in
Proceedings of the4th International Workshop on Recommendation Systems for SoftwareEngineering , 2014, pp. 26–27.[57] M. Asaduzzaman, C. K. Roy, K. A. Schneider, and D. Hou, “Recom-mending framework extension examples,” in . IEEE,2017, pp. 456–466.[58] ——, “Femir: A tool for recommending framework extension exam-ples,” in . IEEE, 2017, pp. 967–972.[59] Y. Pacheco, J. De Bleser, T. Molderez, D. Di Nucci, W. De Meuter, andC. De Roover, “Mining scala framework extensions for recommendationpatterns,” in2019 IEEE 26th International Conference on SoftwareAnalysis, Evolution and Reengineering (SANER)