Master in Systems and Computer Science Universidad Nacional de Colombia - UNAL © 2009 Authors. All Rights Reserved.

Research paper (draft)

Refactoring oriented software architecture to detection of J2EE design patterns. Víctor E. Collazos Serrano

ABSTRACT The object model is the key that is maintained for any architecture supported by object-oriented technology. This architecture is usually based on implementations of design patterns, which are aimed at solving architecture that take place during the stages of analysis and implementation of a project. At the corporate level, one of the most technology implementations and their benefits because the architecture is called J2EE, which implements each of its layers a series of design patterns that solve a specific problem. Since this is very common in a reengineering process for this platform that raises the need to detect design patterns currently implemented in a solution of this technology, to make a diagnosis of current architecture and propose specialists from a solution objective for the optimization of the architecture itself. Our approach is based on the analysis and dynamic level of the source code of an implementation based on J2EE technology, which allows the detection of different patterns that use each of the layers constituting the architecture, as well as describe how it is implemented a prototype that allows the detection of these patterns illustrating the user about the current state in which is the design of the solution.

1. INTRODUCTION Refactoring is the most common term that refers to time have a choice in the reengineering process optimization and improvement of software. This term is commonly recognized as the route to improve the internal structure of an object-oriented software while at the same time retains its external behavior. Since in his book on the subject Fowler [1], reveals a series of programming and design patterns to simplify the task of refactoring, there have been various proposals and new thoughts for optimize software by this paradigm. Parallel and constantly develop new types of refactoring and areas in various approaches to solve new problems that are involved in the construction and evolution of software. Bearing in mind that J2EE or Java 2 Platform, Enterprise Edition (now known as Java Platform, Enterprise Edition or JEE since version 1.4) is a programming platform to develop and run software applications in Java programming language with distributed architecture of N levels, based largely on modular software components and runs on an application server, is one of the platforms implemented at the corporate level and is therefore almost inevitable that a process of evolution in an implementation of this architecture is necessary to use the refactoring as a mechanism for optimizing the solution.

Categories and Subject Descriptor D.2 [Software Engineering] D.2.11 [Software Architecture] I.5 [Pattern Recognition]

General Terms Refactoring, design patterns, J2EE.

Keywords Refactoring, pattern-based refactoring, J2EE design patterns, refactoring techniques, static and dynamic tools for detecting patterns.

Víctor Edwin Collazos Serrano Maestría en Sistemas ciencias de la computación Departamento de Ingeniería de Sistemas e Industrial, Universidad Nacional de Colombia, Sede Bogotá E-mail: [email protected] Cel.: 311-2348381

It's a good idea to consider a process of refactoring detection patterns as a solution to give a real diagnosis of the current state of its architectural design. This paper presents an approach to detect patterns of a J2EE architecture using static structure supported by the source and its dynamic behavior to detect patterns that are implemented in each of its architectural layers as displayed in Figure 1. The current document presents the following structure, In section 2 presents the conceptual and technical approach that is based on investigative work, section 3 describes the process and techniques used for detecting patterns in section 4 presents the prototype developed for detecting patterns J2ee, in section 5 we present the findings throughout the research process and Chapter 6 presents the references used to support this research.

2. APPROACH The J2EE design patterns have their own intention and describe roles and responsibilities for each separate layer to which they

belong. In the source, each function is commonly represented by a class and responsibilities are codified in those classes with attributes and methods. The guidelines also describe the collaboration between objects at runtime. In this paper we use the functions, responsibilities and collaboration applications to analyze information to detection of J2EE design patterns and then categorize the results. Understand the structure and intent of the software system will give developers a quick overview of the entire system without going into detail about the source code.

Figure 2. The process of identifying J2EE patterns

3.1 Recognition of the structural model This recognition is based on gathering information from classes and uses of the methods, attributes and their parameters, in this way to define roles, responsibilities and relationships between clases and interfaces of the system.

Figure 1. General taxonomy of the J2EE Architecture

To carry out this process which captures the model of an application using the format RSF (Rigi Standard Format) [11], which is the format that reflects the relations between inheritance and interfaces that define the structure again once done parsing the source code to extract the facts that compose it.

2.2 Case Study ToDo: Choose a case study applied to the process of detection a particular design pattern in J2EE technology.

3. RECOVERING PATTERNS For the detection of patterns is necessary to take account not only the analysis performed at the files that make up the source code of a J2EE application to address the detection of patterns and structural composition of the classes and their relationships with each other, but also a dynamic analysis for the behavioral patterns at to make a more precise recognition of different patterns that implement it in certain layers.

Figure 3. Viewing events in Rigi Standard Format

Once the facts that form the model is implemented language QL [12], which is a re-implementation of GROK [13] to generate a script that displays the facts extracted from the bodies to form a candidate pattern. In Figure 4 presents a script QL in which the first line displays the roles that make

up a pattern (this example case the Adapter pattern) and the second line of possible classes that make up this pattern.

3.2 Recognition of the dynamic behavior For this analysis is necessary to extract and collect facts that make up the model and result in the detection of patterns J2ee not structural, but as noted earlier behavioral level, in other words when the application is in memory at runtime.

Figure 4. QL Script after manipulation of the facts base.

The dynamic analysis is based on the transformation behavior in the aspect of a design pattern provided by diagram sequence UML, which consists of vertical lines that represent the objects at runtime and arrows that relate to it represents the messages that are shared by their corresponding methods. The dynamic analysis is used to calculate the probability that a particular pattern is in the source.

To extract the facts of the source code that makes up the application using the extractor Javex facts [14], which allows to extract such information from all entities of java code. These entities are defined as the application directories, source files, classes and interfaces, methods, variables and parameters, so each entity is registered for Javex all the links on this source. Once the facts is a detail of the same granularity and is used GROK, which is a programming language that manipulates binary relations, this tool operates at the level of relational database, and directly in the relations of entities and not just among themselves, it operates more efficiently in the relationship and keeps thousands of events throughout the structure of their data in memory.

Figure 6. Example of UML sequence diagram

The dynamic definition used to detect patterns J2ee is the number of method calls and the temp restrictions that apply to these calls. These constraints define the order in which the method call should happen. The restrictions provide another type of dynamic conditions, grouped in the following categories:

Figure 3. Lifting facts to class level whit Grok

The script that lists the events generated at the level of classes can be expressed as follows:

• Restricting Roles • Restricting methods • Temporary Restrictions • Constraints objects • Ranking

ToDo: Description in detail of Probekit [15] used for the detection of dynamic patterns in the different layers of a J2EE platform.

3.3 Pattern Validation ToDo: Selection and description of the validation process based on metrics for detecting a particular pattern in J2EE.

4

PROTOTYPE FOR DETECTING PATTERNS (ECLIPSE PLUG-IN)

ToDo: Description of the prototype implemented for the detection of J2EE patterns.

5

CONCLUSIONS.

Information collected in this paper visualizes the process, techniques and methodology used to perform a detection process of J2EE patterns to support the process of refactoring at an abstract architecture of this technology. The most important thing is that there is planted the seed for future research based on reengineering in order to optimize the software, allowing applications to be more scalable and flexible without this demand a large amount of labor and economic efforts. ToDo: Description of the conclutions after the research work.

6

REFERENCES

[1] M. Fowler. Refactoring (Improving the Design of Existing Code). Addison Wesley, 1999. Proc. of the 6th Workshop Software Reengineering, Bad Honnef, Germany, Softwaretechnik-Trends, volume 24/2, pages 63–64, May 2004. [2] Birkner marcel, Objected-oriented design pattern detection using static and dynamic analysis in java software,Magister Thesis, university of applied sciences bonn-rhein-sieg sankt augustin, Germany, august 2007 [3] Jörg Niere , Wilhelm Schäfer , Jörg P. Wadsack , Lothar Wendehals , Jim Welsh, Towards pattern-based design recovery, Proceedings of the 24th International Conference on Software Engineering, May 19-25, 2002, Orlando, Florida http://doi.acm.org/10.1145/581339.581382 [4] L. Wendehals. Improving design pattern instance recognition by dynamic analysis. In Proc. Of the ICSE 2003 Workshop on Dynamic Analysis (WODA), Portland, USA, May 2003. [5] Naouel Moha. Detection and Correction of Design Defects in Object-Oriented Designs. Doctoral Symposium, 21st International Conference on Object-Oriented Programming, Systems, Languages and Applications, October 2007. [6] Sang-Uk Jeon, Joon-Sang Lee, Doo-Hwan Bae: An Automated Refactoring Approach to Design Pattern-Based Program Transformations in Java Programs. APSEC 2002: 337. [7] D.Janaki Ram, J.Rajesh, Detecting Intent Aspects from Code to Apply Design Patterns in Refactoring: An Approach

Towards a Refactoring Tool, SODA’03, January, 2004, Bangalore, India. Copyright 2003 DOSLab, IIT Madras. [8] [20] Garlan, D.,Kompanek, A., Melton R., and Monroe R.: Architectural Style: An Object-Oriented Approach, February, 1996. [9] Maurice Lebon. A fine-grained model for design pattern detection in eiffel systems. Master’s thesis, York University, Toronto, Ontario, Canada,2006. [10] Joerg Niere, Wilhelm Schaefer, Joerg P. Wadsack, Lothar Wendehals, and Jim Welsh. Towards pattern-based design recovery. Technical Report tr-ri-01-227, University of Paderborn, Paderborn, Germany, October 2001. [11] Rigi Standard Format (RSF) //www.rigi.csc.uvic.ca/ [12] QL http://swag.uwaterloo.ca/~nsynytskyy/grokdoc/operators. [13] Gork http://swag.uwaterloo.ca/~nsynytskyy/grokdoc/index.html. [14] Javex http://www.swag.uwaterloo.ca/javex/index.html. [15] Probekit http://www.eclipse.org/tptp/platform/documents/probekit/pro bekit