英语原文共 17 页，剩余内容已隐藏，支付完成后下载完整资料
允许角色驱动变体的移动应用程序的模型驱动开发[1]
Steffen Vaupel1, Gabriele Taentzer1, Jan Peer Harries1, Raphael Stroh1, Renacute;e Gerlach2, Michael Guckert2
- Philipps-Universitauml;t Marburg, Germany
{svaupel,taentzer,harries,strohraphael}@informatik.uni-marburg.de
- KITE - Kompetenzzentrum fuuml;r Informationstechnologie,
Technische Hochschule Mittelhessen, Germany
{rene.gerlach,michael.guckert}@mnd.thm.de
摘要:越来越多的应用程序和用户使移动应用程序的开发成为软件工程中最有前途的领域之一。由于上市时间短，平台不同，新兴技术快速发展，移动应用程序开发面临着模型驱动开发可以提供帮助的典型挑战。我们为Android应用程序的模型驱动开发（MDD）提供了一种建模语言和基础架构，支持根据用户角色规范不同的应用程序变体。例如，提供用户可以使用一个app变体连续配置和修改自定义内容，而最终用户应该使用其变体中提供的内容。我们的方法允许在不同的抽象级别上进行灵活的应用程序开发：标准应用程序元素的紧凑建模，单个元素的详细建模以及针对特定自定义需求的单独提供者模型。我们在两个应用程序中展示了我们的MDD方法：由会议组织者为参与者配置电话簿管理和会议指南。
关键词：模型驱动开发·移动应用·Android
1.介绍
模型驱动开发的基础架构具有加速软件应用程序开发的巨大潜力。在仅对特定于应用程序的数据结构，过程和布局进行建模时，可以生成可运行的软件系统。因此，MDD并不专注于技术细节，而是将软件开发提升到更高的抽象级别。此外，增加了代码以及用户界面中的标准化量。高质量的MDD基础设施可以大大缩短产品的上市时间。移动应用程序开发面临着普通软件生产问题带来的几大特定挑战。流行的平台在硬件和软件架构方面存在很大差异，通常表现出较短的生命周期和具有重大变化的创新周期。此外，市场不允许将应用程序供应限制在单一平台上的策略。因此，多平台应用程序开发是一个非常耗费时间和成本的必需品。它要求必须从头开始或多或少地为每个值得关注的目标平台构建应用程序。可用的解决方案试图通过使用基于Web 的方法来解决这个问题，与本机应用相比，在限制对手机技术设备的访问和对设备的使用效率方面经常遇到困难。此外，基于网络的解决方案要求应用程序或多或少永久保持在线状态，这可能会导致相当大的成本和可用性受限。
虽然已经有一些模型驱动的移动应用程序开发方法，但我们在语言的设计和目的上的贡献有很大差异。它允许根据信条进行非常灵活的应用程序设计：“模型尽可能抽象，并根据需要具体化。”数据，行为和用户界面可以在适当的抽象级别上建模，这意味着行为和UI设计不使用标准解决方案时仅在更详细的情况下进行建模。将模型分为app模型和一个或多个提供者模型，我们实现了两个阶段生成和部署过程的可能性。虽然app模型定义了基本数据结构，行为和布局，但这些基本元素可以在提供者模型中用于定义特定的自定义需求。因此，提供者模型是app模型的实例，而app模型又是定义整体建模语言的元模型的实例。这种方法非常适合我们在此考虑的应用程序类型：虽然应用程序模型是由软件开发人员开发的，但提供者模型通常由不是软件专家的客户构建。这种应用程序的典型示例是博物馆指南。这里，app模型包含有关博物馆中的对象，类别，事件和游览的信息。它指定了搜索博物馆对象，阅读有关它们的详细信息以及跟踪行程的可能行为。该模型还提供常规页面样式。客户可以添加一个或多个提供者模型，其包含关于当前呈现的对象的信息以及在语义上对组对象的其他类别。还可以添加特定功能，例如阅读接下来四周的即将发生的事件，阅读有关顶级对象的详细信息，以及下一次展览的特殊页面样式。更改提供者模型不会导致重新部署应用程序。它只需要使修改后的实例模型可用。它集成到应用程序模型中，提供具有最新数据和适配功能的刷新应用程序。生成的应用程序可以脱机工作，没有重大限制。
本文的结构如下：在下一节中，介绍了所考虑的应用程序类型。特别是，我们解释了我们考虑的移动应用程序的类型。在第3节中，我们介绍了我们的语言设计，并按照典型的设计指南进行讨论。第4节介绍了开发的MDD基础设施为Android操作系统编写的几个模型编辑器和代码生成器。第5节报告案例。最后，第6节和第7节讨论了相关工作并总结了本文。
2.移动应用程序域
移动应用程序的开发用途非常广泛，从娱乐到严肃的商业应用程序。我们正在开发一种商业应用程序，为选定的域提供基本的通用构建块。领域专家可以使用和改进这些构建块，以根据其特定需求对其进行自定义。然后，完全自定义的应用程序可供最终用户使用。让我们考虑在与我们项目的行业合作伙伴 advenco合作时出现的具体情况：key2guide是一个无需编程即可配置的多媒体指南。它的典型应用在于旅游业，在这里旅游者可以通过景点进行引导，例如博物馆，展览，城镇或地区。景物（例如在博物馆中展示的绘画，工艺品和雕塑）通过丰富的信息列出和解释。此外，物体可以在其他结构中进行分类和排序，即通过展览引导游客的旅行。正如读者所期望的那样，这样的应用程序非常注重数据。这些数据通常会随时间变化。因此，典型的要求是提供域专家（例如博物馆管理员或旅游经理）可以定期刷新数据的可能性。此外，在一个地区四处走动可能会导致互联网连接受限。因此，网络应用程序不是首选解决方案。相比之下，应用程序通常应脱机运行，但可以不时下载新的提供商信息。
称为key2operate的advenco的第二个产品，允许定义手动业务流程，并将移动设备支持集成到整体生产流程中。例如，为了检查生产工厂的机器，工人获得必须按顺序执行的检查请求的列表。这样的执行可能包括关键数据的收集（例如压力或温度）。可以通过扫描条形码或读取RFID芯片来识别机器。控制值可以由工人手动输入。此外，可以采取执行的开始和结束时间。完成检查请求后，应用程序将显示下一个要执行的请求，并将工作人员引导到相应的机器。同样，需要一个可由用户在此处配置定义其预期业务流程的生产经理的应用程序。随着生产过程现在变得非常灵活，具有移动设备支持的手动过程也必须不断适应。key2operate允许在不重新部署的情况下进行此类流程调整。但是，流程定义非常简单，因为它们仅支持简单的数据结构。这两个应用程序都可以与基于Web的后端内容管理系统配合使用，以维护最终用户可用的配置。
总结一下：我们正朝着支持用户特定变体配置的移动商务应用的模型驱动开发迈进。在这在这种情况下，通常有几种用户，例如提供自定义内容的提供者，以及使用所有提供信息的已配置应用程序的最终用户。当然，可以更精细地构造提供者和最终用户的组，以便定义不同的角色。例如，一个城镇的旅游指南可以覆盖城镇的景点以及几个博物馆和展览。指导信息通常由具有不同角色的几个提供者给出。该镇的旅游经理只允许在类别城镇编辑有关景点的信息，而历史博物馆的管理员可以编辑博物馆中有关物品的所有信息。应开发特定于角色的应用程序变体。
在整个项目工作中，上述移动应用程序（key2guide和key2operate）被用作开发MDD基础架构的参考应用程序。最初，我们分析并优化了这些应用程序，以便在原型重新实现中接近最佳实践解决方案。此后，我们使用它们对已开发的基础架构进行建模，并将生成的应用程序与原始应用程序进行比较。由于篇幅限制，我们在本文中选择了一个较小的例子作为演示对象。此示例显示了我们方法的许多重要功能：
示例（简单的电话簿应用程序）。智能手机的核心应用之一是可以管理联系人的电话簿。在下文中，我们将展示一个简单的电话簿应用程序，用于添加，编辑和搜索有关人员的联系信息。此外，电话号码连接到电话应用程序，以便选择电话号码开始拨号。图1显示了已由我们的基础架构生成的手机应用程序的选定屏幕截图。小箭头表示显示的视图顺序。在下一节中，我们将讨论底层模型的选定部分。
3.语言设计
模型驱动开发的基础架构的核心是建模语言。在下文中，我们首先介绍主要的设计决策，这些决策指导我们使用移动应用程序的建模语言。此后，我们提出了定义的元模型，包括限制允许的模型结构的所有主要良构规则。为了说明该语言，我们展示了一个简单的电话簿应用程序模型的选定部分。最后，针对特定领域语言的设计指南讨论了所提出的建模语言。
3.1设计决策
由于我们的域名分析，我们希望支持生成可以通过提供用户灵活配置的移动应用程序。这一主要要求通过区分两种模型反映在我们的建模方法中：指定应用程序的所有潜在设施的应用程序模型和定义的提供程序模型
图1.电话簿应用程序的屏幕截图
实际的应用程序。在图2中，说明了这种通用建模方法。虽然app模型用于生成之后部署的Android项目（1）（2），但提供者模型由生成的Android应用程序（3）解释，即可以在不重新部署应用程序的情况下使用。实例模型可以通过两种方式执行：通常这将在运行时完成，因为实例模型在构建时不存在，或者可以在构建时完成，方法是将实例模型添加到生成的android的资源中项目。
建模语言的一般方法是基于组件的：app模型由底层类结构的数据模型，包含页面定义和图形用户界面样式设置的GUI模型以及定义应用程序的行为设施，以流程和任务的形式定义。数据和GUI模型彼此独立，但过程模型依赖于它们。提供者模型包含将对象结构定义为数据模型中类结构的实例的对象模型，为各个图形用户界面定义显式样式和页面的样式模型，以及选择特定进程并为其提供实际参数的流程实例模型指定预期应用程序的实际行为。与app模型类似，对象和样式模型彼此独立，但由流程实例模型使用。
图2.建模方法
对于建模语言的设计，我们遵循以下信条：“尽可能抽象，并根据需要具体化。”这意味着应用程序的标准设计和行为可以非常抽象地建模。预期应用程序的设计和行为越多，应用程序模型中就必须提供更多细节。特别是，必须在应用程序模型中定义可能在预期应用程序中使用的所有特殊样式，页面和进程。由于提供者模型应由应用专家定义，因此它们已完全针对特定领域并遵循预定义的应用模型。提供者模型支持软件产品线的开发，即共享一组共同特征并支持一些基于角色的可变性。所考虑的应用程序的差异由不同的提供者模型单独建模。
我们尽可能地重用现有的建模语言，这些语言适用于数据结构的定义。数据建模已经成熟，并得到了Eclipse Modeling Framework（EMF）[22]的良好支持。因此，它也用于定义应用程序的数据模型。代码生成器的具体信息（现在很少）由注释给出。
GUI模型根据其目的指定视图，例如查看和编辑对象，从列表中搜索对象并显示它们，进行登录以及从集合中选择用例。GUI模型通常不用于指定UI组件的固有层次结构，如在丰富的布局编辑器中完成，如Interface Builder [20]， Android Common XML Editor [12]和Android Studio [25]。但是，可以逐步细化模型以在生成的应用程序中获得更多特异性。样式设置是独立于视图指定的，并遵循相同的设计思想，即使用的默认外观越多，模型就越抽象。
活动和服务的设计类似，即可以使用不同类型的流程，包括CRUD功能（创建对象，读取所有对象，更新或编辑对象，删除对象），包括搜索，选择流程等作为调用GUI组件，操作和进程。众所周知的库概念可以涵盖更具体的目的，即基本语言通过语言组件扩展，用于不同的目的，如LabView [10]所做。为了支持移动平台的安全和权限概念，流程模型包括与平台无关的权限级别。权限概念是细粒度的（即在单个任务的级别上），然而像Android这样的平台仅支持粗粒度权限（即在应用程序级别上）。另一个与安全相关的功能是用户特定的进程实例化。潜在地，可以通过受限制的流程实例模型禁用应用程序的功能。
3.2语言定义
在介绍了我们的建模语言的主要设计决策之后，我们现在专注于它的元模型。它是在EMF的基础上定义的，由三个分离的Ecore模型组成，这些模型捆绑在一个资源集中。虽然数据模型是由最初的Ecore模型定义的，但已经定义了两个新的Ecore模型来模拟移动应用程序的行为和用户界面。
给定Ecore的数据模型，它配备了特定于域的语义。数据模型不仅用于生成底层对象访问，还影响用户界面上的数据表示。例如，子对象导致对象的
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[439489]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
