苏ICP备112451047180号-6
多平台智能手机应用的模型驱动设计
摘要
为了确定营业收益，智能手机应用的开发者们应该支持所有那些瓜分市场的主流平台，因此提高市场占有率的同时也意味着开发成本的提高。为了解决这个难题，这篇文章提出了一种模型驱动设计流程去开发一个应用，这个应用可以自动转换为在主流平台上可以运行的版本。这个方法基于代码生成，不需要支持其他不同的智能手机平台的额外的库或者进程。我们介绍一个UML2外廓以描述其应用元素于目标平台的独立性；应用的行为被模型化为一个固定状态的设备，同时使用类和对象模型化图形用户接口。转换规则的集合被定义为获取平台依赖的特性，然后是真实的代码。这种方法已经通过在Android和Windows平台创建应用并对比在相应版本上获取到的源码与传统写入的源码的方法证实。
关键词：UML；PIM；PSM；Android；Windows；状态表
一 介绍
电信技术的革命为移动手机创造了一个巨大的市场并且受此市场驱动每天都有成百上千个移动应用被开发出来。智能手机建立在移动计算平台上，故而比之传统的手机具有更多高级计算的能力和连通性。
智能手机应用的开发是为资源有限的设备开发软件并在特定操作系统如Android,Windows Phone,iPhone iOS,和Nokia Symbian运行的过程。同时，每个平台使用不同的编程语言，比如Android的Java，iPhone的Objective-C，还有一些稍微不同的开发流程。
因此，智能手机应用开发的主要限制是给一个平台提供的应用不能在另一个平台中运行且开发者须为每个主流平台提供相应版本的应用，故而增加了开发成本。为了解决这个问题，作者为移动应用支持共同操作性和轻便性提出了一个广泛中间件结构。这个中间件是一个位于操作系统和用户应用之间的软件层。在运行时，这个中间件把独立于平台的应用操作转换为平台特有的副本，这个方法的劣势是运行这个中间件会额外消耗设备资源（比如CPU时间，内存和电源电量）。其他方面如使用一个对应用开发者提供标准接口的库（每个平台具体版本对应的库），会使开发更此外，额外的设备资源会被用来在运行时把应用的响应转换为本地响应。最终，可以开发一个网站应用来提高其在所有可用浏览器设备上的便利性。这主要的缺点在于忽略了目前不可能直接通过移动设备硬件特征开发的现实，以及在网页上普遍实现相应用户接口的困难。
模型驱动设计和平台无关模型提供了一个合理的解决方案去模型化与目标设备无关的应用并自动移植到不同的平台中。
这个工作的主要贡献是一个为开发与具体平台无关的智能手机应用的模型驱动设计方法论。从主流智能移动平台的分析，我们介绍一个UML2外廓去描述与目标平台无关的应用元素；这种应用的行为被模型化一个固定状态的设备，同时使用类和对象模型化图形用户接口。转换规则的集合被定义为获取平台依赖的特性,和两个不同平台的代码。
这篇文章的组织如下。第二节描述大多数智能手机平台的传统应用开发流程。第三节描述提出的开发多平台应用的方法论。第四节介绍为平台无关模型设计的UML2外廓。第五节展示Android和Windows Phone的转换规则。第六节则在现实生活中的应用上阐述试验的可行性。第七节会给出结论。
二 传统开发
如果智能手机应用开发者想拥有更多的用户，他们开发的应用必须支持市场上更多流行的操作系统，比如谷歌的Android,苹果的iPhone,诺基亚的Symbian,微软的Windows Phone或者其他。传统的开发流程在图1中展示。第一步集中在需求上，故而是平台无关的，虽然编码，测试，在具体的硬件/软件平台部署会产生不同的流程分支。考虑到第二步会消耗相当一段时间，对不同平台的支持会直接影响上市时间和成本。
一个智能手机应用包括结构方面（比如模型和库的内联，图形用户接口的结构化）和运行方面（比如事件响应和应用具体的计算）。
在以下的文字中我们会在提出的UML2的架构基础和设计方法论上突出一系列开发平台的相似与不同。
A.Android平台
Android是一个为移动设备例如智能和平板电脑定制的基于Linux的操作系统，并且由以Google为首的开放手机联盟开发。Android软件平台包括基于Linux的内核，负责通信的中间件，以及一些核心的应用，比如网页浏览器和文件管理器。开发者可以自由地下载软件开发工具包，包括编译器，调试器，和在智能集成开发环境中为了更高效工作的Eclipse插件。开发工具包也提供基于ARM的移动设备模拟器。另一方面，应用也可以直接运行在通过USB线连接在开发者机器上的物理设备上。
就运行方面而言，编程语言为Java，其类库文件会绑定到一些系统组件（通信中间件，设备相机，音频，传感器等）。Android使用Dalvik虚拟机运行即时编译出的十六进制码（Dalvik可执行的），这些字节码通常由Java编译得出。每个应用都拥有自己的Dalvik虚拟机以保护系统不被恶意代码攻击。一个初学这个开发平台的好主意是《Android - A Programmer Guide》。Android应用的主要组件是Activity（活动），表现为一个单独的用户界面。一个活动可以存在三个基本状态：
继续（重新开始）：活动在前台显示并拥有用户焦点；
暂停：其他活动在前台显示并且拥有用户焦点，不过当前活动依旧在执行状态；
停止：当前活动完全被其他活动代替。
整个活动生命周期如图二所示。如果一个活动被暂停或停止，系统就可以调用其finish()方法将之内存中移除，或者直接结束此进程。
就结构方面而言，应用由开发者自定义的类的集合与XML资源文件描述的GUI组成。Android开发工具包编译代码，同时将数据和资源文件一起打包，存为后缀为.apk的档案文件。
B.Windows Phone平台
在2010年微软发布特别为触屏设备而做的WP7操作系统。微软，像谷歌一样，提供一个软件开发包并允许开发者去设计，编译，高度和部署一天。这个开发包有Windows Phone的模拟器，以及一个模拟Windows Phone设备的桌面应用。这个模拟器提供一个虚拟开发环境，可以在没有硬件设备的条件下进行调试和测试。
就运行方面而言，Windows Phone应用代码基于.Net Framework和C#语言。WP7主要组件为Page（页面），描述一个单独的用户界面。页面的生命周期和图二中的类似。
就结构方面而言，GUI通过基于XML语言的可扩展应用程序标语言（XAML）编写。GUI依赖于名为Sliverlight的库文件，此库文件提供与微软推出的用户界面框架相似的代码模型，以及智能的多媒体，图形，动画，和中间活动的一个单独的运行开发环境。在Windows Phone的Silverlight应用中，用户接口在XAML中定义并由.Net Framework的子集进行编程。其资源表和Android的大不相同，且其中只包括图片，字符或者在应用包中的泛型文件。
C.iPhone平台
iOS（iPhone OS在2012年六月之前）是仅可在苹果硬件设备上运行的移动操作系统。其提供的开发包仅能在Mac iOS操作系统中使用。其应用使用叫做Object-c的面向对象语言。其图形界面布局被分开描述，其模式可以通过Android，Windows Phone看到。
D.平台对比
在每个平台中，应用开发都可以分为结构层面和运行层面。忽略运行状态，用户交互是非常相似的。因为屏幕尺寸的限制，图形交互界面被设计成一个页面的队列；每个页面都包括展示信息或响应用户动作的图形组件（比如按钮，单选框，列表）；用户动作可以对相同的页面或其他页面产生影响；一个前面定义的按钮会在前面的页面显示使用。在GUI组件上的动作会通过不同编程语言例如Android中的Java语言，WP7的C#语言和iPhone中的Object-C语言传递。
忽略结构层面，那么所有平台中的应用代码，都是类的集合，GUI界面，也都是由XML语言编写的文件，尽管在不同平台中有不同的格式。
这样的分析启发了一种模型驱动设计方法，平台无关的元模型可能用于开发之中：
GUI作为页面集合包含应用图形组件
应用的演变由页面代替
然后由平台的不同之处就会产生一些规则，如代码所使用的语言和XML的格式。这种方法会在下一节解释。在以下的文字中将通过依赖平台的副本理解页面就是屏幕界面这个概念。
三 提出的方法论
图三展示了应用模型驱动设计方法去开发智能手机应用的方法论。这个流程从一个平台无关的方面，阐释了应用的结构层面，GUI和实现应用逻辑的类，以及运行方面，在屏幕之间的转换管理，用户响应，系统事件。这些元素组成PIM（平台无关模型）。转换规则包括允许从PIM移动到PSM，即一个不同于所有智能手机平台的模型，其代码结构和运行都有一定的区别；另一个方面而言，GUI布局也有区别。转换规则因为有转换工具可以实现而被格式化。最张，这种工具必须可以生成应用代码（类，方法签名，代码块），于是就能避免写入重复的代码。
这样的流程考虑到了扩展性，因为其组件可能会在其他的代码或模式中被第二层或第三层集成。在第二层中额外的库可以被加入到类集合中，和XML GUI资源可以加入到GUI布局一样成为应用结构中的一部分。在第三层中，额外的代码可以在底层代码中被重复利用。
这种流程适用于开发大多数由许多屏幕，一系列组件，且按一定顺序执行用户动作任务组成的应用。这样的方法很容易扩展到平板应用上。其他一些要求高级图形或自定义组件例如游戏等的应用，则因为他们自己的本身特有的属性不在此处讨论。
四 平台无关模型
第一步是定义一个元模型去描述平台无关模型。我们决定采用整体的UML元模型并使用一个剖面图详细说明提供的类，接口及其他必须器件。这是必须做出的选择因为PIM（平台无关模型）不只是一个应用结构的描述，也是一个开发者可以在类似一个英武的UML设计中集成其他类与方法的基本模型。
平台无关模型的UML预定义包提供以下元素：
一个组件类的列表，每个类都能描述一个在所有智能手机平台下可以找到的组件。所有类继承于抽象类Widget，这个类拥有描述屏幕定位的属性集合。开发者们可以扩展这个类去创建自定义元件。
一个类Screen,描述在GUI中一个单独的屏幕
Menu和Submenu类。菜单，事实上，不属于组件，因为他们不能在屏幕上随意显示，不过可以在系统中进行直接管理。
一个可在UML元模型的Transition应用的模板ScreenTransition。
一个可以描述用户定义数据类型的清单。这对绑定特殊值和其属性和有用。
图四列出了整个UML外廓。
下一节讨论两个UML图表的使用，每个图表都构成了在模型中描述应用结构和运行层面的基本元素。
A.类图表
类图表定义智能手机应用的结构。许多描述图形用户接口的基本元素的类，比如screen,widgets和menu。其他类则确定关于应用的信息（标题，权限，和版本）和抽象的设备信息。
每个screen类，都继承自抽象类Screen，是必须添加进模型中的。以下是应用屏幕的属性：
widgets集成所有组件组成GUI（图形用户接口）
orientation确定屏幕方向
fullScreen确定是否覆盖系统菜单并占据整个屏幕显示
layout定义屏幕中组件的布局。线性布局会按一条线摆放组件，而相对布局则按与其他组件或屏幕的相对位置摆放组件。
menu则为当前屏幕中Menu的实例，表现为一个菜单与其子菜单。
Application类中则集成了一些通用的信息，资源的列表以便应用的访问。设备资源在每个平台中变得相当标准，原因如下：
个人信息管理，类似短信，联系人，日历等信息
网络连接，协议栈，例如IP或Bluetooth
设备相机，集成相机允许用户拍照和录制视频
外置内存，额外的内存可提高设备存储容量
电话：户外和室内呼叫
B.状态表
定义好应用的结构之后，我们就需要描述其运行状态。在智能手机应用中，运行状态主要由GUI（图形用户接口）中的用户交互和传感器（例如方向仪）的动作事件响应来表现。一般的智能手机应用由屏幕的集合组成，用户使用GUI控制屏幕的切换。这种在两个屏幕之间的转换之所以会发生是因为有如下的事件响应：
1，组件被点击或触摸。用户可与当前屏幕的组件进行交互。每个组件都可以响应用户的“触摸”动作
2，用户按下一个特殊的设备按钮，如“Home”或“Back”按钮。几乎所有智能手机平台都有这两个按钮：前者使当前应用退到幕后并显示系统主屏幕，后者则退回到前一个屏幕显示。iPhone是一个特例，因为他只有一个Back按钮不过这个按钮通常可在GUI中自行定义功能并实现。
3，屏幕菜单的点击或触摸
4，特定类方法的调用（回调）可准确地在系统事件中实现这样的转换（比如低电量警告或来电提醒）
这些典型的运行状态可使用状态表描述，这样我们就可以通过平台无关的方式来观察应用的变化。图5展示了一个由三个屏幕组成的应用运行状态变化的例子。每次转换都会报告一个事件（例如标签1代表一个按钮响应事件），最终可实现状态之间的转换（标签2）和动作（标签3）。
第五节，平台特定模型
模型转换代表模型驱动设计的核心。转换由一系列布置资源元素到一个或多个特定目标模型的规则组成，并且存在三条规则：易处理，增加的连贯性和双向性。下一节的主要目的就是这些规则的定义，以提出这种转换，并在转换工具上实现他们。
为了使这些规则更准确，简洁，易懂，我们介绍一下下列集合，定义和标记法：
泛化联系是指一种UML联系即一个特定的类A和泛型类B。也就是说，B泛化了A，而A特殊化了B。
接口创造指接口由类C创建了接口I，这是一个在类构造器和接口之间实现联系的UML特殊类型。
实例规格，是指一个描述类C的实例的类图表。实例说明使用“槽”来显示对象的属性。每个槽都对应着一个属性或特征，且可能包含实体的一个值。
依赖关系，指当两个实例I1和I2都声明后，在UML中相互之间形成供应者与客户端的关系，供应者提供某些东西给客户端，而客户端在某种程度上并不完整，因为他在语义和结构上是依赖于供应者的。
组件，都为平台无关中的类。
标记法X用于指代一个类属性或XML标签属性
这些规则在UML元模型中起作用（泛化联系，实例说明，依赖关系，组件，标记法）；他们使用如循环的结构，并可将PIM元素部署到PSM中。
A.状态表转换
下列转换规则是Android和Windows Phone平台共有的：
复制所有在新的PSM状态表中的状态，转换和初始伪结点状态。
每个在屏幕转换中从状态Q1到Q2的转换运行后，活动也会随之在PSM状态表中存下副本。
在资源中部署相应字符类型的标签值。
B.平台无关模型到Android平台特定模型的转换
下一子章节将主要讲述实现平台无关模型（PIM）到Android平台特定模型（PSM）的转换的实现且在技术报告中完成对这种转换规则的定义。第1到第7条规则，在章节V－B1中写出，实现了类图表的转换和产生新的类图表，以及Android的功能清单文件Manifest和资源文件String.xml。
这种部署是必要的，因为在PIM（平台无关模型）中被标记的值往往指的是实例规格定义的元素，而不再是PSM中所描述的那样，因为对象图表已经转换为XML的布局文件了。忽略布局到不同屏幕的适应性，Android很显然控制着所有必要的，建立在实际屏幕分辨率基础上的DP单元。通过这种方法，可以保证GUI能够以正确合适的分辨率显示在屏幕上。也因此组件的协作可以从PIM（平台无关模型）中直接复制而不使用任何转换。
1，结构转换
1）初始化：创建一个新的类图表并应用到Android平台特定模型的UML外廓中。
2）概况类的部署：部署一个PIM（平台无关模型）的类到具体的Android平台中
3）资源权限部署：部署PIM（平台无关模型）资源权限到具体的Android平台中
4）结构部署：添加PhoneApplicationPage（应用页面）,ContentControl（内容控制）类到类图表中
5) 接口实现：在每个类似于W类的实例I，如W为一个列表箱，如果在实例S和实例I之间存在依赖关系，S为P类的实例，P类继承自Screen，那么类P必须实现相应的接口，OnItemClickListener（选项点击事件监听器）
6）资源文件：创建String.xml文件，其中包含应用所用到的字符资源
7）功能清单文件：使PIM对象图表中的类的实例可以在应用中实现
C.PIM平台无关模型到WindowsPhone平台特定模型的转换
结构转换规则与上一节中的Android转换很相似。
通常来说，许多转换规则可能因为平台的不同而不同，即使他们转换的东西是相同的。依赖于目标平台，资源元素的子集（比如结构元素）可能会由一条规则或多条规则转换，这是由于目标平台不同的结构描述（XML文件，Java/C#文件）。这个问题在于如何获取一个特定目标元素的信息。同理，其他转换也可通过此法实现转换（结构转换，GUI布局转换行装）。举个例子，接口创建规则（Android平台）可以创建一个在PSM中的接口实现其依赖关系，就像OnItemClickListener接口可以在一些声明了接口的类中使用。这个规范在WindowsPhone中是不需要的，因为其中的事件控制由XAML管理。
D.代码生成
模型驱动设计的最后一步是每个平台特定模型应用代码的生成。生成的代码包括结构和运行两个方面。代码一般是类文件结构，包括构造器，接口实现，以及方法签名，这些几乎都能用UML模型工具去描述。运行方面则必须实现GUI的初始化和状态表的转换，这种转换是和用户在GUI中的交互联系在一起的。因此，代码生成过程是建立在PSM类图表和UML状态表的基础上的，并且可由UML模型工具进行操作。
六 试验可行性
这一节讲述一个简单应用的平台无关模型。其中的转换和代码生成将会被应用，并与由Android和WindowsPhone平台开发的相同的应用进行结构上的对比。由于篇幅有限，实现的细节会放在技术报告的第六章。
这个简单的应用名字叫做MapNavigator（地图导航），用于景点旅游。它可以通过设备相机阅读二维码，将其标签与预先下载的数字地图建立联系并检索相应的信息。
应用结构功能主要如下，用户可以自行浏览：
从内存或外置内存中选择地图(ChooseMap)
浏览地图并得到相应景点(NavigateMap)
通过相机扫描二维码(AcquireQRCode)
浏览景点列表(TagList)
阅读景点信息(TagInfo)
编辑应用设置偏好(Preferences)
类图表如图6所示，每个显示屏幕的类都继承自Screen类。
下面将讲述从PIM到Android-PSM的转换。
只看第4条规则（结构部署），图7展示了Android下的类图表，有7个类，每个类都继承自Activity类，并实现了一些接口。
只看第6条规则（资源文件），图8给出了包括Android下组件信息生成的文件。注意手动写入的代码，唯一不同的是其入口标准化的格式（[activityName]_[widgetName]_text）。
只看GUI的布局，图9所示的两个并列的图显示部分Welcome界面的信息，左边是转换时可自动获取的XML代码，右边是手动写入的代码。Welcome界面给出了个图标列表，用户可通过触摸图标来完成相应任务。这样手动开发的Android组件名为ImageButton，一个可触摸的图片（PIM并不支持）。因此，在PIM到PSM的转换中，这个组件被分成两块使用（ImageView,Button）。
只看生成的代码（附录C），以下是一些代码片段：
代码块C。1.ANDROID资源文件R.java一个将应用中所有资源（组件，布局，菜单，字符，图片）信息都集成在一起的文件，并给每个资源一个数字常数。这个文件也可以手动编辑添加另外的资源，不过要避免和已分配的常数重复。
代码块C。2.Welcome自动生成的Java文件可以和C。3中手动写入的版本对比。其中主要的区别在于许多方法和变量需要手动添加进类中。事实上，为了控制组件的触摸事件响应，代码会自动生成一个后缀为Click的私有方法对Activity中所有的组件进行事件驱动。这个方法的正确调用方式是用一个switch选择语句去控制相应的方法OnClick()。此外，每个构成活动的组件，都要在活动中声明自己的私有变量。这个变量提供了一个组件的指针（引用），并在活动中初始化。手动开发的文件更为简洁，因为可以使用更少的变量去控制可以驱动触摸事件的私有方法onClick()。
代码块C。4.TagList自动生成的Java文件可以和C，5中手动写入的版本进行对比。在这个文件中我们可以分析ListBox组件生成的代码。每个在活动中的ListBox组件，都有对应的后缀为onItemClick的私有方法。可以通过switch语句调用相应的onItemClick事件去驱动相应的组件。这是必须的，因为代码实现了OnItemClickListener接口，所以只能实现此接口才能控制事件响应。在手动写入的文件中，如果只有一个ListBox组件，那么开发者很有可能忽略这个事件驱动方法。
测试过的代码给出了很多有趣的例子。在其他例子中，自动生成的代码和手动开发的代码保持了一致。最后，代码块6展示了NavigateMap自动自成的代码。这个活动实现了一个菜单和Back按钮，点击Back可重新退回到Welcom界面。
七 结论
我们提出了模型驱动设计方法以解决多平台智能手机应用的问题。这个方法是建立在代码生成的基础上的故而不需要支持智能手机平台的额外库或进程。为了实现这个目标，我们分析了市场上主要的智能手机平台和其开发环境。分析中主要强调了在不同的平台和开发环境之间找到共同点。UML2外廓已经展示了平台无关的定义。其中描述界面的GUI布局的类与状态的图表，和应用之间的转换。然后两个特定平台模型PIM和PSM又分别展示了在Android和WindowsPhone之间的转换规则。这个方法论已经通过在两个平台中创建一个应用并且对比用传统方式编写的代码证实了。未来的工作将考虑其他可嵌入GUI的系统（比如平板和工业控制台）以便达到节省资源的目的。
摘要
为了确定营业收益，智能手机应用的开发者们应该支持所有那些瓜分市场的主流平台，因此提高市场占有率的同时也意味着开发成本的提高。为了解决这个难题，这篇文章提出了一种模型驱动设计流程去开发一个应用，这个应用可以自动转换为在主流平台上可以运行的版本。这个方法基于代码生成，不需要支持其他不同的智能手机平台的额外的库或者进程。我们介绍一个UML2外廓以描述其应用元素于目标平台的独立性；应用的行为被模型化为一个固定状态的设备，同时使用类和对象模型化图形用户接口。转换规则的集合被定义为获取平台依赖的特性，然后是真实的代码。这种方法已经通过在Android和Windows平台创建应用并对比在相应版本上获取到的源码与传统写入的源码的方法证实。
关键词：UML；PIM；PSM；Android；Windows；状态表
一 介绍
电信技术的革命为移动手机创造了一个巨大的市场并且受此市场驱动每天都有成百上千个移动应用被开发出来。智能手机建立在移动计算平台上，故而比之传统的手机具有更多高级计算的能力和连通性。
智能手机应用的开发是为资源有限的设备开发软件并在特定操作系统如Android,Windows Phone,iPhone iOS,和Nokia Symbian运行的过程。同时，每个平台使用不同的编程语言，比如Android的Java，iPhone的Objective-C，还有一些稍微不同的开发流程。
因此，智能手机应用开发的主要限制是给一个平台提供的应用不能在另一个平台中运行且开发者须为每个主流平台提供相应版本的应用，故而增加了开发成本。为了解决这个问题，作者为移动应用支持共同操作性和轻便性提出了一个广泛中间件结构。这个中间件是一个位于操作系统和用户应用之间的软件层。在运行时，这个中间件把独立于平台的应用操作转换为平台特有的副本，这个方法的劣势是运行这个中间件会额外消耗设备资源（比如CPU时间，内存和电源电量）。其他方面如使用一个对应用开发者提供标准接口的库（每个平台具体版本对应的库），会使开发更此外，额外的设备资源会被用来在运行时把应用的响应转换为本地响应。最终，可以开发一个网站应用来提高其在所有可用浏览器设备上的便利性。这主要的缺点在于忽略了目前不可能直接通过移动设备硬件特征开发的现实，以及在网页上普遍实现相应用户接口的困难。
模型驱动设计和平台无关模型提供了一个合理的解决方案去模型化与目标设备无关的应用并自动移植到不同的平台中。
这个工作的主要贡献是一个为开发与具体平台无关的智能手机应用的模型驱动设计方法论。从主流智能移动平台的分析，我们介绍一个UML2外廓去描述与目标平台无关的应用元素；这种应用的行为被模型化一个固定状态的设备，同时使用类和对象模型化图形用户接口。转换规则的集合被定义为获取平台依赖的特性,和两个不同平台的代码。
这篇文章的组织如下。第二节描述大多数智能手机平台的传统应用开发流程。第三节描述提出的开发多平台应用的方法论。第四节介绍为平台无关模型设计的UML2外廓。第五节展示Android和Windows Phone的转换规则。第六节则在现实生活中的应用上阐述试验的可行性。第七节会给出结论。
二 传统开发
如果智能手机应用开发者想拥有更多的用户，他们开发的应用必须支持市场上更多流行的操作系统，比如谷歌的Android,苹果的iPhone,诺基亚的Symbian,微软的Windows Phone或者其他。传统的开发流程在图1中展示。第一步集中在需求上，故而是平台无关的，虽然编码，测试，在具体的硬件/软件平台部署会产生不同的流程分支。考虑到第二步会消耗相当一段时间，对不同平台的支持会直接影响上市时间和成本。
一个智能手机应用包括结构方面（比如模型和库的内联，图形用户接口的结构化）和运行方面（比如事件响应和应用具体的计算）。
在以下的文字中我们会在提出的UML2的架构基础和设计方法论上突出一系列开发平台的相似与不同。
A.Android平台
Android是一个为移动设备例如智能和平板电脑定制的基于Linux的操作系统，并且由以Google为首的开放手机联盟开发。Android软件平台包括基于Linux的内核，负责通信的中间件，以及一些核心的应用，比如网页浏览器和文件管理器。开发者可以自由地下载软件开发工具包，包括编译器，调试器，和在智能集成开发环境中为了更高效工作的Eclipse插件。开发工具包也提供基于ARM的移动设备模拟器。另一方面，应用也可以直接运行在通过USB线连接在开发者机器上的物理设备上。
就运行方面而言，编程语言为Java，其类库文件会绑定到一些系统组件（通信中间件，设备相机，音频，传感器等）。Android使用Dalvik虚拟机运行即时编译出的十六进制码（Dalvik可执行的），这些字节码通常由Java编译得出。每个应用都拥有自己的Dalvik虚拟机以保护系统不被恶意代码攻击。一个初学这个开发平台的好主意是《Android - A Programmer Guide》。Android应用的主要组件是Activity（活动），表现为一个单独的用户界面。一个活动可以存在三个基本状态：
继续（重新开始）：活动在前台显示并拥有用户焦点；
暂停：其他活动在前台显示并且拥有用户焦点，不过当前活动依旧在执行状态；
停止：当前活动完全被其他活动代替。
整个活动生命周期如图二所示。如果一个活动被暂停或停止，系统就可以调用其finish()方法将之内存中移除，或者直接结束此进程。
就结构方面而言，应用由开发者自定义的类的集合与XML资源文件描述的GUI组成。Android开发工具包编译代码，同时将数据和资源文件一起打包，存为后缀为.apk的档案文件。
B.Windows Phone平台
在2010年微软发布特别为触屏设备而做的WP7操作系统。微软，像谷歌一样，提供一个软件开发包并允许开发者去设计，编译，高度和部署一天。这个开发包有Windows Phone的模拟器，以及一个模拟Windows Phone设备的桌面应用。这个模拟器提供一个虚拟开发环境，可以在没有硬件设备的条件下进行调试和测试。
就运行方面而言，Windows Phone应用代码基于.Net Framework和C#语言。WP7主要组件为Page（页面），描述一个单独的用户界面。页面的生命周期和图二中的类似。
就结构方面而言，GUI通过基于XML语言的可扩展应用程序标语言（XAML）编写。GUI依赖于名为Sliverlight的库文件，此库文件提供与微软推出的用户界面框架相似的代码模型，以及智能的多媒体，图形，动画，和中间活动的一个单独的运行开发环境。在Windows Phone的Silverlight应用中，用户接口在XAML中定义并由.Net Framework的子集进行编程。其资源表和Android的大不相同，且其中只包括图片，字符或者在应用包中的泛型文件。
C.iPhone平台
iOS（iPhone OS在2012年六月之前）是仅可在苹果硬件设备上运行的移动操作系统。其提供的开发包仅能在Mac iOS操作系统中使用。其应用使用叫做Object-c的面向对象语言。其图形界面布局被分开描述，其模式可以通过Android，Windows Phone看到。
D.平台对比
在每个平台中，应用开发都可以分为结构层面和运行层面。忽略运行状态，用户交互是非常相似的。因为屏幕尺寸的限制，图形交互界面被设计成一个页面的队列；每个页面都包括展示信息或响应用户动作的图形组件（比如按钮，单选框，列表）；用户动作可以对相同的页面或其他页面产生影响；一个前面定义的按钮会在前面的页面显示使用。在GUI组件上的动作会通过不同编程语言例如Android中的Java语言，WP7的C#语言和iPhone中的Object-C语言传递。
忽略结构层面，那么所有平台中的应用代码，都是类的集合，GUI界面，也都是由XML语言编写的文件，尽管在不同平台中有不同的格式。
这样的分析启发了一种模型驱动设计方法，平台无关的元模型可能用于开发之中：
GUI作为页面集合包含应用图形组件
应用的演变由页面代替
然后由平台的不同之处就会产生一些规则，如代码所使用的语言和XML的格式。这种方法会在下一节解释。在以下的文字中将通过依赖平台的副本理解页面就是屏幕界面这个概念。
三 提出的方法论
图三展示了应用模型驱动设计方法去开发智能手机应用的方法论。这个流程从一个平台无关的方面，阐释了应用的结构层面，GUI和实现应用逻辑的类，以及运行方面，在屏幕之间的转换管理，用户响应，系统事件。这些元素组成PIM（平台无关模型）。转换规则包括允许从PIM移动到PSM，即一个不同于所有智能手机平台的模型，其代码结构和运行都有一定的区别；另一个方面而言，GUI布局也有区别。转换规则因为有转换工具可以实现而被格式化。最张，这种工具必须可以生成应用代码（类，方法签名，代码块），于是就能避免写入重复的代码。
这样的流程考虑到了扩展性，因为其组件可能会在其他的代码或模式中被第二层或第三层集成。在第二层中额外的库可以被加入到类集合中，和XML GUI资源可以加入到GUI布局一样成为应用结构中的一部分。在第三层中，额外的代码可以在底层代码中被重复利用。
这种流程适用于开发大多数由许多屏幕，一系列组件，且按一定顺序执行用户动作任务组成的应用。这样的方法很容易扩展到平板应用上。其他一些要求高级图形或自定义组件例如游戏等的应用，则因为他们自己的本身特有的属性不在此处讨论。
四 平台无关模型
第一步是定义一个元模型去描述平台无关模型。我们决定采用整体的UML元模型并使用一个剖面图详细说明提供的类，接口及其他必须器件。这是必须做出的选择因为PIM（平台无关模型）不只是一个应用结构的描述，也是一个开发者可以在类似一个英武的UML设计中集成其他类与方法的基本模型。
平台无关模型的UML预定义包提供以下元素：
一个组件类的列表，每个类都能描述一个在所有智能手机平台下可以找到的组件。所有类继承于抽象类Widget，这个类拥有描述屏幕定位的属性集合。开发者们可以扩展这个类去创建自定义元件。
一个类Screen,描述在GUI中一个单独的屏幕
Menu和Submenu类。菜单，事实上，不属于组件，因为他们不能在屏幕上随意显示，不过可以在系统中进行直接管理。
一个可在UML元模型的Transition应用的模板ScreenTransition。
一个可以描述用户定义数据类型的清单。这对绑定特殊值和其属性和有用。
图四列出了整个UML外廓。
下一节讨论两个UML图表的使用，每个图表都构成了在模型中描述应用结构和运行层面的基本元素。
A.类图表
类图表定义智能手机应用的结构。许多描述图形用户接口的基本元素的类，比如screen,widgets和menu。其他类则确定关于应用的信息（标题，权限，和版本）和抽象的设备信息。
每个screen类，都继承自抽象类Screen，是必须添加进模型中的。以下是应用屏幕的属性：
widgets集成所有组件组成GUI（图形用户接口）
orientation确定屏幕方向
fullScreen确定是否覆盖系统菜单并占据整个屏幕显示
layout定义屏幕中组件的布局。线性布局会按一条线摆放组件，而相对布局则按与其他组件或屏幕的相对位置摆放组件。
menu则为当前屏幕中Menu的实例，表现为一个菜单与其子菜单。
Application类中则集成了一些通用的信息，资源的列表以便应用的访问。设备资源在每个平台中变得相当标准，原因如下：
个人信息管理，类似短信，联系人，日历等信息
网络连接，协议栈，例如IP或Bluetooth
设备相机，集成相机允许用户拍照和录制视频
外置内存，额外的内存可提高设备存储容量
电话：户外和室内呼叫
B.状态表
定义好应用的结构之后，我们就需要描述其运行状态。在智能手机应用中，运行状态主要由GUI（图形用户接口）中的用户交互和传感器（例如方向仪）的动作事件响应来表现。一般的智能手机应用由屏幕的集合组成，用户使用GUI控制屏幕的切换。这种在两个屏幕之间的转换之所以会发生是因为有如下的事件响应：
1，组件被点击或触摸。用户可与当前屏幕的组件进行交互。每个组件都可以响应用户的“触摸”动作
2，用户按下一个特殊的设备按钮，如“Home”或“Back”按钮。几乎所有智能手机平台都有这两个按钮：前者使当前应用退到幕后并显示系统主屏幕，后者则退回到前一个屏幕显示。iPhone是一个特例，因为他只有一个Back按钮不过这个按钮通常可在GUI中自行定义功能并实现。
3，屏幕菜单的点击或触摸
4，特定类方法的调用（回调）可准确地在系统事件中实现这样的转换（比如低电量警告或来电提醒）
这些典型的运行状态可使用状态表描述，这样我们就可以通过平台无关的方式来观察应用的变化。图5展示了一个由三个屏幕组成的应用运行状态变化的例子。每次转换都会报告一个事件（例如标签1代表一个按钮响应事件），最终可实现状态之间的转换（标签2）和动作（标签3）。
第五节，平台特定模型
模型转换代表模型驱动设计的核心。转换由一系列布置资源元素到一个或多个特定目标模型的规则组成，并且存在三条规则：易处理，增加的连贯性和双向性。下一节的主要目的就是这些规则的定义，以提出这种转换，并在转换工具上实现他们。
为了使这些规则更准确，简洁，易懂，我们介绍一下下列集合，定义和标记法：
泛化联系是指一种UML联系即一个特定的类A和泛型类B。也就是说，B泛化了A，而A特殊化了B。
接口创造指接口由类C创建了接口I，这是一个在类构造器和接口之间实现联系的UML特殊类型。
实例规格，是指一个描述类C的实例的类图表。实例说明使用“槽”来显示对象的属性。每个槽都对应着一个属性或特征，且可能包含实体的一个值。
依赖关系，指当两个实例I1和I2都声明后，在UML中相互之间形成供应者与客户端的关系，供应者提供某些东西给客户端，而客户端在某种程度上并不完整，因为他在语义和结构上是依赖于供应者的。
组件，都为平台无关中的类。
标记法X用于指代一个类属性或XML标签属性
这些规则在UML元模型中起作用（泛化联系，实例说明，依赖关系，组件，标记法）；他们使用如循环的结构，并可将PIM元素部署到PSM中。
A.状态表转换
下列转换规则是Android和Windows Phone平台共有的：
复制所有在新的PSM状态表中的状态，转换和初始伪结点状态。
每个在屏幕转换中从状态Q1到Q2的转换运行后，活动也会随之在PSM状态表中存下副本。
在资源中部署相应字符类型的标签值。
B.平台无关模型到Android平台特定模型的转换
下一子章节将主要讲述实现平台无关模型（PIM）到Android平台特定模型（PSM）的转换的实现且在技术报告中完成对这种转换规则的定义。第1到第7条规则，在章节V－B1中写出，实现了类图表的转换和产生新的类图表，以及Android的功能清单文件Manifest和资源文件String.xml。
这种部署是必要的，因为在PIM（平台无关模型）中被标记的值往往指的是实例规格定义的元素，而不再是PSM中所描述的那样，因为对象图表已经转换为XML的布局文件了。忽略布局到不同屏幕的适应性，Android很显然控制着所有必要的，建立在实际屏幕分辨率基础上的DP单元。通过这种方法，可以保证GUI能够以正确合适的分辨率显示在屏幕上。也因此组件的协作可以从PIM（平台无关模型）中直接复制而不使用任何转换。
1，结构转换
1）初始化：创建一个新的类图表并应用到Android平台特定模型的UML外廓中。
2）概况类的部署：部署一个PIM（平台无关模型）的类到具体的Android平台中
3）资源权限部署：部署PIM（平台无关模型）资源权限到具体的Android平台中
4）结构部署：添加PhoneApplicationPage（应用页面）,ContentControl（内容控制）类到类图表中
5) 接口实现：在每个类似于W类的实例I，如W为一个列表箱，如果在实例S和实例I之间存在依赖关系，S为P类的实例，P类继承自Screen，那么类P必须实现相应的接口，OnItemClickListener（选项点击事件监听器）
6）资源文件：创建String.xml文件，其中包含应用所用到的字符资源
7）功能清单文件：使PIM对象图表中的类的实例可以在应用中实现
C.PIM平台无关模型到WindowsPhone平台特定模型的转换
结构转换规则与上一节中的Android转换很相似。
通常来说，许多转换规则可能因为平台的不同而不同，即使他们转换的东西是相同的。依赖于目标平台，资源元素的子集（比如结构元素）可能会由一条规则或多条规则转换，这是由于目标平台不同的结构描述（XML文件，Java/C#文件）。这个问题在于如何获取一个特定目标元素的信息。同理，其他转换也可通过此法实现转换（结构转换，GUI布局转换行装）。举个例子，接口创建规则（Android平台）可以创建一个在PSM中的接口实现其依赖关系，就像OnItemClickListener接口可以在一些声明了接口的类中使用。这个规范在WindowsPhone中是不需要的，因为其中的事件控制由XAML管理。
D.代码生成
模型驱动设计的最后一步是每个平台特定模型应用代码的生成。生成的代码包括结构和运行两个方面。代码一般是类文件结构，包括构造器，接口实现，以及方法签名，这些几乎都能用UML模型工具去描述。运行方面则必须实现GUI的初始化和状态表的转换，这种转换是和用户在GUI中的交互联系在一起的。因此，代码生成过程是建立在PSM类图表和UML状态表的基础上的，并且可由UML模型工具进行操作。
六 试验可行性
这一节讲述一个简单应用的平台无关模型。其中的转换和代码生成将会被应用，并与由Android和WindowsPhone平台开发的相同的应用进行结构上的对比。由于篇幅有限，实现的细节会放在技术报告的第六章。
这个简单的应用名字叫做MapNavigator（地图导航），用于景点旅游。它可以通过设备相机阅读二维码，将其标签与预先下载的数字地图建立联系并检索相应的信息。
应用结构功能主要如下，用户可以自行浏览：
从内存或外置内存中选择地图(ChooseMap)
浏览地图并得到相应景点(NavigateMap)
通过相机扫描二维码(AcquireQRCode)
浏览景点列表(TagList)
阅读景点信息(TagInfo)
编辑应用设置偏好(Preferences)
类图表如图6所示，每个显示屏幕的类都继承自Screen类。
下面将讲述从PIM到Android-PSM的转换。
只看第4条规则（结构部署），图7展示了Android下的类图表，有7个类，每个类都继承自Activity类，并实现了一些接口。
只看第6条规则（资源文件），图8给出了包括Android下组件信息生成的文件。注意手动写入的代码，唯一不同的是其入口标准化的格式（[activityName]_[widgetName]_text）。
只看GUI的布局，图9所示的两个并列的图显示部分Welcome界面的信息，左边是转换时可自动获取的XML代码，右边是手动写入的代码。Welcome界面给出了个图标列表，用户可通过触摸图标来完成相应任务。这样手动开发的Android组件名为ImageButton，一个可触摸的图片（PIM并不支持）。因此，在PIM到PSM的转换中，这个组件被分成两块使用（ImageView,Button）。
只看生成的代码（附录C），以下是一些代码片段：
代码块C。1.ANDROID资源文件R.java一个将应用中所有资源（组件，布局，菜单，字符，图片）信息都集成在一起的文件，并给每个资源一个数字常数。这个文件也可以手动编辑添加另外的资源，不过要避免和已分配的常数重复。
代码块C。2.Welcome自动生成的Java文件可以和C。3中手动写入的版本对比。其中主要的区别在于许多方法和变量需要手动添加进类中。事实上，为了控制组件的触摸事件响应，代码会自动生成一个后缀为Click的私有方法对Activity中所有的组件进行事件驱动。这个方法的正确调用方式是用一个switch选择语句去控制相应的方法OnClick()。此外，每个构成活动的组件，都要在活动中声明自己的私有变量。这个变量提供了一个组件的指针（引用），并在活动中初始化。手动开发的文件更为简洁，因为可以使用更少的变量去控制可以驱动触摸事件的私有方法onClick()。
代码块C。4.TagList自动生成的Java文件可以和C，5中手动写入的版本进行对比。在这个文件中我们可以分析ListBox组件生成的代码。每个在活动中的ListBox组件，都有对应的后缀为onItemClick的私有方法。可以通过switch语句调用相应的onItemClick事件去驱动相应的组件。这是必须的，因为代码实现了OnItemClickListener接口，所以只能实现此接口才能控制事件响应。在手动写入的文件中，如果只有一个ListBox组件，那么开发者很有可能忽略这个事件驱动方法。
测试过的代码给出了很多有趣的例子。在其他例子中，自动生成的代码和手动开发的代码保持了一致。最后，代码块6展示了NavigateMap自动自成的代码。这个活动实现了一个菜单和Back按钮，点击Back可重新退回到Welcom界面。
七 结论
我们提出了模型驱动设计方法以解决多平台智能手机应用的问题。这个方法是建立在代码生成的基础上的故而不需要支持智能手机平台的额外库或进程。为了实现这个目标，我们分析了市场上主要的智能手机平台和其开发环境。分析中主要强调了在不同的平台和开发环境之间找到共同点。UML2外廓已经展示了平台无关的定义。其中描述界面的GUI布局的类与状态的图表，和应用之间的转换。然后两个特定平台模型PIM和PSM又分别展示了在Android和WindowsPhone之间的转换规则。这个方法论已经通过在两个平台中创建一个应用并且对比用传统方式编写的代码证实了。未来的工作将考虑其他可嵌入GUI的系统（比如平板和工业控制台）以便达到节省资源的目的。