技术领域
[0001] 本
发明涉及一种基于模型驱动对Android移动应用进行抽象提取交互流模型，使用针对Android平台扩展的IFML对其进行建模。该模型能够屏蔽Android平台各版本间的复杂差异性，以直观的方式展示Android移动应用的整体运行控制流程，开发人员可基于该模型结合不同的Android平台版本进行Android应用开发，也可以很容易地能够将Android移动应用完成从一个版本向另外一个版本的迁移。本发明属于
软件工程，模型驱动工程领域。
背景技术
[0002] 移动应用市场现如今蓬勃发展，发展速度极其迅速，移动终端及其应用彻底地改变了人们的生活方式，移动应用本身呈现出多平台、多版本的态势，具有平台多，版本演化快的特点，如何更好并高效地支持多平台、多版本的开发是一个备受关注的问题。Android是由Google发布，为移动终端打造的开放移动开发平台，短短几年间Android原生系统便从1.1版本发展到目前(2016年5月)的5.1版本，随着市场需求增长和智能终端市场的快速成长，Android系统的更新
迭代速度也会相应加快以更好地适应市场需求，此外，基于Android系统源码进行的二次开发，深度定制改版的移动平台
操作系统也是Android发展的一个显著趋势，因此可见Android系统版本演化之快之繁杂，各版本间的差异性非常复杂，Android移动应用也会随着系统的变更不断地进行更新演化。模型是对具体实现的一种抽象，能够有效地屏蔽各系统版本间的差异性，对一个移动应用抽象出模型并使用适当的
建模语言刻画描述，从而帮助开发人员完成Android移动应用从一个版本向另外一个版本的迁移。
[0003] Android移动应用的开发是基于MVC(模型-视图-
控制器)设计模式，移动应用项目源代码中所有对象也是按照这三类划分为三部分，视图层主要负责应用的可视内容呈现以及提供用户操作的场所；控制器层和视图层建立联系，负责处理视图层中用户的操作，模型层中存放整个应用的数据。
[0004] 移动应用最大的特点就是
可视化和频繁的
人机交互，移动应用是基于UI事件驱动的，整个运行流程主要是基于界面上的事件驱动完成的，在Android系统各版本中都具有这个特点。移动应用的界面中包含了这个应用的整体运行控制流程，应用都由若干界面组成，界面间存在一定的跳转关系，每个界面中有若干可视化控件元素，用户和这些可视化控件元素进行人机交互，由此触发事件，系统完成对事件的监听处理从而完成用户的交互意图，事件的处理或者完成一定的业务逻辑运算，或者触发了界面间的跳转。
[0005] IFML(The Interaction Flow Modeling Language)交互流建模语言，OMG(Object Management Group)制定的用于描述软件应用前端的内容、用户交互以及行为的建模语言。IFML作为OMG标准交互流建模语言，提供了扩展机制，通过扩展IFML使其能够更好地用于描述移动应用的
用户界面及交互行为。IFML建立的交互流模型只能够描述最通用的前端交互流信息，后来对其进行的针对移动平台的扩展，能够用来刻画描述与移动平台相关的模型，移动平台相关的模型能够初步描述移动平台中的通用信息。我们需要进一步对其进行针对Android平台的扩展，从而建立Android平台相关的模型，开发人员基于屏蔽了版本差异的Android平台相关模型，再结合开发时Android版本，完成Android应用的开发，后期随着版本演化，基于模型可以完成从一个版本到另外一个版本的迁移。
发明内容
[0006] 发明目的，针对目前移动应用开发领域具有版本演化快的特点，演化的深度会体现到API层次，甚至造成新老版本之间的API无法兼容的情况，这给程序员的开发实现带来了巨大的挑战。如何能够提供新的技术和方法来适应这种系统平台级别的快速演化，成为学术界和工业界都共同关注的问题。传统软件开发方式对此支持不够，MDE通过划分不同抽象层次的模型能有效地支持版本间的演化和迁移。IFML交互流建模语言是OMG提出的前端交互流建模规范。本发明目的是，针对Android平台扩展了IFML，并基于扩展的IFML对Android应用进行抽象建立交互流模型，屏蔽各Android系统不同版本的复杂差异性，描述Android移动应用的整体运行控制流程，开发人员基于建立的交互流模型，结合实际开发需求及Android具体版本信息，完成Android应用开发。本发明的主要目的还在于基于模型驱动，针对Android平台的
框架特点扩展了IFML建模规范，并基于该扩展提出一种用于Android移动开发进行建模的方法。
[0007] 技术方案：为完成上述目的，本发明采用的方案如下：
[0008] 一种基于IFML的Android开发建模方法，其特征是包括如下步骤：
[0009] 1)当IFML针对移动平台进行扩展，基于移动平台的扩展需要针对Android平台进行扩展，确定并抽象出Android平台应用的整体运行流程；
[0010] 11)确定Android应用中整体运行流程界面数量，界面间跳转关系；
[0011] 12)确定构成整体运行流程每个界面的控件类型；
[0012] 13)确定所述控件是否绑定事件，并确定事件类型；
[0013] 14)确定所述界面间跳转由哪些控件触发事件来完成；
[0014] 2)使用交互流建模语言IFML针对移动平台的扩展，对步骤1)中Android应用整体运行流程进行初步交互流建模；
[0015] 21)对Android应用中整体运行流程的界面，使用扩展了IFML中ViewContainer得到的Screen表示；
[0016] 22)对整体运行流程界面中的控件，使用扩展了IFML中ViewComponent得到的MobileComponent表示；
[0017] 23)对表示整体运行流程界面中的控件的MobileComponent，如果控件上绑定了事件，扩展IFML中Event得到MobileSystemEvent，进一步对MobileSystemEvent扩展得到具体事件类型，比如Click，使用具体事件类型放在MobileComponent元素边界上；
[0018] 24)从整体运行流程界面中的控件的MobileComponent上绑定的事件引出一条Navigation Flow，指向IFML中的Action元素，表示事件触发后进行的业务逻辑，再从Action元素继续引出Navigation Flow，指向目的界面Screen，表示处理完业务逻辑后跳转到哪个界面；
[0019] 3)IFML针对移动平台扩展，对Android应用平台进行进一步扩展，使用针对Android应用平台扩展的IFML，进行面向实现的交互流建模；
[0020] 31)对Android应用中的界面，使用IFML扩展了的Screen得到的Activity元素表示；
[0021] 32)对界面Activity中的控件，使用针对Android应用平台中基于MobileComponent元素扩展得到的各具体Android控件来表示，包括Button，TextView；
[0022] 33)所述控件上绑定了事件，使用针对Android的基于MobileSystemEvent元素扩展得到的各具体Android事件来表示，包括Cl ick，Touch，LongPress；
[0023] 34)从所述控件上绑定的事件引出一条Navigation Flow，指向表示事件处理业务逻辑的Action元素，从Aciton元素引出Navigation Flow指向目的Activity；
[0024] 35)界面Activity元素间跳转关系已经使用扩展了的IFML表示出来，Activity间进行跳转时如果需要对涉及了跳转的源Activity和目的Activity进行生命周期方法的编码，在源Activity和目的Activity的Navigation Flow间添加表示源Activity和目的Activity的UML类图；
[0025] 4)对步骤3)中的Android应用平台的交互流模型，结合项目需求和Android版本信息，完成应用开发；
[0026] 41)对模型中界面Activity，在项目中添加一个Java类，继承自Android中界面Activity类；
[0027] 42)对界面中的Android控件，在项目布局资源目录中添加各界面的布局文件，即在界面布局文件中添加Android控件；
[0028] 43)步骤41)中的Java类，在生命周期方法onCreate()中完成界面加载和初始化设置等编码工作，获取控件，为控件绑定事件，完成事件处理业务逻辑，添加界面跳转代码。
[0029] 有益效果：
[0030] 本发明基于Android移动应用的IFML扩展模型，结合不同Android平台版本的信息，清晰直观地完成Android应用的开发，也很容易能够完成从一个Android版本向另外一个版本的演化迁移。
[0031] 本发明使用标准IFML对Android应用的整体运行流程中各种元素建立交互流模型，这个模型是粗粒度并且是高度抽象的，对标准IFML针对移动平台进行扩展，使用扩展后的IFML再对模型进行细化，这样得到的模型便具有了移动平台的概念，体现出移动平台的特点。这个模型中包含的元素信息不足够
支撑Android开发，因此要进一步针对Android平台进行IFML的扩展，扩展后对Android应用运行流程进行描述刻画，这一步得到的模型信息能够帮助Android开发人员进行应用的开发。通过对移动应用进行抽象建立模型的方法，不仅可以用来屏蔽Android系统不同版本间的差异性，同样能够用来屏蔽不同移动平台间的差异性，从而帮助完成从一个移动平台模型向另外一个移动平台模型进行转换，再根据模型进行代码生成。
附图说明
[0032] 图1所示为针对Android平台扩展的IFML元模型；
[0033] 图2所示为一个Android应用实例使用IFML建立的模型；
[0034] 图3所示为同一个Android应用实例使用针对移动平台扩展的IFML建立的模型；
[0035] 图4所示为针对Android平台扩展的IFML为Android应用实例建立的交互流模型。
具体实施方式
[0036] 下面对本发明做进一步详细说明。
[0037] 首先Android开发人员确定将要开发的Android应用由多少界面组成以及界面间的跳转关系，确定每个界面中包括了哪些Android控件，哪些控件需要绑定事件并且进行事件处理，事件处理完后是否进行界面间的跳转。对Android应用的整体运行流程确定后，初步地使用标准IFML对Android应用的整体运行流程中各种元素建立交互流模型，这个模型是粗粒度并且是高度抽象的，对标准IFML针对移动平台进行扩展，使用扩展后的IFML再对模型进行细化，这样得到的模型便具有了移动平台的概念，体现出移动平台的特点。这个模型中包含的元素信息不足够支撑Android开发，因此要进一步针对Android平台进行IFML的扩展，扩展后对Android应用运行流程进行描述刻画，这一步得到的模型信息能够帮助Android开发人员进行应用的开发。
[0038] 1)确定并抽象出Android应用的整体运行流程。
[0039] Android应用是UI和事件驱动的，Android开发人员在开发一个Android应用时，首先要确定应用的整体运行流程，对Android应用进行抽象理解可以得知Android应用以界面为单位，在各界面间进行跳转完成应用的运行流程，每个界面中放置合适的可视化控件元素呈现给用户，用户可以与界面中控件元素进行交互，应用会处理用户的交互操作完成功能、实现效果，交互过程中可能会触发界面的跳转。
[0040] Android开发人员都知道Android应用是使用面向对象语言Java进行开发，基于模型-控制器-视图的MVC架构模式进行设计，应用中的任何对象，归根结底都属于模型对象、视图对象以及控制器对象中的一种。视图对象用于呈现可视化内容给用户，并且和用户进行交互，响应用户的输入，但是视图对象不能够处理用户交互引发的事件，必须将视图对象触发的各类事件信息发送给控制器对象，委托控制器对象去处理各类事件。
[0041] Android中的控制器层是由Activity负责完成，每一个Activity都对应一个Java文件。Activity的功能主要是：1.加载其关联的视图并且呈现给用户；2.获取其关联的视图中每个控件，并负责处理控件响应用户与控件交互的操作。应用中每个页面都有相关联的Activity，Activity具体是由Java编程语言结合Android API实现，Activity作为Android中的四大组件之一，Android系统为其提供了7个生命周期方法，应用的状态发生变化时，Android系统会自动调用Activity相应的生命周期方法，开发人员可以在各个生命周期方法体中完成业务逻辑编码便可以在生命周期方法被系统调用时实现预期的功能或效果。
[0042] 移动应用中视图和控制器密不可分，Activity负责加载与其关联的视图，如果应用需要控件和用户进行交互，便会在Activity中对该控件设置事件处理方法，Android对事件的处理机制都是相同的：监听事件源，为事件源绑定一个事件处理方法，事件发生则相应的事件处理方法完成事件处理。此外，事件可能会引起界面间的跳转。Android应用是UI和事件驱动的，开发人员将为提供给用户进行交互的可视化控件绑定事件，系统会捕获用户交互产生的事件并对其进行处理。
[0043] Android应用的所有界面，界面中的控件，控件绑定事件及事件处理，界面间跳转关系，这些信息就能够清晰地表达出Android应用的整体运行流程，这个步骤得到的运行控制流程和具体Android版本是无关的，屏蔽了各版本的复杂差异性。
[0044] 2)使用IFML针对移动平台的扩展，对步骤1中Android应用整体运行流程进行初步交互流建模。
[0045] IFML是通用的交互流建模语言，使用标准没有经过扩展的IFML可以对步骤1中的运行控制流程进行建模，但该模型仅停留在最原始抽象的交互流层级，无法体现出移动平台的特点，也不能详细描述应用的信息，对开发人员的帮助不大。标准的IFML主要使用了以下元素进行交互流建模：ViewContainer表示一个视图容器，可用来容纳可视化元素；ViewComponent表示可以存放于ViewContainer中的可视化元素，对用户可见并且用户可以与其进行交互；Event表示交互流中的事件，通常附着在ViewComponent上表示该ViewComponent会产生事件，与Event紧密联系在一起的是Action和Navigation Flow，Action表示事件产生后会进行的业务逻辑，Navigation Flow表示了交互流的跳转方向。当使用标准IFML对Android应用整体运行流程进行交互流建模时，IFML中ViewContainer表示Android应用中的界面，界面中的Android控件使用ViewComponent表示，控件如果需要绑定事件，则在ViewComponent上添加Event，从Event引出Navigation Flow，如果事件处理方法需要完成业务逻辑，则Navigation Flow和一个Action进行关联，否则指向目的ViewContainer。图1所示为一个Android应用实例使用IFML建立的模型，该模型比较抽象而且粗粒度地描述了Android应用的界面间跳转关系，界面中有多少构成元素，部分构成元素绑定了事件，事件或者触发了界面的跳转，或者完成一部分业务逻辑。
[0046] 对IFML进行针对移动平台的扩展，使得IFML能够进行与移动平台相关的建模，扩展重点主要在具有移动平台显著特点的控件和事件类型方面，移动平台的事件类型主要分为了三大类：1.移动终端所特有的
传感器引发的事件，比如晃动，
加速器等；2.用户使用移动终端的外设引发的事件，比如摄像头拍照，麦克
风等；3.用户直接操作界面上控件引发的事件，比如点击，滑动等，可以基于Event扩展出MobileSystemEvent，基于ViewContainer扩展了Screen，这样表述比较有移动平台特点，Screen表示移动应用的界面，ViewComponent扩展为具有移动平台相关概念的控件MobileComponent，表示这是移动平台的控件。使用针对移动平台进行扩展的IFML对Android应用进行交互流建模时，Android应用的界面使用Screen表示，界面中的Android控件使用MobileComponent表示，控件上绑定的事件则根据具体事件类型来表示，比如单击Click。图2所示为同一个Android应用实例使用针对移动平台扩展的IFML建立的模型，这部分的扩展能够描述有移动平台概念的信息。
[0047] 3)针对IFML的移动平台扩展进一步针对Android平台进行扩展，使用针对Android扩展的IFML进行面向实现的交互流建模。
[0048] 步骤2)中的交互流模型能够描述出移动应用相关的运行交互流过程，我们进一步扩展针对移动平台的IFML使得能够建立Android平台相关的交互流模型。对比Android各版本中的控件类型和事件类型，发现控件和事件类型基本上没有改变，因此我们可以扩展IFML中的MobileComponent，在IFML中扩充Android的控件，比如Button，TextView等。MobileComponent和Android控件的关系类似于面向对象语言中父类和子类的关系，当开发人员不确定某个界面中需要使用哪个控件时，完全可以先使用MobileComponent来代替，等最终开发确定时再用具体Android控件替换MobileComponent。扩展MobileSystemEvent添加Android中的事件类型比如Click，Touch等。Android中Activity和视图层是紧密联系的，视图层的业务逻辑都交由控制器Activity处理，因此我们将Screen扩展为Activity。在步骤1)中我们提到，当Activity进行切换，应用状态发生改变时，Android系统会自动调用提供给Activity的7个生命周期方法，开发人员可以在生命周期方法体中完成业务逻辑编码便能够在生命周期方法被系统调用时实现预期功能。步骤2中的模型无法描述这部分与Android平台紧密相关的信息，为此我们需要添加新元素刻画这部分信息。IFML是可以结合UML(Unified Modeling Language)建模语言完成应用中不能直接通过界面或交互流来表述的部分。我们选择使用UML中的类图和协作图作为新元素，步骤1中提到Activity对应Java文件，完全可以使用UML类图和协作图来在IFML中表示Activity中的生命周期方法。同样地，由于Android控件绑定的事件引起的事件处理方法，也可以使用UML类图和协作图的新元素表述。
[0049] 经过针对Android平台的IFML扩展后，我们可以这样来描述Android应用的整体运行控制流程：使用Activity表示应用中的界面，在Activity中添加Android控件，给控件绑定Android事件，事件通过Navigation Flow和Action联系起来，Action部分由开发人员具体去实现，完成Action后，Navigation Flow要么指向原来的界面表示实现了功能、完成效果，要么指向Activity，如果指向其他的Activity，则需要添加Activity生命周期方法，生命周期方法体中的内容交由开发人员决定是否添加。通过这些步骤，Android应用的整体交互运行流程便建模完成。图3所示为针对Android平台扩展的IFML为Android应用实例建立的交互流模型。
[0050] 4)基于步骤3)中的Android交互流模型，结合Android具体版本，如有需要只对Android控件类型进行调整，开发人员对照模型可以直接在Android项目源代码中完成应用的所有界面，界面中控件，界面对应的Activity，控件绑定的事件，界面如何跳转及跳转关系。Android开发人员看到模型中的Activity，为此Activity在项目中添加一个Java类，看到模型中Activity里的控件可以在Activity关联的界面中进行添加，模型中控件上绑定了事件及进行了事件处理，直接可以在Activity中捕获控件并对控件进行事件绑定。
