（计算机应用技术专业论文）分布式应用系统建模中soad方法的研究与应用.pdf

摘要 基于软件体系结构开发的方法学一直试图解决同益增长的软件复杂性。传统 的体系结构在一定程度上已经达到了所能处理复杂问题的限度，而复杂性依然在 飞速增长，并对应用系统提出了新的需求：系统需要对新的业务需求进行快速的 反应，需要不断地减少业务中i t 的成本，以及吸收、集成新的业务伙伴。业界 提出面向服务的体系结构s o a 应对复杂的挑战。问题随之而来：如何从面向服 务的角度来分析和设计系统；如何合理地整合整个企业范围内的信息资源，降低 开发成本；如何面对已存在的系统开展分析、设计；如何设计和建模，以确保面 向服务的系统能实现其快速应对需求的变化等最初的目标。现有的分析设计方 法，无法满足构建s o a 系统的需求。正如存在着面向对象的分析设计方法与面 向对象体系结构相对应一样，我们需要一种新的面向服务的分析和设计方法来支 持基于s o a 的系统构建。 面向服务的分析与设计包含服务的建模和设计两部分。在建模方面，本文结 合中央电大远程开放教育系统的业务需求，按照面向服务的原则，介绍了s o a d 的准则、目标和建模过程，给出了用于构建系统的服务建模架构。并在此基础上， 给出了充分利用遗留系统分析设计成果的混合建模方法。在设计方面，详细阐述 了应用x s ds c h e m a 规范定义数据格式和应用w s d l 规范进行抽象服务定义的方 法以及使用w s b p e l 规范进行业务流程编排的过程。在实现方面，结合电大系 统的开发过程，探索并实践了利用遗留系统组件实现服务的方法，将现有的系统 存放的大量的重要数据结构和软件组件迁移到新的架构中去。 关键词面向服务的体系结构；面向服务的分析与设计；系统建模；遗留系统 a b s t r a c t 1 1 1 ed e v e l o p i n gm e t h o d o l o g i 鹤b a s e do ns 0 1 a r ea r c h i t e c t u r ea l et r y i n gt od e a l w i t ht h ec o m p l i c a t i o no fs o f t w a r e t h et r a d i t i o n a la r c h i t e c t u r eh a sa l m o s tr e a c h e di t s l i m i tw h i l ec o m p l i c a t i o ni ss t i l li n c r e a s i n g w en e e ds y s t e mr e s p o n dq u i c k l yt ot h e c h a n g eo fr e q u i r e m e n t , k e e pr e d u c et h ec o s to fi ta n di n t e g r a t en e wb u s i n e s sp a r t n e r e a s i l y n o w a d a y s ，s e r v i c e s - o r i e n t e da r c h i t e c t u r ei sp r o p o s e dt od e a lw i t ht h o s e p r o b l e m s a tt h es a l t l et i m e , n e wc h a l l e n g e sa r i s ei nt h ea p p l i c a t i o ns y s t e md e s i g n s u c ha sh o wt oa n a l y s e sa n dd e s i g ns y s t e mi ns e r v i c e - o r i e n t e da n g l e ；h o wt od e a l w i t hl e g a c y - s y s t e mw h i l ed e s i g n i n ga n dh o wt om o d e la n dd e s i g nt om a k es y s t e m a g i l ew h i l ef a c i n gr e q u e s tc h a n g e s 1 1 b ee x i s t i n gm e t h o d sc a l ln o tf u l f i l lt h en e e da n d an e ws e r v i c e - o r i e n t e da n a l y s e sa n dd e s i g nm e t h o da r en e e d e dt os u p p o r tt h e c o n s t r u c t i o no f s o as y s t e m s s e r v i c e o r i e n t e da n a l y s e sa n dd e s i g ni n c l u d es e l v i c em o d e l i n ga n ds e r v i c e d e s i g nt w op a r t s i nm o d e l i n gp r o c e s s w i t l lt h ep r i n c i p a lo fs e r v i c e - o r i e n t e d a r c h i t e c t u r e , t h i sp a p e rp r o p o s e sar e f e r e n c em o d e la r c h i t e c t u r e b a s e0 1 1t h e a r c h i t e c t u r e , w ep r o p o s ea n dp r a c t i c eam i x e dm o d e l i n gm e t h o dw h i c hf u l l yu s e dt h e e x i s t i n gd e s i g np r o d u c t i o no fl e g a c y - s y s t e m i nd e s i g n i n ga s p e c t ，w ed e m o n s t r a t et h e m e t h o df o rd e f i n i n ga b s t r a c ts e r v i c e sw i t l lw s d l , e s t a b l i s h i n gd a t a - f o r m a tl i b 、v i t h x s ds c h e m aa n da r r a n g i n gb u s i n e s sp r o c e s sw i t hw s b p e l i nr e a l i s t i ca s p e c t , c o m b i n i n gw i t l lt h ed e v e l o p m e n to fc e n t r a lr a d i oa n dt vu n i v e r s i t yr c r t v u ) s e d u c a t i o na d m i n i s t r a t i o ns y s t e m , w ee x p l o r ea n dp r a c t i c et h es e r v i c ei m p l e m e n t m e t h o dt ot r a n s f e rl e g a c y c o m p o n e n t st ot h en e wa r c h i t e c t u r e k e y w o r d ss e r v i c e - o r i e n t e da r c h i t e c t u r e ；s e r v i c e - o r i e n t e da n a l y s i sa n dd e s i g n ； s y s t e m m o d e l i n g ；l e g a c ys y s t e m i i i 独创性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研 究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其 他人已经发表或撰写过的研究成果，也不包含为获得北京工业大学或其它教育 机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何 贡献均已在论文中作了明确的说明并表示了谢意。 躲盈魄丝i 日刚 关于论文使用授权的说明 本人完全了解北京工业大学有关保留、使用学位论文的规定，即：学校有 权保留送交论文的复印件，允许论文被查阅和借阅：学校可以公布论文的全部 或部分内容，可以采用影印、缩印或其他复制手段保存论文。 ( 保密的论文在解密后应遵守此规定) 魏塑竖导师签名雠墨眺a 竺2 印夕 1 1 选题的背景 第1 章绪论 基于软件体系结构开发的方法学一直试图解决f 1 益增长的软件复杂性。传统 的体系结构在一定程度上已经达到了所能处理复杂问题的限度，尤其是当我们用 于解决复杂问题的技术平台本身又过于复杂的时候。另一方面，复杂性依然在飞 速增长，并对应用系统提出了新的需求。例如，系统需要对新的业务需求进行快 速的反应，需要不断地减少i t 成本，以及吸收集成新的业务伙伴。作为一个产 业，我们经历了能够提供完全的分布式计算的多种体系结构以及平台无关的编程 语言，我们还经历了无数的连接性产品，这些产品能够更快更好地集成应用程序。 然而，这些还不是完全的解决方案。问题在于缺乏一个一致的体系结构框架，在 这种体系结构中可以快速地开发、集成和重用应用程序。更重要的是，我们需要 这样一个体系结构框架，它能够装配组件和服务，以便快速甚至动态地交付应用 程序。现在，业界提出面向服务的体系结构s o a 作为软件体系结构中下一个发 展的阶段来帮助r r 组织满足其面临的越来越多的复杂性的挑战。 面向服务的体系结构( s e r v i c e - o r i e n t e d a r c h i t e c t u r e ，s o a ) 作为一种新型的 应用软件架构模型，特点是服务重用和共享，面向流程以及以业务为中心。与传 统架构相比，它强调消除软硬件平台差异，互通异构系统。最大限度利用现有r r 资源。 自g a r t n e r 于1 9 9 6 年提出s o a 的预言并预测它将成为占绝对优势的软件工 程实践方法至今，s o a 真正走到了开发实现阶段。问题随之而来：如何从面向 服务的角度来分析和设计系统：如何合理地整合整个企业范围内的信息资源，降 低开发成本；如何面对已存在的系统开展分析、设计；如何设计和建模，以确保 面向服务的系统能实现其最初目标，例如快速应对未来业务需求的变化。这些是 构建面向服务系统正在面对的问题。 正如存在着面向对象的分析设计方法，与面向对象的体系结构相对应一样， 我们需要一种新的面向服务的分析和设计方法来支持基于s o a 的系统的构建。 1 2 相关领域研究进展和成果 早期的s o a 实现项目经验表明，诸如o o a d ，e a 和b p m 这样的现有开发 流程和表示法仅仅涵盖s o a 体系结构模式所需的部分要求。s o a 方法在加强通 用软件体系结构原则的同时，还增添了附加的主题，在建模时需给予特别关注。 北京t 业人学丁学硕f j 学位论文 o l a f 等人肯定了e a 、b p m 和o o a d 方法在s o a 分析设计中的价值和可用 性，但也指出其各自的不足。他们研究o o a d ，e a 和b p m 的适当原理，将这此 规则中的原理与些独特的新原则组合，形成s o a d 的一种混和分析设计方法。 下图展示了现有的e 八b p m 和o o a d 建模方法的主要应用领域，水平轴表示项 目生命周期阶段；垂直轴表示不同抽象层或领域之间的区别，而建模活动在其上 进行嘲。 图卜1s 0 h 9 混合建模方法0 1 f i g u r e1 - 1m i x e dm o d e l i n gm e t h e db a s e do i ls o a d 此外，o l a f 等提出s o a d ( s e r v i c e - o r i e n t e da n a l y s i sa n dd e s i g n ) 面向服务的 分析与设计的概念，用于定义构建s o a 系统的结构化分析与设计方法，举例说 明了基于服务的建模方法的主要活动。讨论了基于服务的建模和架构的重要部 分，以及构建s o a 所需的分析和设计的关键活动，并按架构分层给出了建模模 板和步骤，提出基于组件的服务设计方法。“”“1 。采用了结合自顶向下和自底向 上的混和建模步骤。 1 3 目前s o a d 方法研究的不足 目前，s o a d 的研究尚处于起步阶段，缺乏整体的标准的方法。信息化发展 到今天，i t 系统已经广泛存在于企业之中，往往正在发挥着重要作用。s o a 常 常面对的是已存在且循序渐进构建起来的应用系统。然而，已有的研究主要针对 新建s o a 项目情况，即从无到有地建立s o a 系统。1 。 这带来两方面的问题： 在建模和设计方面，如何能够充分利用遗留系统得分析设计成果，将原有设 计精华迁移到面向服务的系统中。尽量减少重复性设计工作，即提高系统建模设 计效率，又避免错误的产生。 第l 苹绪论 在实现方面，如何能将现有的系统存放的大量的重要数据结构、软件组件和 业务流程迁移到新架构中去，节约r r 开发成本。 此外，在建模步骤上，业内主要采用自顶向下的分析方法。虽然，理论上也 给出了自底向上、自顶向下、中间相遇等方法m 州，但综合使用这些方法，针对 具体应用给出细致的建模、设计和实现过程描述的不是很多。特别是，如果我们 将遗留分析成果作为服务建模设计的重要依据和出发点时，应怎样调整分析的步 骤是比较重要的问题。 1 4 本研究课题来源及主要研究内容 本课题来源于中央广播电视大学教务管理系统的开发。系统分为中央电大、 省电大两级平台，地理上遍布全国，以中央电大为项层节点，下设4 4 个省级节 点，其下又分别涉及到几个至几十个分校及教学点节点。该系统由多个按照业务 发展的需要逐渐开发的信息系统组成，形成了多个信息孤岛。为了提供更好的服 务，电大系统面临着同原有办公自动化系统及电大在线系统的协作及数据共享。 同时，随着中央电大在开放式教育思想指导下的教学改革的展开，系统业务会随 着需求变化不断做出调整。 为了满足远程开放教育业务发展的需要，我们依据s o a 策略重新对中国远程 开放教育信息系统进行规划，其中核心的工作之一是基于s o a 开放教育信息系 统参考架构进行服务建模和设计。基于系统的庞大性、多样性、复杂性及业务需 求变动频繁等特点，如何构建一个能够灵活应对业务变化，扩展性良好的s o a 系统成为我们需要研究的难点。另外，原系统分析设计资料详尽，为避免重复、 减少错误，如何充分利用遗留分析成果开展面向服务的分析设计是我们需要探索 的重点。 本文主要从三部分阐述面向服务分析设计的研究与实践。首先，建立了以电 大系统为背景的服务模型，并在此模型的基础上给出了一种充分利用遗留分析设 计成果开展面向服务分析设计的方法。并将此方法应用于中央电大远程开放教育 系统的建模。其次，应用s o a 的最新规范，包括w s b p e l 、x s d 、w s d l 等， 设计和定义电大系统服务和业务流程服务。最后，探索并在电大系统中实践了一 种充分利用遗留软件组件实现服务的方法。 1 5 本文结构 本文将分为四个部分来阐述： 第一部分：介绍与本课题相关的背景知识，对国p q # l - 相关领域的研究和进用 进行综述。介绍本课题的来源及主要研究内容。 北京t 业人学t 学顾i 学位论文 第二部分： 第三部分： 第四部分： 对面向服务的架构的概念和特点做了一个理论概述，明确了面向 服务分析设计的准则及目标。强调了s o a 的服务重用和共享，面 向流程以及以业务为中心等特点。 主要介绍中央电大系统面向服务的分析与建模过程。首先，基于 中央电大的系统背景，给出了服务模型。继而，参照此模型，在 分析遗留系统设计成果的基础上，对系统业务流程和服务进行分 析和建模。 研究并实践了面向服务系统的设计和实现。探索应用x s d 语言描 述服务消息格式的方法，并参考原系统域数据层建立了标准化的 电大数据格式定义库。应用w s d l 、w s - b p e l 等s o a 最新规范， 实践了电大系统服务和业务流程的设计和定义方法，进一步将第 二部分的建模成果向具体实现推进。基于a x i s 技术，利用遗留系 统的业务逻辑组件和持久化组件完成了服务的构建。最后，对今后 基于s o a 建立中央电大远程开放教育平台进行展望。 第2 章面向服务的分析1 ，i 殳计概述 第2 章面向服务的分析与设计概述 2 1 面向服务的体系结构 面向服务的体系结构是一个组件模型。它将应用程序中的不同功能单元称作 服务，通过组织服务构建应用系统。组织服务的基础是定义良好的服务接口。服 务接口必须采用中立方式定义，独立于实现服务的软硬件平台。这使得构建于 s o a 系统中的服务可以用一种统一、通用的方式进行交互o “”“川。 s o a 突出的特点是松耦合“”。松耦合系统的好处是灵活应对变化。当每个 服务的内部结构和实现发生改变时，变化能够被限制在服务内部。相对紧耦合来 看，因为应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当 需要对部分或整个应用程序进行某种形式的更改时，系统就显得非常脆弱。对松 耦合系统的需要来自于应用程序需要根据业务逻辑的需要变得更加灵活，以适应 不断变化的环境。比如经常改变的政策、上级部门的规定、产品报价、各部门或 单位之间关系、以及其他与业务有关的因素，这些因素甚至会影响业务的性质。 因此就有这样的需求，即一旦需要就可以对完成或执行任务的方式进行必要的更 改。 面向服务的体系结构是下一代分布式应用开发的体系结构蓝图。其目的是建 立起以服务为中心的业务模型，从而对用户的需求做出快速、灵活的响应“”。在 这种体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调 用接口，并可以定义好的顺序调用这些服务来形成业务流程。 2 2 面向服务的分析与设计 面向服务的分析与设计是利用面向服务的原理分析、设计应用系统的方法 论。主要工作包括服务建模、服务设计和业务流程编排等。本节首先确定了服务 建模应在那些层次开展，其次，讨论了现有的分析准则和服务设计目标，在最后， 讨论了现有的建模步骤和过程。 2 2 1 面向服务分析设计层次 构建s o a 系统会涉及很多层面的问题，包括着眼于功能性方面的和着眼于 服务质量方面的，建立s o a 是复杂而浩大的，如图2 - 1 s o a 体系结构堆栈“”所 示。在此，提出s o a 体系结构堆栈是要说明本文讨论的s o a d 将主要精力集中 于功能区中横向排列元素的设计和实现，即如何进行服务和业务流程的分析、设 北京t 业人学t 学硕f ：学位论文 计和描述。此外，在实现服务的过程中也涉及了对服务通讯协议和底层传输协议 的指定。而s o a 元素的其它部分是今后s o a 实现平台研究的重点，包括如何发 现服务、如何管理安全和事务等。 图2 - 1s o a 体系结构堆栈“1 f i g u r el - 1s t a c ko f s e n c e - o e n t e da r c h i t e c t u r e 因此，本文将主要精力集中于s o a 的三个主要的抽象级别“。建模活动也 围绕着他们展开，形成三个s o a d 建模层次操作、服务和流程。从建模的 观点来看，s o a d 的任务就是如何设计和描述定义良好的操作、服务和流程的抽 象特征以及如何系统地构造它们。其中，服务的分析和设计最为关键。以下是三 个主要的抽象级别“”： 操作：代表单个逻辑工作单元的事务。执行操作通常会导致读、写或修改一 个或多个持久性数据。s o a 操作可以直接与面向对象的方法相比。它们都有 特定的结构化接口，并且返回结构化的响应。如同方法，特定操作的执行可 能涉及调用其它的操作。 服务：代表操作的逻辑分组。例如，如果我们将收取考试费视为服务，则按 查询学生账户余额、检索收费标准并计算费用和扣除考试费就代表与其相关 的操作。 业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务 流程通常包括多个业务调用。业务流程的例子有：考前管理流程、学生报考 流程、毕业审核流程等。在s o a 术语中，业务流程包括依据一组业务规则 按照有序序列执行的系列操作。操作的排序、选择和执行称为流程编排。典 型的情况是调用己编排好的流程形成一个服务，来响应业务事件。 2 2 2 面向服务分析设计原则 $ o a 架构是为了解决系统开发中的问题而提出的。因此，面向服务的分析 设计应当从s o a 的目标和挑战着手，其原则都应围绕着需要解决的现实问题。 第2 苹向向服务的分析j 设计概述 当今的企业正面对两项挑战：迅速改变的能力和降低成本。为使面向服务的分析 设计能够构建出足以应对挑战的系统，s o a d 应遵循以下原则。 ( 1 ) 以流程为中心 现有的体系结构模型和实践往往是以程序为中心的。应用程序是为了程序员 的便利而开发的，重用需要复制代码。在以流程为中心的体系结构中，应用程序 是为过程开发的，流程被分解成一系列的步骤，每一个步骤由一个业务服务完成。 将这些服务链接在一起可以创建能够满足业务需求的流程，这种方式可以充分利 用和重用整个组织中的不同粒度的服务。 ( 2 ) 充分利用现有资产 应构建一个抽象层一一服务层。通过这个抽象层，企业可以继续利用它在1 1 r 方面的投资，方法是将这些现有的资产封装成能提供企业功能的服务，这些业务 服务是现有组件的集合。通过合并构建在不同机器上、运行在不同操作系统中、 用不同编程语言开发的组件来创建。通过服务接口来封装和访问遗留系统可以， 以便企业可以继续从现有的资源中获取价值，而不必重新从头开始构建。 ( 3 ) 减少成本和增加重用 通过松散藕合的方式设计和发布出的服务应能够被用来构建新的更高层次 的服务。通过利用现有的组件和服务，可以缩短完成软件开发的生命周期。 在设计过程中，业界还总结出一些通用原则或品质因素可以作为s o a d 的 设计基准“”。 服务松耦合。服务请求者到服务提供者的绑定与服务之间应该是松耦合的。 服务请求者不知道提供者实现的技术细节。服务请求者通过消息调用服务的 操作，而不是通过使用a p i 。松耦合使会话一端的可以在不影响另一端的情 况下发生改变。 服务抽象是内聚、完整和一致的。例如，在设计服务和它们的操作名称时应 该考虑创建、读取、更新、删除和搜索来隐喻其含义。 明确定义服务接口。服务交互必须是明确定义的。要清楚的描述请求者绑定 到服务提供者所需要的所有细节。服务的描述不应包括服务实现的任何技术 细节。 通常服务是无状态的。为了满足服务在特定的问题域和上下文中的状态需 求，将削弱服务无状态的假定。但可以通过将状态信息抽离到流程编排工作 中而是其更易于管理、更容易修改。 名字空间必须让没有深奥r r 知识的领域专家可以理解。 设计良好的服务是有意义的，且必须显式声明。不只适用于企业应用程序， 而且服务之间的依赖性需减到最少。在开发过程中，服务和服务使用者除了 领域知识外只需要掌握基本的编程语言技能。 北京t 业人学t 学硕j j 学位论文 2 2 3 面向服务的建模活动和过程 面向服务的建模是运用s o a d 方法设计s o a 的重要过程。成功地创建s o a 需要的不仅仅是工具和标准，还需要一些规范的步骤来支持s o a d 。现在，业界 对此还没有统一的标准。域分解、子系统分析、目标模型创建和相关技术是s o a 流程构造方法或服务概念化框架最有代表性的提议“”。此外，a l i 等人在文中提 出了一种面向服务的建模活动和过程，包含服务、组件和流程的鉴别、指定和实 现等主要步骤1 。下面按服务鉴别、服务指定、服务实现三个部分介绍a l i 提出 的建模活动和过程。 ：壁墨垣 陛缝司 臣网一 l 建梗il 厂二匆窆_ f 1 三墨婪分划l 丽务括i 随鳓量： u 一。jr ，一， 疆务实现决簸r i 雎务分配剃蛆伴ll + 蛆件蜃 图2 - 2s o a b 建模活动和过程。1 f i g u r e2 - 2m o d e l i n ga c f i v i t y sa n dp l d c e o fs o a d 服务鉴别 这个过程由域分解、现有资产分析和目标服务建模的自项向下、自底向上、 中间向外技术联合组成，如图2 2 所示。 在自顶向下视图中，业务用例的蓝图提供了业务服务的规范。自顶向下过程 先是域分解，域分解由业务领域和它的功能区域以及子系统的分解组成，包含它 的流程或过程分解成过程、子过程和高级别业务用例。 在自下而上的分析过程中，现有的系统被分析和选择作为可行的候选，支持 业务过程的底层服务的功能性实现。在这个过程中，分析和利用来自遗留和打包 应用程序的a p i 、事务和模块。在有些情况下，为了支持服务的功能重新模块化 现有的资产需要遗留系统的组件化。 中问向外视图由目标服务建模组成，来验证和发现自顶向下或自底向上的服 务鉴别手段中没有捕捉到的其他服务。 服务指定 服务分级和分类活动在服务被指定时开始。将服务分级为服务层次是非常重 要的，反映了服务的复合或者不规则的本性。服务可以也应该由良好粒度的组件 第2 辛面向服务的分析，设计概述 和服务组成，分级帮助决定合成和分层，以及基于层次的相互依赖的服务的协同 构建。同样，它帮助减轻服务增值综合症，这种症状中，越来越多的小粒度的服 务被定义、设计和部署，却缺乏控制，导致了主要的性能、可伸缩性和管理问题， 却获得不到经济效益。 子系统分析活动获取上面域分解过程中发现的子系统，并且指定子系统之间 的相互依赖和流程。子系统的分析包含创建对象模型来表现内部工作方式，以及 所包含的公开服务并且实现它们的子系统设计“。 组件指定活动中，将指定实现服务的组件的细节，包括数据、规则、服务、 可配置概要和变更。消息和事件指定以及管理定义也包含在服务指定这一步骤 中。 服务实现 服务分配活动包括分派服务到目前鉴别的子系统。服务分配还包含服务的指 派以及在s o a 层中实现他们的组件的指派。组件和服务向s o a 层中的分配是一 个关键的任务，需要关键架构决策的文件和决议，这些决策不仅仅同应用程序架 构有关系，也同在运行时设计和用来支持s o a 实现的技术架构有关。 服务实现步骤指出实现特定服务的软件必须被选择或者自定义构建。其他可 用的选项包括使用w e b 服务来集成、转化、订阅和外购。在这个步骤中，决定 哪个遗留系统模块用来实现给定的服务，哪些服务将从基础来构建。服务的其他 不同于业务功能的实现决策包括：服务的安全、管理和监视。 a l i 推荐并行管理三个流：自顶向下的域分解同自底向上的组件化和服务公 开候选的现有遗留资产的分析并行执行。通过目标服务建模获得项目背后的业务 意图和使服务同业务意图密切合作。 2 3 面向对象的分析与设计 2 3 1 面向对象的分析与设计概述 面向对象的分析与设计( o b j e c t o r i e n t e d a n a l y s i sa n d d e s i g n ，o o a d ) 包括 面向对象的分析和面向对象的设计两部分。面向对象分析方法( o b j e c t - o r i e n t e d a n a l y s i s ，o o a ) ，是在一个系统的开发过程中，完成系统业务调查后，按照面 向对象的思想来分析问题，对客观世界的系统进行建模的方法。“。o o a 所强调 的是在调查资料的基础上，针对o o 方法所需要的素材进行的归类分析和整理， 而不包括业务现状和流程的分析。 面向对象设计( o b j e c t - o r i e n t e dd e s i g n ，o o d ) 是把分析阶段得到的需求转 变成符合成本和质量要求的抽象的系统实现方案的过程。按照b j a m cs t r o u s t r u p 北京i 业人学t 学顾i 。学位论文 的说法，面向对象的编程范式是。”： 类的识别； 确定每个类提供的操作； 明确地使用继承来表现共同点。 由这个定义，我们可以看出：o o d 就是“根据需求决定所需的类、类的操作 以及类之间关联的过程”。 o o d 的目标是管理程序内部各部分的相互依赖。为了达到这个目标，o o d 要求将程序分成块，每个块的规模应该小到可以管理的程度，然后分别将各个块 隐藏在接口之后，让它们只通过接1 3 交互。比如说，如果用o o d 的方法来设计 一个服务器客户端应用，那么服务器和客户端之问不应该有直接的依赖，而是 应该让服务器的接口和客户端的接口相互依赖。这种依赖关系的转换使得系统的 具有了部分可复用性。在面向对象的系统中，“重用”则需要复制代码、合并共享 库或继承对象】。 2 3 2 面向对象分析设计原则 从实践经验中，人们按照面向对象的思想总结出面向对象的分析和设计过程 的一系列原则，并应用他们指导系统的建模。其中，有些原则在面向服务的分析 中同样适用，而有些则不然。对o o a d 准则的反思有助于更好的理解面向服务 的设计原则。以下是面向对象分析的一些关键原则“。 抽象：面向对象方法中使用最为广泛的原则。抽象原则包括过程抽象和数据 抽象两个方面。过程抽象是指，任何一个完成确定功能的操作序列，其使用者都 可以把它看作一个单一的实体，尽管实际上它可能是由一系列更低级的操作完成 的。数据抽象是根据施加于数据之上的操作来定义数据类型，并限定数据的值只 能由这些操作来修改和观察。数据抽象是o o a 的核心原则。它强调把数据和操 作结合为一个不可分的系统单位即对象。对象的外部只需要知道它做什么，而不 必知道它如何做。 封装：即把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽 对象的内部细节。 继承：特殊类的对象拥有的其一般类的全部属性与服务，称作特殊类对一般 类的继承。在o o a 中运用继承原则，把一般类的对象实例和所有特殊类的对象 实例都共同具有的属性和服务，一次性地在一般类中进行显式的定义。特殊类自 动地、隐含地拥有它的一般类中定义的全部属性和服务。继承原则的好处是使系 统模型简练清晰。 粒度控制：一般来讲，人在面对一个复杂的问题域时，不可能在同一时刻既 第2 章曲向服务的分析j 设计概述 能纵观全局，又能洞察秋毫。因此需要控制自己的视野：考虑全局时，注意其大 的组成部分，暂时不考虑每一部分的具体的细节；考虑某部分的细节时则暂时抛 开其余的部分，既粒度控制原则。 设计过程遵循的原则还有“1 ：模块化；低耦合；高内聚等。 可以发现，面向对象同面向服务一样，也存在抽象、封装和粒度控制等原则。 区别在于，面向对象是以类为单位，面向服务是以服务为单位。面向对象的逻辑 处理单元明显小于面向服务。 2 3 3 面向对象建模活动和过程 面向对象思想具体地分析一个事物时，大致遵循如下五个基本步骤1 ： 第一步，确定对象和类。这里所说的对象是对数据及其处理方式的抽象，它 反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同 属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。 第二步，确定结构。结构是指问题域的复杂性和连接关系。类成员结构反映 了泛化特化关系，整体部分结构反映整体和局部之间的关系。 第三步，确定主题。主题是指事物的总体概貌和总体分析模型。 第四步，确定属性。属性就是数据元素，可用来描述对象或分类结构的实例， 可在图中给出，并在对象的存储中指定。 第五步，确定方法。方法是在收到消息后必须进行的一些处理方法：方法要 在图中定义，并在对象的存储中指定。 2 4 面向服务与面向对象原则的比较 面向对象的思想被广泛用于应用系统的建模，而面向服务的分析设计尚在发 展中，s o a d 与o o a d 的优劣和异同还需要进一步探讨。理解它们的不同有助 于结合两者之长。可以肯定的是两种思想之间不是竞争关系。下面列出两种方法 在设计方面的比较。其中，逻辑处理单元在面向服务中是指服务，在面向对象中 是指对象”。 面向服务强调逻辑处理单元之间的松耦合。虽然面向对象支持可重用、松耦 合的编程程序，但它主要基于预定义的依赖类，产生和逻辑处理单元的紧耦合。 面向服务鼓励粗粒度接口，因此每个通讯单元都包含完成给定任务所需的尽 可能多的信息。面向对象编程完全支持细粒度接口，因此通讯单元能执行各种大 小的任务。 面向服务期望逻辑处理单元的范围可以较大。面向对象中的逻辑处理单元趋 向于在一定范围内更小和更加明确。 北京i 业人学t 学硕i j 学位论文 面向服务更多采用逻辑处理单元进行设计并进可能保持无状态。面向对象鼓 励数据和逻辑的绑定，因此产生有状态单元。 面向服务支持逻辑处理单元的松耦合组合。面向对象也支持组合但趋向于继 承自逻辑处理单元，那会导致依赖紧耦合。 上面从耦合度、接口粒度、关注点、状态等方面对面向服务和面向对象进行 了比较。下面再对两种方法的设计原则进行比较。当然，面向服务还欠缺很多面 向对象已有的概念和理论。下表提供了一般的面向对象原则与已经讨论过的。 表2 - 1 面向服务和面向对象原则的比较1 t a b l e2 - 1c o m p a r a t i o nb e t w e g no o a da n ds o a d 面向服务原则面向对象原则 服务的重用 面向对象人多数情况是创建可重h j 的类模块化分解的面向对象原则 是应_ j 程序的设计方式。相关的原则，如抽象，封装，接口和实现逻 辑的分离。服务重用是这个目标的延续。 服务的契约服务契约的需求和构建面向对象应_ 【i j 中的接口相似。接口提供了一种 提炼类描述的方法，这和w s d l 的定义非常相似。与s o a 鼓励的 w s d l 优先”方法一样，“接口优先”方法也被认为是面向对象的最佳 实践。 服务的松耦合尽管接口的创建一定程度上将类从它的使h j 者解耦，但耦合是面向服 务从面向对象继承到的主要特性。 相对面向服务设计方法，继承和其他面向对象原则造成逻辑处理单元 之间的紧耦合。 服务的抽象面向对象的抽象原则要求一个类提供一个接口给外部世界，并通过这 个接口来访问类。封装通过建立信息隐藏概念来支持这种方式，接口 暴露的类，其内部的任何逻辑都不能被外部访问。 服务抽象可以基本达到对象抽象和封装的程度。它的目标是隐藏服务 的内部细节，因此只有服务契约是可以得到的，服务的请求者也只要 关心服务契约。 服务的组合面向对象支持关联的概念，如聚合和组合。在松耦合的上下文中，这 些概念也被面向服务的方法支持。 例如，可用与对象层次结构组合相同的方法来组合的服务装配服务层 次结构。 可以看到，面向对象和面向服务并非竞争者。面向服务显然在不少方面是以 面向对象为基础，当前典型的面向服务的解决方案将由遵循面向服务的原则构建 服务和面向对象的组件构成。在合理的设计中，每个原则都应当被适当地处理并 能相互补充，只有这样才能更好的完成面向服务的分析与设计。 2 5 本章小结 本章概述了面向服务体系结构的主要概念。从设计原则、建模活动和过程等 方面讨论了传统面向对象分析设计方法。并对现已存在的面向服务分析设计方法 从建模层次、分析原则以及建模活动方面做了综述。最后将面向对象和面向服务 的分析设计进行对比，得出面向对象方法并非对立于面向服务，而应作为其必要 补充的结论。 第3 章远程开放教育系统面向服务的建模方法研究 服务分析、建模工作往往要面对许多已经存在的系统。这些系统经年累月孤 立发展，缺乏弹性，差异很大。而遗留系统往往承载着企业的重要i t 业务，蕴 含着核心流程和战略，是企业不可或缺的软件资产；另一方面，遗留系统一般都 进行过大量分析和设计，分析方法科学，分析成果很多。可见，如何能充分利用 原有系统，从中挖掘有意义的分析设计成果：如何能够充分重用遗留系统软件资 产，是s o a d 研究面临的现实问题。探索该问题对遗留系统向s o a 迁移工作有 现实意义。 本章主要讨论服务的分析方法，下一章讨论服务的设计和实现。我们将服务 分析过程分为三步骤。第一步，确立服务建模的参考架构。第二步，针对参考架 构进行基本服务的分析和建模。最后，利用识别出的底层服务，进行流程服务的 分析和建模。 3 1 系统服务模型的建立 进行s o a 服务建模首先应建立远程开放教育系统的服务参考架构。该架构 应兼顾运作的敏捷性、信息需求的多样性、数据系统的异构性以及良好的扩展性。 架构应当对服务粒度的确定、服务类别的划分以及服务之间相互作用、相互关系 的确定等有很强指导作用。如图3 - 1 所示，是远程开放教育信息系统的建模参考 架构。 图3 - 1 基于s o a 的远程开放教育信息系统服务建模参考架构 f i g u r e3 - 1m o d e l i n gr e f f e r a n c ea r c h i t e c t u r eo f r e m o t eo p e l le d u c a t i o ns y s t e mb a s e do ns o a 总体来看，参考架构包括基本服务层和业务流程服务层两部分。其中，基本 服务层是由数据访问服务、共享业务服务、公共基础服务和专用业务服务四部分 组成。 3 1 1 基本服务层 数据访问服务：建立统一的业务数据模型，为远程开放教育信息系统提供统 一的数据视图，隔离应用与底层数据源，通过服务基础环境以标准存取方式提供 服务给其它层服务调用或用户应用直接使用。 共享业务服务：根据业务逻辑，对核心业务进行梳理和整合，把业务活动分 离抽象成可共享的、基于标准的服务，为上层应用提供相对独立的业务服务。共 享业务服务粒度通常较小，而复用性强啪1 。通常可在同领域的系统中得到重用， 是企业重要的软件资产，同时也是开发者最需要积累的具有领域特征的软件资 产。 公共基础服务：提供非功能性、与业务无关的服务，为其他各层服务的实现 提供底层支持。例如，远程开放教育系统中的文件压缩解压缩、日志审计处理、 报表打印等。公共基础服务层因其与业务无关的特征，相对共享业务服务具有更 广的复用性。 专用业务服务：封装了特定任务或业务逻辑的服务。当业务逻辑比较固定， 且没有复杂到有必要引入流程服务的时候，我们使用专用业务服务。此类服务依 赖于底层服务，通过将底层服务连接起来完成特定任务。专用业务服务较大的粒 度通常导致其复用性较低，但外界不必调用多个细粒度服务来完成特定任务，减 少了由此带来的开销。 3 1 2 业务流程服务层 业务流程服务层：根据业务流程的变化，面向客户需要和业务过程组成较高 层次的复合应用，通过调用下层多种服务，最终向用户提供功能。业务流程服务 将流程逻辑同业务逻辑分离开来，为建立灵活的1 1 r 系统打下基础汹岫1 。 连接业务分析与架构设计 以往，流程分析师使用建模工具设计流程，产生图表交给架构师和开发者。 开发者只能通过工作流程图及其相应文档来传达流程逻辑。要想准确的实现流 程，架构师和开发者必须认真刻苦分析文档和图表，而且要有很强的业务有关的 专门知识。即便这样，设计人员的意图也不一定能被开发者完全掌握，为误解的 产生留下了机会。 编排服务层的建模允许分析师和开发者共同参与流程的设计。分析人员对业 务流程需求进行分析，确保编排服务层为企业提供必须的功能。同时，开发人员 自下而上地寻找服务资源对流程的支持，首先审查现有专用业务服务及各种底层 第3 币远程开放教育系统血向服务的建模方法研究 服务，如果必要还可以开发新服务。继而将这些服务连接起来。 流程服务设计与专用业务服务设计有类似之处。他们都通过将底层服务粘合 在一起来提供业务功能。专用业务服务是针对比较固定的业务建立的，以完成某 一单一专门的功能为目的，在此复用性不是首要考虑的因素，其建模和设计主要 局限于r r 系统内部。流程服务一开始就从高处着眼，本身并没有专一固定的功 能，而是从电大的战略出发，以管理系统的角色对企业业务流程提供支持。它超 越了i t 部门，紧密地同业务分析人员配合。可以说，流程服务是多变的，而这 种多变为基于s o a 架构的系统提供了优势。 流程服务层的其它突出优势 减轻底层服务约束的设计，而将约束集中在这一层： 可将共享业务服务和专用业务服务设计为与流程无关的和可重用的； 流程服务具有极大的有状态性，从而进一步使其他服务摆脱状态管理； 业务流程集中在单一位置，而不是跨越多个设备分布。易于更改流程，使i t 系统对业务快速反应或引入新流程。因为更改只限于编排服务层，其它可保 持不动； 专用业务服务可以在多个编排服务中得到重用。既减少了研发维护服务的数 量，减少了冗余；又避免了同种业务在各个流程中不一致的现象1 。 3 2 基本服务层的分析和建模 3 2 1 基本服务建模方法研究 确立参考架构后，则应依照架构进行建模，即服务和流程的识别和指定。服 务建模的本质是对信息进行组织的一种演练啪1 。通过对信息的分析、抽象，提炼 出一系列具有复用性和自治性的服务并确定它们的相互关系。 在建模过程中，信息的来源以及如何对信息进行分析是重要问题。从遗留系 统迁移到s o a ，如果抛弃原有文档，则不利于充分掌握原有系统，是对时间和 人力的浪费。遗留系统中很大部分是经过面向对象的分析设计方法建立起来的。 活动图、用例图、业务流程图和遗留系统程序模块、软件组建等相关文档会广泛 存在并蕴含建模所需的丰富信息。 在处理真实世界的系统用上下双管齐下的方法将会比单纯的自顶向下或者 由下向上的方法更有优势。由下至上的方法会导致不良的商业服务抽象，使其设 计更多是听从于现有系统，而不是去实现现有系统或者未来需要的需求。而有项 向下将会脱离现有的系统而产生不适合的需求。 综上，我们提出一个从中问服务层建模开始，自中间向上和自中间向下相结 北京t 业人学t 学硕j 学位论文 合，充分利用遗留系统分析成果的新的服务建模方法。 中间建模 共享业务服务和公共基