英语原文共 29 页
基于模型驱动的Android和iOS移动应用程序开发
摘要：
快速增长的应用程序和用户使得移动应用程序的开发成为软件工程中最有前途的领域之一。由于上市时间短、平台不同和新兴技术快速，移动应用程序开发面临典型的挑战，而模型驱动开发(MDD)可以提供帮助。本文介绍了一种面向Android和iOS中原生应用的MDD建模语言和基础架构。我们的方法允许在不同抽象级别上进行灵活的应用程序开发:对标准应用程序元素(如标准数据管理)进行紧凑的建模，并对单个元素进行越来越详细的建模，以涵盖特定的行为等。此外，支持一种变异性建模，可以开发具有变异性的移动应用程序。我们通过几个应用程序演示了我们的MDD方法，包括一个会议应用程序、一个具有增强现实功能的博物馆指南和一个智能插头。
关键词：
模型驱动开发 移动应用程序 Android IOS
1、简介：
模型驱动开发的基础设施对于加速软件应用程序的开发具有很大的潜力。在建模特定于应用程序的数据结构、流程和布局时，可以生成可运行的软件系统。因此，MDD不关注技术细节，而是将软件开发提升到更高的抽象级别。此外，代码和用户界面的标准化程度也有所提高。因此，高质量的MDD基础设施可以大大缩短上市时间。
除了常见的软件生产问题之外，移动应用程序开发还面临一些特定的挑战。受欢迎的平台在硬件和软件方面差异很大，通常使用寿命短，创新周期短，变化很大。市场通常要求应用程序必须可用于多个平台，这就需要进行非常耗时和成本密集型的多平台开发。现有的解决方案试图通过使用基于web的方法来绕过这个问题，这些方法常常难以访问手机的技术设备，而且与本地应用程序相比，使用这些设备的效率更低。此外，基于web的解决方案要求应用程序或多或少地永久在线，这可能会造成相当大的成本和有限的可用性。MDD底层平台在加速开发过程方面具有很高的潜力和提供更容易适应新开发的特点。
虽然已经有一些方法可以实现移动应用程序的模型驱动开发，例如MD2[30]，但是我们的贡献在设计和语言用途上有很大的不同。我们的方法侧重于具有基于角色的变体的数据驱动应用程序(参见图1)。例如，用于管理会议中的会话、演讲和演讲者的会议应用程序区分了两个角色:提供所有相关数据的会议经理和只阅读数据的会议参与者。我们的方法将用于设计具有所有行为、数据结构和用户界面的应用程序模型与用于不同角色的一个或多个提供者模型区分开来。每个提供者模型都包含关于数据、行为和用户界面的特定于角色的信息。整个方法包含三个用户角色:创建应用程序的应用程序开发人员、提供可配置应用程序的可选用户和使用移动应用程序的强制终端用户。
模型驱动开发的核心和灵魂是特定于领域的建模语言。我们的语言涵盖了移动软件应用程序的三个方面:它的数据实体和关系，它的行为包括数据管理、传感器的访问、其他应用程序的使用等，以及它的用户界面。通常，模型驱动开发意味着在更高的抽象级别上对软件进行建模，并生成在更低的抽象级别上实现软件的代码。这就引出了模型的抽象程度问题。在设计建模语言时，我们遵循这样的原则:模型尽可能抽象，需要时尽可能具体。这意味着:对标准解决方案进行非常抽象的建模，而对更具体的解决方案进行更详细的建模。例如，由通常的CRUD功能(使用创建、读取、更新和删除操作)进行的数据管理可以由预定义的模型元素类型建模，而应用程序特定的行为则在通常的控制结构级别上指定。
图1
(1)单一部署 (2)和提供者模型运行时解释 (3)的基于角色的移动应用程序生成
为了有效地使用特定于领域的建模语言，我们提供了一个基于eclipse的工具环境，其中包括一个图形化编辑器，用于数据、行为和用户界面模型的三个不同视图，以及Android[9,21,38]和iOS[7,24]的两个代码生成器。在开发这两个代码生成器之前，我们研究了Android和iOS中移动应用程序的设计原则，发现了很多共性。因此，生成的应用程序获得与所选平台无关的相同的总体架构。
我们在各种示例应用程序中展示了MDD基础设施的潜力和局限性。包括一个会议的程序,指导参与者通过会议、博物馆的应用呈现数学从娱乐的角度来看,一个图片字典帮助移民学习德语在工作环境中,电视提醒应用程序通知最新的广播时间表,以及SmartPlug,应用控制外部硬件设备。
本文是[48,50]的扩展版本。,介绍了我们的方法的核心思想,另外包括一个详细的域分析移动应用的功能模型,更详细的描述MDD基础设施、代码生成不仅Android还iOS,和一个示例应用程序来说明方法的讨论。
本文的结构如下:在下一节中，我们将通过一个特征模型来给出移动应用程序所考虑的领域。在第3节中，我们介绍了我们的语言设计，并按照[33]中提供的领域特定语言的设计指导原则对其进行了讨论。第4节介绍了开发的MDD基础设施，包括一个图形化模型编辑器和两个面向Android和iOS的代码生成器。第5节介绍了几个示例应用程序。最后，第六章和第七章讨论了相关工作并对本文进行了总结。
2、移动应用领域
移动应用程序的开发目的多种多样，从单纯的娱乐到严肃的商业应用程序。虽然主要关注面向数据的业务应用程序，但娱乐和教育元素、传感器和外部硬件访问可能会丰富这些应用程序。
需求捕获过程。首先，我们考虑将参考应用程序作为会议应用程序的要求(参见第5.1节中的屏幕截图)。一个会议应用程序可以在与会者访问科学会议期间支持他们。该应用程序应该是打印会议程序的数字版本，但支持额外的用例来搜索和书签事件，以及在会场中导航。因此，这样的应用程序包含关于地点、可用房间、计划的会议、提交的论文和演讲、演讲者以及提交论文的作者的信息。会议参加者可浏览会议概览，并可查阅有关所提交文件及讲者的详细资料。由于上述数据大多是静态的，除了参与者保存的最喜欢的会话之外，应用程序应该带有一组初始数据，并能够永久离线工作。参与者可以通过在参与之前从(并行)会议中选择事件来创建他们的个人时间表。会议应用程序将向已安装的日历应用程序添加选定的事件，用户可以在下一次事件发生之前轻松地检查(或接收通知)。会议应用程序还可以包含多媒体文件。例如，一个场地可以在不同的楼层有不同的房间，或者有不同的建筑。要找到这些位置，参与者需要一个与应用程序集成的地图。最后，会议应用程序应该有一个布局，符合特定于会议的外观和感觉，并为智能手机(如较小的显示尺寸)进行优化。如前所述，考虑的应用程序应该支持基于角色的应用程序可变性。会议组织者还可以提供用户。会议组织者可以使用会议应用程序的不同实例化来创建初始数据集(房间、会议、论文、作者等)。因此，它们有额外的用例，提供对上述实体的写访问。组织者版本可能使用不同的样式模型，因为这个用户组更喜欢使用不同的设备，比如带有外部键盘的平板电脑/电视棒，以便更舒适地输入数据。
除了来自面向数据的应用程序的这些要求外，还有进一步的要求，这些要求将在稍后介绍案例研究时重新讨论(见5.2f节):移动设备可以提供对许多传感器的访问，这些传感器可以由移动应用程序访问。一个特殊的例子是使用内置摄像头识别对象，并使用不同类型的虚拟对象增强实时图像，这称为增强现实(AR)[29]。这对于工业应用(例如，在发出工作指示的情况下)以及教育和旅游部门都是有用的。最后，移动应用程序通常不是自包含的系统，而是与不同类型的硬件和软件交互。因此，我们的应用程序应该能够通过标准接口(如WiFi、蓝牙)访问外部硬件。
图2
功能模型。基于给定的分类法[15,26,34]对与移动应用程序开发特别相关的属性进行分类，我们提出了图2中所示的特征模型，这是结合了我们在域分析中发现的现有工作和属性的结果。
总之，我们正朝着模型驱动的方向发展，即针对不同平台(Android、iOS)开发原生移动应用程序，这些平台支持针对不同用户和系统上下文的移动应用程序运行时配置(运行时模型)。根据模型驱动方法，应用程序开发人员通过在设计时创建应用程序模型(设计模型)来指定移动应用程序。应用程序开发人员可以使用预定义的模型元素(例如，CRUD)或组合不同的建模元素来创建更详细的功能，这些功能更符合需求。这旨在通过随后的细化快速构建原型。由于在设计时对设备特性(如屏幕大小)或应用程序主机设备和目标用户组的设备类型缺乏了解，所以可以在运行时灵活配置应用程序。不同的用户角色(例如，提供者和最终用户)创建关于功能、用户界面和数据的移动应用程序配置。否则，将从设计模型派生一个默认的运行时配置。我们专注于导航、教育和生产领域，而不是游戏和通信应用。生成的应用程序还支持其他服务的集成(例如，使用Web服务调用其他应用程序)。考虑到这些应用程序应该在运行时根据用户和系统上下文进行调整，它们的体系结构必须支持用户界面和进程的动态实例化。正如Degrandsart等人所描述的，不同的运行时模型支持这种上下文感知的建模方法。最后，离线工作的需求导致了本地数据管理。为了以动态的方式支持不同的网络条件(作为系统上下文的一部分)，生成的app架构支持混合数据管理。特别是，该应用程序可以根据不断变化的网络环境离线和在线工作。
在我们的整个项目工作中，上面描述的会议应用程序被用作开发MDD基础设施的参考应用程序。首先，我们对这些应用程序进行了分析和优化，以便在原型重新实现中近似出最佳实践解决方案。然后，我们使用它们来测试开发的MDD基础设施，方法是对它们进行建模，并将生成的应用程序与原始的[49]进行比较。由于篇幅的限制，我们选择了一个较小的示例作为本文的演示对象。这个例子展示了我们方法的一些重要特性。
图3
运行的例子。智能手机的核心应用之一是管理个人联系人的电话簿。下面，我们将展示一个用于添加、编辑和搜索联系人信息的简单电话簿应用程序。图3显示了电话本应用程序的选定截图，这些截图已经由我们的基础设施生成。小箭头表示显示的视图的顺序。第一个子图(图3a)显示了主菜单，其中包含一个标准的CRUD流程(管理人员)，用于创建、编辑和删除人员。此任务的标准行为和用户界面是由一个简单的CRUD流程生成的(参见图9b)，该流程是应用程序建模师以前创建的。与使用标准的CRUD流程不同，app modeler可以为单个创建流程创建更多的单独流程(参见图9c)，以满足进一步的需求(例如，单独的导航和样式)。图3b从用户的角度显示了各个CRUD进程。这些变量可以在运行时实例化。此外，app会考虑用户位置上下文来查找用户当前位置附近的联系人(图3c)。将电话号码与手机应用程序连接起来，当用户选择一个电话号码时，它就自动开始拨号(图3d)。
图4
3、语言设计
MDD基础结构的核心是领域特定的建模语言。在下面的文章中，我们将首先介绍引导我们使用移动应用程序建模语言的主要设计决策。然后，我们给出了定义元模型的方法，其中包括选择限制模型结构的良好格式规则。为了演示该语言，我们展示了一个简单的电话簿应用程序模型的选定部分。最后，根据领域特定语言的设计准则讨论了所提出的建模语言。
3.1 设计方案：
由于我们的领域分析，我们希望通过提供用户来支持可灵活配置的移动应用程序的生成。这一需求通过区分两种模型反映在我们的建模方法中:指定应用程序的所有潜在功能的应用程序模型和定义实际应用程序变体的提供者模型。在图4中，说明了这种通用的建模方法。虽然应用程序模型是用于生成Android和iOS项目(1)部署之后(2),提供程序模型是解释生成的Android和iOS应用程序(3)。因此提供者模型可以被用来改变功能而无需重新部署应用程序提供者模型可以以两种方式执行:通常情况下,提供者模型是在运行时解释,因为它不甚至没有存在在构建时。但也可以在构建时使用它，方法是将其添加到生成的应用程序项目的资源中。然后在构建过程中考虑它。
建模语言的一般方法是基于组件:一个应用程序模型由一个数据模型定义底层的类结构,一个GUI模型包含页面的定义和图形用户界面风格设置,和一个流程模型定义了应用程序的行为设施形式的流程和任务。数据和GUI模型没有直接的链接。但是流程模型通过引用这两个子模型的元素来依赖于这两个子模型(参见图4)。GUI模型只包含页面的抽象定义(参见图7)，而不包含详细的布局描述。数据模型间接定义了用户界面的结构和默认布局。(图20显示了自动生成的用户界面[42]的示例。)
提供程序模型包含一个对象模型，该对象模型将对象结构定义为数据模型的实例。为自定义图形用户界面定义显式样式和页面的样式模型。最后，它包含一个流程实例模型，该模型选择感兴趣的流程，并为它们提供实际参数，以指定预期的应用程序变体的自定义行为。与应用程序模型类似，对象和样式模型彼此独立，但由流程实例模型使用。
对于建模语言的设计，我们遵循总体原则:尽可能抽象地建模应用程序，并根据需要对其进行具体建模。这意味着可以对应用程序的标准设计和行为进行相当抽象的建模。这对于快速构建移动应用程序原型非常有用。应用程序的设计和行为越个性化，在应用程序模型中需要给出的细节就越多。特别是，所有可能在预期应用程序中使用的特殊样式、页面和进程都必须在应用程序模型中定义。由于提供者模型应该由领域专家定义，所以它们已经完全是特定于领域的，并且遵循预定义的app模型。提供者模型支持软件产品线的开发，因为一组公共特性是共享的，并且支持一些基于角色的可变性。考虑的应用程序变体的差异由不同的提供者模型分别建模。
我们尽可能重用现有的建模语言。例如，这适用于数据结构的定义。数据建模已经成熟，并且得到了Eclipse建模框架(EMF)[46]的良好支持。因此，这里也使用它来定义应用程序的数据模型。代码生成器的特定信息(到目前为止很少)由注释给出。
图5
GUI模型指定视图沿着他们的目的,例如,查看和编辑对
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
