Software Revere Engineering Tool for Object Oriented Programming D.M.Thakore Department of Computer Engineering Bharati vidyapeeth Deemed Univerity College of Engineering, Pune-43, Maharahtra, India S.J.Sarde (M.Tech Student) Department of Computer Engineering Bharati vidyapeeth Deemed Univerity College of Engineering, Pune-43, Maharahtra, India BSTRCT Software quality metric play the vital role in the proce of aeing oftware a in qualitative and quantitative term. Baically, oftware quality metric determine pecific but ome important propertie, attribute or characteritic of oftware in term of number, value or ome ymbol. Thi type of aement hould be occurred according the ome welldefined meaurement rule. Software quality metric are not only the tatic meaurement tate of project but alo it will help in aeing the behavior, ize, quality and complexity etc, of oftware. Evaluation of oftware quality metric i ued to predict the fault-prone area and component of oftware in early tage of reengineering proce of exiting oftware a quality indicator. Thee oftware quality metric help to identify the problem from oftware in early tage of the reengineering of exiting oftware. Therefore, thi paper deal with automate oftware quality metric tool namely Software Revere Engineering Tool (SRET) which hould be developed to determine the different oftware quality metric and attribute of object oriented programming. Hence thee metric meaure the complexity, effectivene, efficiency of oftware and thee metric hould be ave time and cot of oftware analyzer, developer, teter etc., for reengineering the exiting oftware with le effort. Keyword Coheion, complexity, object oriented deign metric, object oriented language, oftware engineering, oftware quality, oftware reengineering etc. 1. INTRODUCTION The main objective of Revere Engineering i to increae contact, awarene and undertanding of exiting oftware. It hould be the firt tep in tranferring effective oftware reengineering procee, method, and tool into practical ue. It hould provide complete picture of the exiting ytem and what ytem mut do to atify the developer requirement and need for oftware improvement, thi i accomplihed by contructing everal model. But the quality of oftware ytem heavily depend on their tructure, which affect maintainability and readability. However, the ability of human to deal with the complexity of large oftware ytem i limited. Software metric are ued to predict critical information about oftware ytem. Object oriented oftware development require a different approach to oftware metric. Software engineer generally ue indirect meaure that lead to metric which provide a quantitative bai for undertanding the underlying information in oftware development procee. Software metric have alway been important for oftware developer to aure the quality of ome repreentation of oftware and organization are achieving promiing reult through their ue. The quality of oftware mut be defined in term that are meaningful to the uer. Generally, quality objective may be lited a performance, reliability, availability and maintainability, which are cloely related to oftware complexity. Recovering thi type of metric i the firt tep toward reengineering a oftware ytem. Therefore, Quality metric are mot important factor in oftware development. Quality baed oftware improvement i eential for the oftware proce improvement. Quality recognition mechanim and individual Quality metric are uggeted to avoid the large effort in typical meaurement of quality in project. Thu for above cae there i no uch automate tool or technique which will find out model for the ytem which determine variou oftware quality metric pecification. Propoed ytem methodology approach hould to meauring coupling, coheion (Complexity), Data cce and Operation cce Metric (Security) relie on the aumption that the attribute, method, relationhip and clae of Object-Oriented ytem are connected in more than one way. 2. LITERTURE SURVEY Quality of oftware i very important into the computer cience becaue quality i nothing but future requirement characteritic of end uer or cutomer that i in meaurable form. Baically, quality can be thoe product characteritic which meet end uer requirement and thereby, provide product atifaction. Hence, it i concluded that quality hould be contain all propertie (or characteritic or feature) and vital attribute of a product which hould atify the given requirement [1]. There are variou tandard definition of quality-1) quality contain all characteritic and ignificant feature of a product or an activity which related to the atifying of given requirement, 2) quality i nothing but totality of feature and characteritic of product or a ervice that bear on it ability in atify the given need, 3) conformation to requirement, 4)meeting uer requirement etc.[3] The important role of oftware proce improvement i evaluating the current tatu of the oftware and decide the improvement proprietie. Therefore, it hould the focu on the oftware proce improvement that require the need of oftware meaure i.e. meaurement of oftware quality metric [3]. oftware quality metric i a meaurement of characteritic (or propertie) of a oftware or it pecification. So, quantitative meaurement are eential in reengineering of 6
exiting oftware. The purpoe i gaining objective, goal, reproducible and quantible meaurement which hould be in numerical form, valuable in planning, chedule, debugging, oftware performance optimization etc. Thi i reaon for the need of evaluating of oftware quality metric of exiting oftware ytem (a part of reengineering proce) hould be required when organization (or company) i decided to make change into exiting oftware ytem. The develop ytem which hould automate and comprehenive tool which evaluate the oftware wide metric, module wide metric, attribute and hierarchical metric for object oriented program by analyzing the ource code of oftware. Software quality metric can be claified into three categorie-1) product, 2) proce, and 3) project metric out of thee claification let focu on the product metric which decribe the characteritic of product uch a ize, complexity, deign feature, performance, ecurity etc. Hence, develop a new automate oftware revere engineering tool (SRET) which hould analyze and how a a new technique of getting oftware metric from ource code of oftware ytem i.e. deal with extracting oftware metric from.cla file of java programming. 3. OUTLINE Thi paper i organized a follow. Section IV preent the related work. Section V repreent variou metric and reult. Section VI and VII preent conclude the paper by preenting reult, concluion and future work. 4. RELTED WORK Propoed approach hould evaluate oftware quality metric for object oriented program like Java, oftware quality metric are coupling, coheion (Complexity), Data cce and Operation cce Metric (Security) relie on the aumption that the attribute, method, relationhip and clae of Object-Oriented ytem are connected in more than one way. Complexity: Coupling: Low value->good and High->Bad and coheion i vice vera of coupling. Security: SDM and OPM: Low value - >Bad and High value->good So, propoed approach hould be minimize coupling and maximize coheion for reduction in complexity of object oriented programming language, DM and OPM metric hould much le a poible for greater ecurity. Fig 1: ctivity Diagram for Software Revere Engineering Tool Propoed approach hould ue ome better package which help into the aement of oftware quality metric. Thee package are pare the.cla file of Java program and eaily find out metric value. 5. METRICS DESCRIPTION ND RESULTS Conider the example of Shopping Cart for undertanding the aement of oftware quality metric from ource code of.cla file which repreent the cla relationhip a hown below in figure. Fig 2: Example of Shopping Cart 1. Weighted Method per cla(wmc) WMC i a oftware quality metric which ae the ize and complexity. It i defined and repreented a WMC = Σc i i.e ummation of no. method of c i where c i i the complexity of all variou method numbered a c 1, c 2, c n in cla C. If all method in the cla were aigned a complexity equal to 1 then the WMC for cla C would correponding the number of method in the cla. The no. of method and the complexity of the method concerned i a forecater of how much time and effort i required to contruct up and maintain the cla. The greater the no. of method in a cla, the greater the potential impact on children; children inherit all of the method defined in the parent cla. Clae with large number of method are likely to be more application pecific, limiting the poibility of reue. Example: WMC i calculated by counting the number of method in each cla, therefore: WMC for Shopping Cart = 2 WMC for Credit Card = 1 Table 1. Summary Statitic of WMC WMC 27 2 14.5 7
2. Depth of Inheritance Tree (DIT) Depth of Inheritance Tree (DIT) can be defined a depth of a cla within the inheritance hierarchy or jut like tree repreentation i the maximum number of tep from the cla node to the root of the tree or meaure no. of node from leaf node to root node of tree and i calculated by the number of ancetor clae. The leaf a cla within the hierarchy ha maximum no. of ancetor clae then the maximum the number of method it i likely to inherit making it more complex to forecat it behavior. Deeper tree include greater deign complexity, ince more method and clae are concerned, but the greater the potential for reue of inherited method. Example: Cutomer i the root and ha a DIT of 0. The DIT for Preferred_Cutomer i 1. Table 2. Summary Statitic of DIT DIT 4 1 2.5 3. Number of Children (NoC) The number of children i metric which pecify the number of intant ubclae econdary to a cla in the hierarchy. The maximum or larger the NoC value that preent it hould give a thought of the potential powerful a parent cla ha on deign. If a cla ha a huge or larger number of ub-clae, it could need more teting of it method. The larger or maximum the NoC, the larger the reue ince inheritance i a form of reue. Example: Cutomer ha an NoC of 2. NoC for Preferred_Cutomer i 0 ince it i a terminating or leaf node in the tree tructure. Table 3. Summary Statitic of NoC NoC 1 0 0.5 4. Coupling Between Object (CBO) CBO metric i a compute of non inherited communication (or interaction) between clae. CBO i calculating or aeing the number of other clae to which a cla i coupled. It i calculated or meaured by counting the number of ditinct noninheritance related cla hierarchie on which a cla depend. Extreme coupling i harmful or very dangerou to modular deign and it will prevent or prohibit to reue. The huge no. of independent a cla i, it help the eaier to reue in another application. Example: Two clae may have extreme coupling i.e. too many meage paing between them. Thi implie that thoe clae hould be combined into one cla. Table 4. Summary Statitic of CBO CBO 62 0 31 5. Repone for a Cla (RFC) RFC i one of the qualitie metric that can be defined a the calculation of the et or no. of all method in cla that can be called in reply to a meage to an object of the cla or by ome method in the cla. Thi metric how or repreent at mixture of the complexity of a cla through the number of method and the amount of interaction or communication with other clae. The larger the number of method that can be called from a cla through meage, the greater the complexity of the cla. Example: RFC for Preferred_Cutomer = 0 (elf) + 0 (Cutomer) + 1 (Credit_Card)= 1 Table 5. Summary Statitic of RFC RFC 55 0 27.5 6. fferent Coupling(Ca) Conider the no. of clae within the package on which the number of other package are depending which pecify the package' reponibility. The fferent Coupling metric find out the number of clae and interface from other package that depend on clae in the analyzed package. fferent Coupling i alo called a Incoming Dependencie. Table 6. Summary Statitic of Ca Ca 1 0 0.5 7. Efferent Coupling (Ce) The package comprie no. of clae which are depending on the other package pecify the package' independence. Efferent Coupling (Ce) i alo called a Outgoing Dependencie or the Number of Type inide a Package that Depend on Type of other Package. Ce i a quality metric for package. In hort, thi calculate or ae that include all the type within the ource of the meaured package referring to the type not in the meaured package. Table 7. Summary Statitic of Ce Ce 2 0 1 8. Coupling Factor (COF) Coupling Factor (CF) evaluate or determine the coupling between clae. Thi evaluation can be not including coupling due to inheritance. It i defined a the ratio between the number of actually coupled pair of clae in a cope (e.g., package) and the poible number of coupled pair of clae. CF i primarily applicable to object-oriented ytem. Table 8. Summary Statitic of COF COF 62 0 31 9. Data btraction Coupling (DC) The DC i metric which calculate the coupling or pairing complexity caued by btract Data Type (DT). Thi metric i concerned with the coupling between clae repreenting a major apect of the object oriented deign. Table 9. Summary Statitic of DC DC 0 0 0 8
10. Method Invocation (MIC) Method within cla are called likely a normal procedure are called. Only they have an object intance identifier i.e. OID prep ended to them. To find out which method i called, it i neceary to know the type of the method. Table 10. Summary Statitic of MIC MIC 54 0 27 11. Meage Paing Coupling (MPC) Thi metric aee or evaluate the number of meage paing among object of the cla. larger or huge number how increaed coupling between analyzed cla and other clae in the ytem. Thi make the clae more dependent on each other which increae the overall complexity of the ytem and make the cla more difficult to change. Table 11. Summary Statitic of MPC MPC 2 0 1 12. Number of Public Method (NPM) Thi metric meaure or count the number of public method declared in a cla. greater NPM value can be repreent for two variou awful condition in the deign of oftware. Firt, it can be a indication for a cla that i to complex and ha too many reponibilitie in the analyzed oftware ytem. Thi can be confirmed by looking at Weighted Method per Cla metric for the ame cla. good example for uch a ubject i the well known utility cla with all thoe method, which are ued all over the oftware ytem. Secondly, a greater NPM value can be repreent for a cla that i highly coupled with other part of the oftware, becaue each public method may expoe the internally ued clae. Or the cla act a ome kind of context, to tranfer object between everal component. Thi can be confirmed for poible candidate, by looking at the coupling metric for the ame cla, for example the Coupling Between Object and the fferent Coupling metric. Metric Table 12. Summary Statitic of NPM Max. Value Min. Value vg. Value NPM 27 0 13.5 6. COMPRTIVE NLYSIS Thi ection decribe the comparative tudy and evaluation to propoe the accuracy of propoed tool. n evaluation methodology which propoed i ued for the performance evaluation of exiting tool. Tool Coupling nalyt 53.33 Vizznalyzer 42.33 C&K Java metric 52 Propoed ytem Predicated: Below 40 Table 13 - Comparion of Performance Evaluation other tool v. Propoed Sytem Tool Functionality N L Y S t Clae NO YES NO YES ttribute NO YES NO YES Method NO YES NO YES ociation NO YES NO YES Multiplicity NO YES NO YES ggregation NO NO NO YES Generalization NO NO NO YES Intance NO NO NO YES Core prototype model Complete Model Meta Security cceibility Complexity Metric V I z z N L Y Z E r C & K J V M E T R I C P r o p o e d y t e m NO NO NO YES NO NO NO YES NO NO NO YES YES YES YES YES Table 14 Functionality upport comparion of Propoed Sytem with other tool 9
7. RESULTS Thi ection decribe the reult of propoed tool. Fig 3. Screenhot Show the Chooing the Input File From the directory Fig 4. Screenhot how the Software quality Metric value detail for the given input program. Fig 5. Screenhot how the Software quality Metric value detail for the given input Example.cla file program. 10
8. CONCLUSION ND FUTURE WORK The developed ytem i automated and comprehenive tool which meaure product metric which decribe the characteritic of product uch a coupling, coheion etc for Object Oriented program. The propoed work i fully automated eliminating the manual effort required from the developer and analyzer, further becaue of the elimination of manual work thee ytem i effective, efficient for the reengineering of the oftware which already in exitence with effective utilization of the key reource. The utomate tool i ued to evaluate the quality of the object oriented language application. The tool can be improved to evaluate other Object Oriented language uch a C++, C harp, etc., lo, it hould be enhanced for quality of oftware ytem for end uer requirement atifaction, becaue quality ha variou tandard definition. The improved appraial tool will be cooperative in aeing the quality in advance to develop awarene for quality iue uch a reliability, tetability and maintainability. 9. REFERENCES [1] hwin B. Tomar and Dr.Vila. M. Thakare, SYSTEMTIC STUDY OF SOFTWRE QULITY MODELS, International Journal of Software Engineering & pplication (IJSE), Vol.2, No.4, October 2011 [2] Ronan Fitzpatrick, Peter Smith and Brendan O'Shea, Software quality challenge, International Conference on Software Engineering (ICSE 2004) [3] S.run Kumar, T.run Kumar and P.Swarnalatha Significance of Software Metric to Quantify Deign and Code Quality, International Journal of Computer pplication (0975 8887), Volume 11 No.9, December 2010 [4] Fernando Brito e breu and Walcélio Melo, Evaluating the Impact of Object-Oriented Deign on Software Quality, Originally publihed in Proceeding of the 3rd International Software Metric Sympoium (METRICS 96), IEEE, Berlin, Germany, March 1996. [5] Comparing Software Metric Tool RudigerLincke, Jona Lundberg and Welf Lowe Software Technology Group School of Mathematic Mathematic and Sytem EngineeringVaxjoUniverity,Sweden{rudiger.lincke jona.lundberg welf.lowe}@vxu.e [6] Qualitative Evaluation of a Software Development and Re-Engineering Project Thoma Pana,RudigerLincke, Jona Lundberg,Welf Lowe Software Technology Group MSI, Univerity of Vaxjo, Sweden [7] Beyond Language Independent ObjectOrientedMetric:Model Independent Metric Michele Lanzalanza@iam.unibe.ch Software Compoition Group Univerit a di Berna, Svizzera and St ephaneducaeducae@iam.unibe.ch Software Compoition Group Univerit e de Berne, Suie [8] Qualitative Evaluation of a Software Development and Re-Engineering Project Thoma Pana,RudigerLincke, Jona Lundberg,Welf Lowe Software Technology Group MSI, Univerity of Vaxjo, Sweden [9] Development and pplication of Revere Engineering Meaure in a Re-engineering Tool S. Zhou, H. Yang and P. Luker William C. Chu Department of Computer Science Department of Information Engineering De Montfort Univerity Feng Chia Univerity England Taiwan [10] n Empirical Study of Slice-Baed Coheion and Coupling Metric Timothy M. Meyer and David Binkley Loyola College in Maryland Baltimore, Maryland 21210-2699, US {tmeyer,binkley}@c.loyola.edu [11] lhammari, Bandar and Fidge, Colin J. and Corney, Diane (2009) Security metric for object-oriented cla deign. In: QSIC 2009 Proceeding of : Ninth International Conference on Quality Software, ugut 24-25, 2009, Jeju, Korea. (In Pre) [12] New Conceptual Coupling and Coheion Metric for Object-Oriented Sytem BélaÚjházi, Rudolf Ferenc, TiborGyimóthy Univerity of Szeged, Hungary Department of Software Engineering ujhazi.bela@tud.uzeged.hu, {ferenc, gyimi}@inf.u-zeged.hu and Deny Pohyvanyk The College of William and Mary, US Computer Science Department deny@c.wm.edu [13] Revere Engineering Component Model for Quality Prediction Steffen Becker, Michael Hauck, and MirceaTrifu FZI Reearch Center Software Engineering Karlruhe, Germany Klau Krogmann Karlruhe Intitute of Technolgy Software Deign and Quality Karlruhe, Germany Jan Kofroˇn Charle Univerity in Prague Ditributed Sytem Reearch Group Prague, Czech Republic [14] n Exchange Model for Reengineering Tool Sander Tichelaar and Serge Demeyer, Software Compoition Group, Univerity of Berne, Switzerland, {demeyer,tichel}@iam.unibe.ch [15] Viual nalyi and Deign Tool for Planning Software Reengineering Martin Beck, Jona Tr umper and J urgend ollner {martin.beck}, {jona.truemper}, {juergen.doellner}@hpi.uni-potdam.dehao-plattner- Intitute Univerity of Potdam, Germany 11