Design and Implementation of Business Logic Layer Object-Oriented Design versus Relational Design

Transcription

1 Design and Ipleentation of Business Logic Layer Object-Oriented Design versus Relational Design Ali Alharthy Faculty of Engineering and IT University of Technology, Sydney Sydney, Australia Eail: Abstract Object-oriented prograing has becoe one of the ainstrea prograing paradigs in software engineering, whereas relational odels are predoinant in coercial data processing applications. There is strong copetition between these odels for doinance in the building of odern applications, especially after the eergence and spread of object-relational apping technology. This paper addresses the question of whether the object-oriented approach is better than the traditional approach in ters of flexibility with respect to changing requireents. Keywords-object-oriented design; relational design; requireent changes; aintenance I. INTRODUCTION Currently, ost business logic layers of odern applications are constructed using either an object-oriented odel or a relational odel. The object-oriented odel is based on software engineering principles such as coupling, inheritance, cohesion, and encapsulation, whereas the relational odel is based on predicate logic and set theory principles [1]. The object-oriented odel chains the building of applications within objects that have both data and behavior. The relational odel supports the storage of data in tables and the treatent of that data with data anipulation language within the database through stored procedures and externally through structured query language. The relational odel is currently used in any database systes [1]. Object-oriented technology is also coonly used in database application developent. The difference between the two technologies is called the object-relational ipedance isatch [2][3]. In particular, when objects need to be stored in a relational database, object-relational apping (ORM) appears to play an iportant role in overcoing the proble of ipedance isatch. ORM is a new technology that allows applications to access relational data in an object-oriented anner [4][5]. With the widespread use of ORM technology, doain objects are built as objects, and the application logic anipulates these objects in a pure object-oriented anner. The critical issue that arises is whether such an object-oriented odel for business logic layers is a good choice in general. Proponents of the object-oriented approach have tended to assue that an object-oriented business odel will ake the syste easier to aintain, easier to extend, and easier to reuse. The object-oriented approach has been advocated as a tool for iproving developer productivity and software quality [6][7]. Moreover, it has been suggested that developent using object-oriented prograing enhances productivity by siplifying understandability, progra design, and aintenance in coparison to traditional approaches [8].These studies have aintained that using the object-oriented approach would help reduce the aintenance cost of software. However, there are few coplete experiental results that support the clai that there is an advantage in the aintainability of progras developed with the object-oriented approach over those developed with traditional approaches [7][9]. The objective of this paper is to extend this body of knowledge by critically exaining this assuption and to carefully copare the applicability and flexibility of the object-oriented syste to those of the relational syste. The findings fro this project will be significant for practical applications in which the business logic layer is ipleented in an object-oriented fashion, which is a growing trend in enterprise coputing. The rest of the paper is organised as follows. Section II presents the otivation for the study. Section III outlines the investigation ethod. Sections IV, V, VI, and VII present the case studies, and Section VIII reports the experiental results. Section IX concludes the paper. II. MOTIVATION Today, changing requireents have becoe a fact of life for software developers. Many studies have shown that changes in software were one of the reasons why various projects failed. For exaple, a study by the Standish Group found that only 37% of inforation technology projects are considered successes and that 21% of projects are considered failures [10]. The reaining 42% are considered challenged defined as late, over budget, or having failed to eet expectations. Requireent changes are the ajor cause of this phenoenon. Such changes can occur during the developent and aintenance phase in order to accoodate user and business requireents. Therefore, there is a need to identify a flexible approach that can deal with requireent changes. However, ORM is very popular and widely used. According to Russell [3], in order to access data stored in relational databases, ost odern applications are built using ORM technology rather than the traditional approach. 74

2 It has also been argued that using ORM tools can help reduce project costs. Moreover, proponents of the object-oriented approach have tended to assue that an object-oriented business odel will ake the syste easier to aintain, easier to extend, and easier to reuse. On the other hand, proponents of the traditional approach have argued that not all the world ust be handled in objects. In addition, they have aintained that there is soe native incopatibility between ORM code and databases. They also aintain that although object-oriented developent proises to reduce aintenance effort, these proises are not based on reliable experientation [11]. Indeed, there is a significant lack of research on whether the object-oriented approach is better than the traditional approach in ters of flexibility in the face of requireent changes. III. INVESTIGATION MHOD The investigation is perfored using a nuber of case studies and by introducing a variety of requireent changes in order to evaluate how the two approaches cope with the. For the ipleentation, we used Java Database Connectivity (JDBC), a representative relational syste, and, a representative ORM fraework, as well as MYSQL, a relational database. All of these are popular open-source products. In order to easure the overall ipleentation effort associated with JDBC and due to new/changed requireents, we used the code size produced in the copletion of a task the code size was easured in lines of code and takes into account lines added, odified, and deleted as well as the tie required to coplete a task. To easure the code size, we used a free tool to copare the source code files after each ipleentation. The case studies ipleentation has been done by a developer who has six years experience in Web and Database applications developent. IV. FIRST CASE STUDY We chose a siple case study to ake an initial coparison of the effort involved in ipleenting the two technological approaches and changing the in response to requireent changes. A. Proble stateent A copany requires a Car Park application to aintain inforation about eployees and their parking perits. The car park has a nuber of parking spots, which are divided into three areas: A, B, and C. Eployees who want a perit have to pay a fee on a quarterly basis, which will be autoatically deducted fro their salary. The purpose of the Car Park application is to help the car park anager process the eployees' applications for parking perits. Each eployee has an ID, a nae, and a phone extension. Each perit has a perit nuber, the car's registration nuber, and the section where the car can be parked. An eployee can have at ost two perits. Eployees ay change their extension in the course of their eployent. When eployees get a new car and want to use it instead of the old one, they have to discontinue the current perit and apply for a new one. B. Coparison of the findings of the initial construction of the two approaches TABLE I. Progra Files SLOC CPSyste.java 141 Perit.java 47 Eployee.java Util.java 16 4 h 30 Eployee.hb.xl 17 in Perit.hb.xl cfg.xl 18 Total 300 JDBC CPSyste.java h Table I suarises the findings of the initial construction of the Car Park syste using the two approaches. The table shows that even though there are no significant differences between the two approaches with respect to the effort easured by size of source code, the approach took ore tie than the JDBC approach. In fact, with we had to deal with six files, whereas with JDBC we had to deal with only one file. Therefore, the approach took about 4.3 h, copared to 3 h for JDBC. C. Ipact of requireent changes on the two approaches Because requireents change frequently in practice, it is useful to see how different approaches cope with requireent changes. For the initial investigation regarding requireent changes, we ade the following change: in the Terinate Perit use case, instead of deleting the perit (as we did before), we labelled the perit as terinated. D. Coparison of findings after first requireent change Progr a TABLE II. FIRST REQUIREMENT CHANGE Files V1 V2 A M D S CPS.java Perit.java Ep.java Ep.hb.xl Per.hb.xl Hiber.cfg.xl HiberUtil.java Total JDBC CPSy.java in 10 in V1 = before the change; V2 = after the change; A = add; M = odify; D = delete; S = suation of A,M, and D; = estiated tie 75

3 As Table II shows, there are significant differences between the two approaches with respect to the ipleentation effort easured by the size of the source code. The ipleentation of the new requireent changes with required a total of 25 lines of code, copared to only 3 lines of code using JDBC. In addition, the ipleentation of the new requireent changes with took about 40 in, whereas it took only 3 in with JDBC. Indeed, it is evident that JDBC offered ore flexibility with regard to both tie and effort. E. Further ipact of requireent changes on the two approaches For the second requireent change, suppose a copany needs to distinguish between full-tie and part-tie eployees. Part-tie eployees are paid an hourly rate, whereas full-tie eployees are assigned a salary. Pro gra JD BC TABLE III. SECOND REQUIREMENT CHANGE Files V1 V2 A M D S CPS.java Perit.java Ep.java PartTie.java FullTie.java Ep.hb.xl Per.hb.xl Hiber.cfg.xl HiberUtil.java Total CPSy.java h 20 in As Table III shows, the new requireents have had a greater ipact on the progra ipleented through, in ters of both the tie and the effort required to ipleent these changes. The ipleentation of the new requireent changes with required a total of 55 lines of code, in contrast to JDBC, which required only 16 lines. This difference represents a nearly 3:1 ratio in quantity of code. Although one of the key benefits of inheritance is iniising the aount of duplicate code in an application by sharing coon code aongst several subclasses, the ajority of new code is due to inheritance code. Moreover, the ipleentation with took about 1 h, copared to only 20 using JDBC. As a result, increasing the nuber of classes that need to be persisted autoatically can lead to increased levels of effort and tie. V. SECOND CASE STUDY We ade the second case study ore coplicated than the first in order to produce ore statistics with which to copare the two approaches. We also ade changes that reflect the change in business policy, that is, allowing ore than one kind of ite to be stored at a shelf location. This change in policy required a change in the structure of the classes. It will provide ore data with which to copare the two approaches. F. Proble stateent A database is needed to aintain inforation about the ites stored in various warehouses of a copany. Design a relational database, which can store the inforation contained the following: 1. Each warehouse has a phone (not shown) to contact the staff at the warehouse. 2. Shelf locations are of two types: single access and double access. 3. The present policies require that each shelf location, at any tie, can be used to store only one kind of ite. TABLE IV. Progra Files SLOC PartInWareHouse.java 141 Part.java 30 Warehouse.java 31 ShelfLocation.java 45 ShelfLocationPK.java 37 Util.java 16 Warehouse.hb.xl 12 Part.hb.xl 13 ShelfLocation.hb.xl 15.cfg.xl 18 Total JDBC PartInWareHouse.java h Table IV suarises the findings for ipleenting the Parts in Warehouses syste with the two approaches. required a total of 358 lines of code, in contrast to JDBC, which required 202 lines. In addition, required about 4 h, whereas JDBC required 2.3 h. clearly required ore effort and tie than JDBC. G. Ipact of requireent changes on the two approaches The storage rules change to allow ore than one kind of ite to be stored at a shelf location. This entails that the cardinality relationship between the two entities Shelf Location and Ites ust be changed to one-to-any. H. Coparison of the findings after first requireent change As shown in Table V, the new requireents have had a greater ipact on the progra ipleented through, in ters of both the tie and the effort required to ipleent these changes. The ipleentation of the new requireent changes with required a total of 139 lines of code, in contrast to JDBC, which required only 38. This difference represents a nearly 4:1 ratio in quantity of code. Indeed, the source of increase in code quantity was due to the addition of an ite class with its coposite key, which 58 4 h 76

4 is not necessary in JDBC. Moreover, the ipleentation with took about 1.30 h, copared to only 30 in with JDBC. Pro gra JDB C TABLE V. FIRST REQUIREMENT CHANGE Files V1 V2 A M D S WHouse.java Part.java Whouse.java SLoc.java SLocPK.java Ite.java ItePK.java HibUtil.java Who.hb.xl Part.hb.xl SLo.hb.xl Ite.hb.xl Hiber.cfg.xl Total WHouse.java h 40 in TABLE VI. Progra Files SLOC SOSyste.java 86 Custoer.java 22 Order.java 47 Product.java 41 Util.java 16 Custoer.hb.xl 10 Order.hb.xl 15 Product.hb.xl 12.cfg.xl 19 Total JDBC SOSyste.java h K. Ipact of requireent changes on the two approaches We changed the navigation rule between the objects fro unidirectional to bidirectional association. TABLE VII h VI. THIRD CASE STUDY: ISSUE OF RELATIONAL REPRESENTATION/NAVIGATION The representation of the relationship is a fundaental issue. In fact, the difference between hierarchy, network, relational, and object-oriented databases is the way in which the relationship is represented. Therefore, if we construct the application with JDBC, we will not experience the navigation proble, whereas the proble arises when the application is constructed with ORM. Thus, we have to decide how to represent the navigation objects. I. Proble stateent A distribution copany supplies various kinds of products to custoers on a daily basis according to the standing orders placed by the custoers. The copany wants to set up a syste to aintain inforation about the products that the copany can supply, its custoers, and the standing orders. J. Coparison of the findings of the initial construction of the two approaches Table VI suarises the findings for ipleenting the Standing Order syste with the two approaches. required a total of 268 lines of code, in contrast to JDBC, which required 141. In addition, required about 3 h, whereas JDBC required 2 h. Thus, required ore effort and tie than JDBC. Prog ra File Nae V1 V2 A M D S SOSys.java Cust.java Order.java Product.java Htil.java Cu.hb.xl in Or.hb.xl Pr.hb.xl Hib.cfg.xl Total JDBC SOSys.java As Table VII shows, the new requireents have had a greater ipact on the progra ipleented through, in ters of both the tie and the effort required to ipleent these changes. The ipleentation of the new requireent changes with required a total of 28 lines of code and 30 in, in contrast JDBC, which did not require any changes, because navigation is not an issue for it. VII. FOURTH CASE STUDY We ade this case study even ore coplicated and realistic in order to produce uch ore statistical data with which to copare the two approaches. The case study also highlights the issue of relationship representation and illustrates that the object-oriented approach is ore sensitive to the class odel than the relational odel. 77

5 L. Proble stateent Eastern Suburb Gynastics (ESG) is a regional organisation that is responsible for running copetitions between the gynastics clubs in eastern suburbs of Melbourne. The copetitions are organised into seasons. ESG needs a syste to help organise and aintain the records of the copetitions that take place in a single season. The syste, in essence, needs to store inforation on the gynasts, their clubs, the organisation of the copetitions, and the copetition results. M. Coparison of the findings of the initial construction of the two approaches TABLE VIII. Progra File SLOC GScoringSyste 237 Club 44 Copetition 24 CopetitionPk 35 Division 60 EventPk 46 Event 37 EventType 58 Gynast 60 Judge 40 Meet 52 TeaPk 46 Tea 33 Score 22 Util 16 Club.hb.xl 13 Copetition.hb.xl 12 Division.hb.xl 15 Event.hb.xl 21 EventType.hb.xl 14 Gynast.hb.xl 15 Judge.hb.xl 17 Meet.hb.xl 14 Tea.hb.xl 14 Score.hb.xl 16.cfg.xl 26 Total JDBC GScoringSyste h Table VIII suarises the findings for ipleenting the Eastern Suburb Gynastics syste with the two approaches. required a total of 987 lines of code, in contrast to JDBC, which required 259. In addition, required about 6 h, whereas JDBC required 3 h. It is evident that required ore effort and tie than JDBC. This difference represents a nearly 4:1 ratio in quantity of code. Indeed, the source of the increase in the code quantity was due to a plain old Java objects (POJO) and its apping files. 6 h N. Ipact of requireent changes on the two approaches Here, we investigated how sensitive the two approaches are to the choice of doains odelled. TABLE IX. Prog ra File Nae V1 V2 A M D S GSSyste Club Copetition CopetitionPk Division EventPk Event EventType Gynast Judge Meet TeaPk Tea TeaMeber Score Util Club.hb.xl Cop.hb.xl Divis.hb.xl Event.hb.xl ype.hb.xl Gyt.hb.xl Judge.hb.xl Meet.hb.xl Tea.hb.xl TMeber..xl Score.hb.xl Hibern.cfg.xl Total JDBC GSSyste Table IX shows that the ipleentation of the new requireent changes with required a total of 106 lines of code, in contrast to JDBC, which required only 32. This difference represents a nearly 3:1 ratio in quantity of code. Moreover, the ipleentation with took about 1 h, copared to only 25 in for JDBC. VIII. RESULTS The results of our critical coparison of the two paradigs in ters of flexibility, which was based on ipleentation findings, indicate that in the initial construction of the application, using ORM is uch costlier than using JDBC. In other words, the level of effort and tie required to ipleent the application is uch higher with than with JDBC. For instance, the initial construction of the ESG syste with ORM required a total of 987 lines of code, in contrast to JDBC, which required 259. This difference represents a nearly 4:1 ratio in quantity E T 1 h 25 i n 78

6 of code. In addition, ORM required about 6 h, whereas JDBC required only 3 h. Indeed, increasing the nuber of classes that need to be persisted autoatically can lead to increased levels of effort and tie. Moreover, JDBC is ore flexible in the face of requireent changes than is ORM. For exaple, for an object to be persisted to a database, needs a apping file for all the objects that are to be persisted as well as POJO, which is not required when using the JDBC approach. This eans that if we would like to add an attribute to or delete an attribute fro a class, we ust odify the apping file of that class to ap or delete the attribute, and subsequently we ust odify the class itself to add/delete that an attribute with its getter and setter ethods. When using JDBC, in contrast, we do not need to undertake these steps. Furtherore, the object-oriented paradig has an issue related to navigation between objects through association links, whereas navigation is not an issue for JDBC. In addition, deterining the direction with UML is not an easy task, which can be considered one of the coon istakes in design decision. In addition, the objectoriented approach is ore sensitive to the class odel than the relational odel. It is worth entioning that the developer did not use auto-code generation during perforing the initial construction ipleentation, and this could explain the rearkable difference in tie between two approaches. Although the current study has yielded soe clear preliinary findings, its design is not without flaws. First, the case studies were sall scale as a result of soe restrictions, such as the tie and effort required for ipleentation. A further liitation is that the ipleentation of all the case studies was perfored by one developer, which ay affect the generalisability of the study s findings to different developers. results and to investigate flexibility of object-oriented approach to requireent changes. REFERENCES [1] E. F. Codd, A Relational Model of Data for Large Shared Data Banks, Counications of the ACM, vol. 13, 1970, pp [2] B. Unger, L. Prechelt, and M. Philippsen, The Ipact of Inheritance Depth on Maintenance Tasks: Detailed Description and Evaluation of Two Experient Replications. Fak. für Inforatik Univ., [3] C. Russell, Bridging the Object-relational Divide, Queue, vol. 6, 2008, pp [4] M. I. Aguirre-Urreta and G. M. Marakas, Coparing Conceptual Modeling Techniques: A Critical Review of the EER vs. OO Epirical Literature, ACM SIGMIS Database, vol. 39, 2008, pp [5] F. Lodhi and M. A. Ghazali, Design of a Siple and Effective Object-to-Relational Mapping Technique, in Proceedings of the 2007 ACM Syposiu on Applied Coputing, 2007, pp [6] S. Sircar, S. P. Nerur, and R. Mahapatra, Revolution or Evolution? A Coparison of Object-oriented and Structured Systes Developent Methods, MIS Quarterly, 2001, pp [7] G. A. Kiran, S. Haripriya, and P. Jalote, Effect of object orientation on aintainability of software, in Software Maintenance, Proc. International Conference on, 1997, pp [8] M. B. Rosson and S. R. Alpert, The Cognitive Consequences of Object-oriented Design, Huan-Coputer Interaction, vol. 5, 1991, pp [9] M. A. Eieran and M. T. Dishaw, The Process of Software Maintenance: A Coparison of Object-oriented and Third-generation Developent Languages, Journal of Software Maintenance and Evolution: Research and Practice, vol. 19, 2007, pp [10] S. Group. (2011). The Standish Group International Inc. [11] E. Arishol and D. I. Sjoberg, Evaluating the Effect of a Delegated Versus Centralized Control Style on the Maintainability of Objectoriented Software, IEEE Transactions on Software Engineering, vol. 30, 2004, pp IX. CONCLUSION This paper addressed the question of whether the objectoriented approach is better than the traditional approach or vice versa in ters of applicability and flexibility to requireent changes. The experiental results show that the object-oriented approach required ore tie and effort as a result of apping files. Moreover, the object-oriented approach has an issue of navigation between objects. However, our exaination is only the beginning. We believe there is still a need for further research with real projects to yield reliable results. Our future work will focus on conducting ore experients on real projects to validate our 79