移动应用开发比起创建熟悉的web应用的移动版本，其实需要做更多的事情。它要求移动应用开发人员理解基本的开发理念，并且会使用能够帮助他们构建所需操作的工具。

本文探讨移动应用模型的正确方式，在设计移动应用时，使用至上而下的方式构建工作流以及如何和遗留IT链接至关重要。

移动应用对于规划师/架构师，特别对于那些想要改进业务生产率或者现代化企业IT架构的公司而言是如今最热门的领域。简单模拟熟悉的应用程序框架来做出其移动版本是一种捷径，但却是错误的方式。正确的途径是从理解移动应用模型开始，采用至上而下的方式来生成功能流，并且在工作流的最后和遗留的IT链接在一起。如果可能的话，使用工具来构建活动也十分有帮助。

在设计移动应用时，规划师和架构师面临的最大问题是区分不出移动用户/移动工作人员。应用设计流程发生在可以模拟出应用在真实世界使用的场景的框架上至关重要。一些公司在这个领域做了很多尝试，比如使软件团队能够进行“移动模拟”，使他们能够体验到其应用用户可能会使用的场景，并且可视化出应用能够被使用的方式。

应用的用户上下文是应用建模的最高级别。在大多数情况下，应用分为两类，目的驱动或者刺激驱动的使用。目的驱动的应用包含的任务可以让用户来到什么地方，完成什么事情。这些应用必须通过在上下文提供信息来支持该目的，意味着要契合用户在完成目的的流程中所处的位置。相反，刺激驱动的应用的用户使用该应用是因为一些外部因素，并且很可能是因为一些大的随机事件的刺激。这两种模型都适用于工作人员和某种类型行为的消费者，因此，理解你自己的设计里哪种模型起作用非常重要。

应用建模的第二层是UI到工作流的链接。应用的目的会生成工作人员/用户的行为，要能够翻译成信息的请求，处理和某种方式的展示。一直以来能够可视化得看到应用用户会如何操作以及如何尽可能得支持这样的自然行为都很重要。将多步骤交互的每一步看成单独任务很有用；可以帮助早些确定步骤里是否存在信息的依赖，这些信息是否可以从本地数据获得，而不是需要访问更深层的企业仓库。

应用建模的第三层是前端到后台的链接。现代应用，特别是移动应用，被设计来建模用户界面驱动的前端流程，这类似于Web托管，和通常是遗留IT的后台应用流程交互。前端流程可以是简单的Web或者云托管的应用，特别是它们依赖于独立的或者相对不变和压缩的信息。后端是固定的，或者预计可能会因为现有IT的云适应而改变的。

有了这三层并都加以考虑，移动应用模型从内部用户建模功能流开始，从引起移动交互的刺激条件开始。要记住移动用户会经常每隔一小段时间就从事一些松耦合的应用交互，而不是像桌面电脑或者笔记本那样会一直持续使用某个应用。

建模应用的首要问题是是否这些步骤的每一步都应该考虑成一次独立刺激/响应流程，或者设备需要“保持状态”，通过将用户锁定在某一屏幕，从这里开始下一步交互。对于目的驱动的应用流这可能会有用，但是只在下一步是完全可以预测的情况下有用。移动用户不喜欢必须尝试再次去找到某个位置。

移动应用开发人员经常使用后台服务或者工具，来提供定义通用UI功能的方式，随后可以作为单独步骤映射到某个设备。在这里需要考虑像移动后台即服务和平台独立开发助手这样的东西来优化前端模型。

和应用的遗留“后端”部分的链接有两个主要需要考虑的方面。首先，应用序列的哪个点是为工作人员展示所需信息而来访问后端信息所必需的？这一点确定了前端后端交互必需首次出现的地方，并且通常来说是管理响应时间和服务质量可能会很困难的地方。其次，在应用序列的哪一点后台数据会更新并且会生成给工作人员的响应？这是“事务完成”的点，并且在这两点之间是工作所生成变化的状态不确定的地方。

所有更新流程天然就是有状态的，因此当某人尝试更新某些东西的时候，知道他们的更新流程是否成功至关重要。很多优秀的应用程序都毁在流程状态的不确定和更新的重复提交。屏幕消息提示“请等待”或者警告用户某个更新流程正在进行很重要，但是将应用设计成能够在问题发生时“回滚”到可靠状态，回退变化恢复应用到之前的状态也很重要。

使用传统的建模工具可以很好得完成应用建模的这一层，优先使用有丰富经验的供应商提供的产品。在这时转向移动特定的工具或者新工具可能不是个好主意，这样只会降低生产率并且增加出错的风险。用户也反应对于端到端的应用流而言，移动建模工具也似乎没什么用。

一个端到端的移动应用其实是两个应用——前端设备和用户驱动的流程集和后台遗留应用流程。虽然这两部分必须互相连接，但是将这两者分别管理而不是将其作为一个整体处理可能会更好。这样你才能够构建出更好的应用程序。