Research ArticlePorting Mobile Apps from iOS to Android A Practical Experience
Khalid Lamhaddab 12 Mohamed Lachgar 3 and Khalid Elbaamrani1
1TIM Laboratory ENSA Cadi Ayyad University Marrakesh Marrakesh Morocco2MDA Expert MyAppConverter Ltd London UK3LTI Laboratory ENSA University of Chouaib Doukkali El Jadida El Jadida Morocco
Correspondence should be addressed to Khalid Lamhaddab klamhaddabgmailcom
Received 19 April 2019 Revised 19 June 2019 Accepted 22 July 2019 Published 3 September 2019
Academic Editor Ramon Aguero
Copyright copy 2019 Khalid Lamhaddab et al is is an open access article distributed under the Creative Commons AttributionLicense which permits unrestricted use distribution and reproduction in any medium provided the original work isproperly cited
e recent rise of smartphones has triggered a revolution in mobile development As a result of this incremental mobile in-novation new software engineering techniques software documentation and tools adapted to the mobile platform remainessential in order to help developers to better understand analyze and bootstrap porting mobile applications In this paper theauthors propose a model-driven reverse-engineering approach based on static analysis which describes a semantic metamodel ofthe iOS mobile application and extract design information (such as user interfaces activity diagram entities framework andlibrary dependencies) in order to generate the functional specification documentation and the Android UI skeleton us aidingthe project team who has in charge porting the app to another mobile platform to agree upon a consensus on what has to beimplemented and safe development cost by auto generating the Android UI skeleton project To experiment this approach theauthors have implemented a tool called iSpecSnapshot Moreover they evaluate the performance of iSpecSnapshot by an ex-periment involving iOS applications that are ported to Android platform
1 Introduction
e growth in number of smartphone users worldwideis leading to an impressive growth in number of appdownloads and also in terms of incomes generated by theseapps According to a recent statistical study [1] by 2021over 353 billion of mobile apps will have been downloadedworldwide [1]
At present there are over 22 million apps on the Applestore [2] and more than 3 million Android apps are onGoogle Play Store [3]
e key challenge that enterprise organizations facewhen starting their native mobile app development projectsis that what platform should they start with iOS or Android
In fact both the two platforms have their fair share of prosand cons e authors outline the key aspects which can helpto get a clear idea to decide which platform is suited toenterprise requirements e choice comes down to 4 factors
(i) Audience Android is fast-growing and enjoying7527 of the share of whole mobile OS market
compared to iOS which ranks second at 2274AppAnnie [4] reports that for the first quarter of2019 the Google Play Store pulled 22 billion appsworldwide Comparatively the App Store onlydrove 8 billion
(ii) Monetization While Android rakes in moredownloads iOS maintains a nearly 2x lead when itcomes to gross consumer spend [4] AccordinglyiOS customer segment comprises well-off users whoare willing to pay extra for sustainable apps andservices with advanced design security and capa-bilities e apple iOS monetization is built on asubscription model or in-app purchases HoweverAndroid apps rely on an ad-based model
(iii) Project timeline Developing Android apps gener-ally takes more time due to device fragmentationand the complexity involved in Android app de-velopment On an average Android app develop-ment is 30ndash40 percent slower than iOS AlthoughiOS apps are quicker to design Apple has a strict
HindawiMobile Information SystemsVolume 2019 Article ID 4324871 29 pageshttpsdoiorg10115520194324871
approval process to control apps quality and theircompliance to certain standards In contrast GooglePlay Store publication process implies less strictguidelines for publishing an app Generally an appreview process takes a day or two to get approvedand published within few hours
(iv) Budget e cost to develop a mobile app comesdown to a range of factors e scope and thecomplexity of the project are the most significantcost factorsere are other facets that incur the costsuch as Devices and OS versions support Backendinfrastructure and services integrations Marketingeffort Team and cross department involvement andMaintenanceupgrade
Many startups who need to build a minimum viableproduct quickly and cheaply prefer to start with iOS plat-form In the meantime for startups that want to conquer themarket shares and need to scale swiftly as well porting aniOS app to Android is then a key strategy With a wideAndroid user audience they have certainly more moneti-zation and investment opportunities Alternatively otherenterprises prefer to build their mobile app using the pro-gressive web app (PWA) strategy [5] is path is moreeffective when it comes to code reusability maintainabilitycost efficiency and audience reach (access via URL) Re-cently progressive web apps can leverage some featuressimilar to native apps such as send push notification usetouch gesture access to phonersquos accelerometer and use ofvibration However the major drawback of PWA is thebehavior of performance and application PWA will alwayslag behind native because the native APIs need to be de-veloped before In other words PWA might not be the bestoption for developers if they look for a high performance ortheir apps use 3D graphics
Porting iOS app to Android refers to converting orrewriting the app code according to the target platform inorder to enable it to run on different Android mobile devicesand deal with the famous concern Android fragmentation[6] Porting or reverse engineering an app has turned out tobe a tedious and complex task as the developers should havetechnical skills in both the source and target mobile plat-form In fact developers had to deal not only to adaptplatform SDK and write specific code but also to analyzeand understand the functional logic behind a mobile app
In a study carried out by Roehm et al in [7] severaldevelopers act as end users and interact with the user in-terface to test the applicationrsquos behavior in order to find anentry point of the User Experience (UX) model Othersconsider that source code is more credible than docu-mentation this was due to the lost or the outdatedness of thedocumentation
In general most mobile experts agree that the process ofmobile app porting should take the following steps
(i) Understanding the functional behavior(ii) Analyzing UIUX (user interfaceuser experience)(iii) Technical assessment
(iv) Code conversion(v) Testing and quality insurance of the produced
source code(vi) Iterative release
To meet the growing demands of mobile apps portingdedicated software engineering techniques and reverse-en-gineering tools (see [8ndash10]) adapted to the mobile platformremain essential in order to help developers to better un-derstand analyze andmaintain mobile applications [11 12]
Reverse engineering has many valuable benefits emost principal advantages are as follows
(i) Understanding of source code(ii) Evolving and maintaining the software(iii) Redocumenting software(iv) Integration with legacy systems(v) Migration of legacy systems to new recent
technologies(vi) Quality assessment
emain contribution of this paper consists of proposing amodel-driven reverse-engineering (MDRE) approach thatconsiders both the UI part (storyboard workflow (Xcode Sto-ryboard httpsdeveloperapplecomxcodeinterface-builder))and the source code of native iOS mobile application to au-tomatically extract specific models ese models contain UIUX behavior and technical assessments that are needed togenerate both the functional specification document of the iOSapp and the corresponding Android UI skeleton is is im-portant to help designers to analyze systems and could be usedto validate system requirements and accelerate development at areasonable cost [13]
e proposed contributions are outlined below
(i) A reverse-engineering technique that extracts au-tomatically a semantic mobile app model accordingto a predefined mobile metamodel is metamodelincludes more detailed information about themobile app such as screens controllers widgetsnavigations events and actions
(ii) An in-depth reporting analysis through the sourcecode to build a framework dependencies tree In theircase study the authors are interested in iPhone SDKFramework (iOS SDK framework httpsdeveloperapplecomdocumentation)
(iii) iSpecSnapshot which is a tool that analyzes the se-mantic model of the iOS mobile app and turns it intospecific target models e inferred models aretransformed into functional spec document andAndroidUI skeleton following a forward engineeringtechnique [14] e generated artifacts will help de-velopers in their porting task to understand the sourceapplication and bootstrap the porting process
is paper is organized as follows Section 2 reports themost relevant mobile reverse-engineering approaches andcompares them according to various criteria Section 3
2 Mobile Information Systems
presents the empirical study design of our research Section 4describes the proposed MDRE approach for reverse-engi-neering iOS apps to Android Section 5 describes iSpecS-napshot from a technical viewpoint Section 6 discusses anevaluation of the tool through a case study conducted onrealistic third-party iOS applications Finally a discussionregarding the contributions achieved within this research andsome possible challenges and perspectives for future work arepresented in Section 7
2 Related Work
e literature review presented is based on a critical in-depthinvestigation of works published over the last seven yearswith regard to mobile reverse-engineering approaches
In [15] Franke et al investigate how to reverse-engineermobile application lifecycles by testingemethod is drivenby developerrsquos code and consists of four steps (1) Fullimplementation of the lifecycle methods (pause start anddestroy) (2) Log Injection printing some test logs inside thelifecycle methods (3) Transition-trigger detection identify acatalog of triggers and track the app behavior (4) Appli-cation lifecycle rebuild based on the logger data the de-veloper can rebuild a state model for the mobile app emain weakness in their approach is that they oblige de-veloper to hard code logs in order to achieve this taskerefore there is no automation effort such as imple-menting a plugin which can perform source code analysisand detect the possible lifecycle methods and potential eventbehaviors
In [16] Joorabchi and Mesbah propose a reverse-engi-neering technique based on dynamic analysis in order togenerate a state model of a running iOS application isapproach aims to capture the user interface states and tran-sitions between them e authors have endorsed their tech-nique by a tool called ICRAWLER is approach howeverhas not been able to describe correctly all the UI part char-acteristics (graphic information UI classes event types etc)
e study carried out by Yang et al [17] addresses theissue of automated GUI-model generation for mobile ap-plications ey introduce a grey-box approach for auto-matically extracting a model of a given mobile applicatione approach aims to extracts using a static analysis all thesupported events by the GUI components of the applicationen it uses a dynamic crawling process for reverse-engi-neering a model of the application by applyingmdashon theflymdashthe extracted events on the running application eauthors have developed a tool for Android platform calledOrbit which is composed of an action detector modulebased onWALA (TJ Watson Libraries for Analysis WALAhttpsgithubcomwalaWALA) and a dynamic crawlerbuilt on top of Robotium (Robotium httpsgithubcomRobotiumTechrobotium)
In [18] Salva and Zafimiharisoa propose a formal modelinference approach for mobile application by automatictesting e approach aims to store rich details about theencountered interfaces and help to reduce the applicationexploration by using the Ant Colony Optimisation ACOstrategy e method is more suitable for performing an
STS model (Symbolic Transition System) and test casegeneration
In [19] Morgado et al present an approach for testingmobile applications using reverse engineering and behav-ioral patterns e aim of their work consists of defining acatalogue of mobile GUI behavioral patterns and using ahybrid reverse-engineering tool based on Yang et alrsquos ap-proach [17] e tool helps to automatically explore mobileapplication identifying patterns and applying the predefinedtest
In [20] Nguyen and Csallner introduce a techniquecalled REMAUI for inferring mobile application user in-terface code from screenshots or conceptual drawingsHence from a given input bitmap REMAUI identifies userinterface elements such as images texts containers and listsvia computer vision and optical character recognition(OCR) techniques REMAUI merges OCR and computervision results and in the merged data identifies the commonstructures such as lists or images REMAUI then recognizesaligned text blocks groups them into a layout container andexports the recognized text fragments as an Android re-source file A major weakness of this technique is that it isnot well suited to recognize complex composite componentsuch as menumenu item calendar segmented controls oreven radio groupe core of the technique might have beenmore interesting had the authors exploited the MDE par-adigm during the OCR recognition phase us it will allowproducing rich PSM (platform-specific model) models thatdescribe in a more complete way the conceptual drawings
Lamhaddab and Elbaamrani in [21] investigate how to usegraph-based modeling in reverse engineering of mobile ap-plications e authors use a static analysis of the mobile appsource code in order to produce a representative graphmodelof the source app e generated graph model can betransformed via semantic rules to another graph modelaccording to a target mobile metamodel Both the source andthe target graph models are stored in a graph database estudy concludes that graph-based modeling provides ad-vantages such as flexibility regarding the relationship betweengraph nodes data consolidation and the ease of navigationinside graph models thanks to a specific query language
To overcome the challenge of how to avoid stateless eventflow graph (EFG) ofmobile applicationGUI Amalfitano et alin [22] present a GUI-driven testing framework for Androidapps called MobiGUITAR e framework is based on threesteps (1) reverse engineering the state-machine model fromthe running app and creating abstractions of the machine (2)generating test cases and (3) replaying the test casesAccording to the study MobiGUITAR produces severaltesting artifacts (such as Crash Report Finite State-MachineFSM Model GUI Sequences and JUnit test cases)
In another study by Dugerdil and Sako in [23] theauthors present a reverse-engineering process to recover thefunctional structure of mobile apps e approach consistsof three steps (1) using code instrumentation by insertingextra statements in the source code which helps to recordevents (2) recording the execution trace in a flat file formatand (3) performing an offline analysis of the execution traceto retrieve the use cases of the mobile app using many views
Mobile Information Systems 3
Another contribution by Salihu et al [24] proposes ahybrid technique for reverse-engineering the GUI modelfrom Android apps e researchers have developed a toolcalled AMOGA that combines static and dynamic analysise tool performs a static analysis of mobile applicationbinaries to automatically extract GUI information en itinstructs a dynamic crawling to explore and reverse-engi-neer a model of the mobile app
Morgado and Paiva [25] developed a tool named iMPActfor supporting the automatic testing of mobile apps based onthe presence of recurring behavior UI Pattern e meth-odology used in this study was fully automated and it isbased on two steps first crawling the application byidentifying a UI pattern and then interacting with it byapplying a test strategy
A field study approach is applied by Chen et al [26] toinvestigate automating visual understanding of mobile UIdesign to generate a mobile GUI skeleton rough theirstudy a neural machine translator is developed whichcombines a vision convolutional neural network (CNN) anda recurrent neural network (RNN) [27] encoderdecodere translator consists of extracting visual features in UIdesign encoding feature spatial layouts and generating GUIskeletons With the similar focus another case study byBeltramelli [28] contributes to this line of research bypresenting an approach based on convolutional and Re-current neural networks combined with a specific DSLwhich helps to generate from GUI screenshot the corre-sponding source code for different platforms (ie iOSAndroid and web-based technologies) e technique wastrained on a relatively small dataset and requires moreimprovements to recognize vectorial representation eauthor argues that generative adversarial networks (GAN)s[29] could potentially be used in combination with pix2codemodel to improve results
A recent testing technique that is GUI exploration basedis introduced by Amalfitano et al [30]e approach aims toexploit human involvement in the automated process toaddress the challenge of exploring Gate GUIs which requireto be exercised with particular input event sequences eauthors present jugular a hybrid GUI exploration toolcombining automated GUI exploration with capture andreplay by exploiting a machine-learning approach
e previous studies were categorized according to theontology presented initially by Cornelissen et al [31] andrefined according to the mobile reverse-engineering contextby Morgado et al [19] e main aspects to classify theselected approaches included
(i) Goal the main aims of the studied approach(program comprehension model recovery patternidentification verification and validation etc)
(ii) Target the target platform (iOS Android Web) orthe relevant input artifact (UI drawing screen-shots) which is concerned by the study
(iii) Method this refers to what type of analysis per-formed by each approach on the source artifactsie static dynamic or hybrid
(iv) Technique this indicates the implemented tech-nique for reverse engineeringcomprehending theconsidered system (instrumentation code in-jection parsing crawling etc)
(v) Extracted information this specifies the key in-formation extracted by the adopted method (run-time behavior event sequence UI states crashdetection etc)
(vi) Output this indicates in which forms the resultswill be generated (call graph finite state machinereport test suite etc)
(vii) Validation by what means the approach has beenvalidated (case studies comparison with othertoolsapproaches evaluation)
Table 1 summarizes the result of the classification of theprevious studies according to the ontology criteria presentedby Morgado [32]
Based on this in-depth critical analysis of previousworks there remainmany gaps that have not been tackled byrecent research In fact the main challenges covered in thesestudies can be grouped in three topics test automationprogram comprehension and mobile UI drawing Con-siderable gap that warrant particular attention is that none ofthe previous research have addressed the full reverse engi-neering from one platform to another platform In additionmost of these approaches which rely on static analysis of thesource code have not take advantages of the use of themodel-driven engineering (MDE) paradigms in order tobetter comprehend the studied system Only the attemptintroduced by Lamhaddab and Elbaamrani [21] approachedthe reverse-engineering of mobile apps by focusing ongraph-based models We believe that the MDRE approachcan bring a considerable gain regarding detection of be-havior and UI patterns GUI explorations machine stateidentification or event handling
3 Empirical Study Design
In this section the authors present the empirical studydesign of this research ey discuss the methods used fordata collection and data analysis
31 Data Collection e first step of this research meth-odology is to perform a literature survey of the relevantpublished works regarding mobile reverse-engineering fieldas presented in Section 2 e aim of this phase is to conducta deep critical analysis of previous works and identify whichcurrent gaps remain in reverse-engineering mobile platformtechniques to attempt to solve the gaps
e second phase aims to collect the mobile developersrsquoneeds e objective of this study is to investigate the realchallenges faced by mobile developers during the mobileporting process and to identify insight into the aspects andtechnical axis that must be covered when designing theproposed tool erefore it was important to gather datafrom various stakeholders involved in mobile applications
4 Mobile Information Systems
Table 1 Classification of the related mobile reverse-engineering techniques in terms of goal target method extracted information outputand validation
Study Goal Target Method Technique Extractedinformation Output Validation
Frank et al [15]Program
ComprehensionFeature location
iOSAndroidJava ME
Static InstrumentationCode injection
RuntimebehaviorEvent
sequence
Call graphReport Case study
Joorabchi andMesbah [16] Model recovery iOS Dynamic Crawling
Event handling
RuntimebehaviorUser
interfacestates
Finite state machine Case study
Yang et al [17] Model recovery Android HybridCrawling
Event handlingParsing
RuntimebehaviourEvent
Sequence
Finite state machineCase studyComparisonEvaluation
Salva andZafimiharisoa[18]
Verification andvalidation
Model recoveryAndroid Dynamic Crawling
Runtimebehaviour
UserinterfacestatesCrash
detection
Call graphFinite state machine
Test suite
ComparisonEvaluation
Morgado et al[19] 2014
Verification andvalidationPattern
identification
Android Hybrid
CrawlingEvent handling
ParsingInstrumentation
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
Case studyComparison
Nguyen andCsallner [20]
User interfaceidentification
MobileUI design Static
Optical characterrecognition OCREvent handling
Userinterfacewidgets
Computervision
Android UI skeleton Case studyEvaluation
Lamhaddab andElbaamrani[21] Porting iOS Static
ParsingGraph modeling
Modeltransformation
Source codeASTUser
interfaceWidgetsUser
interfaceSequences
Graph models for sourceplatform (iOS)
Graph models for targetplatform (Android)
ComparisonEvaluation
AmalFitano et al[22]
Verification andvalidation
Model recoveryAndroid Dynamic
RippingInstrumentationTest Generation
CrashdetectionBugs
Call graphReport
Test suiteFinite state machine
Case studyComparisonEvaluation
Dugerdil andSako [23]
ProgramcomprehensionMaintenance
iOS Static InstrumentationCode injection
RuntimebehaviourEvent
Sequence
Report Case studyEvaluation
Salihu et al [24] Model recovery Android HybridCrawling
Event handlingParsing
Runtimebehaviour
Userinterfacestates
Finite state machine ComparisonEvaluation
Morgado andPaiva [25]
Verification andvalidationPattern
identification
Android DynamicCrawling
Event handlingParsing
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
ComparisonEvaluation
Mobile Information Systems 5
development Interview participants were recruited throughthe subscriber database of MyAppConverter (MyApp-Converter httpwwwmyappconvertercom) platformerefore candidates have been selected via an e-mailcampaign that highlights the road map of the new tool andwhich encourage subscribers to participate in the surveyeauthors have selected 20 Android developers and 15 iOSdevelopers with 2 to 5 years of experience In addition theyhave targeted 10 product owners who are not necessarilydevelopers but rather business analysts To approve theinterview questionnaire the authors have hired a small teamfrom MyAppConverter composed of two senior mobiledevelopers (iOS amp Android) and one functional analyst leadey recruited a total of 45 interview participants andscheduled 15 to 20minutes conference calls for conductinginterviews based on their availability It should be noted thatall the participants were ensured about the confidentiality oftheir personal information and data
Moreover three variants of questionnaires were ad-ministered to three categories iOS developers Androiddevelopers and product owners e purposes of thesequestionnaires are to identify the best practices and tech-niques widely used to design the UI part of iOS applicationslist the components that present difficulties when they areported to Android and define the key information that willhelp in the functional understanding during the portingprocess
32 Data Analysis After collecting the practitionersrsquo re-sponses the authors analyzed carefully the data in order todetermine the proposed toolrsquos features It is worth notingthat real-world practitioners support the research as themajority of the 45 interviewees agreed that implementing atool which can reverse-engineer the functional specifications
and port the UI storyboard and could contribute sub-stantially on time and cost of mobile porting project
With regard to the questionnaire that targets productowners 70 of the respondents agreed that the proposed toolshould represent the functional requirements as use casesformat In use cases template the functional requirements areunderstood in the context of user action which typicallyavoid a lot of ambiguity that makes its way into an out-ofcontext list of system However 30 of the respondentsprefer to represent the functional spec in an agile form such asuser stories ey argued that the user story form is highlyeffective at capturing and linking user goals functional re-quirements and business benefits Overall 95 of the in-terviewees agreed that the functional spec document shouldinclude information about project team build informationdependencies constraints business class model entity modelscreens details activity diagram and business rules
e respondents of the questionnaire that was targetedthe iOS developers reflected that a high percentage (85 ofthem) use storyboard and xib files to design the UI layereyargue that the Interface Builder IDE within Xcode makes itmuch easier to design UI and flows without writing any codeIn addition storyboards are highly recommended withmultiple interconnected view controllers and eliminateboilerplate code to perform transition between view con-trollers However 15 of the respondents build UI pro-grammatically by writing Objective-C or Swift code eyargue that mastering the coding of iOS UI allows addressingviews with complex or dynamic layouts customizing tran-sition effects between view controllers and refactoring spe-cific views in a reusable fashion 65 used autolayout featurein order to define constraints to control how user interfacewill adapt on different screen sizes when device rotated orwhen the app run in different locales Overall 47 prefer touse third libraries to customize UI components instead of iOS
Table 1 Continued
Study Goal Target Method Technique Extractedinformation Output Validation
Chen et al [26] User interfaceidentification
MobileUI design Static
Neural machinetranslator
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
Userinterfacewidgets
Android UI skeleton Case studyEvaluation
Beltramelli [28] User interfaceidentification
MobileUI design Static
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
DSL
UserInterfaceWidgets
Android UI skeletoniOS UI skeletonWeb-based U
Case study
Amalfitano et al[30]
Verification andvalidation
Model RecoveryAndroid Hybrid
CrawlingInstrumentation
Input event sequenceMachine learning
RuntimebehaviorUser
interfacestatesHuman
involvement
Call graphFinite state machine
Test suiteReport
Case study
6 Mobile Information Systems
UIKit framework Additionally 90 used xib to designstatic table view cell and displaying dynamic data Fur-thermore they used code to define table view data sourceUITableViewDataSource (UITableViewDataSource httpsdeveloperapplecomdocumentationuikituitableviewdatasource) and UITableViewDelegate (UITableViewDelegatehttpsdeveloperapplecomdocumentationuikituitableviewdelegate) in order to manage cell selection and other featuresrelated to displaying the data
With regard to the questionnaire that targets the An-droid developers 90 of the respondents used xml layout todesign UI prototyping Overall 60 used small widthqualifier in order to adapt layout to respond gracefully todifferent screen sizes and orientations However 40 agreedthat it is preferable to use the constraint layout to create aresponsive UI In addition a high percentage (92) of therespondents recommend modularizing UI components withfragments (Android Fragments httpsdeveloperandroidcomguidecomponentsfragments) Overall 100 agreedthat it will be a tedious task to port some iOS UI componentssuch as Attributed TextView TableView Collection ViewController Page View Controller Split View Controller andCollection Reusable View Moreover all the intervieweesadmit that there is an additional effort to adapt iOS graphicassets for Android e best solution is to scale assets tocorrect size for relevant device screen Additionally all therespondents confirm that it is not obvious to find anequivalent for custom UI components in most cases de-velopers are limited to using the closest Android UI standardcomponents based on Googlersquos guidelines
4 Proposed Approach
is section outlines the model-driven reverse-engineering(MDRE) approach followed in iSpecSnapshot e authorsrsquovision is to approach MDRE from a new context which ismobile development ey will try to provide answers toenrich the reverse-engineering literature with a hot topicwhich addresses porting mobile applications from iOS toAndroid e present work closely seeks to address reverseengineering of the documentation and UI of an iOS ap-plication e current contribution sheds the light on usingMDRE paradigm to identify the main steps and modelingstandards with the purpose to propose a more generic andextendable approach
Specifically in their method the authors proceed in thesame way as the Fleurey et al [33] by adopting their MDREsteps with some alterations code to PSM PSM to PIM PIMto PSM and PSM to code e particularity of the authorsrsquoapproach is that all the adopted metamodels are based onKDM and ASTM standards (see Appendix B) Hence theproposed process is depicted in Figure 1 and consists of fourmain steps
(i) Model discovery (code to PSM)(ii) Model semantic extraction (PSM to PIM)(iii) Model transformation (PIM to PSM)(iv) Model to code generation (PSM to code)
As running examples the authors have chosen threeopen sourced projects from Apple sample code Library andGithub Table 2 shows resource link details for each runningexample (ID name and resource link)
Table 3 reports some metrics of each running examplenumber of the source code files (header and main files) sizeof the source files number of used storyboardxib files andthe number of the static UI elements
41 Step 1 Model Discovery Model discovery is a parsingstep which aims to parse the source mobile app artifacts inorder to produce a set of representative models ese so-called initial models have a strong dependency with thecomponents of the source app they are commonly describedby the OMG as platform-specific models (PSMs) (see Ap-pendix A) e implementation of this step depends on thetechnology of the source mobile platform It is based mainlyon the static analysis to automatically generate PSM modelsfrom source code artifacts Typically an iOS app is com-posed by programming language files (h m Swift ccpp) platform-specific files (storyboard pch pliststring) asset files (png jpeg bmp) and data files(xcdatamodeld xml json)
In the initial stage it is wise to first define all themetamodels that describe the source mobile platform In-deed as mentioned in Figure 2 the authors distinguish fourvariants of metamodels technological infrastructure ap-plicative and data metamodels
e technological metamodel describes the programinglanguages used in the source mobile platform It inheritsmainly from the OMG ASTM metamodel For instance forthe iOS mobile platform the authors define ASTM meta-models for the commonly used programming languagessuch as C C++ Objective-C and Swift Figure 3 illustratesan excerpt of the Objective-C metamodel (metamodeling ofthe Objective-C block expression (Objective-C block httpsdeveloperapplecomlibraryarchivedocumentationCocoaConceptualBlocksArticles00_Introductionhtmlapple_refdocuidTP40007502-CH1-SW1))
e infrastructure metamodel defines the tree structureand relative paths of the source mobile app (folders subfolders files assets resources etc) It inherits mainly fromthe OMG KDM metamodel Figure 4 shows an overview ofthe iOS xcode project metamodel
e applicative metamodel defines mainly specific in-formation regarding the source mobile platform includingbuild settings dependencies compiler executable nameand static UI workflow It is designed according to theofficial iOS documentation (UIKit official documentationhttpsdeveloperapplecomdocumentationuikit) Figure 5shows an overview of the metamodel specific to the UI part(xib file)
emodel discovery step is performed through platformparsers which are specific to the source platform e au-thors have set up four kinds of parsers
(i) Infrastructure parsers allow generating a physicalmodel of the source application is model con-tains all the tree structure and relative paths of the
Mobile Information Systems 7
source mobile app (folders sub folders files assetsresources etc) e generated model is conformedto the Xcode Project KDM metamodel
(ii) Technological parsers allow generating abstractsyntax models of all the programming language filesused in the source application (eg C C++ Ob-jective-C and Swift) At this stage all the generatedmodels conform to the technological ASTMmetamodels
(iii) Applicative parsers allow building applicativemodels which are specific to some key artifact ofthe source platform (eg workspace file xcode-proj file pch file plist file xib file Pod file etc)Generally these artifacts include informationabout the source platform namely build settingsdependencies compiler executable name andstatic UI workflow ese models (eg Algo-rithm 1) are designed according to the applicativemetamodels
(iv) Data parsers allow building data models which arestatically stored in the file system (eg xdatamodelfile json file xml file etc)ese models conform totypical metamodels
42 Step 2 Semantic Extraction e semantic extractionstep is considered as a halfway point between code-to-modeland model-to-model steps In fact it aims to analyze thePSM models in order to extract some useful semantic in-formation which is required to build the PIM model eextraction process is designed to be iterative and supportsboth technological and applicative models is process isdriven by a set of semantic extractors that identify collectand consolidate all the semantic data required to build thesemantic mobile model PIM which is an instance of thesemantic mobile metamodel e authors have opted for ageneric metamodel which represents in a semantic mannerany mobile application e proposed metamodel is theresult of a close collaboration with two senior mobile
OMG standard metamodelsKDM ASTM SMM
Mobile platform Ametamodels
Semantic mobilemetamodels
Mobile platform Bmetamodels
Metamodel
ModelConforms to
Target mobilePSMs
32
1
TransformationSemantic model
PIM
Conforms to
Semanticextraction
Source mobilePSMs
Conforms to
Discovery
Source mobileapplication
mobile platform A
Target mobileapplication
mobile platform B
Codegeneration
Code
4
User inherits from
Figure 1 Main steps of the proposed MDRE approach to reverse-engineer a mobile app code to PSM PSM to PIM PIM to PSM and PSMto code
Table 2 Running examples open-source native iOS apps
ID Resource name Resource source link1 eSimpliestTodoList httpsgithubcomaltaibayareSimpliestTodoList
2 UIKitCataloguehttpsdeveloperapplecomlibrarycontent
samplecodeuicatalogIntroductionIntrohtmlapple_refdocuidDTS40007710
3 Tabsterhttpsdeveloperapplecomlibrarycontent
samplecodeTabsterIntroductionIntrohtmlapple_refdocuidDTS40011213
Table 3 Metrics of the running examples
ID No of source files (hm) Size of source file (KB) No of storyboard (xib file) No of UI elements Xcode build (SDK)1 10 30 1 26 72902 50 192 2 157 72903 22 22 3 31 7290
8 Mobile Information Systems
Mobile platform AASTM metamodel
Mobile platform AKDM metamodel
Mobile platform Aapplicativemetamodel
Datametamodel
DataPSM
Parsers
1 Model discovery
ApplicativePSM
InfrastructurePSM
TechnologicalPSM
Conforms to
Code to PSM
Programminglanguage files
Specific artifactsplatform
Assetfiles
Datafiles
Mobile app physical structure
Source mobileapplication
Mobile platform A
Figure 2 First step of the proposed MDRE approach model discovery (code to PSM)
BreakStatement
objcExpression
BlockStatement
Extends
Extends
ExtendsExtends
Extends
Statement
ContinueStatement
ExpressionStatement
IfStatement
WhileStatement
SwitchStatement
Extends
Extends
Extends
Extends
ForStatement
AstmObject
AstmSyntaxObject 1
1
1
1
1
ObjcBlockExpression
formalParameters
FormalParameterDefinition
+ aliasName EString
+ synthesizedName EString + nameString EString
accessKind
AccessKind Name
Identifier Name1
1
+ includeUnitSource EString
+ comment EString
1 lowast
ExtendsExtends
SourceLocation
AnnotationExpression
TypeReference
loctionInfo
ownedObjects
Extends
Extends
lowastExpression
expressionType
definitionType Definition
Extends
Extends
DeclarationOrDefinition
+ isClassAttr EBoolean
+ isProtocolimpl EBoolean
ExtendsinitialValue
DataDefinition
+ isMutable EBoolean
body1
lowastExtends
lowast
KDMEntity
DefinitionObject
Figure 3 Technological metamodel an excerpt of the ASTmetamodel corresponding to the Objective-C block expression e key entitiesare ObjcBlockExpression Expression Statement FormalParameterDefinition TypeReference AccessKind AstmObject KDMEntity etc
Mobile Information Systems 9
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
approval process to control apps quality and theircompliance to certain standards In contrast GooglePlay Store publication process implies less strictguidelines for publishing an app Generally an appreview process takes a day or two to get approvedand published within few hours
(iv) Budget e cost to develop a mobile app comesdown to a range of factors e scope and thecomplexity of the project are the most significantcost factorsere are other facets that incur the costsuch as Devices and OS versions support Backendinfrastructure and services integrations Marketingeffort Team and cross department involvement andMaintenanceupgrade
Many startups who need to build a minimum viableproduct quickly and cheaply prefer to start with iOS plat-form In the meantime for startups that want to conquer themarket shares and need to scale swiftly as well porting aniOS app to Android is then a key strategy With a wideAndroid user audience they have certainly more moneti-zation and investment opportunities Alternatively otherenterprises prefer to build their mobile app using the pro-gressive web app (PWA) strategy [5] is path is moreeffective when it comes to code reusability maintainabilitycost efficiency and audience reach (access via URL) Re-cently progressive web apps can leverage some featuressimilar to native apps such as send push notification usetouch gesture access to phonersquos accelerometer and use ofvibration However the major drawback of PWA is thebehavior of performance and application PWA will alwayslag behind native because the native APIs need to be de-veloped before In other words PWA might not be the bestoption for developers if they look for a high performance ortheir apps use 3D graphics
Porting iOS app to Android refers to converting orrewriting the app code according to the target platform inorder to enable it to run on different Android mobile devicesand deal with the famous concern Android fragmentation[6] Porting or reverse engineering an app has turned out tobe a tedious and complex task as the developers should havetechnical skills in both the source and target mobile plat-form In fact developers had to deal not only to adaptplatform SDK and write specific code but also to analyzeand understand the functional logic behind a mobile app
In a study carried out by Roehm et al in [7] severaldevelopers act as end users and interact with the user in-terface to test the applicationrsquos behavior in order to find anentry point of the User Experience (UX) model Othersconsider that source code is more credible than docu-mentation this was due to the lost or the outdatedness of thedocumentation
In general most mobile experts agree that the process ofmobile app porting should take the following steps
(i) Understanding the functional behavior(ii) Analyzing UIUX (user interfaceuser experience)(iii) Technical assessment
(iv) Code conversion(v) Testing and quality insurance of the produced
source code(vi) Iterative release
To meet the growing demands of mobile apps portingdedicated software engineering techniques and reverse-en-gineering tools (see [8ndash10]) adapted to the mobile platformremain essential in order to help developers to better un-derstand analyze andmaintain mobile applications [11 12]
Reverse engineering has many valuable benefits emost principal advantages are as follows
(i) Understanding of source code(ii) Evolving and maintaining the software(iii) Redocumenting software(iv) Integration with legacy systems(v) Migration of legacy systems to new recent
technologies(vi) Quality assessment
emain contribution of this paper consists of proposing amodel-driven reverse-engineering (MDRE) approach thatconsiders both the UI part (storyboard workflow (Xcode Sto-ryboard httpsdeveloperapplecomxcodeinterface-builder))and the source code of native iOS mobile application to au-tomatically extract specific models ese models contain UIUX behavior and technical assessments that are needed togenerate both the functional specification document of the iOSapp and the corresponding Android UI skeleton is is im-portant to help designers to analyze systems and could be usedto validate system requirements and accelerate development at areasonable cost [13]
e proposed contributions are outlined below
(i) A reverse-engineering technique that extracts au-tomatically a semantic mobile app model accordingto a predefined mobile metamodel is metamodelincludes more detailed information about themobile app such as screens controllers widgetsnavigations events and actions
(ii) An in-depth reporting analysis through the sourcecode to build a framework dependencies tree In theircase study the authors are interested in iPhone SDKFramework (iOS SDK framework httpsdeveloperapplecomdocumentation)
(iii) iSpecSnapshot which is a tool that analyzes the se-mantic model of the iOS mobile app and turns it intospecific target models e inferred models aretransformed into functional spec document andAndroidUI skeleton following a forward engineeringtechnique [14] e generated artifacts will help de-velopers in their porting task to understand the sourceapplication and bootstrap the porting process
is paper is organized as follows Section 2 reports themost relevant mobile reverse-engineering approaches andcompares them according to various criteria Section 3
2 Mobile Information Systems
presents the empirical study design of our research Section 4describes the proposed MDRE approach for reverse-engi-neering iOS apps to Android Section 5 describes iSpecS-napshot from a technical viewpoint Section 6 discusses anevaluation of the tool through a case study conducted onrealistic third-party iOS applications Finally a discussionregarding the contributions achieved within this research andsome possible challenges and perspectives for future work arepresented in Section 7
2 Related Work
e literature review presented is based on a critical in-depthinvestigation of works published over the last seven yearswith regard to mobile reverse-engineering approaches
In [15] Franke et al investigate how to reverse-engineermobile application lifecycles by testingemethod is drivenby developerrsquos code and consists of four steps (1) Fullimplementation of the lifecycle methods (pause start anddestroy) (2) Log Injection printing some test logs inside thelifecycle methods (3) Transition-trigger detection identify acatalog of triggers and track the app behavior (4) Appli-cation lifecycle rebuild based on the logger data the de-veloper can rebuild a state model for the mobile app emain weakness in their approach is that they oblige de-veloper to hard code logs in order to achieve this taskerefore there is no automation effort such as imple-menting a plugin which can perform source code analysisand detect the possible lifecycle methods and potential eventbehaviors
In [16] Joorabchi and Mesbah propose a reverse-engi-neering technique based on dynamic analysis in order togenerate a state model of a running iOS application isapproach aims to capture the user interface states and tran-sitions between them e authors have endorsed their tech-nique by a tool called ICRAWLER is approach howeverhas not been able to describe correctly all the UI part char-acteristics (graphic information UI classes event types etc)
e study carried out by Yang et al [17] addresses theissue of automated GUI-model generation for mobile ap-plications ey introduce a grey-box approach for auto-matically extracting a model of a given mobile applicatione approach aims to extracts using a static analysis all thesupported events by the GUI components of the applicationen it uses a dynamic crawling process for reverse-engi-neering a model of the application by applyingmdashon theflymdashthe extracted events on the running application eauthors have developed a tool for Android platform calledOrbit which is composed of an action detector modulebased onWALA (TJ Watson Libraries for Analysis WALAhttpsgithubcomwalaWALA) and a dynamic crawlerbuilt on top of Robotium (Robotium httpsgithubcomRobotiumTechrobotium)
In [18] Salva and Zafimiharisoa propose a formal modelinference approach for mobile application by automatictesting e approach aims to store rich details about theencountered interfaces and help to reduce the applicationexploration by using the Ant Colony Optimisation ACOstrategy e method is more suitable for performing an
STS model (Symbolic Transition System) and test casegeneration
In [19] Morgado et al present an approach for testingmobile applications using reverse engineering and behav-ioral patterns e aim of their work consists of defining acatalogue of mobile GUI behavioral patterns and using ahybrid reverse-engineering tool based on Yang et alrsquos ap-proach [17] e tool helps to automatically explore mobileapplication identifying patterns and applying the predefinedtest
In [20] Nguyen and Csallner introduce a techniquecalled REMAUI for inferring mobile application user in-terface code from screenshots or conceptual drawingsHence from a given input bitmap REMAUI identifies userinterface elements such as images texts containers and listsvia computer vision and optical character recognition(OCR) techniques REMAUI merges OCR and computervision results and in the merged data identifies the commonstructures such as lists or images REMAUI then recognizesaligned text blocks groups them into a layout container andexports the recognized text fragments as an Android re-source file A major weakness of this technique is that it isnot well suited to recognize complex composite componentsuch as menumenu item calendar segmented controls oreven radio groupe core of the technique might have beenmore interesting had the authors exploited the MDE par-adigm during the OCR recognition phase us it will allowproducing rich PSM (platform-specific model) models thatdescribe in a more complete way the conceptual drawings
Lamhaddab and Elbaamrani in [21] investigate how to usegraph-based modeling in reverse engineering of mobile ap-plications e authors use a static analysis of the mobile appsource code in order to produce a representative graphmodelof the source app e generated graph model can betransformed via semantic rules to another graph modelaccording to a target mobile metamodel Both the source andthe target graph models are stored in a graph database estudy concludes that graph-based modeling provides ad-vantages such as flexibility regarding the relationship betweengraph nodes data consolidation and the ease of navigationinside graph models thanks to a specific query language
To overcome the challenge of how to avoid stateless eventflow graph (EFG) ofmobile applicationGUI Amalfitano et alin [22] present a GUI-driven testing framework for Androidapps called MobiGUITAR e framework is based on threesteps (1) reverse engineering the state-machine model fromthe running app and creating abstractions of the machine (2)generating test cases and (3) replaying the test casesAccording to the study MobiGUITAR produces severaltesting artifacts (such as Crash Report Finite State-MachineFSM Model GUI Sequences and JUnit test cases)
In another study by Dugerdil and Sako in [23] theauthors present a reverse-engineering process to recover thefunctional structure of mobile apps e approach consistsof three steps (1) using code instrumentation by insertingextra statements in the source code which helps to recordevents (2) recording the execution trace in a flat file formatand (3) performing an offline analysis of the execution traceto retrieve the use cases of the mobile app using many views
Mobile Information Systems 3
Another contribution by Salihu et al [24] proposes ahybrid technique for reverse-engineering the GUI modelfrom Android apps e researchers have developed a toolcalled AMOGA that combines static and dynamic analysise tool performs a static analysis of mobile applicationbinaries to automatically extract GUI information en itinstructs a dynamic crawling to explore and reverse-engi-neer a model of the mobile app
Morgado and Paiva [25] developed a tool named iMPActfor supporting the automatic testing of mobile apps based onthe presence of recurring behavior UI Pattern e meth-odology used in this study was fully automated and it isbased on two steps first crawling the application byidentifying a UI pattern and then interacting with it byapplying a test strategy
A field study approach is applied by Chen et al [26] toinvestigate automating visual understanding of mobile UIdesign to generate a mobile GUI skeleton rough theirstudy a neural machine translator is developed whichcombines a vision convolutional neural network (CNN) anda recurrent neural network (RNN) [27] encoderdecodere translator consists of extracting visual features in UIdesign encoding feature spatial layouts and generating GUIskeletons With the similar focus another case study byBeltramelli [28] contributes to this line of research bypresenting an approach based on convolutional and Re-current neural networks combined with a specific DSLwhich helps to generate from GUI screenshot the corre-sponding source code for different platforms (ie iOSAndroid and web-based technologies) e technique wastrained on a relatively small dataset and requires moreimprovements to recognize vectorial representation eauthor argues that generative adversarial networks (GAN)s[29] could potentially be used in combination with pix2codemodel to improve results
A recent testing technique that is GUI exploration basedis introduced by Amalfitano et al [30]e approach aims toexploit human involvement in the automated process toaddress the challenge of exploring Gate GUIs which requireto be exercised with particular input event sequences eauthors present jugular a hybrid GUI exploration toolcombining automated GUI exploration with capture andreplay by exploiting a machine-learning approach
e previous studies were categorized according to theontology presented initially by Cornelissen et al [31] andrefined according to the mobile reverse-engineering contextby Morgado et al [19] e main aspects to classify theselected approaches included
(i) Goal the main aims of the studied approach(program comprehension model recovery patternidentification verification and validation etc)
(ii) Target the target platform (iOS Android Web) orthe relevant input artifact (UI drawing screen-shots) which is concerned by the study
(iii) Method this refers to what type of analysis per-formed by each approach on the source artifactsie static dynamic or hybrid
(iv) Technique this indicates the implemented tech-nique for reverse engineeringcomprehending theconsidered system (instrumentation code in-jection parsing crawling etc)
(v) Extracted information this specifies the key in-formation extracted by the adopted method (run-time behavior event sequence UI states crashdetection etc)
(vi) Output this indicates in which forms the resultswill be generated (call graph finite state machinereport test suite etc)
(vii) Validation by what means the approach has beenvalidated (case studies comparison with othertoolsapproaches evaluation)
Table 1 summarizes the result of the classification of theprevious studies according to the ontology criteria presentedby Morgado [32]
Based on this in-depth critical analysis of previousworks there remainmany gaps that have not been tackled byrecent research In fact the main challenges covered in thesestudies can be grouped in three topics test automationprogram comprehension and mobile UI drawing Con-siderable gap that warrant particular attention is that none ofthe previous research have addressed the full reverse engi-neering from one platform to another platform In additionmost of these approaches which rely on static analysis of thesource code have not take advantages of the use of themodel-driven engineering (MDE) paradigms in order tobetter comprehend the studied system Only the attemptintroduced by Lamhaddab and Elbaamrani [21] approachedthe reverse-engineering of mobile apps by focusing ongraph-based models We believe that the MDRE approachcan bring a considerable gain regarding detection of be-havior and UI patterns GUI explorations machine stateidentification or event handling
3 Empirical Study Design
In this section the authors present the empirical studydesign of this research ey discuss the methods used fordata collection and data analysis
31 Data Collection e first step of this research meth-odology is to perform a literature survey of the relevantpublished works regarding mobile reverse-engineering fieldas presented in Section 2 e aim of this phase is to conducta deep critical analysis of previous works and identify whichcurrent gaps remain in reverse-engineering mobile platformtechniques to attempt to solve the gaps
e second phase aims to collect the mobile developersrsquoneeds e objective of this study is to investigate the realchallenges faced by mobile developers during the mobileporting process and to identify insight into the aspects andtechnical axis that must be covered when designing theproposed tool erefore it was important to gather datafrom various stakeholders involved in mobile applications
4 Mobile Information Systems
Table 1 Classification of the related mobile reverse-engineering techniques in terms of goal target method extracted information outputand validation
Study Goal Target Method Technique Extractedinformation Output Validation
Frank et al [15]Program
ComprehensionFeature location
iOSAndroidJava ME
Static InstrumentationCode injection
RuntimebehaviorEvent
sequence
Call graphReport Case study
Joorabchi andMesbah [16] Model recovery iOS Dynamic Crawling
Event handling
RuntimebehaviorUser
interfacestates
Finite state machine Case study
Yang et al [17] Model recovery Android HybridCrawling
Event handlingParsing
RuntimebehaviourEvent
Sequence
Finite state machineCase studyComparisonEvaluation
Salva andZafimiharisoa[18]
Verification andvalidation
Model recoveryAndroid Dynamic Crawling
Runtimebehaviour
UserinterfacestatesCrash
detection
Call graphFinite state machine
Test suite
ComparisonEvaluation
Morgado et al[19] 2014
Verification andvalidationPattern
identification
Android Hybrid
CrawlingEvent handling
ParsingInstrumentation
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
Case studyComparison
Nguyen andCsallner [20]
User interfaceidentification
MobileUI design Static
Optical characterrecognition OCREvent handling
Userinterfacewidgets
Computervision
Android UI skeleton Case studyEvaluation
Lamhaddab andElbaamrani[21] Porting iOS Static
ParsingGraph modeling
Modeltransformation
Source codeASTUser
interfaceWidgetsUser
interfaceSequences
Graph models for sourceplatform (iOS)
Graph models for targetplatform (Android)
ComparisonEvaluation
AmalFitano et al[22]
Verification andvalidation
Model recoveryAndroid Dynamic
RippingInstrumentationTest Generation
CrashdetectionBugs
Call graphReport
Test suiteFinite state machine
Case studyComparisonEvaluation
Dugerdil andSako [23]
ProgramcomprehensionMaintenance
iOS Static InstrumentationCode injection
RuntimebehaviourEvent
Sequence
Report Case studyEvaluation
Salihu et al [24] Model recovery Android HybridCrawling
Event handlingParsing
Runtimebehaviour
Userinterfacestates
Finite state machine ComparisonEvaluation
Morgado andPaiva [25]
Verification andvalidationPattern
identification
Android DynamicCrawling
Event handlingParsing
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
ComparisonEvaluation
Mobile Information Systems 5
development Interview participants were recruited throughthe subscriber database of MyAppConverter (MyApp-Converter httpwwwmyappconvertercom) platformerefore candidates have been selected via an e-mailcampaign that highlights the road map of the new tool andwhich encourage subscribers to participate in the surveyeauthors have selected 20 Android developers and 15 iOSdevelopers with 2 to 5 years of experience In addition theyhave targeted 10 product owners who are not necessarilydevelopers but rather business analysts To approve theinterview questionnaire the authors have hired a small teamfrom MyAppConverter composed of two senior mobiledevelopers (iOS amp Android) and one functional analyst leadey recruited a total of 45 interview participants andscheduled 15 to 20minutes conference calls for conductinginterviews based on their availability It should be noted thatall the participants were ensured about the confidentiality oftheir personal information and data
Moreover three variants of questionnaires were ad-ministered to three categories iOS developers Androiddevelopers and product owners e purposes of thesequestionnaires are to identify the best practices and tech-niques widely used to design the UI part of iOS applicationslist the components that present difficulties when they areported to Android and define the key information that willhelp in the functional understanding during the portingprocess
32 Data Analysis After collecting the practitionersrsquo re-sponses the authors analyzed carefully the data in order todetermine the proposed toolrsquos features It is worth notingthat real-world practitioners support the research as themajority of the 45 interviewees agreed that implementing atool which can reverse-engineer the functional specifications
and port the UI storyboard and could contribute sub-stantially on time and cost of mobile porting project
With regard to the questionnaire that targets productowners 70 of the respondents agreed that the proposed toolshould represent the functional requirements as use casesformat In use cases template the functional requirements areunderstood in the context of user action which typicallyavoid a lot of ambiguity that makes its way into an out-ofcontext list of system However 30 of the respondentsprefer to represent the functional spec in an agile form such asuser stories ey argued that the user story form is highlyeffective at capturing and linking user goals functional re-quirements and business benefits Overall 95 of the in-terviewees agreed that the functional spec document shouldinclude information about project team build informationdependencies constraints business class model entity modelscreens details activity diagram and business rules
e respondents of the questionnaire that was targetedthe iOS developers reflected that a high percentage (85 ofthem) use storyboard and xib files to design the UI layereyargue that the Interface Builder IDE within Xcode makes itmuch easier to design UI and flows without writing any codeIn addition storyboards are highly recommended withmultiple interconnected view controllers and eliminateboilerplate code to perform transition between view con-trollers However 15 of the respondents build UI pro-grammatically by writing Objective-C or Swift code eyargue that mastering the coding of iOS UI allows addressingviews with complex or dynamic layouts customizing tran-sition effects between view controllers and refactoring spe-cific views in a reusable fashion 65 used autolayout featurein order to define constraints to control how user interfacewill adapt on different screen sizes when device rotated orwhen the app run in different locales Overall 47 prefer touse third libraries to customize UI components instead of iOS
Table 1 Continued
Study Goal Target Method Technique Extractedinformation Output Validation
Chen et al [26] User interfaceidentification
MobileUI design Static
Neural machinetranslator
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
Userinterfacewidgets
Android UI skeleton Case studyEvaluation
Beltramelli [28] User interfaceidentification
MobileUI design Static
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
DSL
UserInterfaceWidgets
Android UI skeletoniOS UI skeletonWeb-based U
Case study
Amalfitano et al[30]
Verification andvalidation
Model RecoveryAndroid Hybrid
CrawlingInstrumentation
Input event sequenceMachine learning
RuntimebehaviorUser
interfacestatesHuman
involvement
Call graphFinite state machine
Test suiteReport
Case study
6 Mobile Information Systems
UIKit framework Additionally 90 used xib to designstatic table view cell and displaying dynamic data Fur-thermore they used code to define table view data sourceUITableViewDataSource (UITableViewDataSource httpsdeveloperapplecomdocumentationuikituitableviewdatasource) and UITableViewDelegate (UITableViewDelegatehttpsdeveloperapplecomdocumentationuikituitableviewdelegate) in order to manage cell selection and other featuresrelated to displaying the data
With regard to the questionnaire that targets the An-droid developers 90 of the respondents used xml layout todesign UI prototyping Overall 60 used small widthqualifier in order to adapt layout to respond gracefully todifferent screen sizes and orientations However 40 agreedthat it is preferable to use the constraint layout to create aresponsive UI In addition a high percentage (92) of therespondents recommend modularizing UI components withfragments (Android Fragments httpsdeveloperandroidcomguidecomponentsfragments) Overall 100 agreedthat it will be a tedious task to port some iOS UI componentssuch as Attributed TextView TableView Collection ViewController Page View Controller Split View Controller andCollection Reusable View Moreover all the intervieweesadmit that there is an additional effort to adapt iOS graphicassets for Android e best solution is to scale assets tocorrect size for relevant device screen Additionally all therespondents confirm that it is not obvious to find anequivalent for custom UI components in most cases de-velopers are limited to using the closest Android UI standardcomponents based on Googlersquos guidelines
4 Proposed Approach
is section outlines the model-driven reverse-engineering(MDRE) approach followed in iSpecSnapshot e authorsrsquovision is to approach MDRE from a new context which ismobile development ey will try to provide answers toenrich the reverse-engineering literature with a hot topicwhich addresses porting mobile applications from iOS toAndroid e present work closely seeks to address reverseengineering of the documentation and UI of an iOS ap-plication e current contribution sheds the light on usingMDRE paradigm to identify the main steps and modelingstandards with the purpose to propose a more generic andextendable approach
Specifically in their method the authors proceed in thesame way as the Fleurey et al [33] by adopting their MDREsteps with some alterations code to PSM PSM to PIM PIMto PSM and PSM to code e particularity of the authorsrsquoapproach is that all the adopted metamodels are based onKDM and ASTM standards (see Appendix B) Hence theproposed process is depicted in Figure 1 and consists of fourmain steps
(i) Model discovery (code to PSM)(ii) Model semantic extraction (PSM to PIM)(iii) Model transformation (PIM to PSM)(iv) Model to code generation (PSM to code)
As running examples the authors have chosen threeopen sourced projects from Apple sample code Library andGithub Table 2 shows resource link details for each runningexample (ID name and resource link)
Table 3 reports some metrics of each running examplenumber of the source code files (header and main files) sizeof the source files number of used storyboardxib files andthe number of the static UI elements
41 Step 1 Model Discovery Model discovery is a parsingstep which aims to parse the source mobile app artifacts inorder to produce a set of representative models ese so-called initial models have a strong dependency with thecomponents of the source app they are commonly describedby the OMG as platform-specific models (PSMs) (see Ap-pendix A) e implementation of this step depends on thetechnology of the source mobile platform It is based mainlyon the static analysis to automatically generate PSM modelsfrom source code artifacts Typically an iOS app is com-posed by programming language files (h m Swift ccpp) platform-specific files (storyboard pch pliststring) asset files (png jpeg bmp) and data files(xcdatamodeld xml json)
In the initial stage it is wise to first define all themetamodels that describe the source mobile platform In-deed as mentioned in Figure 2 the authors distinguish fourvariants of metamodels technological infrastructure ap-plicative and data metamodels
e technological metamodel describes the programinglanguages used in the source mobile platform It inheritsmainly from the OMG ASTM metamodel For instance forthe iOS mobile platform the authors define ASTM meta-models for the commonly used programming languagessuch as C C++ Objective-C and Swift Figure 3 illustratesan excerpt of the Objective-C metamodel (metamodeling ofthe Objective-C block expression (Objective-C block httpsdeveloperapplecomlibraryarchivedocumentationCocoaConceptualBlocksArticles00_Introductionhtmlapple_refdocuidTP40007502-CH1-SW1))
e infrastructure metamodel defines the tree structureand relative paths of the source mobile app (folders subfolders files assets resources etc) It inherits mainly fromthe OMG KDM metamodel Figure 4 shows an overview ofthe iOS xcode project metamodel
e applicative metamodel defines mainly specific in-formation regarding the source mobile platform includingbuild settings dependencies compiler executable nameand static UI workflow It is designed according to theofficial iOS documentation (UIKit official documentationhttpsdeveloperapplecomdocumentationuikit) Figure 5shows an overview of the metamodel specific to the UI part(xib file)
emodel discovery step is performed through platformparsers which are specific to the source platform e au-thors have set up four kinds of parsers
(i) Infrastructure parsers allow generating a physicalmodel of the source application is model con-tains all the tree structure and relative paths of the
Mobile Information Systems 7
source mobile app (folders sub folders files assetsresources etc) e generated model is conformedto the Xcode Project KDM metamodel
(ii) Technological parsers allow generating abstractsyntax models of all the programming language filesused in the source application (eg C C++ Ob-jective-C and Swift) At this stage all the generatedmodels conform to the technological ASTMmetamodels
(iii) Applicative parsers allow building applicativemodels which are specific to some key artifact ofthe source platform (eg workspace file xcode-proj file pch file plist file xib file Pod file etc)Generally these artifacts include informationabout the source platform namely build settingsdependencies compiler executable name andstatic UI workflow ese models (eg Algo-rithm 1) are designed according to the applicativemetamodels
(iv) Data parsers allow building data models which arestatically stored in the file system (eg xdatamodelfile json file xml file etc)ese models conform totypical metamodels
42 Step 2 Semantic Extraction e semantic extractionstep is considered as a halfway point between code-to-modeland model-to-model steps In fact it aims to analyze thePSM models in order to extract some useful semantic in-formation which is required to build the PIM model eextraction process is designed to be iterative and supportsboth technological and applicative models is process isdriven by a set of semantic extractors that identify collectand consolidate all the semantic data required to build thesemantic mobile model PIM which is an instance of thesemantic mobile metamodel e authors have opted for ageneric metamodel which represents in a semantic mannerany mobile application e proposed metamodel is theresult of a close collaboration with two senior mobile
OMG standard metamodelsKDM ASTM SMM
Mobile platform Ametamodels
Semantic mobilemetamodels
Mobile platform Bmetamodels
Metamodel
ModelConforms to
Target mobilePSMs
32
1
TransformationSemantic model
PIM
Conforms to
Semanticextraction
Source mobilePSMs
Conforms to
Discovery
Source mobileapplication
mobile platform A
Target mobileapplication
mobile platform B
Codegeneration
Code
4
User inherits from
Figure 1 Main steps of the proposed MDRE approach to reverse-engineer a mobile app code to PSM PSM to PIM PIM to PSM and PSMto code
Table 2 Running examples open-source native iOS apps
ID Resource name Resource source link1 eSimpliestTodoList httpsgithubcomaltaibayareSimpliestTodoList
2 UIKitCataloguehttpsdeveloperapplecomlibrarycontent
samplecodeuicatalogIntroductionIntrohtmlapple_refdocuidDTS40007710
3 Tabsterhttpsdeveloperapplecomlibrarycontent
samplecodeTabsterIntroductionIntrohtmlapple_refdocuidDTS40011213
Table 3 Metrics of the running examples
ID No of source files (hm) Size of source file (KB) No of storyboard (xib file) No of UI elements Xcode build (SDK)1 10 30 1 26 72902 50 192 2 157 72903 22 22 3 31 7290
8 Mobile Information Systems
Mobile platform AASTM metamodel
Mobile platform AKDM metamodel
Mobile platform Aapplicativemetamodel
Datametamodel
DataPSM
Parsers
1 Model discovery
ApplicativePSM
InfrastructurePSM
TechnologicalPSM
Conforms to
Code to PSM
Programminglanguage files
Specific artifactsplatform
Assetfiles
Datafiles
Mobile app physical structure
Source mobileapplication
Mobile platform A
Figure 2 First step of the proposed MDRE approach model discovery (code to PSM)
BreakStatement
objcExpression
BlockStatement
Extends
Extends
ExtendsExtends
Extends
Statement
ContinueStatement
ExpressionStatement
IfStatement
WhileStatement
SwitchStatement
Extends
Extends
Extends
Extends
ForStatement
AstmObject
AstmSyntaxObject 1
1
1
1
1
ObjcBlockExpression
formalParameters
FormalParameterDefinition
+ aliasName EString
+ synthesizedName EString + nameString EString
accessKind
AccessKind Name
Identifier Name1
1
+ includeUnitSource EString
+ comment EString
1 lowast
ExtendsExtends
SourceLocation
AnnotationExpression
TypeReference
loctionInfo
ownedObjects
Extends
Extends
lowastExpression
expressionType
definitionType Definition
Extends
Extends
DeclarationOrDefinition
+ isClassAttr EBoolean
+ isProtocolimpl EBoolean
ExtendsinitialValue
DataDefinition
+ isMutable EBoolean
body1
lowastExtends
lowast
KDMEntity
DefinitionObject
Figure 3 Technological metamodel an excerpt of the ASTmetamodel corresponding to the Objective-C block expression e key entitiesare ObjcBlockExpression Expression Statement FormalParameterDefinition TypeReference AccessKind AstmObject KDMEntity etc
Mobile Information Systems 9
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
presents the empirical study design of our research Section 4describes the proposed MDRE approach for reverse-engi-neering iOS apps to Android Section 5 describes iSpecS-napshot from a technical viewpoint Section 6 discusses anevaluation of the tool through a case study conducted onrealistic third-party iOS applications Finally a discussionregarding the contributions achieved within this research andsome possible challenges and perspectives for future work arepresented in Section 7
2 Related Work
e literature review presented is based on a critical in-depthinvestigation of works published over the last seven yearswith regard to mobile reverse-engineering approaches
In [15] Franke et al investigate how to reverse-engineermobile application lifecycles by testingemethod is drivenby developerrsquos code and consists of four steps (1) Fullimplementation of the lifecycle methods (pause start anddestroy) (2) Log Injection printing some test logs inside thelifecycle methods (3) Transition-trigger detection identify acatalog of triggers and track the app behavior (4) Appli-cation lifecycle rebuild based on the logger data the de-veloper can rebuild a state model for the mobile app emain weakness in their approach is that they oblige de-veloper to hard code logs in order to achieve this taskerefore there is no automation effort such as imple-menting a plugin which can perform source code analysisand detect the possible lifecycle methods and potential eventbehaviors
In [16] Joorabchi and Mesbah propose a reverse-engi-neering technique based on dynamic analysis in order togenerate a state model of a running iOS application isapproach aims to capture the user interface states and tran-sitions between them e authors have endorsed their tech-nique by a tool called ICRAWLER is approach howeverhas not been able to describe correctly all the UI part char-acteristics (graphic information UI classes event types etc)
e study carried out by Yang et al [17] addresses theissue of automated GUI-model generation for mobile ap-plications ey introduce a grey-box approach for auto-matically extracting a model of a given mobile applicatione approach aims to extracts using a static analysis all thesupported events by the GUI components of the applicationen it uses a dynamic crawling process for reverse-engi-neering a model of the application by applyingmdashon theflymdashthe extracted events on the running application eauthors have developed a tool for Android platform calledOrbit which is composed of an action detector modulebased onWALA (TJ Watson Libraries for Analysis WALAhttpsgithubcomwalaWALA) and a dynamic crawlerbuilt on top of Robotium (Robotium httpsgithubcomRobotiumTechrobotium)
In [18] Salva and Zafimiharisoa propose a formal modelinference approach for mobile application by automatictesting e approach aims to store rich details about theencountered interfaces and help to reduce the applicationexploration by using the Ant Colony Optimisation ACOstrategy e method is more suitable for performing an
STS model (Symbolic Transition System) and test casegeneration
In [19] Morgado et al present an approach for testingmobile applications using reverse engineering and behav-ioral patterns e aim of their work consists of defining acatalogue of mobile GUI behavioral patterns and using ahybrid reverse-engineering tool based on Yang et alrsquos ap-proach [17] e tool helps to automatically explore mobileapplication identifying patterns and applying the predefinedtest
In [20] Nguyen and Csallner introduce a techniquecalled REMAUI for inferring mobile application user in-terface code from screenshots or conceptual drawingsHence from a given input bitmap REMAUI identifies userinterface elements such as images texts containers and listsvia computer vision and optical character recognition(OCR) techniques REMAUI merges OCR and computervision results and in the merged data identifies the commonstructures such as lists or images REMAUI then recognizesaligned text blocks groups them into a layout container andexports the recognized text fragments as an Android re-source file A major weakness of this technique is that it isnot well suited to recognize complex composite componentsuch as menumenu item calendar segmented controls oreven radio groupe core of the technique might have beenmore interesting had the authors exploited the MDE par-adigm during the OCR recognition phase us it will allowproducing rich PSM (platform-specific model) models thatdescribe in a more complete way the conceptual drawings
Lamhaddab and Elbaamrani in [21] investigate how to usegraph-based modeling in reverse engineering of mobile ap-plications e authors use a static analysis of the mobile appsource code in order to produce a representative graphmodelof the source app e generated graph model can betransformed via semantic rules to another graph modelaccording to a target mobile metamodel Both the source andthe target graph models are stored in a graph database estudy concludes that graph-based modeling provides ad-vantages such as flexibility regarding the relationship betweengraph nodes data consolidation and the ease of navigationinside graph models thanks to a specific query language
To overcome the challenge of how to avoid stateless eventflow graph (EFG) ofmobile applicationGUI Amalfitano et alin [22] present a GUI-driven testing framework for Androidapps called MobiGUITAR e framework is based on threesteps (1) reverse engineering the state-machine model fromthe running app and creating abstractions of the machine (2)generating test cases and (3) replaying the test casesAccording to the study MobiGUITAR produces severaltesting artifacts (such as Crash Report Finite State-MachineFSM Model GUI Sequences and JUnit test cases)
In another study by Dugerdil and Sako in [23] theauthors present a reverse-engineering process to recover thefunctional structure of mobile apps e approach consistsof three steps (1) using code instrumentation by insertingextra statements in the source code which helps to recordevents (2) recording the execution trace in a flat file formatand (3) performing an offline analysis of the execution traceto retrieve the use cases of the mobile app using many views
Mobile Information Systems 3
Another contribution by Salihu et al [24] proposes ahybrid technique for reverse-engineering the GUI modelfrom Android apps e researchers have developed a toolcalled AMOGA that combines static and dynamic analysise tool performs a static analysis of mobile applicationbinaries to automatically extract GUI information en itinstructs a dynamic crawling to explore and reverse-engi-neer a model of the mobile app
Morgado and Paiva [25] developed a tool named iMPActfor supporting the automatic testing of mobile apps based onthe presence of recurring behavior UI Pattern e meth-odology used in this study was fully automated and it isbased on two steps first crawling the application byidentifying a UI pattern and then interacting with it byapplying a test strategy
A field study approach is applied by Chen et al [26] toinvestigate automating visual understanding of mobile UIdesign to generate a mobile GUI skeleton rough theirstudy a neural machine translator is developed whichcombines a vision convolutional neural network (CNN) anda recurrent neural network (RNN) [27] encoderdecodere translator consists of extracting visual features in UIdesign encoding feature spatial layouts and generating GUIskeletons With the similar focus another case study byBeltramelli [28] contributes to this line of research bypresenting an approach based on convolutional and Re-current neural networks combined with a specific DSLwhich helps to generate from GUI screenshot the corre-sponding source code for different platforms (ie iOSAndroid and web-based technologies) e technique wastrained on a relatively small dataset and requires moreimprovements to recognize vectorial representation eauthor argues that generative adversarial networks (GAN)s[29] could potentially be used in combination with pix2codemodel to improve results
A recent testing technique that is GUI exploration basedis introduced by Amalfitano et al [30]e approach aims toexploit human involvement in the automated process toaddress the challenge of exploring Gate GUIs which requireto be exercised with particular input event sequences eauthors present jugular a hybrid GUI exploration toolcombining automated GUI exploration with capture andreplay by exploiting a machine-learning approach
e previous studies were categorized according to theontology presented initially by Cornelissen et al [31] andrefined according to the mobile reverse-engineering contextby Morgado et al [19] e main aspects to classify theselected approaches included
(i) Goal the main aims of the studied approach(program comprehension model recovery patternidentification verification and validation etc)
(ii) Target the target platform (iOS Android Web) orthe relevant input artifact (UI drawing screen-shots) which is concerned by the study
(iii) Method this refers to what type of analysis per-formed by each approach on the source artifactsie static dynamic or hybrid
(iv) Technique this indicates the implemented tech-nique for reverse engineeringcomprehending theconsidered system (instrumentation code in-jection parsing crawling etc)
(v) Extracted information this specifies the key in-formation extracted by the adopted method (run-time behavior event sequence UI states crashdetection etc)
(vi) Output this indicates in which forms the resultswill be generated (call graph finite state machinereport test suite etc)
(vii) Validation by what means the approach has beenvalidated (case studies comparison with othertoolsapproaches evaluation)
Table 1 summarizes the result of the classification of theprevious studies according to the ontology criteria presentedby Morgado [32]
Based on this in-depth critical analysis of previousworks there remainmany gaps that have not been tackled byrecent research In fact the main challenges covered in thesestudies can be grouped in three topics test automationprogram comprehension and mobile UI drawing Con-siderable gap that warrant particular attention is that none ofthe previous research have addressed the full reverse engi-neering from one platform to another platform In additionmost of these approaches which rely on static analysis of thesource code have not take advantages of the use of themodel-driven engineering (MDE) paradigms in order tobetter comprehend the studied system Only the attemptintroduced by Lamhaddab and Elbaamrani [21] approachedthe reverse-engineering of mobile apps by focusing ongraph-based models We believe that the MDRE approachcan bring a considerable gain regarding detection of be-havior and UI patterns GUI explorations machine stateidentification or event handling
3 Empirical Study Design
In this section the authors present the empirical studydesign of this research ey discuss the methods used fordata collection and data analysis
31 Data Collection e first step of this research meth-odology is to perform a literature survey of the relevantpublished works regarding mobile reverse-engineering fieldas presented in Section 2 e aim of this phase is to conducta deep critical analysis of previous works and identify whichcurrent gaps remain in reverse-engineering mobile platformtechniques to attempt to solve the gaps
e second phase aims to collect the mobile developersrsquoneeds e objective of this study is to investigate the realchallenges faced by mobile developers during the mobileporting process and to identify insight into the aspects andtechnical axis that must be covered when designing theproposed tool erefore it was important to gather datafrom various stakeholders involved in mobile applications
4 Mobile Information Systems
Table 1 Classification of the related mobile reverse-engineering techniques in terms of goal target method extracted information outputand validation
Study Goal Target Method Technique Extractedinformation Output Validation
Frank et al [15]Program
ComprehensionFeature location
iOSAndroidJava ME
Static InstrumentationCode injection
RuntimebehaviorEvent
sequence
Call graphReport Case study
Joorabchi andMesbah [16] Model recovery iOS Dynamic Crawling
Event handling
RuntimebehaviorUser
interfacestates
Finite state machine Case study
Yang et al [17] Model recovery Android HybridCrawling
Event handlingParsing
RuntimebehaviourEvent
Sequence
Finite state machineCase studyComparisonEvaluation
Salva andZafimiharisoa[18]
Verification andvalidation
Model recoveryAndroid Dynamic Crawling
Runtimebehaviour
UserinterfacestatesCrash
detection
Call graphFinite state machine
Test suite
ComparisonEvaluation
Morgado et al[19] 2014
Verification andvalidationPattern
identification
Android Hybrid
CrawlingEvent handling
ParsingInstrumentation
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
Case studyComparison
Nguyen andCsallner [20]
User interfaceidentification
MobileUI design Static
Optical characterrecognition OCREvent handling
Userinterfacewidgets
Computervision
Android UI skeleton Case studyEvaluation
Lamhaddab andElbaamrani[21] Porting iOS Static
ParsingGraph modeling
Modeltransformation
Source codeASTUser
interfaceWidgetsUser
interfaceSequences
Graph models for sourceplatform (iOS)
Graph models for targetplatform (Android)
ComparisonEvaluation
AmalFitano et al[22]
Verification andvalidation
Model recoveryAndroid Dynamic
RippingInstrumentationTest Generation
CrashdetectionBugs
Call graphReport
Test suiteFinite state machine
Case studyComparisonEvaluation
Dugerdil andSako [23]
ProgramcomprehensionMaintenance
iOS Static InstrumentationCode injection
RuntimebehaviourEvent
Sequence
Report Case studyEvaluation
Salihu et al [24] Model recovery Android HybridCrawling
Event handlingParsing
Runtimebehaviour
Userinterfacestates
Finite state machine ComparisonEvaluation
Morgado andPaiva [25]
Verification andvalidationPattern
identification
Android DynamicCrawling
Event handlingParsing
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
ComparisonEvaluation
Mobile Information Systems 5
development Interview participants were recruited throughthe subscriber database of MyAppConverter (MyApp-Converter httpwwwmyappconvertercom) platformerefore candidates have been selected via an e-mailcampaign that highlights the road map of the new tool andwhich encourage subscribers to participate in the surveyeauthors have selected 20 Android developers and 15 iOSdevelopers with 2 to 5 years of experience In addition theyhave targeted 10 product owners who are not necessarilydevelopers but rather business analysts To approve theinterview questionnaire the authors have hired a small teamfrom MyAppConverter composed of two senior mobiledevelopers (iOS amp Android) and one functional analyst leadey recruited a total of 45 interview participants andscheduled 15 to 20minutes conference calls for conductinginterviews based on their availability It should be noted thatall the participants were ensured about the confidentiality oftheir personal information and data
Moreover three variants of questionnaires were ad-ministered to three categories iOS developers Androiddevelopers and product owners e purposes of thesequestionnaires are to identify the best practices and tech-niques widely used to design the UI part of iOS applicationslist the components that present difficulties when they areported to Android and define the key information that willhelp in the functional understanding during the portingprocess
32 Data Analysis After collecting the practitionersrsquo re-sponses the authors analyzed carefully the data in order todetermine the proposed toolrsquos features It is worth notingthat real-world practitioners support the research as themajority of the 45 interviewees agreed that implementing atool which can reverse-engineer the functional specifications
and port the UI storyboard and could contribute sub-stantially on time and cost of mobile porting project
With regard to the questionnaire that targets productowners 70 of the respondents agreed that the proposed toolshould represent the functional requirements as use casesformat In use cases template the functional requirements areunderstood in the context of user action which typicallyavoid a lot of ambiguity that makes its way into an out-ofcontext list of system However 30 of the respondentsprefer to represent the functional spec in an agile form such asuser stories ey argued that the user story form is highlyeffective at capturing and linking user goals functional re-quirements and business benefits Overall 95 of the in-terviewees agreed that the functional spec document shouldinclude information about project team build informationdependencies constraints business class model entity modelscreens details activity diagram and business rules
e respondents of the questionnaire that was targetedthe iOS developers reflected that a high percentage (85 ofthem) use storyboard and xib files to design the UI layereyargue that the Interface Builder IDE within Xcode makes itmuch easier to design UI and flows without writing any codeIn addition storyboards are highly recommended withmultiple interconnected view controllers and eliminateboilerplate code to perform transition between view con-trollers However 15 of the respondents build UI pro-grammatically by writing Objective-C or Swift code eyargue that mastering the coding of iOS UI allows addressingviews with complex or dynamic layouts customizing tran-sition effects between view controllers and refactoring spe-cific views in a reusable fashion 65 used autolayout featurein order to define constraints to control how user interfacewill adapt on different screen sizes when device rotated orwhen the app run in different locales Overall 47 prefer touse third libraries to customize UI components instead of iOS
Table 1 Continued
Study Goal Target Method Technique Extractedinformation Output Validation
Chen et al [26] User interfaceidentification
MobileUI design Static
Neural machinetranslator
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
Userinterfacewidgets
Android UI skeleton Case studyEvaluation
Beltramelli [28] User interfaceidentification
MobileUI design Static
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
DSL
UserInterfaceWidgets
Android UI skeletoniOS UI skeletonWeb-based U
Case study
Amalfitano et al[30]
Verification andvalidation
Model RecoveryAndroid Hybrid
CrawlingInstrumentation
Input event sequenceMachine learning
RuntimebehaviorUser
interfacestatesHuman
involvement
Call graphFinite state machine
Test suiteReport
Case study
6 Mobile Information Systems
UIKit framework Additionally 90 used xib to designstatic table view cell and displaying dynamic data Fur-thermore they used code to define table view data sourceUITableViewDataSource (UITableViewDataSource httpsdeveloperapplecomdocumentationuikituitableviewdatasource) and UITableViewDelegate (UITableViewDelegatehttpsdeveloperapplecomdocumentationuikituitableviewdelegate) in order to manage cell selection and other featuresrelated to displaying the data
With regard to the questionnaire that targets the An-droid developers 90 of the respondents used xml layout todesign UI prototyping Overall 60 used small widthqualifier in order to adapt layout to respond gracefully todifferent screen sizes and orientations However 40 agreedthat it is preferable to use the constraint layout to create aresponsive UI In addition a high percentage (92) of therespondents recommend modularizing UI components withfragments (Android Fragments httpsdeveloperandroidcomguidecomponentsfragments) Overall 100 agreedthat it will be a tedious task to port some iOS UI componentssuch as Attributed TextView TableView Collection ViewController Page View Controller Split View Controller andCollection Reusable View Moreover all the intervieweesadmit that there is an additional effort to adapt iOS graphicassets for Android e best solution is to scale assets tocorrect size for relevant device screen Additionally all therespondents confirm that it is not obvious to find anequivalent for custom UI components in most cases de-velopers are limited to using the closest Android UI standardcomponents based on Googlersquos guidelines
4 Proposed Approach
is section outlines the model-driven reverse-engineering(MDRE) approach followed in iSpecSnapshot e authorsrsquovision is to approach MDRE from a new context which ismobile development ey will try to provide answers toenrich the reverse-engineering literature with a hot topicwhich addresses porting mobile applications from iOS toAndroid e present work closely seeks to address reverseengineering of the documentation and UI of an iOS ap-plication e current contribution sheds the light on usingMDRE paradigm to identify the main steps and modelingstandards with the purpose to propose a more generic andextendable approach
Specifically in their method the authors proceed in thesame way as the Fleurey et al [33] by adopting their MDREsteps with some alterations code to PSM PSM to PIM PIMto PSM and PSM to code e particularity of the authorsrsquoapproach is that all the adopted metamodels are based onKDM and ASTM standards (see Appendix B) Hence theproposed process is depicted in Figure 1 and consists of fourmain steps
(i) Model discovery (code to PSM)(ii) Model semantic extraction (PSM to PIM)(iii) Model transformation (PIM to PSM)(iv) Model to code generation (PSM to code)
As running examples the authors have chosen threeopen sourced projects from Apple sample code Library andGithub Table 2 shows resource link details for each runningexample (ID name and resource link)
Table 3 reports some metrics of each running examplenumber of the source code files (header and main files) sizeof the source files number of used storyboardxib files andthe number of the static UI elements
41 Step 1 Model Discovery Model discovery is a parsingstep which aims to parse the source mobile app artifacts inorder to produce a set of representative models ese so-called initial models have a strong dependency with thecomponents of the source app they are commonly describedby the OMG as platform-specific models (PSMs) (see Ap-pendix A) e implementation of this step depends on thetechnology of the source mobile platform It is based mainlyon the static analysis to automatically generate PSM modelsfrom source code artifacts Typically an iOS app is com-posed by programming language files (h m Swift ccpp) platform-specific files (storyboard pch pliststring) asset files (png jpeg bmp) and data files(xcdatamodeld xml json)
In the initial stage it is wise to first define all themetamodels that describe the source mobile platform In-deed as mentioned in Figure 2 the authors distinguish fourvariants of metamodels technological infrastructure ap-plicative and data metamodels
e technological metamodel describes the programinglanguages used in the source mobile platform It inheritsmainly from the OMG ASTM metamodel For instance forthe iOS mobile platform the authors define ASTM meta-models for the commonly used programming languagessuch as C C++ Objective-C and Swift Figure 3 illustratesan excerpt of the Objective-C metamodel (metamodeling ofthe Objective-C block expression (Objective-C block httpsdeveloperapplecomlibraryarchivedocumentationCocoaConceptualBlocksArticles00_Introductionhtmlapple_refdocuidTP40007502-CH1-SW1))
e infrastructure metamodel defines the tree structureand relative paths of the source mobile app (folders subfolders files assets resources etc) It inherits mainly fromthe OMG KDM metamodel Figure 4 shows an overview ofthe iOS xcode project metamodel
e applicative metamodel defines mainly specific in-formation regarding the source mobile platform includingbuild settings dependencies compiler executable nameand static UI workflow It is designed according to theofficial iOS documentation (UIKit official documentationhttpsdeveloperapplecomdocumentationuikit) Figure 5shows an overview of the metamodel specific to the UI part(xib file)
emodel discovery step is performed through platformparsers which are specific to the source platform e au-thors have set up four kinds of parsers
(i) Infrastructure parsers allow generating a physicalmodel of the source application is model con-tains all the tree structure and relative paths of the
Mobile Information Systems 7
source mobile app (folders sub folders files assetsresources etc) e generated model is conformedto the Xcode Project KDM metamodel
(ii) Technological parsers allow generating abstractsyntax models of all the programming language filesused in the source application (eg C C++ Ob-jective-C and Swift) At this stage all the generatedmodels conform to the technological ASTMmetamodels
(iii) Applicative parsers allow building applicativemodels which are specific to some key artifact ofthe source platform (eg workspace file xcode-proj file pch file plist file xib file Pod file etc)Generally these artifacts include informationabout the source platform namely build settingsdependencies compiler executable name andstatic UI workflow ese models (eg Algo-rithm 1) are designed according to the applicativemetamodels
(iv) Data parsers allow building data models which arestatically stored in the file system (eg xdatamodelfile json file xml file etc)ese models conform totypical metamodels
42 Step 2 Semantic Extraction e semantic extractionstep is considered as a halfway point between code-to-modeland model-to-model steps In fact it aims to analyze thePSM models in order to extract some useful semantic in-formation which is required to build the PIM model eextraction process is designed to be iterative and supportsboth technological and applicative models is process isdriven by a set of semantic extractors that identify collectand consolidate all the semantic data required to build thesemantic mobile model PIM which is an instance of thesemantic mobile metamodel e authors have opted for ageneric metamodel which represents in a semantic mannerany mobile application e proposed metamodel is theresult of a close collaboration with two senior mobile
OMG standard metamodelsKDM ASTM SMM
Mobile platform Ametamodels
Semantic mobilemetamodels
Mobile platform Bmetamodels
Metamodel
ModelConforms to
Target mobilePSMs
32
1
TransformationSemantic model
PIM
Conforms to
Semanticextraction
Source mobilePSMs
Conforms to
Discovery
Source mobileapplication
mobile platform A
Target mobileapplication
mobile platform B
Codegeneration
Code
4
User inherits from
Figure 1 Main steps of the proposed MDRE approach to reverse-engineer a mobile app code to PSM PSM to PIM PIM to PSM and PSMto code
Table 2 Running examples open-source native iOS apps
ID Resource name Resource source link1 eSimpliestTodoList httpsgithubcomaltaibayareSimpliestTodoList
2 UIKitCataloguehttpsdeveloperapplecomlibrarycontent
samplecodeuicatalogIntroductionIntrohtmlapple_refdocuidDTS40007710
3 Tabsterhttpsdeveloperapplecomlibrarycontent
samplecodeTabsterIntroductionIntrohtmlapple_refdocuidDTS40011213
Table 3 Metrics of the running examples
ID No of source files (hm) Size of source file (KB) No of storyboard (xib file) No of UI elements Xcode build (SDK)1 10 30 1 26 72902 50 192 2 157 72903 22 22 3 31 7290
8 Mobile Information Systems
Mobile platform AASTM metamodel
Mobile platform AKDM metamodel
Mobile platform Aapplicativemetamodel
Datametamodel
DataPSM
Parsers
1 Model discovery
ApplicativePSM
InfrastructurePSM
TechnologicalPSM
Conforms to
Code to PSM
Programminglanguage files
Specific artifactsplatform
Assetfiles
Datafiles
Mobile app physical structure
Source mobileapplication
Mobile platform A
Figure 2 First step of the proposed MDRE approach model discovery (code to PSM)
BreakStatement
objcExpression
BlockStatement
Extends
Extends
ExtendsExtends
Extends
Statement
ContinueStatement
ExpressionStatement
IfStatement
WhileStatement
SwitchStatement
Extends
Extends
Extends
Extends
ForStatement
AstmObject
AstmSyntaxObject 1
1
1
1
1
ObjcBlockExpression
formalParameters
FormalParameterDefinition
+ aliasName EString
+ synthesizedName EString + nameString EString
accessKind
AccessKind Name
Identifier Name1
1
+ includeUnitSource EString
+ comment EString
1 lowast
ExtendsExtends
SourceLocation
AnnotationExpression
TypeReference
loctionInfo
ownedObjects
Extends
Extends
lowastExpression
expressionType
definitionType Definition
Extends
Extends
DeclarationOrDefinition
+ isClassAttr EBoolean
+ isProtocolimpl EBoolean
ExtendsinitialValue
DataDefinition
+ isMutable EBoolean
body1
lowastExtends
lowast
KDMEntity
DefinitionObject
Figure 3 Technological metamodel an excerpt of the ASTmetamodel corresponding to the Objective-C block expression e key entitiesare ObjcBlockExpression Expression Statement FormalParameterDefinition TypeReference AccessKind AstmObject KDMEntity etc
Mobile Information Systems 9
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
Another contribution by Salihu et al [24] proposes ahybrid technique for reverse-engineering the GUI modelfrom Android apps e researchers have developed a toolcalled AMOGA that combines static and dynamic analysise tool performs a static analysis of mobile applicationbinaries to automatically extract GUI information en itinstructs a dynamic crawling to explore and reverse-engi-neer a model of the mobile app
Morgado and Paiva [25] developed a tool named iMPActfor supporting the automatic testing of mobile apps based onthe presence of recurring behavior UI Pattern e meth-odology used in this study was fully automated and it isbased on two steps first crawling the application byidentifying a UI pattern and then interacting with it byapplying a test strategy
A field study approach is applied by Chen et al [26] toinvestigate automating visual understanding of mobile UIdesign to generate a mobile GUI skeleton rough theirstudy a neural machine translator is developed whichcombines a vision convolutional neural network (CNN) anda recurrent neural network (RNN) [27] encoderdecodere translator consists of extracting visual features in UIdesign encoding feature spatial layouts and generating GUIskeletons With the similar focus another case study byBeltramelli [28] contributes to this line of research bypresenting an approach based on convolutional and Re-current neural networks combined with a specific DSLwhich helps to generate from GUI screenshot the corre-sponding source code for different platforms (ie iOSAndroid and web-based technologies) e technique wastrained on a relatively small dataset and requires moreimprovements to recognize vectorial representation eauthor argues that generative adversarial networks (GAN)s[29] could potentially be used in combination with pix2codemodel to improve results
A recent testing technique that is GUI exploration basedis introduced by Amalfitano et al [30]e approach aims toexploit human involvement in the automated process toaddress the challenge of exploring Gate GUIs which requireto be exercised with particular input event sequences eauthors present jugular a hybrid GUI exploration toolcombining automated GUI exploration with capture andreplay by exploiting a machine-learning approach
e previous studies were categorized according to theontology presented initially by Cornelissen et al [31] andrefined according to the mobile reverse-engineering contextby Morgado et al [19] e main aspects to classify theselected approaches included
(i) Goal the main aims of the studied approach(program comprehension model recovery patternidentification verification and validation etc)
(ii) Target the target platform (iOS Android Web) orthe relevant input artifact (UI drawing screen-shots) which is concerned by the study
(iii) Method this refers to what type of analysis per-formed by each approach on the source artifactsie static dynamic or hybrid
(iv) Technique this indicates the implemented tech-nique for reverse engineeringcomprehending theconsidered system (instrumentation code in-jection parsing crawling etc)
(v) Extracted information this specifies the key in-formation extracted by the adopted method (run-time behavior event sequence UI states crashdetection etc)
(vi) Output this indicates in which forms the resultswill be generated (call graph finite state machinereport test suite etc)
(vii) Validation by what means the approach has beenvalidated (case studies comparison with othertoolsapproaches evaluation)
Table 1 summarizes the result of the classification of theprevious studies according to the ontology criteria presentedby Morgado [32]
Based on this in-depth critical analysis of previousworks there remainmany gaps that have not been tackled byrecent research In fact the main challenges covered in thesestudies can be grouped in three topics test automationprogram comprehension and mobile UI drawing Con-siderable gap that warrant particular attention is that none ofthe previous research have addressed the full reverse engi-neering from one platform to another platform In additionmost of these approaches which rely on static analysis of thesource code have not take advantages of the use of themodel-driven engineering (MDE) paradigms in order tobetter comprehend the studied system Only the attemptintroduced by Lamhaddab and Elbaamrani [21] approachedthe reverse-engineering of mobile apps by focusing ongraph-based models We believe that the MDRE approachcan bring a considerable gain regarding detection of be-havior and UI patterns GUI explorations machine stateidentification or event handling
3 Empirical Study Design
In this section the authors present the empirical studydesign of this research ey discuss the methods used fordata collection and data analysis
31 Data Collection e first step of this research meth-odology is to perform a literature survey of the relevantpublished works regarding mobile reverse-engineering fieldas presented in Section 2 e aim of this phase is to conducta deep critical analysis of previous works and identify whichcurrent gaps remain in reverse-engineering mobile platformtechniques to attempt to solve the gaps
e second phase aims to collect the mobile developersrsquoneeds e objective of this study is to investigate the realchallenges faced by mobile developers during the mobileporting process and to identify insight into the aspects andtechnical axis that must be covered when designing theproposed tool erefore it was important to gather datafrom various stakeholders involved in mobile applications
4 Mobile Information Systems
Table 1 Classification of the related mobile reverse-engineering techniques in terms of goal target method extracted information outputand validation
Study Goal Target Method Technique Extractedinformation Output Validation
Frank et al [15]Program
ComprehensionFeature location
iOSAndroidJava ME
Static InstrumentationCode injection
RuntimebehaviorEvent
sequence
Call graphReport Case study
Joorabchi andMesbah [16] Model recovery iOS Dynamic Crawling
Event handling
RuntimebehaviorUser
interfacestates
Finite state machine Case study
Yang et al [17] Model recovery Android HybridCrawling
Event handlingParsing
RuntimebehaviourEvent
Sequence
Finite state machineCase studyComparisonEvaluation
Salva andZafimiharisoa[18]
Verification andvalidation
Model recoveryAndroid Dynamic Crawling
Runtimebehaviour
UserinterfacestatesCrash
detection
Call graphFinite state machine
Test suite
ComparisonEvaluation
Morgado et al[19] 2014
Verification andvalidationPattern
identification
Android Hybrid
CrawlingEvent handling
ParsingInstrumentation
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
Case studyComparison
Nguyen andCsallner [20]
User interfaceidentification
MobileUI design Static
Optical characterrecognition OCREvent handling
Userinterfacewidgets
Computervision
Android UI skeleton Case studyEvaluation
Lamhaddab andElbaamrani[21] Porting iOS Static
ParsingGraph modeling
Modeltransformation
Source codeASTUser
interfaceWidgetsUser
interfaceSequences
Graph models for sourceplatform (iOS)
Graph models for targetplatform (Android)
ComparisonEvaluation
AmalFitano et al[22]
Verification andvalidation
Model recoveryAndroid Dynamic
RippingInstrumentationTest Generation
CrashdetectionBugs
Call graphReport
Test suiteFinite state machine
Case studyComparisonEvaluation
Dugerdil andSako [23]
ProgramcomprehensionMaintenance
iOS Static InstrumentationCode injection
RuntimebehaviourEvent
Sequence
Report Case studyEvaluation
Salihu et al [24] Model recovery Android HybridCrawling
Event handlingParsing
Runtimebehaviour
Userinterfacestates
Finite state machine ComparisonEvaluation
Morgado andPaiva [25]
Verification andvalidationPattern
identification
Android DynamicCrawling
Event handlingParsing
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
ComparisonEvaluation
Mobile Information Systems 5
development Interview participants were recruited throughthe subscriber database of MyAppConverter (MyApp-Converter httpwwwmyappconvertercom) platformerefore candidates have been selected via an e-mailcampaign that highlights the road map of the new tool andwhich encourage subscribers to participate in the surveyeauthors have selected 20 Android developers and 15 iOSdevelopers with 2 to 5 years of experience In addition theyhave targeted 10 product owners who are not necessarilydevelopers but rather business analysts To approve theinterview questionnaire the authors have hired a small teamfrom MyAppConverter composed of two senior mobiledevelopers (iOS amp Android) and one functional analyst leadey recruited a total of 45 interview participants andscheduled 15 to 20minutes conference calls for conductinginterviews based on their availability It should be noted thatall the participants were ensured about the confidentiality oftheir personal information and data
Moreover three variants of questionnaires were ad-ministered to three categories iOS developers Androiddevelopers and product owners e purposes of thesequestionnaires are to identify the best practices and tech-niques widely used to design the UI part of iOS applicationslist the components that present difficulties when they areported to Android and define the key information that willhelp in the functional understanding during the portingprocess
32 Data Analysis After collecting the practitionersrsquo re-sponses the authors analyzed carefully the data in order todetermine the proposed toolrsquos features It is worth notingthat real-world practitioners support the research as themajority of the 45 interviewees agreed that implementing atool which can reverse-engineer the functional specifications
and port the UI storyboard and could contribute sub-stantially on time and cost of mobile porting project
With regard to the questionnaire that targets productowners 70 of the respondents agreed that the proposed toolshould represent the functional requirements as use casesformat In use cases template the functional requirements areunderstood in the context of user action which typicallyavoid a lot of ambiguity that makes its way into an out-ofcontext list of system However 30 of the respondentsprefer to represent the functional spec in an agile form such asuser stories ey argued that the user story form is highlyeffective at capturing and linking user goals functional re-quirements and business benefits Overall 95 of the in-terviewees agreed that the functional spec document shouldinclude information about project team build informationdependencies constraints business class model entity modelscreens details activity diagram and business rules
e respondents of the questionnaire that was targetedthe iOS developers reflected that a high percentage (85 ofthem) use storyboard and xib files to design the UI layereyargue that the Interface Builder IDE within Xcode makes itmuch easier to design UI and flows without writing any codeIn addition storyboards are highly recommended withmultiple interconnected view controllers and eliminateboilerplate code to perform transition between view con-trollers However 15 of the respondents build UI pro-grammatically by writing Objective-C or Swift code eyargue that mastering the coding of iOS UI allows addressingviews with complex or dynamic layouts customizing tran-sition effects between view controllers and refactoring spe-cific views in a reusable fashion 65 used autolayout featurein order to define constraints to control how user interfacewill adapt on different screen sizes when device rotated orwhen the app run in different locales Overall 47 prefer touse third libraries to customize UI components instead of iOS
Table 1 Continued
Study Goal Target Method Technique Extractedinformation Output Validation
Chen et al [26] User interfaceidentification
MobileUI design Static
Neural machinetranslator
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
Userinterfacewidgets
Android UI skeleton Case studyEvaluation
Beltramelli [28] User interfaceidentification
MobileUI design Static
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
DSL
UserInterfaceWidgets
Android UI skeletoniOS UI skeletonWeb-based U
Case study
Amalfitano et al[30]
Verification andvalidation
Model RecoveryAndroid Hybrid
CrawlingInstrumentation
Input event sequenceMachine learning
RuntimebehaviorUser
interfacestatesHuman
involvement
Call graphFinite state machine
Test suiteReport
Case study
6 Mobile Information Systems
UIKit framework Additionally 90 used xib to designstatic table view cell and displaying dynamic data Fur-thermore they used code to define table view data sourceUITableViewDataSource (UITableViewDataSource httpsdeveloperapplecomdocumentationuikituitableviewdatasource) and UITableViewDelegate (UITableViewDelegatehttpsdeveloperapplecomdocumentationuikituitableviewdelegate) in order to manage cell selection and other featuresrelated to displaying the data
With regard to the questionnaire that targets the An-droid developers 90 of the respondents used xml layout todesign UI prototyping Overall 60 used small widthqualifier in order to adapt layout to respond gracefully todifferent screen sizes and orientations However 40 agreedthat it is preferable to use the constraint layout to create aresponsive UI In addition a high percentage (92) of therespondents recommend modularizing UI components withfragments (Android Fragments httpsdeveloperandroidcomguidecomponentsfragments) Overall 100 agreedthat it will be a tedious task to port some iOS UI componentssuch as Attributed TextView TableView Collection ViewController Page View Controller Split View Controller andCollection Reusable View Moreover all the intervieweesadmit that there is an additional effort to adapt iOS graphicassets for Android e best solution is to scale assets tocorrect size for relevant device screen Additionally all therespondents confirm that it is not obvious to find anequivalent for custom UI components in most cases de-velopers are limited to using the closest Android UI standardcomponents based on Googlersquos guidelines
4 Proposed Approach
is section outlines the model-driven reverse-engineering(MDRE) approach followed in iSpecSnapshot e authorsrsquovision is to approach MDRE from a new context which ismobile development ey will try to provide answers toenrich the reverse-engineering literature with a hot topicwhich addresses porting mobile applications from iOS toAndroid e present work closely seeks to address reverseengineering of the documentation and UI of an iOS ap-plication e current contribution sheds the light on usingMDRE paradigm to identify the main steps and modelingstandards with the purpose to propose a more generic andextendable approach
Specifically in their method the authors proceed in thesame way as the Fleurey et al [33] by adopting their MDREsteps with some alterations code to PSM PSM to PIM PIMto PSM and PSM to code e particularity of the authorsrsquoapproach is that all the adopted metamodels are based onKDM and ASTM standards (see Appendix B) Hence theproposed process is depicted in Figure 1 and consists of fourmain steps
(i) Model discovery (code to PSM)(ii) Model semantic extraction (PSM to PIM)(iii) Model transformation (PIM to PSM)(iv) Model to code generation (PSM to code)
As running examples the authors have chosen threeopen sourced projects from Apple sample code Library andGithub Table 2 shows resource link details for each runningexample (ID name and resource link)
Table 3 reports some metrics of each running examplenumber of the source code files (header and main files) sizeof the source files number of used storyboardxib files andthe number of the static UI elements
41 Step 1 Model Discovery Model discovery is a parsingstep which aims to parse the source mobile app artifacts inorder to produce a set of representative models ese so-called initial models have a strong dependency with thecomponents of the source app they are commonly describedby the OMG as platform-specific models (PSMs) (see Ap-pendix A) e implementation of this step depends on thetechnology of the source mobile platform It is based mainlyon the static analysis to automatically generate PSM modelsfrom source code artifacts Typically an iOS app is com-posed by programming language files (h m Swift ccpp) platform-specific files (storyboard pch pliststring) asset files (png jpeg bmp) and data files(xcdatamodeld xml json)
In the initial stage it is wise to first define all themetamodels that describe the source mobile platform In-deed as mentioned in Figure 2 the authors distinguish fourvariants of metamodels technological infrastructure ap-plicative and data metamodels
e technological metamodel describes the programinglanguages used in the source mobile platform It inheritsmainly from the OMG ASTM metamodel For instance forthe iOS mobile platform the authors define ASTM meta-models for the commonly used programming languagessuch as C C++ Objective-C and Swift Figure 3 illustratesan excerpt of the Objective-C metamodel (metamodeling ofthe Objective-C block expression (Objective-C block httpsdeveloperapplecomlibraryarchivedocumentationCocoaConceptualBlocksArticles00_Introductionhtmlapple_refdocuidTP40007502-CH1-SW1))
e infrastructure metamodel defines the tree structureand relative paths of the source mobile app (folders subfolders files assets resources etc) It inherits mainly fromthe OMG KDM metamodel Figure 4 shows an overview ofthe iOS xcode project metamodel
e applicative metamodel defines mainly specific in-formation regarding the source mobile platform includingbuild settings dependencies compiler executable nameand static UI workflow It is designed according to theofficial iOS documentation (UIKit official documentationhttpsdeveloperapplecomdocumentationuikit) Figure 5shows an overview of the metamodel specific to the UI part(xib file)
emodel discovery step is performed through platformparsers which are specific to the source platform e au-thors have set up four kinds of parsers
(i) Infrastructure parsers allow generating a physicalmodel of the source application is model con-tains all the tree structure and relative paths of the
Mobile Information Systems 7
source mobile app (folders sub folders files assetsresources etc) e generated model is conformedto the Xcode Project KDM metamodel
(ii) Technological parsers allow generating abstractsyntax models of all the programming language filesused in the source application (eg C C++ Ob-jective-C and Swift) At this stage all the generatedmodels conform to the technological ASTMmetamodels
(iii) Applicative parsers allow building applicativemodels which are specific to some key artifact ofthe source platform (eg workspace file xcode-proj file pch file plist file xib file Pod file etc)Generally these artifacts include informationabout the source platform namely build settingsdependencies compiler executable name andstatic UI workflow ese models (eg Algo-rithm 1) are designed according to the applicativemetamodels
(iv) Data parsers allow building data models which arestatically stored in the file system (eg xdatamodelfile json file xml file etc)ese models conform totypical metamodels
42 Step 2 Semantic Extraction e semantic extractionstep is considered as a halfway point between code-to-modeland model-to-model steps In fact it aims to analyze thePSM models in order to extract some useful semantic in-formation which is required to build the PIM model eextraction process is designed to be iterative and supportsboth technological and applicative models is process isdriven by a set of semantic extractors that identify collectand consolidate all the semantic data required to build thesemantic mobile model PIM which is an instance of thesemantic mobile metamodel e authors have opted for ageneric metamodel which represents in a semantic mannerany mobile application e proposed metamodel is theresult of a close collaboration with two senior mobile
OMG standard metamodelsKDM ASTM SMM
Mobile platform Ametamodels
Semantic mobilemetamodels
Mobile platform Bmetamodels
Metamodel
ModelConforms to
Target mobilePSMs
32
1
TransformationSemantic model
PIM
Conforms to
Semanticextraction
Source mobilePSMs
Conforms to
Discovery
Source mobileapplication
mobile platform A
Target mobileapplication
mobile platform B
Codegeneration
Code
4
User inherits from
Figure 1 Main steps of the proposed MDRE approach to reverse-engineer a mobile app code to PSM PSM to PIM PIM to PSM and PSMto code
Table 2 Running examples open-source native iOS apps
ID Resource name Resource source link1 eSimpliestTodoList httpsgithubcomaltaibayareSimpliestTodoList
2 UIKitCataloguehttpsdeveloperapplecomlibrarycontent
samplecodeuicatalogIntroductionIntrohtmlapple_refdocuidDTS40007710
3 Tabsterhttpsdeveloperapplecomlibrarycontent
samplecodeTabsterIntroductionIntrohtmlapple_refdocuidDTS40011213
Table 3 Metrics of the running examples
ID No of source files (hm) Size of source file (KB) No of storyboard (xib file) No of UI elements Xcode build (SDK)1 10 30 1 26 72902 50 192 2 157 72903 22 22 3 31 7290
8 Mobile Information Systems
Mobile platform AASTM metamodel
Mobile platform AKDM metamodel
Mobile platform Aapplicativemetamodel
Datametamodel
DataPSM
Parsers
1 Model discovery
ApplicativePSM
InfrastructurePSM
TechnologicalPSM
Conforms to
Code to PSM
Programminglanguage files
Specific artifactsplatform
Assetfiles
Datafiles
Mobile app physical structure
Source mobileapplication
Mobile platform A
Figure 2 First step of the proposed MDRE approach model discovery (code to PSM)
BreakStatement
objcExpression
BlockStatement
Extends
Extends
ExtendsExtends
Extends
Statement
ContinueStatement
ExpressionStatement
IfStatement
WhileStatement
SwitchStatement
Extends
Extends
Extends
Extends
ForStatement
AstmObject
AstmSyntaxObject 1
1
1
1
1
ObjcBlockExpression
formalParameters
FormalParameterDefinition
+ aliasName EString
+ synthesizedName EString + nameString EString
accessKind
AccessKind Name
Identifier Name1
1
+ includeUnitSource EString
+ comment EString
1 lowast
ExtendsExtends
SourceLocation
AnnotationExpression
TypeReference
loctionInfo
ownedObjects
Extends
Extends
lowastExpression
expressionType
definitionType Definition
Extends
Extends
DeclarationOrDefinition
+ isClassAttr EBoolean
+ isProtocolimpl EBoolean
ExtendsinitialValue
DataDefinition
+ isMutable EBoolean
body1
lowastExtends
lowast
KDMEntity
DefinitionObject
Figure 3 Technological metamodel an excerpt of the ASTmetamodel corresponding to the Objective-C block expression e key entitiesare ObjcBlockExpression Expression Statement FormalParameterDefinition TypeReference AccessKind AstmObject KDMEntity etc
Mobile Information Systems 9
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
Table 1 Classification of the related mobile reverse-engineering techniques in terms of goal target method extracted information outputand validation
Study Goal Target Method Technique Extractedinformation Output Validation
Frank et al [15]Program
ComprehensionFeature location
iOSAndroidJava ME
Static InstrumentationCode injection
RuntimebehaviorEvent
sequence
Call graphReport Case study
Joorabchi andMesbah [16] Model recovery iOS Dynamic Crawling
Event handling
RuntimebehaviorUser
interfacestates
Finite state machine Case study
Yang et al [17] Model recovery Android HybridCrawling
Event handlingParsing
RuntimebehaviourEvent
Sequence
Finite state machineCase studyComparisonEvaluation
Salva andZafimiharisoa[18]
Verification andvalidation
Model recoveryAndroid Dynamic Crawling
Runtimebehaviour
UserinterfacestatesCrash
detection
Call graphFinite state machine
Test suite
ComparisonEvaluation
Morgado et al[19] 2014
Verification andvalidationPattern
identification
Android Hybrid
CrawlingEvent handling
ParsingInstrumentation
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
Case studyComparison
Nguyen andCsallner [20]
User interfaceidentification
MobileUI design Static
Optical characterrecognition OCREvent handling
Userinterfacewidgets
Computervision
Android UI skeleton Case studyEvaluation
Lamhaddab andElbaamrani[21] Porting iOS Static
ParsingGraph modeling
Modeltransformation
Source codeASTUser
interfaceWidgetsUser
interfaceSequences
Graph models for sourceplatform (iOS)
Graph models for targetplatform (Android)
ComparisonEvaluation
AmalFitano et al[22]
Verification andvalidation
Model recoveryAndroid Dynamic
RippingInstrumentationTest Generation
CrashdetectionBugs
Call graphReport
Test suiteFinite state machine
Case studyComparisonEvaluation
Dugerdil andSako [23]
ProgramcomprehensionMaintenance
iOS Static InstrumentationCode injection
RuntimebehaviourEvent
Sequence
Report Case studyEvaluation
Salihu et al [24] Model recovery Android HybridCrawling
Event handlingParsing
Runtimebehaviour
Userinterfacestates
Finite state machine ComparisonEvaluation
Morgado andPaiva [25]
Verification andvalidationPattern
identification
Android DynamicCrawling
Event handlingParsing
RuntimebehaviourEvent
sequenceBugs
Call graphReport
Test suite
ComparisonEvaluation
Mobile Information Systems 5
development Interview participants were recruited throughthe subscriber database of MyAppConverter (MyApp-Converter httpwwwmyappconvertercom) platformerefore candidates have been selected via an e-mailcampaign that highlights the road map of the new tool andwhich encourage subscribers to participate in the surveyeauthors have selected 20 Android developers and 15 iOSdevelopers with 2 to 5 years of experience In addition theyhave targeted 10 product owners who are not necessarilydevelopers but rather business analysts To approve theinterview questionnaire the authors have hired a small teamfrom MyAppConverter composed of two senior mobiledevelopers (iOS amp Android) and one functional analyst leadey recruited a total of 45 interview participants andscheduled 15 to 20minutes conference calls for conductinginterviews based on their availability It should be noted thatall the participants were ensured about the confidentiality oftheir personal information and data
Moreover three variants of questionnaires were ad-ministered to three categories iOS developers Androiddevelopers and product owners e purposes of thesequestionnaires are to identify the best practices and tech-niques widely used to design the UI part of iOS applicationslist the components that present difficulties when they areported to Android and define the key information that willhelp in the functional understanding during the portingprocess
32 Data Analysis After collecting the practitionersrsquo re-sponses the authors analyzed carefully the data in order todetermine the proposed toolrsquos features It is worth notingthat real-world practitioners support the research as themajority of the 45 interviewees agreed that implementing atool which can reverse-engineer the functional specifications
and port the UI storyboard and could contribute sub-stantially on time and cost of mobile porting project
With regard to the questionnaire that targets productowners 70 of the respondents agreed that the proposed toolshould represent the functional requirements as use casesformat In use cases template the functional requirements areunderstood in the context of user action which typicallyavoid a lot of ambiguity that makes its way into an out-ofcontext list of system However 30 of the respondentsprefer to represent the functional spec in an agile form such asuser stories ey argued that the user story form is highlyeffective at capturing and linking user goals functional re-quirements and business benefits Overall 95 of the in-terviewees agreed that the functional spec document shouldinclude information about project team build informationdependencies constraints business class model entity modelscreens details activity diagram and business rules
e respondents of the questionnaire that was targetedthe iOS developers reflected that a high percentage (85 ofthem) use storyboard and xib files to design the UI layereyargue that the Interface Builder IDE within Xcode makes itmuch easier to design UI and flows without writing any codeIn addition storyboards are highly recommended withmultiple interconnected view controllers and eliminateboilerplate code to perform transition between view con-trollers However 15 of the respondents build UI pro-grammatically by writing Objective-C or Swift code eyargue that mastering the coding of iOS UI allows addressingviews with complex or dynamic layouts customizing tran-sition effects between view controllers and refactoring spe-cific views in a reusable fashion 65 used autolayout featurein order to define constraints to control how user interfacewill adapt on different screen sizes when device rotated orwhen the app run in different locales Overall 47 prefer touse third libraries to customize UI components instead of iOS
Table 1 Continued
Study Goal Target Method Technique Extractedinformation Output Validation
Chen et al [26] User interfaceidentification
MobileUI design Static
Neural machinetranslator
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
Userinterfacewidgets
Android UI skeleton Case studyEvaluation
Beltramelli [28] User interfaceidentification
MobileUI design Static
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
DSL
UserInterfaceWidgets
Android UI skeletoniOS UI skeletonWeb-based U
Case study
Amalfitano et al[30]
Verification andvalidation
Model RecoveryAndroid Hybrid
CrawlingInstrumentation
Input event sequenceMachine learning
RuntimebehaviorUser
interfacestatesHuman
involvement
Call graphFinite state machine
Test suiteReport
Case study
6 Mobile Information Systems
UIKit framework Additionally 90 used xib to designstatic table view cell and displaying dynamic data Fur-thermore they used code to define table view data sourceUITableViewDataSource (UITableViewDataSource httpsdeveloperapplecomdocumentationuikituitableviewdatasource) and UITableViewDelegate (UITableViewDelegatehttpsdeveloperapplecomdocumentationuikituitableviewdelegate) in order to manage cell selection and other featuresrelated to displaying the data
With regard to the questionnaire that targets the An-droid developers 90 of the respondents used xml layout todesign UI prototyping Overall 60 used small widthqualifier in order to adapt layout to respond gracefully todifferent screen sizes and orientations However 40 agreedthat it is preferable to use the constraint layout to create aresponsive UI In addition a high percentage (92) of therespondents recommend modularizing UI components withfragments (Android Fragments httpsdeveloperandroidcomguidecomponentsfragments) Overall 100 agreedthat it will be a tedious task to port some iOS UI componentssuch as Attributed TextView TableView Collection ViewController Page View Controller Split View Controller andCollection Reusable View Moreover all the intervieweesadmit that there is an additional effort to adapt iOS graphicassets for Android e best solution is to scale assets tocorrect size for relevant device screen Additionally all therespondents confirm that it is not obvious to find anequivalent for custom UI components in most cases de-velopers are limited to using the closest Android UI standardcomponents based on Googlersquos guidelines
4 Proposed Approach
is section outlines the model-driven reverse-engineering(MDRE) approach followed in iSpecSnapshot e authorsrsquovision is to approach MDRE from a new context which ismobile development ey will try to provide answers toenrich the reverse-engineering literature with a hot topicwhich addresses porting mobile applications from iOS toAndroid e present work closely seeks to address reverseengineering of the documentation and UI of an iOS ap-plication e current contribution sheds the light on usingMDRE paradigm to identify the main steps and modelingstandards with the purpose to propose a more generic andextendable approach
Specifically in their method the authors proceed in thesame way as the Fleurey et al [33] by adopting their MDREsteps with some alterations code to PSM PSM to PIM PIMto PSM and PSM to code e particularity of the authorsrsquoapproach is that all the adopted metamodels are based onKDM and ASTM standards (see Appendix B) Hence theproposed process is depicted in Figure 1 and consists of fourmain steps
(i) Model discovery (code to PSM)(ii) Model semantic extraction (PSM to PIM)(iii) Model transformation (PIM to PSM)(iv) Model to code generation (PSM to code)
As running examples the authors have chosen threeopen sourced projects from Apple sample code Library andGithub Table 2 shows resource link details for each runningexample (ID name and resource link)
Table 3 reports some metrics of each running examplenumber of the source code files (header and main files) sizeof the source files number of used storyboardxib files andthe number of the static UI elements
41 Step 1 Model Discovery Model discovery is a parsingstep which aims to parse the source mobile app artifacts inorder to produce a set of representative models ese so-called initial models have a strong dependency with thecomponents of the source app they are commonly describedby the OMG as platform-specific models (PSMs) (see Ap-pendix A) e implementation of this step depends on thetechnology of the source mobile platform It is based mainlyon the static analysis to automatically generate PSM modelsfrom source code artifacts Typically an iOS app is com-posed by programming language files (h m Swift ccpp) platform-specific files (storyboard pch pliststring) asset files (png jpeg bmp) and data files(xcdatamodeld xml json)
In the initial stage it is wise to first define all themetamodels that describe the source mobile platform In-deed as mentioned in Figure 2 the authors distinguish fourvariants of metamodels technological infrastructure ap-plicative and data metamodels
e technological metamodel describes the programinglanguages used in the source mobile platform It inheritsmainly from the OMG ASTM metamodel For instance forthe iOS mobile platform the authors define ASTM meta-models for the commonly used programming languagessuch as C C++ Objective-C and Swift Figure 3 illustratesan excerpt of the Objective-C metamodel (metamodeling ofthe Objective-C block expression (Objective-C block httpsdeveloperapplecomlibraryarchivedocumentationCocoaConceptualBlocksArticles00_Introductionhtmlapple_refdocuidTP40007502-CH1-SW1))
e infrastructure metamodel defines the tree structureand relative paths of the source mobile app (folders subfolders files assets resources etc) It inherits mainly fromthe OMG KDM metamodel Figure 4 shows an overview ofthe iOS xcode project metamodel
e applicative metamodel defines mainly specific in-formation regarding the source mobile platform includingbuild settings dependencies compiler executable nameand static UI workflow It is designed according to theofficial iOS documentation (UIKit official documentationhttpsdeveloperapplecomdocumentationuikit) Figure 5shows an overview of the metamodel specific to the UI part(xib file)
emodel discovery step is performed through platformparsers which are specific to the source platform e au-thors have set up four kinds of parsers
(i) Infrastructure parsers allow generating a physicalmodel of the source application is model con-tains all the tree structure and relative paths of the
Mobile Information Systems 7
source mobile app (folders sub folders files assetsresources etc) e generated model is conformedto the Xcode Project KDM metamodel
(ii) Technological parsers allow generating abstractsyntax models of all the programming language filesused in the source application (eg C C++ Ob-jective-C and Swift) At this stage all the generatedmodels conform to the technological ASTMmetamodels
(iii) Applicative parsers allow building applicativemodels which are specific to some key artifact ofthe source platform (eg workspace file xcode-proj file pch file plist file xib file Pod file etc)Generally these artifacts include informationabout the source platform namely build settingsdependencies compiler executable name andstatic UI workflow ese models (eg Algo-rithm 1) are designed according to the applicativemetamodels
(iv) Data parsers allow building data models which arestatically stored in the file system (eg xdatamodelfile json file xml file etc)ese models conform totypical metamodels
42 Step 2 Semantic Extraction e semantic extractionstep is considered as a halfway point between code-to-modeland model-to-model steps In fact it aims to analyze thePSM models in order to extract some useful semantic in-formation which is required to build the PIM model eextraction process is designed to be iterative and supportsboth technological and applicative models is process isdriven by a set of semantic extractors that identify collectand consolidate all the semantic data required to build thesemantic mobile model PIM which is an instance of thesemantic mobile metamodel e authors have opted for ageneric metamodel which represents in a semantic mannerany mobile application e proposed metamodel is theresult of a close collaboration with two senior mobile
OMG standard metamodelsKDM ASTM SMM
Mobile platform Ametamodels
Semantic mobilemetamodels
Mobile platform Bmetamodels
Metamodel
ModelConforms to
Target mobilePSMs
32
1
TransformationSemantic model
PIM
Conforms to
Semanticextraction
Source mobilePSMs
Conforms to
Discovery
Source mobileapplication
mobile platform A
Target mobileapplication
mobile platform B
Codegeneration
Code
4
User inherits from
Figure 1 Main steps of the proposed MDRE approach to reverse-engineer a mobile app code to PSM PSM to PIM PIM to PSM and PSMto code
Table 2 Running examples open-source native iOS apps
ID Resource name Resource source link1 eSimpliestTodoList httpsgithubcomaltaibayareSimpliestTodoList
2 UIKitCataloguehttpsdeveloperapplecomlibrarycontent
samplecodeuicatalogIntroductionIntrohtmlapple_refdocuidDTS40007710
3 Tabsterhttpsdeveloperapplecomlibrarycontent
samplecodeTabsterIntroductionIntrohtmlapple_refdocuidDTS40011213
Table 3 Metrics of the running examples
ID No of source files (hm) Size of source file (KB) No of storyboard (xib file) No of UI elements Xcode build (SDK)1 10 30 1 26 72902 50 192 2 157 72903 22 22 3 31 7290
8 Mobile Information Systems
Mobile platform AASTM metamodel
Mobile platform AKDM metamodel
Mobile platform Aapplicativemetamodel
Datametamodel
DataPSM
Parsers
1 Model discovery
ApplicativePSM
InfrastructurePSM
TechnologicalPSM
Conforms to
Code to PSM
Programminglanguage files
Specific artifactsplatform
Assetfiles
Datafiles
Mobile app physical structure
Source mobileapplication
Mobile platform A
Figure 2 First step of the proposed MDRE approach model discovery (code to PSM)
BreakStatement
objcExpression
BlockStatement
Extends
Extends
ExtendsExtends
Extends
Statement
ContinueStatement
ExpressionStatement
IfStatement
WhileStatement
SwitchStatement
Extends
Extends
Extends
Extends
ForStatement
AstmObject
AstmSyntaxObject 1
1
1
1
1
ObjcBlockExpression
formalParameters
FormalParameterDefinition
+ aliasName EString
+ synthesizedName EString + nameString EString
accessKind
AccessKind Name
Identifier Name1
1
+ includeUnitSource EString
+ comment EString
1 lowast
ExtendsExtends
SourceLocation
AnnotationExpression
TypeReference
loctionInfo
ownedObjects
Extends
Extends
lowastExpression
expressionType
definitionType Definition
Extends
Extends
DeclarationOrDefinition
+ isClassAttr EBoolean
+ isProtocolimpl EBoolean
ExtendsinitialValue
DataDefinition
+ isMutable EBoolean
body1
lowastExtends
lowast
KDMEntity
DefinitionObject
Figure 3 Technological metamodel an excerpt of the ASTmetamodel corresponding to the Objective-C block expression e key entitiesare ObjcBlockExpression Expression Statement FormalParameterDefinition TypeReference AccessKind AstmObject KDMEntity etc
Mobile Information Systems 9
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
development Interview participants were recruited throughthe subscriber database of MyAppConverter (MyApp-Converter httpwwwmyappconvertercom) platformerefore candidates have been selected via an e-mailcampaign that highlights the road map of the new tool andwhich encourage subscribers to participate in the surveyeauthors have selected 20 Android developers and 15 iOSdevelopers with 2 to 5 years of experience In addition theyhave targeted 10 product owners who are not necessarilydevelopers but rather business analysts To approve theinterview questionnaire the authors have hired a small teamfrom MyAppConverter composed of two senior mobiledevelopers (iOS amp Android) and one functional analyst leadey recruited a total of 45 interview participants andscheduled 15 to 20minutes conference calls for conductinginterviews based on their availability It should be noted thatall the participants were ensured about the confidentiality oftheir personal information and data
Moreover three variants of questionnaires were ad-ministered to three categories iOS developers Androiddevelopers and product owners e purposes of thesequestionnaires are to identify the best practices and tech-niques widely used to design the UI part of iOS applicationslist the components that present difficulties when they areported to Android and define the key information that willhelp in the functional understanding during the portingprocess
32 Data Analysis After collecting the practitionersrsquo re-sponses the authors analyzed carefully the data in order todetermine the proposed toolrsquos features It is worth notingthat real-world practitioners support the research as themajority of the 45 interviewees agreed that implementing atool which can reverse-engineer the functional specifications
and port the UI storyboard and could contribute sub-stantially on time and cost of mobile porting project
With regard to the questionnaire that targets productowners 70 of the respondents agreed that the proposed toolshould represent the functional requirements as use casesformat In use cases template the functional requirements areunderstood in the context of user action which typicallyavoid a lot of ambiguity that makes its way into an out-ofcontext list of system However 30 of the respondentsprefer to represent the functional spec in an agile form such asuser stories ey argued that the user story form is highlyeffective at capturing and linking user goals functional re-quirements and business benefits Overall 95 of the in-terviewees agreed that the functional spec document shouldinclude information about project team build informationdependencies constraints business class model entity modelscreens details activity diagram and business rules
e respondents of the questionnaire that was targetedthe iOS developers reflected that a high percentage (85 ofthem) use storyboard and xib files to design the UI layereyargue that the Interface Builder IDE within Xcode makes itmuch easier to design UI and flows without writing any codeIn addition storyboards are highly recommended withmultiple interconnected view controllers and eliminateboilerplate code to perform transition between view con-trollers However 15 of the respondents build UI pro-grammatically by writing Objective-C or Swift code eyargue that mastering the coding of iOS UI allows addressingviews with complex or dynamic layouts customizing tran-sition effects between view controllers and refactoring spe-cific views in a reusable fashion 65 used autolayout featurein order to define constraints to control how user interfacewill adapt on different screen sizes when device rotated orwhen the app run in different locales Overall 47 prefer touse third libraries to customize UI components instead of iOS
Table 1 Continued
Study Goal Target Method Technique Extractedinformation Output Validation
Chen et al [26] User interfaceidentification
MobileUI design Static
Neural machinetranslator
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
Userinterfacewidgets
Android UI skeleton Case studyEvaluation
Beltramelli [28] User interfaceidentification
MobileUI design Static
Convolutionalneural network
(CNN)Recurrent neuralnetwork (RNN)
DSL
UserInterfaceWidgets
Android UI skeletoniOS UI skeletonWeb-based U
Case study
Amalfitano et al[30]
Verification andvalidation
Model RecoveryAndroid Hybrid
CrawlingInstrumentation
Input event sequenceMachine learning
RuntimebehaviorUser
interfacestatesHuman
involvement
Call graphFinite state machine
Test suiteReport
Case study
6 Mobile Information Systems
UIKit framework Additionally 90 used xib to designstatic table view cell and displaying dynamic data Fur-thermore they used code to define table view data sourceUITableViewDataSource (UITableViewDataSource httpsdeveloperapplecomdocumentationuikituitableviewdatasource) and UITableViewDelegate (UITableViewDelegatehttpsdeveloperapplecomdocumentationuikituitableviewdelegate) in order to manage cell selection and other featuresrelated to displaying the data
With regard to the questionnaire that targets the An-droid developers 90 of the respondents used xml layout todesign UI prototyping Overall 60 used small widthqualifier in order to adapt layout to respond gracefully todifferent screen sizes and orientations However 40 agreedthat it is preferable to use the constraint layout to create aresponsive UI In addition a high percentage (92) of therespondents recommend modularizing UI components withfragments (Android Fragments httpsdeveloperandroidcomguidecomponentsfragments) Overall 100 agreedthat it will be a tedious task to port some iOS UI componentssuch as Attributed TextView TableView Collection ViewController Page View Controller Split View Controller andCollection Reusable View Moreover all the intervieweesadmit that there is an additional effort to adapt iOS graphicassets for Android e best solution is to scale assets tocorrect size for relevant device screen Additionally all therespondents confirm that it is not obvious to find anequivalent for custom UI components in most cases de-velopers are limited to using the closest Android UI standardcomponents based on Googlersquos guidelines
4 Proposed Approach
is section outlines the model-driven reverse-engineering(MDRE) approach followed in iSpecSnapshot e authorsrsquovision is to approach MDRE from a new context which ismobile development ey will try to provide answers toenrich the reverse-engineering literature with a hot topicwhich addresses porting mobile applications from iOS toAndroid e present work closely seeks to address reverseengineering of the documentation and UI of an iOS ap-plication e current contribution sheds the light on usingMDRE paradigm to identify the main steps and modelingstandards with the purpose to propose a more generic andextendable approach
Specifically in their method the authors proceed in thesame way as the Fleurey et al [33] by adopting their MDREsteps with some alterations code to PSM PSM to PIM PIMto PSM and PSM to code e particularity of the authorsrsquoapproach is that all the adopted metamodels are based onKDM and ASTM standards (see Appendix B) Hence theproposed process is depicted in Figure 1 and consists of fourmain steps
(i) Model discovery (code to PSM)(ii) Model semantic extraction (PSM to PIM)(iii) Model transformation (PIM to PSM)(iv) Model to code generation (PSM to code)
As running examples the authors have chosen threeopen sourced projects from Apple sample code Library andGithub Table 2 shows resource link details for each runningexample (ID name and resource link)
Table 3 reports some metrics of each running examplenumber of the source code files (header and main files) sizeof the source files number of used storyboardxib files andthe number of the static UI elements
41 Step 1 Model Discovery Model discovery is a parsingstep which aims to parse the source mobile app artifacts inorder to produce a set of representative models ese so-called initial models have a strong dependency with thecomponents of the source app they are commonly describedby the OMG as platform-specific models (PSMs) (see Ap-pendix A) e implementation of this step depends on thetechnology of the source mobile platform It is based mainlyon the static analysis to automatically generate PSM modelsfrom source code artifacts Typically an iOS app is com-posed by programming language files (h m Swift ccpp) platform-specific files (storyboard pch pliststring) asset files (png jpeg bmp) and data files(xcdatamodeld xml json)
In the initial stage it is wise to first define all themetamodels that describe the source mobile platform In-deed as mentioned in Figure 2 the authors distinguish fourvariants of metamodels technological infrastructure ap-plicative and data metamodels
e technological metamodel describes the programinglanguages used in the source mobile platform It inheritsmainly from the OMG ASTM metamodel For instance forthe iOS mobile platform the authors define ASTM meta-models for the commonly used programming languagessuch as C C++ Objective-C and Swift Figure 3 illustratesan excerpt of the Objective-C metamodel (metamodeling ofthe Objective-C block expression (Objective-C block httpsdeveloperapplecomlibraryarchivedocumentationCocoaConceptualBlocksArticles00_Introductionhtmlapple_refdocuidTP40007502-CH1-SW1))
e infrastructure metamodel defines the tree structureand relative paths of the source mobile app (folders subfolders files assets resources etc) It inherits mainly fromthe OMG KDM metamodel Figure 4 shows an overview ofthe iOS xcode project metamodel
e applicative metamodel defines mainly specific in-formation regarding the source mobile platform includingbuild settings dependencies compiler executable nameand static UI workflow It is designed according to theofficial iOS documentation (UIKit official documentationhttpsdeveloperapplecomdocumentationuikit) Figure 5shows an overview of the metamodel specific to the UI part(xib file)
emodel discovery step is performed through platformparsers which are specific to the source platform e au-thors have set up four kinds of parsers
(i) Infrastructure parsers allow generating a physicalmodel of the source application is model con-tains all the tree structure and relative paths of the
Mobile Information Systems 7
source mobile app (folders sub folders files assetsresources etc) e generated model is conformedto the Xcode Project KDM metamodel
(ii) Technological parsers allow generating abstractsyntax models of all the programming language filesused in the source application (eg C C++ Ob-jective-C and Swift) At this stage all the generatedmodels conform to the technological ASTMmetamodels
(iii) Applicative parsers allow building applicativemodels which are specific to some key artifact ofthe source platform (eg workspace file xcode-proj file pch file plist file xib file Pod file etc)Generally these artifacts include informationabout the source platform namely build settingsdependencies compiler executable name andstatic UI workflow ese models (eg Algo-rithm 1) are designed according to the applicativemetamodels
(iv) Data parsers allow building data models which arestatically stored in the file system (eg xdatamodelfile json file xml file etc)ese models conform totypical metamodels
42 Step 2 Semantic Extraction e semantic extractionstep is considered as a halfway point between code-to-modeland model-to-model steps In fact it aims to analyze thePSM models in order to extract some useful semantic in-formation which is required to build the PIM model eextraction process is designed to be iterative and supportsboth technological and applicative models is process isdriven by a set of semantic extractors that identify collectand consolidate all the semantic data required to build thesemantic mobile model PIM which is an instance of thesemantic mobile metamodel e authors have opted for ageneric metamodel which represents in a semantic mannerany mobile application e proposed metamodel is theresult of a close collaboration with two senior mobile
OMG standard metamodelsKDM ASTM SMM
Mobile platform Ametamodels
Semantic mobilemetamodels
Mobile platform Bmetamodels
Metamodel
ModelConforms to
Target mobilePSMs
32
1
TransformationSemantic model
PIM
Conforms to
Semanticextraction
Source mobilePSMs
Conforms to
Discovery
Source mobileapplication
mobile platform A
Target mobileapplication
mobile platform B
Codegeneration
Code
4
User inherits from
Figure 1 Main steps of the proposed MDRE approach to reverse-engineer a mobile app code to PSM PSM to PIM PIM to PSM and PSMto code
Table 2 Running examples open-source native iOS apps
ID Resource name Resource source link1 eSimpliestTodoList httpsgithubcomaltaibayareSimpliestTodoList
2 UIKitCataloguehttpsdeveloperapplecomlibrarycontent
samplecodeuicatalogIntroductionIntrohtmlapple_refdocuidDTS40007710
3 Tabsterhttpsdeveloperapplecomlibrarycontent
samplecodeTabsterIntroductionIntrohtmlapple_refdocuidDTS40011213
Table 3 Metrics of the running examples
ID No of source files (hm) Size of source file (KB) No of storyboard (xib file) No of UI elements Xcode build (SDK)1 10 30 1 26 72902 50 192 2 157 72903 22 22 3 31 7290
8 Mobile Information Systems
Mobile platform AASTM metamodel
Mobile platform AKDM metamodel
Mobile platform Aapplicativemetamodel
Datametamodel
DataPSM
Parsers
1 Model discovery
ApplicativePSM
InfrastructurePSM
TechnologicalPSM
Conforms to
Code to PSM
Programminglanguage files
Specific artifactsplatform
Assetfiles
Datafiles
Mobile app physical structure
Source mobileapplication
Mobile platform A
Figure 2 First step of the proposed MDRE approach model discovery (code to PSM)
BreakStatement
objcExpression
BlockStatement
Extends
Extends
ExtendsExtends
Extends
Statement
ContinueStatement
ExpressionStatement
IfStatement
WhileStatement
SwitchStatement
Extends
Extends
Extends
Extends
ForStatement
AstmObject
AstmSyntaxObject 1
1
1
1
1
ObjcBlockExpression
formalParameters
FormalParameterDefinition
+ aliasName EString
+ synthesizedName EString + nameString EString
accessKind
AccessKind Name
Identifier Name1
1
+ includeUnitSource EString
+ comment EString
1 lowast
ExtendsExtends
SourceLocation
AnnotationExpression
TypeReference
loctionInfo
ownedObjects
Extends
Extends
lowastExpression
expressionType
definitionType Definition
Extends
Extends
DeclarationOrDefinition
+ isClassAttr EBoolean
+ isProtocolimpl EBoolean
ExtendsinitialValue
DataDefinition
+ isMutable EBoolean
body1
lowastExtends
lowast
KDMEntity
DefinitionObject
Figure 3 Technological metamodel an excerpt of the ASTmetamodel corresponding to the Objective-C block expression e key entitiesare ObjcBlockExpression Expression Statement FormalParameterDefinition TypeReference AccessKind AstmObject KDMEntity etc
Mobile Information Systems 9
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
UIKit framework Additionally 90 used xib to designstatic table view cell and displaying dynamic data Fur-thermore they used code to define table view data sourceUITableViewDataSource (UITableViewDataSource httpsdeveloperapplecomdocumentationuikituitableviewdatasource) and UITableViewDelegate (UITableViewDelegatehttpsdeveloperapplecomdocumentationuikituitableviewdelegate) in order to manage cell selection and other featuresrelated to displaying the data
With regard to the questionnaire that targets the An-droid developers 90 of the respondents used xml layout todesign UI prototyping Overall 60 used small widthqualifier in order to adapt layout to respond gracefully todifferent screen sizes and orientations However 40 agreedthat it is preferable to use the constraint layout to create aresponsive UI In addition a high percentage (92) of therespondents recommend modularizing UI components withfragments (Android Fragments httpsdeveloperandroidcomguidecomponentsfragments) Overall 100 agreedthat it will be a tedious task to port some iOS UI componentssuch as Attributed TextView TableView Collection ViewController Page View Controller Split View Controller andCollection Reusable View Moreover all the intervieweesadmit that there is an additional effort to adapt iOS graphicassets for Android e best solution is to scale assets tocorrect size for relevant device screen Additionally all therespondents confirm that it is not obvious to find anequivalent for custom UI components in most cases de-velopers are limited to using the closest Android UI standardcomponents based on Googlersquos guidelines
4 Proposed Approach
is section outlines the model-driven reverse-engineering(MDRE) approach followed in iSpecSnapshot e authorsrsquovision is to approach MDRE from a new context which ismobile development ey will try to provide answers toenrich the reverse-engineering literature with a hot topicwhich addresses porting mobile applications from iOS toAndroid e present work closely seeks to address reverseengineering of the documentation and UI of an iOS ap-plication e current contribution sheds the light on usingMDRE paradigm to identify the main steps and modelingstandards with the purpose to propose a more generic andextendable approach
Specifically in their method the authors proceed in thesame way as the Fleurey et al [33] by adopting their MDREsteps with some alterations code to PSM PSM to PIM PIMto PSM and PSM to code e particularity of the authorsrsquoapproach is that all the adopted metamodels are based onKDM and ASTM standards (see Appendix B) Hence theproposed process is depicted in Figure 1 and consists of fourmain steps
(i) Model discovery (code to PSM)(ii) Model semantic extraction (PSM to PIM)(iii) Model transformation (PIM to PSM)(iv) Model to code generation (PSM to code)
As running examples the authors have chosen threeopen sourced projects from Apple sample code Library andGithub Table 2 shows resource link details for each runningexample (ID name and resource link)
Table 3 reports some metrics of each running examplenumber of the source code files (header and main files) sizeof the source files number of used storyboardxib files andthe number of the static UI elements
41 Step 1 Model Discovery Model discovery is a parsingstep which aims to parse the source mobile app artifacts inorder to produce a set of representative models ese so-called initial models have a strong dependency with thecomponents of the source app they are commonly describedby the OMG as platform-specific models (PSMs) (see Ap-pendix A) e implementation of this step depends on thetechnology of the source mobile platform It is based mainlyon the static analysis to automatically generate PSM modelsfrom source code artifacts Typically an iOS app is com-posed by programming language files (h m Swift ccpp) platform-specific files (storyboard pch pliststring) asset files (png jpeg bmp) and data files(xcdatamodeld xml json)
In the initial stage it is wise to first define all themetamodels that describe the source mobile platform In-deed as mentioned in Figure 2 the authors distinguish fourvariants of metamodels technological infrastructure ap-plicative and data metamodels
e technological metamodel describes the programinglanguages used in the source mobile platform It inheritsmainly from the OMG ASTM metamodel For instance forthe iOS mobile platform the authors define ASTM meta-models for the commonly used programming languagessuch as C C++ Objective-C and Swift Figure 3 illustratesan excerpt of the Objective-C metamodel (metamodeling ofthe Objective-C block expression (Objective-C block httpsdeveloperapplecomlibraryarchivedocumentationCocoaConceptualBlocksArticles00_Introductionhtmlapple_refdocuidTP40007502-CH1-SW1))
e infrastructure metamodel defines the tree structureand relative paths of the source mobile app (folders subfolders files assets resources etc) It inherits mainly fromthe OMG KDM metamodel Figure 4 shows an overview ofthe iOS xcode project metamodel
e applicative metamodel defines mainly specific in-formation regarding the source mobile platform includingbuild settings dependencies compiler executable nameand static UI workflow It is designed according to theofficial iOS documentation (UIKit official documentationhttpsdeveloperapplecomdocumentationuikit) Figure 5shows an overview of the metamodel specific to the UI part(xib file)
emodel discovery step is performed through platformparsers which are specific to the source platform e au-thors have set up four kinds of parsers
(i) Infrastructure parsers allow generating a physicalmodel of the source application is model con-tains all the tree structure and relative paths of the
Mobile Information Systems 7
source mobile app (folders sub folders files assetsresources etc) e generated model is conformedto the Xcode Project KDM metamodel
(ii) Technological parsers allow generating abstractsyntax models of all the programming language filesused in the source application (eg C C++ Ob-jective-C and Swift) At this stage all the generatedmodels conform to the technological ASTMmetamodels
(iii) Applicative parsers allow building applicativemodels which are specific to some key artifact ofthe source platform (eg workspace file xcode-proj file pch file plist file xib file Pod file etc)Generally these artifacts include informationabout the source platform namely build settingsdependencies compiler executable name andstatic UI workflow ese models (eg Algo-rithm 1) are designed according to the applicativemetamodels
(iv) Data parsers allow building data models which arestatically stored in the file system (eg xdatamodelfile json file xml file etc)ese models conform totypical metamodels
42 Step 2 Semantic Extraction e semantic extractionstep is considered as a halfway point between code-to-modeland model-to-model steps In fact it aims to analyze thePSM models in order to extract some useful semantic in-formation which is required to build the PIM model eextraction process is designed to be iterative and supportsboth technological and applicative models is process isdriven by a set of semantic extractors that identify collectand consolidate all the semantic data required to build thesemantic mobile model PIM which is an instance of thesemantic mobile metamodel e authors have opted for ageneric metamodel which represents in a semantic mannerany mobile application e proposed metamodel is theresult of a close collaboration with two senior mobile
OMG standard metamodelsKDM ASTM SMM
Mobile platform Ametamodels
Semantic mobilemetamodels
Mobile platform Bmetamodels
Metamodel
ModelConforms to
Target mobilePSMs
32
1
TransformationSemantic model
PIM
Conforms to
Semanticextraction
Source mobilePSMs
Conforms to
Discovery
Source mobileapplication
mobile platform A
Target mobileapplication
mobile platform B
Codegeneration
Code
4
User inherits from
Figure 1 Main steps of the proposed MDRE approach to reverse-engineer a mobile app code to PSM PSM to PIM PIM to PSM and PSMto code
Table 2 Running examples open-source native iOS apps
ID Resource name Resource source link1 eSimpliestTodoList httpsgithubcomaltaibayareSimpliestTodoList
2 UIKitCataloguehttpsdeveloperapplecomlibrarycontent
samplecodeuicatalogIntroductionIntrohtmlapple_refdocuidDTS40007710
3 Tabsterhttpsdeveloperapplecomlibrarycontent
samplecodeTabsterIntroductionIntrohtmlapple_refdocuidDTS40011213
Table 3 Metrics of the running examples
ID No of source files (hm) Size of source file (KB) No of storyboard (xib file) No of UI elements Xcode build (SDK)1 10 30 1 26 72902 50 192 2 157 72903 22 22 3 31 7290
8 Mobile Information Systems
Mobile platform AASTM metamodel
Mobile platform AKDM metamodel
Mobile platform Aapplicativemetamodel
Datametamodel
DataPSM
Parsers
1 Model discovery
ApplicativePSM
InfrastructurePSM
TechnologicalPSM
Conforms to
Code to PSM
Programminglanguage files
Specific artifactsplatform
Assetfiles
Datafiles
Mobile app physical structure
Source mobileapplication
Mobile platform A
Figure 2 First step of the proposed MDRE approach model discovery (code to PSM)
BreakStatement
objcExpression
BlockStatement
Extends
Extends
ExtendsExtends
Extends
Statement
ContinueStatement
ExpressionStatement
IfStatement
WhileStatement
SwitchStatement
Extends
Extends
Extends
Extends
ForStatement
AstmObject
AstmSyntaxObject 1
1
1
1
1
ObjcBlockExpression
formalParameters
FormalParameterDefinition
+ aliasName EString
+ synthesizedName EString + nameString EString
accessKind
AccessKind Name
Identifier Name1
1
+ includeUnitSource EString
+ comment EString
1 lowast
ExtendsExtends
SourceLocation
AnnotationExpression
TypeReference
loctionInfo
ownedObjects
Extends
Extends
lowastExpression
expressionType
definitionType Definition
Extends
Extends
DeclarationOrDefinition
+ isClassAttr EBoolean
+ isProtocolimpl EBoolean
ExtendsinitialValue
DataDefinition
+ isMutable EBoolean
body1
lowastExtends
lowast
KDMEntity
DefinitionObject
Figure 3 Technological metamodel an excerpt of the ASTmetamodel corresponding to the Objective-C block expression e key entitiesare ObjcBlockExpression Expression Statement FormalParameterDefinition TypeReference AccessKind AstmObject KDMEntity etc
Mobile Information Systems 9
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
source mobile app (folders sub folders files assetsresources etc) e generated model is conformedto the Xcode Project KDM metamodel
(ii) Technological parsers allow generating abstractsyntax models of all the programming language filesused in the source application (eg C C++ Ob-jective-C and Swift) At this stage all the generatedmodels conform to the technological ASTMmetamodels
(iii) Applicative parsers allow building applicativemodels which are specific to some key artifact ofthe source platform (eg workspace file xcode-proj file pch file plist file xib file Pod file etc)Generally these artifacts include informationabout the source platform namely build settingsdependencies compiler executable name andstatic UI workflow ese models (eg Algo-rithm 1) are designed according to the applicativemetamodels
(iv) Data parsers allow building data models which arestatically stored in the file system (eg xdatamodelfile json file xml file etc)ese models conform totypical metamodels
42 Step 2 Semantic Extraction e semantic extractionstep is considered as a halfway point between code-to-modeland model-to-model steps In fact it aims to analyze thePSM models in order to extract some useful semantic in-formation which is required to build the PIM model eextraction process is designed to be iterative and supportsboth technological and applicative models is process isdriven by a set of semantic extractors that identify collectand consolidate all the semantic data required to build thesemantic mobile model PIM which is an instance of thesemantic mobile metamodel e authors have opted for ageneric metamodel which represents in a semantic mannerany mobile application e proposed metamodel is theresult of a close collaboration with two senior mobile
OMG standard metamodelsKDM ASTM SMM
Mobile platform Ametamodels
Semantic mobilemetamodels
Mobile platform Bmetamodels
Metamodel
ModelConforms to
Target mobilePSMs
32
1
TransformationSemantic model
PIM
Conforms to
Semanticextraction
Source mobilePSMs
Conforms to
Discovery
Source mobileapplication
mobile platform A
Target mobileapplication
mobile platform B
Codegeneration
Code
4
User inherits from
Figure 1 Main steps of the proposed MDRE approach to reverse-engineer a mobile app code to PSM PSM to PIM PIM to PSM and PSMto code
Table 2 Running examples open-source native iOS apps
ID Resource name Resource source link1 eSimpliestTodoList httpsgithubcomaltaibayareSimpliestTodoList
2 UIKitCataloguehttpsdeveloperapplecomlibrarycontent
samplecodeuicatalogIntroductionIntrohtmlapple_refdocuidDTS40007710
3 Tabsterhttpsdeveloperapplecomlibrarycontent
samplecodeTabsterIntroductionIntrohtmlapple_refdocuidDTS40011213
Table 3 Metrics of the running examples
ID No of source files (hm) Size of source file (KB) No of storyboard (xib file) No of UI elements Xcode build (SDK)1 10 30 1 26 72902 50 192 2 157 72903 22 22 3 31 7290
8 Mobile Information Systems
Mobile platform AASTM metamodel
Mobile platform AKDM metamodel
Mobile platform Aapplicativemetamodel
Datametamodel
DataPSM
Parsers
1 Model discovery
ApplicativePSM
InfrastructurePSM
TechnologicalPSM
Conforms to
Code to PSM
Programminglanguage files
Specific artifactsplatform
Assetfiles
Datafiles
Mobile app physical structure
Source mobileapplication
Mobile platform A
Figure 2 First step of the proposed MDRE approach model discovery (code to PSM)
BreakStatement
objcExpression
BlockStatement
Extends
Extends
ExtendsExtends
Extends
Statement
ContinueStatement
ExpressionStatement
IfStatement
WhileStatement
SwitchStatement
Extends
Extends
Extends
Extends
ForStatement
AstmObject
AstmSyntaxObject 1
1
1
1
1
ObjcBlockExpression
formalParameters
FormalParameterDefinition
+ aliasName EString
+ synthesizedName EString + nameString EString
accessKind
AccessKind Name
Identifier Name1
1
+ includeUnitSource EString
+ comment EString
1 lowast
ExtendsExtends
SourceLocation
AnnotationExpression
TypeReference
loctionInfo
ownedObjects
Extends
Extends
lowastExpression
expressionType
definitionType Definition
Extends
Extends
DeclarationOrDefinition
+ isClassAttr EBoolean
+ isProtocolimpl EBoolean
ExtendsinitialValue
DataDefinition
+ isMutable EBoolean
body1
lowastExtends
lowast
KDMEntity
DefinitionObject
Figure 3 Technological metamodel an excerpt of the ASTmetamodel corresponding to the Objective-C block expression e key entitiesare ObjcBlockExpression Expression Statement FormalParameterDefinition TypeReference AccessKind AstmObject KDMEntity etc
Mobile Information Systems 9
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
Mobile platform AASTM metamodel
Mobile platform AKDM metamodel
Mobile platform Aapplicativemetamodel
Datametamodel
DataPSM
Parsers
1 Model discovery
ApplicativePSM
InfrastructurePSM
TechnologicalPSM
Conforms to
Code to PSM
Programminglanguage files
Specific artifactsplatform
Assetfiles
Datafiles
Mobile app physical structure
Source mobileapplication
Mobile platform A
Figure 2 First step of the proposed MDRE approach model discovery (code to PSM)
BreakStatement
objcExpression
BlockStatement
Extends
Extends
ExtendsExtends
Extends
Statement
ContinueStatement
ExpressionStatement
IfStatement
WhileStatement
SwitchStatement
Extends
Extends
Extends
Extends
ForStatement
AstmObject
AstmSyntaxObject 1
1
1
1
1
ObjcBlockExpression
formalParameters
FormalParameterDefinition
+ aliasName EString
+ synthesizedName EString + nameString EString
accessKind
AccessKind Name
Identifier Name1
1
+ includeUnitSource EString
+ comment EString
1 lowast
ExtendsExtends
SourceLocation
AnnotationExpression
TypeReference
loctionInfo
ownedObjects
Extends
Extends
lowastExpression
expressionType
definitionType Definition
Extends
Extends
DeclarationOrDefinition
+ isClassAttr EBoolean
+ isProtocolimpl EBoolean
ExtendsinitialValue
DataDefinition
+ isMutable EBoolean
body1
lowastExtends
lowast
KDMEntity
DefinitionObject
Figure 3 Technological metamodel an excerpt of the ASTmetamodel corresponding to the Objective-C block expression e key entitiesare ObjcBlockExpression Expression Statement FormalParameterDefinition TypeReference AccessKind AstmObject KDMEntity etc
Mobile Information Systems 9
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
developers (iOS and Android) from the MyAppConverterteam e metamodel is thus refined and readjusted duringthe private beta test of iSpecSnapshot e metamodel in-herits mainly from the KDM standard (Figure 6) e se-mantic mobile metamodel is briefly outlined below
(i) A mobile application entity (MobileApp) has someinformation such as app name executable name
version author package etc It is composed ofseveral screens (AbstractScreen inherits from Screenwhich is described in the KDM metamodel)MobileApp contains information about orientationparameters also (ApplicationOrientation)
(ii) A screen has a single controller which is used tomanage the screenrsquos behavior (AbstractController
xcodeProject AbstractArtefactElement
+ extension String
+ includeUnitSource String
+ path StringExtends
Extends
AbstractRepositorysubRepos
1
Directory
lowast
lowast
files
XcodeAbstractElementt
StoryboardUIConfigFile
XcodePlistFile
XcodeJsonFile
XcodeStringFile
Extends
Extends
ExtendsExtends
Extends
XcodeHSourceFile
XcodeProjectRepository
+ projectType EString
+ language String
+ path String
+ version String
+ encoding String
SourceFile
InventoryItem
XcodeMSourceFile
AbstractSourceFile
Extends
Extends
Extends
1
Extends
Figure 4 Infrastructure metamodel an excerpt of the iOS xcode project metamodel e key entities are XcodeProjectRepositoryAbstractRepository Directory XcodeAbstractElement XcodeHsourceFile XcodeMSourceFile etc
storyboardButton
Scene
KDMEntity
Extends Extends Extends
EntryNodelowast childs
attributes
+ name String
+ value String
EntryAttribute
1 1+ customClass EString
+ intialViewController EString
+ useAutoLayout EString
+ systemVersion EString
Extends
ExtendsExtends
Extends
Extends
Extends
TextField
Image
ViewController
CollectionView
View
StoryboardDocumentlowast
Figure 5 Applicative metamodel an excerpt of the iOS Storyboard metamodel e key entities are StoryboardDocument EntryNodeEntryAttribute View Scene TextField etc
10 Mobile Information Systems
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
inherits from KDMEntity which is described in theKDMmetamodel) e screen may contain a layout(AbstractLayout) which is used to group the UIcomponents
(iii) A controller which refers to View Controller foriOS and Activity for Android groups methods thatimplement the behavior of the actions It also de-fines methods for managing the controllerrsquoslifecycles
(iv) e UI component which is identified as anAbstractView entity inherits from UIElementwhich is described in the KDM metamodel It isdescribed by the following attributes id widthheight marginTop marginBottom etc e UIcomponent is likely to handle events
(v) e event entity can trigger an action (Abstrac-tAction) e result of the action may lead to aredirection to the same screen or to another screenor even to another application
is stage includes also the following substeps PSMmodel exploring PSM model querying and PIM modelgenerating To build the PIM model the extractors men-tioned above seek to identify the following information
(i) General information app name icon app packageversion and author
(ii) Platform information build device orientationlinked frameworks libraries and localization
(iii) Use cases information launch screen screenworkflow controllers app lifecycle behavior nav-igations events actions and service flow
(iv) UI components properties size position offsetrange color state transition and effects
e resulting PIM model is in accordance with theprevious semantic mobile metamodel
43 Step 3ModelTransformation e goal of this model-to-model M2M transformation phase is to transform the PIMmodel generated at the end of the previous step into a PSMspecific to the target platform In the literature modeltransformation can be performed using various languagesdeclarative (eg QVT [34]) imperative (eg Java) or hybrid(eg ATL [35]) In the case of the current approach theauthors have opted for Java as an imperative language todrive the transformation stage eir choice makes sensefor many technical reasons namely in terms of design
ltstoryBoarddocument xmiversion ldquo20rdquopropertyAccessControl ldquononerdquo systemVersion ldquo15D21rdquotargetRuntime ldquoiOSCocoaTouchrdquo useAutolayout ldquoYESrdquoinitialViewController ldquoWIIndashGlndashwjJrdquo toolsVersion ldquo9531rdquo version ldquo30rdquogtltchild xsitype ldquostoryBoarddependenciesrdquogtltchild name ldquodeploymentrdquogtltchildgtltchild xsitype ldquostoryBoardscenesrdquogtltchild xsitype ldquostoryBoardscenerdquo sceneID ldquoNNpndashGindashV3jrdquogtltchild xsitype ldquostoryBoardobjectsrdquogtltchild xsitype ldquostoryBoardtableViewControllerrdquocustomClass ldquoCategoryViewControllerrdquo id ldquo4epndashNpndashax8rdquogtltchild xsitype ldquostoryBoardtableViewrdquo sectionHeaderHeight ldquo22rdquoalwaysBounceVertical ldquoYESrdquo id ldquo4V1ndash1BndashaCerdquo style ldquoplainrdquoopaque ldquoNOrdquo separatorStyle ldquodefaultrdquo contentMode ldquoscaleToFillrdquokey ldquoviewrdquo sectionFooterHeight ldquo22rdquo clearsContextBeforeDrawing ldquoNOrdquoclipsSubviews ldquoYESrdquo rowHeight ldquo44rdquo dataMode ldquoprototypesrdquogtltchild xsitype ldquostoryBoardrectrdquo height ldquo568rdquowidth ldquo320rdquo y ldquo00rdquo key ldquoframerdquo x ldquo00rdquogtltchild xsitype ldquostoryBoardautoresizingMaskrdquowidthSizable ldquoYESrdquo heightSizable ldquoYESrdquo key ldquoautoresizingMaskrdquogtltchild xsitype ldquostoryBoardcolorrdquo colorSpace ldquocalibratedWhiterdquoalpha ldquo1rdquo white ldquo1rdquo key ldquobackgroundColorrdquogtltchildgtltchildgtltchildgtltchildgtltchildgtltchild xsitype ldquostoryBoardpointrdquo y ldquo752rdquo key ldquocanvasLocationrdquo x ldquo1220rdquogtltchildgtltchildgtltstoryBoarddocumentgt
ALGORITHM 1 Applicative PSM an excerpt of the inferred storyboard model
Mobile Information Systems 11
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
refactoring performance and integration e process isobviously driven by metamodels It is carried out explicitlyby a set of transformers likely imperative language (egJava) which allow exploring the PIM model queryingcomputing and generating the target PSM In other wordsthe transformation rule was designed as a FROM-TO dipolee rule is triggered when the FROM node fulfills severalconditions related to the TO node e rule logic may in-clude special treatments and data computation dependingon the target platforme process is recursive until the PSMmodel is built
To sum up the model-to-model process involves thefollowing workflow model exploration model queryingmodel computation and PSM generation With regard tothe studied scope the authors have described the targetmetamodels which are specific to the Android platformwhile specifying the following areas applicative and docu-mentation e Applicative metamodel defines mainlyspecific information regarding the target mobile platformincluding (build settings dependencies compiler execut-able name and static UI workflow) It is designed in ac-cordance with the official Android documentation (AndroidUI amp navigation official documentation httpsdeveloperandroidcomguidetopicsui) An overview of the Androidapplicative metamodel is illustrated in Figure 7
Algorithm 2 visualizes an example of the transformedPIM model to Android UI model (PIM to PSM)
e documentation metamodel describes all the neededinformation to build the structure of a functional specifi-cation document e authors have opted for the use caseformat as suggested by the interviewees in the empiricalstudy section e document includes the following in-formation app name app icon app content build in-formation activity diagram business class model entityclass model screens screen components and rule actionsAn overview of the documentation metamodel is illustratedin Figure 8
Additionally the transformation process includes acomplementary key substep which is the mapping betweenthe two platforms e authors distinguish two types ofmapping
(i) Semantic mapping It aims to define a semanticcorrespondence between the applicative meta-models for both source and target mobile platformsFor instance it gives answers to how can seek toaddress matching between mobile platform UIcomponents Table 4 shows a list of the semanticmapping between iOS UI components and AndroidUI Components
semantic UIDisplay
ExtendsKDMEntity
Extends
AbstractController
AbstractLifeCycleBehaviour
Screen
ScreensExtends
AbstractScreen 1controller
1layout
views
AbstractLayoutExtends Event
Extends
1action
AbstractEvent AbstractAction
1
forward
AbstractForward
MobileApp
+ id EString
+ id EString
+ id EString
+ width EString
+ height EString
+ marginTop EString
+ marginBottom EString
+ marginBottom EString
+ marginLeft EString
+ id EString
+ qualifiedName EString
+ title EString
+ isMainScreen EBoolean
+ name EString
+ icon EString+ mainPackage EString
uiOrientations
ApplicationOrientation
+ name String
+ value String
UIElement
Extends
AbstractView
1
1
1
Figure 6 An excerpt of the semantic mobile metamodele key entities areMobileApp AbstractScreen AbstractView AbstractcontrollerAbstractLayout Abstractevent etc
12 Mobile Information Systems
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
At this stage the authors also define several trans-formation rules in order to match from a semanticpoint of view the UI inconsistencies between the twoplatforms namely text alignment navigation bar fontfamily button styles controls icons (Table 5)Moreover the authors set up a specific trans-formation rule to support Android multidevicesiOS devices come in a variety of screen sizes and canbe used in either portrait or landscape orientation(Table 6) It was noted that in iOS the position of allUI components are absolute on a device metriccoordinate system base except for autolayout fea-ture Using autolayout allows defining rules (knownas constraints) that govern the content in the iOSappAndroid runs also on a variety of devices that havedifferent screen sizes and pixel densities (Pixeldensity on Android httpsmaterialiodesignlayoutpixel-densityhtmlpixel-density-on-android)(Table 7)e dedicated transformation rule will be based on anabsolute metric system To assess this the authorsused the smallest width qualifier (the smallest widthqualifier specifies the smallest of the screenrsquos twosides regardless of the devicersquos current orientationhttpsdeveloperandroidcomtrainingmultiscreenscreensizesTaskUseSWQuali) e ldquosmallest widthrdquoscreen size qualifier allows providing alternativelayouts for screens that have a minimum widthmeasured in density pixels (see Table 8)
e authors have implemented a cross-multiplicationrule in order to identify the width rate and the heightrate for the two device platforms ey have con-sidered devices that have metrics closer to each other(eg iPhone 6 vs Samsung S5) e rule is as follows
width rate Android device widthiOS device width
height rate Android device heightiOS device height
(1)
(ii) Technological mapping it aims to establish amapping knowledge base [21] e base is designedas a node graph which manages the relationshipbetween the SDKs API of the source and targetmobile platforms (see Figure 9) e analysis of thesource ASTMmodel allows generating a dependencyreport of the used APIs throughout the sourcemobile application is report helps developers todrive the choice of which target API to use during theporting process
44 Step 4 Code Generation is last step of the reverse-engineering process is considered as a model to text M2Ttransformation It aims to generate code or textual artifactsfrom PSM models e process is broken down into severalgenerators Each generator is considered as a template en-gine that serves a specific domain of the targeted platform
e authors have opted for the PSM to code strategywhich is widely considered to be the most suitable for
AndroidApp AbstractView AbstractScreen AbstractController AbstractLayout
LinearLayout
Segues
AndroidNavigationSegue
RelativeLayout
AndroidApp
AndroidView
+ alpha EFloat
+ clickable EBoolean
+ translationX EFloat
+ translationY EFloatStyle
StylesubViews
Extends Extends
ExtendsExtends
Extends
Extends
Extends
Button
ImageView
PickerSpinner
EditText
TextViewAndroidViewGroup
+ clipChildren EBoolean
+ layoutMode EString
+
1
1
MobileApp
ExtendsExtends Extends
1
AndroidScreen Activity AndroidLayout
+ orientation EString
+ gravity EString
+ parentController EString
+ viewActivity EBoolean
Extends
Extends Extends
Extends
Figure 7 Model transformation an excerpt of the Android applicative metamodel e key entities are AndroidApp AndroidViewAndroidScreen Activity AndroidLayout AndroidViewGroup TextView etc
Mobile Information Systems 13
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
describing and representing the app requirements in a givendevelopment platform However authors in [36] highlightedother code-generation strategies when it comes to MDDapproach such as PIM-to-PSM-to-Native Code PIM-to-Native Code PSM-to-Native Code PIM-to-Cross PlatformCode PIM-to-Cross Platform Framework and SM-to-CrossPlatform Code e generators are basically based on Xpand(Eclipse Xpand httpwikieclipseorgXpand) which is aModel to Text Language (MTL) [37] dedicated for codegeneration based on EMFmodels Xpand provides interestingfeatures such as polymorphic template invocation aspect
oriented programming functional extensions and modelvalidation ere are also other M2T alternative tools likeAcceleo (Eclipse Acceleo httpwwweclipseorgacceleo)and JET (Eclipse JET httpwwweclipseorgmodelingm2tdownloadsprojectjetarchives) which provide code-gen-eration framework and facilities that are used by EMF ebasic idea of generators is to refine and transform PSMmodels into code e templates contain fragments of thetarget text and pieces of code that are replaced with in-formation derived from the PSM model e authors havedefined several templates for each application domain
ltxml version ldquo10rdquo encoding ldquoASCIIrdquoltandroidappAndroidAppgtname ldquoeSimpliestTODOLIstrdquo mainPackage ldquocommyappconvertermobilerdquo version ldquo100rdquogtltscreens xsitype ldquouiAndroidScreenrdquoname ldquoActivity_2sa_q5_EymrdquoscreenWidth ldquo3200rdquoscreenHeight ldquo5680rdquonavBar ldquotruerdquogtltcontroller xsitype ldquocoreActivityrdquoname ldquoActivity_Vic_8g_ebUrdquo qualifiedName ldquocommyappconvertermobileActivity_Vic_8g_ebUrdquo id ldquoVicndash8gndashebUrdquogtltlayout xsitype ldquolayoutRelativeLayoutrdquonavBar ldquotruerdquo width ldquomatchparentrdquo height ldquomatch_parentrdquo background ldquoFFFFFFFFrdquogtltviews xsitype ldquolayoutNavigationBarrdquoid ldquotaskdetailrdquo height ldquo64rdquo tintColorNav ldquo1E73FErdquo backgroundTint ldquoF5F5F5rdquo title ldquoTask DetailrdquobackTitle ldquoBackrdquo titleColor ldquo000rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoid3vVkR7e7rdquo width ldquo320rdquo height ldquo568rdquo background ldquoFFFFFFFFrdquo backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewScrollViewrdquoid ldquopvh_st_nB8rdquo width ldquo320rdquo height ldquo568rdquogtltsubLayout xsitype ldquolayoutRelativeLayoutrdquoid ldquoKDE_WF_gSZrdquo width ldquo320rdquo height ldquo40rdquo marginTop ldquo15rdquo background ldquoFFFFFFFFrdquo
backgroundColor ldquoFFFFFFFFrdquogtltviews xsitype ldquoviewTextViewrdquoid ldquoSDE_fx_EOQrdquo width ldquo42rdquo height ldquo21rdquo marginTop ldquo9rdquo text ldquoTitlerdquo marginLeft ldquo20rdquo
textAlignment ldquocenterverticalrdquo textColor ldquoFF000000rdquo textSize ldquo140rdquogtltcolorsred ldquo0rdquo green ldquo0rdquo alpha ldquo1rdquo blue ldquo0rdquo textColor ldquodarkTextColorrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltviews xsitype ldquoviewEditTextrdquoid ldquoP74_wp_hB2rdquo width ldquo230rdquo height ldquo30rdquo marginTop ldquo5rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquo
textSize ldquo130rdquo borderStyle ldquoroundedRectrdquogtltfont type ldquosystemrdquo key ldquofontDescriptionrdquogtltviewsgtltcolorswhite ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltsubLayout xsitype ldquolayoutRelativeLayoutrdquo
id ldquonw2_zD_rrPrdquo width ldquo320rdquo height ldquo185rdquo marginTop ldquo550rdquo marginLeft ldquo0rdquo background ldquoFFFFFFFFrdquobackgroundColor ldquoFFFFFFFFrdquogt
ltviews xsitype ldquoviewDatePickerrdquoid ldquoqLg_1Q_MqFrdquo width ldquo230rdquo height ldquo162rdquo marginLeft ldquo70rdquo marginRight ldquo20rdquogtltcolors white ldquo1rdquo alpha ldquo1rdquo key ldquobackgroundColorrdquo colorSpace ldquocustomrdquogtltsubLayoutgtltviewsgtltsubLayoutgtltlayoutgtltscreensgtltandroidappAndroidAppgt
ALGORITHM 2 PIM to PSM transformation an excerpt of the inferred Android UI PSM model
14 Mobile Information Systems
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
(i) Templates for Mobile App physical structure (An-droid studio structure)
(ii) Templates for target language (Java class)(iii) Templates for UI part (xml layouts drawables)(iv) Templates for specific assets (manifest gradle
config values strings and build settings)(v) Templates for documentation (functional spec docs
and readme file)(vi) Templates for data (json csv xml and SQLLite)
Figure 10 illustrates an overview of xpand templatesdesigned for functional spec document
Figure 11 illustrates an overview of xpand templatesdesigned for Android UI components
Figure 12 outlines an overview of the result of PSM to codestep which is performed on the functional spec PSM modele generated source codes for the three running examplesare shared publicly on a dedicated Gitlab repository (Tabster(Tabster Android UI project httpsgitlabcomispecsnapshottabster) eSimpliestTodoList (eSimpliestTodoList
Android UI project httpsgitlabcomispecsnapshotthesimpliesttodolist) and UICatalog (UICatalog Android UIproject httpsgitlabcomispecsnapshotuikitcatalog))
45 Discussion In the literature Brunliere et al in [38] havedrawn the authorsrsquo attention to a ldquoMust Haverdquo characteristicthat each MDRE approach should abide by e authorsbelieve that these characteristics seem to be well foundedespecially if a sustainable and scalable approach is to beensured ese criteria are as follows
(i) Genericity an MDRE approach should rely onOMG metamodels standards and customizablemodel-based components
(ii) Extensibility an MDRE approach should guaranteea separation between themodels (as input or outputelements) and the actions and treatment of eachstage of the reverse-engineering process
(iii) Application domain the Scope of the approachconcerns specific or generic purpose
SnapShot
SnapShotDoc Pages
AbstractPages
AbstractSection
+ projectName EString
+ icon EString
+ icon EString
+ id EString
+ id EString
+ name EString
+ hyperlink EString
+ hyperlink EString
ExtendsExtends Extends Extends Extends
Sections
ApplicationScreensPageUmlModelsPageOverViewPageSummaryPageCoverPage
Size
Font
Position
+ x EDouble
+ y EDouble
+ height EDouble
+ width EDouble
Extends
Extends
Extends
ExtendsExtendsExtendsExtends
Extends
Extends
Extends
Extends
+ version EString
+ title EString+ title EString
+ type EString
+ id EString
ScreenShotUIElement
ScreenShotButton ScreenShotLabel ScreenShotTextView ScreenShotImageView
ScreenShotSection AbstractUMLViewSection
ScreenShotWebViewLinked flow
ActivityDiagFlow
ActivityDiagOperation
ActivityDiagramSection
uiElements
+ maxHeight type
+ maxWidth EDouble1
1
1
1
PersistenceEntitySection BusinessEntitySection
ActivityDiagElement
FlowEventUISpec
Event
1
1to
1 text EString
+ contentMode EString
+ color EString+ size EString
+ date EString
Figure 8 An excerpt of the functional spec document metamodel e key entities are SnapshotDoc AbstractPage AbstratcSection CoverPage ScreenShotSection AbstractUMLViewSection ScreenShotUIElement etc
Mobile Information Systems 15
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
(iv) Automation a reverse-engineering process shouldbe totally or partially automated
(v) FullPartial coverage the modeling should cover allthe representative artifacts of the system and alsomaintain a semantic link between them
(vi) Scalability this refers to how well the MDRE toolworks when the size of the system being studiedincreases
(vii) Validation has the approach been validated byindustrial case studies or was it just in an earlystage
Based on the list of criteria described above the authorstry to give answers on how their approach remains efficientregarding the MDRE field
451 Genericity e proposed approach provides a coremetamodel based on the OMG standards KDM and ASTMspecification Indeed for each MDRE step the authors havedescribed a set of metamodels depending on the reverse-engineering purpose for example
(i) Used metamodels for model discovery step XcodeProject metamodel Objective-C metamodel Swiftmetamodel Storyboard metamodel Xib meta-model Plist metamodel and xcdatamodelmetamodel
(ii) Used metamodels for semantic extraction stepsemantic metamodel
(iii) Used metamodels for model transformation stepAndroidApp metamodel AndroidProjectStructuremetamodel Java metamodel and Functional specdocument metamodel
Table 4 Mapping between iOS UI components and Android UIcomponents
iOS UI component Android UI componentUIActivityIndicatorView SpinnerUIAlertView AlertDialogUIBarButtonItem ActionBarUIBarItem MenuItemUIButton ButtonUIColor ColorUIDatePicker DatePickerUIEvent EventUIFont FontUIImage ImageUIImageView ImageViewUIInputView KeyboardViewUILabel TextViewUIMenuItem MenuItemUINavigationBar ActionBarUIPageViewController ViewPagerUIPickerView DatePickerUIProgressView ProgressBarUIScrollView ScrollViewUISearchBar SearchViewUISegmentedControl RadioGroupUISlider SeekBarUISplitViewController RelativeLayoutUIStepper ButtonUISwitch ToggleButtonUITabBar TabHostUITabBarItem TabWidgetUITableView ListViewCompatUITableViewCell TableRowUITextField EditTextUITextPosition FieldPositionUITextView TextViewUIToolbar ActionBarUIView LayoutUIWebView WebViewUIWindow Window
Table 5 UI aspects mapping between iOS and Android
UI aspect iOS AndroidTextalignment Centered Left
Navigationbar
Tab bar menu withcentered items
Bottom navigationlocated
at the bottom
Font family San Francisco andHelvetica Neue Roboto
Buttonstyles Flat button with shadows Floating action buttons
with textIcons in line icons ick stroke iconsControls Tabs or buttons Simple underline
List With arrow icons No arrow icons on theright side
Table 6 iPhone device screen sizes
Device Portrait dimensionsiPhone iPhone 4 4s 320 dptimes 480 dpiPhone 5 5s 5c SE 320 dptimes 568 dpiPhone 6 6s 7 8 375 dptimes 667 dpiPhone 6+ 6s+ 7+ 8+ 414 dptimes 736 dpiPhone X xs 375 dptimes 812 dpAutolayout 600 dptimes 600 dp
Table 7 Android device screen sizes
Device Portrait dimensionsGoogle Pixel 411 dptimes 731 dpHTC One M9 360 dptimes 640 dpLG G3 480 dptimes 853 dpMoto X 360 dptimes 640 dpNexus 5 360 dptimes 640 dpNexus 7 600 dptimes 960 dpSamsung Galaxy S5 360 dptimes 640 dpSamsung Galaxy S8 360 dptimes 740 dpSony Xperia Z3 360 dptimes 640 dp
Table 8 Android small width metrics
Metric Smallest width320 dptimes 569 dp sw320dp360 dptimes 640 dp sw360dp384 dptimes 640 dp sw384dp411 dptimes 731 dp sw411dp
16 Mobile Information Systems
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
452 Application Domain e scope of the proposed ap-proach is specifically designed for reverse-engineeringmobile platforms field In this work the authors focused onthe generation of functional specs and Android UI eseartifacts are useful for developers to bootstrap the fullporting from iOS to Android Nevertheless the approachitself is also valid for other purposes e strong point of thecurrent approach lies in representing the mobile applicationin the form of PSMmodels In turn any information or datafrom the application is preserved for later processing ereare others use cases in which the current approach can beexploited for example
(i) Upgrading iOS apps written in Objective-C to thelatest Swift language version
(ii) Refactoring some APIs towards more compliantand stable ones
(iii) Reverse engineering of the iOS UI part to MicrosoftXamarin UI or React Native
(iv) Reverse engineering from Android to iOS
453 Extensibility e proposed approach guarantees aseparation between the models and the actions of each stage ofthe reverse-engineering process Indeed the implementation
Source SDK API
iOS APIA
Header_1
Method_1
Method_1Method_n
Method_n
Property_n
Property_n
Property_1
Property_1
Property Property
Property
Type Type
Class_1
Android API A
Target SDK API
Param_nParam_1Param Param
Param
Param Param
Method
MethodMethod
Method
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
ltltMAPPED_TOgtgt
Param_1 Param_1
Param_1
Param_n Param_n
Param_n
Param
Param Param
Figure 9 Structure of the knowledge base graph
Figure 10 Overview of specific Xpand templates designed for the functional spec document
Mobile Information Systems 17
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
of the current approach includes facilities to expand meta-models or add new ones and the abilities to define newtransformation rules as well as to define new generatorrsquostemplates
454 Automation e current approach is totally auto-mated with regard to the scope of generating the functional
specs and the UI part However it is plausible that a numberof limitations may be raised when it comes to the mappingbetween platform SDKs
455 FullPartial Coverage In the proposed approachmetamodels are described in order to cover all the views ofthe source and target mobile platforms
Figure 11 Overview of specific Xpand templates designed for the Android UI project
Figure 12 Overview of the generated functional spec document
18 Mobile Information Systems
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
5 Tool Implementation iSpecSnapshot
51 Description is section describes iSpecSnaphot tool asa reverse-engineering tool which implements the proposedMDRE approach As stated in Introduction the main aim ofthis tool is to produce spec documentation for a given nativeiOS mobile app and reverse-engineer the Android UI partiSpecSnapshot is a model-based toolbox an experimentaltool developed by MyAppConverter team as a part ofMyAppConverter SAAS platform Figure 13 shows thetechnical architecture of iSpecSnapshot
iSpecSnapshot is structured as a set of loosely coupledcollaborating services Each service is registered with a so-called service registrye registration process is periodicallyrefreshed following a heartbeat mechanism e servicersquoslogic implements narrowly related subservices It runs as aunique process and communicates through a distributedstreaming platform to serve each MDRE stage Note that allservices are tightly communicating with the underlyingrepository cluster e cluster includes the following re-positories metamodel repository knowledge base andtemplate repository
511 Metamodel Repository It includes in particular all themetamodels which are specific to the mobile platformsMetamodels are classified by platform type and by domainsuch as infrastructure technological and platform-specificmetamodel For example for the iOS platform the meta-models are listed as follows
(i) Infrastructure Xcode Project metamodel(ii) Technological Objective-C Metamodel Swift
Metamodel(iii) Platform-specific metamodels storyboard meta-
model plist metamodel and xcdata metamodel
512 Knowledge Base KB It houses the mapping betweenthe SDKs APIs of the two platforms (iOS and Android) eKB is structured as a graph database each node represents anentity (headerjava package class interface method pa-rameter access kind etc) and each relationship representshow two nodes are associated Using Graph databases havemany key advantages such as performance flexibility andagility
513 Template Repository It includes all kind of templatesthat are used in the code-generation phase It is alsostructured by domains infrastructure technological doc-umentation and applicative e following classification isconsidered
(i) Infrastructure it describes the Android studioproject template
(ii) Technological it describes the Java AST template(a) Declaration block class interface method etc(b) Statement block if For While etc
(iii) Applicative it describes the UI components (Text-View Button List Image TexyFiel Switch etc)
(iv) Documentation it describes all sections of thefunctional spec document Cover page UML dia-gram page Activity diagram section Coverage re-port etc
From a usability view the user experience of the tool isergonomically smart and intuitively simple (Figure 14)Indeed to get started with a porting session the end usershould proceed as follows first create an account thenupload the source code of the iOS app start the portingprocess visualize the UI preview and analyze the generatedoutputs (SFD document and Android UI project)
iSpecSnapshot
Input
iOS mobile appsource code
APImanagement
Distributed storage
Parsersmicroservices
Serviceregistry
Metamodelrepository
Knowledge basegraph DB
Templatesrepository
Android mobile appUI source code
Functional spec doc
Output
Extractorsmicroservices
Transformersmicroservices
Generatorsmicroservices
Figure 13 Technical architecture of iSpecSnapshot
Mobile Information Systems 19
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
From a logical view iSpecSnapshot provides fourservices
(i) Parsers allow to automatically generating PSMmodels from the iOS mobile app source code ePSMmodels correspond to Xcode project structureprogramming language (C C++ Objective-C andSwift) xib file plist file strings file etc
(ii) Extractors analyze the PSM models which areproduced by the parsers in order to extract se-mantic information for building the PIM pivotmodel (semantic mobile model) e PIM modeltypically identify specific information on the iOSapp name icon build device orientation linkedframeworks screen workflow lifecycle behaviornavigations transition UI component propertiesetc
(iii) Transformers explore the PIM model and launch arecursive transformation process in order to build thedocumentation PSM model and the Android PSMmodel SFDrsquos PSM model describes in a reliablemanner the whole structure and content of thefunctional specification documentation Cover pagesummary page screen page framework dependenciesandmapping entitymodels persistentmodels activitydiagram etc e Android app PSM model describesthe structure of the target Android UI project
(vi) Generators move around the resulting SFD PSMand Android PSM models and load the corre-sponding templates from the template repository inorder to generate the SFD document and the An-droid UI skeleton
52 Limitations e authors sound a note that their ap-proach supports currently the reverse engineering of iOSapplications that have the UI part statically defined in thestoryboard or Xib files Indeed the majority of the UIcomponents of the UIKit framework are covered (UIViewUILabel UIButton UITextField UITextView UISliderUISegmentedControl UISwitch UITableView etc) exceptsome restrictions compared tomatching semantic propertieswith their Android correspondents However the currentresearch is in progress to support UIKit applications whose
UI part was dynamically programmed or customized inSwift or Objective-C e major challenge in this task is howto recognize code blocks where developer uses the in-structions for building instantiating initializing and in-voking UI components inside the controllerrsquos AST tree
6 Evaluation
e implemented tool is evaluated according to two aspectsevaluation as a tool that meets software developmentstandards and evaluation as an effective mobile porting tool
e evaluation of the tool with regard to software de-velopments standard includes two testing phases alphatesting and private beta testing In lockstep with theMyAppConverter team the authors have conducted alphatesting stage to avoid any bugs or issues and to guaranteethat the tool meets perfectly the established requirements Atthe end of this stage private beta testing was conducted witha close group of developers selected from the interviewsessions e aim of the private beta testing is to collectfeedbacks on how to improve the overall user experience ofthe tool as well as fixing some of the issues found in thegenerated outputs
To evaluate the proposed tool as an effective mobileporting tool for mobile developers the authors used anexperimental procedure within the selected group of beta-test users e objective of this process is to ensure that theresulting outputs meet the expectations of the developers interms of functional specs details extracted from the iOSsource app and the UI quality of the Android project portedfrom iOS erefore they try to answer to the fundamentalproblematic of the current research RQ Does iSpecSnapshotefficiently help mobile developers to speed up the mobileporting process
To assess an efficient evaluation the authors will carefullyfocus on apps that are built usingUIKit framework (iOSUIKitFramework httpsdeveloperapplecomdocumentationuikit) And obviously they will be particularly interested infeedbacks from two categories of users Android developersand functional analysts e authors also did look for othertools to compare with iSpecSnapshotrsquos features But so far theycould not find any tool whose functional scope can be com-pared to iSpecSnapshot tool (generating functional spec andAndroid UI part) Nevertheless there are commercial tools
Figure 14 iSpecSnapshot 3 steps to perform a successful porting process create an account upload the iOS source code and analyze thegenerated outputs
20 Mobile Information Systems
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
whose technical documentation is quite poor and which havethe vocation of binary decompiler or interactive disassembleror even debugger such as veracode iRet (iRet Toolkit httpswwwveracodecomiret-ios-reverse-engineering-toolkit-veracode) IDA (DA Pro httpswwwhex-rayscomproductsida) and Hopper (Hooper httpswwwhopperappcom)
61 Participants e authors have recruited 13 participantsselected from the interview sessions e participants aredivided into two categories e first is composed of 10Android developers with minimal skills of the iOS platforme second involves 3 mobile functional analysts who areaccustomed to produce mobile functional spec documente majority of the participants either hold positions atstartups or are freelancers who are self-employed All theparticipants were ensured about their privacy and databefore their participation in this study e data was solelyused for research purposes and will not be shared withanyone under any circumstances
62 Experimental Objects e authors have carried outexperiments on the beta-test userrsquos apps As was afore-mentioned they have limited the experimental objects to 13iOS apps which are submitted by the selected participantse choice of participantsrsquo apps is determined by 3 criteriaFirst the application must be compatible at least with theXcode7x version Secondly the UI part should be designedaccording to the storyboardxib files and finally the usage of
the UIKit components should exceed 70 of all the used UIcomponents (customized UI components will not be cov-ered in the current scope of the tool) To preserve theconfidentiality of apps supplied by participants the authorshave identified the apps by the identifier APPn(1le nle 13)
and participant by the identifier PARm(1lemle 13)Table 9 shows some characteristics of each application
number of resources who has developed the iOS app globaldevelopment cost (man-day) workload of the UI part (man-day) number of screens total number of the UI componentand UI complexity As it emerges from the data reported inTable 9 the selected apps are sufficiently diverse since theyrepresent different functional scopes and have variablemetrics in terms of workload and size
63 Metrics Definition Since in the present work the au-thors focused on reverse engineering of the functional specand UI porting they merely point out that in their experi-ments they decide to evaluate the effectiveness of iSpecS-napshot with regard to the accuracy of the functional specformulation coverage of frameworkmapping coverage of theUI components and cost margin of the generated Android UIpart erefore the following metrics are considered
(i) Functional spec accuracy percentage (FSA) repre-sents the percentage of consistencycompleteness ofthe information represented in the FSD documentincluding the persistence model (PM) the businessclass model (BM) and the activity diagram (AM)It can bemeasured according to the following formula
PM number of detected items for the persistencemodel
total number of the persistencemodel itemstimes 100
BM number of detected items of the businessmodel
total number of the businessmodel itemstimes 100
AM number of detected screen transitiontotal number of screen transition
times 100
FSA mean(PMBMAM)
(2)
(ii) Coverage of framework mapping percentage (CFM) defines the percentage of the mapped iPhone
SDK elements used in the iOS source code with theircorrespondent in the Android SDK
CFM number of mapped iPhone SDK elements
number of iPhone SDK elements used in the source codetimes 100 (3)
(iii) Coverage of UI component percentage (CUI)defines the percentage of the generated Android UI
component against the overall of the UI compo-nents of the iOS App
Mobile Information Systems 21
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
CUI 1113936
snn1(number of generatedUI component per each screentotal number of UI component per each screen) times 100
sn
sn screen numbers(4)
(iv) Cost margin of the generated Android UI partpercentage (CMUI) defines the cost margin
involved by the generated Android UI part against afrom scratch development task
CMUI 100 times 1 minusEffAutoGenUI + EffCustomUI
EstimEffAndroidUIMan1113888 1113889
EffAutoGenUI effort of the automatic generation of UI part
EffCustomUI effort of developing customizedUI component
EstimEffAndroidUIMan estimated effort for developing theAndroidUI partmanually
(5)
64 Experimental Design e experimental methodologywhich is performed for carrying out the study consists ofthree sequential steps source app analysis outputs com-parison and metrics analysis
In the source app analysis step one researcher and a senioriOS developer from theMyAppConverter team had the task ofpreparing an analytical report for each iOS application from thelist of selected objects e report includes the following in-formation number of screens number of standard UI com-ponents per screen number of customized UI components UIcomplexity transition between screens (defined using story-board connections or managed by code) and referenced podsor third libraries e analysis task consists also of revisiting theiOS PSM specific to each app e goal is to ensure that themodel resulting from the model discovery phase does notcontain errors which may lead to false results for the otherstages of the MDRE process
In the outputs comparison step the authors divided theselected subjects in 2 groups G-UI includes Android de-velopers who have the task of reviewing the Android UIproject generated by iSpecSnapshot tool and compare it tothe UI part of their iOS app e second G-SPEC group hadthe task of evaluating the content of the functional specdocument generated for all the apps e analysis of theparticipants is even more important since it gives insight acritical view of the end customer in relation with the resultsgenerated by the evaluated tool However the authors be-lieve that limiting themselves to their own judgment interms of results can bias the overall evaluation of the tool Toassess the generated Android UI project they instruct theparticipants to import the generated Android UI project intoAndroid Studio IDE and they recommend using the 31xversion e participants are invited to use the Xcode In-terface Builder IDE 9x to compare the iOS UI part with the
Table 9 Metrics of the experimental objects number of resources who has developed the iOS app global development cost (man-day)workload of the UI part (man-day) number of screens total number of the UI component and UI complexity
iOS appID Owner Developed by
(resource)Global dev cost
(man-day)UI part workload
(man-day)No ofscreen
No of UIcomp
UIcomplexity Category
APP1 PAR1 2 30 6 18 158 Medium EducationAPP2 PAR2 2 68 12 42 347 Basic GamingAPP3 PAR3 1 43 9 19 144 Medium CommunicationAPP4 PAR4 3 63 15 38 290 Complex Social
APP5 PAR5 3 96 20 49 370 Complex Teamcollaboration
APP6 PAR6 3 75 22 43 314 Medium HealthAPP7 PAR7 2 54 11 23 130 Complex NetworkingAPP8 PAR8 1 15 3 9 53 Basic AdvertisingAPP9 PAR9 2 24 5 25 211 Basic MedicineAPP10 PAR10 2 20 4 14 107 Medium EventsAPP11 PAR11 1 30 5 13 85 Medium GamingAPP12 PAR12 2 64 21 27 167 Complex SocialAPP13 PAR13 1 20 4 13 112 Basic Medicine
22 Mobile Information Systems
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
generated Android UI It should be noted that the generatedandroid xml layout is identified by the pattern activity_ ltidof the iOS screengtxml To better help the members of eachgroup in their analysis the authors have configured theTrello (Trello httpswwwtrellocom) agile tool Trello is acollaboration tool that organizes projects into boards eyset up Trello boards for each app then they sent out emailinvitations to invite each participant to join the corre-sponding board Each participant is brought to report anyremark or bug as ldquocardsrdquo in the ldquoissues backlogrdquo list It is alsointeresting to specify the severity of each issue using ldquolabelsrdquodecorators rdquocriticalrdquo ldquomajorrdquo ldquomediumrdquo and ldquolowrdquo ebugs reported by each participant are supported by the re-searchersrsquo team they are then moved to the ldquoIn progressrdquo listof the Trello boarde qualification of the bugs will point outwhich phase of the MDRE process will require an adjustmentto correct the bug Once the bug is corrected the card as-sociated with the bug is then moved to the ldquoDonerdquo list isprocess is repeated for each application until all the bugs areexhausted Each participant is asked to renew a new iterationto make sure that all these remarks are taken care of
In the data collection and analysis step the authorsanalyzed the reports produced by each participant At theend of the last iteration each participant is brought to fill inhis own Trello board the following metrics the executiontime (to report by the G-UI and the G-Spec groups) thepercentage of detected elements from persistence model(reserved for the G-Spec group) the percentage of detectedelements from business model (reserved for the G-Specgroup) the percentage of detected screen transitions (re-served for the G-Spec group) the percentage of mappediPhone SDK vs Android SDK (reserved for the G-Specgroup) the number of generated UI component per eachscreen (reserved for the G-UI group) and the effort forimplementing custom UI component (reserved for the G-UIgroup)
65 Experimental Results Table 10 reports the resultingvalues of all the metrics measured for the selected apps eresults are also represented as graphs (Figures 15ndash17) tomore appropriately analyze the FSA CFM and CMUImetrics
Based on the evaluation analysis of functional analystsiSpecSnapshot visibly identifies the entity model the busi-ness class model and the activity diagram Indeed for the 13apps the average of FSA is of 6982 which is quiteencouraging (Figure 15)
e authors observe that iSpecSnapshot has clearlymanaged to identify the persistence model (PM 100)for apps that use the xcdatamodel as a format to describe thepersistence model
Regarding the apps that have a BMlt 100 score (forexample APP7 47) this is due to the fact that the businessclasses are coded in other languages other than Objective-C(the beta version of the parsing engine recognizes just theObjective-C language)
As for the apps that have a score AMlt 100 (for ex-ample APP4 42) this is justified by the fact that the flow of
navigations between screens is partly programmed in theview controllers (the beta version of iSpecSnapshot is limitedto connections of navigations defined in the storyboard)
Regarding CFM of the coverage of mapped frame-works from iOS to Android the knowledge base KB ofiSpecSnapshot shows an acceptable average of 63 for theconsidered apps in this evaluation (Figure 16) Indeed mostof the studied apps use frameworks from the iPhone SDKthat are not yet supported in the KB in addition there aremany apps (Appi i isin 1 4 5 6 7 12 ) that use third librariesor specific pods
For apps that are categorized under ldquoUI complexrdquo cate-gory the estimated effort to implement specific UI compo-nents (components that are not part of the UIKit framework)typically represents a ratio between 20 and 30 of theestimated total charge for implementing Android UI partfrom scratch (Figure 17) However the execution time dis-played by iSpecSnapshot in order to automatically generateUIKit components does not exceed few minutes on average117 sec for the current case study (Table 10) According totheir observation the authors can readjust the CMUI metricby neglecting the effort of the automatic generation of UIKitcomponents Additionally the participants drew the authorsrsquoattention that they should take into account in respect to theCMUI formula the integration effort that the developer canspend when integrating the generated UI part and theremaining customized UI part With regard to the currentcase studies the authors have estimated the average effort ofthe UI integration by 14 (man-day)
CMUI 100 times 1 minusEffCustomUI +(14)
EstimEffAndroidUIMan1113888 1113889 (6)
us the gain in development effort of theUIAndroid partusing iSpecsnapshot exceeds the threshold of 77 (Figure 18)
66 Study Conclusion According to these experimentalresults the authors could answer the main research questionof their study concluding that iSpecSnapshot can greatlyhelp Android developers in their tasks of porting iOS ap-plications On one hand the tool draws up a report that givesvisibility on the use of iOS frameworks and their Androidmapping On the other hand the tool fills the lack offunctional documentation by bringing a functional un-derstanding of the iOS application in terms of persistenceand business models In addition it allows tracing the flow ofnavigation between screens and describing in detail thecomponents of each screen Finally it speeds up the de-velopment time and bootstrap the porting project whilesparing the Android developer of the effort to implement theAndroid UI part from scratch
67ltreats toValidity In this section the authors discuss thevalidity threats in conducting this experimental study [39]
671 Internal Validity e evaluation of the accuracy of theFSD document for the 13 apps by the group of 3 functionalanalysts may present a possible threat to the internal validity
Mobile Information Systems 23
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
To avoid this threat the authors have selected 3 candidatesbased on their skills regarding the iOS platform in order tobe able to compare the generated results to the source code
of the iOS app e authors also have conducted a doublecheck with the group of Android developers who are a priorithe owners of iOS apps
Accuracy of PMAccuracy of BM
Accuracy of AMAccuracy of functional spec FSA
Accuracy of the functional spec
1 2 3 4 5 6 7 8 9 10 11 12 13
7567
5500
8567
4667
6800 6533 66675567
8967
7367 76006667
8300
120
100
80
60
40
20
0
Figure 15 Functional spec accuracy reported by the participants
0APP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
10
20
30
40
5059
71
63
5348
58
Framework mapping coverage
54
7883
6467
49
81
60
70
80
90
Figure 16 Framework mapping coverage performed by iSpecSnapshot
Table 10 Average metric values of the selected apps performed by iSpecSnapshot
iOS appID
PM
BM
AM
FSA
CFM
CUI
Eff auto gen UI(sec)
Eff custom UI (man-day)
Estim Eff Android UI Man(man-day)
CMUI
APP1 100 65 62 7567 59 68 96 158 6 6954APP2 73 92 5500 71 94 209 065 12 9250APP3 100 90 67 8567 63 60 87 178 9 7725APP4 98 42 4667 53 41 175 534 15 6274APP5 100 53 51 6800 48 435 223 652 20 6614APP6 100 84 65 8300 58 65 190 343 22 8328APP7 100 47 49 6533 54 44 79 227 11 7708APP8 100 100 6667 78 89 32 018 3 8560APP9 67 100 5567 83 93 128 046 5 8578APP10 100 100 69 8967 64 58 71 140 4 5870App11 100 51 70 7367 67 56 52 117 5 7166App12 100 74 54 7600 49 52 102 280 21 8547App13 100 100 6667 81 92 69 028 4 8676Avg 6982 6369 6581 11638 7712
24 Mobile Information Systems
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
672 External Validity In this study a possible threat tothe external validity could have been the selection of theobject apps e goal of the first step of the evaluationprocess is to mitigate this threat During this preliminaryanalysis the authors have selected a set of different ap-plications to cover the entire range of UIKit componentsey also have been interested in applications that deal withvarious functional domains (social medicine networkingetc) In order to extend the validity of their results othercase studies were considered during the public beta phase ofthe tool
7 Conclusion and Future Work
To meet the growing demands of mobile app porting newsoftware engineering techniques and reverse-engineeringtools adapted to the mobile platform remain essential inorder to help developers to better understand analyze andmaintain mobile applications
In this paper the authors have presented iSpecSnapshota model-driven reverse-engineering tool which aims togenerate automatically the functional specification docu-mentation of iOS mobile apps and bootstrap the
000APP1 APP2 APP3 APP4 APP5 APP6 APP7
iOS apps
Effor
t (m
an-d
ay)
APP8 APP9 APP10 App11 App13App12
500
1000
1500
2000
2500Effort for implementing Android UI part vs custom UI component
Effort for implementing custom UIcomponents (man-day)Estimated effort for implementingandroid UI part from scratch (man-day)
Figure 17 Effort for implementing Android UI part vs custom UI components
Wor
kloa
d pe
rcen
tage
()
iOS appsAPP1 APP2 APP3 APP4 APP5 APP6 APP7 APP8 APP9 APP10 App11 App12 App13
Cost margin for implementing Android UI using iSpecSnapshot100
90
80
70
60
50
40
30
20
10
0
Remain android UI workloadCost margin for implementing android UI
Figure 18 Cost margin for implementing Android UI using iSpecSnapshot
Mobile Information Systems 25
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
corresponding Android UI skeleton ey have underlinedtheir MDRE approach and outlined the key reverse-engi-neering steps model discovery semantic extraction modeltransformation and code generation Further they haveexposed the technical architecture of iSpecSnapshot as acloud service
In the meantime the authors have revised some pre-liminary works in mobile the reverse-engineering fielde findings of their evaluation conducted on iOS nativeapps have ensured that iSpecSnapshot is a useful solutionfor detecting key information for the iOS to Androidmobile app porting process eg framework dependenciesrate of SDK platforms mapping activity diagram businessmodel and screen components (UI elements events andactions)
71 Future Work ere are some research lines in whichthe proposed approach can be improved and extendede immediate task would be to improve the activitydiagram to support dynamic screen transitions iscould eventually be done by readjusting the semanticextraction step in order to detect the dynamic navigationthat is described towards the source code of event actionsis leads certainly to further enrichment of the semanticrepository based on the best practices of iOS mobiledevelopment
Other perspectives worthwhile pursuing would be toenhance the mapping coverage rate between mobile SDKframeworks In fact the authors are looking forward toexamine the possible mapping between iPhone SDK andthe plethora of Android open-sourced libraries atpoint they hope to be valuable for a full-porting process
Furthermore the prospect of being able to port from iOSto Android serves as a continuous incentive for other re-verse-engineering directions e authors are about toprototype a reverse-engineering POC (Proof Of Concept)from UI iOS to Flutter UI (Flutter UI httpsflutterio)ey intend to follow the same MDRE approach that ispresented in this paper in order to migrate the iOS UI toGooglersquos portable UI Toolkit which is known by their fastrendering and expressive UI
Appendix
A Model-Driven Engineering (MDE)
MDE [40] is a growing concept in software engineering Itaims to improve software development by raising the level ofabstraction in system specification and increase automationof implementation maintenance and testing [41 42] epromoted idea by MDE is to use models at different levels ofabstraction for developing systems e MDE approach iswidely used in the context of forward engineering [43]through appropriate model to code M2C tools specificallydesigned to convert model to code
e object management group (OMG) describes modelsas ldquoa description or specification of a system and its envi-ronment for a certain purposerdquo [44] e model is related tothe system by an explicit or implicit mapping It may rep-resent the software the hardware the environment or otherdomain-specific aspects of the system e OMGrsquos frame-work ie MDA (model-driven architecture) [45] distin-guishes different kinds of models (see Figure 19)
(i) Computation-independent model (CIM)(ii) Platform-independent model (PIM)(iii) Platform-specific model (PSM)(iv) Implementation-specific model (ISM)
A CIM is a view of a system from the computation-independent viewpoint that focuses on the environment andthe requirements for the system It does not show details ofthe structure of system or how the system is implemented Ingeneral it is called domain model and it is assumed that theprimary user of the CIM is the domain practitioner orbusiness expert e CIM helps to bridge the gap betweendomain experts (or business experts) and IT experts [46]
A PIM is a view of a system from the platform-in-dependent viewpoint It presents a specified degree ofplatform independence so as to be conforming for use with anumber of different platforms of similar type e PIM isdefined as a set of components and functionalities which aredefined independently of any specific platforms and can berealized in platform-specific models [46]
1 Computation independent modelCreated by business analyst to describebusiness viewpoint
Created by developer or tester toimplement system
3 Platform specific model
Created by architectdesigner to describesystem architecture
2 Platform independent model
CIM PIM PSM CODE
CIM gtgt PIMTransformation
PIM gtgt PSMTransformation
PSM gtgt CODETransformation
Figure 19 Key models of the MDA paradigm CIM PIM and PSM
26 Mobile Information Systems
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
A PSM is a view of a system from the platform-specificviewpoint It combines the specifications in the PIMwith thedetails that specify how the system uses a particular type ofplatform e PSM includes specific elements representingthe target platform [46]
An ISM is a model which all details of implementation ofthe target system are specified [47]
Metamodel defines the abstract syntax of a modelinglanguage and as such is a special kind of model It can bedescribed as the specification of the set of all possible modelsexpressed in that modeling language MDA is based on theuse of a language to write metamodels called the meta objectfacility (MOF) [48] MOF guarantees that the models can bestored in a MOF-compliant repository parsed transformedrendered into different formats including XMI (XMLMetadata Interchange) transported across a network andused to generate application code
Model transformation is a very important task in anymodel-driven approach Indeed the transformations ensurethe operations of translating of one or more models from agiven level of abstraction to one or more other models of thesame level (horizontal transformation PSM to PSM) or of adifferent level (vertical transformation PIM to PSM) eOMG has standardized QVT (query view and trans-formation) as transformation language specifications(queryviewtransformation or QVT [34] and MOF2Text[49]) e QVT standard defines three languages fortransformations operational relational and core languagese relational language is the most relevant [50]
B Model-Driven Reverse Engineering (MDRE)
As noted by Chikofsky and Cross [51] the term ldquoreverseengineeringrdquo is generally understood to mean ldquoreverse en-gineering is the process of analyzing a subject system toidentify the systems components and their interrelationshipsand create representations of the system in another form orat a higher level of abstractionrdquo
In software engineering the use of reverse-engineeringparadigm has been considered in order to extract a widerange of models from existing systems eses models helpto analyze and comprehend the system
In literature model-driven reverse engineering (MDRE)[52] has come to be used to refer to model-driven engi-neering (MDE) approaches and techniques which are ap-plicable to the reverse-engineering challenge
A recent review of this topic in the literature [53] showsthat MDRE has reached a peak in publication within the lastfew years is is mostly due to the OMGrsquos effort to providethe ADM (architecture-driven modernization) task force[54] with the purpose of standardizing metamodels forreverse-engineering legacy systems
ADM has set up many key standards [55] in order tosupport all tasks that are subject to ADM-based processSubsequent standards [56] will treat many aspects such asanalysis visualization refactoring and transformation-re-lated standards
(i) KDM (knowledge discovery metamodel) defines ametamodel that describes a high-level view of theapplication behavior structure and data
(ii) ASTM (abstract syntax tree metamodel) defines ametamodel that represents the procedural level ofthe application ASTM is built upon KDM to ensurelanguage metadata exchange Moreover it allowsanalysis tools to deal with metamodel instead of thespecific language AST
(iii) SMM (structured metrics metamodel) defines ametamodel that provides metrics from the KDMthat can describe technical functional and archi-tectural issues
Data Availability
e data used to support the findings of this study are in-cluded within the article
Conflicts of Interest
e authors declare that they have no conflicts of interest
Acknowledgments
is research was partially supported by MyAppConverterLtd Warm thanks are due to some employees at MyApp-Converter LTD who generously shared with the authorstheir ideas and their enlightenment which had greatlycontributed to the originality of this paper
References
[1] Worldwide Mobile Apps Download September 2018 httpswwwstatistacomstatistics271644worldwidefreeandpaidmobileappstoredownloads
[2] Number of available apps in the apple app store from July2008 to January 2017 September 2018 httpswwwstatistacomstatistics263795numberofavailableappsintheappleappstore
[3] Number of available applications in the google play store fromDecember 2009 to December 2017 September 2018 httpswwwstatistacomstatistics266210numberofavailableapplicationsinthegoogleplaystore
[4] Mobile hit new milestones in q1 2019 June 2019 httpswwwappanniecomeninsightsmarketdatamobilehitnewmilestonesinq12019
[5] D Fortunato and J Bernardino ldquoProgressive web apps analternative to the native mobile appsrdquo in Proceedings of the2018 13th Iberian Conference on Information Systems andTechnologies (CISTI) pp 1ndash6 Caceres Spain June 2018
[6] J H Park Y B Park and H K Ham ldquoFragmentationproblem in androidrdquo in Proceedings of the InternationalConference on Information Science and Applications (ICISA)pp 1-2 Suwon South Korea June 2013
[7] T Roehm R Tiarks R Koschke and W Maalej ldquoHow doprofessional developers comprehend softwarerdquo in Pro-ceedings of the 34th International Conference on SoftwareEngineering (ICSE) pp 255ndash265 IEEE Computer SocietyZurich Switzerland June 2012
Mobile Information Systems 27
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
[8] H Muccini A D Francesco and P Esposito ldquoSoftwar-etesting of mobile applications challenges and future researchdirectionsrdquo in Proceedings of the 7th International Workshopon Automation of Software Test (AST) pp 29ndash53 IEEEComputer Society Zurich Switzerland June 2012
[9] J Dehlinger and J Dixon ldquoMobile application software en-gineering challenges and research directionsrdquo in Proceedingsof the Workshop on Mobile Software Engineering pp 29ndash32Springer Santa Monica LA USA 2011
[10] A I Wasserman ldquoSoftware engineering issues for mobileapplication developmentrdquo in Proceedings of the FSESDPWorkshop on Future of Software Engineering Research(FoSER10) pp 397ndash400 ACM Santa Fe NM USANovember 2010
[11] M Janicki M Katara and T Paakkonen ldquoObstacles andopportunities in deploying model-based GUI testing ofmobile software a surveyrdquo Software Testing Verification andReliability vol 22 no 5 pp 313ndash341 2012
[12] D Franke and C Weise ldquoProviding a software qualityframework for testing of mobile applicationsrdquo in Proceedingsof the International Conference on Software Testing Verifi-cation and Validation (ICST) pp 431ndash434 IEEE ComputerSociety Berlin Germany March 2011
[13] S P Miller A C Tribble M W Whalen andM P E Heimdahl ldquoProving the shallsrdquo International Journalon Software Tools for Technology Transfer vol 8 no 4-5pp 303ndash319 2006
[14] P Tilakaratna and J Rajapakse ldquoForward engineering theobject oriented analysis and designrdquo in Proceedings of theMalaysian Conference in Software Engineering pp 107ndash112IEEE Johor Bahru Malaysia December 2011
[15] D Franke C Elsemann S Kowalewski and C WeiseldquoReverse engineering of mobile application lifecyclesrdquo inProceedings of the 2011 18th Working Conference on ReverseEngineering pp 283ndash292 Limerick Ireland November 2011
[16] M E Joorabchi and A Mesbah ldquoReverse engineering iOSmobile applicationsrdquo in Proceedings of the 2012 19th WorkingConference on Reverse Engineering pp 177ndash186 KingstonCanada October 2012
[17] W Yang M R Prasad and T Xie ldquoA grey-box approach forautomated GUI-model generation of mobile applicationsrdquo inFundamental Approaches to Software EngineeringV Cortellessa and D Varro Eds pp 250ndash265 SpringerBerlin Heidelberg 2013
[18] S Salva and S Zafimiharisoa ldquoModel reverse-engineering ofmobile applications with exploration strategiesrdquo in Pro-ceedings of the ICSEA 2014 the Ninth International Conferenceon Software Engineering Advances pp 396ndash403 Nice FranceOctober 2014
[19] I C Morgado A Paiva and J Faria ldquoAutomated pattern-based testing of mobile applicationsrdquo in Proceedings of the2014 9th International Conference on the Quality of In-formation and Communications Technology pp 294ndash299Guimaratildees Portugal April 2014
[20] T A Nguyen and C Csallner ldquoReverse engineering mobileapplication user interfaces with remauirdquo in Proceedings of the2015 30th IEEEACM International Conference on AutomatedSoftware Engineering (ASE) pp 248ndash259 Lincoln NE USANovember 2015
[21] K Lamhaddab and K Elbaamrani ldquoModel driven reverseengineering graph modeling for mobiles platformsrdquo inProceedings of the 2015 15th International Conference onIntelligent Systems Design and Applications (ISDA) pp 392ndash397 Marrakech Morocco December 2015
[22] D Amalfitano A R Fasolino P Tramontana B D Ta andA M Memon ldquoMobiGUITAR automated model-basedtesting of mobile appsrdquo IEEE Software vol 32 no 5pp 53ndash59 2015
[23] P Dugerdil and R Sako ldquoDynamic analysis techniques toreverse engineer mobile applicationsrdquo in Software Technol-ogies P Lorenz J Cardoso L A Maciaszek andM van Sinderen Eds pp 250ndash268 Springer InternationalPublishing Cham Switzerland 2016
[24] I A Salihu R Ibrahim and AMustapha ldquoA hybrid approachfor reverse engineering GUI model from android apps forautomated testingrdquo Journal of Telecommunication Electronicand Computer Engineering vol 9 no 3 pp 45ndash49 2017
[25] I C Morgado and A C R Paiva ldquoMobile GUI testingrdquoSoftware Quality Journal vol 26 no 4 pp 1553ndash1570 2018
[26] C Chen T Su G Meng Z Xing and Y Liu ldquoFromUI designimage to GUI skeleton a neural machine translator tobootstrap mobile GUI implementationrdquo in Proceedings of the40th International Conference on Software EngineeringICSErsquo18 pp 665ndash676 ACM New York NY USA May-June2018
[27] H Salehinejad J Baarbe S Sankar J Barfett E Colak andS Valaee ldquoRecent advances in recurrent neural networksrdquo2017 httparxivorgabs180101078
[28] T Beltramelli ldquopix2code generating code from a graphicaluser interface screenshotrdquo in Proceedings of the ACM SIGCHISymposium on Engineering Interactive Computing Systems-EICSrsquo18 pp 31ndash36 ACM New York NY USA June 2018
[29] B Dai S Fidler R Urtasun and D Lin ldquoTowards diverse andnatural image descriptions via a conditional ganrdquo in Pro-ceedings of the 2017 IEEE International Conference on Com-puter Vision (ICCV) pp 2989ndash2998 Venice Italy October2017
[30] D Amalfitano V Riccio N Amatucci V D Simone andA R Fasolino ldquoCombining automated GUI exploration ofandroid apps with capture and replay through machinelearningrdquo Information and Software Technology vol 105pp 95ndash116 2019
[31] B Cornelissen A Zaidman A van Deursen L Moonen andR Koschke ldquoA systematic survey of program comprehensionthrough dynamic analysisrdquo IEEE Transactions on SoftwareEngineering vol 35 no 5 pp 684ndash702 2009
[32] I C Morgado ldquoAutomated pattern-based testing of mobileapplicationsrdquo Tech Rep Faculdade Engenharia UniversidadePorto November 2018 httppaginasfeuppt7epro11016filesPhDesisProposalpdf
[33] F Fleurey E Breton B Baudry A Nicolas andJ-M Jezequel ldquoModel-driven engineering for software mi-gration in a large industrial contextrdquo in Model Driven En-gineering Languages and Systems (Lecture Notes in ComputerScience) G Engels B Opdyke D Schmidt and E F WeilEds vol 4735 Springer Berlin Germany 2007
[34] I Kurtev ldquoState of the art of QVT a model transformationlanguage standardrdquo in Applications of Graph Transformationswith Industrial Relevance A Schurr M Nagl and A ZundorfEds pp 377ndash393 Springer Berlin Germany 2008
[35] F Jouault F Allilaire J Bezivin and I Kurtev ldquoATL a modeltransformation toolrdquo Science of Computer Programmingvol 72 no 1-2 pp 31ndash39 2008
[36] E Umuhoza H Ed-douibi M Brambilla J Cabot andA Bongio ldquoAutomatic code generation for cross-platformmulti-device mobile apps some reflections from an industrialexperiencerdquo in Proceedings of the 3rd International Workshop
28 Mobile Information Systems
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
on Mobile Development Lifecycle-MobileDeLi 2015 pp 37ndash44ACM New York NY USA October 2015
[37] OMG ldquoOMG MOF model to text transformation languagerdquoSeptember 2018 httpswwwomgorgspecMOFM2T10
[38] H Bruneliee J Cabot G Dupe and F Madiot ldquoMoDisco amodel driven reverse engineering frameworkrdquo Informationand Software Technology vol 56 no 8 pp 1012ndash1032 2014
[39] C Wohlin P Runeson M Hst M C Ohlsson B Regnelland A Wessln Experimentation in Software EngineeringSpringer Publishing Company New York NY USA 2012
[40] S Kent ldquoModel driven engineeringrdquo in Integrated FormalMethods M Butler L Petre and K Sere Eds pp 286ndash298Springer Berlin Germany 2002
[41] A van Deursen E Visser and J Warmer ldquoModel-drivensoftware evolution a research agendardquo in Proceedings of theCSMR Workshop Model-Driven Softw Evol (MoDSE)pp 41ndash49 Amsterdam Netherlands March 2007
[42] P Mohagheghi W Gilani A Stefanescu M A FernandezB Nordmoen and M Fritzsche ldquoWhere does model-drivenengineering help experiences from three industrial casesrdquoSoftware and Systems Modeling vol 12 no 3 pp 619ndash6392013
[43] F Jouault J Bezivin and M Barbero ldquoTowards an advancedmodel-driven engineering toolboxrdquo Innovations in Systemsand Software Engineering vol 5 no 1 pp 5ndash12 2009
[44] OMG ldquoMDA Guide Revision 20rdquo September 2009 httpwwwomgorgcgi-bindocormsc140601
[45] A Elsawi S Sahibuddin and R Ibrahim ldquoModel drivenarchitecture a review of current literaturerdquo Journal of lteo-retical and Applied Information Technology vol 79 pp 122ndash127 2015
[46] L Favre ldquoMDA-based reverse engineeringrdquo in Reverse En-gineering A C Telea Ed IntechOpen Rijeka Croatia 2012
[47] A BrownModel Driven Architecture Principles and Practicevol 3 Springer-Verlag Verlag Germany 2004
[48] OMG ldquoMOF Meta Object Facility (Mof Tm) 20 OMGspecification formal161101rdquo September 2018 httpwwwomgorgmof
[49] J Oldevik T Neple R Groslashnmo J Aagedal and A-J BerreldquoToward standardised model to text transformationsrdquo inModel Driven ArchitecturemdashFoundations and ApplicationsA Hartman and D Kreische Eds pp 239ndash253 SpringerBerlin Germany 2005
[50] P Stevens ldquoBidirectional model transformations in QVTsemantic issues and open questionsrdquo Software and SystemsModeling vol 9 no 1 pp 7ndash20 2008
[51] E J Chikofsky and J H Cross ldquoReverse engineering anddesign recovery a taxonomyrdquo IEEE Software vol 7 no 1pp 13ndash17 1990
[52] S Rugaber and K Stirewalt ldquoModel-driven reverse engi-neeringrdquo IEEE Software vol 21 no 4 pp 45ndash53 2004
[53] C Raibulet F Arcelli Fontana andM Zanoni ldquoModel-drivenreverse engineering approaches a systematic literature re-viewrdquo IEEE Access vol 5 pp 14516ndash14542 2017
[54] P Newcomb ldquoArchitecture-driven modernization (ADM)rdquoin Proceedings of the 12th Working Conference on ReverseEngineering (WCRErsquo05) p 237 Pittsburgh PA USA No-vember 2005
[55] R Perez-Castillo I G-R de Guzman and M PiattinildquoKnowledge discovery metamodel-ISOIEC 19506 a standardto modernize legacy systemsrdquo Computer Standards and In-terfaces vol 33 no 6 pp 519ndash532 2011
[56] OMG ldquoArchitecture-driven modernization standards road-maprdquo September 2009 httpadmomgorgADMTF20Roadmappdf
Mobile Information Systems 29
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom
Computer Games Technology
International Journal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom
Journal ofEngineeringVolume 2018
Advances in
FuzzySystems
Hindawiwwwhindawicom
Volume 2018
International Journal of
ReconfigurableComputing
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
thinspArtificial Intelligence
Hindawiwwwhindawicom Volumethinsp2018
Hindawiwwwhindawicom Volume 2018
Civil EngineeringAdvances in
Hindawiwwwhindawicom Volume 2018
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawiwwwhindawicom Volume 2018
Hindawi
wwwhindawicom Volume 2018
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Engineering Mathematics
International Journal of
RoboticsJournal of
Hindawiwwwhindawicom Volume 2018
Hindawiwwwhindawicom Volume 2018
Computational Intelligence and Neuroscience
Hindawiwwwhindawicom Volume 2018
Mathematical Problems in Engineering
Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018
Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom
The Scientific World Journal
Volume 2018
Hindawiwwwhindawicom Volume 2018
Human-ComputerInteraction
Advances in
Hindawiwwwhindawicom Volume 2018
Scientic Programming
Submit your manuscripts atwwwhindawicom