加载中…

加载中...

个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:4,131,692
  • 关注人气:5,912
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

关于SOA中需求分析的讨论-转载

(2009-09-07 21:53:29)
标签:

soa

需求分析

it

分类: 转载文章
原文:http://hi.baidu.com/lihonghao_shzh/blog/item/fc11d06d11b2dbfe4216942b.html

让我们回顾一下需求分析的历史,然后讨论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)将是以服务为中心的分析、建模的重要环节。

面向服务的体系结构(service-oriented architecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。而另一方面,紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的,因而当需要对部分或整个应用程序进行某种形式的更改时,它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活,以适应不断变化的环境,比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素,这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需(On demand)业务,在按需业务中,一旦需要,就可以对完成或执行任务的方式进行必要的更改。

虽然面向服务的体系结构不是一个新鲜事物,但它却是更传统的面向对象的模型的替代模型,面向对象的模型是紧耦合的,已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务,但是其整体设计却是面向服务的。由于它考虑到了系统内的对象,所以虽然 SOA 是基于对象的,但是作为一个整体,它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构(Common Object Request Broker Architecture,CORBA),它已经出现很长时间了,其定义的概念与 SOA 相似。

然而,现在的 SOA 已经有所不同了,因为它依赖于一些更新的进展,这些进展是以可扩展标记语言(eXtensible Markup Language,XML)为基础的。通过使用基于 XML 的语言(称为 Web 服务描述语言(Web Services Definition Language,WSDL))来描述接口,服务已经转到更动态且更灵活的接口系统中,非以前 CORBA 中的接口描述语言(Interface Definition Language,IDL)可比了。

Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式,这样就有了面向消息的中间件(Message-Oriented Middleware)系统,比如 IBM 的 MQseries。但是为了建立体系结构模型,您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此,SOA 应该能够将业务的商业流程与它们的技术流程联系起来,并且映射这两者之间的关系。例如,给供应商付款的操作是商业流程,而更新您的零件数据库,以包括进新供应的货物却是技术流程。因而,工作流还可以在 SOA 的设计中扮演重要的角色。

此外,动态业务的工作流不仅可以包括部门之间的操作,甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此,为了提高效率,您需要定义应该如何得知服务之间的关系的策略,这种策略常常采用服务级协定和操作策略的形式。

最后,所有这些都必须处于一个信任和可靠的环境之中,以同预期的一样根据约定的条款来执行流程。因此,安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。

我可以用面向服务的体系结构做什么?对SOA的需要来源于需要使业务 IT 系统变得更加灵活,以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现,IT 系统既可以利用现有系统的功能,又可以准备在以后做一些改变来满足它们之间交互的需要。

下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店,它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色,甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容,那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性,每个公司都可以将它们的现有系统保持现状,而仅仅匹配 WSDL 接口并制订新的服务级协定,这样就不必完全重构它们的软件系统了。这是业务的水平改变,也就是说,它们改变的是合作伙伴,而所有的业务操作基本上都保持不变。这里,业务接口可以作少许改变,而内部操作却不需要改变,之所以这样做,仅仅是为了能够与外部合作伙伴一起工作。

另一种形式是内部改变,在这种改变中,零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店,这可以看作是采用店中店(store-in-store)的业务模型。这里,虽然公司的大多数业务操作都保持不变,但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修,但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下,SOA 模型保持原封不动,而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责,但是正常的零售管理系统继续如往常一样。

为了延续内部改变的观念,IT 经理可能会发现,软件的新配置还可以以另外的一种方式加以使用,比如出租粘贴海报的地方以供广告之用。这里,新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果,并且还是一个新的机会,而这样的新机会在以前可能是不会有的。

垂直改变也是可能的,在这种改变中,零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话,就会带来SOA模型结构的显著改变,与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下,SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题,这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式,而不是在许多现有的软件平台上常常看到的其他方式。

正如您可以看到的,在这里,改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说,这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生,这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是,架构师的作用就是引起对 SOA 模型大的改变。这种分工,就是让开发人员集中精力于创建作为服务定义的功能单元,而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起,它已经有十多年的历史了,通常用统一建模语言(Universal Modeling Language,UML),并且描述成模型驱动的体系结构(Model-Driven Architecture,MDA)。

0

阅读 收藏 转载 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有