94計(jì)算機(jī)專業(yè)相關(guān)有關(guān)外文文獻(xiàn)翻譯成品分析java ee應(yīng)用程序中的程序依賴性

1、<p>　　此文檔是畢業(yè)設(shè)計(jì)外文翻譯成品（ 含英文原文+中文翻譯），無需調(diào)整復(fù)雜的格式！下載之后直接可用，方便快捷！本文價(jià)格不貴,也就幾十塊錢！</p><p>　　外文標(biāo)題：Analyzing Program Dependencies in Java EE Applications</p><p>　　外文作者：Anas Shatnawi, Hafedh Mili, Ghizl

2、ane El Boussaidi, Anis Boubaker, Yann-Gaël Guéhéneuc, Naouel Moha, Jean Privat, Manel Abdellatif</p><p>　　文獻(xiàn)出處:2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR)

3、</p><p>　　英文3890單詞，22598字符，中文6405漢字。</p><p>　　Analyzing Program Dependencies in Java EE Applications</p><p>　　Anas Shatnawi, Hafedh Mili, Ghizlane El Boussaidi, Anis Boubaker, Yann-

4、Gaël Guéhéneuc, Naouel Moha, Jean Privat, Manel Abdellatif</p><p>　　Abstract—Program dependency artifacts such as call graphs help support a number of software engineering tasks such as softwa

5、re mining, program understanding, debugging, feature location, software maintenance and evolution. Java Enterprise Edition (JEE) applications represent a significant part of the recent legacy applications, and we are int

6、erested in modernizing them. This modernization involves, among other things, analyzing dependencies between their various components/tiers. JEE application</p><p>　　Index Terms—program dependency, code anal

7、ysis, Java EE application, modernization, container services, server pages.</p><p>　　I.INTRODUCTION</p><p>　　Program dependency artifacts such as call graphs help support a number of software en

8、gineering tasks such as software mining, program understanding, debugging, feature location, maintenance and evolution. Since the early 2000’s, most new enterprise applications were developed using dis- tributed objects,

9、 with Java technologies taking the lead. The early generation of JEE (Java Enterprise Edition) applications suffered from many ills due to a combination of, 1) the inherent limitations of the tec</p><p>　　Ho

10、wever, JEE applications present a number of character- istics that make analysis difficult:</p><p>　　they tend to be distributed and multi-tiered –as opposed to monolithic applications– which makes tracing c

11、alls across tiers more difficult;</p><p>　　a number of (calls) dependencies are implicit in frameworks and services offered by JEE servers/containers: they are not ‘visible’ in the user code;</p><

12、p>　　they tend to make extensive use of late binding tech- niques, including language-specific features (e.g. reflex- ion package) and coding and design idioms/tricks;</p><p>　　a number of dependencies wil

13、l be recorded in configuration files that have ad-hoc syntax, and whose semantics are fully embodied in the tools that consume them; and they usually embed portions of code written in other programming/data presentation

14、languages other than Java.</p><p>　　All of these considerations mean that to get a complete representation of relationships between program elements, we need to augment the traditional unilingual program sta

15、tic analysis techniques with other kinds of analyses, involving other kinds of artifacts, but also, possibly, involving the codification of services offered by containers/application servers. Figure 1 illustrates this.&l

16、t;/p><p>　　Many approaches were proposed in the literature to analyze program dependencies in JEE applications with different purposes. Most of these approaches focus on a subset of JEE technologies that is par

17、t of a tier. For examples, Naumovich and Centonze analyzed EJBs and JEE access policies [3], Kirkegaard and Moller focused on the analysis of Java Servlets [4], and Zaidman supports the understanding of Ajax-based web ap

18、plications [6]. While each one of these technologies present significant analysis</p><p>　　In this paper, we look at some of the challenges posed by JEE characteristics to build a dependency call graph, and

19、 illustrate with some details the problems and solutions of uncovering invocation relationships between server pages (Servlets, JSPs and JSFs). We also give some insights on our envisioned approach to discover dependenci

20、es related to container services such as RMI, life-cycle management, and persistence. We rely on the OMG’s Knowledge Discovery Meta-model (KDM) [2] to represent dif</p><p>　　Fig. 1. Java code analyses have t

21、o be complemented with the analysis of, 1) other program artifacts, and 2) services offered by the run-time infrastructure</p><p>　　The rest of this paper is organized as follows. We first provide a short ov

22、erview of the anatomy of a JEE applica- tion (Section II). In Section III, we identify the underlying problems at analyzing dependencies in JEE applications and propose our solutions. We discuss the implementation and so

23、me preliminary results of DeJEE tool on two case studies in Section IV. Section V provides a discussion about some important issues related to the proposed approach. Next, we explore related work in Sectio</p><

24、;p>　　II.THE ANATOMY OF JEE APPLICATIONS</p><p>　　A.Overview of JEE applications</p><p>　　JEE applications are managed, developed and deployed based on a multi-tier distributed model. In this

25、context, the application logic of a JEE application is decomposed into a set of components distributed among different tiers based on their functionalities. Fig. 2 shows an example of two JEE applications that are split

26、into four tiers: client, web, business logic and data tiers. The client tier can be client applications that access business logic functionalities running on server-side machines</p><p>　　Fig. 2. Architectur

27、e of multi-tiered JEE applications</p><p>　　B.Server pages in JEE applications: Servlets, JSPs, and JSFs In web tier layer, server pages allow to extend web application capabilities to offer clients function

28、alities through HTTP requests. Server pages can be implemented based on three JEE technologies: Servlets, JSPs, and JSFs. Servlets represent the traditional implementation of server pages and are implemented using normal

29、 object-oriented Java code (see javax.Servlet and javax.Servlet.http packages in Java APIs), while the presentation o</p><p>　　JSPs (JavaServer Pages) and JSFs (JavaServer Faces) are built on the top of Java

30、 Servlets and are used for developing dynamic server-side pages based on scripting languages(based on XML). They can contain a mix of static content (XML/HTML tags) and dynamic content (like dynamic JSP tags). They provi

31、de reusable components via tag libraries (taglibs). In addition, developers are allowed to include normal Java code fragments and to invoke external Java components such as JavaBeans and Managed Beans</p><p>

32、;　　III.ANALYZING DEPENDENCIES IN JEE APPLICATIONS We identified several problems during the analysis of our two case studies. These are: 1) the various JEE technologies conform to different (exogenous) meta-models; 2) th

33、e con- tainer services’ related dependencies are implicit; 3) the use of multi-language code in single source files; 4) the embedding of dependencies in string literals; 5) the different mechanisms to codify dependencies

34、; and 6) the need to look in different files to interpret depen</p><p>　　A.Problem with the variety of meta-models</p><p>　　1)Problem: Different JEE technologies were designed for different obje

35、ctives. Therefore, they follow different meta- models that have various structures based on the inventors’ point of views about what it is the right lexical, syntax and semantics. As servlets are implemented using Java c

36、ode, they follow an object-oriented meta-model where their program elements are associated to classes, methods and attributes, and their program dependencies are mainly based on method invocations, attribute ac</p>

37、<p>　　Solution: To solve the problem of the variety of meta- models, we select to use an intermediate language-independent meta-model. Such a meta-model should be able to offer a common interchange format that uni

38、fies all of JEE technolo- gies with respect to their program elements and relationships as well. Among existing language-independent meta-models (such as KDM [2], FAMIX [7] and Abstract Syntax Tree), we selected KDM (Kno

39、wledge Discovery Meta-model), an Object Management Group (OMG) standard f</p><p>　　For KDM tool support, we considered two of the most mature tools: MoDisco [8] and KDM Analytics [9]. However, MoDisco is the

40、 only one that offers open-source implementation that can be extended to understand JEE dependencies.Therefore, we used MoDisco as an underlying tool to extract and to manipulate KDM models.</p><p>　　However

41、, MoDisco suffers from two limitations. First, the current version only supports the construction of KDM models from to object-oriented languages like Java and C++. Although it does permit the analysis of non-object orie

42、nted languages, such as JSP, JSF or HTML, the concepts are extracted follow- ing an alternate (i.e. non-KDM) meta-model. Each concept is represented in terms of string literals. These string literals need to be analyzed

43、for mining dependencies within and across the JSP and</p><p>　　The second problem with MoDisco is that configuration files are statically represented as XML-based models without interpreting their content wi

44、th respect to the other software artifacts. As a result, the KDM model produced by MoDisco does not take into account any of the JEE framework specifics. To address these issues, we developed a specific processor to pars

45、e JSPs, JSFs and HTML, in order to represent them (and their dependencies) by complementing MoDisco’s KDM model. We define JSPs, JSFs an</p><p>　　2)Solution: We use a common representation model (KDM model)

46、that abstracts away language and paradigm differences. We develop an analyzer that is able to detect multi-language code usage in a given source file. It identifies pieces of code related to different JEE technologies. T

47、hen, it parses each piece of code based on its technology to identify program elements and dependencies, and represent them in the central KDM model. We also consider detecting dependencies be- tween program elements be&

48、lt;/p><p>　　D.Dependencies embedded in string literals</p><p>　　1)Problem: String literals are frequently used in JEE ap- plications for several purposes such as codifying dependencies and encapsul

49、ating parameters.</p><p>　　a)Codifying dependencies: In Servlets, JSPs and JSFs,string literals are used to refer to relative-URLs that are related to other server pages. Listing 1 shows an example of a Serv

50、let that use string literals that embed a dependency for a relative-URL. String literals are also used to refer to the usage (reference) of JavaBeans and/or Managed Beans components, and to determine which members (attri

51、butes or methods) are accessed in the Beans. Listing 3 shows an example of JSF code that use string </p><p>　　b)Encapsulating parameters: String literals are utilized to encapsulate parameters in requests ba

52、sed on an id:value pattern. In Listing 4, the server page firstly reads three parameters from the sender through the request object, does its thing, and then attaches another parameter to the request. This works as long

53、as both the sender and the receiver agree on parameter ids (i.e. gradeX and average in our example). Thus, we need to verify the compatibility of the string literals used by the sende</p><p>　　2)Solution: We

54、 studied Oracle’s JEE specification to iden- tify where string literals could be used to codify dependencies. For JSPs and JSFs, we made a list of tags and their attributes that are related to program dependencies to ser

55、ver pages and Bean components. For example, that list includes the action attribute of the form tag, since its value corresponds to a relative-URL corresponding to a server page. For Servlets, we develop a lexical analyz

56、er that is able to process the string literals</p><p>　　VII.CONCLUSION AND FUTURE WORK</p><p>　　A.Conclusion</p><p>　　Program dependency artifacts such as call graph supports a numb

57、er of key software engineering tasks including software mining, program understanding, debugging, feature location, maintenance and evolution. Static code analysis can be quite challenging when dealing with single-langua

58、ge monolithic applications–depending on the language (e.g. typed or not) and the task at hand (e.g. understanding versus data flow analysis). Things get far more complicated when dealing with multi-language systems su<

59、;/p><p>　　To implement our solution, we developed a tool called DeJEE (Dependencies in JEE) as an Eclipse plug-in. We reused the KDM APIs offered by MoDisco. We applied DeJEE on two open-source JEE applications

60、. The results show that DeJEE is able to detect different type of dependencies that MoDicso does not. Also, DeJEE detects dependencies toward program elements that do not exist in the application implementation.</p>

61、;<p>　　B.Future Work</p><p>　　We are extending our work in four research directions. These are:</p><p>　　1)Generalization from JEE applications to multi-language applications: The problem

62、s encountered with JEE applica- tions are common to modern legacies which also tend to be multi-language, and also rely on various frameworks, middle- wares, and container services, which relieve application developers f

63、rom the complexities of the run-time environment, but also obfuscate dependencies that would otherwise help explain functional dependencies and run-time behavior. The principles underlying our solut</p><p>　

64、　2)The application of the resulting dependency call graph: Thanks to the thoroughness and precision of the dependencies that we are uncovering, we are exploring other uses for the program dependency graphs that we are bu

65、ilding, including:</p><p>　　1) help with program understanding tasks2) change impact analysis, and performance engineering–thanks, in part, to the codification of container services.</p><p>　　Ex

66、tending DeJEE tool to include all dependencies in JEE applications: The current implementation of DeJEE tool does not support the codification of dependencies related to container services. We are currently working on th

67、at. More- over, JEE allow developers to use other programming languages inside the implementation of JEE applications such as JavaScript code. DeJEE does not cover dependencies existing in these other languages and we pl

68、an to consider them in our future work.</p><p>　　4)Experimenting with large number of case studies: To generalize the results of our approach for other JEE appli- cations, we need to evaluate it with a large

69、 number of JEE applications. Different JEE applications can be implemented using different sets of JEE technologies following different design patterns by developers with various knowledge and experience levels. Therefor

70、e, we want to collect a large set of JEE applications as case studies developed for various purposes by different develope</p><p>　　5)The evaluation of our approach by human experts: We demonstrated the appl

71、icability of our approach through the most common ways that developers used for developing JEE applications (Java PetStore that represents the official demon- stration offered by Oracle and several representative example

72、s taken form the JEE specification offered by Oracle). However, the resulting dependency call graph should be validated using external human experts. Therefore, we plan to validate our results using the he</p><

73、;p>　　REFERENCES</p><p>　　[1] Bill Dudney, Stephen Asbury, Jospeh K. Krozak, and Kevin Wittkopf. J2EE Antipatterns. Wiley, 2003.10</p><p>　　[2] Ricardo Pérez-Castillo, Ignacio Garcia-Rodr

74、iguez De Guzman, and Mario Piattini, "Knowledge Discovery Metamodel-ISO/IEC 19506: A standard to modernize legacy systems," Computer Standards & Interfaces, 33(6):519–532, 2011.</p><p>　　[3] Gl

75、eb Naumovich and Paolina Centonze, "Static analysis of role-based access control in j2ee applications," ACM SIGSOFT Software Engineering Notes, 29(5):1–10, 2004.</p><p>　　[4] Christian Kirkegaard a

76、nd Anders Møller, "Static analysis for java Servlets and jsp," In International Static Analysis Symposium, pages 336–352. Springer, 2006.</p><p>　　[5] Jonathan Cloutier, Sy`gla Kpodjedo, and G

77、hizlane El Boussaidi, "Wavi:A reverse engineering tool for web applications," In IEEE 24th International Conference on Program Comprehension (ICPC), pages 1–3.IEEE, 2016.</p><p>　　[6] Andy Zaidman,

78、 Nick Matthijssen, Margaret-Anne Storey, and Arie Van Deursen, "Understanding ajax applications by connecting client and server-side execution traces," Empirical Software Engineering, 18(2):181–218, 2013.</p

79、><p>　　[7] Tichelaar Sander, Stéphane Ducasse and Serge Demeyer, "FAMIX: Exchange experiences with CDIF and XMI," In Proceedings of the ICSE 2000 Workshop on Standard Exchange Format (WoSEF 2000)

80、, 2000.</p><p>　　[8] Bruneliere, Hugo, Jordi Cabot, Grégoire Dupé and Frédéric Madiot, "Modisco: A model driven reverse engineering framework," Information and Software Technolo

81、gy, 56 (8):1012–1032, 2014.</p><p>　　[9] KDM Analytics, ww.kdmanalytics.com, visited in 2016.</p><p>　　[10] A. von Mayrhauser. "Program comprehension during software maintenance and evoluti

82、on," In IEEE Computer, 28(8):44–55, 1995.</p><p>　　[11] H. M. Kienle and H. A. Mllër. "Rigi–an environment for software reverse engineering, exploration, visualization, and redocumentation&quo

83、t;. In Science of Computer Programming, 75(4):247–263, 2012.</p><p>　　[12] D. L. Moise and K. Wong. "Extracting and representing cross-language dependencies in diverse software systems," In Proceed

84、ings of the 12th Working Conference on Reverse Engineering. IEEE Computer Society Press, November 2005.</p><p>　　[13] L. Deruelle, N. Melab, M. Bouneffa, and H. Basson. "Analysis and manipulation of dis

85、tributed multi-language software code," In Proceedings of the 1st International Workshop on Source Code Analysis and Manipulation, pages 45–56. IEEE Computer Society Press, November 2001.</p><p>　　[14]

86、P. K. Linos, Z. hong Chen, S. Berrier, and B. O’Rourke. "A tool for understanding multi-language program dependencies," In Proceedings of the 11th International Workshop on Program Comprehension, pages 64–72. I

87、EEE Computer Society Press, May 2003.</p><p>　　[15] N. A. Kraft, B. W. Bonds, and R. K. Smith. "Cross-language clone detection," In Proceedings of the 20th International Conference on Software Engi

88、neering and Knowledge Engineering., pages 54–59. Knowledge Systems Institute, July 2008.</p><p>　　[16] D. M. German and A. E. Hassan. "License integration patterns: Addressing license mismatches in comp

89、onent-based development," In Proceedings of the 31st International Conference on Software Engineering, pages 188–198. ACM Press, May 2009.</p><p>　　[17] Philip Mayer and Andreas Schroeder, "Automat

90、ed multi-language artifact binding and rename refactoring between java and dsls used by java frameworks," In European Conference on Object-Oriented Pro- gramming, pages 437–462. Springer, 2014.</p><p>　

91、　[18] A. Ayers, R. Schooler, C. Metcalf, A. Agarwal, J. Rhee, and E. Witchel."Traceback: first fault diagnosis by reconstruction of distributed control flow," In Proceedings of the 26th conference on Programmin

92、g language design and implementation. pages 201–212. ACM Press, June 2005.</p><p>　　[19] A. R. Yazdanshenas and L. Moonen. "Crossing the boundaries while analyzing heterogeneous component-based software

93、 systems," In Proceedings of the 27th International Conference on Software Maintenance,pages 193–202. IEEE CS Press, September 2011.</p><p>　　[20]Sun MicroSystems, Java Pet Store, http://www.oracle.com/

94、technetwork/ java/petstore1-3-1-02-139690.html, last access: Feb. 8th 2017.</p><p>　　[21] JSP Blog, http://jspblog.sourceforge.net, last access: Feb. 8th 2017.</p><p>　　[22] Object Management Gr

95、oup, "Architecture-Driven Modernization: Knowledge Discovery Meta-Model (KDM), v. 1.3".</p><p><b>　　譯文：</b></p><p>　　分析Java EE應(yīng)用程序中的程序依賴性</p><p>　　Anas Shatnaw

96、i, Hafedh Mili, Ghizlane El Boussaidi, Anis Boubaker, Yann-Gaël Guéhéneuc, Naouel Moha, Jean Privat, Manel Abdellatif</p><p>　　摘要：程序依賴項(xiàng)工件（如調(diào)用圖）有助于支持許多軟件工程任務(wù)，如軟件挖掘，程序理解，調(diào)試，功能定位，軟件維護(hù)和演變。 Java En

97、terprise Edition（JEE）應(yīng)用程序代表了最近遺留應(yīng)用程序的重要部分，我們對(duì)它們的現(xiàn)代化感興趣。除其他外，這種現(xiàn)代化涉及分析其各個(gè)組件/層之間的依賴關(guān)系。 JEE應(yīng)用程序往往是多語言，依賴于JEE容器服務(wù)，并廣泛使用后期綁定技術(shù) - 所有這些都使得發(fā)現(xiàn)這種依賴性變得困難。在本文中，我們描述了其中的一些困難，以及我們?nèi)绾谓鉀Q它們以構(gòu)建依賴調(diào)用圖。我們開發(fā)了一個(gè)名為DeJEE（JEE中的Dependencies）的工具作為Ec

98、lipse插件。我們?cè)趦蓚€(gè)開源JEE應(yīng)用程序上應(yīng)用了DeJEE：Java PetStore和JSP Blog。結(jié)果表明DeJEE能夠識(shí)別不同類型的JEE依賴關(guān)系。</p><p>　　索引術(shù)語--程序依賴性，代碼分析，Java EE應(yīng)用程序，現(xiàn)代化，容器服務(wù)，服務(wù)器頁面。</p><p><b>　　引言</b></p><p>　　程序依賴性

99、工件（如調(diào)用圖）有助于支持許多軟件工程任務(wù)，如軟件挖掘，程序理解，調(diào)試，功能定位，維護(hù)和演變。自2000年初以來，大多數(shù)新的企業(yè)應(yīng)用程序都是使用分布式對(duì)象開發(fā)的，Java技術(shù)占據(jù)了主導(dǎo)地位。早期的JEE（Java企業(yè)版）應(yīng)用程序由于以下原因而遭受許多弊端：1）技術(shù)的固有局限性; 2）其功能的不正確使用（參見例如EJB反模式[1]）。 JEE應(yīng)用程序代表了最近遺留應(yīng)用程序的重要部分。我們感興趣的是分析這些應(yīng)用程序以支持它們的現(xiàn)代化，包括將