ResearchArticle Porting Mobile Apps from iOS to Android: A...

30
Research Article Porting Mobile Apps from iOS to Android: A Practical Experience Khalid Lamhaddab , 1,2 Mohamed Lachgar , 3 and Khalid Elbaamrani 1 1 TIM Laboratory, ENSA, Cadi Ayyad University Marrakesh, Marrakesh, Morocco 2 MDA Expert, MyAppConverter Ltd., London, UK 3 LTI Laboratory, ENSA, University of Chouaib Doukkali El Jadida, El Jadida, Morocco Correspondence should be addressed to Khalid Lamhaddab; [email protected] Received 19 April 2019; Revised 19 June 2019; Accepted 22 July 2019; Published 3 September 2019 Academic Editor: Ramon Aguero Copyright © 2019 Khalid Lamhaddab et al. is is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly 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 remain essential in order to help developers to better understand, analyze, and bootstrap porting mobile applications. In this paper, the authors propose a model-driven reverse-engineering approach based on static analysis, which describes a semantic metamodel of the iOS mobile application and extract design information (such as user interfaces, activity diagram, entities, framework and library dependencies) in order to generate the functional specification documentation and the Android UI skeleton. us, aiding the project team, who has in charge porting the app to another mobile platform, to agree upon a consensus on what has to be implemented and safe development cost by auto generating the Android UI skeleton project. To experiment this approach, the authors 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 worldwide is leading to an impressive growth in number of app downloads and also in terms of incomes generated by these apps. According to a recent statistical study [1], by 2021, over 353 billion of mobile apps will have been downloaded worldwide [1]. At present, there are over 2.2 million apps on the Apple store [2], and more than 3 million Android apps are on Google Play Store [3]. e key challenge that enterprise organizations face when starting their native mobile app development projects is that what platform should they start with: iOS or Android? In fact, both the two platforms have their fair share of pros and cons. e authors outline the key aspects, which can help to get a clear idea to decide which platform is suited to enterprise requirements. e choice comes down to 4 factors: (i) Audience: Android is fast-growing and enjoying 75.27% of the share of whole mobile OS market compared to iOS, which ranks second at 22.74%. AppAnnie [4] reports that, for the first quarter of 2019, the Google Play Store pulled 22 billion apps worldwide. Comparatively, the App Store only drove 8 billion. (ii) Monetization: While Android rakes in more downloads, iOS maintains a nearly 2x lead when it comes to gross consumer spend [4]. Accordingly, iOS customer segment comprises well-off users who are willing to pay extra for sustainable apps and services with advanced design, security and capa- bilities. e apple iOS monetization is built on a subscription model or in-app purchases. However, Android apps rely on an ad-based model. (iii) Project timeline: Developing Android apps gener- ally takes more time due to device fragmentation and the complexity involved in Android app de- velopment. On an average, Android app develop- ment is 30–40 percent slower than iOS. Although iOS apps are quicker to design, Apple has a strict Hindawi Mobile Information Systems Volume 2019, Article ID 4324871, 29 pages https://doi.org/10.1155/2019/4324871

Transcript of ResearchArticle Porting Mobile Apps from iOS to Android: A...

Page 1: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 2: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 3: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 4: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 5: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 6: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 7: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 8: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 9: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 10: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 11: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 12: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 13: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 14: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 15: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

(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

Page 16: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

(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

Page 17: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 18: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 19: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 20: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 21: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 22: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 23: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 24: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 25: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 26: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 27: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 28: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

[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

Page 29: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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

Page 30: ResearchArticle Porting Mobile Apps from iOS to Android: A ...downloads.hindawi.com/journals/misy/2019/4324871.pdf · gressive web app (PWA) strategy [5]. is path is more effective

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