【毕业学位论文】（Word原稿）项目汇报管理平台的设计与实现-软件工程

硕士学位论文 （专业学位） 项目汇报 管理 平台 的设计与实现 姓 名： 杨萨如拉 学 号： 所在院系：软件学院 学科门类：计算机科学与技术 学科专业：软件工程 指导教师：杜庆峰 校外导师： 邓业云 二一 一 年 三 月 A in he to 0821170173 u 2011 项目汇报管理平台的设计与实现 杨萨如拉 同 济 大 学 学位论文版权使用授权书 本人完全了解同济大学关于收集、保存、使用学位论文的规定，同意如下各项内容：按照学校要求提交学位论文的印刷本和电子版本；学校有权保存学位论文的印刷本和电子版，并采用影印、缩印、扫描、数字化或其它手段保存论文；学校有权提供目录检索以及提供本学位论文全文或者部分的阅览服务；学校有权按有关规定向国家有关部门或者机构送交论文的复印件和电子版；在不以赢利为目的的前提下，学校可以适当复制论文的部分或全部内 容用于学术活动。 学位论文作者签名： 年 月 日 同济大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下，进行研究工作所取得的成果。除文中已经注明引用的内容外，本学位论文的研究成果不包含任何他人创作的、已公开发表或者没有公开发表的作品的内容。对本论文所涉及的研究工作做出贡献的其他个人和集体，均已在文中以明确方式标明。本学位论文原创性声明的法律责任由本人承担。 学位论文作者签名： 年 月 日同济大学 硕士学位论文 摘要 摘要 在当前工程领域，项目管理软件已经成为工程项目普遍使用的管理手段之一。作为业主方来讲，要求施工方使用项目管理软件管理工程项目已经成为行业规则。但是，目前面临的问题是施工方使用的项目管理软件种类繁多，缺乏统一的标准，项目管理牵涉范围广、内容多 ，也无法要求实施方有统一的项目管理软件。这样，在客观上 业主方对自己名下多项工程项目缺乏统一的信息化的管理监督手段。 本文在上述背景下，针对项目管理中汇报和沟通的主题，进行项目管 理软件的设计与实现。首先，在访谈的基础上，对项目汇报 管理软件的需求进行了分析，按照业务内容模块化功能。 随后，从需求模块、系统界面和数据库方面进行了系统的设计。最后简述了平台的实现过程及对平台进行了一定的测试，来验证平台的可行性。本文的论述的软件工程方法，可以给软件项目的开发进行必要的指导，而且项目汇报管理软件也是项目管理软件类别的一个重要的补充，具有实用价值。 关键词： 项目管理 软件工程 项目汇报管理 n of As is a of by of a of so of So,of a a of In to in of of on of in of to to of is to of is an to 济大学 硕 士学位论文 目录 I 目录 第 1章 概述 . 3 究背景和意义 . 3 目汇报管理平台的概念和作用 . 3 文的研究内容和组织结构 . 4 第 2章 关键技术介绍 . 5 特图（ . 5 特图的概述 . 5 能树 . 6 能说明 . 6 作流技术介绍 . 8 件体系及数据总线技术介绍 . 11 限模型 . 12 则引擎技术介绍 . 15 术介绍 . 15 术介绍 . 19 第 3章 需求分析 . 23 体需求分析 . 23 务范围 . 23 统功能需求分析 . 24 体功能结构分析 . 24 统初始化 . 27 度管理 . 30 程资料管理 . 32 . 33 功能性需求分析 . 36 据需求分析 . 37 第 4章 项目汇报管理平台的设计 . 37 统体系架构设计 . 37 要功能的设计 . 38 户登录验证模块 . 38 统初始化模块设计 . 39 度管理模块设计 . 41 同济大学 硕士学位论文 目录 工程资料管理模块设计 . 42 同办公模块设计 . 43 统管理模块设计 . 43 统界面设计 . 44 面布局说明 . 45 台操作错误提示举例 . 45 统数据库设计 . 46 表【系统初始化模型】 . 47 表【进度资料模型】 . 49 表【工程资料管理模型】 . 50 表【协同办公模型】 . 51 第 5章 项目汇报管理平台的实现与测试 . 55 统主要功能的实现 . 55 据总线的实现 . 55 户登录验证模块的实现 . 63 作流的实现举例 . 66 期管理功能的实现举例 . 69 档在线查看的实现举例 . 75 统界面展示 . 83 台的测试与结论 . 89 . 89 . 89 . 111 . 113 . 114 统运行环境 . 114 第 6章 结论与展望 . 115 论 . 115 望 . 115 致谢 117 参考文献 . 118 项目汇报管理平台的 设计 与实现 3 第 1 章 概述 究背景和意义 在当前工程领域，项目管理软件已经成为工程项目普遍使用的管理手段之一。作为业主方来讲，要求施工方使用项目管理软件管理工程项目已经成为行业规则。但是，目前面临的问题是施工方使用的项目管理软件种类繁多，缺乏统一的标准，项目管理牵涉范围广、内容多，也无法要求实施方有 统一的项目管理软件。这样，在客观上对业主方对自己名下多项工程项目缺乏统一的信息化的管理监督手段。 目前，各业务方用的监督管理方式都是以定期会议的方式，或要求施工方定期提交件，以 格形式提交进度、成本等信息。这样的方式缺乏时效性，也很难有准确的数据判断，无法实时掌握施工方的具体情况，从而也无法有效支持业主方对工程项目的监督管理。 目汇报管理平台的概念和作用 项目汇报管理平台是通过一套统一简单快速的软件平台，能够实时采集施工方的施工进度、提交文档、成本等信息，供业主方、监理方、材 料供应方、施工方使用，集中管理施工项目的统一管理平台。 项目汇报管理平台要求施工方实时填报项目进度、按照计划提交项目文档、统计项目成本等，业主方能够通过项目汇报管理平台实施查看工程项目的各种进度信息，监理方也可以查看到监理相关的信息和数据，材料方可以通过进度确定材料使用情况，以便及时供应材料。 与传统项目管理软件相比，项目汇报管理平台有以下特点和不同： （ 1） 简单性 项目汇报管理平台涉及到的内容仅为业主方、监理方关心的项目内容，而不是所有的项目管理内容。 （ 2） 实时性 通过项目汇报管理平台，业主方能够实 时掌握施工项目的进度情况，彻底改变了通过电话、报表等传统人工手段了解的方式，从而能够更加准确的了解和监控项目，提高了对自己施工项目的管理监督水平。 （ 3） 统一性 项目汇报管理平台给业主方、施工方、监理方提供了一个统一的施工项目进度管理平台，方便各单位协同办公。 同济大学 硕士学位论文 目录 4 （ 4） 集成性 通过项目汇报管理平台和各种项目管理软件的集成，能够方便的把施工方的数据准确实时的同步到项目汇报管理平台，并未给施工方带来额外的工作量。 文的研究内容和组织结构 本论文以工程项目的实际沟通需要，研究项目汇报管理平台的主要功能 ，平台采用的实现技术及设计架构。 本文的章节如下： 第 1章概述，主要讲述了论文的研究背景及意义， 项目汇报管理平台的基本概念和平台的作用。 第 2章 项目汇报管理平台涉及的关键技术， 主要介绍了 甘特图、规则引擎技术、 工作流 引擎 技术 、 据库技术以及平台的开发工具 第 3章 项目汇报管理平台需求分析，描述了平台的总体需求和总体功能结构，并分析了系统初始化、进度管理、工程资料管理、协同办公等主要模块。 第 4章 项目汇报管理平台的设计，详细 论述了 项目汇报管理平台用户登录验证、系统初始化、进度管理、工程资 料管理、协同办公模块的设计，介绍了界面的设计过程以及数据库的设计过程 。 第 5章项目汇报管理平台的实现和应用。介绍了平台主要功能的实现，包含了部分的代码，描述了平台的测试和应用环境，给出了应用结论。 第 6章 结论与展望，关于本论文设计过程的 总结 和对平台未来发展的展望 。 项目汇报管理平台的 设计 与实现 5 第 2 章 关键技术 介绍 特图（ 在项目管理中，甘特图的应用非常普遍 。 通过甘特图的使用，能够大大提高项目任务进度的直观性， 改善了用户界面的友好性，同时基于甘特图的任务关系的图形化操作，也使的项目功能操作的性更为直 观和方便。 特图 的 概述 甘特图（ 叫横道图、条状图 (它是在第一次世界大战时期发明的，以亨利 L 甘特先生的名字命名，他制定了一个完整地用条形图表进度的标志系统。甘特图内在思想简单，即以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。基本是一条线条图，横轴表示时间，纵轴表示活动（项目），线条表示在整个期间上计划和实际的活动完成情况。它直观地表明任务计划在什么时候进行，及实际进展与计划要求的对比。管理者由此可便利地弄清一项 任务（项目）还剩下哪些工作要做，并可评估工作进度。 甘特图组件实现了作业计划显示、跟踪信息显示等功能，其甘特图信息逻辑模型为： 甘特图条：代表一个具体的任务，具有开始时间、结束时间、详细信息等内容； 甘特图组：代表一个甘特图条的集合，该集合内的甘特图条均在一行中显示； 甘特图集：代表一个甘特图组的集合，该集合内具有集合名称、甘特图组等信息内容； 甘特图视图：代表一个甘特图集的集合，该集合内具有视图名称、甘特图集等信息内容； 甘特图条关系：甘特图信息中某两个或几个甘特图条具有的连接关系。 甘特图组件包含两个核心部分： 1） 甘特图信息的显示：如任务条、机器名、时间标尺、任务信息的显示等； 同济大学 硕士学位论文 目录 6 2） 甘特图显示信息的控制：实现当任务条拖动时控制其它任务条的显示控制、双击任务条的显示控制、不同任务条组的显示等功能。 该甘特图组件设计成 一组通过 现的 类，当程序需要使用该甘特图组件时， 通过在页面上引用 文件来加载这些类 。 能树 甘特图组件功能树如 图 图 特图组件功能树 能说明 甘特图显示 甘特图显示功能为甘特图组件核心功能之一，其根据 配置信息和甘特图信息，将各个甘特图条显示在界面上。甘特图组件的显示区域分为四个区域，如图 图 一个甘特图显示实例，可参考），分别为： 1） 控制区域： 控制区域实现了甘特图组件显示的动态调整（快捷配置）功能，包括： 显示甘特图配置界面； 时间标尺显示粒度控制； 当前时间显示； 是否显示关系线； 各个甘特图集中甘特图组的显示控制。 2） 甘特图视图区域： 同济大学 硕士学位论文 目录 7 甘特图视图区域实现了甘特图信息中甘特图视图名称的显示，当用户激活某个甘特图视图时，甘特图条区域显示该甘特图视图所包含的甘 特图集、甘特图组和甘特图条等信息。 3） 甘特图条区域： 甘特图条区域将甘特图集的名称显示在区域的最左边，对应每个甘特图集，将该集内包含的甘特图组按行显示，并在每行内显示该甘特图组内的甘特图条信息。甘特图条具有可拖动、可双击等功能。甘特图条区域 4） 时间标尺： 时间标尺的显示粒度可根据配置信息进行改变，也可通过控制区域的时间标尺显示粒度控制而进行改变，当时间标尺的显示粒度改变时，甘特图条区域的各个甘特图的显示需进行相应的变化。时间标尺显示粒度动态变化规则为： 显示粒度分为分钟、小时、天，在时间标尺第一 行显示； 显示细度为一整数，有配置界面设定，在时间标尺第二行显示为柱状小标尺； 时间标尺最左方根据显示粒度，显示粒度的总体信息。 甘特图显示配置 甘特图显示配置其中： 视图标题名称配置可改变甘特图视图区域的甘特图视图标题信息； 时间标尺显示粒度可选择分、时、日进行配置； 时间标尺显示细度可设置成一个合理的正整数； 甘特图集显示组数可设置成 1 到 10 之间的正整数，从而控制甘特图条区域每个甘特图集中显示的甘特图组的数量； 是否显示关系线可控制是否在甘特图区域中将甘特图条之间的关系用线连 接起来。 甘特图动态配置 甘特图动态配置功能对应控制区域，其基本为一个甘特图显示配置的子集，可视为一类配置功能的快捷方式。 甘特图信息管理 甘特图信息管理根据甘特图信息的逻辑模型，实现了对甘特图信息的管理功能，包括： 增加甘特图条、甘特图组、甘特图集和甘特图视图、甘特图条关系等功能； 删除甘特图条、甘特图组、甘特图集和甘特图视图、甘特图条关系等功能； 同济大学 硕士学位论文 目录 8 修改甘特图条、甘特图组、甘特图集和甘特图视图、甘特图条关系等功能； 甘特图条的显示模式维护，如甘特图条高度、显示信息、显示颜色等； 甘特图条移 动控制 甘特图条移动控制实现了当在界面上拖动甘特图条或双击甘特图条时的显示控制功能。其中： 拖动甘特图条：甘特图条的拖动需实现实时拖动效果，其拖动可在该甘特图所在行中进行左右拖动，也可在各个甘特图行中进行上下拖动。当拖动过程结束后，需判断甘特图条是否可在该释放位置上，如果不可行，则取消此次拖动，如果可行，则进行与此次拖动相关的各个其它甘特图条的移动。判断是否可行和其它甘特图条的移动均需由使用该甘特图组件的程序进行配置； 双击甘特图条：当双击甘特图条后，需弹出甘特图条信息窗口显示甘特图信息，除甘特图基本文 字信息外，也可显示图片等信息。 作流 技术 介绍 在项目的审批汇报中，需要 有 相应的 业务 流程。 为了适应流程的多变性，本项目开发中决定采用业务流程来处理系统中的流程需求。 工作流技术介绍 随着社会生产的流程化，工作流起着越来越重要的作用。根据 定义，工作流（ 是自动运作的业务过程部分或整体，表现为参与者对文件、信息或任务按照规程采取行动，并令其在参与者之间传递。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。 流程管理方面， 最直接有效地满足需求方法就是采用工 作流解决方案。工作流解决方案把流程定义和业务操作分离开来，使得流程可以相对独立。这样在流程发生变化的时候，不至于修改所有的业务功能和逻辑。只需要通过相应的流程定义进行流程变化的调整，就可以直接变更系统相应的业务处理流程，因而采用工作流是灵活应对流程需求的最简单有效的解决方案。 同济大学 硕士学位论文 目录 9 开源的一款轻量级工作流解决方案。是基于现有各中工作流系统和理论建立起来，主要是根据实际项目应用中常见的流程需求，满足最基本需求的工作流体系。 要包括流程定义、 置、流程执行执行引擎、 流程监控、流程查询等部分。 结构图 ，如图 示： 图 作流功能特点图 流程定义 流程定义包含了所有使业务流程 能被工作流 控制之星 的必要信息。这些信息 包括起始和终止节点、各个组成节点、节点流向规则 、各业务的参与者 的使用权限 等。 流程定义需要定义流程基本信息、详细流程定义、流程节点属性定义、流程权限等。 系统提供简单的图形化流程定义工具，界面如 图 示： 同济大学 硕士学位论文 目录 10 图 作流流程设计示意图 流程基本信息包括：流程编号、流程名称、流程描述、是否修 改、活动状态、相关业务对象等信息。 流程节点信息包括：节点编号、节点名称、节点描述、节点类型、权限类型、流向类型、节点文本、相关面板、相关服务等信息。 流程节点流向信息包括：起始节点、下一结点、流向条件等信息。 流程权限包括：流程编号、节点编号、操作编号、权限拥有角色或用户或用户组等。 置 流程定义好后，流程的各个操作需要在不同的业务操作界面中调用，才能启动工作流，并通过相应的具有操作权限的人员的操作，决定工作流的流向和处理结果。 需要把工作流相应的需要人工交互的节点，配置在相应的业务处理界面中，这样 实现了流程和界面集成的配置化，无代码化，同时在灵活配置方面具有最大的灵活性。 流程执行引擎 工作流 流程执行 引擎是 核心部分 。它的功能包括：解释 流程定义，创建流 程实例并控制其执行 过程 ，调度各项活动，为用户工作表添加工作项，通过应用程序接口（ 用应用程序，提供监督和管理功能等。 同济大学 硕士学位论文 目录 11 流程监控 流程监控是用户用来查看流程实例执行情况的入口，通过流程监控，可以随时对正在执行过程中的工作流示例进行查看监控，真对流程执行中的各种 事件进行及时的处理。 流程查询 流程查询是对执行后所有的流程历史数据进行查询。流程查询能够查看流程执行过程中所有的详细信息，包括示例各节点的处理记录信息等。并且能够通过相关的业务信息直接查看业务状况。 件体系 及数据总线技术介绍 为了满足系统的扩展需求，同时考虑到平台扩展和变更的灵活性，在系统内部采用微内核技术，外部用总线加插件的架构模式构建各种应用组件。这种方式保证了系统插件的最大灵活性，也保证了系统插件间的“零依赖性”。对于系统的扩展和变更非常的方便， 插件体系结构 如 图 图 件体系结构图 插件式体系结构是一种非常灵活的组件式结构， 通过科学的分析系统功能，按照功能的内敛型，分别设计为不同的功能插件。 插件是 符合系统插入接口的可独立开发程序模块或组建，能够方便快速的动态的插入系统中， 并且插件可同济大学 硕士学位论文 目录 12 以被自由地插入 、删除和替换 ，并不影响系统其他插件和系统底层系统 。因此它 在系统的维护和扩展时，具有非常突出的灵活性和方便性， 能够提高软件开发的并行性和开发效率，降低设计开发难度，缩短开发周期， 增强应用程序的可运行性、可测试性和可维护性。 数据总线 数据总线将作为项目汇报平台的各种数据交互的唯一 途径，从而在架构上解耦了系统插件间相互依赖的关系，使得系统插件扩展和替换基本不会影响现有其他插件。数据总线存在存、取两种操作。 数据总线的生命周期是是 就是说从用户会话开始到用户会话结束数据总线是一贯和连续的。数据总线是线程独享的、线程安全的，一个线程对数据总线的改变不会影响到其他线程对数据总线的使用，每个线程都是使用的总线的副本。 插件和总线的关系如 图 图 线技术示意图 限模型 本项目中对于权限模型的需求以功能权限为主，经过分析决定采用业界比较流 行和通用的 限模型，该权限模型基本覆盖了项目中的权限定义和使用需求，下面详细介绍一下 型。 权限管理使用的权限模型是综合考虑多种权限应用经过进一步抽象分析所采取的相对通用的一种模型。也是业界最为通用的模型，即 基于角色的访问控制（ 模型。采用这种模型基本可以满足各种业务应用的权限分配和管理需求。 同济大学 硕士学位论文 目录 13 介 基于角色的访问控制（ 入了 概念 ,目的是为了隔离 动作主 体， 限，表示对 一个操作，即 为一个用户 (权限 (代理层，解耦了权限和用户的关系，所有的授权应该给予 不是直接给 权限颗粒，由 成，表示对 一个 如，对于新闻的删除操作。 关系，这就是权限的核心。 基于角色的访问控制方法（ 显著的两大特征是： 权限之间的变化比角色 /用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。 对企业的变化有很大的伸缩性。 本概念 为权限授权实际上是 问题。在 型中， 成了访问权限三元组 ,也就是“ 行 操作”。 限的拥用者或主体（如 限针对的对象或资源（ 体的权限（ 向授权与负向授权）。 作。表明对 作。也就是 色，一定数量的权限的集合。权限分配的单位与载体 ,目的是隔离 逻辑关系 . 户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组 (以实现权限的继承 )，也可以包含用户，组内用户继承组的权限。 多对多的关系。 以层次化，以满足不同层级权限控制的要求。 关注点在于 关系。称为 A) 和 A). 关 系 的 左 右 两 边 都 是系。就是 以有多个 以包括多个 凡是用过 知道， n:m 的关系需要一个中间表来保存两个表的关系。这 相当于中间表。事实上，整个 是基于关系模型。 同济大学 硕士学位论文 目录 14 是比较隐晦的一个元素。标准上说：每个 一个映射，一个用户到多个 映射。当一个用户激活他所有角色的一个子集的时候，建立一个 个 单个的 联，并且每个 以关联到一或多个 在 统中， 际上是在扮演角色 (可以用 取代个想法来自于 书 式。考虑到多人可以有相同权限， 入了 概念。 样也看作是 概念就具象到一个人。 这里的 的 ）不同。 用于操作系统中。其中的 接和权限相关联，实际上 概念。 和组织机构有关，但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构一般用 责任模式来建模。 式中的 关系，是每个 以对应到一个 可能不是所有的 有对应的 的部门 组织可以对应到 之 必对应一个实际的机构。例如，可以有副经理这个 是多人有相同职责。 引入 个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：例如， A 部门的新闻我希望所有的 A 部门的人都能看。有了这样一个 A 部门对应的 可直接授 权给这个 示意图如 图 示： 图 型示意图 同济大学 硕士学位论文 目录 15 则引擎 技术介绍 随着企业级应用的复杂化 ,需求不断的随着业务规则的变化而变化 ， 使得企业应用中的业务逻辑需要同开发人员的技术架构相分离 ， 需要将这些业务规则从软件中抽取出来 ,进行集中的管理 ,使之能够在不同的时段 (包括运行时 )， 可以动态的对业务规则进行修改 ,而不用 修改和维护系统， 规则引擎基于此目的而提出的 。 规则引擎可以看作是一套软件组件 ， 它负责将应用程序中的业务规则 (业务逻辑 )抽取出来 ， 使用预定义的语义模块编写业务决策 ， 可以 接受数据输入并对业务规则 (业务逻辑 )。 软件工厂创建的系统中的服务支持规则引擎，可以灵活定义服务之间的执行规则，规则引擎将自动解析业务规则来实现复杂的企业业务逻辑。通过业务规则的抽取定义和隔离，大大 降低 了 实现复杂业务逻辑的复杂性，降低 了 应用系统 的维护和可扩展性成本。 技术介绍 为了保证系统具有优良的可集成性和可扩展性，内部采用 技术，也就是说系统内部的业务性功能点均能够方便的进行 装，供外部调用继承，也保证了系统架构 的清晰性。 面向服务的体系结构（ 叫面向服务架构）是指为了解决在 境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。 一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 在软件技术的发展过程 中，体系架构经历了 如图 示的 发展历程： 单片机编程结构化编程客户/服务器三层结构多层结构分布式结构组件架构面向服务架构图 系架构发展历程图 同济大学 硕士学位论文 目录 16 面向服务的体系结构（ 一个组件模型，它将应用程序的不同功能单元（称为 服务 ）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、 组合和使用。服务层是 以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。 一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。 以看作是 B/S 模型、术之后的自然延伸。 能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以 构的系统能够更加从容地面对业务的急剧变化 。 体系结构 基于 系统是一种 松耦合的系统 ， 这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改 变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（ On 务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。 虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。统原型的一个典型例子是通用对象请求代理体系结构（ 济大学 硕士学位论文 目录 17 它已经出现很长时间了，其定义的概念与 似。 然而，现在的 经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（ 基础的。通过使用基于 语言（称为 务描述语言（ 来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 的接口描述语言（ 比了。 务并不是实现 惟一方式。前面刚讲的 另一种方式，这样就有了面向消息的中间件（ 统，比如 是为了建立体系结构模型，您所需要的并不只是服务描述。您需 要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此， 该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 设计中扮演重要的角色。 此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略 ，这种策略常常采用服务级协定和操作策略的形式。 最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 都起着重要的作用。 体系结构作用 我可以用面向服务的体系结构做什么？ 对 需要来源于需要使业务 统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现， 统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。 下面举一个具体的例子。一个服装零售组织 拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的