<尚大教育，教育至上，人才为大：sdedu.cc>

 

系分论文1

企业人事信息系统的应用

 

【摘要】

  本文讨论《企业人事信息系统》项目的需求分析方法与工具的选用。该系统的建设目标是帮助该企业管理好企业内部的人员和人员的活动，人事信息管理指的是企业员工从招聘面试到离职退休的全过程，涉及的主要活动包括面试、报到、培训、升职、离职或其他的人事变动，也包括电子化考勤、工资性收入的计算与分发、使用其他公司资源的有关记录（如宿舍、保险、证件办理等等）。此外，本系统也涉及到企业在全国各地的人事信息管理，企业的组织架构的设置，级别与职务管理，人力申请直至人力需求报表，从而形成一个对企业真正有用的人事信息管理应用系统。在本文中首先讨论了选用面向对象方法与工具的主要理由与策略，进一步通过一个简例说明该方法与工具使用的效果，也讨论了使用多种工具与方法在需求分析中的必要性，最后简要小结了选用正确工具与方法的意义和作用。

  在项目开展期间，我担任了系统分析、系统设计与数据库管理等大量工作。

【正文】

  人事信息管理系统是一个有着广泛应用面的实用性系统，但是，我国各个企业有着自身的体制、机制、特点与不同的要求；在开发这类系统时，系统需求分析是极为重要的一环。在整个分析过程中，我们都采用了面向对象的分析方法，这是因为我们在近几年的实践中已坚信这种方法能够更加有效地表达和描述现实世界。软件要具有适用性和扩展性，就必须更接近于现实世界本身的发展规律。

  以一个简单的例子来看，假设要求设计关于引进人才评估的一个系统，按我们过去的做法，先会要求提供给我们一份相关的引进人才评估表，然后依葫芦画瓢地设计相应的表单与界面。在短期来说，这样做是简便而实用的，但并不能够符合现实世界的长远目标，这套设计方法不具有扩展性，因为任何一份评估表的结构都会有可能发生许多改变的。采用面向对象的方法，可以从中提取出表类型、表结构、评分方法以及能考虑继承等各方面的要素，这样就可以保证软件的通用性，可配置性与可维护性。

  在工具的选择过程中，我们选择了现在已十分流行的Rational系列，包括Rational Rose、RUP、SoDA等，为什么选取这个系列工具呢？这是基于我们对软件需求分析目标的看法，我们认为需求分析应当能正确地回答如下的几个关键性问题：

  （1）用户的需求是否已详尽地被考虑到了？

  （2）用户能理解或明白我们所描述的内容吗？

  （3）分析是否会和设计相脱节，

  （4）程序员能明白我们的分析与设计要求吗？等等。

  以下对上述几个问题逐一简要地加以说明：

  （1）详尽地获取用户的需求。

  用户的需求可分为显式的需求与隐性的需求，用户的倾向往往只顾及到当前的与明显的需求。要达到对需求理解的全面性，不仅仅只是依靠有效的用户谈话和调查，因为我们所面对的用户需求往往会有些片面的，采用Rational Rose（基于UML）提供的用例，以及多种图的联合使用，可以使我们发现其中的遗漏。

  （2）使用户能充分地理解我们的表示方法，能够真正明白我们描述的内容。

  软件需求分析规格说明书通常会是冗长而枯燥的，一般的用户不容易深入理解，这样就削弱了分析的正确性。通过支持面向对象及UML语言的Rational Rose可以更好地和用户交流，让用户了解系统的运作方式甚至细节的操作。

  （3）使分析和设计两个阶段互相联系与贯通。

  这是我们选择面向对象的方法及Rational Rose工具的重要原因，系统分析要向用户描述的不仅仅是用户的需求，而且包括解决方法，解决方法当然应包括设计（程序）、数据库与系统配置，我们当然不希望用户得到的是一个与需求规格说明不相同的软件，也不可能要求程序员完成一个不可胜任的任务。然而我们在以前的多项工作中经常发现这类情节，因为系统分析与设计相互脱节，导致一头扎在分析中不顾设计有关的事宜。

  分析与设计的脱节，还不利于设计现格说明的评估，因为分析往往会脱离现实，导致缺乏评估的依据。

  因为不可能成功地完成设计而使分析需要重来，就会造成巨大的浪费与损失。一个好的工具可以使分析与设计更紧密地连结起来，甚至于—一对应。面向对象的分析方法使对象之间相对而言有独立性，减少了任何影响到全局的改动，能避免因需求变化而导致全盘皆动的被动局面。

  （4）使程序员明白我们的设计。

  一个好的设计应该让程序员感到清晰明白，更少疑问。一个疑问很多的设计加上沟通不畅，绝对会出现在应用环境下所不需要的另一个软件，所以设计规格说明书务必清楚、形象与明确，当然，Rational Rose具有足够的图形与其他形式，能使程序员更加明确，甚至能细微到每一个语句（事实上如果使用VB，程序架构都有可能直接生成了）。

  （5）选择UML可能会有更多的理由。

  比如用户文档的编写、数据库设计，我们都需要做到有延续性，有自动化支持和具有质量上的保证。

  所以，我们选用了以上的方法和工具。

  在分析中，面对考勤班次的问题时，由于过去一直使用纸卡方式考勤，使用户对班次形成了固定的概念，而现在的许多考勤软件也采用多次刷卡的方法来形成一天的记录。经过面向对象的分析可以发现，事实上每天的上班记录是由多个时段所形成的，时段的多少在各个公司，各个工种与部门都不尽相同，每个时段可能有不同的属性，时段与时段组合可形成为班次，这更适合于现实的情况，使之能更加灵活与更有扩展性。其实，在天与天之间也都有相互之间的关系。在这一点上，我们又发现必须在考勤与薪金工资中加入与MRP中相似的期段（Periods）的基本概念，比如可以称之为考勤期段，允许为用户更加方便地设置考勤期段，可能使之不一定与自然年月日相同等等。

  Rational Rose使我们更方便地把上面的想法在类上去实现，更进一步地设计好我们的高效率的数据库。

  当然，使用单一的一个工具去完成一个中大型的应用系统的需求分析，是不可能成功的。因为社会在发展，用户的需求也在改变，如何把握住用户的需求是需要时间的，面向对象的方法有时也会忽略外在的与表层的要求，不仅仅是要获得关键的需求，其他更多的需求往往要等到用户在使用后才知道，然而等到用户使用是不现实的，作为原型开发模型中的原型也是收集用户需求，描述与解释需求的一类相当有效的方法与工具。

  在我们的开发过程中，为了更好地让用户了解我们的系统和我们的设计方案，让用户在见面会上更有方向性与针对性，我们首先用Access开发出原型，让用户先试用。这样，我们在真正的分析与设计时就能更加符合用户的要求。

  总之，软件需求分析方法和工具的使用，对我们软件开发过程影响是很深远的，选用高效能的正确的方法与工具，可以使我们的软件更加正确地反映现实需求，更加具有可用性、可扩展性和可维护性；降低了软件项目的风险。

评注：（1）写得有些特色，观点鲜明。（2）摘要写得不错，既反映了项目内容，也小结了本文的写作要点。（3）文中所举的例子虽然简单，但很实际。（4）多种方法与工具的使用，叙述得简明扼要。（5）内容可更丰富一些，更深入的例子也可再增多一些，则会更有说服力。（6）对需求分析的全过程的描述太少。（本文主要参考了广东延国庆等人的论文）

 

 

系分论文2

企业集团的信息管理系统应用

 

【摘要】

  本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本。因此，需求分析过程不同于建立一个全新的系统，大体上可分为三个阶段：（）实施逆向工程获得对系统的初步了解；（2）在第1步的基础上写出基本需求，交由客户评审补充；（3）在第2步的基础上开发原型，利用原型与客户交流，最终获得基线需求。针对上述三个阶段，本文论述了所使用的分析方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析中使用的工具，谈一些自己的初步体会。

【正文】

  我于1998年8月至2000年7月参加了某个大型集团的企业信息系统的开发工作，该大型集团的业务主要涉及到IT类产品的进销存。本人在项目中负责系统分析的工作，该集团企业原先已委托某个电脑公司开发过一套IT类产品管理系统，但是该老系统存在两个主要的问题：（一）系统运行速度非常慢，如商品销售开单时，从确定开单到开单完成有时需要1～2分钟左右的响应时间，让客户无法忍受。（二）系统数据不准确，经常出现实物库存与电脑库存严重不相匹配的情况，使销售数据的统计产生一些混乱，有关财务的数据因此无法有效使用，只能采用人工录入方式补充进行。在这种情况下，该集团的总经理决定参考原有系统重新开发一个系统，以便解决原系统所存在的上述两个难以克服的难题。注；原系统采用PB6.5开发，数据库采用SYBASE，服务器采用Windows2000Server，客户端采用Windows 98，程序架构采用的是传统的C/S结构。

  鉴于该集团业务操作复杂，流程多，涉及人员多等特点，以及项目完成时间短，经费有限，人员有限等限制约束条件，再考虑到必须避免前一系统出现过的结构混乱与难于维护等问题，我们决定要对原系统的需求做一个比较彻底的和切实可行的分析，由于原有系统已经开发了近两年，并且客户也有了一定的使用经验，业务基本流程本身也并没有太大的变化，因此，我们把需求分析的过程分为三步：（）分析原有系统的结构，主要是数据库结构和程序结构，（2）在获得第（1）步结果的基础上写出基本需求，交由客户评审补充，（3）在第（2）步的基础上开发原型，利用此原型与客户交流，从而获得最终可用的需求结果。下面按上述三步分别加以论述。

  第一步是实施逆向工程，获取原有系统的基本需求。

  由于原有系统在功能上大体上能基本满足客户的需求，并且在两年多的开发中也积累了不少经验，因此，从中可以获得一些有益的参考，也可以避免多走弯路。在这一阶段，我们采用的主要工具是PB自带的Power Designer和PB Documents；前者主要用来分析数据库结构，后者主要用来分析程序结构，便于开发人员与高级用户理解程序。采用这两个工具的原因是：原系统过于庞大，模块多，数据库模式多，表格量很大，仅靠人工的方法很难从中获得一个比较完整的、明确的系统结构以及整体构成，而且原有系统未能提供一套正确完整有效的设计文档，于是我们只能依靠工具辅助来进行。在使用Power Designer分析数据库，并且用PB Documents分析原程序中的PBL以后，我们对原系统的结构有了一个初步的了解，再结合对原系统的使用，基本明确了功能与流程的需求，并在此基础上用人工录入方式，产生了初步需求的自然语言文档。这里指出，使用Power Designer的一个不足之处是：如果一个表中的字段过多，而且又同时依赖多个表时，输出的表格相关图形很复杂，有很多交叉，且难于调整，不方便阅读及打印。

  第二步是在第一步的基础上进行的，即写出系统基本需求，交由客户评审和补充。

  通过第一步的逆向工程，我们获得了系统的基本需求。为了充分记录需求的变化及需求之间的依赖关系，我们决定选用Rational公司的Requisite PRO作为我们的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非常强大，包括Requisite Pro、Clear Quest等等，这些需求分析工具可以对需求进行全面的管理，包括记录需求的变化情况，需求之间的依赖关系等等。但是，我们考虑到Rational的一套工具全面实施会非常昂贵与复杂，需要非常强的项目管理能力才能全面实施，因此，我们只采用了其中最简单的一部分功能，那就是记录需求变更，记录需求之间的依赖关系，其他跟RUP有关的功能都给略去了。之所以这样做，主要是考虑到项目的经费、人力以及国内软件开发的实际情况。正如前面所说，我们根据自己的理解并写出基本需求后，交由客户做评审井做适当补充，我们将经过补充整理后的需求作为正式需求记录入Requisite Pro所维护的数据库中，并对各个需求进行分类，设定优先级等，这些工作完成后，就可以从数据库中直观地了解客户到现在为止提出了哪些需求，哪些需求是必须优先考虑的，哪些是难度较大的等等。在这个过程中，我们遇到了一些问题，譬如：用户对我们用自然语言书写的需求文档有许多地方不理解，往往在花了较长时间阅读之后，仍不明白我们所描写的需求过程与他们所完成的业务之间的对应关系；另外是由于首次采用Requisite Pro进行需求管理，在类型划分，属性值的确定上，部分开发人员没有经验，造成了不少反复，对于前者，我们的方法是想办法增加一些示意图，将大的流程分解为小流程，再与客户反复交流与沟通，最终达到双方理解一致的目的。对第二个问题，则参考了一些例子，再结合实际中属性的使用情况，给予取舍或者选择，经过这一阶段的工作，我们建立了基本的需求库，定出了基本需求规格说明。

  第三步则是在第二步的基础上建立起原型，利用原型与客户进行更深入的交流，通过交流修改相应的需求。

  在这一阶段的工作是在对第二步任务进行报告交流的基础上进行的。我们用PB开发了一个原型系统，就具体的业务流程与客户进行交流与沟通，通过原型，客户发现了许多我们与他们的理解相互不协调的地方，我们在修改需求的同时，也在Requisite Pro需求数据库中记录下修改的历史。事实证明，这种记录历史的作用是很有效的，如曾经有客户在两个不同的时间对同一需求提了相反的需求，我们根据历史记录很快证实了该客户的提法有错误，在事实面前无需再作争论，同时利用Requisite Pro，我们还发现了一些需求相互之间有矛盾。经过这一阶段工作，我们终于获得了经过用户认可的需求基线，即是可用于下一步进行详细设计的基线需求。

  在这个项目中，我们利用了Power Designer、PB Documents等逆向工程分析工具和Requisite Pro需求管理工具，这些工具的使用，使我们提高了工作效率，起到了一定的辅助作用。但是，就需求分析工具方面而言。我们觉得国内应用得还是太少了，这一方面是因为对需求分析不够重视，另一方面是因为管理水平还达不到相应的层次。Rational公司的一整套需求分析工具，其功能是非常强大的，国外已在普遍地使用，在国内也逐渐开始普及，特别是那些通过CMM二级以上评审的单位，都必须使用工具对需求进行管理。在本项目中，我们仅仅利用了Requisite Pro功能的一些小方面，已经体会到该工具对于项目管理的诸多好处。如果一个有实力的公司能够全面实施RUP，那么需求管理这个老大难的问题会变得不再那么棘手了，项目的质量也会得到相应的提高。目前国内由于CMM热潮的兴起，已经逐渐重视需求分析，也逐渐使用需求分析工具，这是非常可喜的，当然，更希望在不久的将来，能用上国产的需求分析工具，那时我们的软件产业也许会真正地腾飞了。

评注；采用逆向工具进行再工程的应用很多，本文给出了一个实际的例子。写作有条理，也很实际。合理地界定了需求分析的现实水平。所采用的需求分析的方法与工具相对较合理科学。能在对项目讨论的同时抒发议论、使用体会、爱国心和事业心。深度还可以提高，例子宜更加丰富一些。（本文主要参考了广东刘小波等人的论文）

 

 

系分论文3

论软件需求分析方法和工具的选用——论文3：通信行业的应用

 

【摘要】

  本文以某通信公司的业务报表系统开发为例，讨论了软件需求分析工具与方法的选用。我们认为，软件需求分析是软件工程中重要的一步，直接关系到后继工程的进行以及最终的产品能否满足用户的需求，因此在整个工程中起着关键性的作用。采用适当的工具，有可能显著减少需求阶段的错误，也可大幅度提高需求分析的质量和工作效率。当然工具的选用应当与实际的项目相结合，充分地发挥工具的作用。本文结合我们工作的实际经历，简要讨论了开发系统时所选用的工具及其应用，选用时所考虑的原则以及所碰到的问题。在文中也结合多种开发方法（即传统的瀑布法、信息工程法、面向对象的方法）的比较，指出各种方法的不足之处，说明我们所采用的工具对软件需求分析所起的作用，以及相应产生的效果。

【正文】

  我在某市一家通信公司工作，作为一名技术骨于，受领导委托，参与了开发本公司的业务报表系统，我担任系统的需求分析、总体设计和部分代码的编写工作。

  我所在的企业作为一家通信运营公司，分为总部、省级公司和地市级分公司三级，各级公司之间都有数据报表的要求。但是，每一个地市分公司因所处的地方不同，经营环境不同，所面临的问题也不一样，因此形成了各具特色的数据报表（除地市分公司向省公司汇报的之外）。公司又分设了许多部门，这些部门也都会需要数据，作为分析决策的依据。因此，了解各个部门的需求就成了业务报表系统的关键。

  在调研的过程中，我选用了一种工具叫Play CASE，可以从网上免费下载，有很强的功能。下面就介绍一下，在需求分析阶段，我是如何使用这一工具的。

  第一步，了解业务组织结构。公司内部的数据实际上是在部门之间流动的。业务部门需要知道在本地覆盖区内各基站的话务量、当天的话务量（即话务量的时空分布）。财务部门需要知道本月各类用户的话费收入、预交款收入、与其他电信运营商的网间结算等。计划部门需要各部门的分析数据。计费部门需要提供本月的账革统计数据、话单统计数据分布（比如分别按照基站分布、时段分布以及按用户类别分布）、预交款统计数据、当前的欠费总额分布、催缴情况等等。这些部门时常为了数据而产生了大量无谓的争议。在使用Play CASE工具时，先要将这些部门录入到Play CASE的“业务部门”中．构成了一个信息源的接收点（或发送点）；而Play CASE通过图示表示了这些部门的关系，并转换成了相应的软件结构。实际上，这是一种系统建模的方法，即把业务系统中的各个组织转变为软件功能中的各个结构。这样，在需求分析阶段，明确哪些部门需要数据，从而保证了需求分析对整个公司的全面性，而不会忽略掉某一个部门，导致需求分析的不完整。

  第二步，了解各个业务部门中的业务流程，使之通过Play CASE转换成软件的运行过程，这是一种动态建模的方法。在上一步的基础上，追踪各个部门的行为，录入到Play CASE中，并以形式化的语言描述各过程。对于复杂的过程，该工具还提供了进一步细化的方法，并且形成了业务流程图和业务状态图。根据这些流程图、状态图与实际业务部门的业务相结合比较，还是较为吻合的。在此步的实施过程中，运用了动态建模技术，使各部门业务流程的情况在软件的运行过程反映出来，从而保证了需求分析阶段中运行过程的描述能真实地反映实际情况，防止在后继的程序编写过程中，可能会经常发生的一类情况：程序员因为没有理解业务流程而出现“闭门造车”的现象，从软件的功能角度上保证了软件的正确性。

  第三步，将业务数据转变为软件数据，这一步工作实际上就是收集各部门所需要的数据。分析各部门需要的数据都有哪些；以及数据是如何转换的，这可以归入“功能建模”的范畴。将这些相应数据录入到Play CASE中，选定所属的部门。这时就自动地建立了DFD图（数据流程图），数据字典，省去了人工建立时的很大麻烦。

  第四步，将业务上的数据关系转变成软件中的数据关系。这里采用了面向对象的方法，把业务部门所需要的数据看作一个实体，部门间的数据关系就是实体之间的关系。比如：经营部门所需要的用户资料、用户话费，实际上就是用户这一实体与账单这一实体间的关系。Play CASE提供了构件（不过我觉得是部件更为合适一些），来表示对应的数据，并提供了三种构件的表示关系即组装关系、分类关系与相连关系。这三类关系基本上反映出了现实世界中的业务数据之间的关系。例如现实世界中的用户资料与用户话费，在Play CASE中，可将用户构件与账单构件用相连关系表示。这种方法，实际上是借鉴了OOA面向对象的分析方法中的类、聚集、继承、封装等概念，能较好地反映出现实中的业务；同时，这一步的工作也为总体设计中数据库的概念模式设计奠定了很好的基础。

  经历了上述四个步骤以后，利用Play CASE工具自动生成了软件需求规格说明书、初步的DFD图和业务流程图，为下一步的总体设计打好了基础。

  使用Play CASE工具，使需求分析既能继承传统的结构化分析方法，又能吸收面向对象设计方法的优点。比如能把业务流程转变成为运行过程，业务组织转变成了软件的结构等都体现了这一点。而在运行过程中，对复杂过程的细分以及追踪则反映了传统方法中的自上到下分解的分析思想，这对于解决复杂系统的分析是很有帮助的。

  通过使用，我觉得这个工具还是很不错的。因为它实际将以下四个方面的问题结合起来了：软件、业务、开发人员和用户。对于用户而言，Play CASE用图形化的方式显示出业务流程，使用户了解业务在软件中的运行过程，提供了将来验收软件时的依据。对于开发人员来说，使开发人员能更清楚地了解业务流程，不会再发生“因为不理解用户的需求而出现的闭门造车情况，从而导致开发出来的产品不符合用户需要”的现象。因此，Play CASE所自动提供的需求说明书能够很好地沟通用户与开发人员之间的理解，使他们都能对需求有共同的理解。

  使用Play CASE工具后，使我们的需求分析取得了很好的效果，不但能自动地提供许多结果，如需求说明书等；还使需求的质量有了很大的提高，受到领导的赞扬（领导不是学计算机的，但对公司的业务十分熟悉）；在后继的设计与维护工作中，我们感到工作似乎轻松了很多。

  当然，该软件工具也有不足之处，一个突出问题是灵活性不够，一县公司的部门或者组织机构发生变化时，整个设计都要重新来过。因此，在改进的过程中，我们在第一步过程预留了好多个虚拟的部门，以备将来进一步的扩充或者变动。

评注：（1）具体项目有些体会，完成情况似乎不错。（2）条理较清晰，比较系统地描述了使用Play CASE的过程和体会。（3）偏重于工具的讨论，对需求分析的方法分析还嫌不够。（4）项目相对较小，仅涉及报表系统，对更为复杂的业务流程应举例分析，才能更充分地体现方法与工具的作用。

 

 

 

 

系分论文4

论软件需求分析方法和工具的选用——论文4：IC行业内部的CAD应用

 

【摘要】

  本文通过一个集成电路设计有关的软件项目，讨论了该项目的主要特点和本人所担任的工作，着重讨论了在项目需求分析过程中采用的具体方法和工具以及选用的理由。

  由于项目的专业领域的特殊性，分两类不同的需求讨论了需求分析中遇到的问题及解决方法；在这个过程中给出了对选用的具体工具和方法的效果的描述。接着本文讨论了对使用方法的改进的一些想法以及具体的实现过程。最后提出了我对需求分析的某些看法，强调了与客户沟通的重要性。

【正文】

  近年，我一直从事某企业中有关IT项目的开发，有一个系统是用于计算机辅助电路设计的，包括了从上流设计到下流设计的所有流程，如用于可设计百万门数量级的逻辑门电路。有关方面把电路中路径的提取、过滤以及表示的某软件开发任务交给我公司，我有幸担任了该部分的需求分析以及设计。

  我所设计部分为一单独可启动的软件，主要是解析文件中的连线路径，以列表视图和用直方图等把它们显示出来，还可以执行诸如查找与过滤等功能。

  委托方对此提供了很初步的需求说明，把一些基本功能及性能要求描述了一下。我在需求分析时的工作主要有两点：第一，对该软件的界面等详细需求要自己重新进行分析提取。第二，对于已提供的功能要求需要深化和细化，以形成真正完整的需求分析文档。

  在接到需求分析任务后，我分析了一下所要完成的工作。发现由于是专用领域的软件，对专业领域要求相当高，所以准备把此项目分成两部分：

  （1）界面所受专业领域影响几乎没有，但由于全部没有任何要求，反而会感到风险和改动可能是最大的。

  （2）功能方面由于委托方的许多功能都可以调用相应模块来得到，并且已有了相应的书面的简单需求，相应来说只是完成深化。对界面，我采用了部分RUP的思想迭代与渐进。而对功能需求采取了分层细化，每细化一层就要求委托方确认、修改和补充。

  首先把风险较大的部分完成，这是现代软件开发的基本常识。我选择先进行界面的需求分析。第一步是根据功能描述抽取出逻辑模型，并使逻辑模型与界面元素及功能一一对应，大体上决定了界面应有的功能，然后根据该界面功能描述，确定具体的控件，这时，我参考了委托方已初步完成的主窗口的界面布局及控件的使用规律，然后根据需要完成的功能从Qt（由于要支持Windows和Unix双平台，所以控件库采用Qt）的类库中选择相应的控件。在提取和抽象逻辑模型时，我采用了Rose 2000中的用例图，即以 USE-CASE图来描述与外部的关系。之所以采用Rose，我是基于以下的原因：第一，在已开发的部分中，委托方统一要求我们使用Rose进行类和顺序图等的设计和代码生成。第二，Rose提供了标准的图来描述系统与外部的关系，在全球范围已是一种标准结构。第三，使用上的方便性。我用Rose的USE-CASE图，理清了我们的软件窗口与委托方主窗口以及外部角色（操作者）之间的相互关系。

  在确定了界面元素后，考虑到文档的可理解性不是很强，我采用Visio 2000把界面的外观绘制出来，写上了基本的控件作用，随后送给委托方评审，幸运的是除了几个小功能的修改，委托方基本批准了我的方案。

  下面的工作是为控件的行为及状态变化制定相应的状态迁移图，我选用的工具仍是Rose，我用了状态图和时序图，把重要的控件状态变化及相应顺序进行了描述，随后的几天把相应的DOC文档建好写明，基本上界面设计就完成了。

  下面的需求是针对功能需求的。虽然委托方技术部门有初步的需求文档，但由于领域的专门化不对，我不清楚其中复杂的路径提取关系及较深入的专业术语，一直有一种举步维艰的感觉。只能采用分层细化的原则，从最初的几条深入一层变成十几条。这样的话，不会一下子碰到太深的专业问题，可以循序渐进从委托方与文献的解答中不断学习，深化自己对专业领域的了解，这样在设计中自己始终是层层推进的，不至于一于碰到无法逾越的专业障碍。

  在这一阶段的开发中，由于一直是与自己不熟悉的专业领域打交道，所以我觉得一些辅助设计工具似乎无法发挥应有的功能。在这期间，对我帮助最大的应是公司的E-Mail系统，所有不清楚的问题的提出，以及对问题的解答都通过它进行周转。换句话说，在需求分析阶段，它起到了一个与客户的交流沟通和客户需求的提取作用。所以，我认为在这一阶段，E-Mail系统是对我帮助最大的工具，其次是Excel，我用它建立了问题跟踪图表，对每一个提出的问题，均需要记录上去，把问题结果（可分为已清楚、仍不太清楚、不清楚、尚未回答）均记录下来，根据这些表，我可以很好地了解自己工作中的核心问题，并有了解决它的方向，提高了工作效率。

  每进行一层的细化，我都把结果交付委托方审核，由他们进行提出何时能终止细化，大约在八层细化后，对方认为已达到了效果，确认可以结束。至此，分析工作全部完成，项目的需求分析基本成功了。

  在这次需求分析中，我认为取得成功的原因主要是方法和工具选择得正确。在界面设计中采用了流行的辅助工具，对需求及逻辑模型的建立提供很大的帮助，可以更方便帮助自己理清思路。选用了迭代法，把一些错误的影响在功能分析和界面分析的不断迭代过程中加以改正。在后期，以功能需求为主时，我主要依赖的是沟通工具和表格工具，这也说明辅助工具不是万能的，需求分析的关键之关键，应是与客户的交流与沟通。

  通过这次案例，我认为在软件的需求分析工作中，方法的重要性应远超过工具的使用，应当首先确定分析中的风险，把风险分类，用不同的方法去解决各类风险，而工具的选择不仅是要看影响力和名气，而是要真正为我所用，应把握其精髓，即是此工具到底可以对开发有什么帮助，而不是仅限于如何使用。我认为在需求分析中工具的作用不外乎两个：一是实际系统与环境模型等的抽象工具，二是需求表达工具。第一类的代表是Rose，第二类的代表是Word，WPS，Visio等，在这次项目中由于地理上的限制还用到了沟通工具，Web浏览与E-Mail服务系统。

  最后我还是总结一下，在需求分析中工具方法都只是辅助项目成功的因素，真正的决定因素还是—一“与客户的沟通”。

  评注；

  （1）较实际地讨论了方法与工具。（2）两类需求的讨论有点特色，解决需求问题的方法较成功，有说服力。（3）能发表自己的观点和意见，体会较实在。（4）本例似乎有些特殊性，还是要鼓励对自己熟悉的业务领域做项目，否则的话，有时会事倍功半。（5）最好再列举更多的项目或例子，使方法与工具的讨论更全面一些。（本文主要参考了上海解亮等人的论文）

 

 

系分论文5

论Java技术在因特网平台上的应用——论文1：ERP开发的应用

 

【摘要】

  根据某类企业的迫切需要，我所在的信息技术公司组织了一个企业资源计划（ERP）项目的开发，希望推进我国ERP应用的发展，也希望更深入有效地运用Java技术。该项目的内容涉及到某类行业的企业生产经营的全过程，其基本目标是为了提高企业的劳动生产率，增加企业的利润，优化配置企业的资源，使企业的整体运营水平能上一个台阶。这是一个基于Java技术的Intranet典型应用项目。

  在该项目中，我承担项目负责人的重要职责，比如在项目的准备阶段，我曾组织了对项目组的成员进行该类企业业务流程方面的培训；在项目需求分析和设计阶段，我着重考虑了架构好系统的框架和原型，为项目组及其他分析员进行下一步的细化分析奠定了坚实的基础。同时我还组织好项目总体组，把握住各模块之间的接日分析，保持各个分析员之间实现密切的沟通。在系统的开发阶段，做好开发、测试方面的协调和同步工作，保证系统的可靠性，在系统的实施阶段能够顺利地推进项目，此项目开发后的应用已得到了用户们的一致好评。

【正文】

  与国际上ERP项目的广泛应用相比，我国的ERP应用水平尚有相当大的差距。根据某类企业的实际迫切需求，我公司组织了对一类ERP产品的开发，我有幸参与了该项目的分析与设计，开发的成果是一个典型的Java技术应用于Intranet的实际项目。

  在选择具体的技术方案时，我们曾经进行了认真的思考和研究。对于选择普遍采用的微软模式的平台方案，还是跨平台式的Java方案，我们曾举棋未定，这是因为微软的VB＋ASP已成为大家在较长时间工作后认可而熟悉了的方案。而Java由于其环境要求高与执行效率低的老大难问题，成为我们担心害怕的重要因素。但是Java的跨平台特性越来越成为人们的关注点，尤其是许多大中型的企业，他们现有的网络系统都是基于多种平台的，对跨平台的要求和呼声极为强烈，而对软件公司来说，软件的跨平台特性有可能会节约开发成本，降低维护量，也能获得更多客户的认可。综合考虑了诸多市场行情与行业发展因素，最终决定一定要用Java。所幸的是现在Java用于因特网的开发也已经越来越便利了。

  目前Java在因特网上的开发技术已呈白花齐放之势态，有最初的Java Servlet，有与数据库联系在一起的SQL-J，还有可与ASP和PHP相媲美的JSP。尤其是JSP技术的迅速发展，使得Java的网络应用不再是少数人的专利，JSP以其执行的高效性和使用的方便性，已成为近年来大家首选的因特网开发技术，JSP是一种页面开发技术，它以Java为其服务器端语言，结合Java Script作为其客户端语言，能方便地实现页面的表示。

  选择好了后端的Java和前端的JSP，还有一项重要的任务，那就是前后的联接。由于JSP主要用于页面表现，需要表现的内容要封装起来，这样，为了保证主要商务逻辑的安全性，我们采用了Java Bean作为桥梁，即客户端JSP通过其中Java Bean的使用，完成主要的商务逻辑功能。在后台，将Bean构造好，形成一个强大的Bean库，再由前台JSP进行使用。

  在进行Java Bean的规划时，我们下决心作出很大的投入，因为这些不仅是我们当前项目中所需急用的，而且还应成为公司长期积累使用的一个强大的资源库，能实现一定程度的资源共享和软件复用，为其他项目开发打好基础。因此，此次规划的目标是形成公司Java技术的Java Bean的平台库。

  我们根据Java Bean所体现的类的用途，将这些类分成几个层次。最底部的一层就是参数化类的构造，这一层的类所实现的主要功能包括通用访问机制，对数据库等其他层次的访问接口和公共处理系统等。中间一层是实体类的构造，这些实体类包括与数据信息相关的结构及其处理方法，其中的重点是包含了一些重要的商务逻辑的处理。这一层类与系统各部分相关，并且其安全性要求很高，直接影响到系统主要功能的体现，因为系统的主体是对一些逻辑进行处理，这就要求这层实体类的规划需要十分认真，做到细节准确。最上面的一层可以称为接口类，这一层类主要用于实现底层的类与前台之间的关系。也只有这层类才能由前台JSP进行Java Bean调用而加以使用，只有这层具有开放性，这一层类除了上述的接口功能外，还应当有一项重要的实用内容，即包括用于实现前台JSP的页面自动构造程序。

  这里所说的页面自动构造程序可以认为是本系统的一个重要特点，目的是为了让用户可以方便地自定义界面，而不需要由程序员修改程序，这样能够极大地满足了用户的要求。页面自动构成程序的主要内容包括对界面元素的定制与修改、位置的修改、动作的触发、行为的控制以及报表设计和计算汇总等功能。页面自动构成程序的设计主要采用上述的接口类与JSP相结合的方式，用类实现元素的定制、控制及关联，并将重要信息加以保存，以利于用户的多次反复修改。该自动构造程序提供了强大功能，已成为我们的一个独立产品。能应用于各个项目的界面制作，实现了我们原先制定的共享资源的目标。

  在前台JSP的应用中，做到了尽可能最简化的程度，这样可以提高系统的安全性。当然在我们的系统中，还存在一些客户端控制比较复杂的情况，为保护这段比较复杂的控制脚本，我们采取了用Servlet的方法，保护这段脚本，从而保证了一定程度的安全性。

  在系统的登录过程中，我们采取了相当严格的登录键检查操作，用户没有供应商提供的相应的键，就无法通过验证而进入系统。对于试用版的用户则提供了一种有效期限约束。这些加密或安全措施，通过在Java Bean中封装了严格而有强大功能的加密算法，在客户端申请验证后才能准予通过。

  在使用这套技术方案的过程中，我们曾经遇到过许多的困难。比如；前面曾提到过要求JSP中代码能够尽量简化，以提高安全性。由于JSP中仍有一些容易让人可能猜测到处理方法的语句及处理的过程，为进一步提高安全性，我们通过查阅大量的网上资料，才形成了一套较好的措施，比如制作JSP的标记库，将有可能被猜测的处理进一步加以规划，对应地生成一套行之有效的实用标记库，这样就又增加了一道很有效的防护墙，大幅度地提高了安全保密性，并且使页面结构的分离达到了一定的水准。又如：在对数据的处理上，刚开始时也总是遇到系统运行会变得越来越慢的情况，最后追查其原因，发现原来是数据的连接过多，我们及时地采用了数据连接池等技术解决了此类问题。

  该系统采用Java平台，提供了深入地使用Java Bean和JSP的方案，其效果是相当显著的，在用户真实使用环境中受到了一致好评，运行也较为稳定。由于采用了统一而方便的页面自动构造程序，用户的界面非常友善，并且可以按用户需求进行定制，满足了用户的适应性需求。而在我们公司的内部，也开始建立了一套基于此平台的资源库，成为公司的今后开发使用的宝贵财富。

必须指出的是，在此系统中，还存在着很多的不足，比如实体类的组装程度尚不尽如人意，根据多种商务逻辑的一些共同点，可以进一步加以抽象封装，使这部分内容能满足多种系统对类似逻辑的处理过程。我将会在今后的工作中进一步加强各方面的分析能力，带领团队不断地超越现在的层次与水准，加强我们的队伍建设，希望有更多优秀的软件产品上写着Made In China。（本文主要参考了上海陈莉莉等人的论文）

 

 

 

系分论文6

论Java技术在因特网平台上的应用——论文2：通信服务平台的应用

 

【正文】

  数据通讯是当前十分活跃与热门的计算机与信息技术的应用领域。某大型通信公司开发了其业务的主要支撑平台，在这里，我们简称之为“通信信息服务平台”，用于在全国与全球开展数据业务的需要。该平台是一个典型的Java技术应用于Internet的项目。

  作为信息技术公司中的一名技术骨干，我有幸参加了该系统的分析与设计工作，承担了相当多的Java应用开发任务。此系统中的软件部分大多由Java来实现，在全系统中我们是这样来用Java构架系统的：

  （1）本系统可分为4层，分别是Browser、表示层、中间件层和数据层。

  （2）表示层用Java中的Java Script来实现页面输出。

  （3）中间件层用Java来实现CORBA，即实现Component（构件），主要实现业务逻辑的封装与复用。

  （4）数据层主要是数据库和存储过程的实现。

  我们在应用Java技术时，所采用的技术和策略可大致上归纳为以下5个方面：

  （1）使Java Script尽量简单，因为Java Script在我们系统中是放在服务器端执行的，该语言是通过一个解释器解释执行的，相对速度很慢，我们采用了两台HP前置机来运行Java Script，但是其运行速度还是不理想，所以我们在设计中把Java Script仅用来显示从中间件层所得到的数据，生成动态页面。在最初的设计中表示层（Java Script）曾承担了一些业务逻辑处理操作，导致效率不理想，因此，我们不得不尽量地减少Java Script的程序量。

  （2）用Java实现CORBA时，应尽量考虑共享和复用。在本系统中，最初的设计是让Java在实现Component时，只是执行一些数据库表的操作，导致表示层的负载较大。后来，我们重新设计时，总结归纳了所有的Use Case，找出了其中可供共享和复用的接口，把相同的业务逻辑操作封装到一个接口中去。因为 Java的执行效率比Java Script要高，因此提高了系统效率。

  （3）在别的项目中，我们曾大量地使用过Java中的JSP技术和Servlet技术，一般人可能不能区分这两种Java技术的区别。为了得到系统的一些执行速率的数据，我们采用了一个著名的压力测试软件——Load Runner来测试这两种技术的差别。测试表明：用JSP和Servlet完成同样的一个操作，并且保证是在相同的测试环境中（相同服务器、压力测试工作站与数据库环境），得到的测试数据却有着很大差别，JSP完成一个操作的平均执行时间大致会是Servlet程序的两倍。在一个企业级应用项目中，这可能是一个很关键的瓶颈。因此，我们得出的结论是：在可能的条件下，尽量地多使用Servlet。当然，与Servlet相比，JSP编程快速，修改方便，在访问量不是很大的应用场合下也是可以接受的。

  （4）使用Java作为整体解决方案时，应尽量使用相同版本的JDK。在用Java作为编程语言的项目中，几乎大多要遇到“汉字”问题，即Java在没有经过转换的情况下，在输出汉字时，很可能会出现乱码。采用不同版本的JDK，解决的方案是不一样的，比如V1.2.2版本的JDK和V1.3版本的JDK解决方法就会有一些不一样，把V1.2.2的Java程序放在V1.3的JDK中，就不能顺利输出汉字了。其根本原因在于Java使用了Unicode编码，和我们中国的国标编码不一样。所以在这个意义上一些人竭力鼓吹的“一次编写，到处运行”似乎不一定能在所有的场合都行得通。

  （5）使用Java时，应尽量遵从软件规范。在Java中有一个JVM的概念，即在Java虚拟机中使用了一个垃圾收集器，专门用来回收内存。但是该垃圾收集器在给编程人员带来方便的同时，也隐埋下了隐患。在程序设计中，并不能强制执行垃圾收集器，所以，开发人员不能确定某对象是否已释放，常常让编程人员养成依赖自动收集的坏习惯，因此我们要求：在Try，Catch之后必须明确要求回收内存（当然，也只能是通知垃圾收集器来回收垃圾），这样可以有效地提高系统稳定性。

  以上这些实用性的技术与策略，是我们在实践中的一些实际体会，仅供各位开发人员根据实际情况参考。

  当然，在使用Java作为解决方案时，也会遇到很多让我们头疼的问题，这些问题导致同时执行的并发性比较差，系统速度慢等等。归纳起来看，我们曾遇到过的主要具体的问题有：

  （1）用Java来实现CORBA中的Component，有时效率会比较低。

  （2）用Java来建立数据库连接往往会比较慢。

  （3）用JSP编程时容易导致系统信息的扩散。比如，如果有黑客攻击一台运行JSP程序的服务器，他可以故意地输入一些非法字符或异常信息给JSP程序，于是程序执行将出现异常。这时，就会在页面上打印出相应的错误信息。很不幸的是，这些信息极有可能暴露出这台服务器的JDK的版本号与路径信息等内容。这往往容易让黑客们有机可乘，有可能去抓住系统的漏洞。

  在发现了这些问题后，我们经过仔细研究，找出了一些解决办法。比如：

  （1）既然用Java实现Component比较慢，我们就尽量减少Component所执行的业务逻辑量。争取把能够放在存储过程中实现的操作，尽可能在存储过程中加以实现。众所周知，数据库的存储过程操作，比起在Java程序中执行数据库操作要快得多。

  （2）既然用Java建立数据库连接比较慢，我们就可以把数据库连接封装成连接池（Connect Pool），从而能非常有效地提高系统效率。我们也曾经用“Load Runner”作过压力测试，使用连接池比不使用连接池的速度要快上3～5倍。

  （3）为了对付JSP程序与Servlet程序会打印出异常系统信息的问题。我们曾查阅了很多JSP或Servlet的资料，最终是毫无头绪。但是我们可以换另一种思路，即是不从程序下手，而从Web Server着手，我们可以把Apache配置成为使这类异常信息不再打印出来，而是使之仅出现一个通用的异常说明的页面，这样，就能十分有效地解决这个问题。

  在我们使用Java作为编程语言的这么多项目中，绝大多数是比较成功的。Java语言作为一种快捷、稳定的计算机语言，开发基于因特网应用的项目大多是相当稳定和比较适用的。

  在我个人看来，Java的应用前景十分光明，大体上可以着眼于以下方面：

  （1）在因特网上将会有更加广泛的应用。

  （2）在嵌入式设备中，Java也大有用武之地。比如，在最新推出的Java技术中，Java已经进入了手机领域。

  （3）Java程序大多以线程运行，占用资源少，会逐步代替ASP与CGI程序。根据第三方测试表明：JSP程序比ASP程序要快2倍以上。用JSP代替ASP应是大势所趋。

  （4）Java在无线互联网中的应用将会更加广泛。Java支持WAP，可以方便地用Java开发WAP程序，实现WAP应用。

  （5）Java与XML的无缝连接使Java在数据传输和异构网络通信方面有着很大的优势。

  就我个人而言，我将会在相当长一段时期内致力于Java在无线互联中的应用，为我国的移动通信事业开发出更多的优秀实用的项目。

评注；参与了一个较大的项目后有实践体会。全文都采用1、2、3、4方式，文章的风格显得单调，不大吸引人。但是本文的优点是；（1）写得很有条理。（2）内容的选择合适。（3）所列举的策略、注意事项与发现的问题都很现实可信。（本文主要参考了广州王海波等人论文）

 

 

 

系分论文7

论Java技术在因特网平台上的应用——论文3：银行业的应用

 

【摘要】

  因特网上应用的日益普及与深化，为Java技术的运用提供了广阔的活动舞台，也大大推进了Browser/Server模式的企业内联网应用与网络计算。

  作为某信息公司中的技术骨干，我有幸承担了某银行信贷管理与查询系统等的开发任务，独立地完成了其中的系统设计、类设计、部分开发及测试工作。

  整个系统完全按照J2EE的标准来设计。前台界面应用了JSP技术，控制部分采用了Servlet来开发，业务逻辑应用了EJB技术来封装，应用服务器采用了支持J2EE标准的BEA公司的Weblogic，后台的数据库选用的是Informix7.3，目的是为了与银行中其他业务系统数据库保持一致。在硬件平台上，我们选用的是HP公司的某台中型服务器机器，操作系统是HP-UX。

  该系统界面运用的是IE，它不仅兼容性较好，而且已为广大用户所熟悉。系统运行后，各个支行都普遍反映界面友善，功能强大，开发的效果令人满意。

【正文】

  在银行应用中私人的储蓄、企业的会计、国际的业务、信贷、财务管理都是十分重要的，它们构成银行的基础业务系统。我从事开发的信贷业务更是银行利润来源的重要部分。与储蓄，对公等以交易事务为主的业务模式有所不同的是，尽管信贷也是交易，但需要更多其他辅助信息的支持。如客户的基本资料，在本行内业务发生状况、信用等级、是否有逾期贷款未能归还等。各个支行的有关业务人员及分行管理人员都希望能方便及时地了解这些信息。传统的基于终端的用户界面难以传递这么多信息给用户，所以我们决定采用基于测览器IE的用户界面，一方面IE使用方便，不需要专门培训，另外它是与Windows操作系统捆绑在一起的，也可节省前台费用。在开发技术上有ASP，JSP可供选择。

  由于考虑到Java技术在Internet上的迅速发展，J2EE更是提出了全新的用语言来统一平台的思路，于是我们决定采纳J2EE标准，并选用了JSP。在设计上，基本上是采用了一个交易画面对应于一个JSP程序，充分发挥JSP动态处理页面的长处。

  为了使设计有更好的可扩性、灵活性与逻辑性，能为以后扩展奠定坚实的基础，我采用了（Modelu，View，Controller）的MVC设计模式，View全部由JSP实现，而Controller则是设计了一个Servlet程序，它负责处理前台浏览器传送来的所有请求，并按事先定义好的路径/程序关系，分发给相应的JSP程序去处理。由于Servlet本来就是为Java服务器端编程来设计的，因此由它来负责服务器端的处理是相当合适的。

  在开始设计时，我运用了构件技术，由EJB承担起设计模式的Modelu角色。具体的贷款开户，放款，结息逾期贷款，归还贷款等交易都对应一个具体的EJB。为了将这些处理逻辑与相应的数据库操作分离开，能更加便于维护，我将处理业务的EJB设计成Session Bean，而为每个Session Bean再配备一个相对应的Entity Bean，用于访问后台的数据库。贷款管理中有很重要的一点是进行查询，我按照需求分析的结果，为每类查询都设计了相对应的Bean，其目标是尽可能地提高查询的速度。

  在对数据库的存取中，我本来的设计应用Informix JDBC所带的Driver Manager，这样，在存取数据库中的Bean中就要把Driver及Server写入，后来考虑到应尽量提高应用的平台独立性，在参阅了J2EE中JDBC部分的说明后，改用了Data Resource的处理方法，这样，即使以后数据库换成Oracle或其他产品，程序也不用修改，只需要在配置时进行变动即可。

  在这次信贷管理系统的开发过程中，Java的平台无关性优势，在开发人员从事开发的活动中体现得淋漓尽致。由于经费相对紧缺，我们的开发环境是各个项目组共用一台HP机器，虽然每个开发小组都搭建了自己的环境，但项目一多，特别是遇上结息与批量测试等场合，机器就显得不堪重负，使开发与测试工作的效率大为下降。我们小组由于采用的是Java技术，大家可以在自己的NT机器上搭建相同的环境。这样一来，大家平时的开发工作，包括JSP，Servlet，EJB的程序，都可以在本地完成，只是到测试或展现阶段才需放到HP开发机器上进行。

  以前我们开发的Web应用，往往只是应用了部分的Web技术，如采用Apache Web Server、ASP开发语言等。整个体系的集成与组合往往不够理想，这次由于我们采用的一整套符合J2EE标准的组件，整个系统的协同性与一致性非常之好。再加上有一个支持J2EE的应用服务器——BEA Weblogic，以往我们做得不理想的复杂配置，模块间的连结，如今都用不到再操心了，只需在图形化的配置工具中，输入系统所需要的配置，如路径与实际应用程序的关系，组件中的EJB引用，Data Resource的属性等；全部配置完成后，Weblogic会替我们完成项目的部署，并将这一切有关的程序都封装起来。

  原来，我们开发小组的文档编制任务显得非常之繁重，因为整个系统既有交易部分，又有管理查询部分，交易、数据与源程序都很多。为了解决这个问题，我们直接应用了Java源程序中的Javadoc导出文档，这样不仅文档美观，而且能够保持与源程序的一致性，实乃一石二鸟之举。

  整个项目完成后，用户使用下来都觉得界面友好，操作简便。但是我心里知道．这个系统还有很多可以加以改进的地方。

  首先，基于Java系统的开发需要资金较多的投入，由于该系统受到经费的限制，只申请到一台生产用机，这样，Web Server、Application Server、DB Server只能被挤放在一起。虽然Weblogic能实现部分负载平衡，但在将来的业务发展时，这样的分布肯定不是最理想的。好在我们在设计时已经考虑过尽量有良好的扩展性，在以后条件许可时，只需进行在不同机器之间的进一步部署即可，应用程序大体上无需改动。

  其次，在设计上，可以采用UML的产品，如Rational Rose，另一方面，Rational Rose具有自动代码生成功能，也可以大大节省开发的成本。

  最后，目前的信贷管理系统相对用户数目量不多，当推广类似系统需要拥有大批用户时，基于Java的系统的响应时间与系统分布都会有较为突出的矛盾出现。

  以上这些，都是我在今后的系统设计与开发中需要加以注意的地方，也是运用Java技术应当努力的方向。（本文主要参考了上海戴黎平等人的论文）

评注：讨论具体，应用较为深入，表达清晰。存在的问题属实。

 

 

 

系分论文8

论改进Web服务器性能的有关技术——论文1：银行业的应用

 

【摘要】

基于Web技术的数据库应用是当前应用的一个热点，在用户数目与通信负荷很大的场合，提高Web服务器性能是一个迫切的课题。本文从笔者参与某个银行系统项目开发的经历出发，阐述了提高Web服务器的性能应渗入到项目论证、选型、开发、运行和管理的各个环节，只有各个环节都能充分考虑到性能与质量的需要，系统的性能才是真正可保证的和可扩充的。

文章从系统的实际运行与相应的经验出发，阐述了性能改进方面的一些具体措施。

比如：在本文中讨论了Web服务器平台的选型考虑；Web服务器的配置管理；应用系统本身的优化与预先设计系统时可扩性的性能保障等具体内容。

通过技术上的分析与改进，综合性地运用多类措施与手段，在实际系统中，Web服务器运行的性能得到了一定程度的保证。

【正文】

我所在的单位是把目标定位于金融领域开发IT应用的一家信息技术公司。随着金融电子化建设的发展和商业银行之间市场竞争的加剧，各主要商业银行不断通过信息技术提供新的金融产品，并且希望能整合市场渠道。比如主要的商业银行不断推出形形色色的网上银行服务。在这种背景下，本人参与了开发新一代网上银行产品，涉及到提供网上个人理财服务、网上外汇买卖服务、网上企业服务等具有市场竞争力的产品。作为项目开发的组织者之一和主要的技术骨干，在整个项目开发过程中始终要处于第一线，从而在改进Web服务器性能、提高整个网上平台系统性能方面收获良多，在本文中简要讨论如下，希望与读者们共享经验。在Web服务器配置与优化方面，我有如下几方面主要的体会：

第一方面是Web服务器选型考虑。

在Web服务器选型及网上平台搭建之初，我们就已充分考虑整个网上平台的性能及可扩展性问题。这一考虑为该系统的稳定性及扩展性能力方面打下了坚实的基础。

某银行原有的一些网上产品由于开发较早，故而采用的是老式的HTTP Server+CGI程序调用的方式。这时，每一客户请求需要对应于后端系统的系统进程来运行CGI程序来处理，系统的开销相当大，系统的扩展能力也很差，性能已不能满足业务处理的需要，故而在为此银行系统具体选型的时候，我们一开始就否决了这种方案。

通过市场上同类产品的比较选择，我们选择了国际商业机器有限公司IBM的Web Sphere产品系列作为该行网上银行系统的建立平台。作出这样选择是因为Web Sphere基于使HTTP Server和应用服务器相分离的整体架构，同时支持JSP、Servlet和企业组Java Bean等轻量级线程规范，所有的请求对应于应用服务器上的处理线程，系统的开销低、效率非常高，同时Web Sphere整个体系结构相当的灵活，为适应扩展需要可以作不同的横向和纵向扩展，从而可以满足各银行未来的扩展需要。

正是因为在一开始选型的时候我们就已考虑到未来的扩展需要，整个系统在接下来的几次性能改进方面，我们大体上都能相对顺利地达到了预期目标。

第二方面是Web服务器的性能配置。

在一开始系统上线的时候，由于系统的负荷不是很大，为了节省系统总拥有成本TCO投资，我们在一台较低配置的IBM RS6000上投产了该系统。整个系统的HTTP服务器、应用服务器、通信服务器等均位于该台机器上，由于初始投产时用户不多，所以系统的性能基本上能令人接受。

但随着业务的发展和用户访问量的增大，我们发现该服务器的响应变慢，系统的CPU利用率和内外存交换显著增大。经过跟踪，我们发现关键原因之一是系统的内存不足的缘故。由于网上服务器把大量用户的会话信息保存在内存中供给应用系统使用，当内存不足时，大量Session信息被迫交换至硬盘，大量CPU时间消耗在等候内外存的交换上，系统效率迅速下降。

鉴于这种情况，我们把该服务器的内存由2GB扩充为4GB，同时相应调整用户会话信息的保存时间，这样整个系统的效率又回到较为理想的状况。

由于新应用的不断投产及数据库操作的日益增加，我们后来逐渐监控到系统的数据库处于繁忙状态，系统的错误日志也记录下了供应用服务器使用的数据库连接处出现资源不足的情况。在这种背景下，我们认为整个系统由于硬件配置所限，应该进行横向扩展，因此我们把数据库服务器分离出来，配置到另一较高性能的服务器上，相应定义的数据库资源也大幅增加，这样整个系统的性能又处于较为理想的状况。

第三方面是对应用系统进行相应的优化以提高性能。

Web服务器配置及相应的硬件扩展不失为解决系统性能问题的一条捷径，但应用系统的优化也是应该重点加以考虑的，毕竟它能够在投入较少的情况下提高系统的运用效率。

在开发的初期，我们就已经十分注意系统的利用效率，比如提醒程序员尽量不要利用用户会话信息(Session）来传递大的对象，对于内存要注意回收等。同时，通过内部的交流会推广与介绍一些小的、有用的编程技巧来提高开发人员的水平，通过代码的抽查，希望能在早期就发现问题等。

在系统运行期间，我们通过监控发现，应用服务器所基于的Java虚拟机，其内存堆的空闲空间有不断下降的趋势，每隔若干天导致空间消耗殆尽、无法分配新对象空间，从而导致系统重启。在排除了系统本身问题的原因外，我们确定为应用系统的开发有问题。通过从网上万载IBM公司检测Java虚拟机的相关工具对JVM进行监控后终于发现系统内部存在着不能回收内存的对象，再通过查找相应的程序发现在该程序中有“环状”的对象引用，从而导致对象使用后不能被垃圾收集器所回收。这个问题的解决过程虽然十分艰苦，但由于该问题不能通过升级硬件或增加资源配置而得到根本解决，会给系统带来很大的隐患。所以，整个过程的分析与解决是完全值得的，更何况通过查找故障原因的过程，给整个项目组上了生动的一堂软件质量保证课，对项目组的质量意识起了很大的促进作用。

所以说改进Web服务器的性能井不单纯是系统管理方面的工作，它渗透到开发以及

系统运行等一系列环节中。

第四方面预先考虑未来的扩展与性能需要。

随着系统的发展及成熟，考虑到用户访问量的不断上升，为了预留系统的发展空间，我们最近又对整个系统作了一个系统性的升级。通过引入多台HTTP服务器及应用服务器并行工作提高整个系统吞吐量及单点故障克服能力。由于在一开始选型的时候就已经充分考虑到动态负载均衡及横向扩展方面的需要，这一项的升级无需对整个系统的体系结构作根本的变革，对应用程序来说，更是没有造成任何影响。

整个项目历时近两年，从这两年的系统情况来看，整个系统是成功的。根据我亲身的经历，系统性能并不单纯是系统运行与管理阶段的问题，而是渗透在项目论证、开发以及运行的各个阶段。只有在各个阶段都能充分考虑性能方面的需要，在实际运行时，整个系统的性能才可能真正有保障。在技术方面来看，可以综合利用选型评估、硬件扩展、应用优化和系统配置优化等一系列的手段；比如在硬件扩展方面，又可以分为主要部件扩容，纵向升级、横向升级等方面。在我们的项目实践中，曾综合地利用了上述的各种手段。比如某银行的整个系统从日访问量不足1万至现在的每日超过I0万次以上的点击的发展情况来看，整个系统的性能保障及提高方案是比较成功的。

评注：实践过程较有说服力。条理与思路相当清晰，技术措施与管理措施的推进也很明确。所论述的技术还有一些局限，不够开阔。（本文主要参考了广州黄昌湛等人的论文）

 

 

 

系分论文9

论改进Web服务器性能的有关技本——论文2：数字图书馆类的应用

 

【摘要】

  一个大中型的图书馆信息系统涉及到许多方面的技术与方案，本文着重讨论与Web服务器性能有关的一些内容。

  本人有幸作为项目负责人之一参与了某大型图书馆数字化信息系统的设计和基于Web应用软件的开发工作。由于在数字化图书馆信息系统中流通着的大多是数字化的索引、文摘、全文、图像或音频视频等多媒体信息，对Web服务器性能有着较高的要求。

  结合实际工程的经验，本文将从硬件实现手段（缓存服务器、均衡负载设备、Web双机镜像、CPU和网卡的提升、网络带宽扩充）和软件实现手段（三层C/S软件结构设计、应用程序部署）等两个大方面论述如何提高Web服务器的性能，以便使用户能够更快捷、高效、安全地使用应用系统。

【正文】

  随着Intranet信息技术的发展，图书馆为了更好地发挥其图书流通、资料检索和学术交流的职能，图书馆的数字信息化工程也势在必行。某图书馆为了尽快地步入世界先进图书馆的行列，已经启动了一部分的数字图书馆工程。

  该数字图书馆工程主要包括对外信息Web发布系统，交互式检索网、后台馆藏信息管理系统、多媒体资料采集制作以及VOD点播系统等。本人有幸作为项目负责人之一，参与了整个数字化信息系统的总体设计，并参与了基于Web的一些应用（如对外信息发布系统、图像/全文混合检索系统、VOD点播系统）的开发。

  某图书馆数字化信息系统从网络环境上讲，主要划分为多个网段：（一）Intranet接入部分，采用2M的DDN专线；（二）公共网段（非军事区），主要包括前台发布数据库服务器、Web服务器、E-Mail/FTP/DNS服务器、检索服务器及SAN网络区域存储设备；（三）是内部局域网，包括内网Web服务器、后台馆藏数据库服务器、OA服务器等。（四）是VOD点播专用网，包括音频视频点播服务器等。由于制定了严格的网络级和应用级访问权限，通过具有三层交换能力的高性能交换机和安全授权认证系统等，有效地控制了防问权限，确保了数据的安全性和完整性。考虑到经费和人员素质及今后的维护管理运营等方面，操作系统采用Windows NT平台，服务器选用DELL高端的系列，数据库采用IBM的DB2。主干网为千兆快速交换式以太网，局域网百兆到桌面，VOD点播网十兆到桌面。

  在该网络环境下应用主要分为三大部分：（一）对外Web发布系统、对外图书辅助检索系统；（二）后台馆藏信息管理系统和图像/全文混合检索系统；（三）VOD点播系统。由于绝大部分应用采用Browser/Server方式结构，最终用户在本地只需安装IE或者Netscape Web浏览器，在后台数据库服务器的支持下通过网页方式请求和访问各类应用服务。另外，由于在图书馆信息系统中流通的多为索引、摘要、全文或音频视频等多媒体信息，对Web服务器性能与网络带宽等都有更高的要求。

  通过不断地试验和实践，我们发现从以下几个方面可以相对有效地提升Web服务器性能；

  （1）缓存服务器和均衡负载设备使用可以缓解访问瓶颈，提高网络带宽、实现均衡负载。

  缓存服务器也称为cache服务器，可以存储cache静态的内容如网页、多媒体点播资源和会议实况（已压缩的、有一定格式要求的）等。此外，目前美国cashflow缓存服务器，已经可以存储cache数据库、ASP等动态内容。cache服务器通常放到防火墙之外，外网Web服务器之前，因此Internet用户点击网页不再直接访问网站Web服务器，而是访问cache服务器。

  由于cache服务器具有多个CPU和高速大容量I/O通道，独立的OS，因此能大大缓解Internet访问瓶颈，而且也具有一定的抗黑客攻击的能力。

  目前某图书馆采用这种方式，把大数据量的静态图片、点播资源、虚拟三维应用等都事先置放在cache服务器中，即使现今只有2M Internet的接入带宽，以上应用的播放速度和效果仍能让用户满意。

  另外一种方式采用均衡负载设备或Web双机镜像。这种方式通过负载均衡的方法达到 Web访问性能最优。Web双机镜像是较早以前流行的方式，虽能使系统可靠性提升，但由于双机总是在互相询问对方状态，将会影响一定的访问性能。均衡负载设备是独立于Web服务器的硬件，它和Web服务器及网站中其他服务器接在同一交换机上，通过负载调度程序为各个服务器分配工作量，从而，能达到充分利用资源，提高访问性能的目的。只是由于某图书馆目前对外发布资源相对仍较少，只采用了三台Web服务器，因此目前的均衡负载设备作用还不显著。

  （2）从Web服务器的配置来看Web服务器自身CPU个数及速度、网卡数量、Web服务器与防火墙的位置关系等，都会影响到Web服务器的性能。

  从Web服务器硬件本身来讲，CPU个数的增加、网卡个数的增加、I/O信道的扩展无疑可以直接地提高Web服务器性能。此外，由于千兆口的防火墙目前较少且费用较高，如果把Web服务器放置防火墙之后，一定会大大影响Internet访问性能。某图书馆采用IDS（入侵侦测）+Web服务器（服务器防火墙，较低端，不会影响流量）+应用服务器+数据库服务器（防火墙，高端），分层次的安全模式，既保证了系统的安全性，又提升了网络访问性能。

  另外，某图书馆还采用了SAN网络区域存储来提高服务器访问速度。

  （3）三层C/S软件结构设计和应用程序的适当部署也会提高Web服务器的性能。

  将业务逻辑、通用访问接口与数据等相互分离、分别置放于Web服务器、应用服务器、数据库服务器上，通过程序功能和逻辑的合理部署，也能大大改进Web服务器性能。

  一般的原则是，Web服务器只需接受Internet http访问请求，使Web只有最少的任务，把实际处理交给各个应用服务器处理，然后返回结果给Browser。某图书馆采用这种方式专门开发了搜索引擎应用服务器和混合检索应用服务器等，达到了良好的应用效果。

  事实上，Web服务器的性能提升还存在很多手段和方法，比如CPU与存储之间关系，Web交换机等等，有待于我们进一步的实践、分析和讨论。（本文主要参考了上海童茵等人的论文）

评注：主题鲜明，条理也较分明。但所讨论的技术应更有机地结合于项目的实例。

 

 

 

系分论文10

论实时控制系统与企业信息系统的集成——论文1：通信业应用

 

【摘要】

  近年来，在应用需求的强大驱动下，我国通信业有了长足的进步。现有通信行业中的许多企业单位，如电信公司或移动集团，其信息系统的主要特征之一是对线路的实时监控要求很高，数据量庞大，如何将实时控制与信息系统集成在一起便成为系统实施的一个关键部分。

  在参与了某个通信公司的一套网管系统以及决策支持系统的设计后，我们分析了两者的集成与应用工作，深切地感受到有一个良好的设计策略以及重视所选用的工具是一个关键。这个项目主要是对下属各分站的子网以及有关链路的连通情况进行实时监控、实现报警、路由控制和授权等功能，其关键在于提供一个实时显示情况的地图界面，井将数据汇总和组织，建立起数据仓库以及进一步实施数据挖掘分析，从而能支持企业的决策分析。我作为设计人员之一，着重在本文中讨论控制系统与信息系统集成时的策略。

【正文】

  众所周知，通信行业需要有一整套监控通信网络的手段，其工作特点是涉及到的各分站与基站的在地理位置L的分布性，更加需要有在更高一级提供检测不同分站链接情况的手段。一般来讲，由于数据都是海量的，所以，如何将整个网络系统所得的数据及时处理，以便和决策部门的分析相结合，也成为迫切需要解决的重要课题。简言之，分布性、实时性以及数据海量性是解决整个系统设计和集成的核心问题。

  首先，让我们来讨论一下“网管监控系统”。由于我参与设计与开发的这个系统并不是位于基层的分站，其定位在将下属各分站的主机通信数据（包括数据流量、链路负荷、通往其他结点即主机的连通情况等）加以收集，所以对于具体通信事务的底层操作要求并不很高。

  考虑到上述原因，我们采用了一个地理信息系统开发平台Mapinfo并采用Delphi编程，后台用SQL Server数据库（这是由于考虑到决策所需要用到的是Microsoft公司的OLAP Service）。在分析和计划之前，我们先对ITU801标准做了详细的探讨，这只是一个有关子网和链路定义以及分层等描述的标准，在听取了许多分站人员的建议后，将MAPINFO公司提供的一个相关的MAP X的Active X控件嵌入到Delphi程序中，利用MAP X中提供的丰富的类以及操作，比如Object、Layer等实现网管界面，井且加入了子网和链路的概念，对属下的分站可以随意地组合成为不同子网，而且实现了放大与缩小的功能，大致可以将整个地区的分站集中在一张地图中，能显示在屏幕上，这时，只是显示出各个分站的概要，小到可以显示出某台主机的机柜、机柜直到插件板（因为这些都要实时监控）。我们采用了分层的方法来实现以上缩放。对于一些静态的数据，如分站，主机的位置等则先用Mapinfo公司提供的一套编制地理信息的工具（MAP X是其提供给编程工具的一个Active X控件）做成静态的层次图放置于数据库中。

  我们新做成的这套系统通过与各分站的专用线路加以连接，能实时地得到数据，显示于地图上，反映出各站、各子网、各链路的实时状态，并能将控制命令传回分站（如强制链路中断、路由转换等）。

  现在，让我们来讨论其中最为关键的问题，即是要将实时控制系统与企业信息系统加以集成，我们的设想和体系结构大体上可以用一张简图表示（此处暂略）。

  在这个体系结构中，由各分站保留着详细的数据，网管系统则在一定时间间隔内将汇总到的数据作少量统计，抽取其中需要保存的内容放入数据库，如每分钟流量，某分站与其他分站每分钟通信流量，在该分站中某个链路的负荷（这些链路有可能是动态分配的，也可能是固定分站之间的通信链路）。尽管如此，数据仍然是海量的，因此，如果要把这些数据都直接送到各个决策部门，比如送给市场部门是不现实的。所以，我们在数据库的基础上建立了数据仓库，确定了客户、时间、通信量、计费和故障等几个数据仓库的主题，每隔一定时间对数据库中的原始数据进行清理与抽取等预处理工作，建立好数据仓库。这里的预处理包括了许多方面的内容，比如有建立计算时间，但是无计费的（计费值为零）的数据，应视为建立失败的无效数据，需要予以剔除；某些企业租用的是专用线路按月计费，中间的通信因此无计费的一些有关记录也应剔除等。

  在预处理之后，再利用OLAP Service的分析将数据融合与汇总。按照决策部门的需要提供相应数据（比如：市场部门需要每一分站的收益，客户分布情况以及客户费用等）。这些都可以由OLAP Service对数据作预先处理，此时处理完的数据在逻辑上是以立方体（CUBE）形式存在的，其占用的存储空间便能显著地降低，如1999年8月有2000万条通讯记录，即使形成作为备份的文本都需要4G空间，经过OLAP Service处理后仅需200M左右空间，因此，经处理后的数据主要存放于另外的相关部门的机器中，而不能与主服务器放在一起。

  最后，再来讨论由决策人员所使用的系统。由于这些部门并不分散，我们就没有采用OLAP Servce的Web发布方案。采用Delphi编制了访问OLAP Service的客户端软件，用了OLAP Service提供的、Cube Browser控件，用相似于网页的界面提供了数据立方体的各种操作，如上钻（观察角度从月转到季度甚至年），切片，旋转等操作。为了便于输出打印数据，还内嵌了Microsoft的Excel数据透视表，可以将在Cube Browser上所看到的数据转化为Excel的表格形式，或者转换成饼形图、柱形图和曲线图等，比如可以观察每天24小时通信流量的分布曲线图，可以发现在夜间12点以后明显通信流量减少，而决策部门便可制定某些优惠或减价措施吸引更多客户在12点之后使用网络。

  另外，在采用OLAP Service中的数据挖掘功能时，其中提供的两类算法分别是基于决策树的分类和基于决策树的聚类，市场部门的聚类算法将客户根据费用情况加以聚集，以期发现处于同一消费水平的客户的共同特征，便于制定政策，吸引客户。这方面的努力我们将会进一步持续进行，以保证有足够的海量数据而发现其中的规律。

  整个系统运行后，其数据采集，数据处理等一系列工作都由程序定期地自动进行，该系统应用已有一段时间，受到了不少好评。当然，也发现了其中有不少问题，比如；主服务器数据库的容量问题，主站与分站的通信效率问题，还有在网管系统中，网络故障的确定还不够细致，需要由分站再具体化加以确定，决策系统与网管系统之间还缺少直接通信手段等，这些都有待于进一步的解决与改进。

  实时控制系统与企业信息系统集成化是推动从事生产制造、测量与监控等业务的企事业单位真正迈向信息化，提高工作效率的一个重要动力。如果是大型企业，更需要有一整套的系统，支持Web发布，智能查询，自动识别如用于故障预测和数据挖掘等技术，从而能够将底层的实时监控与高层的决策更好地集成在一起。展望其前景，无疑是十分美好的，但是我们认为相应的工作量很大，在技术上仍然需要有所提高和有所突破。

评注：能紧扣集成的主题，结合实际作了较有深度的论述。所讨论的数据库和数据仓库技术符合企业信息化的方向。对遇到的问题的举例剖析还不够，实时控制方面的论述也可更细化一些说明。（本文主要参考了广东林嘉宜等人的论文）

 

<尚大教育，教育至上，人才为大：sdedu.cc>