Analysing Program Dependencies in Java EE Applications

1. Analyzing Program Dependencies
in Java EE Applications
Anas Shatnawi, Hafedh Mili, Ghizlane El Boussaidi, Anis Boubaker,
Yann-Gael Gueheneuc, Naouel Moha, Jean Privat and Manel Abdellatif
LATECE Laboratory, University of Quebec at Montreal
MSR 2017
Buenos Aires

2. Static Dependency Call Graph
• Highlighting different dependencies between the
program elements
• It supports:
• Software mining
• Maintenance
• Understandability
• Feature location
• Etc.
Dependencies
Elements

3. Difficulties in Analyzing JEE Applications

4. Java code implementation space
The PrevFormTag handlertaglib descriptor
Descriptor file space
A use of prevForm tag
JSP implementation space
describes
maps
Multilanguage code
and string literals
XMLJSP
Java

5. Our Goal
• Build a dependency call graph that includes all dependencies that exist
between program elements, despite the different languages, technologies,
and development environment mechanisms

6. The main idea
Limiting the analysis to Java program artifacts
leaves a disconnected program dependency graph
Data-driven control dependencies
Codification of container services
A codification of the other kinds of dependencies helps
us connect the different parts of the dependency graph

7. Underlying challenges to be solved
1. The various JEE technologies confirm to different meta-models
2. The container 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 need to look in different files to interpret dependencies

8. Our Approach
• The OMG’s Knowledge Discovery Meta-model (KDM)
‒ A language-independent meta-model
‒ Use one common model that represents all program elements and their related
dependencies
‒ Abstract away differences between different JEE technologies
• We developed a number of tools
‒ Transform the multi-language code to KDM
‒ Codify container service dependencies
‒ Parse configuration files
‒ Parse string literals to identify dependencies

9. Codifying container services dependencies
• JEE servers offer a number of services to contain JEE components
• Some are out of the box (e.g., RMI, lifecycle management)
• Some are configurable (security, transaction, persistence)
• Configuration parameters found different places
• Deployment descriptors and code annotations
• Knowledge of these services helps connect some of the missing links
JEE Container
JSPs
Servlets
Tag
Handler
EJBs
JSFs
Managed
Beans

10. Life Cycle Management
• Knowledge of life cycle management helps connect some of the missing
links

11. Dependencies of Life Cycle Management
setAction(“cart”)
doEndTag()
doStartTag()

12. Tool implementation
• We developed DeJEE (Dependencies in JEE) tool as an Eclipse plug-in
• DeJEE supports the representation of multi-language code of JEE
technologies in one common KDM model
• Based on this common KDM model, we extract a dependency call graph.

13. Case studies
• Subject applications
‒ Java PetStore (8 HTMLs, 88 JSPs, 233 Java classes)
‒ JspBlog (1 HTML, 11 JSPs)
• Method:
1. The ability of DeJEE to codify problems underlying dependencies in JEE applications
2. How much DeJEE extends MoDisco (recall improvement)
‒ We have executed both MoDisco and DeJEE and noted the differences between each tool's
results

14. The Capability to Identify Dependencies
Java PetStore JSP Blog
Multilanguage files 45.4% of JSPs 54.5% of JSPs
Total no. of string literals 1541 204
No. of string literals having
dep.
720 65
No. of KDM entities 329 11
No. of KDM relationships 2673 61

15. Recall Improvement

16. Related work
• Many approaches were proposed to analyze program dependencies in JEE
applications with different purposes.
• Most of these approaches focus on a subset of JEE technologies that is
part of a tier. For examples,
‒ Naumovich and Centonze analyzed EJBs and JEE access policies
‒ Kirkegaard and Moller focused on the analysis of Java Servlets
‒ Zaidman supports the understanding of Ajax-based web applications
• While each one of these technologies present significant analysis
challenges, in their own right, none of the approaches attempt an
integrated view of the technologies.

17. Conclusion
• Static code analysis gets more complicated when dealing with multi-language
systems such as JEE applications
• We identified the major difficulties in analyzing dependencies across key JEE
technologies, and presented our strategies for addressing them
• We developed a tool called DeJEE that implements our solutions
• Results showed that DeJEE solves the challenges that we identified in the
static analysis of JEE applications and detects related dependencies

18. Future directions
• Generalization from JEE applications to multi-language applications
• The application of the resulting dependency call graph
‒ Migration to SOA
‒ Change impact analysis
• Scalability of DeJEE by experimenting with large number of case studies
• Accuracy of DeJEE by by comparing its call-graphs against call-graphs
obtained from runtime execution.

19. Thank you
anasshatnawi@gmail.com

20. Codifying container services dependencies
• JEE servers offer a number of services to contain JEE components (JSPs,
Servelets, EJBs, Tag Handlers, etc.)
‒ Some are out of the box
• E.g. RMI, lifecycle management
‒ Some are configurable
• Security, transaction, persistence
‒ Configuration parameters found different places
• Deployment descriptors
• Code annotations
• Knowledge of these services helps connect some of the missing links

21. Callback Methods
• Dependencies (calls) that are invisible in user code
JEE Container
JSPs
Servlets
Tag
Handler
EJBs
JSFs
Managed
Beans