軌件詳細設計說明

書例

案卷號00001

日期

軟件詳細設計說明書（例）

作者：

完成日期：

簽收人：

簽收日期：

修改情況記錄：

版本號修改批準人修改人安裝日期簽收人

目錄

1引言......................................錯誤!未定義書簽。

1.1編寫目的................................錯誤!未定義書簽。

1.2范圍....................................錯誤!未定義書簽。

1.4參考資料...............................錯誤!未定義書簽。

2總體設計..................................錯誤!未定義書簽。

2.1需求規定................................錯誤!未定義書簽。

2.2運行1環境...............................錯誤!未定義書簽。

2.3基本設計概念和處理流程.................錯誤味定義書簽。

2.4結構....................................錯誤!未定義書簽。

2.5功能需求與程序的關系....................錯誤!未定義書簽。

2.6人工處理過程...........................錯誤味定義書簽。

2.7尚未解決的問題.........................錯誤味定義書簽。

3接口設計..................................錯誤!未定義書簽。

3.1用戶接口................................錯誤!未定義書簽。

3.2外部接口...............................錯誤!未定義書簽。

3.3內部接口................................錯誤!未定義書簽。

4運行設計..................................錯誤!未定義書簽。

4.1運行模塊組合............................錯誤味定義書簽。

4.2運行控制J...............................................................錯誤!未定義書簽。

4.3運行時間................................錯誤!未定義書簽。

5系統數據結構設計.........................錯誤!未定義書簽。

5.1邏輯結構設計要點........................錯誤!未定義書簽。

5.2物理結構設計要點........................錯誤!未定義書簽。

5.3數據結構與程序的關系....................錯誤!未定義書簽。

6系統出錯處理設計.........................錯誤!未定義書簽。

6.1出錯信息................................錯誤味定義書簽。

6.2補救措施...............................錯誤味定義書簽。

6.3系統維護設計...........................錯誤!未定義書簽。

1引言

1.1編寫目的

隨著證券交易電子化程度的不斷提高，券商對于各種業務提出

了新的要求，為了滿足券商的發展需求，更好的為客戶提供服

務，現結合原有各版本的證券交易軟件的優點和特點，開發一套

采用Client/Server結構的證券交易軟件管理系統（SQL版）。本

系統從底層予以優化，使整個系統的運行速度得到較大提高，經

過重新優化數據庫內部結構，使系統的可擴充性得到極大提高。

本說明書給出SQL版證券交易系統的設計說明，包括最終實

現的軟件必須滿足的功能、性能、接口和用戶界面、附屬工具程

序的功能以及設計約束等。

目的在于：

?為編碼人員提供依據；

?為修改、維護提供條件；

■項目負責人將按計劃書的要求布置和控制開發工作全過程；

■項目質量保證組將按此計劃書做階段性和總結性的質量驗證

和確認。

本說明書的預期讀者包括：

?項目開發人員，特別是編碼人員;

?軟件維護人員；

■技術管理人員；

?執行軟件質量保證計劃的專門人員；

■參與本項目開發進程各階段驗證、確認以及負責為最后項目

驗收、鑒定提供相應報告的有關人員。

■合作各方有關部門的復雜人；項目負責人和全體參加人員。

1.2范圍

說明：

a.待開發的軟件系統的名稱：模擬股票交易系統

b,列出本項目的任務提出者、開發者、用戶以及將運行該項

軟件的單位。

1.3定義

列出本文件中用到的專門術語的定義和縮寫詞的原詞組。

本報告用到的術語符合國家標準《軟件工程術語(GB/TU475-

1995)》o

1.4參考資料

列出要用到的參考資料，如：

本項目的經核準的計劃任務書或合同、上級機關的批

文；

b.屬于本項目的其它已發表的文件；

C.本文件中各處引用的文件、資料，包括所要用到的軟

件開發標準。

列出這些文件的標題、文件編號、發表日期和出版單位，說明

能夠得到這些文件資料的來源。

2總體設計

2.1需求規定

說明對本系統的主要的輸入輸出項目、處理的功能性能要求,

詳細的說明可參見《需求分析說明書》。

2.2運行環境

簡要地說明對本系統的運行環境（包括硬件環境和支持環境）

的規定，詳細說明參見《需求分析說明書》。

?數據庫服務器

奔騰Pro

內存128MB以上

硬盤9GB

100M網卡

-應用服務器

奔騰Pro

內存64MB以上

硬盤4GB

100M網卡

■網絡配置

100M/10M

-工作站（柜臺）

P100以上

內存8MB以上

硬盤1G以上

100M/10M網卡

軟件

■操作系統

WindowsNT4.0以上

■數據庫管理系統

SQLServer

■相關軟件工具

WindowsNTWorkstationAVindowsNTserver

WindowsProfessional/Server

開發工具

-平臺：Windows95/98、WindowsNT>Windows

?開發工具：visualstidiosp1,C#.Net

測試環境

Windows31>Windows95/98、WindowsNT^Windows

2.3基本設計概念和處理流程

說明本系統的基本設計概念和處理流程，盡量使用圖表的形

式。

營業部系統一共有四個對象，即客戶、員工、市場和銀行，市

場的概念是交易所的細化，比如上海證券交易所的A股和B股就

是兩個市場，有了市場的概念我們就能夠把交易所這個概念細

化，并使同一個市場的共性更突出。銀行則經過銀證轉賬業務介

入，并成為營業部系統不可或缺的組成部分。

上述四個對象經過一些業務流程進行相互操作從而形成整個交

易活動。因此整個系統模型能夠表述為圖2-1

設計時需要將營業部系統所使用的各種信息分為描述四個對象

的信息和描述業務流程的信息。由于四個對象相對而言是一種穩

定型信息，而業務流程則較易變化，且營業部之間差異很大，因

此應將四個對象盡量定型，而將各種業務流程盡可能做成組件，

以便營業部可根據實際需求組裝成適合自己的系統。

客戶

市場

根據以上思想，在設計對象模型時應充分考慮到可擴展性，盡

量做到抽象化、參數化，從而使對象需求變化時不致影響系統結

構。

自動撮合系統

運

界

夕

?

圖2.1

2.4結構

用一覽表及框圖的形式說明本系統的系統元素（各層模塊、子

程序、公用程序等）的劃分，扼要說明每個系統元素的標識符和

功能，分層次地給出各元素之間的控制與被控制關系。

本系統采用c/s模式的3層結構

按照不同會話來劃分的話能夠分為3大系統模塊

和據鹿

阿CG右目左妙秣五任珈

客戶端登陸模塊:

p

至

2

c

±

u-

u0

w一

一

匚

匚

之

最關鍵的交易系統模塊結構圖如下:

buyStock;

sellStock

quoteStock

Cansel

Delegate

scrMoncyCount(stockData

checkUserStockCount

通過數據訪問層來訪問用戶表

在報門隊列中處理并旦返回處理結果

(radelnQueuc(stockData

newstockDtta)

Success

unSucccss

upDatcUsirlnfo

(stockData)upDateDelegate

通過調用ADOInfo(stockDat

層工廠來訪問a)

不同的數據庫同左更新的是

(更新用戶表委托臨時表RUJie

s/()d

M范

a賣

規

令

買

愉

指

數

傳

結

的

必

據

是

構

xk

須Ila

stc

Da

股票信息發布

經過修改我認為每次由客戶端每5秒去查詢一次服務器更新信

息不可取，因為這會加重服務端和客戶端的負擔，特別是服務器

端的運算。

修改后實現變更為：用戶一開始登陸后獲得一次服務器的全部

股票當前信息。而服務器端每次發生交易后，給每一個在線月戶

發送當前交易需要更新的股票信息，這樣就減輕了客戶機和服務

端的信息

Stockid

Stockprice

服務器每次交易返回最新信息

2.5功能需求與程序的關系

（該關系由需求分析報告編寫者根據結構圖說明）

本條用一張如下的矩陣圖說明各項功能需求的實現同各塊程序的

分配關系：

獲取并發送繪制分時MD5加密發送用戶接受并識別調用數據層服務器返回

撮合交易

用戶請求圖解密交易請求用戶請求查詢客戶端信息

用戶登陸JV

查看用戶,

持倉7

實時指.

數7V

交易委托JJJJJJJ

取消交易VVVV

2.6人工處理過程

說明在本軟件系統的工作過程中不得不包含的人工處理過程

（如果有的話）。

沒有完成股票管理的模塊設計，因此股票必須從數據庫后臺添

加

如果有新股發行，還必須添加有關股票的交易隊列

2.7尚未解決的問題

說明在概要設計過程中尚未解決而設計者認為在系統完成之前

必須解決的各個問題。

3接口設計

3.1用戶接口

說明將向用戶提供的命令和它們的語法結構，以及軟件的回答

信息O

向用戶提供簡單易用的UL以及幫助文檔。

客戶端將提供以下功能

首先彈出用戶登陸框，供用戶輸入用戶名和密碼

菜單項提供個股查詢和分時圖按鈕

菜單欄下是選項卡，提供股票實時信息和個股分時圖欄

提供用戶交易界面和交易按鈕以及查看用戶盈虧按

3.2外部接口

說明本系統同外界的所有接口的安排包括軟件與硬件之間的接

口、本系統與各支持軟件之間的接口關系。

采用基于正確公開標準的部件和技術以確保最大限度的協作能

力以及與第三方系統與部件集成的簡便性。這類標準包括但不限

于以下幾種；

-網絡協議與標準(TCP/IP,HTTP,SSL,etc)

■語言(SQL,C#.net,etc.)

?數據庫連接性(ADO。net)

3.3內部接口

說明本系統之內的各個系統元素之間的接口的安排。

邏輯層和數據訪問層經過以經的stockDataModel接口，來限定

訪問stockData類型的數據

客戶端經過調用buyStock（stockData）和sellStock

（stockData）來訪問邏輯層，在這個函數中包含了訪問邏輯層的

接口dealTransaction（stockData）

經過AdoFactory訪問不同的數據庫

客戶端登陸協議

D（二字節）+（客戶名字長度）（4字節）+（客戶名字）+（客戶密碼長

度）（4字節）+（客戶密碼）；

客戶買賣協議

B（二字節）+（股票ID）（4字節）+（股票數量X4字節）

S（二字節）+（股票ID）（4字節）+（股票數量）（4字節）

查詢交易信息并返回給客戶端

C（二字節）

具體有拆包解包的類

usingSystem;

usingSystem.Collections.Generic;

usingSystem.Text;

namespaceProjectCenterTradingSys

(

publicclassProtocal

(

privatebyte[]messagebuffer;

privatebyte[]messagelength;

publicbyteflmessagebag;

//該函數是將字符串轉換為字節數組

publicbyte[]StringtoByte(stringstringinfo)

(

messagebuffer二

System.Text.ASCIIEncoding.ASCILGetBytes(stringlnfo);

returnmessagebuffer;

〃該函數將整型轉換為個字節

publicbyte[]InttoByte(intnumber)

(

messagelength=BitConverter.GetBytes(number);

returnmessagelength;

〃將浮點型轉換為個字節

publicbyte[]DoubletoByte(doubleprice)

(

byte[lpricebyte=BitConverter.GetBytes(price);

returnpricebyte;

〃合并一個字符串(字節數組)和她的長度作為一個包

publicbyte[]Combinarray(byte[]messle,byte[]messinfo)

(

messagebag=newbytefmessle.Length+messinfo.Length];

intindex;

for(index=0;index<messle.Length;index++)

messagebag[index]二messagelength[index];

for(intindex1=0;index1<messinfo.Length;index1++)

messagebag[index+index1]=messagebuffer[index1];

returnmessagebag;

)

〃解包頭

publicbyte[]BagHead(charhead)

(

bytef]headbyte=BitConverter.GetBytes(head);

returnheadbyte;

//讀包頭

publiccharDeBagHead(byte[]buffer)

charheadinfo=BitConvcrtcr.ToChar(buffer,0);

returnheadinfo;

〃該函數為解包信息為字符串！

publicstringdeMessgeBag(byte[]Messagebag,intstart,outint

next)

(

next=BitConverter.ToInt32(Messagebag,start);

stringmessage=

System.Text.ASCIIEncoding.ASCII.GetString(Messagebag,start+4,

next);

returnmessage;

4運行設計

4.1運行模塊組合

說明對系統施加不同的外界運行控制時所引起的各種不同的運

行模塊組合，說明每種運行所歷經的內部模塊和支持軟件。

4.2運行控制

說明每一種外界的運行控制的方式方法和操作步驟。

4.3運行時間

說明每種運行模塊組合將占用各種資源的時間。

5系統數據結構設計

5.1邏輯結構設計要點

給出本系統內所使用的每個數據結構的名稱、標識符以及它們

之中每個數據項、記錄、文卷和系的標識、定義、長度及它們之

間的層次的或表格的相互關系。

客戶端類圖：

windowForm：Form

Private：

userLogDialog

userNametextBox

userPasswordtextBox

userlogOKbotton

userlogCanselbutton

(接上)

MD5encrypt(string)

〃以下都要經過

sendMestoServer

〃向主機發送信息

logOK_press(event,handl

e)；

stockQuoteitem_press(e,

h)；

buyStockButton_press(e,

h)；

sellStockButton_press(e,

h)；

?1r1IO?.，?

ClassRealTimeGraph

PrivateClassstockData

stockID

訂單號publicint

〃動態數組存儲股票價

ListID;

格

publicintUsrlD;

ArrayListstockPrice[J

publicstring

Public：

//在windowform類中

recievemess

后更新當前價格，即在

服務器端

StockQueue

Private

stockDatadata

stockDatanext

Public

ClassTradeService

Dispose(bool)

QForml()

GetChatt.erList()

InitializeComponent0

SendtoClient(CharServer.Clientinfo,string)

serviceClient0

爭StartListeningO

豈/clientSocket

E，components

￡；/lsb_client

〃m_client.

,?-;/m_serverThread

m_Tcplisten

甲m_Port

該類還要補充若干個StockQueue類型的成員變量

privatevoidStartListeningO

(

byte[Jipadre=newbyte[]{10,82,14,47);

IPAddressip=newIPAddress(ipadre);

m_Tcplisten=newrcpListener(ip,m_Port);

m_Tcplisten.Start();

while(true)

try

Sockets二m_Tcplisten.AcceptSocket();

clientSocket=s;

m_serverThread=newThrcad(new

ThreadStart(serviceClient));〃多線程deal各個連接用戶的socket

m_serverThread.Start();

)

catch(ExceptionE)

(

Console.WriteLine(E.ToStringO);

如以上startlistening代碼所示，監聽創造一個連接客戶端的套

接字，再用多線程處理該連接，而服務器端則繼續監聽新的套接

字。

這樣主要的交易代碼就能夠放入Serviceclient這個函數中，當

有新客戶信息連入時，即可進行查詢數據庫，對比插入股票隊列

等工作

ClassClientlnfo

//這個類記錄了客戶端的socket

99Clientinfo(string,,System.Net.EndPoint,Syste

T

lCLThread

字

Host

母

3Name

Sock

clthread

endpoint

name

sock

<

數據訪問層類圖

ClassADOSQLserver

Private

ClassstockData

dataSet

//ds下可有4個dataTable訂單號publicint

userTableListID;

publicintUsrlD;

stockTablepublicstring

User_stockTable

tempTable

Public:

////驗證用戶信息

BoolCheckUserlogin(stringusridstring

password);

關于交易算法的詳細設計

5.2撮合算法

在前文中，我們已經提到了，撮合算法是整個交易所乃至整

個證券仿真系統的核心部分。此算法的成功與否，直接影響著仿

真系統是否能實現以及實現效率的高低。

按照真實的交易原則，撮合算法分為連續競價和集中競價兩

種方式。

下面我們將分別對這兩種方式進行實現。

5.2.1連續競價

連續競價是在絕大部分交易時間使用的撮合算法。

連續競價原則：

1.）價格優先原則：價格較高的買入申報優先于價格較低的買

入申報，價格較低的賣出申報優先于價格較高的賣出申報。

2.）時間優先原則：同價位申報、依照申報時序決定優先順

序，即買賣方向、價格相同的，先申報者先于后申報者。先后順

序按證券交易所主機接受申報的時間確定。

在正常情況下，買隊列的第一筆（報價最高）的報價一定小

于賣隊列的第一筆（最低報價）的報價。此時不發生撮合。一旦

買賣隊列的價格發生了交叉，如圖2.3.1所不，發生交叉的那部分

就會進行撮合。

而事實上，由于每一筆新來的單子進入數列后都會觸發一次

比較，因此每次觸發撮合都是由新單子促成的。稱為“來一筆撮

合一次”，也就是連續競價。

麻

撮合成功

圖2.3.1

連續競價算法描述:

首先設定QueueStruct結構為元素的買賣兩個隊列BuyQueue

和SellQueueo

為了盡可能的提高效率，減少資源占用，我們用靜態數組構

建這兩個隊列。

其中BuyQueue是時間優先、買價降序排序，而SeHQueue是

時間優先、賣價升序排序，在連續競價條件下，能夠保證

BuyQueue[O]的price小于SellQueue[O]的priceo

連續競價算法如下：

1.)接收一個新單子newlist,判斷newlist是買單還是

賣單；如果是買單，則轉2,如果是賣單，則轉

B；

2.)取賣單隊列頭SellQueue[O],if

SellQueue[O].price>newlist.price,利用插入排序將

newlist插入到買隊列BuyQueue中,轉1；

3.)ifSellQueue[0].count>newlist.count,newlist完全撮

合，SellQueue[0].count=SellQueue[0].count一

newlist.count,轉2；

4.)ifSellQueue[0].count<=newlist.count,SellQueue[O]

撮合，并將SellQueue[O]從SellQueue隊列中刪

除，newlist.count=newlist.count-

SellQueue[0].count,轉2；

5.)取買單隊列頭BuyQueue[O],if

BuyQueue[O].price<newlist.price,利用插入排序將

newlist插入到賣隊列BuyQueue中，轉1；

6.)ifBuyQueue[0].count>newlist.count,newlist完全

撮合,BuyQueue[0].count=BuyQueue[O].count一

newlist.count,轉1；

7.)ifBuyQueuefO].count<=newlist.count,

BuyQueue[O]撮合，并將BuyQueuelO]從

BuyQueue隊列中刪除，

newlist.count=newlist.count-BuyQueue[0].count,轉

5；

如下面流程圖5.2.2所示:

圖3.2.2

5.2.2集合競價

集合競價是指對所有有效委托進行集中處理，深、滬兩市的

集合競價時間為交易日上午9：15至9：25o

集合競價原則：

?凡是高于開盤價的買單一定成交；

?凡是低于開盤價的賣單一定成交；

■凡是高于開盤價的賣單一定不成交；

■凡是低于開盤價的買單一定不成交；

集合競價分四步完成：

第一步：確定有效委托在有漲跌幅限制的情況下，有效委托

是這樣確定的：

根據該只證券上一交易日收盤價以及確定的漲跌幅度來計算

當日的最高限價、最低限價。有效價格范圍就是該只證券最高限

價、最低限價之間的所有價位。

限價超出此范圍的委托為無效委托，系統作自動撤單處理。

第二步：系統根據競價規則自動確定集合競價的成交價，這

個價格就是當日的開盤價，所有高于開盤價的買盤和所有低開開

盤價的賣盤均以此價格成交，集合競價的成交價確定原則是：以

此價格成交，能夠得到最大成交量。

第三步：集中撮合處理所有的買委托按照委托限價由高到低

的順序排列，限價相同者按照進入系統的時間先后排列；所有賣

委托按委托限價由低到高的順序排列，限價相同者按照進入系統

的時間先后排列。依序逐筆將排在前面的買委托與賣委托配對成

交，即按照“價格優先，同等價格下時間優先”的成交順序依次成

交，直至成交條件不滿足為止，即不存在限價高于等于成交價的

叫買委托、或不存在限價低于等于成交價的叫賣委托。

所有成交都以同一成交價成交。這司一成交價成交的買賣單

第四步：行情揭示:

1.)如該只證券的成交量為零，則將成交價位揭示為

開盤價、最近成交價、最高價、最低價，并揭示

出成交量、成交金額。

2.)剩余有效委托中，實際的最高叫買價揭示為叫買

揭示價，若最高叫買價不存在，則叫買揭示價揭

示為空；實際的最低叫賣價揭示為叫賣揭示價，

若最低叫賣價不存在，則叫賣揭示價揭不為空，

集合競價中未能成交的委托，自動進入連續競價。

按照這樣的原則和要求，我們設計了如下的集合競價撮合算

法。如圖324所示。

判斷兩隊列是否開盤價為昨日收

否都不為空盤價，成交量為0

小于0

i=j=O,M、N分別為BuyQueue[]與SellQueue[|非空元素

的數目;BOOLk;Buy=BuyQueue[O];Sell=SelQueue[O]

是

等于0

大于0

開盤價為(SelQieue『1].price+BuyQueue[i-11price)乏;總開盤價為BuyQueue[i].price;總

成交量為Selll.count成交量為SeMcount

等于0

小TO

w

開盤價為(SellQueue[j].price+BuyQueue『1].price)2開盤價為SelQueueQ.price;總成

總成交量為Buy1.count交量為Buy1.count

圖3.2.4

集合競價算法描述：

和連續競價一樣，首先設定QueueStruct結構為元素的買

賣兩個隊列BuyQueue和SellQueueo

為了盡可能的提高效率，減少資源占用，我們用靜態數組

構建這兩個隊列。

其中BuyQueue是時間優先、買價降序排序，而

SellQueue是時間優先、賣價升序排序。在開市到開盤這段時

間內，買賣單已經分別進入了買賣隊列內排好了序。

一旦宣布開盤，則觸發集合撮合，如下：

?判斷兩隊列是否都不為空，如是，轉2；如

否，轉21；

■判斷BuyQueue[0].prince與

SellQueue[0].prince之差，如大于等于0,轉

3：如小于0,轉21；

■定義inti=j二0；M、N分別為買賣兩隊列非空

元素的個數；BOOLk；QueueStruct

Buy=BuyQueue[0]；Sell=SellQueue[O]；

Buyl；Selll；轉4；

■判斷BuyQueue[i].prince與

SellQueuefjl.prince之差，如大于等于0,轉

5：如小于0,轉14；

■判斷Buy.count與Sell.count之差，如大于

0,轉6；如小于等于0,轉9；

j++；k=true；Sell1.count=Sel1.count；

Sell.count=Sell.count4-SellQueue[iSellQueue]

.count；轉7；

判斷j是否小于N,如是，轉4；如不是，轉

8；

開盤價為BuyQueue[i].price；總成交量為

Sell.count；統計成交數據及回報，并返回；

i++；k=false；Buy1.count=Buy.count；

Buy.count=Buy.count+BuyQueue[i].count；

轉10；

判斷i是否小于M,如是，轉4；如不是，轉

11;

判斷Buy.count與Sell.count之差，如小于

0,轉12；如等于0,轉13；

開盤價為SellQueue[j].price；總成交量為

Buy.count；統計成交數據及回報，并返回；

開盤價為(SellQueue[j].price+BuyQueue[i-

l].price)/2；總成交量為sell.count；統計成交

數據及回報，并返回；

判斷k值，如為true,轉15；如為false,轉

18；

判斷Buyl.counl與Sell1.count之差，如大于

0,轉16；如小于0,轉17；

開盤價為BuyQueue[i].price；總成交量為

Selll.count；統計成交數據及回報，并返回；

開盤價為(SellQueue[j-l].price+BuyQueueti-

ll.price)/2；總成交量為Sell1.count；統計成

交數據及回報，并返回；

判斷Buyl.count與Sell.count之差，如小于

0,轉19；如等于0,轉20；

開盤價為SellQueue[j].price；總成交量為

Buyl.count；統計成交數據及回報，并返回；

開盤價為(SellQueue[j].price+BuyQueue[i-

l].price)/2；總成交量為Buy1.count；統計成

交數據及回報，并返回；

開盤價為昨日收盤價，成交量為0；保留所有

數據至開盤進入連續競價撮合；

5.2.3買賣隊列排序

上面我們介紹了撮合算法的核心部分，但實際上在撮合前

后都要對兩個買賣隊列進行一定的插入和排列處理，這在整

個算法中也是很重要的部分。下面我們就來具體介紹一下。

對所有的排列和插入我們考慮了效率問題之后，最后統一

使用了二分插入排序法。

在單子進入隊列時，我們首先統計出當前隊列中的非空數

據個數，然后再經過新單子與當前隊列中間值的價格比較，

確定新單子在隊列的前半部分還是后半部分，然后再取該區

域中間值與之比較，直到確定新單子應在的位置。

如下列代碼所示：

intlow=0;inthigh=N-l;//N為隊列中非空元素的個數

while(low<=high)

(

intm=(low+high)/2;

if(newlist->price<SellQueue[m].price)

high=m-1;

elselow=m+l；

for(inti=N-l;i>=high+l;-i)

SellQueue[i+1]=SellQueue[i];

SellQueue[high+l]=*newlist;

這是賣隊列的排序，對于買隊列的排序與之相似，只是價

格排列是由高到底。在這里不再贅述。

這種插入排序方法完全符合了撮合算法中價格優先、時間

優先的要求，而且效率也是比較高的。

在集合競價前和連續競價后進行的插入排序都是這樣進行

的，而在集合競價撮合之后，對兩隊列的重新排列，我們首

先使用了memset函數將前面已全部成交的t個元素清空，然

后將t到N(原總非空元素個數)前移t位。

如下列代碼所示：

for(intp=0;*t<*N;p++,*t++)

QueueStructtemp;

temp二Queue[*t];

Queue[*t]=Queue[p];

Queue[p]=temp;

5.2.4撮合算法的運行機制

在交易所正常運行時，一天內分為開市、開盤、休市、復

開、收市等5個步驟。

開市：每天上午9:15開市。這時候，股民能夠經過券商向交

易所遞單。同一只股票的買賣單開始分別進入這只股票的買賣隊

列中，但并不進行撮合。該過程一直持續到9:25。

開盤：每天上午9:30正式開盤。9:25-9:30為盤前處理，這段

時間也就是集合競價撮合算法運行的時間。9:25,買賣兩隊列開

市不再接收新的單子。新的單子這時都放在緩沖區中，直到兩隊

列運行完整個集合競價算法后開市重新進單時，再依序將單子從

緩存區取出讀入買賣隊列進行連續競價的撮合。買賣隊列于9:25

開始集合競價，運算完畢，得出開盤價等所有統計數據并發布行

情以及發送完所有回報之后，重新接收單子進入該日正常交易

中，使用連續競價算法進行撮合。

休市：每天上午11:00休市。此時，所有的券商不再接受買

賣單子，也不再給交易所遞單。交易所將此前已經收到的所有單

子撮合之后處于休息階段。并進行各種當日前市盤點。

復開：每天下午13:30復開。此時，券商開市接收用戶的遞

單，并將其送交交易所。交易所重新開市進入連續競價撮合

收市：每天下午15:00收市。此時交易所不再接受任何單

子，準時進行最后一筆單子的撮合之后，關閉撮合線程。將最后

得到的收盤價等數據統計發送完之后，當天的所有工作全部結

束。

如圖3.2.5所示。

9：25開巾15：00收市

9：33開盤13：30復開

11：00休市

開市開盤