让我们回顾一下需求分析的历史，然后讨论SOA中如何来进行面向服务的分析和建模吧。

软件工程方法中，需求分析的方法跟问题域的复杂度和类型紧密相关。在早期，计算需求主要来自科学计算，其抽象手段主要是“数据结构+算法”。在沟通需求的时候，技术人员跟业务人员以自然语言为基础来沟通，然后以过程和/或函数以及数据结构为主要抽象手段，来建立分析模型。分析结果包含过程/函数、流程图、数据流图，复杂一些的，引入模块和子系统来分割。然后，用自然语言描述为主的文档来作为沟通的手段。如果我们还记得关于GOTO的讨论，我们了解，这个计算时代经过多年的发展，推动了结构化编程的发展和成熟。

伴随着商业计算逐渐成为主流，商业计算从早期类似于科学计算的财务等，转向更为广泛的领域，其计算的复杂度和类型，发生了很大的变化，这中间各种数据库技术曾经领衔主演了一段时间，我们按下不表。这期间，在“软件危机”的推动下，对象成为基本的抽象手段，将其高度内耦合的数据、状态和行为结合在一起，不仅提高了抽象度，也自然地反映人们认识和描述这个世界的方式。经过多年的实践、争吵和合作，人们总结出了很多关于对象分析和建模的方式，组件、接口、各种分析和设计模式，逐渐地被认识和流行，UML建立了图例和文档规范，以便沟通。这是软件界的一个巨大进步。在这种软件工程方法中，技术人员通常用自然语言同业务人员沟通，然后用“Use Case”（用例）来建立各种角色所看到的系统边界，再辅助以用户交互（UI）等必要的其他模型，建立一个系统的分析视图，然后，以对象（和组件）为基本手段，建立系统的分析模型，最后，用UML和一些过程如RUP提供的文档模板为基础，提供需求分析结果。这种分析方法，今天非常流行，也很有效。

但是，商业计算的情况再次发生巨大的变化——“整合”和“灵活性”成为主要的需求。经过几十年的发展，商业计算已经不再是过去白手起家的时刻，我们已经有了很多的“历史”，那就是我们已经建立起来的这么多的系统：每个企业都有IT系统，少到几个、几十个，多到几千甚至上万。人类花了这么多钱、这么多时间在这些系统上，没有了这些系统，核心业务会崩溃。但这些系统也给我们带来了巨大的麻烦——它们能够满足不同业务部门（Line of Business，LoB）的垂直需求，可是相互不往来、也不能或者很难相互往来，难以满足跨业务部门的水平需求，更不要说在今天这个平的世界里，如何将合作伙伴、客户连接起来，建立一个动态的商业价值网络。但是，全球化的经济结构和运作模式，互联网作为全球化的IT基础设施，从商业和技术两个角度，透过竞争，既给富有创新和执行能力的企业带来了一个前所未有的商业机会，又迫使跟随的企业不得不起而迎战——将业务模式调整到以客户为中心，将自己内部的业务系统连接起来，水平整合业务活动成为端到端的业务流程，透过这些流程，让整个公司的员工可以自由地得到业务活动需要的信息，轻松地相互协作，从而将整个企业的运作模式转化为一个扁平的结构，打破业务部门的边界，极大地提高企业的效率，得到更好的客户满意度。即便如此，用户需求、市场情况、商业环境的快速变化作为这个时代的特点，要求企业能够快速调整自己的商业模型，因此，在整合的基础上，还要加上快速应变的灵活性要求。这就涉及到了软件的两个魔鬼：复杂度和演变。全面整合（整个企业，客户，合作伙伴）的系统，其复杂度再次提升，而灵活应变能力，在一个整合的世界里，大家都变，自己也没办法以不变应万变，究竟如何因变？所以，我们需要发展软件系统的构造方法，它既可以帮助我们将问题域进行良好的分割，分解映射为分布世界里的独立单元，又可以帮助我们灵活地将它们组合起来以完成一个完整的业务活动，这样一种新型的、富有弹性的分布式系统，是今天的商务世界所需要的，是商业计算的主要发展方向。SOA也好，正在热吵的Enterprise Web 2.0也好，都是我们期望用来解决上面这个问题的方法。

虽然，我们还处在这个早期，有赖于过去多年的EAI、分布式系统的构造实践，尤其是Web的发展，IT行业积累了不少的经验和技术来求解。让我们简要地看看现在这个阶段的解的重点：一个是将业务本身作为一个独立的实体，由业务人员自己自觉（而不是自发）地以业务世界的元素，比如业务活动，业务流程，业务规则，业务性能及其测评，建立起数字化的模型，其核心概念就说所谓的“服务”。在这个模型中，我们将看到一个清晰的图景：业务活动是如何影响业务绩效的，业务模型的问题在那里，如何改善。这就是所谓的“商业科学化”，请参看我在 Service Science方面的介绍。了解BPR (Business Process Reengineering) 的话，应该了解这件事情会在什么状态，它的困难在哪里。有了这个为基础，业务人员可以自己跟自己玩：市场需求变了（他们的需求），那业务模型怎么变化来适应？或者，有了一个市场图谋，如何变化自己的业务模型来适应？过去要猜，要靠某些精英的个人特质，有了这个模型，我们期待一个魔术的出现，就是可以用数学的方法来演算、模拟、推断，哪怕结果不是高度精确的，也可以给决策者一个合理的、基于数字的决策依据。然后，这个模型要清晰地被分解和映射到IT系统中的服务接口、组件和业务规则描述等等，然后将它们分配到各个应用（包括已经存在的）中，再在这个基础上，使用用例、组件（细粒度）和对象建立应用或者子系统的需求模型，我们可能需要增加新的模型，比如整合各个应用的模型，安全模型（整合情况下安全更复杂）等。看得到，这个模型对过去的业务分析（尤其是从BPR，或者其他以业务流程为基础的）是有继承的，但要看到，他们的出发点和追求的目标，有交叉但并不能等同，所基于的概念和方法，即使有所借用，却有很不相同的重点。站在发展的角度，我们期待着业务模型数字化、科学化的突破。

是故，我们认为SOA将业务建模作为一个全新的因素引入，如何建立一个好的业务模型，然后递次分解、映射到传统技术世界主导的分析和建模，如何保证其可追溯性（Tracability）将是以服务为中心的分析、建模的重要环节。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号