（计算机软件与理论专业论文）mvc设计模式和hibernate在bs架构呼叫中心业务系统中的研究.pdf

摘要 随着具有优秀跨平台性的j 2 e e 平台的出现和发展，越来越多的w e b 应用开 始在j 2 e e 平台上进行开发。作为j 2 e e 平台主要组成部分之一的j s p ，逐渐受到 了开发者的广泛青睐。j s p 技术规范给出了两种使用j s p 开发w e b 应用的方式： m o d e l1 和m o d e l2 ，两者主要差别在于它们处理业务的流程不同。从设计结构来 看，m o d e l2 充分体现了模型一视图控制器m v c 的设计模式，具有更清晰的页 面表现，更清楚的开发角色划分，可充分发挥开发团队中的网页设计人员和j a v a 开发人员的才干。这些优势在大型项目中表现得尤为突出。 另外，也有不少成熟的组件解决了开发人员一直关注的数据访问层的问题。 h i b e r n a t e 是一种开源的o rm a p p i n g 技术，对j d b c 进行了轻量级的封装，解决 了很长时间一直困扰开发人员的问题，大幅度减少开发时人工使用s q l 和j d b c 处理数据的时间。 本论文结合福州邮政1 1 1 8 5 呼叫中心业务系统的开发，就m v c 设计模式和 h i b e r n a t e 框架技术的应用展开论述，介绍了该系统纵向上各个业务模块、横向上 各个层次的设计和实现，其中对该系统中数据持久层的设计进行了详细介绍。 最后本论文就呼叫中心业务系统开发中存在的重复开发的问题，提出了一种 可重用的呼叫中心业务系统框架的设计方案。该设计方案从众多呼叫中心业务系 统中抽象出共同的系统管理功能，形成一个基本的与业务无关的系统框架，提高 了代码的可重用性。 关键词：m v co 础h i b e r n a t e 可重用框架 a b s t r a c t w i t ht h ee m e r g e n c ea n dd e v e l o p m e n to fj 2 e ep l a t f o r m ，w h i c hh a sa no u t s t a n d i n g c h a r a c t e ro fc r o s s p l a t f o r m ，ag r o w i n gn u m b e ro fw e ba p p l i c a t i o n sa r ed e v e l o p e d 晰t l l t h ej 2 e ep l a t f o r m a sam a j o rc o m p o n e n to fj 2 e ep l a t f o r m ，j s ph a sr e c e i v e d d e v e l o p e r s w i d e s p r e a df a v o rg r a d u a l l y t h ej s ps p e c i f i c a t i o n sp r o v i d et w ow e b a p p l i c a t i o nd e v e l o p i n gm o d e l s 谢t i lj s p ：m o d e l1a n dm o d e l2 ，t h em a j o rd i f f e r e n c e b e t w e e nt h et w om o d e l si st h a tt h e yd e a lw i t hb u s i n e s sp r o c e s s e sd i f f e r e n t l y f r o mt h e a n g l eo fd e s i g ns t r u c t u r e ，m o d e l2f u l l ye m b o d i e st h em o d e l - v i e w - c o n t r o l l e rd e s i g n p a t t e r n , i th a sam o r ec l a r i t yo np e r f o r m i n gw e bp a g e sa n dd i v i d i n gd e v e l o p e r s 、) l ，i t h d i f f e r e n tr o l e s ，t h e r e f o r ei tc a ng i v ef u l lp l a yt ot h et a l e n to fw e bp a g ed e s i g n e ra n d j a v ad e v e l o p e r s t h e s ea d v a n t a g e sw e r ep a r t i c u l a r l yc o n s p i c u o u si nl a r g e s c a l ep r o j e c t d e v e l o p m e n t i na d d i t i o n , t h e r ea r er e s p e c t a b l em a t u r ec o m p o n e n t ss o l v et h ep r o b l e mo fd a t a a c c e s sl a y e r , w h i c hh a sa l w a y sb e e nc o n c e m e db yt h ed e v e l o p e r s h i b e r n a t ei sao r m a p p i n gt e c h n o l o g y 、i t i ls o u r c eo p e n e d ，i th a se n c a p s u l a t e dj d b ci nl i g h t w e i g h t s c a l ea n dh a ss o l v e dt h ep r o b l e mt r o u b l e d d e v e l o p e r s f o rav e r y l o n gt i m e ， s i g n i f i c a n t l yr e d u c et h et i m es p e n to nd a t ap r o c e s s i n gw i t hs q la n dj d b ca r t i f i c i a l l y i nt h i sp a p e r , 、 ，i t l lt h ed e v e l o p m e n to ff u z h o up o s t1118 5c a l lc e n t e rb u s i n e s s s y s t e m ，t h em v cd e s i g np a t t e ma n dh i b e m a t ef r a m e w o r kt e c h n o l o g yi sd i s c u s s e d ，t h e d e s i g na n dr e a l i z a t i o no ft h eb u s i n e s sm o d u l e so nv e r t i c a ld i r e c t i o na n dt h el e v e l so n h o r i z o n t a ld i r e c t i o no ft h es y s t e ma r ei n t r o d u c e d i nw h i c ht h ed e s i g no ft h ed a t a p e r s i s t e n c el a y e ri nt h es y s t e mi sd e s c r i b e di nd e t a i l f i n a l l ya i m i n ga tt h ep r o b l e mo fd e v e l o p m e n td u p l i c a t i o ne x i s t si nd e v e l o p m e n to f c a l lc e n t e rb u s i n e s ss y s t e m s ，ac o m m o nr e u s a b l ec a l lc e n t e rb u s i n e s s s y s t e m f r a m e w o r kd e s i g ns c h e m ei sp u tf o r w a r di nt h i sp a p e r t h ed e s i g ns c h e m ea b s t r a c t s c o m m o ns y s t e mm a n a g e m e n tf u n c t i o nf r o man u m b e ro fc a l lc e n t e rb u s i n e s ss y s t e m s a n df o r m sab a s i cs y s t e mf r a m e w o r kw h i c hh a sn or e l a t i o n s h i pw i t hb u s i n e s sa n d i m p r o v e st h ec o d er e u s a b i l i t y k e y w o r d ：m v co r m h i b e r n a t er e u s a b l e - f r a m e w o r k 创新性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不 包含其他人已经发表或撰写过的研究成果；也不包含为获得西安电子科技大学或 其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做 的任何贡献均已在论文中做了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名： 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究 生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。本人保证毕 业离校后，发表论文或使用论文工作成果时署名单位仍然为西安电子科技大学。 学校有权保留送交论文的复印件，允许查阅和借阅论文；学校可以公布论文的全 部或部分内容，可以允许采用影印、缩印或其它复制手段保存论文。( 保密的论文 在解密后遵守此规定) 本学位论文属于保密，在一年解密后适用本授权书。 本人签名： 导师签名： 日期： 同期： 如煳学；一 第一章绪论 第一章绪论 1 1 课题研究的主要内容 作者在参与福州邮政1 1 1 8 5 呼叫中心业务系统的开发过程中，研究了目前使 用j s p 开发w e b 应用的主流方式m o d e l2 以及m o d e l2 的基础- c 设计模 式，并学习了m v c 中的三种主要设计模式o b s e r v e r 模式、c o m p o s i t e 模式和 s t r a t e g y 模式。 由于福州邮政1 1 1 8 5 呼叫中心业务系统的数据持久层是使用著名的对象关系 数据库映射工具h i b e m a t e 组件，作者也对对象关系数据库映射的原理、优 缺点以及h i b e m a t e 的体系结构、主要a p i 、基本配置进行了深入研究。 最后，作者针对呼叫中心业务系统的开发中存在的重复开发系统管理模块的 问题，研究了基于b s 架构的呼叫中心业务系统可重用框架设计的可行性。 1 2 主要工作 作者参与了福州邮政1 1 1 8 5 呼叫中心业务系统数据持久层的设计与实现，并 且负责该呼叫中心业务系统的用户登录、用户个人信息管理、角色信息管理等部 分系统管理模块和e m s 揽收、预约投包、订单催办、订单处理等业务模块的开 发、设计与实现。 作者还针对呼叫中心业务系统开发过程中存在的诸如重复开发的问题，提出 了一种通用的呼叫中心业务系统框架的设计方案。该设计方案对各种业务系统进 行了抽象，形成了通用的系统管理框架。该框架与业务无关，具有很强的通用性： 并且该框架基于b s 的架构，易于扩展，满足了需求不断变化的呼叫中心业务系 统的要求。开发者可以在该系统框架的基础上，开发与具体业务逻辑相关的功能 模块，形成一个完整的呼叫中心业务系统。 1 3 章节安排 本文共五章，其余章节为： 第二章为m v c 模式和h i b e r n a t e 研究，简要介绍了福州邮政1 1 1 8 5 呼叫中心 业务系统开发中应用的m v c 设计模式和h i b e r n a t e 对象关系数据库映射工具。 第三章为福州邮政1 1 1 8 5 呼叫中心业务系统设计与实现，主要叙述了福州邮 2 m v c 设计模式和h i b e r n a t e 在b s 架构呼叫中心业务系统中的研究 政1 1 1 8 5 呼叫中心业务系统的数据持久层的设计思路与实现，以及作者负责的部 分系统管理和业务模块的设计与实现。 第四章为基于b s 架构的呼叫中心业务系统框架设计，主要叙述了一种通用 的呼叫中心业务系统可重用框架的设计方案的设计思路。 第五章为结束语，总结了本文的主要内容，并对未来的工作做出了展望。 第二章m v c 模式和h i b e r n a t e 研究 3 第二章m v c 模式和h i b e r n a t e 研究 2 1m v c 设计模式 2 1 1 跚c 模式简介 m v c 模式提供了一种按功能对各种对象进行分割的方法，强制性的使应用程 序的输入、处理和输出分开，其目的是为了将各对象间的耦合程度减至最小。使 用m ，c 的应用程序被分成三个核心部件：模型、视图、控制器。 1 、模型( m o d e l ) ：是业务流程、状态的处理以及业务规则的制定，包含应用 系统的核心功能，表示一个应用系统的数据，并且包含访问、维护和管理这些数 据的逻辑。模型接受视图请求的数据，并返回最终的处理结果嘲略3 。模型聚集了相 关的数据和操作，以提供详细而精确的服务。模型的接口提供了访问和更新模型 状态，执行封装在模型中的复杂进程的方法。模型服务被控制器访问，用于查询 或更改模型状态。当模型状态发生变化时，模型会通报给视图。在模型同界面分 离的情况下，代码可实现可管理性和重用性。 m v c 并没有提供模型的设计方法，而只告之应该组织管理这些模型，以便于 模型的重构和提高重用性。业务模型还有一个很重要的模型那就是数据模型。数 据模型主要指实体对象的数据保存和读取。比如将一张订单保存到数据库，或从 数据库获取订单。我们可以将这个模型单独列出，所有有关数据的操作只限制在 该模型中。 模型在w e b 系统中代表了商业规则和商业数据，存在于e j b 层和w e b 层。 在j 2 e e 的规范中，系统有些数据需要存储于数据库中，也有一些不需要记录在 数据库里的。在w 曲层有h t t p s e s s i o n 和s e r v l e t c o n t e x t 及j a v a b e a n 对象来存储数 据，在e j b 层则有e j b 来存储数据和逻辑。 2 、视图( v i e w ) ：视图代表用户交互界面，表示模型的状态，是应用系统的外 观，当模型发生改变时，视图也将随之改变。在m v c 模式下，视图界面不应当 处理数据而应仅限于对数据的采集和处理，以及用户的请求，而不包括在视图上 的业务流程的处理h 1 。 视图在w e b 系统中代表系统的显示，它完全存在于w e b 层。一般由j s p 、 j a v a b e a n 和c u g o mt a g 组成。 3 、控制器( c o n t r o l l e r ) ：控制器可以理解为从用户接收请求，将模型与视图匹 配在一起，共同完成用户的请求，是联系模型与视图之间的纽带，控制模型和视 4 m v c 设计模式和h i b e r n a t e 在b s 架构呼叫中心业务系统中的研究 图之间的交互过程。它获取并翻译用户输入的动作，指定执行该动作的模型，或 者根据用户的输入和执行的结果来选择下一个视图。控制器并不做任何的数据处 理，它接受用户的输入并调用模型和视图去完成用户的需求晦1 。 控制器在w e b 系统中协调模型与视图，把用户请求转换成系统识别的事件。 在w e b 层，一般有一个s e r v l e t 接收所有请求，它可以调用视图流管理器( v i e wf l o w m a n a g e r ) 决定下一个视图。一般还有一个请求处理器( r e q u e s tp r o c e s s o o ，包含所 有请求都需要做的处理逻辑，如把请求转换成系统事件等。 模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用 户通过某个视图的控制器改变了模型的数据，控制器都会将变化通知依赖于这些 数据的视图，导致显示的更新】。它们三者之间的关系以及它们之间的协作如图 2 1 所示。 事件一一p方法调用 图2 1m v c 模式的工作流程 由图2 1 可知，m o d e l 是整个m v c 模型的核心，它表示的是解决方案空间的 真正的逻辑，一个m o d e l 可以对应一个或者多个视图。视图是m o d e l 的外在表现， 具有与外界交互的功能。同时，m o d e l 的更新与修改也将通过控制器来通知视图， 从而保持视图与m o d e l 的一致性。m v c 的处理过程：首先控制器接收用户的请 求，并决定主要管理应用系统与外界的接口。一方面它为外界提供输入手段，并 触发应用逻辑运行；另一方面，它又将逻辑运行的结果以某种形式显示给外界。 控制器是m o d e l 与视图的联系纽带，控制器提取通过视图传输进来的外部信息， 并将其转化成响应来调用对应的m o d e l 进行处理，然后m o d e l 处理用户的请求并 返回数据，最后控制器调用相应的视图模型返回数据，并通过表示层呈现给用户。 第二章m v c 模式和h i b e r n a t e 研究 5 2 1 2m v c 设计模式的优缺点 使用m v c 的优点，一方面分离数据和其表示，使得添加或者删除一个用户 视图变得很容易，甚至可以在程序执行过程中动态的进行用户视图的更新。模型 和视图能够单独的开发( 即业务逻辑和用户表现的分离) ，增加了程序的可维护性， 可扩展性，并使测试变得更为容易。 另一方面，将控制逻辑和表现界面分离，允许程序能够在运行时根据工作流、 用户习惯或者模型状态来动态选择不同的用户界面口3 。尽管构造m v c 应用程序 需要一些额外的工作，但是它给开发者带来的好处是无庸质疑的。 最重要的一点是多个视图能共享一个模型，现在一个应用程序需要用越来越 多的方式访问。因为m v c 己经将数据和业务规则从表示层分开，模型返回的数 据没有进行格式化，同样的构件能被不同界面使用。因而在m v c 设计模式中应 用开发人员可以最大化的重用他的代码。 由于运用m v c 的应用程序的三个部件是相互独立，改变其中一个不会影响 其它两个，所以依据这种设计思想开发者能构造良好的松耦合的构件。 同时，控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和 视图去完成用户的需求，这样给定一些可重用的模型和视图，控制器可以根据用 户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。 m v c 的缺点在于它没有明确的定义，所以完全理解m v c 并不是很容易。使 用m v c 也需要精心的计划，需要花费相当可观的时间去考虑如何将m v c 运用 到应用程序之中。同时由于模型和视图要严格的分离，这样也给调试应用程序带 来了一定的困难。还有开发m v c 系统比简单的j s p 开发要复杂许多，它需要更 多的时间学习和掌握。 2 2 对象关系数据库映射工具h i b e r n a t e 简介 现在，构建信息系统的需求越来越复杂，开发周期越来越紧迫，同时对系统 的稳定性、扩展性和可维护性要求越来越高。为了满足客户对系统的要求，加快 系统开发，一个有效的解决方案是把业务信息按照功能模块拆分开：业务逻辑与 数据库服务器分开，用户界面与业务逻辑分开，彼此相对独立，任一方的改变都 不会影响对方。 但在实际的项目中，“客户端一w r e b 层业务逻辑层一数据库四层结构的划 分往往不能很准确的指导开发。因为在业务逻辑层与数据库交互的过程中往往需 要对数据库调用接口做进一步的封装。而且，对许多公司而言，数据层是关系型 数据库或公司大型机系统，不能明确映射要实现的许多面向对象的机制。 另外，以往的大多数应用程序开发人员只是考虑中间层的业务逻辑复用，很 6 m v c 设计模式和h i b e r n a t e 在b s 架构呼叫中心业务系统中的研究 少考虑过用任何正规的数据持久性框架建立数据层，即数据持久层。如图2 2 所 不o i 卜卜1卜 3t 业 数 务据 w e b 层 逻持 辑久 1 卜 1卜 层 卜 层 j 图2 2 增加了数据持久层的b s 系统结构 为了把数据访问细节和业务逻辑处理分开，使得各层内部功能更专一，可以 把处理访问与操作数据的部分划分出来作为单独的数据持久化层。 数据持久层是一组提供数据持久化功能的软件服务，将面向对象应用程序与 其使用和操纵的数据源分离，在对象一关系数据库之间提供一个成功的企业级别 的映射解决方案。持久层隐藏了访问这些数据源的相关数据访问a p i ，提供的服 务完全抽象并且隐藏了数据源使用和操纵数据的物理细节。 在业务逻辑层和数据库之间增加一个数据持久层有以下优点： 1 、将数据持久逻辑和业务逻辑分离，使业务逻辑层通过数据持久层与数据库 交互，而不用j d b c 之类的数据访问a p i 访问数据源，使得各层功能简洁、专一。 2 、对业务逻辑层隐藏了数据库平台。将所有数据连接逻辑包装到数据持久层 中，业务逻辑的开发人员不需要知道连接的数据库平台类型，连接数据库时所需 的任何安全信息等。 3 、抽象数据库中存储数据的物理细节和数据实体之间存在的关系。建立在上 述体系结构布局之上的应用程序不必直接对数据库发出s q l 查询，不必知道数据 的物理结构，而用数值对象访问数据库。 4 、简化开发过程，隐藏打开数据库连接、发出数据读取与操纵命令以及事务 管理的细节旧1 。 目前，关系型数据库是存储数据的普遍选择，但是随着面向对象技术日益发 展，在持久层上关系型数据库的设计体系与面向对象体系格格不入。无论业务逻 辑层设计多么完美，在真正储存或者加载业务对象时，设计人员面对的却是一大 堆关系数据，这些数据在j d b c 中已经完全失去对象( 这里的对象称之为业务对象 或许更为确切) 的意义，整体的面向对象程序设计到此为止。 这其实是一个经典的问题：对象和关系的映射问题。实际上自从o o p 编程流 行以后，就存在这个难题了，所以才有人提出关系数据库进行重新设计，改用对 象数据库，但实际上关系数据库仍然是存储数据的主要形式，于是就只能在上层 第二章m v c 模式和h i b e r n a t e 研究 7 的应用层找解决方案。这就是对o r m 技术的研究。 对象关系数据库的映射( o r m ) 是一种耗时的工作，需要由专门的映射工具来 支持。 h i b e r n a t e 是一个面向j a v a 环境、开放源代码的对象关系数据库映射工具， 它提供了一套完整的基于面向对象的方式来操纵和管理关系型数据的解决方案。 h i b e r n a t e 是一个与j d b c 密切关联的框架阻1 ，它对j d b c 进行了轻量级的对象封 装，使j a v a 程序员可以使用面向对象编程思维来操纵数据库，惟一需要做的就是 创建一份x m l 映射文档，告诉h i b e r n a t e 希望能够保存在数据库中的类，以及它 们如何关联到该数据库中的表和列，然后就可以要求它以对象的形式获取数据， 或者把对象保存为数据n 训。 h i b e r n a t e 可以应用在任何使用j d b c 的场合，既可以在j a v a 的客户端程序使 用，也可以在s e r v l e t j s p 的w | e b 应用中使用，最具革命意义的是，h i b e m a t e 可 以在应用e j b 的j 2e e 架构中取代c m p ，完成数据持久化的重任。 h i b e r n a t e 不仅仅管理j a v a 类到数据库表的映射( 包括j a v a 数据类型到s q l 数 据类型的映射) ，还提供数据查询和获取数据的方法，可以大幅度减少开发时人工 使用s q l 和j d b c 处理数据的时间。h i b e r n a t e 本质上是一个提供数据库服务的 中间件n 。对于开发者而言，h i b e r n a t e 的目标就是要简化通常的与数据持久化相 关的编程任务。 h i b e r n a t e 的精髓是持久层实现模式，它完全是针对对象的持久化，即把一个 普通的j a v a 对象映射到关系数据库中。面向对象设计中的继承与多态机制在 h i b e m a t e 里也得到了支持，在数据查询中，它支持动态q u e r y ，并提供对十六种 数据库语言的支持。它沿用传统数据库的事务模型，使程序员不必为新的事务模 型大伤脑筋。另外，h i b e r n a t e 是本地调用，比e n t i t yb e a n 有更高的性能，而且它 改进的速度之快也是其他o r m 产品无法企及的。 h i b e r n a t e 在大多数主流j 2 e e 应用服务器的受管理环境中都可以良好运作， h i b e m a t e 还可以和多种w 曲服务器或者应用服务器良好集成，如今已经支持几乎 所有的流行的数据库服务器( 达1 6 种) ，甚至也可以在独立的j a v a 应用程序中运行。 下面来看一下使用h i b e r n a t e 进行软件开发的体系结构。 对h i b e r n a t e 非常高层的预览如图2 3 所示： 8 m v c 设计模式和h i b e r n a t e 在b s 架构呼叫中心业务系统中的研究 l 数据库 l 图2 3h i b e r n a t e 概览1 1 2 】 从整个应用程序的高度看，h i b e r n a t e 处于数据库和应用程序之间，为应用程 序提供将对象持久化到数据库的服务，它使用数据库和配置文件数据来为应用程 序提供持久化服务，即它使用h i b e r n a t e p r o p e r t i e s 和x m lm a p p i n g 两个配置文件 把普通j a v a 对象映射成关系数据库中的表。 口鼢一t j 2e ea p i 图2 4h i b e r n a t ea p i 在分层体系架构中的高度概括1 1 3 1 图2 4 是h i b e r n a t e a p i 在分层体系架构中的高度概括。图中显示的接口可以 近似地分为如下几类： 1 、由应用调用的完成基本的c r u d 和查询操作的接口。这些接口是应用的 业务控制逻辑对h i b e r n a t e 的主要依赖点。它们包括s e s s i o n ，t r a n s a c t i o n 和 第二章m v c 模式和h i b e r n a t e 研究 9 q u e r y 。 2 、由应用的底层代码调用的配置h i b e r n a t e 的接口，最重要的是c o n f i g u r a t i o n 接口。 + 3 、允许应用对h i b e r n a t e 内部出现的事件进行处理的回调接口，例如 i n t e r c e p t o r ，l i f e c y c l e 和v a l i d a t a b l e 接口。 4 、一些扩展h i b e r n a t e 的映射功能的接1 2 1 ，例如u s e r t y p e ，c o m p o s i t e u s e r t y p e 和i d e n t i f i e r g e n e r a t o r 。这些接口是由应用的底层代码实现的( 如果需要的话) n 劓。 h i b e r n a t e 使用了现有的j a v aa p i ，包括j d b c 、j a v a 事务a p i ( j t a ) 和j a v a 命 名和目录接口( j n d d n 4 1 。j d b c 为关系数据库的共通功能提供了一个基本级别的 抽象，允许几乎所有具有j d b c 驱动的数据库被h i b e r n a t e 支持。j n d i 和j t a 还 允许h i b e r n a t e 与支持j 2 e e 平台的应用服务器进行集成。 第三章福州邮政1 1 1 8 5 呼叫中心业务系统设计与实现 11 第三章福州邮政1 118 5 呼叫中心业务系统设计与实现 3 1 福州邮政1 1 1 8 5 呼叫中心业务系统简介 福州邮政1 1 1 8 5 业务平台是基于企业呼叫中心平台的邮政业务信息化系统， 系统为邮政企业内部各业务部门之间、企业与客户之间进行业务受理、消息传递、 咨询服务等业务开展提供一个开放的信息平台。 系统需要实现的功能包括以下几方面： 1 、客户服务：邮政客户通过1 1 1 8 5 客服系统可以查询业务信息、提出问题投 诉及建议； 2 、业务受理：客户通过呼叫中心系统预约或者办理各类邮政综合业务，业务 受理模块记录客户业务请求，后台业务人员作相应处理； 3 、业务咨询：业务资费、流程、受理网点、受理时间等信息咨询，业务数据 查询； 4 、报表统计：统计业务数据并生成相应报表； 5 、内部通告：企业内部通告消息传递； 6 、客户资料管理：维护客户基本资料信息，用于简单的客户关系管理及数据 分析； 3 2 福州邮政1 1 1 8 5 呼叫中心业务系统设计 3 2 1 功能模块设计 根据上面描述的系统需要实现的功能，可以将该呼叫中心业务系统划分为几 个大的功能模块。 系统管理功能：管理提供各业务服务的部门信息，部门与部门之间的通知、 公告等内部的消息传递、各部门提供的业务信息，各部门的员工也就是使用 本系统的用户信息； 业务服务功能：管理本系统提供的各种业务，例如上面提到的受理类业务、 咨询类业务等； 报表统计功能：通过统计各类订单以及投诉等业务数据来生成各种统计报表； 客户管理功能：管理维护客户的信息，因为每一条业务订单都必然与某一客 户相关联，因此客户与业务的关系比较密切。 12 m v c 设计模式和h i b e r n a t e 在b s 架构呼叫中心业务系统中的研究 3 2 2 系统层次设计 随着具有优秀跨平台性的j 2 e e 平台的出现和发展，越来越多的w e b 应用开 始在j 2 e e 平台上进行开发n 副。而作为j 2 e e 平台主要组成部分之一的j s p ，逐渐 受到了开发者的广泛青睐。这是因为j s p 页面不仅拥有跨平台和跨w e b 服务器的 特性，而且可以非常容易的将业务逻辑、服务器端处理过程和静态h t m l 页面“所 见即所得”的功能相结合，同时实现显示、业务逻辑和流程控制等功能，从而帮 助开发者快速的完成任务n 们。 j s p 技术规范给出了两种使用j s p 开发w e b 应用的方式：m o d e l1 和m o d e l2 ， 两者主要差别在于它们处理业务的流程不同。 l 、m o d e l1 模式 m o d e l1 模式是一种以j s p 页面为中心，以j a v a b e a n 处理业务逻辑的开发模 型。在m o d e l1 中，j s p 页面独自响应请求并将处理结果返回给客户，所有的数 据通过j a v a b e a n 来处理，j s p 实现页面的表现。此模型的体系结构如图3 1 所示。 w e b 应用 h t t p 请求 服务器 ， s p i w e b 、h t t p i 鄹j 岖 i - - - _ _ _ _ _ h - _ - _ _ _ _ - _ _ 一 浏览猫 ； 图3 1m o d e li 体系结构 从图3 1 中可以看出m o d e l1 体系结构的工作流程如下： 1 ) 、从客户端的w e b 浏览器读取用户请求，并将请求发送到j s p 页面； 2 ) 、j s p 页面调用相应的业务逻辑j a v a b e a n 处理请求； 3 ) 、j a v a b e a n 根据用户请求操纵位于e i s 层的数据库； 4 ) 、j a v a b e a n 取得返回结果； 5 ) 、j a v a b e a n 将取得的结果传送给j s p 页面； 6 ) 、j s p 页面将结果生成h t t p 文档返回给客户端。 m o d e l1 模式的优点是简单，可以很好的满足小型应用开发的需求。它也实现 了页面表现和业务逻辑相分离，然而在企业级应用的开发过程中，由于不加选择 地大量使用它就需要在j s p 页面中嵌入大量脚本小程序或j a v a 代码，尤其是在需 要处理复杂业务逻辑时，大量的嵌入式代码会使整个页面程序变得异常复杂，使 第三章福州邮政1 1 1 8 5 呼叫中心业务系统设计与实现 1 3 代码的开发和维护出现困难。此外它还存在另一个缺陷：每个j s p 页面必须单独 负责管理应用程序的状态、验证与安全性。 2 、m o d e l2 模式 m o d e l2 模型结合了j s p 和s e r v l e t 技术。j s p 技术用于表现页面，s e r v l e t 技 术负责完成大量的业务处理，j a v a b e a n 用来存储数据。其中，s e r v l e t 用来处理请 求的事务，充当一个控制者的角色，并负责向客户发送请求：它创建j s p 需要的 b e a n 和对象，然后根据用户请求的行为决定将哪个j s p 页面发送给客户。这种模 型的体系结构如图3 2 所示。 w e b 应用服务器 h t t p 请求 ds e r v l e “控镉器) ，_ 、 w e b rx 浏览器 1 h t t p 响应 fj s p ( 视蹦) 图3 2 m o d e l 2 体系结构 从开发的观点来看，m o d e l2 具有更清晰的页面表现，清楚的开发角色划分， 可充分发挥开发团队中的网页设计人员和j a v a 开发人员的才干。这些优势在大型 项目中表现得尤为突出。从设计结构来看，它充分体现了模型一视图一控制器 m v c 的设计模式。 通过以上m o d e l1 和m o d e l2 的比较，可以看出，福州邮政1 1 1 8 5 呼叫中心业 务系统的开发更适合应用m o d e l2 的开发模式。 无论是m o d e l1 还是m o d e l2 ，它们都是用j a v a b e a n 直接对数据库进行操作。 这样造成的结果，就是系统的业务逻辑代码与对数据库的操作代码混在一起。这 不仅增加了编写代码和维护代码的复杂程度，还大大降低了代码的可重用性。试 想，如果系统不再采用s q ls e r v e r 数据库而开始采用o r a c l e 数据库，那么对数据 库的操作代码几乎就都要修改过才能使用。因此，我们在m o d e l2 开发模式的基 础上增加一个数据持久层，系统的业务模型通过数据持久层提供的接口与数据库 打交道。而数据持久层则屏蔽掉数据库之间的差异，为系统提供一套操作数据库 的方法。这样即使得整个系统的层次分明，又可以提高代码的可重用程度。图3 3 所示是增加了数据持久层的m o d e l 2 体系结构。 14 m v c 设计模式和h i b e r n a t e 在b s 架构呼叫中心业务系统中的研究 w e b 麻用服务器 h t t p 请求 ：t s e r v l e l ( 控制器) 、，7 、 数 w e b ，矧 据 测览器 持 1 久 h t t p 响戍 l j s p ( 视图) 层 ， 图3 3 增加了数据持久层的m o d e l2 体系结构 确定了系统需要提供的功能和系统的层次设计后，就可以开始进行详细功能 模块设计了。下面将要介绍的就是在福州邮政1 1 1 8 5 呼叫中心业务系统各个功能 模块的设计。 3 2 3 功能模块详细设计 根据福州邮政1 1 1 8 5 系统提出的需求，我们将系统提供的功能分为系统管理、 客户管理、业务、报表及数据统计等共四大功能模块。下面将分别介绍各个模块 具体的功能： 1 、系统管理模块 首先介绍一下福州邮政1 1 1 8 5 呼叫中心业务系统中的角色定义。福州邮政 1 1 1 8 5 系统中的所有用户按照角色可以分为两大类： 1 ) 、系统管理员：负责系统配置、用户及日志管理管理等。 系统管理员具体负责各业务单位的创建和维护、单位下用户的创建和维护、 用户权限的分配和管理，以及业务信息的维护和配置。此外，系统运行参数、系 统日志也由系统管理员进行维护。 为方便管理用户，可以按照系统管理员所在单位的上下级关系赋予相应级别 用户管理权限，例如上层机构的管理员可以管理其下的所有用户账号( 包括下属单 位的用户管理权限) 。 2 ) 、普通用户：指登录系统进行业务处理的相关业务人员( 包括话务人员) 。 普通用户包括话务员、业务人员、决策人员( 一般只能对数据进行查看操作) 。 ( 1 ) 话务员：呼叫中心人工坐席，负责接受客户请求，查询用户请求的信息， 生成业务单据，并对需要进行后台处理的业务执行催办、查询等操作； ( 2 ) 业务人员：指可以登录系统进行业务相关业务处理的员工，例如速递局业 务人员； ( 3 ) 决策人员：此类人员只能查询业务信息，不能对业务数据进行修改或变更， 如业务部门管理人员。 第三章福州邮政1 1 1 8 5 呼叫中心业务系统设计与实现 1 5 将用户分为不同的角色的设计，目的是为了能通过角色来对不同的用户进行 权限管理。 系统管理模块提供以下功能： 1 ) 、部门管理功能：管理员在部门管理页面，根据企业实际的业务部门信息， 对企业的部门进行创建新部门、修改和删除现有部门的操作。创建一个部门时要 输入该部门的上级部门、部门名称、部门地址、部门负责人等信息。 2 1 ) 、业务管理功能：管理员在业务管理页面，进行创建新业务、修改现有业 务和删除业务的操作。创建新业务需要输入业务名称、业务类型、业务描述信息 等信息。 3 ) 、部门业务设置功能：管理员在部门管理页面，选中需要设置的部门，在 业务列表中选择该部门对应的业务选项。 有一点是很容易理解，但是又很容易被忽略的，那就是子部门的业务只能在 父部门的业务中选择。所以在创建一个部门时必须先选择该部门的上级部门，这 样才能确定候选的业务集合，以备管理员选择。 4 ) 、权限管理功能：管理员在权限管理页面，进行创建新权限、修改现有权 限和删除权限的操作。创建新权限时需要输入权限的名称、对应的u r l 、说明等信 息。 先对“权限 作一下解释：本系统的权限是与角色相对应的，即一个角色对 应着一个权限的集合。分配了某个角色的用户就拥有了该角色对应的组权限。 用户拥有某个权限意味着该用户可以访问一个特定的j s p 页面。例如管理员拥有 “权限管理”的权限，那么当管理员登录到系统中之后，他就可以通过一个超链 接进入“权限管理页面 进行权限管理的操作。这也解释了为什么在创建权限时， 需要输入一个u r l 地址，这个u d 就是新创建的权限对应的j s p 页面的u r l - 在一 般情况下，这个u r l 都是相对于系统根目录的相对路径。 5 ) 、角色管理功能：管理员在角色管理页面，进行创建角色、修改现有角色 信息和删除角色的操作。创建一个新角色时，管理员要输入角色名称、角色说明 等信息。 6 ) 、角色权限设置功能：管理员在角色管理页面，选中需要设置的角色，在 权限列表中选择该角色对应的权限并保存。管理员在创建一个新的角色时，在输 入完了角色名称、角色说明等信息之后就可以通过勾选权限列表中的各个权限来 设置这个新角色拥有的权限。 16 m v c 设计模式和h i b e r n a t e 在b s 架构呼叫中心业务系统中的研究 图3 4 角色管理功能操作流程 图3 4 所示为角色管理功能的操作流程的简单图示。管理员登录后首先进入角 色管理页面；在角色管理页面上已经列出了系统目前所有的角色；管理员可以选 择进行创建新角色、修改或删除角色三种操作之一；如果管理员选择修改或删除 角色，那么必须先选择角色列表中的一个角色，对其进行操作；如果创建一个新 的角色，那么管理员需要输入角色名称、角色说明，还要从所有权限中选择某些 权限构成该角色对应的权限集合，然后点击创建按钮；如果修改一个现有角色， 那么管理员需要对需要修改的角色信息以及角色权限集合进行修改，然后点击修 改按钮；如果选择删除一个角色，那么管理员只需直接点击删除按钮；管理员在 点击相应操作的按钮后，系统再以弹出窗口的形式提示“确定该操作吗? ，管理 员确定后系统执行各种操作，并将各种执行结果以弹出窗口的形式通知管理员。 7 ) 、用户管理功能：管理员在用户管理页面，进行新建用户、修改现有用户 信息和删除现有用户的操作。创建一个用户时要输入该用户所属的部门、用户名 称、职务、联系电话等信息。 如果系统用户的角色不是管理员，而只是普通用户的话，该用户依然可以进 入用户管理页面，但是该用户只能进行修改本人部分个人信息的操作，不能进行 创建新用户，修改其他用户信息以及删除用户的操作。普通用户可以修改的部分 个人信息包括用户名称、联系电话、密码等，该用户所属部门以及职务等信息， 普通用户无权修改。 图3 5 所示为普通用户修改个人信息的流程图。用户在登录系统后进入用户管 第三章福9 i l 由g 政1 1 1 8 5 呼叫中心业务系统设计与实现 1 7 理页面，因为不是管理员的角色，用户只能修改部分个人信息。用户在输入密码、 用户名、联系电话等允许修改的个