07新技术.pdf

希赛软考学院系统分析师考试辅导与培训 新技术应用资料 （2007年11月版）希赛IT教育研发中心 1 引言.8 2 极限编程的测试.8 2.1 单元测试.8 2.2 功能测试.9 2.3 持续集成的测试.9 3 测试对其他实践的支持.10 3.1 迭代式开发.10 3.2 持续集成.10 3.3 重构.11 4 测试先行的应用开发.11 4.1 测试框架.11 4.2 测试先行的应用实例.12 4.3 测试的特性分析.13 5 测试先行与传统测试的比较.14 5.1 测试先行优于传统测试.14 5.2 现有的测试先行方法的不足.14 6 结论.15 基于中间件的分布式系统开发过程的研究.16 1 软件构件和中间件.16 2 基于中间件的分布式系统开发过程.17 2.1 基于中间件的分布式系统开发过程可行性研究.17 2.2 基于中间件的分布式系统开发过程需求分析.18 2.3 基于中间件的分布式系统开发过程的设计.19 2.4 基于中间件的分布式系统的测试和维护.20 3 结束语.20 基于XML的三层结构的WEBGIS系统.21 1 引言.21 目 录 基于极限编程的测试分析.8 2 XML及三层网络结构.21 2.1 XML，XSL和DOM.21 2.2 三层网络架构.22 3 系统设计.23 3.1 应用XML于三层网络架构.23 3.2 总体架构.24 3.3 用XML描述空间数据.25 4 系统特点.26 5 结束语.27 基于WEB的多层分布式物流管理系统.28 1 引言.28 2 系统功能.28 3 系统实现.29 3.1 多层分布式系统结构.30 3.2引入控制器.30 3.3 引入同步令牌.31 3.4数据库连接池.32 4 系统实施.33 5 小结.33 EAI技术在电信运营支撑系统中的应用.34 1 引言.34 2 电信OSS建设中的应用系统集成问题.34 2.1 应用系统本身.34 2.2 系统互连互通.34 2.3 流程自动化.35 3 EAI技术简介.35 3.1 数据传输.36 3.2 数据转换.37 3.3 工作流.37 3.4 接口集成.38 4 EAI的解决办法.38 4.1“信息孤岛”问题.38 4.2 系统间接口通信机制的多样性问题.38 4.3 流程的自动化问题.39 5 结论.39 遗留系统的评价方法和进化策略.40 1 引言.40 2 遗留系统的评价方法.40 2.1 启动评价.41 2.2 商业价值评价.41 2.3 外部环境评价.42 2.4 应用软件评价.44 2.5 分析评价结果.44 3 遗留系统的进化策略.45 3.1 淘汰策略.45 3.2 继承策略.45 3.3 改造策略.46 3.4 集成策略.46 4 结论.46 网格与 WEB 服务的结合.47 1 网格通信.47 2 WEB 服务概览.48 3 网格与WEB 服务之间的界限逐渐模糊.48 4 支持请求架构.50 5 支持分发架构.50 6 结束语.52 基于JAVA的企业应用集成技术.53 1 引言.53 2利用JNI实现EAI.53 3 分布式企业通信范型实现EAI.54 4 利用消息服务与JMS实现EAI.55 5 利用XML实现EAI.56 6 利用J2EE连接程序实现EAI.56 7 小结.57 基于J2ME的小型移动商务系统.58 1 引言.58 2 系统原理框架.58 3 系统实现的关键技术.60 3.1 J2ME体系结构.60 3.2 XML的作用.60 3.3 移动客户端与Web服务器的数据传输.61 3.4 移动客户端XML解析.62 4 实验系统.62 5 结束语.63 基于智能卡的电子商务身份认证模型.64 1 引言.64 2 电子商务应用中的加密方法.64 2.1 公钥密码体系.64 2.2 RSA加密算法.64 3 电子商务应活动中身份认证的方法.65 3.1 传统的口令式身份认证方法.65 3.2 数字签名、数字信封、数字证书.66 3.3 数字签名的产生、发送与认证.66 3.4 数字签名认证中存在的问题.67 4 智能卡的保护方案.68 4.1 智能卡的国际标准.68 4.2 智能卡物理结构的安全性.68 4.3 智能卡中的数据保护机制.68 4.4 综合的保护机制.69 5 结束语.69 SOA构架与电子商务应用集成.70 1 电子商务应用集成方案.70 1.1 开放式平台构架方案.70 1.2 信息描述与交互方案.72 1.3 信息安全方案.73 2 应用实例.74 3 结束语.76 基于AGILE方法的软件架构设计与实现.77 1 引言.77 2 AGILE方法的特点.77 3 基于AGILE方法的软件架构设计.78 3.1 Agile软件架构设计的需求.78 3.2 Agile软件架构设计的模式.78 3.3 从需求到架构设计.79 4 设计与实现.80 5 结束语.82 面向WEB的数据仓库体系设计.83 1 XML.83 1.1 XML概述.83 1.2 XML与数据库.83 2 数据仓库.84 2.1 数据仓库概述.84 2.2 数据挖掘与数据仓库.85 2.3 数据挖掘面临的挑战.85 3 基于XML的数据仓库系统设计.86 4 基于XML的数据仓库体系在电子商务中具体应用.88 移动数据库技术研究与应用.89 1 引言.89 2 移动数据库的概念.89 2.1 移动数据库的概念和特点.89 2.2 移动数据库系统的体系结构.89 3 移动数据库关键技术研究.90 3.1 复制和缓存技术.90 3.2 数据广播技术.90 3.3位置管理.91 3.4 查询处理及优化.91 3.5 移动事务处理.92 4 移动数据库的应用.92 5 总结.93 嵌入式移动数据库的应用研究.94 1 嵌入式移动数据库的发展现状.94 2 移动计算与嵌入式移动数据库.94 3 嵌入式移动数据库在应用中的关键.94 3.1 数据的一致性.94 3.2 高效的事务处理.95 3.3 数据的安全性.95 4 移动数据库管理系统的特性.95 5 总结.97 AJAX技术及应用.98 1 概述.98 2 特点.98 3 现状及发展前景.99 4 主要技术.100 5 应用.103 RIA体系中的设计模式.104 1 前言.104 2 为什么丰富？.104 3 RIA设计.105 4 RIA体系结构中的设计模式.107 5 服务中介.108 6 永恒的主题.112 7 向丰富迁移.113 基于极限编程的测试分析 1 引言 一套软件开发方法是由一系列用来生产软件的规则和实际操作组成。传统的方法拥有过多的规则、操作和文档，要正确地实施，需要制定出相应的制度标准作保证。而极限编程则属于易于实施的轻量级的软件开发方法。极限编程（eXtreme Programming，XP）是一个简明的工作平台，它是基于对影响软件开发速度的因素进行考查而发展起来的。这种开发方式适用于经常面临需求不明确或者需求快速变化的小到中型的软件开发团队。相对于现有的编程方式，XP有两个明显的变化：（1）XP的实践规则是“适应性”（Adaptive），这使得我们能适应并勇于面对开发过程中的各种变化。（2）XP不仅仅强调测试，而且更要求实现高效的自动化测试（Automated Test）。另外，XP要求以清晰易懂且容易扩展的方式写代码，而且源代码的质量比以往显得更加重要，这就对开发人员的素质提出更高的要求。XP去掉了传统“重量级”软件开发方法中一些妨碍进度甚至干扰开发人员的部分，归纳出四个要素一 沟通、简洁、反馈、勇气，即用XP的价值准则来指导软件工程师编写程序。对如今的软件行业来说，XP跨出了极其重要的一步。极限编程本身的内容相当丰富，本文将从测试实践方面对XP进行讨论。2 极限编程的测试 在XP实现中有四步解决策略计划、设计、测试、开发。与任何一种软件开发方式一样，测试是一个相当重要的环节。对于测试，XP要求体现出测试先行（Test First）的特点，这也是测试驱动开发方式的核心所在。开发人员在编写代码之前和开发过程中设计单元测试代码，客户在确定功能之后就进行功能测试的设计。测试主要分为两种：（1）程序员编写的单元测试（Unit Test）利用这些测试确保程序以他们所期望的方式运行；（2）客户提供的满意度功能测试（Functional Test），用来确保系统整体上以他们期望的方式运行。另外，单元测试中要求体现集成测试的原则，即持续集成的测试。2.1 单元测试 单元测试的设计过程实际上就是项目设计的过程。对初步的交互接口和数据接口类中将被使用的方法以及相关的重要接口编写测试，一旦单元测试设计完成，类的接口也就自然实现。当用户需求改变时，相应的测试需要改变或者增加相应的测试模块。单元测试是XP中的主要的测试实践。由一系列实践组成，增强了项目代码的可靠性。(1)所有代码必须有相应的单元测试类单元。(2)单元测试的设计是在开发前或编码的过程中实施。(3)单元测试模块的设计尽可能的简单和直接，有利于测试的进行。(4)每个可能出错的方法都要实现对应的单元测试，发现了错误必须要增加相应的测试。(5)同一个项目的开发人员共同使用该单元测试模块。(6)单元测试必须自动化，并且可以以清楚的信息表示测试通过或失败。(7)软件项目同时验证和维护单元测试。在开发的每个阶段都要通过单元测试，否则不能加入版本控管。通过单元测试让开发人员确信所写的程序代码是可行的，并且留下线索和注释给其他开发人员帮助理解原作者的思想。单元测试的失败可以让开发人员下决心重整程序代码。2.2 功能测试 测试除了单元测试之外还有客户的功能测试，也可以称之为满意度测试。在我们实际应用中，我们可能会提供给用户多个版本的系统(如，版)，而针对不同版本的目标不同，客户端的测试用例也有所区别，主要体现客户不同的测试要求。客户为每个功能编写满意度测试，这些测试也说明整个系统该有什么样的功能，通常满意度测试的编写需要开发人员的协助。理想情况下，客户的满意度测试必须在程序编写的最后一个阶段性迭代之前完成。满意度测试是用来帮助客户评估设计的完成度，同时让客户知道某个部份是不是可以发布，因而不是所有的满意度测试都非要通过不可重要的是把握所能容忍的缺陷级别。2.3 持续集成的测试 对于集成而言，我们要求尽量频繁进行，而集成的测试当然也是要同步的。实际上，集成测试是在单元测试中体现的，因为集成测试是属于开发过程中的小阶段迭代的结果。持续集成的环境中，自动测试是必要的前提。对于实现一个足够快的集成支持来说，就需要一个足够级别的自动测试，即获得一个确切的工具环境。我们在开发过程中尽量在每个工作日对系统都至少进行一次集成测试，而且是用专用计算机来做这项工作。减少了其他的干扰，更利用结对开发人员的检测，如果无法完全通过测试，就重新更改相应的集成，直到完全通过。集成离不开自动测试，自动测试中同样需要持续集成。(1)始终拥有一个稳定的可执行系统，即使失败，也可以回溯到上一次集成。(2)可以把代码尽快集成到系统中进行测试，尽早并持续获得各种反馈，并作出相应的调整。(3)由于测试与开发同步进行，因而减少了最终测试的前导时间，提高项目进展效率。3 测试对其他实践的支持 XP具体的需求和实践规则包括计划游戏(Planning Game)、小版本发布(Small Release)、简 单 设 计(Simple Design)、结 对 开 发(Pair Programming)、测试(Test-First)、重构(Refactoring)、现场客户(On-site Customer)、持续集成(ContinuousIntegration)、代码公有(Collective Ownership)、编码标准(Coding Standard)。XP把所有的实践结合起来，而且必须把各种实践结合起来才能确保其最有效地彻底执行。就测试而言，XP要求实现自动化测试(Automated Test)，主要涉及持续集成和重构，为其他实践提供了相当的支持，在迭代过程中有充分体现。3.1 迭代式开发 迭代式开发(Iteration)是极限编程的关键，它是贯穿于整个开发过程的原则。迭代必须及时进行测试，验证迭代效果和促使迭代的合理规划。每次迭代都需要完整的测试体系来确保迭代计划的完成，否则失败的测试需要重新进入下一次迭代计划及时地进行调整(图1描述了迭代过程)。将开发进度划分为多个迭代，每次迭代给出确定的时间(最好少于20天)。不要太早对开发任务进行计划，而应该在每个迭代开始前计划确定本次迭代要完成的任务，不要过早增加任何功能，应该着眼于目前所急需的部分，额外增加的任何东西都会延缓进度。3.2 持续集成 持续集成是团队或者个人控制向系统交付代码，而且每次迭代更需要集成和测试，一次集成也可能需要多次很小的迭代，这样我们就可以使得测试过程变得简单，而开发过程也变得容易控制。持续集成是通过频繁的构造来实现的。每次集成需要花费一定的时间，因为新的代码集成会引入一些错误或冲突，会带来破坏原系统的可能性。而高效的测试和重构可以减少集成的更改量和冲突的可能性。集成测试同样要求要100通过，否则就应该放弃相应的更改，这也表明对当前集成的功能还没有足够的理解，因而测试和集成同样是密不可分的。3.3 重构 伴随着测试开发过程，我们经常需要进行重构，重构是不改变系统行为的系统更改，是一项改变代码而不至于改变功能的技巧，但是开发人员通过修改来提高一些非功能性的质量，简单性、灵活性、易懂性和性能。如果开发人员发现可重用的代码，也会重构代码以抽出重复部分。重构就是测试、更改、再测试、再更改、。XP要求用最简单的代码实现可运作的程序，但这是需要坚持的边做边学。重构是从自己的程序代码中学到的东西，它使得代码的生命周期更久，保持代码的简洁，让接手的人更不容易出错。4 测试先行的应用开发 传统的测试设计都是在系统开发基础上进行的，而极限编程中的开发方式就是测试驱动的模式测试先行。测试先行要求在测试对应的系统模块的开发前进行该模块测试的设计，更重要的是，仅当不能通过测试时才对代码进行重新编写。下面我们就讨论XP中主要的测试实践单元测试。4.1 测试框架 在XP的测试中我们利用了测试框架这个概念。利用测试框架对测试进行自动验收，可以让开发测试人员简单地进入测试接口，输入相关的输入并得到期望的输出。测试框架也可以将输入转换成XML文件或者其他文件形式，然后运行文件中的测试，进而为每个测试显示结果通过或失败。实质上就是一种自动化的黑箱测试，一切单元测试都在测试框架中实现。针对测试集把相应的测试用例送入测试接口进行测试，得到反馈的测试结果，或者通过，或者失败，通过则进行下一步测试，失败则根据相关错误信息进行更正修改，然后再进入测试集用相应的用例进行测试。图2所示为国外应用较广泛的JUnit框架结构。特定的开发平台需要特定的测试框架，我们可以利用现有比较成熟的测试框架，如JUnit，CppUnit，PerlUnit以及VBUnit等。尽管测试框架在不同语言平台内实现，但是它们在语言允许限度内的工作方式是相同的。4.2 测试先行的应用实例 有了测试框架之后，我们就要建立测试类的子类来存储相关测试，这些测试就是用来检测要被测试的对象。测试用例包括所需的所有测试方法，测试框架收集所有测试，并逐个执行它们，这样可以确保每次测试都在清晰的环境下进行，一个测试中的错误也不会影响其他测试。设计和实现之间通常存在着一个空隙。我们通过用户素材得到一个接口层次上的初步设计，然后进行单元测试的设计，确切地说我们是边考虑测试设计边进行项目分析。我们同样还利用JUnit来对实例进行分析。一个公司员工的基本资料在网页上显示。先写类测试：public void testClerk()Clerk c=new Clerk(Luis，”1”)；assertEquals(Luis”，c。getName()assertEquals(1，c。getLevel()；编译无法通过，我们需要创建类的实现：public clas Clerk String name；int level=-1；public Clerk(String name，int level)thisName=name；thislevel=level；public String getName()return name；public int getLevel()return level；再运行testClerk()，通过测试，接下来，再创建一个测试：public void testtoXml()Clerk c=new Clerk(Tom”，-1)；assertEquals(Tom，ctoXml()；编译没有通过，因为我们还没有声明实现Clerk中的toXml()方法：public String toXml()return null；编译运行，测试失败：public String toXml()return”十name+；测试通过。我们接着加入另一个测试：Clerk c1=new Clerk(Jane，1)；assertEquals(Jane”，c1toXml()；编译通过，然后运行，失败。因为在toXml()中缺少了相关的功能，我们继续增加相应的功能代码：public String toXml()retnm”namee”+(level”+name+“”；最后我们开始考查自己的代码，分析重构的必要性。实际最终我们可能会把代码重整为下面的结构，这也是代码清晰简洁的原则要求。Private String toLevel()if(level0)return”；else return”level=”+level+”；public String toXml()return”+name+”；接着我们就可以继续下一步的测试设计，也就是对于类的其他相关方法的设计过程，该方法测试通过的同时，还要保证所有的原有测试完全能够通过。该实例的实现过程实质上也体现了一点：只有当一个失败的测试时才写新的程序代码。4.3 测试的特性分析 在开发过程中进行测试的设计所需的时间花费要比对系统相关错误的修复少得多。使用先行测试代替死板的CASE工具使得详细设计的过程变得互动、迭代和平滑。把单元测试作为文档交给项目程序员，也可以加强团队交流学习，有助于后期的开发协作。测试过程给我们同样带来了很多反馈，指导我们继续写出更多的单元测试。用户功能的变更要求相应的测试设计的改进，然后在迭代开始时，对项目要进行全面测试，而且在每次集成的时候测试模块也要相应的更新。这种测试先行的设计思路不但最真实地记录了详细设计的过程，同时也填补了接口层次设计和实现之间的空隙。当我们完成了单元测试的设计，真正要实现类变得非常容易，相应的接口参数变得一目了然，类接口和状态很自然地呈现了出来。把系统生产代码从测试代码中分离出来，简化了以往复杂的开发过程。如图3所示，利用独立管理和接口来简化设计。对象的复杂程度直接关系到完全测试它的难度系数。从设计的角度来说，当无法做到完全测试这条规则时，我们就应该考虑重新设计，因为原先的设计包含了太多的职责状态。在测试提出不合适的接口要求时，我们就要利用重构来设计新的接口进行测试。另外，对于非接口方法的测试实现需要做一些改进。对非接口方法的测试意味着测试依赖于类的实现而非类的接口，也就是说，即使类的接口不变，该类的实现的变化也会造成测试的变化。要解决这个问题就需要把这些非接口方法接口化。或者直接接口化这些方法，或者为这些方法和状态建立独立的类来实现接口。这样就可以确保：测试依赖接口而不是依赖实现。对象的接口是稳定的，它封装了实现，而实现是相对可变的。5 测试先行与传统测试的比较 5.1 测试先行优于传统测试 传统测试理论的目标和相关的工具最关心的问题是程序的正确性，它们的目的是寻找代码中存在的Bug。它们的测试对象是已经存在的代码。而在XP中相关的单元测试并不完全是一种质量保证体系和发现Bug的工具，一定程度上应当说是一种设计方法。在XP项目的设计中，单元测试的设计过程其实就是表达项目设计的过程，接着所写的代码则是为了测试单元测试是否正确，换句话说，也就是代码的实现是否能够符合项目设计的过程。在重构的过程中，单元测试不破坏程序的可观察行为：不产生新的Bug和不破环原 先的设计。在XP项目的开发过程中，以测试先行的驱动方式来实现单元测试，从而测试可以不受实现的干扰，独立地表达各自的意图，而代码则是来实现这个目标。通过这样处理我们可以有最完整的测试，得到最简洁的运行代码，以及一个目标明确的成品。而如果使用后测试(Test-last)的方式，那么这两个方面很容易融合成一个问题，因为目的性受到了实现的干扰。显然，XP中单元测试的思想和传统的单元测试是一个颠倒的过程。传统思路是用单元测试来测试代码，而XP中则是让代码来测试单元测试编写单元测试(各接口声明)、编写代码通过单元测试、重构、重新运行测试。5.2 现有的测试先行方法的不足 任何开发方式存在优点的同时也必然有其不足之处，极限编程也同样存在着一些问题：(1)XP要求程序员开发单元测试，但是没有明确指出测试用例的选材。(2)XP表明何时开始写单元测试用例，但是没有指导何时开始测试。(3)XP要求写尽能想到的所有测试，但是无法判断测试用例是否足够。不论在系统级还是单元中都要利用测试来确保集成的系统依然继续正确运作。测试的增长主要面对新的功能设计，同时避免重复，如果发现反馈的是低质代码，就需要我们扩大测试覆盖面。在实际应用中，我们需要不断积累经验，来提高测试效率，这也是当前针对不足的最有效的方式。6 结论 测试既是一种资源也是一种职责，极限编程中的先行测试刚刚起步，尤其在国内，开发人员正在考虑覆盖所有功能的基本测试的必要性。利用开发测试的平行，解决了功能测试和设计同步。而在某些情况下还不能完全建立自动的单元测试和功能测试，开发中缺乏一定的预见性，易造成结构性的质量问题，但是XP也正在考虑让测试用例来代替更多的功能说明。编程和测试的结合有利于赢得更高的生产效率，节省调试时间。作为一种新的软件工艺，XP的一个中心理念是以适应式，而非预测式(Predictive)的方式开发软件。在实际开发应用过程中应该认真学习和理解XP的思想，特别注意和认识XP的对策。基于中间件的分布式系统开发过程的研究 近年来，随着计算机技术，IntenetIntranet的不断发展及企业对计算成本的不断要求，计算机应用系统由集中式向分布式计算发展。软件的体系结构也从CS模式转向了多层应用体系结构。这种结构必然需要中间件支持，而面向对象分析方法是当今软件开发的主要方法，所以，分布式对象中间件成为一个主要的发展方向。运用这种技术，开发者可以将运行在网络中的分布对象集成为分布式应用，面向对象分析方法中的继承和复用技术有助于软件复用和控制系统的改动，降低维护的费用，使得系统的改动可以快速准确的予以实现。为了使开发者更专注于业务逻辑的实现，在分布式对象中间件的基础上又实现了一些分布式应用所必需的服务：目录管理、安全管理、分布式事务管理等。这就是所谓的“应用服务器”，它极大方便了多层分布式应用系统的开发，促进了中间件应用的发展。因而，也使得中间件技术受到人们广泛的关注，对软件业产生了巨大的影响。基于中间件的多层分布式体系结构，符合软件工程的化整为零的原则，同时满足方法论的要求。1 软件构件和中间件 一个构件是一个系统中最重要的、基本上独立的、可替换的部分，在已定义好的软件体系中执行清楚的功能，适合提供一系列接口的物理实现。中间件是基于构件技术，处于两种或多种软件之间(通常是在应用程序和操作系统、网络操作系统或数据库管理系统之间)传递信息的软件；它使用户能使用一种脚本语言来选择和连接已有的服务，从而生成简单程序的软件开发工具。中间件涉及软件的各个领域，是供公用应用程序编程接口的软件。中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。中间件应具有以下的特点：(1)中间件的平台无关性。中间件是用来解决应用之间的互连性，它提供了一个公共的应用通信机制和数据接口，以屏蔽各类通信协议之间的差异和实现通信协议间尽可能地完全映射。除此之外，还用来控制数据传输过程中的流量、加密、并发等问题。数据接口用来实现分布式环境中异构系统之间数据的共享，从而做到平台无关性。(2)中间件具有良好的可靠性。良好的可靠性是中间件技术开始以来就追求的目标，随着技术标准的形成，中间件已经可以提供可靠的稳定性。(3)中间件具有较高的效率。中间件的工作机制为：当客户端的应用程序需要调用分布式环境下某个服务器的数据或服务时，中间件系统负责接收客户端的请求，查找数据源或服务，并建立相应服务或数据同相应服务器之间的对应关系。完成连接后，还要负责结果的返回。因此，中间件实现了客户和服务器透明性，所以要求必须减少请求响应时间。因此中间件提供的对服务或数据的查询效率是比较高的。中间件技术的应用非常广泛。目前主要的分布式中间件技术标准有：Microsoft的以COMDCOM为基础的COM+，Java的JavaBeans和EJB，OMG组织的CORBA等。可以说，计算机界很久以前就有用分布式构件集成处于分布式环境中的各种应用系统的想法，但一直未能真正实现，其中的一个主要原因是分布式中间件技术标准的缺乏。正是由于出现了以上较为成熟的标准，才使得分布式系统通过分布式中间件开发构造由梦想走向现实。2 基于中间件的分布式系统开发过程 基于中间件的分布式系统开发过程隶属于基于构件的软件工程(CBSE)范畴。CBSE(Component-Based Software Engineering)是指用装配可重用软件构件的方法来构造应用程序。CBSE不仅仅是简单地应用对象要求代理建立一个代码库，或从Internet上下载相关控件，还需要策略而系统地进行全局考虑和规划。它包含了系统分析、构造、维护和扩展等各个方面。它具有即插即用，以接口为核心及标准化等特点，CBSE开发过程如图1所示。基于中间件的分布式系统开发过程在需求分析等各个过程中有其自身的特点，本文就这些方面予以探讨。2.1 基于中间件的分布式系统开发过程可行性研究 相对于传统软件工程早期的可行性研究，增加了对软件工作的分布式环境的研究、软件工作平台的配置研究以及所涉及的原有系统的改造问题，并且逐步过渡到以体系结构为指南的可行性研究，这与CBSE的特点是分不开的。20世纪80年代以来，大部分应用系统采用的是两层的CS模式。其中，一个客户机负责数据的表示、采集和处理工作，而服务器负责数据的集中存储。这种“胖客户”的CS体系结构只能工作在有限的环境中，但是，当客户数目过多或未知时，该结构就无能为力了。同时，应用程序庞大，应用逻辑无法复用。除此之外，系统修改要将所有的程序版本发给每一个客户机，成本较高。于是，从“胖客户”CS结构出发，人们把部分“业务逻辑”转移到数据库服务器上进行，演变成一种“胖服务器”的CS结构。但是，该体系结构性能仍不能满足分布式应用程序的要求，应用逻辑的复用度也很有限。由此可以看出，这种CS结构当业务规则很复杂时，系统很难管理，业务规则的更改也将变得异常困难，甚至不得不重新开发，这是该类体系结构不能适应大型分布式应用的主要原因。因此，人们又在客户端和服务器中间抽象出应用逻辑层，组成三层(多层)分布式体系结构，将企业的业务过程实现集中在该层中。所谓的多层应用体系结构，就是将在客户机和服务器之间增加某些应用逻辑层，将业务规则封装在这些层中。它们可能分布在一个或多个物理服务器上，甚至客户机，使得业务规则的改变比较容易实现。这种多层的体系结构必然要利用中间件技术，将企业的业务规则分别实现于各个组件中，数据和实现细节予以安全隐藏，仅展示其提供的服务接口。该体系结构如图2所示。分布式系统的可行性研究主要侧重于某一种体系结构能否满足于企业需求，这是不同于传统软件工程的。对于开发分布式应用系统而言，就是考虑三层(多层)应用体系结构能否满足分布式需求，技术上是否可行。实际上，也是选择分布式中间件的过程(图3)。2.2 基于中间件的分布式系统开发过程需求分析 对于基于中间件的分布式应用，需求分析和软件设计阶段由原来的从头开发产品变成了体系结构的选择、中间件的选择和开发工具的选择。系统分析员必须在系统需求和使用的分布式中间件之间进行权衡，并且作出折中的考虑。除此之外，同时还要在体系结构和接口之间进行权衡。一般而言，分布式应用采用面向对象分析方法。因为该方法已被软件工程界公认为是具有发展潜力的重要的需求分析方法。而且，目前分布式中间件技术基本上也是分布式技术与面向对象分析设计相互作用的产物。面向对象分析是分布式系统开发过程中的问题定义阶段，输出的是对问题域清晰和精确的定义。传统软件工程的系统分析产生一组面向过程的文档，用于定义目标系统的功能。面向对象分析主要产生一种描述系统功能及问题域特征的综合文档。后者在更大的问题域中考虑问题，是对现实问题更高层的抽象。因此，在分布式环境下分析其应用，就是将问题抽象为一组相互作用的实体和各实体之间的关系。从而，系统分析将产生一个能够控制的方式运行的模型。(1)识别分布式对象。即从问题抽象出分布式系统中包含的组件，遵循如下原则：使用分布式问题域中单个名词或名词短语。分布式对象名称必须简洁、精确，而且易于理解。尽量使用用户熟悉的标准词汇。尽量使组件的复用度较高。最后，可以提取类似组件间相同点，进行“泛化”。泛化后还要寻找类似组件间差异，即“特化”，以提高软件复用度。需要指出的是，对分布式对象的识别是一个主观的过程，因人而异，会产生不同的结果。但是，在对象的物理分布上，要遵循简洁、有效和复用的原则，并不是所有的应用逻辑组件都分布在服务器上。有时，为了更好地解决问题，一些只针对极少数客户机的逻辑组件也可能放在客户机上，这正是多层体系结构的体现。(2)用例设计。所谓用例(Use Case)就是用户与系统，系统内部各部分之间相互交互、对话的场景。它描述了系统工作机制，从而揭示需要建造的系统模型，并检验可否满足需求。对于分布式系统而言，应该从分布式环境出发，找出系统的用例来，它对系统的功能设计及最后的测试都有很大的意义，这方面应该请教有关应用领域的专家。(3)对象的设计与调整。这是标志对象后更进一步的设计，对标志出的对象(组件)确定属性和行为，也就是数据成员和方法。这样，整个分布式系统的运作可看成处于分布式环境中的各对象之间的相互通信及其引发的动作。属性是问题域中对象性质的刻画，行为为分布式对象应该展现的外部服务之总和。可以通过提取外部服务名称及大致功能，标志分布式对象间消息传递予以识别。最后，要通过实际运行的场景中的事件顺序对对象的设计予以调整。2.3 基于中间件的分布式系统开发过程的设计 三层分布式体系结构上面已经介绍，其表示层、应用逻辑层和数据存储层是彼此分离的。其优点如下：具有可伸缩性，这是因为它的数据库连接之类的资源可以共享，每一个消耗资源的客户应用程序并不直接访问数据库服务器，而是由客户应用程序与业务逻辑层进行通信。一个应用逻辑实例可以向多个客户提供服务，降低了资源消耗，提高了伸缩性。应用逻辑实体可以独立于任何客户应用程序来设计。这样对于很多应用程序来说，就提供了非常的灵活性和重复使用的潜力。定义公共接口之后的业务逻辑的封装，使得开发者可以创建可重复使用的服务的一个载体。当然，也可以用新的应用逻辑来组合，以创建新的应用程序。此外，公共功能也很容易更新，以适应商业规则的变化。三层的体系结构使得现有的旧系统更容易地被集成：只需将现有系统封装在业务逻辑中，客户程序只需关心怎样访问业务逻辑，不必关心依赖的各种不同应用系统。(1)表示层的设计。表示层向用户提供数据输入输出和响应用户动作并控制用户的界面。一般而言，目前主要有两种：图形用户界面和基于Web的用户界面。(2)应用逻辑层。该层主要用来实施业务规则和数据完整性规则等。它向表示层提供服务，这些服务具有通用性，即服务适合于所有的应用程序。只有这样设计，才能达到高效复用的目标。但是，它并不清楚数据以何种方式存储及存储的地方，这要依赖于数据存储层。所以，应用逻辑层还要提供数据访问服务，以执行数据的检索和存储。(3)数据存储层。主要负责数据的存储，因此，它的设计主要是数据存取的设计，必须确定上面分析中对象(组件)模型到关系模型的映射。一般有三种策略：只把超类转换成表：超类把所有子类的属性和子类与其他实体间的关系都收集起来，并加入一个辨别属性。这种方法便于查询所有的子类的信息，但也会造成存储空间的浪费。只把子类转换成表：把各个子类分别转换成互补相关的表，而超类中的属性及其他实体的关系都由各个表收集。这种方法是最容易理解及编码的，但超类更新比较困难，超类的改动将影响到所有涉及到的子类的表的改动，而且查询所有子类信息也不方便。一对一关联。将子类和超类都转移成表，并在它们之间建立一对一的关联。该方法概念清晰，超类更新与上一种方法一样，但可以查询所有子类信息，只是不得不进行连接操作，速度较慢。然而，它的概念较为清晰。除了上面所讨论的之外，还应该注意层间接口的设计、安全控制和事务管理。一般而言，目前的中间件基本上都提供安全控制和事务管理。但开发人员必须细心地设计接口，因为体系结构本来就是具有长期影响的系统接口的集合。2.4 基于中间件的分布式系统的测试和维护 用中间件来建造一个分布式应用系统，测试是必不可少的工作。软件工程中测试可分为三种形式：单元测试、集成测试和系统测试。对于分布式系统而言，就是组件的单独测试、组件集成和系统的最后测试，方法不外乎黑盒子法和白盒子法。相对而言，组件的测试黑盒子法用得多一些，因为有些组件源码不公开。而且，由于开始系统并未建立，所以可能会写一些桩模块，这些测试概念可详见资料。基于中间件的分布式系统的后期维护，主要就是业务规则变化的维护。如前所述，该维护比较简单。而且，改动较为容易。3 结束语 基于中间件的分布式系统开发过程具有适用范围广、应用效率高的特点，但其效率的发挥必须要有大量标准的中间件或中间件技术来支持。同时，必须要在充分进行领域分析的基础上，构造并生成大量的基本构件。只有中间件技术标准比较成熟的情况下，才可能通过中间件生成分布式应用系统。基于XML的三层结构的WebGIS系统 1 引言 WebGIS是Intemet技术应用于GIS开发的产物，Intemet用户可以从WWW的任意一个节点浏览WebGIS站点的空间数据，并且能够进行各种空间检索、分析和制作专题图。到目前为止，WebGIS的处理模型主要有三种：(1)基于GIS服务器的模型，这种模型是由客户端浏览器向通用网关接口(Cn)发出服务请求，CGI接到服务请求后调用GIS服务器的地理空间数据进行处理，最后将处理结果以静态HTML页面的形式发送到客户端。这是典型的瘦客户、胖服务器模型。(2)基于客户端的模型，这种模型一般采用配套的服务器端和客户端软件，把需要的地理空间数据从服务器端下载到客户端，由客户端软件进行处理。(3)部分基于客户端的模型，这种模型采用前端插件技术(Plug-in，ActiveX，JavaApplets等)将WebGIS服务器上的部分处理功能移植到客户端。通过利用客户端的处理能力，平衡客户和服务器两端的数据处理量，减轻网络传输负担。以上几种都是CS主从模型，对于GIS系统而言，由于是海量数据，且由于其空间信息的复杂性，如果是基于GIS服务器的模型，虽然简化了客户端，但把所有处理集中在服务器端，加大了服务器端处理的数据量和网络传输负担；如果是基于客户端的模型，它虽然增强了客户端处理能力，减少了服务器端处理的数据量和网络传输负担，但是由于客户端软件功能有限，对于地理空间数据标准有局限性，需要及时对地理空间数据进行更新；如果是部分基于客户端的模型，需要确定哪些数据和操作在服务器端执行，哪些在客户端执行，软件的设计复杂，成本较高。因此本文提出了利用XML的技术来实现三层网络结构的WebG