Implementing the Data Access Object Pattern Using AspectJ André Luiz de Oliveira
André Luis Andrade Menolli
Ricardo Gonçalves Coelho
Computer Science Department State University of the Nort of the Paraná - Bandeirantes
[email protected]
[email protected]
ABSTRACT Due to the constant access and storage information need, there is a constant concern for implement theses functionalities in larger part of the current developments applications. The most theses applications use the Data Access Object pattern to implement those functionalities, once this pattern makes possible the separation of the data access code of the application code. However your implementation cause the exhibition of the data access object to the others application objects, causing situations witch an business object access the data access object. With the target of solving this problem, the present work proposes an aspect oriented implementation of this pattern, followed by a quantitative evaluation of both object oriented (OO) and aspect oriented (AO) implementations of this pattern. This study used strong software engineering attributes, such as separation of concerns, coupling and cohesion, as evaluation criteria.
Categories and Subject Descriptors D.2.11 [Software Engineering]: Software Architectures – patterns, information hiding, and languages; D.3.3 [Programming Languages]: Language Contructs and Features – patterns, classes and objects.
General Terms Design, Languages.
Keywords Data Access Object pattern, aspect oriented implementation, metrics.
1. INTRODUCTION A lot of applications frequently need implements some access mechanism of data persistence, once the organizations often needs access and storage yours information in some kind of database. To access this information security and efficiently some patterns was introduced by several authors, so much in the object-oriented software development (OOSD) as in the aspect-oriented software development (AOSD). In the literature we can find several patterns that implement the data persistence, like Persistence Data Collection [15], that provide a class and interfaces configuration to separate data access code and business rules from user interface, promoting the modularity. Among others patterns with the same purpose is the Decoupling Patterns, that is a set of data access patterns proposed by Nock [16], that describes strategies to uncouple data access
[email protected]
components from others parts of the application, and the Data Access Object [20], that is one of the data access pattern more used, due to fact of this pattern isolate the whole data access code of the application code, facilitating migration processes for others storage systems. There are several forms of implementing the data access functionality of the application. As sees in [20], can be adopted the factory data access object strategy, in situations witch the applications access more than one storage mechanism, or create an generic data access object, in order to determine a common access point to the data access functions of the application. Both the implementations mentioned previously are good solutions that isolate the data access code of the others application functions, optimizing the legibility and the modularity of the developed application, facilitating futures maintained and extension process of the application, providing the reuse of several components of the system. It was verified in [20], that Data Access Object pattern allow the business object to the using the data source without having the knowledge of the specifics details of your implementation, supplying a transparent access to the your functionalities, once that details of the data source implementation are encapsulate within of the data access object. That whole transparency provoke the exposition of the data access object to the others application objects, causing situations witch an business object access the data access object, harming the modularity, the legibility and the encapsulate the application code, besides the need of adding an extra objects layer between the data client and the data source so that your implementation the benefices of this pattern. With the objective of solving this problem, the present work proposes an alternative implementation of the Data Access Object pattern using the aspect oriented programming with AspectJ language. That solution provided the encapsulate of the data access functions of the application development, once that the business object and others application components no more need access the data access functions of the application, whole the control from calls to the data access and persistence operations is made by aspects. Being like this, the others application objects not more need knowledge the implementation details of the classes and methods responsible for the data access functions of the application, optimizing the application modularity and legibility. In this study, we identified some situations in that are profitable to change the Data Access Object pattern implementation to an aspect oriented implementation of this pattern. These situations happen when there is a need constant of isolate whole the data
access functions implementation of the application, in order of avoiding the data access object exposition to the others application objects. Your application provided a better separation of concerns of data access that is verified for the outcomes presented in the 5 section. Those outcomes were obtained through a comparative study between object oriented (OO) and aspect oriented (AO) implementations of the Data Access Object pattern. The comparison between OO and AO implementations of traditional patterns not is so new. Some papers already made this kind of comparison, like [8, 11]. This paper presents an alternative implementation of the Data Access Object pattern, followed of an quantitative evaluation of both OO and AO implementations of this pattern. Is important to point out that this work not proposes an approach that substitutes the Data Access Object pattern, but yes an alternative approach for the implementation of this pattern, that can be applied in the application scenarios previously mentioned, providing a better separation concerns of this pattern. In order to explicit the foundations of the proposed solution, the present work is organized in eight sections. The section 2 supplies a brief description of the Data Access Object pattern. The section 3 approaches the persistence concepts using the aspect oriented programming. The section 4 presents the organization of the developed study that includes a brief illustration of the studies developed for Hannemann and Kiczales [11] and Garcia et. al. [8], the OO and AO implementations of the Data Access Object pattern, the metrics used in the validation of this study and the evaluation procedures adopted. The section 5 expose the outcomes obtained in the comparison of the OO and AO implementations of the Data Access Object pattern. The section 6 present the discussion on the outcomes showed in the section 5 and illustrates the constraints of this study. The section 7 approach some related works to this study. And finally, the section 8 exposes the conclusions and the future works proposes.
2. DATA ACCESS OBJECT PATTERN Was verified in [20] that the Data Access Object pattern aims at to avoid direct dependence situations between the application code and the data access code. Such dependence happens when the business components like beans, and even presentation components, like a Swing GUI, servlets, and helper objects for Java Server Pages (JSP) need to access a data source, they can use appropriate API to reach the connectivity and manipulate the data source. Such code dependence in those components make difficult and tedious the task of migrate the application of a type of data source for other, or be, when modifies the data source, the components need to be modified to manipulate the new type of data source. The application of the Data Access Object pattern supply an interface of data access to the business and presentation components, providing an independence of data source and APIs of storage persistence used, contribute to the portability of the systems components and facilitate the migration to different data sources [20]. The structure this pattern is illustrated in the Figure 1.
Figure 1. Structure of the Data Access Object pattern.
3. PERSISTENCE CONCEPTS USING ASPECT ORIENTED PROGRAMMING The persistence crosscutting concern, in agreement with the vision [19], consists of functionalities responsible for the persistence storage of information manipulated by the system. Those functionalities correspond to the exception control, transaction management, partial loading and object cache to get better performance and objects states synchronization with the corresponding database entities to the consistence assure. Verified in [19], that the persistence concern can be divided in several sub-concerns, like data access classes, connection control, management transaction and data access classes customizations. Even with large use of the Data Access Object [20] pattern, that allow the modularization of the persistence concern in data access classes, some code spaces of that interest are dispersed and interlaced found by the functionalities of the business and presentation layers (the knowledge GUI layer).
4. ORGANIZATION OF THE STUDY This section describes the configuration of that empirical study. This study approaches an alternative implementation of the Data Access Object pattern, using the aspect oriented programming, with the AspectJ language. In order to explicit the propose solution foundations, the section 4.1 presented a brief description of the Hanneman and Kiczales [11] and Garcia et. al. [8] studies. The section 4.2 show the object oriented implementation of the Data Access Object pattern and later the aspect oriented implementation of this pattern. Already the section 4.3 introduces the metrics used in the evaluation process of the propose solution. And finally, the section 4.4 describes the applied evaluation procedures.
4.1 Hannemann and Kiczales and Garcia et. al. Study Verified in [11] that several design patterns exhibit crosscutting concerns. Was in that context that [11] undertaken a study in which they developed and compared Java [14] and AspectJ [2] implementations of the 23 GoF design patterns [6]. [11] verified in your study that the programming languages affect pattern implementation. Second [8], design patterns assign roles to their participants. Was verified in [11], that an amount of patterns involve crosscutting structures in the relationship between roles and classes in each instance of the pattern. Those roles was verified for [11], in which correspond to the defining and superimposed roles, in which the defining role, defines a participant class completely, or be, the
classes that carry out this role have no functionality outside the pattern, an example of that role is in the Facade pattern. Already the superimposed role can be assign to participant classes that have functionality outside of the pattern. An example of that role is in the Mediator pattern. These kinds of roles were used by [11] to analyze the crosscutting structure of the design patterns. The developed study for [11] had the goal of modularity the roles finding in the 23 design patterns [6], using AspectJ implementations. The authors reported that modularity improvements were reached in 17 of the 23 patterns, and 12 aspect oriented pattern implementations resulted in improved reuse. In agreement with [8], the obtained improvements for the [11] study were based in some attributes that are not well know in software engineering, such as composability and pluggability. Moreover, this study was based only on a qualitative assessment. With the purpose to solve this problem, [8] supplement this study by quantitative case studies, seeking to provide the knowledge about the use of aspects for addressing the crosscutting properties of the design patterns. The development study for the [8] was based on well know software engineering attributes, such as separation of concerns, coupling, cohesion and size. In this study was verified that the aspect oriented solutions improved the separation of patternrelated concerns, in addition to this was found that: (i) the use of aspects helped to improve the coupling and cohesion of some pattern implementations; (ii) the “aspectization” of the design patterns reduced the number of the attributes of 10 patterns, and decreased the number of operations and respective parameters of 12 patterns; (iii) only 4 design patterns implemented in AspectJ have exhibited significant reuse degree; (iv) the relationship between pattern roles and applicationspecific concerns are sometimes so intense that it seems not trivial to separate those roles in aspects; (v) the use of coupling, cohesion and size metrics was helpful to assist the detection of opportunities for aspect-oriented refactoring of design patterns.
the Business Logic and the Data Access. The Business Logic role is responsible for every control of the business logic of the application, or be, it make the data inputs treatments before of those data be passed in the call of data access function, besides manipulating the obtained data of a data access function, summarizing that role is an data client [20]. Already the Data Access role represents the object that abstracted the underlying data access implementation [20] to the Business Logic role, enabling transparent access to the data source, or be, it provide all the access and storage data functionalities to the Business Logic role. The Figure 2 illustrates the oriented object implementation of this pattern applied in the present work. Analyzing this figure is ended that the Data Access role implementation is dispersed for all classes of the pattern. Already the Business Logic role is implemented for the BusinessObject and TransferObject classes.
Figure 2. Object oriented model of the Data Access Object pattern The Figure 3 presents the source code of the BusinessObject class. The code spaces that not implemented the Business Logic role are shadowed. That class possess reference the DataAccessObject and TransferObject classes (lines 09 and 10), that are instantiated in the constructor method of the class (lines 14 and 15). This class contains the insert method (lines 17 to 26), that modified the attributes values of the LaboratoryReservation object (lines 19 to 23), and passes that object as argument to the insert method, present in the LabReservationDAO (line 24), to register a new reservation.
The study of [8] obtained less optimistic results than the exposed for [11], in virtue of the first have based in quantitative measures and the second to be based in simple qualitative attributes. But is important to point out that quantitative metrics treated in an isolated way provide inconsistent outcomes, once a larger amount of lines of code (LOC) can mean as much a modularization improvement of a program as the organization code lack. The study [8] was based in the united analysis of 9 quantitative metrics, in which 8 were used in the validation process of the aspect oriented implementation of the Data Access Object pattern proposed in this work. Those metrics are described in the section 4.3.
4.2 Data Access Implementation
Object
Pattern
As seems previously, the Data Access Object aims at avoid direct dependence situations between the application code and the data access code [20]. Analyzing this pattern, was verified that it define two roles for yours participant classes, that correspond to
Figure 3. BusinessObject class in the OO implementation As it is observed in the Figure 3, the shadowed code implements the Data Access role within of the Business Logic role
implementation. Those shadowed points are places where there a concern switch in the pattern implementation, once the data access concern is interlaced with the business logic manipulation concern. In order to solve that problem, the aspect oriented implementation of this pattern avoid that the business components, in the case the BusinessObject class, have the knowledge of the data access objects of the application, totally isolating those objects of the application code, providing a better separation of the Business Logic and Data Access roles, as illustrates the Figure 4.
The AO implementation of the Data Access Object pattern approached in this work avoid that the business object instantiate an data access object, to have access to the your functionalities, once the aspect captures the join points presents in the business object, execute the required operation and return the resultant value of your execution for this join point. The presented solution provided the encapsulate of all the data access functionality of the application, contributing to the modularity and legibility of the development application, once in this solution the business object not need of interact with the data access object, that is implemented as one aspect, that control all the data access functions defined in the business object. The optimization of those software engineering attributes was verified through the application of a measurement process of that solution, that is described in the next sections of that work. In the AO solution of the Data Access Object pattern, the code that implement the Data Access role is textually localized in the aspect DAOAspect, that encapsulates all the data access functions of the application, isolating her of the remaining of the application code, as illustrates the Figure 6.
Figure 4. Aspect oriented model of the Data Access Object pattern In the diagram shown previously, the business object acts as an Facade [6] object, that works as a access interface to the functionalities present in the subsystem, in your conventional implementation. Already in the AspectJ implementation, that object acts as one interface that contains only the methods body (assign, parameters list and the return value) need the execution of the data access functionalities of the application. The DAOAspect object, showed in the Figure 4, is the key point of the AO implementation of the Data Access Object pattern proposed in this work, due to fact of this to make the whole control of the data access logic of the application, through the pointcuts definition, that contains the join points be captured her for the execution of the data access functions of the application, implemented in the advices, as display in full detail the class diagram of the Figure 5. That diagram is based in an aspect oriented modeling notation proposed for [13].
Figure 6. DaoAspect implementation
Figure 5. Class diagram of the aspect oriented implementation of the Data Access Object pattern Due to that solution, can be observed that the aspect make the whole control of the data access logic of the application, capturing an join point, executing an data access operation and returning the operation value for this join point.
The related code to the Data Access role implementation is shadowed, in which contains a reference to the GenericDAO object (lines 12 and 16), that correspond to the data source implementation, and a reference to the LaboratoryReservation object (line 13), that is the object that implement part of the business rules of the application. The whole implementation process of the data access concern ponders in the insert pointcut (lines 19 to 23), that captures the insert join point, defined in the BusinessObject class, and in the around advice (lines 25 to 40), that execute a database manipulation operation in turn of the call of an join point, returning the resultant value of that operation to for the same.
That implementation removes whole the data access concern of the class that implementing the business rules of the application, in virtue of those classes not more depend of the data access classes of the application. That independence can be visualized better in the Figure 7, that illustrates the BusinessObject class implementation after the insert of the data access aspect DAOAspect.
Figure 7. BusinessObject class after of the DaoAspect implementation As display the Figure 7, in the AO implementation of the Data Access Object pattern, whole the data access concern code was removed of the classes that carry out the Business Logic role, turning them more modulate and maintained, once in these classes they ponder only the Business Logic concern, that corresponds to the shadowed code of the Figure 7, not more existing the
dependence with calls to the data access functions of the application, as illustrated in the conventional object oriented implementation in the Figure 3. That is possible in virtue of whole the control of call and execution of the data access functions of the application be pondered in an data access aspect.
4.3 Metrics Used This study selected a group of metrics of separation concerns, coupling, cohesion and size [17] to evaluate the foundations of the aspect oriented implementation of the Data Access Object pattern approached in this work. These metrics have already been used in four different studies [7, 8, 9, 18]. Some of them have been automated in the context of a query based tool for the measurement and analysis of aspect oriented programs [1]. This metrics was defined based on the reuse and refinement of some classical and object oriented metrics [3, 5]. The original definitions of object oriented metrics [3] were extended to be applied in a paradigm independent way, supporting the generation of comparable results. The separation of concerns metrics measure the degree to which a single concern in the system maps to the design components (classes and aspects), operations (methods and advices), and lines of code [17]. The Table 1 presents a brief definition of each metric applied in this study, and associates them with the attributes measured by each one. More detailed information about these metrics can be found in [7, 17].
Table 1. Metrics
4.4 Assessment Procedures With the purpose of comparing the OO and AO implementations of the Data Access Object pattern, both versions of the pattern implement the same functionalities, with same style of codification. This pattern possess several implementation forms, in which the study in question chose the one that seems be the more used. Just happened few modifications in the aspect oriented solution in relation to the object oriented solution, in that some methods was modified or excluded, some attributes and a class was excluded and an aspect was added. Likewise to the [11]
study, this work treats each role as a crosscutting concern, because the roles are primary sources of crosscutting structures [8]. In that measurement process, the data were gathered with base in the code analysis, using the Eclipse 3.3 ver. tool [4]. The measures of separation of concerns (CDC, CDO and CDLOC) were preceded by the shaded of all the classes and aspects in both pattern implementations. That shadowed was accomplished with the roles found in the Data Access Object pattern implementation. Likewise to the Hannemann and Kiczales [11] study, in this study each pattern role was treated as a concern, once roles are primary fonts of crosscutting structures [8]. The Figures 3, 6 and 7
exemplify the shadowed of some classes and aspects in both the Java [14] and AspectJ [2] implementations of this pattern, for consider the Business Logic and Data Access roles. After the shadowed, the separation of concerns data metrics were manually collected.
5. RESULTS This section presents the measurement process results. The data have been collected with base in the metrics defined in the section 4.3. The objective of that measurement process is describer the results of the metrics application in the OO and AO implementations of the Data Access Object pattern, in order to compare and prove the foundations of the aspect oriented implantation of this pattern. That analysis is divided in two parts. The section 5.1 focalizes in the analysis of to what extent aspect oriented and object oriented solutions provide support to the separation of the pattern-related concerns. The section 5.2 presents the results with respect to the coupling, cohesion and size metrics. In the exhibition of the results of this study graphics are used to represent the data gathered in the measurement process. The results of the graphics presents the data gathered of the OO and AO implementations of the Data Access Object pattern. The Yaxis of the graphic presents the absolute values gathered by the metrics. Each per of bars, that correspond to the metric values gathered by the OO and AO implementations of the pattern, is attached to a percentage value, which represents the difference between the OO and AO results. A positive percentage means that the AO implementation was superior, while the negative percentage means that the AO implementation was inferior. The results presented in the graphics were gathered with base in the pattern point view, or be, they represent the metric values associated with all classes and aspects for each pattern implementation. To obtain the separation concerns metric values of both OO and AO implementations of the Data Access Object pattern, firstly was verified the presence of two roles in the of this pattern implementation. That was made because the roles are primary sources of crosscutting structures [8].
5.1 Separation of Concerns The Figure 8 presents the separation of concerns metrics results for the OO and AO implementations of the Data Access Object pattern. As is observed in the Figure 8, the most of the measurements favored in a significant way the AO implementation of this pattern. That solution reduced the coupling of the classes that play the Business Logic role, and consequently the number of operations for implements that role, besides demanding few concerns switches between the components that play the Business Logic and Data Access roles.
Figure 8. Results of separation of concerns metrics An analysis of the Figure 8 shows that those improvements were reached through separate the pattern role in aspects. The definition of the Business Logic role demanded 3 classes in the OO solution, while that the aspects application reduced that number for 2, providing a better separation of that role with relation to the OO solution. That improvement is equal to the 33% of AO solution superiority with relation to the OO implementation. The results yet were better for the concern diffusion over components (CDC) in the Business Logic role and diffusion of concerns over lines of code (CDLOC) metrics, which reached optimizations of 87,5% with relation to the OO implementation. In addition, can be observed that good results were reached in the modularization of the defining role, that in case is the Business Logic. After that analysis, is ended that the AO implementation of the Data Access Object pattern optimized in media of 69% the isolation of the implemented concerns by the Business Logic role in comparison with the OO solution. One of the reasons to the superiority of the AO implementation over the OO implementation is that in the OO solutions there several operations implementations mixed with the specific code of the role.
5.2 Coupling, Cohesion and Size In this section are presented the results of coupling, cohesion and size metrics. Was used an graphic for the representation of the gathered results, that represent the metrics values associates with all classes and aspects for each pattern implementation, with exception of the DIT metric. The results of DIT represent the maximum value of this metric for all the implementation. In the OO implementation of the Data Access Object pattern were reached improvements only in the NOA metric, as illustrates the Figure 9. The use of aspects led the reduction of only 0,5% of the LOC metric in relation to the object oriented project, therefore is ended that this difference is despicable. In spite of the data access code retreat of the classes that carry out the Business Logic role, the aspect that carry out the Data Access role possess more lines of code that the OO implementation of that role.
Similar to the study of [8], that illustrates the implementation of roles of several patterns in aspects, in our study the Data Access role, of the Data Access Object pattern was expressed separately with an aspect.
6.1.2 Reducing Coupling and Increasing Cohesion
Figure 9. Coupling, cohesion and size metrics results With relationship to the NOA metric results, the AO implementation obtained 7,1% of superiority in relation to the OO solution. That occurs in virtue of in the OO solution, the classes that carry out the Business Logic role possess a reference to the data access object that in the AO project was retired. With relation to the CBC and LCOO metrics, the results were same to both OO and AO implementations. That similarity happens in virtue of the occurrence of just one an coupling inversion between the business object and data access object components in both implementations of the pattern. In the OO implementation, the business object component possess a dependence relationship with the data access object. Already in the AO implementation, happen the contrary, the data access object component possess a dependence relationship with the business object component, as shown in the Figure 4. And to respect of the cohesion metrics, your values continued constants in both the solutions, once them use the same operations and references to the attributes. The value of the WOC metric was the only in which the AO implementation obtained result inferior to the solution OO. This inferiority corresponds to the 32,5%. The reason of this is based in the fact that the AO implementation possess declarations of advices with more parameters, what doesn't happen in the OO solution.
Based in the results of the section 5.2, we can conclude that the use of aspects in the implementation of the Data Access Object pattern didn’t alter the values of the CBC and LCOO metrics obtained by the conventional OO implementation. The value of the CBC metric didn't lose temper in both implementations, in virtue of the occurrence of a coupling inversion between both the implementations of this pattern, once in the OO implementation, the BusinessObject class possesses a dependence relationship with the DataAccessObject class, and in the AO implementation is the data access aspect that possess a dependence relationship with the BusinessObject class. Was verified that the reason for the which LCOO metric values be same in both the implementations, is that those implementations use the same operations and references to the attributes. Another reason for those results is that the optimization of those metric ones with the use of aspects is only in patterns roles [8] that healthy highly interactive. The results obtained by the CBC and LCOO metrics are justified for the fact that the use of aspects optimize the values of those metrics only in patterns that possess roles that healthy highly interactive [8]. As is the case of the Mediator pattern, that possesses the Mediator and Colleague roles, that collaborate to each other [6]. The use of aspects in this pattern modularized [8] the collaboration protocol between the pattern roles. However, the roles of the Data Access Object pattern not possess the same interactivity.
6.1.3 Reusability Issues
This section provides a general analysis of the observed results in the section 5 and discusses the constraints in the validity of ours empirical evaluation.
The Data Access Object pattern implementation proposed in this work is not characterized as a reusable solution, in virtue that reusable solutions define as reusable abstracts aspects, improve the separation of concerns, increase the cohesion and reduces the values of the LOC and WOC metrics with the applied changes. In spite of that implementation improve the separation of concerns and reduce the LOC of a discreet way, she didn't obtain the same results with relation the LCOO, CBC, WOC metrics and not implements abstract aspects.
6.1 General Analysis
6.1.4 Aspects and Size Attributes
This section illustrates a global analysis of the resulted previously observed in the application of metrics to the separation of concerns, coupling, cohesion and size.
This comparative study verified that the use of aspects obtain negative results for the metric WOC and a discreet positive result for the LOC metric. In relation to the WOC metric, that measure the number of operations and your respective parameters, the AO implementation was 32,5% inferior to the OO solution. That result is decurrently of the augment of the quantity of parameters in the advices declarations in comparison with the OO solution. To the opposite, the result of the LOC metric was only 0,5% superior to the OO implementation, a difference not very significant. Even with the best separation of concerns related to the Business Logic role in the AO solution, in which there was the removal of all the data access code of the components that implements this role, that doesn't guarantee optimization in both the metrics.
6. DISCUSSIONS
6.1.1 Separable and Inseparable Concerns As verified previously in the section 5.1, the AO implementation of the Data Access Object pattern showed better results in terms of separation of concerns metrics. This observation provides the evidence of the effectiveness of AO abstractions to segregate crosscutting structures. The results obtained in these metrics confirmed the observations of the [11] study in terms of the place property that consists in the reduction of coupling between the pattern classes.
Those results are justified for the reason that the use of aspects optimize the values of this metrics only in patterns that possess roles that healthy highly interactive [8], as happen with the coupling and cohesion metrics. In agreement with [8], the reduction of the program size usually reduces the probability of developers introduce mistakes in the system.
6.2 Study Constraints With relation to the metrics used in this study, was verified in [8] that there are some critics to the respect of your application. Those critics refer to the theoretical arguments related to the use of conventional size metrics, that are commonly applied in the traditional software development. In spite of the simplicity of those metrics, they have been objective of the several critics in [23]. The reason of those critics is the difficulty of evaluating software quality attributes, as for example, the LOC measures are difficult to interpret, since in certain situations a high value of LOC can mean a better modularization, or mean code replication by the project components. Was verified in [8] that due to the limitations of these metrics, they cannot be analyzed in an isolated way. However they are extremely useful when analyzed in conjunction with others used metrics. In addition, was verified in [8] that some researchers, as Henderson-Sellers [12], have criticized the lack of a solid theoretical bases and empirical validation of the cohesion metrics. The AO implementation of the Data Access Object pattern presented in this study can restrict the extrapolation of the results obtained in this work. The evaluation process of the presented implementation is restrict to one instance specific of the Data Access Object pattern, in case was selected the more used.
7. RELATED WORKS Exists few related works focusing in the quantitative evaluation of aspects oriented solutions to modularize crosscutting concerns of the classic design patterns. Was verified in [8] that initials experiments, as the one of [11], were based in qualitative measures. Already the study of [8] presented a quantitative evaluation of the OO and AO implementations of the 23 design patterns of the GoF [6]. The section 5 exposed some critics to the respect of the cohesion metrics. Seeking to optimize those metrics, the studies of Zao and Xu [21, 22] have proposed new cohesion measures that considerer the peculiarities of the AO abstractions and mechanisms. Those metrics are based on a dependence model for AO software that consists in a group of dependence graphs. In that study the authors have show that their measures satisfy some properties that good measures should have. However, as sees in [8], these metrics not yet been validated or applied to the assessment of realistic AO systems.
8. CONCLUSIONS The present work presents an alternative aspect oriented implementation of the Data Access Object pattern, and makes a comparative evaluation between the OO and AO of this pattern. The results of this study have been showing that the AO implementation improves the separation of concerns, reduced the
quantity of the lines of code (LOC) and optimized the number of attributes (NOA) of the pattern. With relation to the coupling and cohesion, there was not difference between the results of the both implementations, in virtue of the occurrence of dependence inversion between the BusinessObject and DAO components and due to the use of the same attributes and methods in both implementations. That occurs because the use of aspects increases the cohesion and reduces the coupling only in patterns that possess role highly interactive. Already the WOC metric, was the only metric that obtained inferior result in relation to the OO implementation. That result is reflex of the advices declarations with many parameters in the AO solution. Before the obtained results, can be ended that the alternative implementation of the Data Access Object, approached in this work, provided larger modularity and legibility in the development application code, facilitating maintenance and extensions processes of the application, once this solution provided the encapsulation of all data access functionalities of the application, due to the fact that the business objects not more need of interact with the data access object, that is implemented with an aspect, that control all the data access functions defined in the business object. The approach presented in this work allow that all the data access layer of the application be implemented through aspects, providing a total isolation of the data access functions of the application. The positive results obtained by the application of that solution confirmed the optimization of legibility and modularity aspects in the development application, could be implemented in any application that need of access and persistence of data functionalities. As proposal the futures works can be placed an quantitative study about the OO and AO implementations of the Core J2EE patterns, with the objective of verify in which patterns the aspect oriented programming provide a better modularization in relation to the object oriented implementations. Other proposal for futures works is the project of a software architecture aspect oriented, based in the discussed approach in this writing. That proposal has the purpose of reducing the increase crescent in the complexity and dimension of the software systems projects in the present time, caused by the crescent increase in the complexity in the user requirements and by the constant need of the integration of applications through several platforms, with the purpose of possibility the global access to the information.
REFERENCES [1] Alencar, P. et al. A Query-Based Approach for Aspect Measurement and Analysis. TR CS-2004-13, School of Computer Science, Univ. of Waterloo, Canada, Feb 2004. [2] AspectJ Team. The AspectJ Guide. http://eclipse.org/aspectj/. [3] Chidamber, S. and Kemerer, C. A Metrics Suite for OO Design. IEEE Trans. on Soft. Eng.,20-6, June 1994, 476-493. [4] Eclipse Project. http://www.eclipse.org. [5] Fenton, N. and Pfleeger, S. Software Metrics: A Rigorous Practical Approach. London: PWS, 1997.
[6] Gamma, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, 1995. [7] Garcia, A. From Objects to Agents: An Aspect-Oriented Approach. Doctoral Thesis, PUC-Rio, Rio de Janeiro, Brazil, April 2004. [8] Garcia, A., Sant'Anna, C., Figueiredo, E., Kulesza, U. Modularizing Design Patterns with Aspects: A Quantitative Study. International Conference on Aspect-Oriented Software Development (AOSD'05), Chicago, USA, 14-18 March 2005. ACM Press. Pages 3-14. [9] Garcia, A. et al. Separation of Concerns in Multi-Agent Systems: An Empirical Study. In Software Engineering for Multi-Agent Systems II, Springer, LNCS 2940, January 2004. [10] Garcia, A., Silva, V., Chavez, and C., Lucena, C. Engineering Multi-Agent Systems with Aspects and Patterns. J. of the Brazilian Computer Society, 1, 8 (July 2002), 57-72. [11] Hannemann, J., Kiczales, G. Design Pattern Implementation in Java and AspectJ. Proc. OOPSLA’02, Nov 2002, 161173. [12] Henderson-Sellers, B. Object-Oriented Metrics: Measures of Complexity. Prentice Hall, 1996.
[15] Massoni, T.; Alves, V. and Soares, S. PDC: Persistent Data Collections pattern. First Latin American Conference on Pattern Languages of Programming, Rio de Janeiro, Brazil, 3th-5th October 2001. [16] Nock, Clifton. Data Access Patterns: Database Interactions in Object-Oriented Applications. Addison-Wesley. 2003. [17] Sant’Anna, C. et al. On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. Proc. of Brazilian Symposium on Software Engineering (SBES’03), Manaus, Brazil, Oct 2003, 19-34. [18] Soares, S. An Aspect-Oriented Implementation Method. Doctoral Thesis, Federal Univ. of Pernambuco, Oct 2004. [19] Soares, S. et. al. Implementing distribution and persistence aspects with AspectJ. ACM. In Proceedings of the OOPSLA' 2002, pp. 174-190, Seattle, USA. 2002. [20] Sun Microsystems. Core J2EE Patterns: Data Access Object. 2002. http://java.sun.com/blueprints/corej2eepatterns/Patter ns/DataAccessObject.html. [21] Zhao, J. Towards a Metrics Suite for Aspect-Oriented Software.TR SE200213625, Inf. Proc. Society of Japan, 2002.
[13] Jacabson, Ivar and Ng, Pan-Wei. Aspect Oriented Software Development with Use Cases. Addison-Wesley. 2004.
[22] Zhao, J. and Xu, B. Measuring Aspect Cohesion. Proc. Conf. on Fundamental Approaches to Software Engineering (FASE'04), LNCS 2984, Barcelona, March 2004, 54-68.
[14] Java Reference Documentation. http://java.sun.com/referenc e/docs/index.html.
[23] Zuse, H. History of Software Measurement. Available online at: irb.cs.tu-berlin.de/~zuse/metrics/History_00.html.
