求描述方式，如对于复杂的业务处理过程，我们就采用了判定树的方式进行描述。在用例文档的描述中我们汲取了前面的教训，使用通俗的语言进行表达以方便与用户进行沟通，如对于前置条件和后置条件我们就换成了前提条件及处理结果，避免了用户理解冗长而晦涩的专业用语，有利于与用户进行沟通并可简单明了的表达用户使用系统所要完成的任务。
最后，在用户需求分析的过程中注意用户对系统的非功能性需求进行提取与处理。在系统需求分析的过程中用户往往不会对系统的非功能性需求，如可操作性、界面的简便性及系统性能提出明确的要求，而这也往往是系统分析人员容易忽略的一个方面。为此，在系统分析的过程中我要求系统分析人员注意用户描述中的“简单”、“快一些”等词语的分析。如在了解处理客户扣款银行文件时用户抱怨系统处理不方便，而且在处理时其它业务都得停下来等。分析人员在知识这个情况时及时了解到系统在处理此业务时采用了独占的方式访问数据库，而且由于每次需求处理的记录都上万条，所以造成了以上情况。为此用户需求中的一些隐性的非功能性需求也得到了很好的处理，对于后期的系统设计有很好的帮助作用。
需求分析阶段的成果是用户需求规格说明（SRS），完成SRS后再用户代表进行沟通确定以为系统的设计开发工作设定一条基线。通过综合采用如上所述的方法，在用户需求分析的过程中系统分析人员很好的把握了用户的需求，使得需求获取的效率与质量都有明显的提高，为系统的设计工作奠定了良好的基础。总的来说我们的需求分析工作是成功的，在系统设计开发阶段没有出现因需求不完全而停工的情况，系统已于2004年底顺利完成并能够较好的满足用户的要求，得到了公司领导及同事的认可。同时，在用户需求的把握上也存在一些不足之处，（1）、系统分析人员对于Rational Rose的使用不是很熟练导致需求开发的速度有所降低；（2）、在用户需求与分析人员的理解存在冲突时过份迁就用户而使部分需求用例开发的质量不高。
论软件开发平台的选择与应用
摘要：
本文以我2004年在某自来水公司实施水务综合管理系统的经历为例，详细介绍了软件开发平台的选择与应用，我本着软件开发平台的开放性、分布性及先进性等原则，对当前主流的J2EE及.NET平台进行对比分析，重点考虑了以下因素：（1）、开发平台的使用要有利于保持系统的开放性；（2）、开发平台的使用要有利于保持系统的兼容性与先进性。通过仔细的评比我们选择.NET作为本项目的开发平台，在系统设计时构建多层应用体系结构以适应系统在布署、维护及性能方面的要求，并注意了设计模式的使用为系统的可扩展性奠定了良好的基础，同时使用Web服务及XML的数据交换格式为与异构系统交互提供了方便。基于互联网的企业应用要求开发平台具开放性、分布性及平台无关性，作为一名分析人员则需要不断的学习和了解新的技术以更新自己的知识结构。
正文：
本人所在的某市级自来水公司经过多年的信息化建设已形成数个应用系统，如客户用水工程系统、用水抄表计量系统、营业收费管理系统、欠费催收系统、生产调度系统及客户服务系统等。由于原来的系统都是由各部门或分公司为主导建设的，因业务需求的“局部性”及当时技术条件的限制导致系统之间很难共享信息，已经不再适应公司业务发展的需要。为此，公司领导经过研究决定于2004年利用自身技术力量重新开发设计一套水务综合管理系统，我作为技术部的负责人及主要技术骨干，主持并参与了系统的方案选型、系统分析、设计及部分开发工作。
新的水务综合管理系统涉及到客户用水工程、抄表计量、营业收费、欠费催收、用水报障、生产调度、客户服务及网上业务授理等，除了满足以上的业务功能需求以外系统还具备如下特点：（1）、涉及业务种类繁多，如客户用水工程、抄表计量、费用的计算与收取、票据打印与管理、银行实时扣款及网上业务受理等；（2）、业务处理的分布式，要求系统易于布署、升级与维护，这主要是由各部门地理位置分散所致，如各营业所、水厂分布于全市范围内不同镇区；（3）、业务处理的多种形式，有些需要采用C/S结构完成，而另外一些则须采用B/S结构，如网上业
21
务受理、相关法规的发布等；（4）、开发成本上的限制，特别是对于开发人员已有知识经验的利用。
工欲善其事，必先利其器。随着软件技术的发展，开发平台也朝着开放性、分布性和与平台的无关性方向发展，相继出现了COM、CORBA等技术，但因其开发上的复杂性、布署上难于通过防火墙等，从而限制了其继续发展与更广泛的应用。为了进一步适应Web应用及多层体系结构软件的开发，又出现了以Java J2EE和微软的.NET为主的两种相互竞争的开发平台。
对于水务系统的开发到底选择哪种平台，在开发人员之间曾展开的激烈的争论。面向对象技术使Java语言迅速发展与成熟起来，特别是J2EE具有的平台无关性，一次编译多处运行以及EJB、JSP、Java Servlet等技术的发展，使其成为企业级应用开发的首选平台。而我司原有系统及相关应用都架设在微软的Windows系列家族产品上，并且技术部的开发人员在其上积累了大量的开发与实施经验，.NET平台支持多种程序语言，如C++.NET、VB.NET、C#及ASP.NET等，实现了语言的互操作性，而且易开发性都强过Java J2EE平台，使得开发人员的知识得到延续与发展。
随着需求分析的深入及软件体系结构的日渐清晰，我决定最终选择微软的.NET作为新系统的开发平台，开发工具则使用Visual Studio.NET，其原因主要居于开发平台以下几方面的考虑。
首先，开发平台的使用要有利于保持系统的开放性。水务系统要求在内部网络、远程网络及Internet环境中使用，单纯使用C/S或B/S结构都无法满足要求。在设计时我们使用了混合的C/S、B/S多层体系结构，如对于抄表计量、水费计算与收取、表务管理及管网管理子系统采用C/S结构，而对于客户服务、网上报装、用水法规的发布等则采用B/S结构实现。.NET就是应对如上复杂应用而出现的，对于桌面应用可使用C#或VB.NET进行Winform快速开发，对Web应用则可使用ASP.NET开发，两者都可以使用统一的ADO.NET存取引擎进行数据库操作，.NET的使用保证了水务系统的开放性。
其次，开发平台的使用要有利于保持系统的兼容性与先进性。我司原有的应用都是基于微软Windows家族产品，而.NET已经与Windows 2003集成在一起，相应使用SQL 2000作为数据库管理系统，使得.NET开发的应用具有更好的兼容性、可用性。同时.NET对Web Service进行了很好的支持，使得在其下对Web服务的开放变得异常容易，对数据库的存取则提出了比ADO更高级的ADO.NET引擎，使得系统的兼容性与先进性都有较好的保证。而且在.NET下提供了语言的互操作性，开发人员可以选用自己熟悉的VB.NET或C#进行开发，其开发效率、兼容性与可用性得到很好的保证，这也是Java J2EE平台无法比拟的。
在选择了.NET作为水务综合管理系统的软件开发平台后，为保持系统的开放性、先进性我们主要做了如下工作：
构建多层应用体系结构以适应系统在布署、维护及性能方面的要求。在设计时我将系统体系结构主要分为三个层次：（1）、表示层完成与用户的交互及数据的展现功能，我们利用.NET设计了抽象的表示框架，使得开发人员可以迅速的创建基于Web或SmartClient的客户端应用；（2）、业务逻辑层负责业务规则的封装，如对于抄表计量的处理各分公司略有不同我们则只需要在业务逻辑层进行处理，简化了系统的设计难度与维护工作量；（3）、数据层采用SQL Server 2000数据库，使系统之间的兼容性与性能都有较好的保障。
设计模式的使用为系统的可扩展性奠定了良好的基础。系统设计时以多层体系结构为基础上我注意了对设计模式的应用，使用MVC模式隔离数据表示与控制的关系，如果通过表格窗口、图表窗口为客户历月用水提供了丰富的展现形式又不影响后台的数据处理。在相关业务的处理操作中则大量使用了命令（Command）模式，使得相关业务操作可以串行化提高了系统的自动化程度。同时还综合运用了工厂方法、职责链以及单件模式，设计模式的应用使系统的结构更为清晰也更容易扩展。
使用Web服务及XML的数据交换格式为与异构系统交互提供了方便。在系统的开发过程中我适当的采用了Web服务及XML为系统与其它系统进行数据交换提供了方便，如对客户水费实
22
时扣款处理与银行大机（Unix）进行交互时，我们通过创建Web服务的方式为其调用提供简单的接口，采用XML格式是由于各家银行的扣款格式并不统一，为此只需要针对不同的银行创建一个XSL就能顺利实现不同格式的转换，大大的简化了系统设计的难度。
通过如上设计保证了系统的开放性、分布性及可扩展性，新系统于2004年底顺利上线并取得了较好的效果，得到公司领导及同事的认可。当前，开发平台已随软件技术向Web应用、开放性、分布性及平台无关性的方向发展，并出现了以微软的.NET及Sun的Java J2EE为代表的相互竞争开发平台。技术的发展日新月异，要求系统分析人员不断的学习新的技术更新自己的知识结构，了解和掌握相关技术的适应领域，才能在具体的项目实施中选择合适的软件开发平台。正所谓路漫漫兮 其修远兮 吾将上下而求索！
论基于构件的软件开发
摘要：
本文结合我于2004年在某市级自来水公司开发的水务综合管理系统，介绍了在项目中采用基于构件技术开发的经历与心得。在系统的开发中我结合项目的实际情况，将其分成三个阶段来完成。（1）构件体系结构与接口的设计，为系统的完成打下的基础；（2）基于领域工程的应用构件的开发，重点介绍了构件的提取、适应性修改及新构件的开发过程；（3）运用开发完成的领域构件组装软件系统，这也是系统开发的最终目的。通过采用构件技术为系统的开发积累了大量的可复用资产，为组装式的软件开发提供了现实的基础，在本文的最后一部分也对系统中存在的不足之处进行了简要的总结。
正文：
本人所在的某市级自来水公司经过多年的信息化建设，已经形成了数个应用系统如客户报装业扩系统、营业收费系统、抄表计量系统、人事管理系统及生产调度系统等。由于各系统都是以部门或各分公司为主导建设的，因当时技术条件所限及业务需求的“局部性”等原因，虽然系统从一定程序上解决了业务自动化与效率的问题，但并没有解决各部门与人员之间的协作问题，也不能很好的共享信息，已经成为公司发展的一种桎梏。
针对以上问题，公司领导经过深入的调研分析后，决定于2004年由公司技术部自主开发一套能够较好的解决上述问题的水务综合管理系统。我作为技术部的负责人及主要技术骨干，主持并参与了系统的方案选型、需求分析、设计与开发过程。水务综合管理系统涉及公司从生产到客户服务的几乎所有业务，主要包括客户用水报装工程、抄表计量、费用计算与收取、欠费催收、用水报障、生产调度及客户服务等子系统。
水务综合管理系统不仅需要满足总公司的日常业务需求，而且还要布署到市属所有镇区的自来水分公司。由于各分公司的日常业务流程并不一样，如同样对于客户水费的计算有的是直接由前后两期水表行度相减得到，而有的则要加调表底用水再加公摊水量得到。其它的业务处理也大同小异，如何在有限的资源条件及项目周期内，开发完成适合各企业的水务管理系统成为系统设计的首要目标，做到系统的灵活性与适用性的最佳平衡。
为此，我们需要一种能够利用已经开发过的系统组件搭建新的软件系统的技术，开发其中不存在的业务组件，而不是从头开发，以达到积累和固化开发人员知识财富的作用。在经过对多种开发技术的分析比较后，我决定在系统的开发中引入基于构件的软件开发技术，但因技术部相关开发人员对其不熟，同时，技术部人手也不多（总共7人，除去日常系统维护的可实际投入开发的就4～5人）。为了增强开发人员的信心，我将系统的开发任务分成三个阶段。
首先，通过定义完善的系统体系结构为领域工程中的应用构件开发提供支持。目前支持构件体系结构开发较成熟的模型有CORBA、COM/DCOM及J2EE三大技术体系。它们各有长处如J2EE提供了平台无关性，一次开发多处运行等特点，使其已成为企业级应用的首选平台。而COM/DCOM则是微软提供的在Windows下分布式组件模型，具有开发、布署容易，支持多种程序语言等优点。另外，我司的原有业务都是基于Windows的，经过反复考虑，我们决定采用COM/DCOM体系
23
结构，使新开发的系统具有良好的兼容性与可扩展性。我们还将系统划分成各个独立的层，各层构件独立工作又相互协调的完成系统的功能。有利于系统的维护与升级，而且可以并行的开发这些组件，互不影响。
系统的体系结构如下图所示：
稳定的接口定义为基于构件的开发提供了保障。在基于构件的软件开发中，由于系统是依靠预制的或独立运行的组件协同工作来完成系统的功能。各构件对信息的交换就成为必然。而要完成此工作则必须定义一组能用的信息交换接口。在我们的系统中采用一组服务来完成，上层或需用方通过以XML定义的服务接口向提供者请求服务，系统中的各构件也是利用XML定义的接口发布和请求服务的。这保证了各构件间的相互协作，也为第三方的开发提供了可能。 其次，与构件基础结构对应的是创建可复用资产和可复用的领域构件。可复用构件是领域内通用性较好的对象，在领域构件的开发过程中我们主要采取了以下步骤：
通过对以前的可复用资产进行整理为领域构件的开发打下基础。将原来开发的系统的设计结构、数据流图、业务逻辑规则及所有的文档资料都做一次全面的梳理。将存在的源代码与文档进行统一的标识管理，以便在进行构件开发时可以直接引用相关的数据结构或算法。在上述工作的基础上，对原来系统中一些好的业务流程、效率高、质量好的组件分别从源代码或流程中提取出来，并放入构件库内，详细记录其使用的环境、开发语言、接口定义等资料，为下一步的复用做好准备。
对登记入库的“原始”组件进行适应性修改以满足构件体系结构的要求。在修改的过程中，我们主要从系统的功能出发，在构件库查找到最接近要求的组件，然后按照接口定义进行修改。如对于抄表计量业务构件的开发就是在原来算法的基础上，根据各分公司的计算特点，抽取各家的共性生成一个抽象的处理构件，再对其中特殊的地方（有些存在表底数、公摊、水损等）进行子类化或参数化处理。这样就形成了满足要求的合格组件。
对于没法通过适应性修改得到的构件，我们就根据业务需求全新开发它。在开发时注意了构件的应用环境与不同分公司在业务上的差异性，以使开发出来的应用构件具有较高的复用价值。如对于用户用水工程的业务流程，有的分公司的处理为：申报→安装→交费→开通用水；而有的分公司则为：申报→勘查→工程预算→审批→交费→施工→验收→结算→开通用水。各分公司并不统一，为此我们并不是分别开发，而是根据业务最复杂的流程开发，完成后再根据各分公司的实际情况进行裁剪以满足各自的要求。这样既使开发工作量减到最小，在业务需求与系统开发之间取得较好的平衡，保证了系统各阶段的工作产品按时上线运行，其它的构件如语音查询、实时扣款构件等也如此开发完成。
最后，通过XML定义的接口将各层构件连接到一起形成满足业务要求的软件。从上图中可见系统是通过各层构件相互配合完成任务的，在层与层或构件与构件之间是通过其接口描述文件来进行连接的，并由系统核心的基础件将各构件最终加载到系统中。构件组装人员可以根据业务的需要从构件库中选取合格的构件进行装配以形成可用的应用软件。一方面可以很好的满足业务需求的变化，另一方面也为类似软件的开发积累了大量可复用的资产。
本系统于2005年初投入使用，由于采用构件技术大大缩短了开发的时间，同时也达到了系统的设计目标，培养了开发人员的可复用意识，也使自己的软件分析与设计水平得到了提高。另外，因系统采用的是自定义的软件构件接口，难于与第三方软件交互，这也是系统中存在的不足之处，为此我们打算在第二阶段以Web Services来对系统进行改造，以加强系统的开放性与可集成性。当前IT技术发展日新月异，如面向服务架构（SOA）、面向方面开发（AOP）及中间件技术的发展都为基于构件的开发提供了新的方向，也将使得我的软件分析与设计工作进入到更宽广的领域。
24
论软件的性能优化设计
摘要：
本文结合我2004年在某市级自来水公司实施的水务综合管理系统的经历，就软件的性能优化设计进行了详细讨论。在系统的设计中针对企业的实际应用环境主要从以下几方面对系统性能进行了优化设计：（1）、选择当前成熟的三层C/S体系结构进行开发，以减轻数据库服务器的负担；（2）、优化数据存取策略以降低系统运行对网络带宽的要求；（3）、对客户端应用进行优化，如减少数据请求量、相关的处理利用多线程进行以提高系统的响应速度。通过以上优化设计，系统满足了企业百万级以上主题数据库处理要求，得到了企业领导与同事的认可与赞许。最后对系统中存在的不足进行了简要的总结，如系统应用服务器端的负载平衡算法过于简单等。
正文：
本人所在的某市级自来水公司经过多年的信息化建设，已经形成了数个应用系统如客户用水工程系统、用水抄表计量系统、营业收费管理系统、欠费催收系统、生产调度系统及客户服务系统等。由于原来的系统都是由各部门或分公司为主导建设的，因业务需求的“局部性”导致系统之间很难共享信息，已经不再适应公司业务发展的需要。为此，公司领导经过研究决定于2004年利用自身技术力量重新开发设计一套水务综合管理系统，我作为技术部的负责人及主要技术骨干，主持并参与了系统的方案选型、系统分析、设计及部分开发工作。
新的水务综合管理系统涉及到客户用水工程、抄表计量、营业收费、欠费催收、用水报障、生产调度、客户服务及网上业务授理等业务，除了满足以上的业务功能需求以外，还要应对如下性能方面的需求。（1）、公司的大部分业务工作都由分散全市各镇区的分公司和营业所完成，相应要求系统适合于分布式的应用环境并提供较好的性能；（2）、对于远程客户端应用来说，必须在较小的网络带宽占用下完成日常业务处理，如分公司都使用512KB的ADSL与总公司连接，但一般的业务处理要求在10秒以内完成；（3）、对于大型的业务如抄表数据的上传、水费的批量计算，报表统计与生成工作等，要求不能影响其它业务的正常进行。
根据公司的业务和管理特点及上述提出的对软件性能方面的要求。在对软件的性能优化设计中我和系统分析人员主要做了以下几方面的工作。（1）、选择当前成熟的三层C/S体系结构进行开发，以减轻数据库服务器的负担；（2）、优化数据存取策略以降低系统运行对网络带宽的要求；（3）、对客户端应用进行优化，如减少数据请求量、相关的处理利用多线程进行以提高系统的响应速度。
工欲善其事，必先利其器。在本系统的开发中我们选择了目前在数据库开发方面非常成熟的Borland公司的Delphi开发工具、负载平衡使用的是其附带的ConnectionBroker、应用服务器连接则采用其MIDAS（DataSnap）技术。由于整个技术方案都使用的是Borland公司的技术，系统具有良好的兼容性与可扩展性的同时，也为系统的性能改善提供了可能。下面将就我在系统性能优化方面所做工作进行详细介绍。
首先，在水务综合管理系统中我们根据企业业务处理分散在异地的特点，采用了三层C/S体系结构，系统的体系结构如下图所示：
通过三层C/S体系结构的设计可以将数据库的访问及业务处理逻辑移到应用服务器进行。由于我司应用特点，我们在应用服务器的设计中主要采取了连接池和负载均衡的技术来提高系统性能。（1）、对于客户的连接我们首先去查找连接池中是否有可用的连接，如果没有才则建立之，否则直接利用连接池中的连接来处理客户端的请求，这样做可以有效降低系统因建立与数据库的连接而带来的性能影响，同时也可以较好的节约系统资源。（2）、针对系统主题数据库容量上百万及日常业务处理繁重的情况，在应用服务器端我们利用Borland公司的VisiBroker组件为系统提供了负载均衡的能力，如在业务处理高峰期系统将会自动通过VisiBroker Agent将
25
系统分析师论文案例集PDF
