(完整版)基于某大型实时交易系统的开发过程毕业论文

学士学位论文

基于某大型实时交易系统的开发

过程

作者：吴晶

学号：005598

指导教师：杜庆峰

同济大学软件学院软件工程专业

二零零四年六月

摘要

当前，计算机软件的趋势正朝着庞大且复杂的方向发展。这是因为计算机处理能力的增大，导致用户对它的期望更多。我们满足客户需求的同时，需求本身也变得越来越复杂，从而，开发出来的软件也。总之我们希望软件运行的越来越快捷。

大型软件的开发需要一种受控的工作方式，它需要一个过程来集成软件开发的许多方面。本文以一个大型实时交易系统软件为例子，阐述大型实时交易软件的开发过程，以及在过程的每个阶段都应注意的问题，并简要评述了特定的过程在软件项目开发中的优势及不足之处。

【关键词】实时系统, 开发过程, 分析,设计

Abstract

Now, software is becoming more and more complicated and large, it is partly because

the ability of the computer process becoming large and it cause the customer it.The time when we need the software which meets our requirements better,we also make the software become

complicated. All in all,we example of a lager software development

to show the development process of the large real time software and the attention should be paid in every step.The paper will also point out the good and the bad aspects of the process. 【Keywords】Iteration, software engineering, software requirement ,development processes, Core Workflows

一、引言

当前，软件的趋势是朝着更大更复杂的系统发展。这部分地是因为计算机的处理能力每年都在增大，导致用户对它的期望更多。同时，这种趋势也受到为交流各种信息（从纯文本到格式化文本到图像到图表再到多媒体）而不断扩大互联网的使用的影响。在产品版本的不断升级过程中，我们了解到产品是如何被改进的，因此我们对越来越复杂的软件的胃口也就越来越大。我们需要更符合我们的需要的软件，但是，这种需要反过来又使得软件越来越复杂。总之，我们需要更多。我们希望软件运行得越来越快捷。推向市场的时间是另一个重要的推动因素。然而，要达到这个目的是困难的。我们对强大、复杂软件的需要与软件开发的当前状况并不一致。今天，大多数人还在使用25 年前使用的旧方法来开发软件。这就是症结所在。除非我们革新我们的方法，否则，我们无法达到开发当前所需的复杂软件的目标。我们可以把这个软件问题归结为软件开发人员面临的将一个大型软件项目的众多线索综合在一起的困难。大型软件的开发需要一种受控的工作方式。它需要一个过程来集成软件开发的许多方面。它需要一种通用方

法，该方法能：

（1）提供应如何对整个开发团队的开发活动进行组织的指导。

（2）综合指导单个开发人员和开发团队。

（3）规定开发成果是什么。

（4）提供监控和衡量一个项目中的产品和活动的标准。

本文主要以中国外汇交易中心本币交易系统为例子来讨论一种大型实时交易软件的开发过程。

一项目及软件开发过程模型

1.1项目简介

中国外汇交易中心是全国银行间外汇市场、人民币同业拆借和债券交易市场的组织者，为包括国有独资商业银行、股份制商业银行、外资银行、保险公司、证券公司、基金公司、财务公司等各类金融机构提供交易、清算交割和信息等方面的服务。

在交易中心目前运行的本币交易系统采用了BS结构，是一个建立在广域网上、采用总中心－分中心－交易成员三层结构的分布式应用系统。总中心、分中心主机均采用PC SERVER，总中心和分中心瑞安装SCO UNIX操作系统、SYBASE数据库管理系统，分中心WEB服务器安装了PowerDynamo2.0。使用JavaScript、ASP和Dynamo Script开发交易系统的Web端应用程序，用PowerBuilder开发场务管理子系统，使用C语言和SYBASE OPEN CLIENT开发后台进程监控系统等应用程序。

目前运行的系统涉及的业务主要包括金融机构间的资金信用拆借、债券的二级市场交易与回购业务、隔夜拆借交易系统、债券市场一级市场发行的分销报价系统等。系统为参与本币市场交易的用户提供风险管理、行情信息等各种支持及清算、统计等辅助功能，以保证其日常交易的顺利进行。同时，保证市场管理部门对市场交易的日常管理及实时监控，保证中央银行对本币交易市场的交易状况及交易成员交易行为的了解和监督。

现行系统由于操作平台相对落后及系统结构方面的缺陷，存在不能满足业务处理变化的要求、系统稳定性不够、交易便捷性不够、系统响应慢等问题，目前已不适应业务发展的需要。系统

的另外一些不足，包括灵活性不够、缺乏技术分析工具、与其他交易系统、信息系统整合不足等。为了满足市场需要、提高系统性能、适应整个交易中心信息化建设的需要，交易中心提出建设中国外汇交易中心新版本币交易系统。

1．2 开发过程模型介绍

1．3 SCM工具的选择及在过程控制中的使用

3.6.1 配置管理工具的选择

在大型交易软件的开发过程中，配臵和变更管理也是非常重要的，因为配臵和变更管理提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。配臵和变更管理描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

在本币交易系统的开发过程中，根据项目的实际情况，项目组选择了CVS作为版本控制软件。项目组用一个文件服务器作为CVS的代码仓库，然后每个开发机器上都安装客户端软件，在开发的时候从服务器下载源代码或者提交完成的文件。项目组选择CVS主要使基于以下几点考虑的：

(1)免费

作为开放源代码世界的杰作，CVS使免费的。而且世界上有很多杰出的程序员都在维护这个软件，从而使软件更趋稳定和强大。

(2)出色的并行开发支持

CVS能够支持客户进行并行开发，它实现的版本分支功能能够嘎实现软件开发者梦寐以求的许多功能－－多小组并行开发不

同的模块而不相互干扰，隔离危险或者冒险代码，在任意版本上打补丁，可灵活定制多种版本的演示模型等等。由于，本币系统模块较多，而且是多个项目小组并行开发，所以CVS的这些强大的功能能够让项目组开发人员大大提高效率，因此它很适合作为本币系统开发的版本控制软件。

当然，在软件开发的时候，还有很多的版本控制软件可以供开发人员选择，比如Rational ClearCase和Microsoft Source safe 等等。

（1）Rational Clearcase

和CVS相比较，Clearcase是一款真正的商业化软件产品，功能更加强大、全面和完善。它适合管理大型、特大型的软件项目开发。但是它的缺点也很明显，首先是价格昂贵，一般公司很难承受。其实它对服务器性能、网络带宽都有很高的要求，这意味着更高的投资。此外，由于clearcase功能比较复杂，因此，开发人员将会耗费很大的精力才能熟练的使用它的功能。

（2）Microsoft Source Safe

它是微软公司为Visual Studio配套开发的一个版本管理系统，它自动集成在Visual Stdio 中，具有图形用户界面，管理和使用都比较简单。但是Source Safe 不具备跨平台的能力，不支持版本的分支和合并，不支持并行开发，在一个时间只能有一个人修改某个源文件。因此Source Safe 只适合于开发团队在10个人以下的小项目开发。

经过上面的分析可以看出，用CVS作为大型实时交易软件的版本控制软件还是很合适的。它的功能完全符合项目需要，使用方便，而且是免费的软件。

3.6.2 配置管理计划的制定

在选择了一个适合项目开发的配臵管理工具以后，拟订配臵管理计划也是非常重要的。笔者将以本币交易系统为例子，说明配臵管理计划的制定。

（1）配臵标识

配臵项标识是配臵管理的基础性工作，是管理配臵的前提。配臵项命名是配臵标识的重要工作，所谓标识，其实质就是区分，在众多的配臵项中合理、科学地命名是最为有效的区分方法。除为配臵项命名外，必要时应提供某些相关信息，比如：配臵项组名及其存放位臵，子目录名等；版本信息；作者、修改者、审核者信息。常见的配臵项是文档，代码。工具以及第三方的产品。本币交易系统中的文档主要有：需求分析说明书，详细设计说明书，主机模块设计说明书，界面设计说明书等等。对于工具的配臵项，要标识出中英文名称，版本号，提供商和序列号。

（2）配臵基线

基线是已经通过正式复审核和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变化控制过程的改变。在本币交易系统的实施过程中将建立以下基线：1．需求规约

2．概要设计规约

3．详细设计规约

4．编码实现

5．测试

6．用户认可测试

在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要修改前面有关阶段的阶段产品时，就必须通过项目的配臵管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配臵管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配臵管理小组研究同意，然后报配臵管理委员会批准。

（3）版本控制

这里所说的版本，不是指单个配臵项的版本属性，而是指配臵项形成的集合，可以是某个模块、子系统或整个软件系统。版本控制要解决的第一个问题便是版本标识，也就是为区分不同的版本，要给它们科学的命名。本项目以号码版本标识法为主，符号版本标识法作为辅助手段，例如版本：V2.0.0(INTEGRATION_TEST)。版本号包括主版本号、副版本号、发布号，格式。

（4）发行管理

版本发行解决了如何把产品配臵成可以使用的方法。由于本项目需要涉及总中心及各分中心的切换，以及需要与各家银行联网调试，因此，对于发行到外部使用的软件要进行控制，用SER流程进行控制，keyword为SCM_DELIVERY，表单包含的主要信息如下：产品名称、版本信息、交付使用者、使用场所、交付方式、交付内容。

软件配臵计划的制定有助于保证所交付的软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体设计组制定的软件系统需求规格说明书中规定的各项具体需求。因此，在软件开发的过程中，应该严格按照配臵计划制定的内容去实施。

二商业建模和需求分析

3.2.2系统特性需求

作为一个大型实时的交易系统，客户对系统提出了非常高的需求，经过总结他们的需求主要集中在以下三点：

（1）实时性：

交易系统是业务处理十分频繁、数据交换吞吐量很大的系统，业务处理的速度直接关系到公司的经济效益和客户对公司的评价。在客观条件下，整个广域网系统必须在大业务量的情况下同时保持快速的实时响应能力，以保证整个业务系统的通畅运行。（2）安全性：

安全性问题主要体现在交易成员资金和交易的安全性以及营业部内部网络的安全性，但随着公司一级的广域网系统的建立，特别是在本币交易系统中，系统的安全就显得更为重要，各个方面充分考虑整个系统的安全性。另外，对系统中所有的重要操作必须绝对留痕，以规范管理。

（3）可靠性和健壮性：

客户要求在系统交易的过程中要连续无故障，因为一旦交易中断，都会给交易成员带来损失。系统对用户的操作顺序、输入的数据进行正确性检查，并以显著方式提示错误信息。必须使用系统出错处理机制，当应用软件系统运行过程中发生错误时，系

统将明确提示错误信息并指导用户进行处理。提供系统的运行监视和故障恢复机制，生成系统运行的日志信息，跟踪系统的所有操作，便于即时发现并排除故障。

通过对系统特性需求的获取，可以看出，每一个大型实时系统都有它共有的要求，例如，对实时的要求，对可靠性和健壮性的要求。但由于本币交易系统的特殊性，客户对系统的安全性也提出了很高的要求。从这点可以看出，在取得系统的需求的时候，不仅仅要把握那些共有的需求，更重要的是挖掘那些隐含的需求，这些需求往往可能

被需求分析人员或者是客户所忽略，但却是非常重要的。

3.3.3系统划分和接口需求

依据交易中心本币交易系统方案书中的设计目标、设计原则和系统性能要求目标，并根据用户使用的要求和特点，中国外汇交易中心新版本币交易系统包括三大子系统：中国外汇交易中心新版本币交易子系统，中国外汇交易中心新版本币中介子系统，中国外汇交易中心新版本币场务管理子系统。（见图2）

图2：本币系统的划分图

其中本币交易子系统是本币交易系统项目的核心，主要支持银行间信用拆借、债券回购、债券买卖和债券分销市场业务。新版本币交易系统中介子系统作为交易系统的一部分，为中介的报价、交易和手工录入提供完善服务。新版本币场务管理子系统为系统管理员和场务管理员提供方便灵活的管理接口，完成交易系统的交易控制、数据维护、场务管理和信息查询提供支持，并提供应急交易的功能。

本系统作为交易中心本币系统的核心系统，是其他系统建设的基础和数据源，在本系统的建设中主要考虑的外界接口主要有：中国外汇交易中心本币信息系统接口、中国外汇中心F－风险管理系统接口、债券结算接口、交易成员本方数据存储接口，（详见：图三）：

图3：本币系统的接口图

作为一个大型的实时交易软件，系统分割成几个独立的子系统这种架构模式是很有用的。这样既方便软件的开发，又方便软件的维护的工作。因此在进行需求分析的时候，一定要注意把相同的功能模块集成到一个子系统中去。同时，由于软件不是孤立存在的，因此，一定要考虑系统和系统之间的接口问题。不光光要考虑对现有系统的接口，还要考虑对以后扩展系统的接口。否则，对以后软件的使用和扩展将造成很大的麻烦。

3.3.4系统构架需求

新版本币交易系统的框架是一个具有多层构架的客户服务器应用结构。采用中间件技术构建多层客户服务器应用结构已经成为应用开发和运行的主流技术，其核心概念是利用中间件将应用的表示逻辑（客户界面）、业务逻辑（服务组件）和数据管理（数据库）分为三个不同的处理层：

1、表示层提供协议控制和用户界面，与系统最终用户实现直接交互。负责接收用户的服务请求，通过socket连接向交易前臵服务发送。

2、商业逻辑层作为中间层实现核心业务逻辑服务，这些组件由中间件管理，接受客户的服务请求，向交易主机提交数据操作，

并将交易主机的业务处理结果返回给请求者。

3、数据层负责整个系统中数据信息的存储、访问及其优化。

通过使用中间层，实现了业务逻辑与表示逻辑、业务逻辑与数据管理的分离，使得系统能够灵活的适应用户业务逻辑的变化。(详见：图4)

图4：系统业务架构图之所以采用这种构架主要是因为考虑到软件的使用者分布在全国各地，这样采用web界面的访问方式可以使软件实现零安装。而且采用这种MVC的模式，使的业务逻辑层、表示层和数据管理层分开。这样有助于软件的开发和维护。由于软件的系统架构就象人的骨架一样，是整个软件的脊椎骨，所以在考虑系统架构的时候一定要从用户的业务需求出发，确保软件的系统架构合理。

3.3.5软件功能需求

笔者将以本币交易系统中中介交易子系统为例子来说明定义功能需求的目的以及怎样定义软件的功能需求。

本币交易系统的中介子系统的相关功能包括：

中介成交处理：

（1）录入成交单：参与交易的双方成员经过与中介联系后达成交易，交易双方交易员通过电话传真传送成交单

给中介，中介交易员把交易成交单录入系统。

（2）修改成交单：修改当日中介成交单。

（3）撤消成交单：撤消当日中介成交单。

中介交易处理：

（1）发送公开报价：向市场全体成员转发已收到的成员匿

名报价或手工录入的报价，代理委托成员完成指定交

易。

（2）发送对话报价：向特定的市场成员表达本方的具体的交易意向，通过选择委托方发送给中介的匿名报价并

发送给所选择特定成员交易员，此报价对委托方具有

约束力。

（3）询价交谈：为达成一致的交易意向，与交易对手就报价中交易各要素进行磋商。同新版交易子系统询价交

谈。

（4）确认成交：对报价指定交易进行确认，经过交易双方通过报价交谈，对于各交易要素达成一致后，交易双

方都有权确认。同新版交易子系统。

（5）修改报价：为了达到更准确和及时的表达自己的交易意向，修改本方已经发送但没有确认成交或应答的报

价中一些交易要素。

（6）撤消报价：取消交易意向，对本方已经发送但没有确认成交或者部分没有成交的报单进行撤销。

其它：

（1）登录：中介交易员进入中介交易系统，代理委托成员进行报价、询价、确认成交以及录入成交单等。

（2）查询统计：可按开始结束日期、委托方、交易方向、债券代码、等组合查询，并小计出笔数和交易量。详见：图5

图5：中介子系统功能需求

通过上述例子可以看出，在需求分析阶段，功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。开发人员和用户需要对软件实现的功能达成一致。要对需要的功能和约束进行提取、组织、文档化。正确的划分功能需求非常重要，这就需要需求人员能够正确把握用户的需求，了解行业背景，挖掘隐含需求。

3.3.6需求用例和建模

所谓的用例就是软件的使用者和系统的交互。一个用例就是系统中向用户提供一个有价值的结果的某项功能。用例捕捉的是功能性需求。所有用例结合起来就构成了“用例模型”，该模型描述系统的全部功能。用例迫使我们从用户的利益角度出发进行考

虑，而不仅仅是考虑系统应当具有哪些良好功能。用例不仅仅是定义系统的需求的一个非常好的工具，它还可以驱动系统的设计、实现和测试。亦即整个开发过程。在需求阶段我们一般完成用例的定义，在以后的阶段中还会有用例的设计等等。下面笔者将以交易子系统中信用拆借公开报价用例来说明用例的定义。

用例名称：信用拆借公开报价

系统范围：交易系统

上下文目标：交易员提供本方的初步交易意向，填写本方公开报价单，并且通过交易系统发布在交易系统的公开报价栏中，让所有的其他交易员能够看到。

前臵条件：交易员已经通过身份认证，并具有信用拆借业务权限

主要角色：信用拆借交易员

成功场景：

交易员发出“信用拆借公开报价”交易指令；

系统切换到“信用拆借公开报价”窗口；

交易员填写信用拆借公开报价要素，并提交；

系统校验信用拆借公开报价，并广播信用拆借公开报价；

在线交易机显示信用拆借公开报价。

扩展：

3a.公开报价要素不合法

3a.1、拆借方向未填写，提示交易员：“请填写拆借方向”，返回到3；

3a.2、公开报价要素数据格式不对，返回失败信息：“XX数据格式不对”，返回到3。

4a.数据不合法

4a.1、包格式不对，提示交易员：“公开报价失败”，用例失败。

备注：

业务规则：

1.1、“利率”和“金额”允许报空值（可不填写具体数值），只表示资金进出方向；

1.2、系统自动生成每笔报价编号，在系统状态栏中显示报价发送状态。

一个完整的用例需要包括以下内容：

（1）名称：

每个用例都必须有一个区别于其他用例的名称。

（2）用例参与者

一个参与者表示用例的使用者在与这些用例进行交互时所扮演的角色的一个紧密的集合。通常一个参与者代表的角色有：人，硬件设备，或甚至是另外一个系统。

（3）用例和事件流

用例描述的是一个系统做什么，这可以通过一个足够清晰的、外部人员很容易理解的文字描述一个事件流，来说明一个用例的行为。书写这个事件流的时候，应该包含用例何时开始，何时结束，用例合适和参与者交互，什么时候对象被交换，以及行为的基本流和可选择流。

3.3.7小结

通过对本币交易系统的需求分析为例子的分析，可以看出最

重要的是客户和系统开发人员在系统的工作内容方面达成一致，系统开发人员能够清晰的了解系统的需求，定义系统的边界。最后要生成一个用例模型，其中主角代表与系统通信的外部单元，用例代表事务序列，为主角提供可测量的结果值。

三系统设计与实现

本币系统的设计主要是为了说明系统总体设计的技术方案和模块的详细设计，涉及到系统设计的主要方面，如系统架构、模块划分、功能分配、接口设计、运行设计、数据库设计和出错处理设计等内容，以向整个开发期提供关于子系统关系的总体描述，从而作为程序详细设计或编码的框架性基础。

3.3.1总体结构设计

在本文中笔者将以交易子系统的交易处理模块为例子来阐述总体结构设计。交易处理模块采用四层架构，在业务处理中采用交易中间件，分为数据表示层、通信层、业务处理层和数据层；整个结构基于消息的驱动。（UML图6）

UserInterface：用户的操作界面，其中分为会员交易前台界面，中介交易前台界面，场务管理前台界面。实现表现层（终端界面）所要求的功能。

NetWork：系统中客户端和服务器端的通讯采用标准的协议，该模块负责两者之间数据的传输工作，检查通讯故障。

DataProtocol：由于客户端和服务器端传输的数据都采用了标准的XML格式，该模块一方面对所有发送的数据按照XML的语法格式进行组织，另一方面对所有收到的数据进行解析；

FunctionCase：各子系统业务处理（场务子系统、中介子系统、交易子系统），实现终端业务层、交易业务层和主机业务层所要求的功能。（中间件服务器）

MessageDispatcher：该模块实现了前臵机和交易主机服务器端各模块之间交互消息的发送、接收以及分发功能，实现前臵机主机通讯协议层所要求的功能。（中间件客户端）

Logging：记录系统运行中的时序信息，包括正常、调试和错误信息，帮助诊断系统状况，测试模块功能，确定问题的位臵。可以根据配臵文件，确定输出的内容。

DataProcess：数据库的接入，实现主机数据库通讯协议层所要求的功能。

体系结构是软件系统中最本质的东西,体系结构是对复杂事物的一种抽象。良好的体系结构是普遍适用的，它可以高效地处理

多种多样的个体需求。一提起“房子”，我们的脑中马上就会出现房子的印象（而不是地洞的印象）。“房子”是人们对住宿或办公环境的一种抽象。不论是办公楼还是民房，同一类建筑物（甚至不同类的建筑物）之间都具有非常相似的体系结构和构造方式。如果13亿中国人民每个人都要用特别的方式构造奇异的房子，那么960万平方公里的土地将会变得千疮百孔，终日不得安宁。

体系结构在一定的时间内保持稳定。只有在稳定的环境下，人们才能干点事情，社会才能发展。科学告诉我们，宇宙间万物无时无刻不在运动、飞行。由于我们的生活环境在地球上保持相对稳定，以致于我们可以无忧无虑地吃饭和睡觉，压根就意识不到自己是活生生的导弹。软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件的体系结构。就如人们对住宿的需求也会变动，你可以经常改变房间的装璜和摆设，但不会在每次变动时都要去折墙、拆柱、挖地基。如果当需求发生变化时，程序员不得不去修改软件的体系结构，那么这个软件的系统设计是失败的。

良好的体系结构意味着普适、高效和稳定。

3.3.2功能模块的设计

本文中笔者将以撤销本方交易员模块的设计为例子来阐述交易系统中模块的设计。

（1）模块描述

由首席交易员撤销本方交易员。首席交易员在会员机上将CDlrDelReqMessage请求消息发给主机，主机Tuxedo服务进程接