移动信息系统

PDF
移动信息系统/2019年/文章

研究文章|开放获取

体积 2019年 |文章的ID 4324871 | https://doi.org/10.1155/2019/4324871

哈立德Lamhaddab Mohamed Lachgar,哈立德Elbaamrani, 将从iOS移动应用程序移植到Android:实践经验”,移动信息系统, 卷。2019年, 文章的ID4324871, 29日 页面, 2019年 https://doi.org/10.1155/2019/4324871

将从iOS移动应用程序移植到Android:实践经验

学术编辑器:雷蒙阿奎罗
收到了 2019年4月19日
修改后的 2019年6月19日
接受 2019年7月22日
发表 2019年9月3日

文摘

最近兴起的智能手机在移动开发引发了一场革命。由于这个增量移动创新,新的软件工程技术,软件文档和工具适应移动平台保持基本以帮助开发人员更好地理解、分析和引导移植移动应用程序。在本文中,作者提出一种基于静态分析模型驱动逆向工程方法,它描述了一个iOS移动应用程序的语义元模型和提取设计信息(如用户界面、活动图、实体框架和库依赖关系)来生成功能规范文档和Android UI框架。因此,协助项目团队,负责将应用程序移植到另一个移动平台,达成一致共识已实现和安全开发成本通过自动生成Android UI框架项目。尝试这种方法,作者实现了一个工具叫iSpecSnapshot。此外,他们通过一个实验评估iSpecSnapshot的性能包括iOS应用程序移植到Android平台。

1。介绍

全球智能手机用户数量的增长导致了一个令人印象深刻的增长数量的应用程序下载的收入也由这些应用程序生成的。根据最近的一项统计研究(1),到2021年,全世界超过3530亿的移动应用程序被下载(1]。

目前,在苹果商店有超过220万个应用程序(2,全球超过300万的Android应用程序是在谷歌玩商店(3]。

企业组织所面临的关键挑战当开始他们的本地移动应用程序开发项目是什么平台应该他们开始:iOS和Android吗?

事实上,两个平台都有自己的优点和缺点。作者大纲的关键因素,它可以帮助得到一个清晰的想法来决定哪些平台适合企业需求。选择可以归结为4个因素:(我)观众:Android是快速发展的,享受75.27%的整体移动操作系统市场的份额和iOS相比,排名第二,得票率为22.74%。AppAnnie [4)报道,2019年第一季度,谷歌玩商店把全球220亿个应用程序。相比之下,只有驱车80亿App Store。(2)货币化:Android耙在下载时,iOS保持近2 x领先时总消费支出(4]。因此,iOS客户部门包括富裕的用户愿意支付额外的可持续应用和服务与先进的设计、安全与功能。苹果的iOS货币化是建立在订阅模式或应用程序内购买。然而,Android应用程序依赖于一个基于广告模型。(3)项目时间表:开发Android应用程序通常要花更多的时间,由于设备的平台和Android应用程序开发的过程比较复杂。平均来说,安卓应用开发是30 - 40百分比低于iOS。尽管iOS应用程序更快的设计,苹果有严格的审批流程控制软件质量和符合一定的标准。相比之下,谷歌玩商店出版过程意味着更少的严格的指导方针,发布一个应用程序。一般来说,一个应用程序审查过程需要一到两天几个小时内获得批准和发布。(iv)成本预算:开发一个移动应用可以归结为一系列的因素。项目的范围和复杂性是最重要的成本因素。还有其他方面,招致成本如:设备和操作系统版本支持,后端基础设施和服务的集成,营销努力,团队和跨部门的参与和维护/升级。

许多初创企业需要建立一个最小可行产品迅速而廉价地倾向于从iOS平台。与此同时,对于创业公司来说,想要征服市场份额和需要迅速,规模将一个iOS应用程序移植到Android是一项关键战略。与多种Android用户观众,当然更多的盈利和投资机会。或者,其他企业更倾向于建立自己的手机应用程序使用先进的web应用程序(PWA)策略5]。这条路更有效时,代码的可重用性,可维护性,成本效率,和观众达到通过URL(访问)。最近,进步的web应用程序可以利用一些功能类似于本地应用,如发送推送通知,使用触摸手势,访问手机的加速度计,并使用振动。然而,PWA的主要缺点是性能和应用程序的行为。PWA总是落后于本土,因为本地api需要开发。换句话说,PWA可能不是最好的选择,开发人员如果他们寻找高性能或应用程序使用3 d图形。

iOS应用程序移植到Android是指将根据目标平台或重写应用程序代码,以使它能够运行在不同的Android移动设备和处理著名的担忧(Android版本6]。移植或逆向工程应用已被证明是一个冗长而复杂的任务,随着开发人员应该在源和目标移动平台技术技能。实际上,开发人员必须交易不仅适应平台SDK和编写特定代码,还要分析和理解背后的功能逻辑一个移动应用程序。

在一项由Roehm等人在7],一些开发人员作为最终用户,与用户界面交互测试应用程序的行为为了找到一个入口点的用户体验(UX)模型。其他人认为源代码更可靠的文档;这是由于丢失或outdatedness的文档。

一般来说,大多数移动专家认为,手机应用程序移植的过程中应采取以下步骤:(我)理解功能行为(2)分析UI / UX(用户界面/用户体验)(3)技术评估(iv)代码转换(v)测试和质量保险产生的源代码(vi)迭代发布

以满足日益增长的需求,移动应用程序移植,专用的软件工程技术和逆向工程工具(见[8- - - - - -10])适应移动平台保持基本以帮助开发人员更好地理解、分析和维护移动应用程序(11,12]。

逆向工程有许多有价值的好处。最主要的优势如下:(我)理解源代码(2)发展和维护软件(3)重新编制软件(iv)与遗留系统集成(v)最近的遗留系统迁移到新技术(vi)质量评估

本文的主要贡献包括提出模型驱动逆向工程(MDRE)方法,考虑UI部分(故事板工作流(Xcode故事板:https://developer.apple.com/xcode/interface-builder/))和本地iOS移动应用程序的源代码,自动提取特定的模型。这些模型包含UI / UX行为和技术评估,需要生成的功能规范文档iOS应用程序和相应的Android UI框架。这是很重要的,帮助设计师分析系统,可以用来验证系统需求和加快发展以合理的成本(13]。

拟议的贡献如下所示:(我)一种逆向工程技术,自动提取语义移动应用模型,根据预定义的移动元模型。这个元模型包括更多关于手机应用程序的详细信息,如屏幕、控制器、小部件,导航,事件和行动。(2)深入报道通过源代码分析,构建一个框架依赖关系树。在案例研究中,作者感兴趣的iPhone SDK框架(iOS SDK框架:https://developer.apple.com/documentation/)。(3)iSpecSnapshot,这是一个工具,分析了iOS移动应用的语义模型,然后将它转变成具体的目标模型。推断模型转化为功能规范文档和Android UI框架,在正向工程技术(14]。生成的构件将帮助开发者移植任务理解源应用程序和引导移植过程。

本文的组织结构如下:部分2报告最相关的移动逆向工程方法并根据不同的标准进行对比。部分3介绍了我们研究的实证研究设计。部分4描述了提出了逆向工程iOS应用Android MDRE方法。部分5描述iSpecSnapshot从技术观点。部分6通过一个案例研究讨论了一个评估工具进行现实的第三方iOS应用程序。最后,讨论取得的贡献在这个研究和一些可能的挑战和未来工作角度提出了部分7

文献综述提出了基于临界深度调查发表在过去七年的作品关于手机逆向工程方法。

在[15),因特网等人研究如何逆向工程移动应用程序生命周期的测试。方法是由开发人员的代码,包括四个步骤:(1)全面实施的生命周期方法(暂停、启动和破坏)。(2)日志注:印刷一些测试日志在生命周期方法。(3)Transition-trigger检测:确定一个目录的触发器和跟踪应用程序的行为。(4)应用程序生命周期重建:基于日志数据,开发人员可以重建一个移动应用程序状态模型。方法的主要缺点是,他们迫使开发商硬编码日志为了实现这一任务。因此,没有自动化等实现一个插件,它可以执行源代码的分析和检测可能的生命周期方法和潜在的事件行为。

在[16),Joorabchi和Mesbah提出一种逆向工程技术动态分析的基础上,以生成一个运行iOS应用程序的状态模型。这种方法旨在捕捉用户界面状态和它们之间的转换。作者也迎合了他们的技术,称为ICRAWLER的工具。这种方法,然而,未能正确地描述所有UI部分特征(图形信息,UI类,事件类型,等等)。

这项研究由杨et al。17)地址自动GUI-model生成移动应用程序的问题。他们引入一个灰色矩形方法自动提取模型,给定的移动应用程序。旨在提取的方法,使用静态分析,所有支持的事件的应用程序的GUI组件。然后,它使用一个动态爬行过程逆向工程模型的应用程序中,由应用于提取的飞行事件上运行的应用程序。作者开发了一个Android平台的工具称为轨道,这是由一个动作探测器模块基于WALA(分析WALA T.J.沃森库:https://github.com/wala/WALA),以及一个动态的履带Robotium之上(Robotium:https://github.com/RobotiumTech/robotium)。

在[18],萨尔瓦•和Zafimiharisoa提出一个正式的模型推理方法移动应用的自动测试。方法旨在商店遇到接口的细节丰富,有助于减少应用探索,利用蚁群优化算法的策略。该方法更适合执行STS模式(符号转换系统)和测试用例生成。

在[19),Morgado等人提出一个方法用于测试移动应用程序使用逆向工程和行为模式。他们工作的目的包括定义一个目录使用混合逆向工程工具移动GUI行为模式和基于杨等人的方法(17]。工具有助于探索移动应用程序,自动识别模式和应用预定义的测试。

在[20.),阮和Csallner引入了一种叫做REMAUI推断移动应用程序用户界面代码从截图或概念图纸。因此,从一个给定的输入位图,REMAUI标识用户界面元素,如图像、文本、容器和列表通过计算机视觉和光学字符识别(OCR)技术。REMAUI合并OCR和计算机视觉的结果和在合并后的数据识别常见的结构,如列表或图像。REMAUI然后承认对齐的文本块,组织成一个布局容器,和出口识别文本片段作为一个Android资源文件。这种技术的主要弱点是不适合识别复杂的复合组件如菜单/菜单项,日历,分段控制,甚至广播组。的核心技术可能是更有趣的是,作者利用了身边的范式在OCR识别阶段。因此,它将允许生产丰富的PSM(特定于平台的模型)模型,更完整地描述概念图纸。

Lamhaddab和Elbaamrani [21)研究如何使用基于逆向工程建模的移动应用程序。作者用一个手机应用程序源代码的静态分析,为了产生一个代表图模型的源程序。可以转换生成的图模型,通过语义规则,根据目标移动到另一个图模型的元模型。源和目标图模型存储在一个图形数据库。这项研究得出结论,基于建模提供灵活性等优势对图的节点之间的关系,数据整合,缓解内部导航图的模型由于特定的查询语言。

要克服的挑战如何避免无状态事件流图(EFG)的移动应用程序GUI, Amalfitano等人在22]目前Android应用程序称为MobiGUITAR gui驱动的测试框架。框架是基于三个步骤:(1)逆向工程从正在运行的应用程序的状态机模型和创建抽象的机器,(2)生成测试用例,和(3)重放的测试用例。根据这项研究,MobiGUITAR产生几个测试构件(如事故报告,有限状态机FSM模型中,GUI序列,和JUnit测试用例)。

在另一项研究通过Dugerdil和Sako (23),作者提出了逆向工程过程恢复移动应用的功能结构。的方法包括三个步骤:(1)使用代码插装在源代码中插入额外的语句,这有助于记录事件,(2)记录的执行跟踪平面文件格式,和(3)执行离线分析的执行跟踪检索手机应用程序的用例使用很多的观点。

另一个贡献Salihu et al。24)提出了一种混合动力技术,逆向工程从Android应用程序的GUI模型。研究人员已经开发出一种工具,称为AMOGA结合静态和动态分析。移动应用程序二进制文件的执行静态分析工具来自动提取GUI信息。然后,它指示一个动态爬行探索和逆向工程模型的移动应用程序。

Morgado和Paiva25)开发了一个工具叫影响支持移动应用的自动测试基于重复行为的UI模式的存在。本研究中使用的方法是完全自动化的,它是基于两个步骤:首先,爬行应用程序通过识别UI模式与它交互,然后通过应用测试策略。

现场研究的方法是采用陈et al。26]调查自动化视觉理解移动用户界面设计来生成一个移动GUI框架。通过他们的研究中,神经开发机器翻译,结合视觉卷积神经网络(CNN)和递归神经网络(RNN) [27编码器/解码器。翻译由提取视觉特征在UI设计,编码功能空间布局,并生成GUI骨架。与类似的焦点,另一个案例研究Beltramelli [28)有助于这一研究提出一种基于卷积的方法和递归神经网络结合特定的DSL,这有助于生成,从GUI屏幕截图,不同的平台(即相应的源代码。,iOS、Android和基于web的技术)。技术训练在一个相对较小的数据集和需要更多的改进识别矢量表示。作者认为生成对抗网络(GAN)年代(29日)可能与pix2code模型结合使用来改善结果。

最近测试技术,介绍了基于GUI的探索是Amalfitano et al。30.]。方法旨在利用人工参与自动化流程处理探索门gui的挑战,这需要锻炼与特定的输入事件序列。作者目前的颈,混合GUI开发工具,结合自动与捕获和回放GUI开发利用机器学习的方法。

以前的研究都是分类根据Cornelissen最初给出的本体et al。31日根据移动逆向工程背景)和精制Morgado et al。19]。所选方法进行分类的主要方面包括:(我)目标:学习方法的主要目的(程序理解,复苏模式,模式识别、验证和确认,等等)。(2)目标:目标平台(iOS、Android、Web)或相关的输入工件(UI画画,截图),有关的研究。(3)方法:这是指什么类型的每种方法分析由源构件,即。、静态、动态或混合。(iv)技巧:这表明实施反向工程技术/理解考虑系统(仪表、代码注入、解析、爬行等)。(v)提取信息:这指定关键信息提取采用方法(运行时行为、事件序列,UI,碰撞检测,等等)。(vi)输出:这表示形式的结果将生成(调用图、有限状态机、报告、测试套件,等等)。(七)验证:通过什么方式进行验证的方法(案例研究、比较与其他工具/方法,评价)。

1总结之前的研究的分类的结果根据本体标准提出的Morgado [32]。


研究 目标 目标 方法 技术 提取信息 输出 验证

弗兰克et al。15] 项目的理解
功能位置
iOS
安卓
Java ME
静态 仪表
代码注入
运行时行为
事件序列
调用图
报告
案例研究
Joorabchi和Mesbah16] 模型复苏 iOS 动态 爬行
事件处理
运行时行为
用户界面状态
有限状态机 案例研究
杨et al。17] 模型复苏 安卓 混合动力 爬行
事件处理
解析
运行时行为
事件序列
有限状态机 案例研究
比较
评价
萨尔瓦•和Zafimiharisoa18] 验证和确认
模型复苏
安卓 动态 爬行 运行时行为
用户界面状态
碰撞检测
调用图
有限状态机
测试套件
比较
评价
Morgado et al。19),2014年 验证和确认
模式识别
安卓 混合动力 爬行
事件处理
解析
仪表
运行时行为
事件序列
错误
调用图
报告
测试套件
案例研究
比较
阮和Csallner20.] 用户界面的识别 手机用户界面设计 静态 光学字符识别OCR
事件处理
用户界面小部件
计算机视觉
Android的UI框架 案例研究
评价
Lamhaddab和Elbaamrani21] 移植 iOS 静态 解析
图建模
模型转换
源代码AST
用户界面小部件
用户界面序列
源的图模型平台(iOS)
图模型为目标平台(Android)
比较
评价
AmalFitano et al。22] 验证和确认
模型复苏
安卓 动态
仪表
测试生成
碰撞检测
错误
调用图
报告
测试套件
有限状态机
案例研究
比较
评价
Dugerdil和Sako23] 项目的理解
维护
iOS 静态 仪表
代码注入
运行时行为
事件序列
报告 案例研究
评价
Salihu et al。24] 模型复苏 安卓 混合动力 爬行
事件处理
解析
运行时行为
用户界面状态
有限状态机 比较
评价
Morgado和Paiva25] 验证和确认
模式识别
安卓 动态 爬行
事件处理
解析
运行时行为
事件序列
错误
调用图
报告
测试套件
比较
评价
陈等人。26] 用户界面的识别 手机用户界面设计 静态 神经机器翻译
卷积神经网络(CNN)
递归神经网络(RNN)
用户界面小部件 Android的UI框架 案例研究
评价
Beltramelli [28] 用户界面的识别 手机用户界面设计 静态 卷积神经网络(CNN)
递归神经网络(RNN)
DSL
用户界面小部件 Android的UI框架
iOS用户界面框架
基于web的你
案例研究
Amalfitano et al。30.] 验证和确认
模型复苏
安卓 混合动力 爬行
仪表
输入事件序列
机器学习
运行时行为
用户界面状态
人类的参与
调用图
有限状态机
测试套件
报告
案例研究

在此基础上深入批判分析之前的工作,仍有许多空白,没有被最近的研究解决。事实上,主要挑战覆盖在这些研究可以分为三个主题:UI测试自动化,程序理解,和移动。相当大的差距,值得特别注意的是没有一个先前的研究解决了完整的逆向工程从一个平台到另一个平台。另外,大多数的这些方法,它依赖于源代码的静态分析,没有利用的使用模型驱动工程范例(身边),为了更好地理解学习系统。只有尝试引入Lamhaddab和Elbaamrani21)走到移动应用程序通过专注于基于图模型的逆向工程。我们相信MDRE方法可以带来一个巨大的进步,对于检测行为和UI模式,GUI探索,机器状态识别,或事件处理。

3所示。实证研究设计

在这一节中,作者提出了本研究的实证研究设计。他们讨论的方法用于数据收集和数据分析。

3.1。数据收集

这个研究方法的第一步是进行文献调查相关的出版工作手机逆向工程领域,如部分所示2。这个阶段的目的是进行深以前作品的关键分析,确定当前的差距仍在逆向工程移动平台技术试图解决这个差距。

第二阶段的目的是收集移动开发者的需求。本研究的目的是探讨移动开发者所面临的真正的挑战在移动移植过程和识别洞察方面和技术轴必须覆盖在设计该工具。因此,重要的是要从各利益相关者参与收集数据移动应用程序开发。面试招募参与者通过MyAppConverter订户数据库(MyAppConverter:http://www.myappconverter.com)平台。因此,候选人被选择通过电子邮件活动,突出了路线图的新工具,并鼓励用户参与调查。作者选择20 Android开发人员和15 iOS开发者2到5年的经验。此外,他们的目标是10产品拥有者不一定是开发商,而是业务分析师。批准面试问卷调查,作者从MyAppConverter雇了一个小团队组成的两位高级移动开发者(iOS和Android)和一个功能分析。他们招募了总共45采访参与者和预定15到20分钟电话会议进行访谈根据他们的可用性。应该注意的是,所有的参与者都保证个人信息的保密和数据。

此外,问卷管理的三种版本的三类:iOS开发者,Android开发人员和产品负责人。这些问卷调查的目的是确定最佳实践和技术被广泛用于设计的UI部分iOS应用程序列表的组件构成困难当他们移植到Android,并定义功能的关键信息,这将有助于理解在移植过程中。

3.2。数据分析

在收集从业者的反应,作者仔细分析数据,以确定该工具的功能。值得注意的是,实际从业者支持研究的大多数45受访者,同意实施可逆向工程工具的功能规范和端口UI故事板,和能够贡献大幅移动移植项目的时间和成本。

对目标产品负责人的问卷调查,70%的受访者同意拟议的工具应该代表功能需求用例格式。在用例模板,功能需求是理解用户操作环境中,通常避免很多歧义,使其进入一个外环境系统的列表。然而,30%的受访者更倾向于代表功能规范在敏捷用户故事等形式。他们认为,用户故事形式是高度有效地捕捉和连接用户目标,功能需求和商业利益。总体而言,95%的受访者认为功能规范文档应该包括信息:项目团队,构建信息,依赖,限制,业务类模型、实体模型、屏幕细节,活动图和业务规则。

受访者的问卷是针对iOS开发人员反映,高百分比(85%的人)使用故事板和xib文件设计UI层。他们认为界面构建器在Xcode IDE使它更容易设计UI和流动而不需要编写任何代码。此外,故事板是强烈推荐与多个相互关联的视图控制器,消除样板代码执行视图控制器之间的过渡。然而,15%的受访者构建UI编程方式编写objective - c或代码。他们认为掌握iOS的编码与复杂的UI允许处理意见或动态布局,定制视图控制器之间的转换效果,和重构可重用的方式具体意见。65%使用自动布局特性来定义约束来控制用户界面将如何适应在不同的屏幕尺寸,设备旋转时,或者当应用程序运行在不同的地区。总体而言,47%喜欢用第三库定制UI组件而不是iOS UIKit框架。此外,90%使用xib设计静态表视图单元和显示动态数据。此外,他们使用代码定义表视图数据源需要(需要显示:https://developer.apple.com/documentation/uikit/uitableviewdatasource)和UITableViewDelegate (UITableViewDelegate:https://developer.apple.com/documentation/uikit/uitableviewdelegate)为了管理单元选择和其他特性相关的显示数据。

关于目标Android开发人员的问卷调查,90%的受访者使用xml布局设计UI原型。总体而言,60%使用小宽度限定符为了适应布局优雅应对不同的屏幕尺寸和取向。然而,40%同意,最好使用约束布局来创建一个响应UI。此外,高的比例(92%)的受访者推荐模块化UI组件与片段(Android片段:https://developer.android.com/guide/components/fragments)。总体而言,100%同意这将是一个乏味的任务等iOS UI组件由于TextView港TableView,集合视图控制器,页面视图控制器,分割视图控制器,并收集可重用视图。此外,所有的受访者承认有一个额外的努力适应iOS图形资产为Android。最好的解决方案是正确资产规模为相关设备屏幕大小。此外,所有的受访者确认这不是明显的找到一个等价定义UI组件;在大多数情况下,开发人员只能使用最接近的标准Android UI组件基于谷歌指南。

4所示。建议的方法

本节概述了模型驱动的逆向工程(MDRE)方法在iSpecSnapshot紧随其后。作者的目标是接近MDRE从一个新的背景下,移动开发。他们将试图回答丰富逆向工程文学,一个热门话题,地址从iOS移动应用程序移植到Android。目前的密切合作寻求解决逆向工程的文档和iOS应用程序的UI。当前贡献了光使用MDRE模式识别的主要步骤和建模标准与目的提出一个更通用的和可扩展的方法。

具体来说,在他们的方法中,作者继续以同样的方式作为Fleurey et al。33采用他们MDRE步骤和一些改变:代码PSM, PSM PIM, PIM到PSM, PSM代码。作者的方法的特殊性是所有通过元模型是基于股和ASTM标准(见附录B)。因此,该过程是描绘在图1,由四个主要步骤:(我)PSM模型发现(代码)(2)PIM模型语义提取(PSM)(3)模型转换(PIM到PSM)(iv)模型的代码生成代码(PSM)

运行例子,作者选择了三个开源项目从苹果示例代码库和Github。表2显示了资源链接的细节为每个运行示例(ID、名称和资源链接)。

3报道一些指标运行的每一个例子:许多源代码文件(头文件和主要文件),源文件的大小,数量的使用故事板/ xib文件,和静态UI元素的数量。


ID 不。源文件(h / m) 源文件的大小(KB) 不。故事板(xib文件) 不。UI元素的 Xcode构建(SDK)

1 10 30. 1 26 7.2/9.0
2 50 192年 2 157年 7.2/9.0
3 22 22 3 31日 7.2/9.0

4.1。步骤1:模型的发现

模型的发现是一个解析步骤,旨在解析源手机应用程序工件以产生一组代表性的模型。这些所谓的初始模型有很强的依赖组件的源程序;它们通常被OMG称为特定于平台的模型(psm)(见附录A)。这一步的实现取决于源移动平台的技术。它主要是基于静态分析PSM模型从源代码自动生成工件。通常,一个iOS应用程序是由:编程语言文件(。.Swift, h, m . c . cpp),特定于平台的文件(。故事板、.pch .plist .string),资产文件(。bmp格式jpeg, png)和数据文件(。xcdatamodeld, . xml . json)。

在初始阶段,明智的做法是先定义的元模型描述源移动平台。的确,正如前面提到的图2,作者区分四元模型的变体:技术、基础设施、应用和数据元模型。

技术元模型描述源移动平台中使用的编程语言。它继承主要来自OMG ASTM元模型。例如,iOS移动平台,作者定义ASTM元模型等常用编程语言:C, c++, objective - C和迅速。图3说明摘录objective - c的元模型(objective - c块的元建模表达(objective - c块:https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html / / apple_ref / doc / uid / TP40007502-CH1-SW1))。

基础设施的元模型定义了树结构和源移动应用的相对路径(文件夹、子文件夹、文件、资产、资源,等等)。它继承主要来自OMG KDM元模型。图4显示了iOS xcode项目元模型的概述。

主要应用元模型定义了特定的信息关于源移动平台包括构建设置、依赖、编译器、可执行的名字,和静态UI工作流。它的目的是根据官方iOS文档(UIKit官方文档:https://developer.apple.com/documentation/uikit)。图5概述了元模型特定的UI部分(xib文件)。

模型发现步骤是通过平台解析器,执行特定的源平台。作者建立了四种解析器:(我)基础设施的解析器允许生成源程序的物理模型。这个模型包含所有源的树结构和相对路径移动应用(文件夹、子文件夹,文件、资产、资源,等等)。生成的模型符合Xcode项目KDM元模型(2)技术解析器允许生成所有编程语言的抽象语法模型文件源应用程序中使用(例如,C, c++, objective - C,并迅速)。在这个阶段,所有生成的模型符合技术ASTM元模型(3)应用解析器允许构建应用模型,这是特定于源平台的一些关键构件(例如,工作区文件,xcodeproj文件,pch文件,plist文件,xib文件,Pod文件,等等)。一般这些工件包括源信息平台,即构建设置、依赖、编译器、可执行文件名称和静态UI工作流。这些模型(例如,算法1)根据应用元模型而设计的(iv)数据解析器允许建立数据模型,静态存储在文件系统(例如,xdatamodel文件,json文件,xml文件,等等)。这些模型符合典型的元模型

<故事板:xmi文档:version = " 2.0 "
propertyAccessControl = "没有" systemVersion = " 15 d21”
targetRuntime = " iOS。CocoaTouch“useAutolayout =“是”
initialViewController = " WII-Gl-wjJ " toolsVersion = " 9531 " version = " 3.0 " >
<孩子xsi: type = "故事板:依赖性”>
<孩子name = "部署" / >
< /孩子>
<孩子xsi: type = "故事板:场景”>
<孩子xsi: type = "故事板:场景”sceneID = " NNp-Gi-V3j " >
<孩子xsi: type = "故事板:对象”>
<孩子xsi: type = "故事板:表”
customClass = " CategoryViewController " id = " 4 ep-np-ax8 " >
<孩子xsi: type = "故事板:tableView”sectionHeaderHeight =“22”
alwaysBounceVertical = "是的" id = " 4 v1-1b-ace "风格=“平原”
不透明=“不”separatorStyle =“默认”内容模式=“scaleToFill”
关键= "视图" sectionFooterHeight = " 22 " clearsContextBeforeDrawing =“不”
clipsSubviews = "是的" rowHeight =“44”dataMode = "原型" >
<孩子xsi: type = "故事板:矩形”高度= " 568 "
宽度= " 320 "y= = " 0.0 "关键“帧”x= " 0.0 " / >
<孩子xsi: type = "故事板:autoresizingMask”
widthSizable = "是的" heightSizable =“是的”键= " autoresizingMask " / >
<孩子xsi: type = "故事板:颜色”色彩=“calibratedWhite”
α= " 1 "白色=“1”键= "写成backgroundColor " / >
< /孩子>
< /孩子>
< /孩子>
< /孩子>
< /孩子>
<孩子xsi: type = "故事板:点”y= " 752 "键= " canvasLocation "x= " 1220 " / >
< /孩子>
< /孩子>
< /故事板:文档>
4.2。步骤2:语义提取

语义提取步骤之间被认为是一个中点code-to-model和模型到模型的步骤。事实上,它旨在分析PSM模型为了提取一些有用的语义信息,需要建立PIM模型。提取过程是设计为迭代和支持技术和应用模式。这个过程是由一组语义提取器,识别,收集,整合所有的语义数据构建语义所需移动模型PIM语义移动元模型的一个实例。作者选择了一个通用的元模型,代表,语义的方式,任何移动应用程序。该元模型的结果与两位高级移动开发者密切合作(iOS和Android) MyAppConverter团队。元模型因此精制iSpecSnapshot的私人测试期间和调整。元模型继承主要来自KDM标准(图6)。语义移动元模型简要概述如下:(我)一个移动应用程序实体(MobileApp)有一些信息,如应用程序的名字,可执行文件的名称、版本、作者、包等。它是由几个屏幕(AbstractScreen继承自屏幕KDM元模型中描述)。MobileApp也包含信息定位参数(ApplicationOrientation)。(2)屏幕有一个控制器,它是用于管理屏幕的行为(AbstractController继承自KDMEntity KDM元模型中描述)。屏幕可能包含一个布局(AbstractLayout),用于UI组件。(3)一个控制器,它是指为iOS和Android活动视图控制器,组织实施行动的行为的方法。它还定义了方法来管理控制器的生命周期。(iv)UI组件,它被确定为一个AbstractView实体,继承自UIElement,股中描述元模型。描述以下属性:id,宽度,高度,marginTop, marginBottom等等。UI组件可能会处理事件。(v)事件实体可以触发一个动作(AbstractAction)。行动的结果可能导致一个重定向到同一个屏幕或到另一个屏幕,甚至到另一个应用程序。

这个阶段还包括以下步骤:PSM模型探索,PSM模型查询和PIM模型生成。构建PIM模型,提取器上面所提到的,寻求确定以下信息:(我)一般信息:应用名称,图标,程序包,版本,和作者(2)平台信息:构建、设备方向与框架、库和本地化(3)用例信息:启动屏幕,屏幕工作流,控制器,应用生命周期行为,导航,事件,行动,和服务流(iv)UI组件属性:大小、位置、补偿范围、颜色、状态,过渡,和效果

按照前面生成的PIM模型语义移动元模型。

4.3。步骤3:模型转换

这个模型到模型M2M转换阶段的目标是年底将PIM模型生成的前一步PSM特定于目标平台。在文献中,模型转换可以使用各种语言:声明(例如,QVT [34]),命令(例如,Java)或混合(例如,ATL (35])。在当前方法的情况下,作者选择了Java作为一个命令式语言转换阶段。他们的选择是有意义的对于许多技术上的原因,也就是说,在设计方面,重构、性能、和集成。这个过程显然是由元模型驱动的。它是由一组进行明确变压器可能命令式语言(如Java),允许探索PIM模型,查询、计算,并生成目标PSM。换句话说,转换规则设计从偶极子。规则被触发时,从节点满足几个条件相关的节点。规则逻辑可能包括特殊治疗和数据计算根据目标平台。这个过程是递归的,直到PSM模型构建。

综上所述,模型到模型的过程包括以下流程:模型探索,查询模型,模型计算和PSM的一代。关于研究范围,作者所描述的特定于Android平台的目标元模型,同时指定以下领域:应用和文档。主要应用元模型定义了特定的信息对目标移动平台包括(构建设置、依赖、编译器、可执行文件名称和静态UI工作流)。它的目的是按照官方Android文档(Android UI和导航官方文档:https://developer.android.com/guide/topics/ui/)。Android应用的概述元模型如图7

算法2可视化的一个例子将PIM模型Android UI模型(PIM到PSM):

< ?xml version = “1.0” encoding = “ASCII”?
< androidapp: androidapp >
name = " TheSimpliestTODOLIst " mainPackage = " com.myappconverter。移动“version = " 1.0.0 " >
<屏幕xsi: type = " ui: AndroidScreen”
name = " Activity_2sa_q5_Eym "
screenWidth = " 320.0 "
screenHeight = " 568.0 "
导航条= " true " >
<控制器xsi: type = "核心:活动”
name = " Activity_Vic_8g_ebU " qualifiedName = " com.myappconverter.mobile。Activity_Vic_8g_ebU " id = " Vic-8g-ebU " / >
<布局xsi: type = "布局:使用”
导航条= " true "宽度=“matchparent”高度=“match_parent”背景= " # FFFFFFFF " >
<视图xsi: type = "布局:NavigationBar”
id = " taskdetail "高度= " 64 " tintColorNav = " # 1 e73fe " backgroundTint = " # F5F5F5 " title =“任务详细”
backTitle =“返回”titleColor = " # 000 " / >
< subLayout xsi: type = "布局:使用”
id = " id3vVkR7e7 "宽度= " 320 "高度= " 568 "背景= " # FFFFFFFF "写成backgroundColor = " # FFFFFFFF " >
<视图xsi: type = "观点:滚动视图”
id = " pvh_st_nB8 "宽度= " 320 "高度= " 568 " >
< subLayout xsi: type = "布局:使用”
id = " KDE_WF_gSZ "宽度= " 320 "高度=“40”marginTop =“15”背景= " # FFFFFFFF "写成backgroundColor = " # FFFFFFFF " >
<视图xsi: type = "观点:TextView”
id = " SDE_fx_EOQ "宽度=“42”高度=“21”marginTop = =“9”文本”标题:“marginLeft =“20”textAlignment输入textColor = " # FF000000 " = " centervertical textSize = " 14.0 " >
< colorsred = " 0 "绿色蓝色= " 0 "α= " 1 " = " 0 "输入textColor = " darkTextColor " / >
<字体类型=“系统”键= " fontDescription " / >
< /视图>
EditText <视图xsi: type = "的观点:“
id = " P74_wp_hB2 "宽度= " 230 "高度= " 30 " marginTop =“5”marginLeft = " 70 " marginRight = " 20 " textSize = " 13.0 "边框类型=“roundedRect”>
<字体类型=“系统”键= " fontDescription " / >
< /视图>
α< colorswhite =“1”=“1”键= "写成backgroundColor "色彩= "自定义" / >
< / subLayout >
< subLayout xsi: type = "布局:使用”
id = " nw2_zD_rrP "宽度= " 320 "高度= " 185 " marginTop = " 55.0 " marginLeft = " 0 "背景= " # FFFFFFFF "写成backgroundColor = " # FFFFFFFF " >
<视图xsi: type = "观点:DatePicker”
id = " qLg_1Q_MqF "宽度= " 230 "高度= " 162 " marginLeft = " 70 " marginRight = " 20 " / >
<颜色白色= " 1 "α=“1”键= "写成backgroundColor "色彩= "自定义" / >
< / subLayout >
< /视图>
< / subLayout >
> < /布局
< /屏幕>
< / androidapp: androidapp >

文档元模型描述了所有需要的信息来构建功能设计规格文档的结构。作者选择了用例格式所显示受访者在实证研究部分。文档包括以下信息:应用名称、应用图标,应用内容,构建信息,活动图、业务类模型、实体类模型,屏幕,屏幕组件和规则的行为。文档的概述元模型如图8

另外,转换过程包括一个互补的关键步骤,这是两个平台之间的映射。作者区分两种类型的映射:(我)语义映射:它的目的是定义一个语义对应应用元模型的源和目标之间的移动平台。例如,它给的答案如何寻求解决移动平台UI组件之间的匹配。表4显示一个iOS之间的语义映射列表UI组件和Android UI组件。在这个阶段,作者还定义多个转换规则为了匹配从语义的角度两个平台之间的界面不一致,即文本对齐,导航栏,字体,按钮样式,控制,图标…(表5)。此外,作者建立了一个支持Android正如具体的转换规则。iOS设备在各种屏幕尺寸和可用于肖像或横向(表6)。指出,在iOS,所有UI组件的位置在设备上绝对指标坐标系统基础,除了自动布局功能。使用自动布局,允许定义规则(称为约束)管理iOS应用程序中的内容。Android也运行在不同的设备有不同的屏幕尺寸和像素密度(像素密度在Android上:https://material.io/design/layout/pixel-density.html pixel-density-on-android)(表7)。专用转换规则将基于绝对公制。评估,作者使用了最小宽度限定符(最小宽度限定符指定最小的屏幕上的双方,无论设备当前方位:https://developer.android.com/training/multiscreen/screensizes TaskUseSWQuali)。“最小宽度”屏幕大小限定符允许提供替代布局屏幕有最小宽度测量密度像素(见表8)。作者实现了一个交叉相乘的规则,以确定宽率和高速率的两个设备平台。他们认为设备指标接近对方(如iPhone 6 vs .三星S5)。规则如下: (2)技术映射:它的目的是建立一个映射知识库(21]。基本设计为一个节点图,管理之间的关系源和目标移动平台的sdk API(参见图9)。源的分析ASTM模型允许生成依赖源移动应用程序api中使用的报告。这份报告可以帮助开发人员驱动的选择在移植过程中目标API来使用。


iOS UI组件 Android UI组件

UIActivityIndicatorView 微调控制项
UIAlertView AlertDialog
UIBarButtonItem ActionBar
UIBarItem 子菜单
UIButton 按钮
用户界面颜色 颜色
UIDatePicker DatePicker
UIEvent 事件
UIFont 字体
用户界面图像 图像
UIImageView ImageView
UIInputView KeyboardView
UILabel TextView
UIMenuItem 子菜单
UINavigationBar ActionBar
UIPageViewController :viewpage
UIPickerView DatePicker
UIProgressView ProgressBar
UIScrollView 滚动视图
UISearchBar SearchView
UISegmentedControl RadioGroup
UISlider SeekBar
UISplitViewController 使用
UIStepper 按钮
UISwitch ToggleButton
UITabBar TabHost
UITabBarItem TabWidget
UITableView ListViewCompat
UITableViewCell TableRow
UITextField EditText
UITextPosition FieldPosition
UITextView TextView
UIToolbar ActionBar
UIView 布局
UIWebView WebView
ui窗口 窗口


UI方面 iOS 安卓

文本对齐方式 为中心的
导航栏 标签栏菜单为中心的项目 底部导航位于底部
字体 旧金山,Helvetica Neue Roboto
按钮样式 平键与阴影 浮动操作按钮和文本
图标 细线的图标 厚中风图标
控制 标签和按钮 简单的强调
列表 箭头图标 没有箭头图标在右边


设备 肖像维度

iPhone, iPhone 4, 4 s 320 dp×480 dp
iPhone 5, 5 s, 5 c 320 dp×568 dp
6 s iPhone 6日,7日,8 375 dp×667 dp
iPhone 6 + 6 s + 7 + 8 + 414 dp×736 dp
iPhone X, X 375 dp×812 dp
自动布局 600 dp×600 dp


设备 肖像维度

谷歌像素 411 dp×731 dp
HTC M9之一 360 dp×640 dp
LG G3 480 dp×853 dp
极限摩托 360 dp×640 dp
联系5 360 dp×640 dp
Nexus 7 600 dp×960 dp
三星Galaxy S5 360 dp×640 dp
三星Galaxy S8 360 dp×740 dp
索尼Xperia Z3 360 dp×640 dp


度规 最小的宽度

320 dp×569 dp sw320dp
360 dp×640 dp sw360dp
384 dp×640 dp sw384dp
411 dp×731 dp sw411dp

4.4。步骤4:代码生成

逆向工程过程的最后一步是一个文本M2T转换模型。它旨在从PSM模型生成代码或文本工件。这个过程被分解成几个发电机。每个发电机被认为是一个模板引擎,服务于特定领域的目标平台。

作者选择了PSM编码策略,这被广泛认为是最适合描述和表示在给定的开发平台应用需求。然而,作者在36)强调其他代码生成策略在MDD方法,如PIM-to-PSM-to-Native代码,PIM-to-Native代码,PSM-to-Native代码,PIM-to-Cross平台代码,PIM-to-Cross平台框架,SM-to-Cross平台代码。发电机基本上是基于Xpand最(Eclipse Xpand最:http://wiki.eclipse.org/Xpand),这是一个模型文本语言(MTL) (37专用的基于EMF模型的代码生成。Xpand最有趣的特性,例如多态提供模板调用,面向方面的编程功能扩展,和模型验证。还有其他M2T替代工具,像Acceleo (Eclipse Acceleo:http://www.eclipse.org/acceleo/)和喷气(Eclipse飞机:http://www.eclipse.org/modeling/m2t/downloads/?project=jet档案),它提供了代码生成框架使用EMF和设施。发电机的基本思想是提炼和PSM模型转换成代码。模板包含的碎片目标文本和代码信息来源于PSM模型所取代。作者为每个应用程序域定义了多个模板:(我)模板移动应用物理结构(Android工作室结构)(2)模板为目标语言(Java类)(3)模板界面部分(xml布局、画板)(iv)模板为特定资产(清单、gradle配置值,字符串,并构建设置)(v)模板文档(功能规范文档和readme文件)(vi)模板数据(json, csv, xml和SQLLite这样)

10概述xpand最模板为功能设计规范文档。

11概述xpand最模板设计为Android UI组件。

12概述概述的PSM代码步骤的结果上执行的功能规范PSM模型。为三个运行示例生成的源代码公开共享一个专用Gitlab库(Tabster (Tabster Android UI项目:https://gitlab.com/ispecsnapshot/tabster),TheSimpliestTodoList (TheSimpliestTodoList Android UI项目:https://gitlab.com/ispecsnapshot/thesimpliesttodolist)和UICatalog (UICatalog Android UI项目:https://gitlab.com/ispecsnapshot/uikitcatalog))。

4.5。讨论

在文献中,Brunliere等人在38引起了作者的关注一个“必须”特征,每个MDRE方法应当遵守。作者认为这些特征似乎是有理由的,特别是如果一个可持续和可伸缩的方法是确保。这些标准如下:(我)Genericity: MDRE方法应该依靠OMG元模型标准和可定制的基于模型的组件(2)可扩展性:MDRE方法应保证分离模型(作为输入或输出元素)和逆向工程的每个阶段的行为和治疗过程(3)应用领域:关注特定的方法或通用目的的范围(iv)自动化:逆向工程过程应完全或部分自动化(v)全部/部分覆盖:建模应该覆盖所有代表构件系统的同时保持它们之间的语义联系(vi)可伸缩性:这是指如何MDRE工具工作时系统被研究的大小增加(七)验证:该方法被工业案例研究验证,还是只是在早期阶段?

基于上述列表的标准,作者试图回答如何关于MDRE场方法仍然有效。

4.5.1。Genericity

该方法提供了一个核心元模型和基于OMG标准KDM ASTM规范。的确,对于每个MDRE步骤,作者描述了一组元模型根据逆向工程的目的,例如:(我)元模型用于模型发现步骤:Xcode项目元模型,objective - c的元模型,斯威夫特元模型,故事板元模型,Xib元模型,Plist元模型,xcdatamodel元模型(2)元模型用于语义提取步骤:语义元模型(3)元模型用于模型转换步骤:AndroidApp元模型,AndroidProjectStructure元模型,Java元模型和功能规范文档的元模型

4.5.2。应用程序域

建议的方法的范围是专门为逆向工程设计移动平台领域。在这部作品中,作者侧重于一代的功能规格和Android UI。这些工件是有用的对于开发人员从iOS引导整个移植到Android。然而,本身也是有效的方法用于其他目的。当前方法的强项在于代表了移动应用程序的形式PSM模型。反过来,任何信息或数据从应用程序保存供以后处理。还有其他用例中可以利用当前的方法,例如:(我)升级iOS最新迅速objective - c语言编写的应用程序版本(2)重构的一些api更兼容的和稳定的(3)逆向工程的iOS界面部分微软Xamarin的UI或本地的反应(iv)逆向工程从Android iOS

4.5.3。可扩展性

该方法保证了之间的分离模型和逆向工程过程的每个阶段的行为。事实上,当前的实现方法包括扩展元模型或添加新的设施和能力定义新的转换规则以及定义新的发电机的模板。

4.5.4。自动化

当前的方法是完全自动化的,关于生成功能规格和UI的范围的部分。然而,它似乎是合理的,提出限制可能的数量时,平台之间的映射sdk。

4.5.5。全部/部分覆盖

在拟议的方法中,为了描述元模型涵盖所有源和目标移动平台的观点。

5。工具实现:iSpecSnapshot

5.1。描述

本节描述iSpecSnaphot工具作为逆向工程工具,实现该MDRE方法。所介绍,该工具的主要目的是生产规范文档对于一个给定的本地iOS移动应用和逆向工程Android UI的一部分。iSpecSnapshot是一种基于模型的工具箱,实验工具,由MyAppConverter团队作为MyAppConverter SAAS平台的一部分。图13显示iSpecSnapshot的技术架构。

iSpecSnapshot结构为一组松散耦合的服务合作。每个服务都是在所谓的服务注册中心注册。注册过程定期刷新后心跳机制。子服务相关的服务的逻辑实现勉强。它运行作为一个独特的过程和通信通过一个分布式流媒体平台为每个MDRE阶段服务。请注意,所有的服务都紧密沟通与底层集群存储库。集群包括以下存储库:元模型库、知识库,和模板库。

5.1.1。元模型库

它包括在特定的元模型,针对移动平台。元模型是由平台类型和分类等领域基础设施、技术和特定于平台的元模型。例如,iOS平台的元模型列出如下:(我)基础设施:Xcode项目元模型(2)技术:objective - c的元模型,斯威夫特元模型(3)特定于平台的元模型:故事板元模型、plist元模型和xcdata元模型

5.1.2中。知识库KB

这房子两个平台的sdk api之间的映射(iOS和Android)。知识库结构图形数据库,每个节点代表一个实体(头/ java包、类、接口、方法、参数,访问,等等),和每个关系表示两个节点是如何相关联的。使用图形数据库有许多关键的优势,例如性能、灵活性和敏捷性。

5.1.3。模板库

它包括所有类型的模板,用于代码生成阶段。这也是结构域:基础设施、技术、文档和应用。以下分类被认为是:(我)基础设施:它描述了Android工作室项目模板(2)技术:它描述了Java AST模板(一)声明块:类、接口、方法等。(b)声明块:如果,,,等等。(3)应用:它描述了UI组件(TextView、按钮、列表、图像、TexyFiel开关,等等)。(iv)文档:描述功能规范文档的所有部分:封面页,页面UML图,活动图部分,覆盖报告等。

从可用性来看,用户体验的工具是人体工学的聪明和直观简单(图14)。的确,与移植会话开始,最终用户应进行如下:首先创建一个帐户,然后上传iOS应用程序的源代码,启动移植过程,可视化界面预览,并分析生成的输出(陕西林业局文档和Android UI项目)。

从逻辑的观点,iSpecSnapshot提供四个服务:(我)解析器允许自动生成PSM模型从iOS移动应用程序源代码。PSM模型对应于Xcode项目结构、编程语言(C, c++, objective - C,斯威夫特),xib文件,plist文件、字符串文件等。(2)提取器分析PSM模型,它是由解析器,为了提取语义信息构建PIM主模型(语义移动模型)。PIM模型通常在iOS应用程序识别特定的信息:名称、图标、构建、设备定位,与框架,屏幕工作流,生命周期行为,导航,过渡,UI组件属性,等等。(3)变形金刚探索PIM模型和发射一个递归转换过程为了构建文档PSM模型和Android PSM模型。陕西林业局的PSM模型以可靠的方式描述了整个功能规范文档的结构和内容:封面、摘要页面,屏幕页面框架依赖关系和映射,实体模型,持久模型,活动图等。Android应用PSM模型描述目标Android UI项目的结构。(vi)发电机移动产生的陕西林业局PSM和Android PSM模型和从模板库加载相应的模板以生成陕西林业局文档和Android UI框架。

5.2。限制

作者声音的注意,他们的方法支持目前逆向工程的iOS应用程序UI静态定义的一部分在故事板或Xib文件。事实上,绝大多数的UI组件UIKit框架被覆盖(UIView、UILabel UIButton,一下UITextField UITextView, UISlider, UISegmentedControl, UISwitch, UITableView,等等),除了一些限制相比,Android记者匹配语义属性。然而,目前的研究正在进行中支持UIKit应用程序的UI部分是动态编程或定制迅速或objective - c。这个任务的主要挑战是如何识别代码块,开发人员使用说明建筑,初始化,初始化和调用UI组件的内部控制器的AST树。

6。评价

实现的工具是根据两个方面评估:评估作为一种工具,符合软件开发标准和评估作为一种有效的移动移植工具。

评估工具对软件开发标准的测试包括两个阶段:α测试和内测测试。同步与MyAppConverter团队,作者进行了alpha测试阶段,以避免任何错误或问题,保证满足完全既定需求的工具。最后这个阶段,私人测试进行了紧密的组织开发人员选择面试课程。私人测试的目的是收集反馈如何提高整体用户体验的工具,以及修复中发现的一些问题生成的输出。

评估提议的工具作为一个有效的移动移动开发者移植工具,作者使用了一个实验过程试验选择组内的用户。这个过程的目的是确保生成的输出满足开发商的预期的功能规格细节从iOS中提取源程序和UI Android项目移植从iOS的质量。因此,他们试图回答的基本问题的研究现状:RQ: iSpecSnapshot有效帮助移动开发者加快移动移植过程?

评估一个有效的评价,作者将仔细关注使用UIKit框架构建的应用程序(iOS UIKit框架:https://developer.apple.com/documentation/uikit)。很明显,他们会特别感兴趣的反馈从两类用户:Android开发者和功能分析。作者还找其他工具与iSpecSnapshot的特性。但到目前为止,他们找不到任何工具的功能范围可以比作iSpecSnapshot工具(生成功能规范和Android UI部分)。然而,有商业工具的技术文档非常贫穷和二进制反编译器的职业或互动的反汇编程序,甚至调试器,如veracode iRet (iRet工具包:https://www.veracode.com/iret-ios-reverse-engineering-toolkit-veracode),艾达(DA正方观点:https://www.hex-rays.com/products/ida/),料斗(Hooper:https://www.hopperapp.com)。

6.1。参与者

作者已经招募了13个参与者,从采访中选择课程。参与者分为两类。首先是由10 Android iOS平台的开发人员以最少的技能。第二个涉及3移动功能的分析师,他们习惯于生产移动功能规范文档。大多数参与者地位在创业公司或个体的自由职业者。所有的参与者都对他们的隐私和保证数据在他们参与这项研究。数据只用于研究目的,在任何情况下不会与任何人分享。

6.2。实验对象

作者进行了实验测试用户的应用程序。就像之前提到的,他们已经限制了实验对象13 iOS应用程序,选择提交的参与者。参与者的选择应用是由3个标准。首先,应用程序必须至少与Xcode7兼容。x版本。其次,UI部分应该根据故事板设计/ xib文件,最后,使用UIKit组件应该超过70%的所有使用UI组件(定制的UI组件不会在当前工具的范围)。保护参与者提供的机密性的应用,作者确定了应用程序的标识符 和参与者的标识符

9显示每个应用程序的一些特点:世卫组织制定了iOS应用程序数量的资源,全球开发成本(人日),工作量UI的一部分(人日),屏幕的数量,总数的UI组件,和UI的复杂性。从报告的数据表中9选定的应用程序是足够多样化,因为他们代表不同的功能范围和变量指标的工作量和大小。


iOS应用程序ID 老板 由(资源) 全球dev.成本(人日) UI部分工作负载(人日) 不。的屏幕 不。用户界面的排版。 UI的复杂性 类别

APP1 PAR1 2 30. 6 18 158年 媒介 教育
APP2 PAR2 2 68年 12 42 347年 基本 游戏
APP3 PAR3 1 43 9 19 144年 媒介 沟通
APP4 标准杆4杆 3 63年 15 38 290年 复杂的 社会
APP5 PAR5 3 96年 20. 49 370年 复杂的 团队协作
APP6 PAR6 3 75年 22 43 314年 媒介 健康
APP7 PAR7 2 54 11 23 130年 复杂的 网络
APP8 PAR8 1 15 3 9 53 基本 广告
APP9 PAR9 2 24 5 25 211年 基本 医学
APP10 PAR10 2 20. 4 14 107年 媒介 事件
APP11 PAR11 1 30. 5 13 85年 媒介 游戏
APP12 PAR12 2 64年 21 27 167年 复杂的 社会
APP13 PAR13 1 20. 4 13 112年 基本 医学

6.3。指标定义

以来,在目前的工作中,作者侧重于逆向工程的功能规范和UI移植,他们仅仅是指出,在他们的实验中,他们决定评估的有效性iSpecSnapshot关于功能规范公式的准确性,映射的报道框架,覆盖的UI组件,和成本利润生成的Android UI的一部分。因此,以下指标被认为是:(我)功能规范准确百分比(FSA %)表示信息的一致性和完整性的百分比代表女性性功能障碍的文档,包括持久性模型(PM %)、业务类模型(BM %)和活动图(%)。它可以测量根据以下公式: (2)的报道框架映射比例(CFM %)定义了映射的iPhone SDK的百分比元素中使用iOS源代码,记者在Android SDK。 (3)崔覆盖UI组件的百分比(%)定义的比例生成的Android UI组件的整体iOS应用程序的UI组件。 (iv)成本利润生成的Android UI的一部分比例(CMUI %)定义生成的Android UI部分所涉及的成本利润率从零开始开发任务。

6.4。实验设计

进行的实验方法进行研究包括三个连续的步骤:源程序分析,输出比较,和指标分析。

在源程序分析步骤,一个研究员和高级iOS开发者,从MyAppConverter团队的任务为每个iOS应用程序准备一份分析报告从列表中被选中的对象。报告包括以下信息:数量的屏幕,每个屏幕的标准UI组件数量,数量的定制的UI组件,用户界面的复杂性,屏幕之间的过渡(使用故事板连接或由定义代码),并引用吊舱或第三库。分析任务也由回顾iOS PSM特定于每个应用程序。我们的目标是确保发现阶段产生的模型模型不包含错误,这可能导致错误结果的其他阶段MDRE过程。

在输出比较步骤中,作者把选定的对象分为两组:g用户界面包括Android开发人员的任务审查iSpecSnapshot工具生成的Android UI项目和比较他们的iOS应用程序的UI部分。第二个G-SPEC组的任务评估的内容功能规范文档生成的所有的应用程序。参与者的分析更为重要,因为它可以提供一个关键的最终客户的关系结果生成的评估工具。然而,作者认为,限制他们自己的判断,就结果而言,可以偏见的总体评价工具。评估生成的Android UI项目,他们指导参与者生成的Android UI项目导入到安卓Studio IDE和他们建议使用3.1。x版本。参与者被邀请使用Xcode IDE接口生成器9。x比较iOS界面生成的Android UI。应该注意的是,生成的android xml布局是由模式识别的活动_ < iOS屏幕的id > . xml。为了更好地帮助每个小组的成员在他们的分析中,作者已经配置了Trello (Trello:https://www.trello.com敏捷工具)。Trello是一种协作工具,组织项目进入董事会。他们为每个应用程序设置Trello董事会;然后,他们发送电子邮件邀请,邀请每个参与者加入相应的董事会。每个参与者被带到报告任何评论或错误“卡片”在“问题积压”列表中。也是有趣的指定每个问题的严重性使用“标签”修饰符:“至关重要的”,“大”,“媒介”,和“低”。错误报告的每个参与者被研究者的支持团队;然后搬到Trello董事会的“进步”列表。资格的bug会指出MDRE过程的阶段需要调整纠正错误。一旦错误纠正,然后搬到卡与缺陷相关的“完成”列表。 This process is repeated for each application until all the bugs are exhausted. Each participant is asked to renew a new iteration to make sure that all these remarks are taken care of.

在数据收集和分析步骤,作者分析了报告由每个参与者。去年迭代结束时,每个参与者被带到填写自己的Trello董事会以下指标:执行时间(g用户界面和G-Spec组)的报告,从持久性模型检测元素的百分比(保留G-Spec集团),从商业模式检测元素的百分比(留给G-Spec集团),发现屏幕的比例转换(留给G-Spec集团),映射iPhone SDK的百分比与Android SDK(留给G-Spec集团),生成UI组件的数量每屏幕(留给g用户界面组),和努力实现自定义UI组件(留给g用户界面组)。

6.5。实验结果

10报告结果的指标测量值的选择应用。结果也表示为图(图15- - - - - -17)更适当地分析FSA %, CFM %, CMUI %指标。


iOS应用程序ID 点% BM % 我% FSA % CFM % 崔% Eff汽车将军UI (sec) Eff定制UI(人日) Estim Eff Android UI的男人(人日) CMUI %

APP1 One hundred. 65年 62年 75.67 59 68年 96年 1.58 6 69.54
APP2 73年 92年 55.00 71年 94年 209年 0.65 12 92.50
APP3 One hundred. 90年 67年 85.67 63年 60 87年 1.78 9 77.25
APP4 98年 42 46.67 53 41 175年 5.34 15 62.74
APP5 One hundred. 53 51 68.00 48 43.5 223年 6.52 20. 66.14
APP6 One hundred. 84年 65年 83.00 58 65年 190年 3.43 22 83.28
APP7 One hundred. 47 49 65.33 54 44 79年 2.27 11 77.08
APP8 One hundred. One hundred. 66.67 78年 89年 32 0.18 3 85.60
APP9 67年 One hundred. 55.67 83年 93年 128年 0.46 5 85.78
APP10 One hundred. One hundred. 69年 89.67 64年 58 71年 1.40 4 58.70
App11 One hundred. 51 70年 73.67 67年 56 52 1.17 5 71.66
App12 One hundred. 74年 54 76.00 49 52 102年 2.80 21 85.47
App13 One hundred. One hundred. 66.67 81年 92年 69年 0.28 4 86.76
Avg 69.82 63.69 65.81 116.38 77.12

基于功能的评估分析分析师iSpecSnapshot明显标识实体模型,业务类模型和活动图。事实上,对13个应用,FSA %的平均值是69.82%,这是很令人鼓舞的(图15)。

作者观察到iSpecSnapshot显然已经设法确定持久性模型(PM % = 100%),对于应用程序使用xcdatamodel作为一种格式来描述持久性模型。

对于一个应用程序 分数(例如APP7, 47%),这是由于这样的事实:业务类编码以外的其他语言objective - c (beta版本的解析引擎识别的objective - c语言)。

至于应用程序有一个分数 (例如APP4 42%),这是合理的,因为事实上的流程导航屏幕部分编程之间的视图控制器(iSpecSnapshot仅限于连接的beta版本的导航在故事板中定义)。

关于CFM %覆盖率的映射框架从iOS、Android、知识库KB的iSpecSnapshot显示一个可接受的平均63%被认为是应用程序的评估(图16)。事实上,大多数的研究应用程序使用iPhone SDK框架中不支持知识库;此外,还有许多应用( )使用第三库或特定的豆荚。

“UI情结”下的应用分类类别,估计为了实现特定的UI组件(组件不UIKit框架的一部分)通常代表一个估计总数的比率在20%和30%之间收费实施从头Android UI的一部分(图17)。然而,执行时间显示iSpecSnapshot为了自动生成UIKit组件不超过几分钟平均117秒,对当前案例研究(表10)。根据他们的观察,作者可以通过忽视的努力调整CMUI度量UIKit组件的自动生成。此外,参与者画作者的关注,他们应该考虑,在尊重CMUI公式,集成工作,开发人员可以花当整合生成的UI部分和剩余的定制的UI部分。关于当前的案例研究,作者估计的平均工作界面集成的1/4(人日)。

因此,获得UI开发的Android使用一部分iSpecsnapshot超过77%的阈值(图18)。

6.6。研究结论

根据这些实验结果,作者的主要研究问题可以回答他们的研究结论iSpecSnapshot可以极大地帮助Android开发者移植iOS应用程序的任务。一方面,该工具草拟出一份报告能见度使用iOS的框架和Android映射。另一方面,该工具填充功能文档的缺乏将iOS应用程序的功能理解的持久性和商业模式。此外,它允许跟踪导航屏幕之间的流动和详细描述每个屏幕的组件。最后,它加速了开发时间和引导移植项目,同时保留Android开发人员的努力实现从头Android UI的一部分。

6.7。威胁的有效性

在这一节中,作者讨论的有效性威胁进行这个实验研究[39]。

6.7.1。内部效度

女性性功能障碍的准确性的评估文档13组3功能应用程序的分析师提出一个可能的威胁,内部有效性。为了避免这种威胁,作者选择了3个候选人基于他们的技能,在iOS平台,为了能够比较生成的结果iOS应用程序的源代码,作者也进行了仔细检查小组的Android开发人员一个先天的iOS应用程序的所有者。

6.7.2。外部效度

在这项研究中,一个可能威胁到外部效度可能是对象的选择应用。评估过程的第一步的目标是减少这种威胁。在这个初步分析,作者选择了一组不同的应用程序覆盖整个范围的UIKit组件。他们还一直感兴趣的应用程序处理各种功能域(社会、医学、网络等等)。为了延长他们的结果的有效性,其他案例研究被认为是在公测阶段的工具。

7所示。结论和未来的工作

以满足日益增长的需求,移动应用程序移植,新的软件工程技术和逆向工程工具适应移动平台保持基本以帮助开发人员更好地理解、分析和维护移动应用程序。

在本文中,作者提出了iSpecSnapshot,模型驱动逆向工程工具,旨在自动生成的功能规范文档iOS移动应用程序并启动相应的Android UI框架。他们强调MDRE方法,概述了逆向工程的关键步骤:模型发现,语义提取、模型转换和代码生成。进一步,他们暴露iSpecSnapshot作为云服务的技术架构。

与此同时,作者已经修改手机逆向工程领域的一些初步工作。iOS的结果评估,进行本地应用,已确保iSpecSnapshot检测关键信息是一个有用的解决方案为iOS Android手机应用程序移植过程,例如,框架的依赖,SDK平台的映射,活动图,商业模式,屏幕组件(UI元素,事件和动作)。

7.1。未来的工作

有一些研究线路中,该方法可以提高和扩展。当务之急是改善活动图支持动态屏幕转换。这可能最终会通过调整语义提取步骤中,为了检测动态导航描述事件动作的源代码。这当然导致进一步浓缩的语义库,基于iOS移动开发的最佳实践。

其他观点值得追求的是提高覆盖率移动SDK框架之间的映射。事实上,作者期待检查可能之间的映射iPhone SDK和过多的Android开源库。这一点他们希望为full-porting过程是有价值的。

此外,能够港口的前景从iOS、Android作为一个持续的激励其他逆向工程方向。作者将原型逆向工程POC(的概念)UI iOS颤振UI(颤振界面:https://flutter.io)。他们打算遵循相同的MDRE方法,提出了以iOS界面迁移到谷歌的便携式UI工具包,这是众所周知的快速渲染和表达的UI。

附录

答:模型驱动工程(身边)

身边的(40软件工程)是一个增长的概念。它的目标是提高软件开发系统规范中通过提高抽象层次,增加自动化的实现,维护和测试(41,42]。提升的想法通过身边的是使用模型在不同的抽象级别开发系统。身边的方法广泛应用于正向工程(的背景下43),通过适当的模型代码M2C工具专门设计用于将模型转换为代码。

对象管理组织(OMG)将模型描述为“一个系统及其环境的描述或规范在一定目的”(44]。相关的模型系统,显式或隐式映射。它可能代表了软件、硬件、环境、或其他系统的特定领域方面。OMG的框架,即。,MDA (model-driven architecture) [45),区分不同类型的模型(见图19):(我)计算独立模型(CIM)(2)独立于平台的模型(PIM)(3)特定于平台的模型(PSM)(iv)特定于实现的模型(ISM)

CIM系统的观点从计算独立观点,关注环境和系统的要求。它不显示细节结构的系统或系统是如何实现的。在一般情况下,它被称为域模型和假设CIM的主要用户是领域从业者或业务专家。CIM有助于之间的桥梁领域专家(或业务专家)和IT专家(46]。

一个PIM系统的观点从独立于平台的观点。它提供了指定的平台独立性,符合使用许多不同的平台上类似的类型。PIM被定义为一组组件和功能,这是定义独立于任何特定的平台,可以实现在特定于平台的模型(46]。

PSM是一个系统的观点从特定于平台的观点。它结合了PIM的规格和细节,指定系统如何使用特定类型的平台。表示目标平台的PSM包括特定元素(46]。

ISM模型,所有的细节实现目标系统指定的47]。

元模型定义了抽象语法的建模语言,因此,是一种特殊的模式。它可以被描述为所有可能的集合模型的规范表达建模语言。MDA是基于使用的语言来编写元模型称为meta object facility (MOF) (48]。财政部保证模型可以存储在一个MOF-compliant库,解析,转化,呈现为不同的格式包括XMI (XML元数据交换),运输网络,用于生成应用程序代码。

模型转换是一个非常重要的任务在任何模型驱动的方法。事实上,转换确保翻译的操作的一个或多个模型从一个给定的抽象级别的一个或多个其他同一级别的模型(PSM)水平转换:PSM或不同的水平(垂直转换:PIM到PSM)。OMG已经QVT标准(查询视图和转换)转换语言规范(查询/视图/转换或QVT [34]和MOF2Text [49])。QVT标准定义了三种语言转换:操作、关系和核心语言。关系的语言是最相关的50]。

b模型驱动逆向工程(MDRE)

如上所述,Chikofsky和交叉(51),“逆向工程”一词通常被理解为“逆向工程分析的过程是一个主题系统,识别系统组件及其相互关系和创建表示系统的另一种形式或更高层次的抽象。

在软件工程中,逆向工程范式的使用被认为是为了从现有系统中提取各种模型。这些模型有助于分析和理解系统。

在文学、模型驱动逆向工程(MDRE) [52)被指模型驱动工程(身边)方法和技术,它适用于逆向工程挑战。

最近这个话题的文献[53]表明MDRE已经达到了一个高峰最后几年内出版。这主要是由于OMG的努力提供了ADM(架构驱动现代化)工作小组54)与规范元模型用于逆向工程遗留系统的目的。

ADM已经建立了许多关键标准(55)为了支持所有任务主题ADM-based过程。后续的标准(56将治疗等方面分析,可视化,重构,并与转换相关的标准:(我)股(知识发现的元模型)定义了一个元模型,描述了一个应用程序行为的高级视图,结构,和数据。(2)ASTM(抽象语法树元模型)定义了一个元模型表示应用程序的程序水平。ASTM确保语言是建立在KDM元数据交换。此外,它允许分析工具来处理元模型而非特定语言AST。(3)多发性骨髓瘤(结构化的度量元模型)定义了一个元模型,提供指标股,可以描述技术、功能和架构问题。

数据可用性

使用的数据来支持本研究的结果包括在本文中。

的利益冲突

作者宣称没有利益冲突。

确认

这项研究部分由MyAppConverter有限公司温暖谢谢MyAppConverter有限公司由于一些员工,慷慨地与作者共享他们的想法和他们的启蒙运动,曾极大地促成了本文的独创性。

引用

  1. 全球移动应用下载,2018年9月,https://www.statista.com/statistics/271644/worldwidefreeandpaidmobileappstoredownloads/
  2. 苹果应用商店的可用的应用程序数量从2008年7月到2017年1月,2018年9月,https://www.statista.com/statistics/263795/numberofavailableappsintheappleappstore/
  3. 可用的应用程序数量谷歌播放存储从2009年12月到2017年12月,2018年9月,https://www.statista.com/statistics/266210/numberofavailableapplicationsinthegoogleplaystore/
  4. 移动了2019年一季度的新里程碑,2019年6月,https://www.appannie.com/en/insights/marketdata/mobilehitnewmilestonesinq12019/
  5. Fortunato d j·贝纳迪诺,“进步的web应用程序:本机移动应用的另一种选择,”学报2018年13伊比利亚信息系统与技术会议(”),页1 - 6、卡塞雷斯、西班牙,2018年6月。视图:出版商的网站|谷歌学术搜索
  6. j . h . y . b .公园,h . k .火腿,“android,碎片问题”国际会议信息科学和应用程序的程序(ICISA),1 - 2页,韩国水原韩国,2013年6月。视图:谷歌学术搜索
  7. t . Roehm r . Tiarks r . Koschke和w . Maalej专业开发人员理解软件怎么样?“在美国第34软件工程国际会议(ICSE),页255 - 265,IEEE计算机协会,苏黎世瑞士,2012年6月。视图:谷歌学术搜索
  8. h . Muccini,公元弗朗西斯科·p·埃斯波西托,“Softwaretesting移动应用:挑战和未来的研究方向,”学报》第七届国际研讨会的自动化软件测试(AST),页29-53,IEEE计算机协会,苏黎世瑞士,2012年6月。视图:谷歌学术搜索
  9. j . Dehlinger和j·迪克森,”手机应用软件工程:挑战和研究方向,”《软件工程研讨会上移动页29-32 Springer,圣塔莫尼卡,洛杉矶,美国,2011。视图:谷歌学术搜索
  10. ai沃瑟曼,“移动应用程序开发的软件工程问题”学报FSE / SDP研讨会的未来软件工程研究(FoSER10)ACM,页397 - 400年,圣达菲,海里,美国,2010年11月。视图:谷歌学术搜索
  11. m . Janicki m . Katara, t . Paakkonen”障碍和机会在部署移动软件的基于模型的GUI测试:一项调查,“软件测试、验证和可靠性,22卷,不。5,313 - 341年,2012页。视图:出版商的网站|谷歌学术搜索
  12. d .因特网和c·威尔斯”提供一个软件质量测试的移动应用程序框架,”学报》国际会议软件测试、验证和确认(ICST),页431 - 434,IEEE计算机协会,柏林,德国,2011年3月。视图:谷歌学术搜索
  13. s p·米勒,a·c·Tribble m·w·惠伦和m . p . e . Heimdahl”证明应当。”国际期刊《技术转让的软件工具,8卷,不。4 - 5,303 - 319年,2006页。视图:出版商的网站|谷歌学术搜索
  14. p . Tilakaratna和j·拉贾帕克萨,”正向工程的面向对象分析和设计”在软件工程学报马来西亚会议IEEE,页107 - 112年,新山市,马来西亚,2011年12月。视图:出版商的网站|谷歌学术搜索
  15. d .因特网c . Elsemann s Kowalewski和c·威尔斯,“移动应用程序生命周期,逆向工程”学报2011年18日在逆向工程工作会议利默里克,页283 - 292年,爱尔兰,2011年11月。视图:出版商的网站|谷歌学术搜索
  16. m . e . Joorabchi和a . Mesbah“反向工程iOS移动应用程序,”学报》2012年19在逆向工程工作会议加拿大金斯顿,页177 - 186,,2012年10月。视图:出版商的网站|谷歌学术搜索
  17. w·杨·m·r·普拉萨德,t·谢“灰色矩形方法自动GUI-model一代的移动应用程序,”软件工程的基本方法诉Cortellessa和d . Varro Eds。,pp. 250–265, Springer, Berlin, Heidelberg, 2013.视图:出版商的网站|谷歌学术搜索
  18. 萨尔瓦•和s . Zafimiharisoa”模型的移动应用逆向工程勘探策略,”学报2014年ICSEA第九软件工程国际会议上进步不错,页396 - 403年,法国,2014年10月。视图:谷歌学术搜索
  19. i c . Morgado a . Paiva和j·法里亚,“自动移动应用程序的基于模式的测试,”学报》2014年第九届国际会议上的质量信息和通信技术吉马良斯,页294 - 299年,葡萄牙,2014年4月。视图:出版商的网站|谷歌学术搜索
  20. t·a·阮和c . Csallner”与remaui逆向工程移动应用程序的用户界面,”学报2015年IEEE 30日/ ACM自动化软件工程国际会议(ASE)林肯,页248 - 259年,东北,美国,2015年11月。视图:出版商的网站|谷歌学术搜索
  21. k . Lamhaddab和k . Elbaamrani模型驱动逆向工程:图形建模为手机平台,”学报2015年15日智能系统设计与应用国际会议(ISDA)马拉喀什,页392 - 397年,摩洛哥,2015年12月。视图:出版商的网站|谷歌学术搜索
  22. d . Amalfitano a . r . Fasolino Tramontana p, b . d .助教和a . m . Memon”MobiGUITAR:自动移动应用的基于模型的测试,”IEEE软件,32卷,不。5日,53至59页,2015年。视图:出版商的网站|谷歌学术搜索
  23. p . Dugerdil和r . Sako动态分析技术逆向移动应用程序,”软件技术p·洛伦茨,j·卡多佐l . a . Maciaszek和m .杰费里•范•辛德伦Eds。,pp. 250–268, Springer International Publishing, Cham, Switzerland, 2016.视图:出版商的网站|谷歌学术搜索
  24. 中情局Salihu、r·易卜拉欣和A·穆斯塔法”的混合方法逆向工程从android应用程序的GUI模型进行自动测试,”《电信、电子和计算机工程,9卷,不。3,45-49,2017页。视图:谷歌学术搜索
  25. i c . Morgado和a·c·r·Paiva“移动GUI测试,”软件质量日报,26卷,不。4、1553 - 1570年,2018页。视图:出版商的网站|谷歌学术搜索
  26. c·陈,t·苏·g·孟,z,和y . Liu”从UI设计图像到GUI框架:神经机器翻译引导移动GUI实现”学报40软件工程国际会议ICSE 18ACM,页665 - 676年,纽约,纽约,美国,2018年5月- 6月。视图:出版商的网站|谷歌学术搜索
  27. h . Salehinejad j . Baarbe s Sankar j . Barfett e . Colak和s . Valaee“近期复发性神经网络的进步,”2017年,http://arxiv.org/abs/1801.01078视图:谷歌学术搜索
  28. t . Beltramelli“pix2code:生成代码从一个图形用户界面截图,”诉讼的ACM SIGCHI工程研讨会上交互计算Systems-EICS 18页31-36 ACM,纽约,纽约,美国,2018年6月。视图:出版商的网站|谷歌学术搜索
  29. b·戴·费德勒、r . Urtasun和d·林”向多样化和自然图像描述通过条件gan”学报2017年IEEE计算机视觉国际会议(ICCV),第2998 - 2989页,威尼斯,意大利,2017年10月。视图:出版商的网站|谷歌学术搜索
  30. d . Amalfitano诉里奇奥,n . Amatucci诉d·西蒙和a . r . Fasolino”结合自动化GUI开发的android应用程序通过机器学习与捕获和回放,”信息与软件技术卷,105年,第116 - 95页,2019年。视图:出版商的网站|谷歌学术搜索
  31. b . Cornelissen柴德曼A A . van Deursen l·穆南和r . Koschke”系统通过动态分析程序理解的调查,“IEEE软件工程,35卷,不。5,684 - 702年,2009页。视图:出版商的网站|谷歌学术搜索
  32. i c . Morgado“自动移动应用程序的基于模式的测试,”技术。代表,Faculdade Engenharia大学波尔图,2018年11月,http://paginas.fe.up.pt/%7epro11016/files/PhDThesisProposal.pdf视图:谷歌学术搜索
  33. f . Fleurey e·布列塔尼人b . Baudry尼古拉斯,和人类。Jezequel "模型驱动工程软件迁移在大型工业背景下,”模型驱动工程语言和系统(计算机科学课堂讲稿)g .恩格斯,b . Opdyke d·施密特和e . f . Weil, Eds。施普林格,卷。4735年,柏林,德国,2007年。视图:谷歌学术搜索
  34. Kurtev,“QVT的艺术:一个模型转换语言的标准,”应用程序与工业相关图转换军中,a . Schurr m ., a . Zundorf Eds。,pp. 377–393, Springer, Berlin, Germany, 2008.视图:谷歌学术搜索
  35. f . Jouault f . Allilaire, j . Bezivin Kurtev,“ATL:一个模型转换工具,”科学的计算机编程,卷72,不。2008年1 - 2,页31 - 39。视图:出版商的网站|谷歌学术搜索
  36. e . Umuhoza h . Ed-douibi m . Brambilla j·卡伯特和a . Bongio”自动代码生成跨平台,无需多设备移动应用:一些来自一个工业的经验,反思”学报》第三届国际研讨会上移动开发Lifecycle-MobileDeLi 2015页37-44 ACM,纽约,纽约,美国,2015年10月。视图:出版商的网站|谷歌学术搜索
  37. OMG,“OMG MOF模型到文本转换语言,”2018年9月,https://www.omg.org/spec/MOFM2T/1.0/视图:谷歌学术搜索
  38. h . Bruneliee j·卡伯特、g .欺骗和f . Madiot”MoDisco:模型驱动逆向工程框架”,信息与软件技术卷,56号8,1012 - 1032年,2014页。视图:出版商的网站|谷歌学术搜索
  39. c·沃林表示p . Runeson m . Hst m·c·欧胜b . Regnell和a . Wessln软件工程实验斯普林格出版公司,纽约,纽约,美国,2012年。
  40. 美国肯特,“模型驱动工程”集成的正式的方法m·巴特勒,l . Petre和k干枯,Eds。,pp. 286–298, Springer, Berlin, Germany, 2002.视图:谷歌学术搜索
  41. a . van Deursen e·维瑟,j .温暖的“模型驱动的软件进化:一项研究议程,”CSMR车间模型驱动Softw学报》上。另一个星球。)”(功能及,页41-49,阿姆斯特丹,荷兰,2007年3月。视图:谷歌学术搜索
  42. p . Mohagheghi w·吉拉尼,a . Stefanescu m·a·费尔南德斯b . Nordmoen和m . Fritzsche”模型驱动工程帮助哪里?从三个工业案例经验,”软件和系统建模,12卷,不。3、619 - 639年,2013页。视图:出版商的网站|谷歌学术搜索
  43. f . Jouault j . Bezivin m·巴贝罗,“对一个先进的模型驱动工程工具箱”,创新系统和软件工程,5卷,不。1,5 - 12,2009页。视图:出版商的网站|谷歌学术搜索
  44. OMG,“MDA指南修订2.0”,2018年9月,http://www.omg.org/cgi-bin/doc?ormsc/140601视图:谷歌学术搜索
  45. a . Elsawi s Sahibuddin r·易卜拉欣,“模型驱动架构评估当前的文学,”理论和应用信息技术杂志》上卷,79年,第127 - 122页,2015年。视图:谷歌学术搜索
  46. l . Favre“基于mda的逆向工程”逆向工程,a·c·Telea Ed IntechOpen、里耶卡,克罗地亚,2012。视图:出版商的网站|谷歌学术搜索
  47. a .布朗,模型驱动架构:原则和实践,3卷,斯普林格出版社,1 -德国,2004年版。
  48. OMG,“财政部:Meta Object Facility (MOF Tm) 2.0。OMG规范正式/ 161101”,2018年9月,http://www.omg.org/mof视图:谷歌学术搜索
  49. j . Oldevik t . Neple r . Grønmo j . Aagedal a.j。Berre”,对标准化的模型到文本转换,”模型驱动Architecture-Foundations和应用程序哈特曼和d . Kreische Eds。,pp. 239–253, Springer, Berlin, Germany, 2005.视图:谷歌学术搜索
  50. p·史蒂文斯:“双向QVT的模型转换:语义问题和开放的问题,“软件和系统建模,9卷,不。1,7-20,2008页。视图:出版商的网站|谷歌学术搜索
  51. e . j . Chikofsky j . h .交叉,“逆向工程和设计恢复:分类法”,IEEE软件,7卷,不。1 - 17,1990页。视图:出版商的网站|谷歌学术搜索
  52. Rugaber和k . Stirewalt“模型驱动的逆向工程,”IEEE软件,21卷,不。4,45-53,2004页。视图:出版商的网站|谷歌学术搜索
  53. c . Raibulet f . Arcelli丰塔纳,m . Zanoni“模型驱动逆向工程的方法:一个系统的文献回顾,“IEEE访问5卷,第14542 - 14516页,2017年。视图:出版商的网站|谷歌学术搜索
  54. p·纽科姆,“架构驱动现代化(ADM)”12日工作会议在逆向工程学报》(WCRE ' 05)p。237年,宾夕法尼亚州匹兹堡,美国,2005年11月。视图:出版商的网站|谷歌学术搜索
  55. r . Perez-Castillo G.-R。de Guzman, m . Piattini”知识发现metamodel-ISO / IEC 19506标准的遗留系统、现代化”计算机标准和接口,33卷,不。6,519 - 532年,2011页。视图:出版商的网站|谷歌学术搜索
  56. OMG,“架构驱动现代化标准路线图”,2009年9月,http://adm.omg.org/ADMTF%20Roadmap.pdf视图:谷歌学术搜索

版权©2019哈立德Lamhaddab et al。这是一个开放的分布式下文章知识共享归属许可,它允许无限制的使用、分配和复制在任何媒介,提供最初的工作是正确引用。


更多相关文章

PDF 下载引用 引用
下载其他格式更多的
订单打印副本订单
的观点2853年
下载1105年
引用

相关文章

文章奖:2020年杰出的研究贡献,选择由我们的首席编辑。获奖的文章阅读