sign in sign up
<<
Home , Software engineering

www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 process is the primary goal of any integration solution. integration any of goal primary the is process this of Automation providers. payment or merchants online more or one from received records on based vendor the in data of rendering the ultimately is result end The data. the manipulate and audit to required is solution the of heart the at another.logic to Business form one from data of transformation the requires purchases consumer online of details the reconcile to order online in vendor an “offline” an and together merchant Bringing . (ERP) planning resource enterprise legacy complex use that vendors (B2B) business-to-business or (B2C) business-to-consumer those for particularly challenge, maintenance and software a be can vendors multi-channel mature more of databases the into INTRODUCTION 1. Keywords product. scalable and maintainable highly a in resulting ultimately next, the upon improve to were used evolution each from learned Lessons interface. software e-commerce such one of evolutions subsequent and among data of sharing and initial the details paper This systems. integration legacy multi-channel mature large, and systems the software e-commerce modern of true particularly is This the situations. fits appropriatelyreal-world approach all defined for single no that times are there today, exist development such for and strategies models many While use. their from learned lessons the and applied techniques the to respect with evolving constantly is that process a is systems dissimilar between interfaces software of reengineering and engineering The ABSTRACT 59-78 (IJARITAC), and Technology Information on Applied of Journal International o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol commerce direct multi-channel in leader market major a of enterprise the with use for designed was solution The period. year (3) three a over enhanced and developed solution software particular a of to integratedissimilarsystems. Thispaperwilladdressthesoftwareengineeringand reengineeringchallenges efforts any into incorporated be to flexibility of amount certain a requires also It change. to paradigm this requires technologies software web-based ever-changing and the merchants online competing of proliferation However, slowly. very evolve to tend systems enterprise Typically,legacy commerce. of landscape changing rapidly the to adapt to modified be therefore must and sales mail-order and marketing direct for geared towardthe“timetomarket”ofsolution.The legacysystemsinvolvedareoftenoriginallydesigned constantly-evolving Interfacing online saleschannelswithlegacymulti-channelenterprise systemsoftenrequiresarapiddevelopmenteffort itself. effort engineering software the of process the in arise challenges for need the motivates This loose couplingoftheinterfacebetweentwoormoresystems toremovetimingfromtheequation. Additional time. real in operate necessarily not do a and in fashion, data scheduled financial procedural, related and commerce process to tend systems minicomputer-based and mainframe e-commerce storefrontsandpaymentprovidersthearchitectureoftheirmorerigidcounterparts.Older Shihong Huang, James J. Mulcahy J. James Huang, Shihong Software Reuse in the Evolution of an E-Commerce System: E-Commerce an of Evolution the in Reuse Software There isaninherentincompatibilitybetweenthemodern“alwayson”real-timearchitectureoftoday’s Integration ofanincreasingvolumeonlinepurchasedatafromrelativelyyoungweb-basedmerchants :s o f t w a r e m a i n t e n a n c e a n d e v o l u t i o n , s o f t w a r e r e u s e , s o f t w a r e s y s t e m s i n t e g r a t i o n , r e e n g i n e e r i n g , l e g a c y software systems,COBOL Science&Engineering,Florida Atlantic University Shihong Huang Shihong [email protected], [email protected] [email protected], A Case Study Case A * , James J. Mulcahy J. James , Indianjournals.com 59 www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 60 encapsulation ofsourcecode allowsforaneasiertransitiontonewcombinations ofhardwareanddatabase and/or segregation Appropriate themselves. applications individual the within level, granular more much a at code source encapsulated paper this by studied technique The contexts. future in reusable be to and Tortorella [6] studiedtheapproachofcreatingamodelortemplatewhenreengineeringCOBOL programs also encapsulated,“wrapped”[27]orotherwiseorganized tobereusablewherepossible.Canfora,Fasolino formats. file external or datasets particular to map further may turn, in that, areas storage variable standardized other include also may They structures. data external and internal to related details include may or logic business actual include may segments code These them. reference that of sourcecodearestoredinindividualfilesthatlater mergeddynamicallybycompilersintotheprograms sections that means commonly this dialect, or language programming by vary may terminology the While “includes”. or libraries” “copy external separate in stored and encapsulated be may it applications, that times new are there into “pasted” and cloned be may code such While logic. useful specifically represent that code source existing of sections reusing entail also may It applications. of callable or form standalone the entire in come may reuse systems, modern that and functionality legacy integrating of When “breaking” faults. the no had eliminate previously or reduce also can It testing. acceptance and testing unit software “trustworthy” existing, components reducesthelengthandscopeofmanyphasessoftwaredevelopmentlifecycle,including of use The [9][18]. product final the of and reliability Asecondary [5]. code source new developing when efforts duplicate avoiding by interfaces software new of development [31]. old decades is that code source working contain to systems legacy for uncommon longer entrenched assuccessfulbusinesssolutions,orsocomplexthattheycannotbeeasilyreengineered.Itisno of creation,requiringreplacement.Thisassumptionisnowlessfeasibleassoftwaresystemsbecomemore years mere within obsolete be to expected was Software concern. a of less was concept this ago, more or reengineering. of type this Aof and cost the both reduced decade code existing to changes fewer and code new of lines fewer that asserted [25] Sneed M. H. systems. when external other importance to interfaces paramount engineering of be should systems, software legacy complex large, with working when easily more be would that maintained, enhancedandreengineeredaccordingtofuturerequirements.Reuseofsourcecode,particularly solution software a produce to used were techniques Development tolerant. fault- and platform-independent highly be to code source new of creation the and code, source available WORK RELATED AND BACKGROUND 2. work. future related for prospects offers and evolutions of series the the from drawn summarizes conclusions 6 Section Finally, process. the of weaknesses and strengths the identifies and approach increasingly improvedevolutionstoscaletheresultingsoftwaresolution.Section5evaluatesengineering two by followed effort, engineering initial the details 4 Section solution. the for need the precipitated that 3 outlinestherequirementforreal-worldsolutionthatisstudiedbythispaper, alongwiththecircumstances and relatedworkintheareaofsoftwaremaintenanceevolutionlegacymodernsystems.Section ERP.common a of versions multiple using vendor different a for performed was evolution Each the re-implementationofrequisitesoftwareapplicationsusingnewhardwareanddatabasearchitectures. popular onlinee-commercemerchants.Eachsuccessiveevolutionofthesolutionrevolvedprimarilyaround several with system ERP legacy the of integration the was solution the of result The solutions. software It is also important to consider that any new software should itself be coded in such a way that it is it that way a such in coded be itself should software new any that consider to important also is It The sourcecodereusetechniqueservesmultiplepurposes.primarypurposeistosignificantlyspeed of reuse and encapsulation the process: reengineering the of areas primary two on focuses paper This study case the for background the describes 2 Section follows: as organized is paper this of rest The , but no less important purpose, is to leverage the reuse of source code in increasing the increasing in code source of reuse the leverage to is purpose, important less no but , Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 product vendor, butratherbetweentheonline merchantorpaymentproviderandtheactualvendorfulfilling INTEGRATION FOR REQUIREMENT REAL-WORLD 3. domain, advancingtechnology, desireforbusinessgrowthortheemergence ofcompetitiveproducts”[16]. that anticipatedrequirementsofsolutions,oncedeveloped,includethe“changingpropertiesoperational [24]. future foreseeable the for service in be to systems tobeevolvablecanadddevelopmentexpense,itisanecessityforlegacythatareexpected modern businessmodelsandarchitecturesbenefitfromthesetechniques[25].Whiledesigningormodifying business logic(Figure1:SegregatingandEncapsulatingbyFunctionality). Transitioning ofsystemstomore identified andsegregatedfromthecoreofinterfacethatcontainsauditingreconciliation(AAR) be can functionality This systems. operating and interfaces, user systems, file databases, to access include architectures. Thisisespeciallytrueforsourcecoderelatedtomachine-dependantactivities.Theseactivities o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol Shihong Huang, James J. Mulcahy J. James Huang, Shihong The type of e-commerce transaction given focus by this paper is not that between the consumer and consumer the between that not is paper this by focus given transaction e-commerce of type The mentioning by context this in maintenance future of topic the addressed has Lehman M. Figure 1: Segregating and Encapsulating by Functionality by Encapsulating and Segregating 1: Figure Figure 2: Flow of Data from Merchant to Vendor to Merchant from Data of Flow 2: Figure 61 www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 businesses with large legacy software systems, using business models and data organization techniques organization data and models business using systems, software legacy large with businesses for returnedproductsorcancelled orders.Thevendoristypicallysuppliedwithareconciliation filecontaining credits of form the take can adjustments These adjustments. consumer-originated other to addition in fee merchant transferssalerevenuetothevendor, ittypicallywithholdsanagreed-uponcommission orprocessing a When arena. ecommerce the into expanded have that companies catalogue-based and marketing direct that canbefarlessflexiblethantheirexpandinginternet-based partners.Manyofthesevendorsareexisting 3.1.2 trading when party other the of format information [21]. data proprietary internal the of aware be directly to merchant manner,this In time”. “real in activity transaction for waiting system and vendor the for necessary not is it to decouplethe“always-on”provider/merchantfromactualvendor, whomayornothaveasoftware serve FTP and SOAP as such techniques Data-sharing providers. particular these with data exchange to entities thatusethisformat.TheimplementationofthesolutionstudiedbypaperusedFTPtechnique of examples are Checkout™ Google and Paypal/eBay form. (CSV) are comma-delimited in created documents typically These vendor. the by intervals scheduled at or demand” “on retrieved reconciliation be which can from documents servers FTP more or one of use the is technique Another interface. the using study, theSOAP/XML solutionwasusedtoestablishaconnectionbetween Amazon.com andthevendor(s) case this In data. such communicate efficiently to provider online and vendor the allows that is established schema XML standard A information. financial and confirmation fulfillment, documents order,XML of appropriate validation with and delivery the for framework a provides architecture This vendor.by maintained the and owned is One that server ways. (SOAP) of Protocol Access Object variety Simple a a of in use vendor the is the example and merchant the between delivered is data The formats. (CSV) often withfilescomposedinthenow-familiareXtensibleMarkupLanguage(XML)andcomma-delimited providers, fulfillment and vendors between data of exchange ready the for provides technology modern of community.use e-commerce The the of age young relatively the to largely due is This systems. hardware 62 3.1.1 [22]. PayPal and Checkout™ Google include type this of Examples process. billing actual the handles and consumer the from data payment card credit and purchase collects provider payment online of this type of interaction include Amazon.com and eBay.com. Another type of interaction occurs when an Examples products. purchase and for shop to consumer the by used website internet an of form the takes handling oftheinitialinteractionwithandpaymentbyonlineconsumer. This typeofinteractiontypically commerce channelswhilepayingonlineorotherwiseremoteprovidersacommission-basedincomeforthe Relationship Vendorand Merchant 3.1 Amazon.com, Paypal. included and Checkout™ that Google providers online and system enterprise legacy the between exchanged data a specificrequirementfortheinterfacetoautomaticallyhandlereconciliationofhighvolumefinancial was There systems. software enterprise commerce direct multi-channel in leader market well-known a for [33]. Thissectiondescribesonesuchreal-worldmerchant-vendorrelationship.Thesolutionwasimplemented consumer the to goods the ships who vendor the than other party a by handled be to transactions financial the ordertoconsumer(Figure2).Itisincreasinglycommonforinitialpurchaseinformationandsubsequent edr ta poie ucae ies o h cnue ae fe mtr mlicanl commerce multi-channel mature often are consumer the to items purchased provide that Vendors Internet merchants and online payment providers typically use more modern, flexible software and software flexible modern, more use typically providers payment online and merchants Internet ih urn tcnlg, edr ae be o akt o n drv sls rm vrey f external of variety a from sales derive and to market to able are vendors technology, current With The Online Merchant Online The The Legacy Vendor Legacy The Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 the software tasked with developing the initial solution. It will also provide details of each of iteration. details next the on provide effects their and also outcomes the describing will evolution, subsequent It solution. initial the developing with tasked engineers software the with futuremaintenanceandscalabilityinmind.Thissectionwillfurtherdetailtheproceduresfollowedby maintenance taskswerealsoperformedtoadjustandimprovethebusinesslogicsoftwaredesignmodel architectures, environment new to components software the of reengineering the to related largely While solution studiedbythispaperprogressedthroughaseriesofdevelopmentiterationsafteritsinitialdeployment. SOLUTION THE IMPLEMENTING 4. applications. contains overonemillionlinesofCOBOLandCsourcecode,makingupmorethan1800individualsoftware repository software the and databases, (11)distinct eleven least at includes It writing. this of as old years (14) fourteen over is paper this by to referred system a enterprise The to system. transaction enterprise legacy the particular of side one on anchored remaining while merchants online different several handle to required ultimately was study case this by described interface The personnel. accounting by attention process. Theseproblemtransactionscannotbeautomaticallysettledbytheinterfaceandthusrequiremanual in Figure2.Further, itisimportanttoautomaticallydetectandsingleoutanytransactionsthatfailtheauditing and postingoftheappropriatevaluestoaccountingareasvendor’s enterprisesystem,asillustrated less and efficient error-prone. Thestakeholdergoalisfortheintegrationsolutiontoaccuratelycarryouttasksofauditing more process the make to interface reconciliation and auditing automated thean for arises need requirements processing in increase the From sales. for potential the and exposure marketing increasing vastly clock, the around business for open are example, for storefronts, Internet-based venues. sales catalog and brick-and-mortar,telemarketing typical the beyond channels commerce new of addition the from come can volume increased The vendor.quickly the for become error-prone to and time-consuming data cumbersome, financial reconciling of process manual the causes volume sales Increasing Integration for Requirement 3.2 order.the of reconciliation the completing thus datasets, financial appropriate the to write-offs commission and payments the of posting the is step final The database. own vendor’s the in records with information order the reconcile to able then is vendor The calculations. accurate verify to merchant, the the merchantandvendor. Fromthereconciliationdata,vendorisabletoauditamountssuppliedby by upon agreed frequency other be any weekly,or to may hourly from vary file can that intervals This vendor.regular at available the of behalf on merchant the by handled transactions of details monetary the o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol many integrationprojects. Data thatisgeneratedorconsumedbyasystemmay notbeofficiallypublished of nature opportunistic the from largely arises This systems. software unrelated previously or dissimilar of no thus and stream, data integration the of typical is shortcoming This specification. formal a designing spent was effort significant inbound expected the describing Little onset minor. the relatively from be available to was expected documentation were manner this in found model business the software. to the Exceptions to modification requiring conditions unexpected any expose adequately would merchant is typicalofestablishedsoftwaredevelopmentmodels. Itwasanticipatedthatlivedatafilesfromtheonline The solutionwastobedevelopedwithouttheprotracted andthoroughspecificationanalysisphasethat was solution The (Amazon.com). merchant specifically designedfortheMicrosoft Windows operatingsystemusing Microsoft’sonline SQL Serverdatabase. single a for interface an requiring vendor single a Vendor and Merchant Single – Evolution First 4.1 Shihong Huang, James J. Mulcahy J. James Huang, Shihong The first evolution of the merchant-vendor interface was to be implemented as a custom solution for solution custom a as implemented be to was interface merchant-vendor the of evolution first The software the partners, online its and vendor the of requirements and demands evolving the meet To 63 www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 They resulted in fewer resources required to research and address logic problems found during the during found problems logic address and research to required resources fewer in resulted They logswouldlaterprovide detailenablingefficientidentificationandre-creation ofdataandlogicerrors. designed tobeleftimbeddedinthedeployedsolution withoutaffecting itsperformanceorcomplexity. The and diagnosis.Thefunctionalitywaseasilyactivated anddeactivatedbydevelopersusersalike.Itwas to theconsoleandwrittenalogfileatexecutiontime. Thisallowedforinstantaneousordelayedreview variable valuesandlogicpathswhiledevelopingthesoftware. Thedataproducedbythiscodingwasdisplayed locations, key mark visually to imbedded initially was coding diagnostic This solution. the of components and problems all software. of the log to a changes and required dependencies that code enhancements source and data of lists logic, business the verify to phase. Othermoregranulardetailswerealsorecording, includingdatarelatedtospecificunittestsperformed software engineers.Detailsthatwererecordedincludedtheamountoftimeconsumedbyeachdevelopment 64 4.1.2 application. resulting the to code source of AAR the by modified and accessed be to component. Copylibrariesreusedfromtheenterpriserepositoryaddedapproximately3,700additionallines were that datasets system legacy (7) seven the to related specifically code source contained libraries copy The libraries”. “copy new several and application new solution. the develop to needed information the derive to developers the allowing data, itself. Theupstreamproviderofthereconciliationtransactionssuppliedseveralfilescontainingcurrent“live” data the from derived were format data the of details case, this In [8]. goals and hardware, approaches similar in with application familiar more the as same the conceptually is software in engineering Reverse documentation. official available of lack the to due developers the by engineered reverse were stream data acceptable an considered was dependency accordingthecustomnatureofthissoftwaresolution.Manydetailsrelatedtoincoming this but system, enterprise legacy the with coupling tight a created reuse that datasets legacy to data of were tobequeriedandmodifiedbytheauditingreconciliation(AAR)componentofsolution.Code mapping the to related was code source reusable the of Much language. (Figure 3).Thischoicealsotookadvantageofthewell-establisheddataprocessingstrengthsCOBOL system commerce legacy the of repository software existing the from available code source of reuse the 4.1.1 combination. merchant-vendor particular a for for solution software the implement to other operatingsystemsordatabases.Indeed,thefirstevolutionwasconsideredaone-timecustomsolution plans initial no were There them. between interfaces the affect One ormoreofthepartiesindependentlyevolvetheirownbusinesssystemsovertime,whichmayattimes These typesofinterfacesoftenrequireregularmaintenanceandmodificationthelongertheyareinservice. “disconnect”. this to immune not are systems vendor and behave merchant integrating to interfaces expected Financial or [16]. documented is it how and behaves actually software how between disconnect or lag a be often can there expand, and evolve systems modern. these and As legacy both systems, merchant organizations allovertheworldcannotbecompletelyspecified.”Thiscanespeciallytrueofhigh-volume to expected is that and businesses system in use regular in software the the of “Most time. of over content and form in artifact changes experience internal an often is it Instead use. external for documented or Documentation was further augmented by the coding of a logical “trace layer” into all software all into layer” “trace logical a of coding the by augmented further was Documentation the by documented was release final the through inception from process development software The Development included more than three thousand (3,000) lines of new source code, in the form of one of form the in code, source new of lines (3,000) thousand three than more included Development enabled language of choice The language. programming COBOL the using coded was solution The Engineering the Solution the Engineering Documenting the Process the Documenting Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 of testingwiththisdata.These faultsrequiredfrequentchangestothebusinesslogic aftertheinitialrelease. files astheybecameavailable fromthemerchant.Moreunanticipatedconditions wereidentifiedasaresult data “live” with tested subsequently was interface The . the in involved parties the by anticipated spent been have to found was overage been not the had faults resulting The model. logic business initial the in of deficiencies resolving and addressing Most followed. that requests change many the to due 4) the totaldevelopmenteffort. However, inexcessof110 hourswereinvestedaftertheofficial release(Figure product. final the of deployment and acceptance vendor the of delay significant in resulted ultimately The lackofresourcesexpendedbyboththevendorand thedevelopersduringearlystagesofproject modifications. post-release of number significant a of form the in shortcuts, these for pay to price a was there However, requirements. project specifying and planning spent time minimal the to due accelerated future measurement of the successes and failures of the project. the of failures and successes the of measurement future for allowed evolution this during generated documentation the of detail of level The period. month (11) to thesoftwarewouldbenefitfromtheselogs,especiallyduringregressiontestingandredeploymentphases. testing addedtotheusefuldocumentationofsoftwarecomponentssolution. Any futuremaintenance issues. corruption data and crashes program reducing significantly by code designedtotrapallpossiblelogicerrorconditions,greatlyincreasedthefaulttoleranceofproduct development, unittestingandintegrationphasesoftheproject. The tracelayer, coupledwithsource o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol 4.1.3 Shihong Huang, James J. Mulcahy J. James Huang, Shihong The developmenttimeconsumeddeliveringtheinitial applicationaccountedforonly37%(65hours)of were project the of stages development initial the that showed project the of analysis Post-release The total development effort of the first evolution of the software spanned 175 hours over an eleven an over hours 175 spanned software the of evolution first the of effort development total The integration and unit during logs of Capturing benefits. documentation additional provided logs Tracing Understanding the Results the Understanding Figure 3: Combining New and Reusable Code Reusable and New Combining 3: Figure 65 www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 times the effort originally estimated, and the target date was pushed and missed several times. several missed and pushed was date target the and estimated, originally effort the times (12) dozen a modified was software (3) three nearly consumed solution of the Development condition. logic unanticipated an repair to each times, time, this During client. the by accepted version final the and post-release acceptanceperiod.Inexcessofnine(9)monthselapsedbetweeninitialreleasethesolution and using the SQL Server database. The new solution was to be scaled to add support for multiple online multiple for support add to scaled be to was solution new The database. Server SQL the using and departure fromtheinitialimplementation, whichhadbeendeployedupontheMicrosoft Windows platform HP3000 platformusingthe TurboImage databaseand theMPE-iXoperatingsystem. This wasasignificant an on operation in and installed was system enterprise vendor’s The architecture. database and hardware system andcommunicatingwiththesameonlinemerchant. Thesolutionwastobedeployeduponadifferent for adifferentvendorthanthefirstevolution.The wasusingthesamelegacymulti-channelenterprise implemented be to was iteration new The first. the of deployment successful the on based merchantvendor be to the interface of version newer a producing with tasked later was provider solution software The Migrated and Scaled – Evolution Second 4.2 during volumes. “live”order to processed the of scalability successful the demonstrating period, this been have orders thousand hundred the Several vendor. to the subsequent by solution reported the been of have acceptance problems No software. resulting the of stability overall the was period release and development extended paper.the this Mitigating of writing the of as vendor the by use in still is solution software resulting The solution. another of favor in scrapped nor canceled neither was 66 4.1.4 vendor. the for week per orders Amazon-originated the deploymentofasoftwareinterfaceabletoautomateauditingandreconciliationseveralthousand While thesuccessfulimplementationofsolutionwasdelayedseveraltimes,endresultultimately functionality.tracing logic described previously the by possible made was This identified. was fault new each as code the of versions patched of release quick relatively the by mitigated was effort additional The The initial evolution of the product can be technically considered a failure, if based on the extended the on based if failure, a considered technically be can product the of evolution initial The The resulting implementation of the software solution was, however, deemed successful. The project The successful. deemed however, was, solution software the of implementation resulting The Evaluating the Results the Evaluating Figure 4: Distribution of First Evolution Resources Evolution First of Distribution 4: Figure Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 coded data transformation module (DTM) from a standard XML format determined by Amazon into the into Amazon by determined format XML standard a from (DTM) module transformation data coded format. input standardized required the into formats merchant inbound various transform to needed as created be could programs mapping component. data AAR of number Any the to changes complicated for need the without interface the to added easily more be to merchants other for support future enabled format input standard a manner.Establishing this in preserved was component main the of nature AAR box” “black stable, merchants. The additional handle to scaled or platforms other to reengineered be to again was solution the if even changes, future fewer require would interface the that fileswere writteninthisformat.Isolationofthebusinesslogic intoalargelygenericmoduletheoreticallyassured output non-report any and established, been had interface the by required fields data all containing were designedtobesimpleinbothformatandcomplexity, aswastheuserinterface. A standardfileformat 4.2.2 process. AAR main the from formats merchant various the decoupling by component, processed AAR the be to was that data input for format internal generic, a establishing to related largely were the of logic business core interface. Supportformultiplemerchantscausedsomeredesignoftheoriginalsoftwaremodel.Thechanges actual the affecting without future the in replaced or modified copied, easily and segregated otherwise were documented withprogrammercommentsimbeddedintothesourcecode.Thisallowedlogictobemore manner above the in encapsulated not variables and Logic interface. libraries Copy the of evolution original interface. the in as manner same the in merchantvendor reused were repository software enterprise the from the of evolution second the by repeated was reuse for This component. design AAR the by used and referenced turn in were libraries copy These libraries. copy into designed theoriginalWindows-based versionusingamethod thatsegregateddatabase-relatedsourcecode required componentinputandoutputbeinghandledgenericallybytheJCLatexecutiontime.Thedevelopers with evolution, previous the than box” “black a like more behave to application the allowed This system. the application itselfandhandledattheJobControlLanguage(JCL)levelthatisnativetoMPE-iXoperating from decoupled was component (AAR) reconciliation and auditing main the for logic interface user The changes. minor only with version newer the in reusable be to expected was code source the of much online purchasesfortheoriginalvendorbytimedevelopmentofsecondevolutionbegan.Therefore, model. design successful previously the on based code source new of creation the enabled also It the of level allowed foreasieridentificationofadditionalreusablesourcecode,withoutextensiveresearchandanalysis. expertise high was the what on of strong based a required forthenewevolutionandwhathadalreadybeenaccomplishedinfirst.Thisdomainknowledge was had project the of decision members the The platform. of newer the Part with members base. project a as code source Windows-based based sourcecode.Thedecisionwasmadetoreengineerthepreviouslydevelopedsolutionusingoriginal anew withanewsoftwaredesign,ortosalvageasmuchofthelogicpossiblefromoriginal Windows- 4.2.1 project. the of months several extensive reengineering.Theaddedfunctionalitywastobeimplementedinmultiplephasesspreadoutover was crucialthattheexistinginterfacebeabletoprocessreconciliationdatafromadditionalmerchantswithout It for Amazon. support existing the to addition in Paypal), Checkout™, (Google providers and merchants o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol Shihong Huang, James J. Mulcahy J. James Huang, Shihong This particular implementation supported Amazon.com input. Data was transformed by a separately a by transformed was Data input. Amazon.com supported implementation particular This files output and Input possible. as flexible yet generic as be to designed was software interface The The originalbusinesslogicwasautomatingtheauditingandreconciliationofseveralhundredthousand start and solution custom original the scrap to whether was evolution second the of focus initial The Anticipating Future Evolutions Future Anticipating Reengineering the Solution the Reengineering 67 www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 to datasets in the legacy ERP system. ERP legacy the in datasets to copy libraryfiles,asinthepreviousevolutionofproject,werelargelyrelatedtomappingvalues were reusedfromcopylibrariesalreadyavailablethelegacyenterprisesystemrepository. The individual the sourcecodeofsolutiontoover9,200linesneworreengineeredcode. Approximately 3,700lines 68 4.2.3 evolutions. subsequent of efficiency the to adding identified andimplemented.FuturechangesarealsounlikelytoaffectanyoftheindividualDTMs,further easily are changes any application, interface the of design to Due system. operating or database different a to solution the of migrating the to related be likely would solution the of area this all. to at changes if Any rarely,change to expected was interface primary The product. the of reengineering future efficient the for DTM tosupportamerchantusingsimilardataformat(i.e.XMLorCSV).Thesetechniquesalsoallowed new a developing for framework or basis a as used be could DTM existing an Indeed, modules. to existing similar tasks transformation data perform would DTMs new necessary.Any where DTMs additional of creation the with solution the to added easily rather are merchants Other solution. the of value business enhanced and scalability future the the for allowed of interface the components of evolution SOAPthis of and design The FTParchitecture. the contain servers These servers. services web vendor’s the by Figure 5illustratesthegeneralflowofdataintoenterprisedatabaseonceitisreceivedfrommerchants be genericallyprocessedbythe AAR componentusingappropriatebusinessrulesthatapplytoallmerchants. then could format this in data The format. internal standardized same the to data (CSV) comma-delimited map to DTMs additional two required merchants these Google for files were input The interface eBay/Paypal. and the Checkout™ by supported Also component. AAR the by required format internal generic Implementation of the interface application for the new platform and merchant combination increased combination merchant and platform new the for application interface the of Implementation Evaluating the Results the Evaluating Figure 5: Multiple Merchant Architecture Merchant Multiple 5: Figure Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 to the Microsoft Windows and SQL Server database architecture. The auditing and auditing The architecture. database Server SQL and system operating Windows Microsoft the to 4.3.1 solution. the into integrated be to need would and component, AAR the for desired also were requirements stakeholder New evolution. original the of details system-specific operating second and database-specific the the with from software the logic of business evolution newest the combine would it Instead, another. to architecture database cost-effective solution.Theresultingsolutionwouldnotmerelybeadirectconversionfromonehardware/ most the identify to efforts research on less and managers project and developers the of opinion expert the on heavily rely case this in would project the reengineer or outsource replace, to decision software The prototype. or specification detailed a develop to time little left again This days. (30) thirty approximately within testing integration for due be would solution software the that was evolution pressing this for most requirement The platform. Server Windows/SQL Microsoft original the on re-implemented be would more recentbusinesslogicmodeldeployedintheversionbasedonHP3000MPEiX/ TurboImage platform Efforts of Combination – evolution Third 4.3 another yet the with realized evolution oftheproduct. significantly more be to was solution integration merchant-vendor the of has evolution second application the of result core successful The writing. this the of as purchases and of thousands of solution, tens processed the of deployment since reported been have requests change or bugs software No client. the by acceptance to subsequent product the by exhibited stability the on based be recreatedbytheexaminationofsourcecode.Theimplementationwasultimatelyconsideredasuccess to aidinfuturemaintenanceandevolutionrequirements. Any losttechnicaldocumentationcouldtheoretically the solution.Thesourcecodealsocontainedextensiveprogrammercommentsdescribingbusinesslogic, the self-documentinglogictracelayerthathadbeendesignedandimplementedduringfirstiterationof Isolation ofstaticsourcecodeaddedtothefuturemaintainabilityapplication,asdidinclusion future efficiencyofanymaintenancerequirements,addingtothebusinessvalueandlongevitysolution. insure to undertaken were they solution, the of iteration this by consumed time of length to added efforts to theadditionalforward-lookingeffortsappliedprogrammingmodelduringdevelopment.Whilethese - evenmoresothantheoriginalevolutionofapplicationitisdifficulttocharacterizeasafailuredue a departurefromtheprevious version,whichaccomplishedsuchinteractionatthe JCLlevelontheHP3000/ was This processed. be to AAR file new input the of The name the for platform. user the prompt new to required be the would component for interface user the to related was requirement additional second A purposes. forwarding or reporting printing, reprocessing, for files output the consume to developed be developed togeneratetheinputfilesconsumedby interface. Additionally, downstreamprocessescould using popularspreadsheetprogramslikeMicrosoftExcel. Itwouldalsoallowforupstreamprocessestobe allow datatobemoreeasilyprepared,viewedormanipulated asneededbyaccountingdepartmentpersonnel (CSV) formatratherthanthefixed-lengthimplemented inpreviousiterations.Thisnewformatwould the auditingandreconciliation(AAR)componentwere tobereadandwritteninastandardcommadelimited by processed files output and input all that was requirement new first The platform. in change a to related typically requirements with along integrated be to were requirements user evolution. Additional previous the by supported as eBay/Paypal) Checkout™, Google (Amazon.com, merchants three same the support reconciliation businesslogicwouldneednomajorchangesforthenewevolution.Thesolutionalso o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol Shihong Huang, James J. Mulcahy J. James Huang, Shihong The third evolution of the interface required a combination of the previous two iterations. That is, the is, That iterations. two previous the of combination a required interface the of evolution third The planned initially than resources more consumed interface merchant-vendor the of evolution the While The primarythrustofthethirdevolutionwastoreengineerHP3000/MPE-iXversionsoftware Integrating New Requirements New Integrating 69 www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 70 effort. reengineering the by introduced been the to related Problems platforms. between logic business logichadbeenpreviously identifiedandaddressedinpriorevolutions, nonewlogicerrorshad business the of transparency the to due tests unit the reuse ofinformationsavedsignificanttimeindeveloping thenewsolution.Fewproblemswerefoundduring 4.3.3 platforms. between transparent relatively any components access these making directly databases, not did DTMs The component. AAR the reengineering dialect while language identified programming differences same the to related specifically were changes These changes. minor result. stable more a for allowed process and implementation the improved further This static. remain would code source the of bulk the that meant This platform. the of independent be to designed previously been had logic Other version. new the systems. operating Windowsand of typical is that standard platform-independent aspossible.Filenamestructureswereredesignedtohandlethelongerpath+filename as it keep and interaction the of the a reduce to as order in designed session answer” was and “question interface simple user The language. programming same the of converting between when found software commonly those were and minor were differences Dialect structures. name file These component. AAR main the differences wereprimarilyrelatedtoprogramminglanguagedialectsandcompilers,theuserinterface, in differences platform-related any recode and identify next to The was evolution. this step by accessed be to datasets new several the support to required coding new any reused be for model a as serve also would thus repository original the from reused code could The changes. significant no with datasets these to related code source The evolution. first the by deployed solution Windows original the in accessed were datasets same the of Many database. system’s commerce legacy 4.3.2 solution. the of iteration previous the by supported merchants the of three all from data reconciliation was usingthesamelegacymulti-channelenterprisesystemaspriortwovendors,andwouldbereceiving the Microsoft Windows platform, usingtheSQL Serverdatabase. The vendorrequestingthesoftwaresolution on reside would version new The 3000/MPE-iX.) (HP evolution recent most the by established model the the of evolution application (Microsoft first Windows/SQLthe Server),thebusinesslogicandstructureofsolutionwouldfollow by established model the follow to were techniques access database actual the While product. stable highly a of development rapid for allow would reengineer and reuse to that choice this anticipated was It solution. new the produce to evolutions prior the of each from merged was Code component. main the from decoupled later be to with automated be “batch files”ortimedscriptswithoutaffectinglater the AAR component,successfullyallowingtheuserinterface could information requisite the of Entry interaction. generic and simple a be to designed was it component, new the to server.interface user the re-couple would evolution new the While application the as acting machine the by accessible anywhere reside could that name file a entering user MPE-iX platform.Onthe Windows platform,thiswouldatleastinitiallybeaninteractiveprocess,withthe Unit tests were derived from test cases developed during the previous evolution of the interface. This interface. the of evolution previous the during developed cases test from derived were tests Unit relatively with platform new the to migrated were (DTMs) models transformation data the of Each The primarybusinesslogic,parsingofinputfilesandgenerationoutputneedednorecodingfor the in accessed be to datasets the of each identify to was stage implementation the in step first The base. code source the as evolutions previous using software the reengineer to made was decision The Reengineering the Solution the Reengineering etn ad ouetn te Solution the Documenting and Testing Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 the auditingandreconciliation process. Additional faulttolerancewasrealized fromthetechniqueofisolating of flexibility the to added capability necessary.feedback if This time, later a at input as data output the of were writtentooutputfilesinthesamestandardCSV formatastheinputfile.Thisenabledreprocessing would theoreticallyautomaticallyprocessmostorders without theneedforuserintervention.Rejectedorders processing. Theapplicationwouldcontinueprocessing withthenextpendingtransactionandinthismanner the mainconsoleoruserdisplay. Any errantrecordswererejectedandwrittentoerrorfiles forlatermanual to as well as file, text line-sequential standard a to logged and trapped were errors logic Recoverable files. output write to attempting while disk) hard (e.g., media storage full encountering component the be would example database. Another remote a to connection a establish to component’sinability the include would if acriticalfilesystemeventoccurredinanunrecoverable context.Oneexampleofthistypetermination Tolerance Fault Establishing 5.1 and maintainable. personnel andsystemdomainknowledge.Thedesiredsolutionwasexpectedtobebothhighlyfaulttolerant The conditions. logical unexpected to development andmaintenanceoftheresultingsoftwareneededtobeasefficientpossiblegivenavailable due crashing without time a at records of thousands process 5. EVALUATING5. market. to time its speeding further solution, the of phases deployment and testing integration pending the of efficiency the aided effort This testing. subsequent for data of up”) (“mocking activities These preparation the in project. invested was phases. time documentation Additional and the testing to related largely of were stages latter the during consumed was evolutions. time previous the than of less much Proportionally,significantly days, (32) thirty-two over hours (110) ten and hundred one approximately spanned interface the of evolution this of entirety The lines. 14,000 over just to 1%, than less increased had (LOC) code source of lines resulting the completion, Upon module. reconciliation and auditing main the from separate components transformation data external with supported were merchants Variouspersonnel. human by processing manual require otherwise would that activities order other and returned credits costs, commission posted It orders. appropriate to revenues the allocate properly needed operations and decisions complex many performed application the of workings box” “black vendor.The 4.3.4 release. its since vendor recent most the by reported been have problems no and success, significant a considered was solution resulting The and documentationphaseswerecomplete,theprojecthadconsumedonlyslightlymoretimethanestimated. testing development, the Once vendor’sdatasets. the financial to posted amount total the and rejected, and processed orders of number the including , execution program contained file log program’sThe activities. the of log a with along emailed, or printed subsequently be reconciled could and reports rejected These both transactions. of reporting the included that interface the by generated were files Output layouts. field and formats file the of details specific included both descriptions The files. described data output and input documentation User servers. database remote or local on located sources data ODBC to Technical engineers. documentation describedtopicsrelatedtotheinstallationandsetupofsoftwareitssubsequentlinking software the by provided were documentation usage day-to-day and technical o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol Shihong Huang, James J. Mulcahy J. James Huang, Shihong The main auditing and reconciliation component had been designed to terminate in an error state only state error an in terminate to designed been had component reconciliation and auditing main The An importantfocusinthedevelopmentofthisproductfromitsinceptionwasabilitytoautomatically This third evolution of the merchant-vendor interface was designed to be as simple as possible for the for possible as simple as be to designed was interface merchant-vendor the of evolution third This Documentation for the solution targeted the casual user and was simple and straightforward. Both straightforward. and simple was and user casual the targeted solution the for Documentation Evaluating the Results the Evaluating THE APPROACH 71 www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 72 solution the of (LOC) code source evolutions. third and second the between of rate lower markedly a by but evolution, new each with lines increases total the that shows 6 Figure consumed. resources in spike the of context the consider to important is it case, this In 6). evolution (Figure evolution first second the to compared the when of time development in increase apparent the by misled be to easy is it that shows Results Canonical Analyzing 5.3 product. software evolving steadily a of improvement iterative of cycle the continued evolutions two first the in established model design and concepts the Using evolution. third the of time deployment and development the speed significantly to proved solution the of evolution with nomajorchangestothebusinesslogicordataformat.Thelessonslearnedandleveragedinsecond efforts. reengineering further anticipate to design software the to made were Modifications success. similar with evolution second the in repeated were evolution first the in introduced evolutions” toaddsupportforeachadditionalmerchant.Thedocumentationandlogictracinglayerapproach “mini multiple of form the took effort This solution. to added efficiently be to merchants online more for the of redesigning the and architecture software database for scalability.and Thehardware latterthe effortnew wasboth intendeda toinvolved increasefor the software businessproduct valuethe of thethe solution,of allowingof evolution reengineering second The code. source the in layer trace diagnostic a efforts ofthedeveloperstothoroughlydocumentengineeringprocess,andpartiallybyimbedding the by mitigated partially was shortcoming This model. design software initial the affected partially least at have would foresight Such product. the of reengineering or scaling future for made been had plans No Evolution Each Improving 5.2 evolutions. future of efforts integration in reduction dramatic a for allows This merchants wouldhavelittledirecteffectonthestaticbusinesslogicrelatedtovendorenterprisesystem. components ofthesolution.Futureevolutionstoreengineersoftwareforadditionalplatformsandonline slowly-evolving businesslogicfromthemoredynamicuserinterfaceandever-changingdatatransformation Comparing thedevelopmenttimeofeachthreemajorevolutionssoftwaresolutioninitially The thirdandmostrecentevolutioninvolvedstrictlythereengineeringofinterfacetoanewplatform, The developmentofthefirstevolutionsolutionlackedsignificantspecificationandanalysiseffort. Figure 6: Comparison of Evolutions of Comparison 6: Figure Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 software in this project was the reuse of existing source code and . However, there were there However, design. software and code source existing of reuse the was project this in software expended unit-testingtheresultingapplication. time the reduces subsequently this and frequent, less is errors logic new of Introduction processes. related database- established to related code source of true especially is stability.This system in increase an and time development in reduction a both to contributes code source existing of Reuse vendor. the by hosted system enterprise legacy the of repository software the from code source of reuse the was significant most Failures and Successes the Identifying 5.4 combination. database and hardware new a for product the of reengineering the to limited strictly were Changes solution. the of architecture overall the to changes no were there evolution, final the In platform. new a to migration the than complicated less far task a merchant, additional an support to coding new only The involved evolution second the of stage third misleading. be also would comparison a such that noted be should it evolution, second the of stage introduced. Whiletheresourcesexpendedduringthirdevolutionexceededthoseby was scalability merchant where evolution second the of stage each of efficiency increasing the illustrating platform-to-platform reengineeringactivities. support adding for additionalmerchants.Thesestagesincludedmodificationtothesoftwaredesignitself,ratherthansimple software, the scale to intended were two next the while architecture, hardware/database new the to software the of reengineering the to related largely was stages three the of first The 7). (Figure interface. and deployingnewiterations.Itisanticipatedthatthetrendwillcontinuewithsubsequentevolutionsof product. Inthiscontext,“highlyevolvable”translatesintothequantifiablereductionofeffortspentdeveloping to thefirsttwo.Combined,theseareindicatorsofsuccessfulengineeringahighlyevolvablesoftware The figurealsoshowsthatsignificantlyfewerhourswererequiredtodevelopthethirdevolutioncompared o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol Shihong Huang, James J. Mulcahy J. James Huang, Shihong One of the most important aspects of the successful implementation and subsequent evolution of the of evolution subsequent and implementation successful the of aspects important most the of One the Arguably project. this of success the to contributed process development the of aspects Several The figureshowsmoreaccuratelytheincreasedefficiencyofeachsuccessiveevolutionsoftware, The second evolution is more accurately characterized as having three separate development stages development separate three having as characterized accurately more is evolution second The Figure 7: Decomposition of the Second Evolution Second the of Decomposition 7: Figure 73 www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 74 saved. are than resources more consumes ultimately integration software new a of onset the at original developmenteffort,perhapsillustratingthatskipping crucialsoftwaredevelopmentlifecyclesteps the than resources in costly more be to proved This refined. were details data and rules business the which neither expectednorplannedfor. This resultedinasignificantpost-releaseperiodofchangerequests through were efforts reengineering future project, the of onset the At requirements. reengineering and scalability future for plan to performed was that recoding extensive the in and software, the of evolution first the to required later.often Inthe projectstudiedbythispaper, thecostscameinformofadozenpost-releasepatchesapplied is effort additional remarkable a that is reality the cost-effective, or reasonable tempting, that whilereducingoreliminatingtimespentplanningandspecifyingasoftwaresolutionmayattimesseem conclude can one deployment, recent most and third the through inception from approach the Evaluating scalability.additional for allow to code source the of modification later required also of It number requests. significant change a to due solution the of deployment initial the hampered this project, the in Early minimal. were project the of evolution each of phases analysis and specification the to allocated time of this by described project The paper helpedhighlightaparticularshortcomingthataffectedtheearlyevolutionsofproject.Theamount shortcomings. or failures the from learn and identify to crucial equally is it model, development software particular a of successes the leverage and identify to important is it While need toretestallsupportedmerchantswhenimplementingchangesrelatedtheformatofonlyonemerchant. the eliminates also It decoupling process. stable and static otherwise This an into errors new of component. introduction the eliminates reconciliation and auditing main the to necessary No be data. merchant’swould that modifications processing with tasked module transformation data particular the only affect is delivered(i.e.,changingfromanXMLtoCSVformatorviceversa).Thesechangeswouldtheoretically data the how change completely or format, data their to fields noncritical remove or add may Merchants further is realized whencontemplatingfuturechangesmadetothedatastreambyindividualmerchantsorproviders. decoupling of type this of advantage The component. reconciliation and auditing main the by processed being to prior format internal generic a into transformed be to data inbound the allowed design This data. financial incoming the of providers with coupled loosely be to designed was interface vendor merchant- the deployed, was it which upon architecture the to and system enterprise legacy vendor’s the nature ofthesolutioncontributedtosuccesseachevolutionsoftware.Whiletightlycoupled benefit ofthesetechniques,contributingtotheoverallsuccessproject.Finally, the“looselycoupled” noticeable a itself. effortswas logic testing business regression the and effectAon unit direct in reduction no having while flexible more be to architecture the allowed This data. reconciliation the of provider the prior todeployment. from theestablishingandverificationofunitteststoefficientidentificationrepairsoftwareerrors activities, development other in aid further to proved It overall. solution interface the of and component each of documentation the in aided further components software the into layer tracing version. logic a successive Imbedding each for time development of reduction the in resulted This model. design software the of improvement iterative the in useful was engineers software the by level granular appropriately an at the development processthatcontributedtothesuccessofproject.Documentingeachevolution of aspect another were efforts Documentation mind. in evolution future with interface the of coding deliberate the and documentation, tracing logic and process the formats, data standard of use the model, other traitsthatcontributedtothesuccessofthisproject.Theyincludeflexible,looselycoupleddesign The use of popular data formats such as XML and CSV helped decouple the software interface from interface software the decouple helped CSV and XML as such formats data popular of use The Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 automated financial processes. financial automated to crucial attribute an reliable, extremely be would evolution resulting each and bugs, software new fewer introduce would scalability to related activities maintenance Additional testing. regression extensive less task. interaction level,futureimplementationsofthesolutionwouldbeanincreasinglymeasurableandpredictable data and user the at coupled flexibly and loosely yet level, component well- the at and cohesive highly self-documenting organized, was that code source engineering By architectures. database other and as hardware well as merchants, and vendors future support to scaled be to designed ultimately was solution that othervendorswouldlikelyrequestidenticalorsimilarmerchant-vendorintegrationsolutions,thesoftware accustomed. already were end-users the which with formats data and software of behavior and feel look, the had that product a in resulted This with thelegacysystembykeepingcomplexitylowforbothuserinterfaceandcomponentoutput. and implementation language licensing ofthevendor’ssame existinglegacysoftware.Italsotookadvantageofuseranddeveloperfamiliarity the of use the of form the in level environment the at and This wasachievedatboththesoftwarelevelinformofreusingsourcecodefromanexistingrepository, assets. legacy of advantage took project The reengineering: and engineering software in goals major the Integration Successful forTechniques 6.1 solution. the of value business future and current the both increasing further evolution, order toimprovetheprocessassoftwareevolved.Thedesignmodelwasrefinedduringeachsubsequent in developers the by analyzed and documented were evolution each during employed techniques the and a to product highly stable,scalableandmaintainablesolutioncapableofefficientfutureadaptations.Thelessonslearned custom off” “one a of engineering initial the Each from merchants. described, was third-party solution via the of products evolution vendor of purchases online to related details financial the of payment providers.Thepurposeoftheintegrationsolutionwastoautomateauditingandreconciliation and merchants online emergent and established multiple with system enterprise commerce multi-channel WORK FUTURE AND SUMMARY 6. o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol there that indicating evidence no is There systems. merchant online emergent and evolving constantly the that satisfiesboththerequirements ofaslowlyevolvinglegacyenterprisesystem withtherequirementsof solution a realizing is complexity added the of much Indeed, themselves. systems software legacy the of based partnerscanbeevenmorecomplexandchallenging processthanthereengineeringandmaintenance Work Future 6.2 possible. as straightforward as efforts future make to designed was solution this design, structural and understanding program both in quality degraded and complex increasingly an at take to expected instead is worst asimilarorpredictableeffort,andatbestsignificantly moreefficienteffort.Ratherthanexhibiting evolution future each is, software That [16]. legacy Lehman of by trend described stereotypical and the envisioned follow not does it “legacy”, or “old” as described software Shihong Huang, James J. Mulcahy J. James Huang, Shihong The reengineering of software that integrates legacy enterprise systems and their more modern web- modern more their and systems enterprise legacy integrates that software of reengineering The While thesolutionitself-alreadythreeyearsoldasofthiswritingwillsoontakeitsownplaceamong Finally, byplanninganddesigningforfaulttolerance,futuremaintenanceofthesolutionwouldrequire Second, theprojecteventuallyfocuseduponplanningforfuturemaintenanceandevolution. Anticipating of some represent that areas major three addressed study case this project, successful highly a Overall legacy a of integration the involved that project real-world particular a of study case a is paper This 75 www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 76 roadmap.” a evolution: and maintenance V.“Software T.Rajlich, and H. K. Bennett, 2. and “Understanding W.L.;Valen,J.D. Melo, and Yong-MiKim; S.; Condon, L.; V.R.;Briand, Basili, 1. References and requirements business architectures. changing of future inevitable the anticipate to designed product evolvable highly a in resulted process development the of analysis and documentation the and system the of aspects repositories, theencapsulationofplatform-specificlogic,decouplingbusinesslogicfromscalable legacy from code source of reuse The challenge. this mitigate to measures deliberate involved paper this by described project the strategies, evolution all of software complex most While the perhaps time. are projects over reengineering maintain to difficult and complex more increasingly grow that systems designed poorly more of characteristics the without change, efficient to itself lends specifically solution new support to architectures, muchoftheprocesshasnowbeenidentified,documentedandanticipated.Thedesign reengineering or merchants, additional support to maintenance future require solution CONCLUSION 7. systems. commerce multichannel legacy of visibility and use the extend and that scrutiny systems integrating of More trend the to others. applied be should by qualitative, and quantitative attempts both measurement, future the of success efficient the of to type crucial this is of integration implementations real-world from derived lessons the from well-established learning by Therefore, channels vendors. sales new other and e-commerce of proliferation the in decrease a be will 4. Bianchi, A.; Caivano,D.;Marengo, V.; Visaggio, G. “IterativeReengineeringofLegacySystems.” maintenance.” software and services “Software K.H. Bennett, 3. 8. Chikofsky, E. “Sustain, Enhance, or Replace: Making Decisions on Systems.” on Decisions Chikofsky,Making 8. Replace: or Enhance, “Sustain, E. 7. Canfora,G.; Fasolino, A. R;,and Tortorella, M.“Towards reengineering inreusereengineeringprocesses.” 6. Blackburn,J.D.;Scudder, G.D.; and Van Wassenhove, L.N.“Improvingspeedandproductivityofsoftware Bing D.; Lawless, J.; Bisbal, 5. Wu;directions,” and issues systems: information “Legacy J. Grimson, and Software inevitably requires maintenance [1][17]. Should the software engineered for this particular this for engineered software the Should [1][17]. maintenance requires inevitably Software Alamitos, CA; IEEE Computer Society Press: 1996. Press: Society Computer IEEE CA; Alamitos, Engineering Software on Conference release.” maintenance software of process the predicting New York,New NY,73-87. pp. SoftwareFutureEngineering of the on Conference the Conference on Software on Conference Maintenance Press:1995. Society Software Computer Washington,IEEE France). DC: Opio, 1995; 17-20, on Conference International the of Proceedings 1996. December 875-885, pp. 12, no. 22, vol. development: aglobalsurveyofsoftwaredevelopers.” Software IEEE Engineering Software of Transactions Reengineering and Maintenance Software on Conference , vol. 16, no. 5, pp. 103-111, September/October 1999. 103-111,September/October pp. 5, no. 16, vol. , Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software , vol. 29, no. 3, pp. 225-241, March 2003. March 225-241, pp. 3, no. 29, vol. , (ICSE 1996: March 25-29, 1996; Berlin, Germany). Los Germany). Berlin, 1996; 25-29, March 1996: (ICSE (ICSM 2006). p. 134, September 2006. September 134, p. 2006). (ICSM o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol IEEE Transactions onSoftware Engineering (June 4-11, 2000; Limerick, Ireland,). ACM: Limerick, 2000; 4-11, (June rceig o te 8h International 18th the of Proceedings , pp. 3-12, March 2003. March 3-12, pp. , Proceedings of the 7th European 7th the of Proceedings 22nd IEEE International IEEE 22nd (ICSM: 1995: October 1995: (ICSM: Proceedings of Proceedings IEEE , www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 21. Muller, H.; Wong, K.; and Tilley, S. “Understanding software systems using reverse using systems software “Understanding S. Tilley, and K.; Wong, H.; Muller, 21. ecommerce, between factors success critical the “Distinguishing W.H.Shaw, and C.; Ming-Ling, 20. directions.” research and issues software: F.;“Reusing Mili, Mili, A. H.; and Mili, 19. 18. Lung,C.“ recoveryandrestructuringthroughclustering techniques” 24. Robertson, P. “Integrating legacy systems with modern corporate applications.” corporate modern with systems legacy “Integrating P. Robertson, 24. February on accessed Last 2006; Jun. checkout.” online your handle to wants “Google L. Petrecca, 23. WernerVogels.”with “Aconversation C. O’Hanlon, 22. Processes.” Evolution Software and Evolution F.“Software J. Ramil, and M.; M. Lehman, 17. 16. Lehman, M. M. “Programs, life cycles, and of software evolution.” software of laws and cycles, life “Programs, M. M. Lehman, 16. small.” the in engineering software objectively: “Thinking P. R. Ward, and M.; Laitinen, E.; M. Fayad, 11. 15. Jelber S. S.; Lethbridge, T.C.; and Matwin, S. “Mining the maintenance history of a legacy software legacy a of history maintenance the “Mining S. Matwin, T.C.;and Lethbridge, S.; S. Jelber 15. Process Maintenance Software “Adoption-Centric D.; Distante, M.; VanHilst,S.; Tilley, S.; Huang, 14. integration.” system “Information W.Hasselbring, 13. Models.” and metrics reuse: “Software Terry,C. and B.; W. Frakes, 12. Tortora,Genoveffa R.; F.;Oliveto, Fasano, A.; Lucia, De 10. 9. Chikofsky, E.J.;andCross,J.H.“Reverseengineeringdesignrecovery:ataxonomy.” o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol Shihong Huang, James J. Mulcahy J. James Huang, Shihong on Software Engineering Software on des Sciences Proceedings Sciences des technology.” 601, EngineeringManagementSociety:2000. enterprise resourceplanning,andsupplychainmanagement.” Architecture Software 101-104, New pp. on York,ACM: Florida). NY, 1998. workshop international third the of Engineering Software vol. 68, no. 9, pp. 1060-1076, September 1980. September 1060-1076, pp. 9, no. 68, vol. the ACM the 26th, 2009:http://www.usatoday.com/tech/products/services/2006-06-29- googlecheckout_x.html. September 22-26, 2003; Amsterdam, The Netherlands). pp. 95-104, September 2003. September 95-104, pp. Netherlands). The 2003; Amsterdam, 22-26, September ACM the of Communications Methodology, and Engineering system.” 2006. Press: Society Computer IEEE CA: Los Alamitos, Hungary). SoftwareTechnologyPractice on Engineering and Integration.” Information via Improvement 32-38, Jun.2000. 1996. June 415-435, pp. 2, no. 28, methods retrieval information using systems management artifact 1990. January 13-17, pp. no.1, vol.7, , vol. 40, no. 5, pp. 39-46, May 1997. May 39-46, pp. 5, no. 40, vol. , Proceedings of the International Conference on Software Maintenance Maintenance Software on Conference International the of Proceedings In The 62nd Congress of L’Association Canadienne Francaise pour l’Avancement pour Francaise Canadienne L’Association of Congress 62nd The In , vol. 14, no. 1-4, pp. 275-309, December 2002. December 275-309, pp. 1-4, no. 14, vol. , , vol.21, no.6, pp.528-562, June 1995. June pp.528-562, no.6, vol.21, , (ACFAS), 1994. (ACFAS), , vol. 43, no. 3, pp. 115-118, March 2000. 115-118,March pp. 3, no. 43, vol. , vol. 16, no. 13, September 2007. September 13, no. 16, vol. Proceedings of the 13th IEEE International ConferenceInternational IEEE 13th the Proceedingsof Communications of the ACM the of Communications (STEP 2005: September 24-25, 2005; Budapest, 2005; 24-25, September (STEP2005: Queue “ , vol. 4, no. 4, pp. 14-22, May 2006. May 14-22, pp. 4, no. 4, vol. , Recovering traceability links in software in links traceability Recovering Proceedings of the 2000 IEEE ” (November 1-5, 1998; Orlando, 1998; 1-5, (November , ACM Transactions on SoftwareTransactionson ACM ACM Computing Surveys Computing ACM Proceedings of the IEEE the of Proceedings , vol. 43, no. 6, pp. 6, no. 43, vol. , Communications of Communications IEEE TransactionsIEEE IEEE Software Proceedings Annals of Annals , pp.596- (ICSM: , vol. , 77 , , www.IndianJournals.com Members Copy, Not for Commercial Sale

Downloaded From IP - 131.91.4.52 on dated 4-Sep-2015 27. Sneed, H. M. “Using XML to Integrate Existing Software Systems into the Web.”the into Systems Software Existing Integrate XMLto “Using M. H. Sneed, 27. 26. Sneed,H.M.“Encapsulationoflegacysoftware: A techniqueforreusinglegacysoftwarecomponents.” 78 XML-Interface.” an behind Programs COBOL Legacy “Wrapping M. H. Sneed, 28. G.Lewis Systems.” and Legacy D.; “Modernizing Plakosh, A. C.; R. Seacord, 25. 29. Sneed, H.M. “Integrating legacy software into a service oriented architecture.” oriented service a into software legacy “Integrating H.M. Sneed, 29. 30. Sneed, H.M. “Planning the Reengineering of Legacy Systems.” Legacy of Reengineering the “Planning H.M. Sneed, 30. 32. Storey, M.D.;Muller, H.A.;and Wong, K.“Manipulatinganddocumentingsoftwarestructures.” Projects.” Reengineering in Involved “Risks H.M. Sneed, 31. 33. Umar, A. “The emerging role of the Web for enterprise applications and ASPs.” and applications enterprise for Web the of role emerging “The A. Umar, 33. 34. Yang, J.,andPapazoglou,M.P. 2000.“Interoperationsupportforelectronic business.” Annals of Software Engineering, Software of Annals 172. IEEE Computer Society: Washington,Society: Computer 2002. IEEE DC, 172. Conference Applications and Software Computer International 26th Engineering Eighth Working Conference on Reverse Engineering Engineering Washington,Society: 2001. Computer DC, IEEE p.189. Reverse Germany). on Conference Working Eighth 10th European Conference on Software Maintenance and Reengineering Reengineering and 2006. 11-14,March pp. Maintenance Italy). Bari, 2006; 24, Software on Conference European 10th Oriented Technology for Database and Software Systems Software and Database for Technology Oriented 1999. Press: Society Computer IEEE Engineering Reverse on Conference 1995. January 34, IEEE of the ACM the of , vol. 92, no. 9, pp. 1420-1438, IEEE Computer Society Press: 2004. Press: Society Computer IEEE 1420-1438, pp. 9, no. 92, vol. , , vol. 43, no. 6, pp. 39-47, June 2000. June 39-47, pp. 6, no. 43, vol. , , Addison Wesley: 2003. Wesley: Addison , Software Reuse in the Evolution of an E-Commerce System: A Case Study Case A System: E-Commerce an of Evolution the in Reuse Software vol. 9, no. 1-4, pp. 293-313, January 2000. January 293-313, pp. 1-4, no. 9, vol. (WCRE: October 6-8, 1999; Atlanta, Georgia). pp 204-211. pp Georgia). Atlanta, 1999; 6-8, October (WCRE: o 1 N. , aur - pi, 00 (IJARITAC) 2010 April, - January 1, No. 1, Vol (WCRE: October 2-5, 2001, Stuttgart, 2001, 2-5, October (WCRE: Proceedings of the IEEE Sixth Working Sixth IEEE the of Proceedings , pp. 240-252, World Scientific: 1995. Scientific: World 240-252, pp. , IEEE SoftwareIEEE (COMPSAC 2002). pp. 167- pp. 2002). (COMPSAC , vol. 12, no. 1, pp. 24- pp. 1, no. 12, vol. , SEI Series in Softwarein Series SEI (CSMR: March 22- March (CSMR: Proceedings of the of Proceedings Proceedings of the of Proceedings Proceedings of the of Proceedings Proceedings of the Proceedingsof Communications Object-