《本科畢業(yè)設計-基于某大型實時交易系統(tǒng)的開發(fā)過程.doc》由會員分享，可在線閱讀，更多相關《本科畢業(yè)設計-基于某大型實時交易系統(tǒng)的開發(fā)過程.doc（23頁珍藏版）》請在裝配圖網上搜索。

學士學位論文 基于某大型實時交易系統(tǒng)的開發(fā)過程 作者：吳晶 學號：005598 指導教師：杜慶峰 同濟大學軟件學院軟件工程專業(yè) 二零零四年六月 摘要 當前，計算機軟件的趨勢正朝著龐大且復雜的方向發(fā)展。這是因為計算機處理能力的增大，導致用戶對它的期望更多。我們滿足客戶需求的同時，需求本身也變得越來越復雜，從而，開發(fā)出來的軟件也。總之我們希望軟件運行的越來越快捷。 大型軟件的開發(fā)需要一種受控的工作方式，它需要一個過程來集成軟件開發(fā)的許多方面。本文以一個大型實時交易系統(tǒng)軟件為例子，闡述大型實時交易軟件的開發(fā)過程，以及在過程的每個階段都應注意的問題，并簡要評述了特定的過程在軟件項目開發(fā)中的優(yōu)勢及不足之處。 【關鍵詞】實時系統(tǒng), 開發(fā)過程, 分析,設計 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 have more demand on it.The time when we need the software which meets our requirements better,we also make the software become complicated. All in all,we hope the software become fast and fast. Large software development needs a way under control,it also needs a process to integrate several aspects of .This paper gives an 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 一、 引言 當前，軟件的趨勢是朝著更大更復雜的系統(tǒng)發(fā)展。這部分地是因為計算機的處理能力每年都在增大，導致用戶對它的期望更多。同時，這種趨勢也受到為交流各種信息（從純文本到格式化文本到圖像到圖表再到多媒體）而不斷擴大互聯(lián)網的使用的影響。在產品版本的不斷升級過程中，我們了解到產品是如何被改進的，因此我們對越來越復雜的軟件的胃口也就越來越大。我們需要更符合我們的需要的軟件，但是，這種需要反過來又使得軟件越來越復雜?？傊?，我們需要更多。我們希望軟件運行得越來越快捷。推向市場的時間是另一個重要的推動因素 。然而，要達到這個目的是困難的。我們對強大、復雜軟件的需要與軟件開發(fā)的當前狀況并不一致。今天，大多數人還在使用25 年前使用的舊方法來開發(fā)軟件。這就是癥結所在。除非我們革新我們的方法，否則，我們無法達到開發(fā)當前所需的復雜軟件的目標 。我們可以把這個軟件問題歸結為軟件開發(fā)人員面臨的將一個大型軟件項目的眾多線索綜合在一起的困難。大型軟件的開發(fā)需要一種受控的工作方式。它需要一個過程來集成軟件開發(fā)的許多方面。它需要一種通用方法 ，該方法能： （1）提供應如何對整個開發(fā)團隊的開發(fā)活動進行組織的指導。 （2）綜合指導單個開發(fā)人員和開發(fā)團隊。 （3）規(guī)定開發(fā)成果是什么。 （4）提供監(jiān)控和衡量一個項目中的產品和活動的標準。 本文主要以中國外匯交易中心本幣交易系統(tǒng)為例子來討論一種大型實時交易軟件的開發(fā)過程。  一 項目及軟件開發(fā)過程模型 1.1項目簡介 中國外匯交易中心是全國銀行間外匯市場、人民幣同業(yè)拆借和債券交易市場的組織者，為包括國有獨資商業(yè)銀行、股份制商業(yè)銀行、外資銀行、保險公司、證券公司、基金公司、財務公司等各類金融機構提供交易、清算交割和信息等方面的服務。 在交易中心目前運行的本幣交易系統(tǒng)采用了B／S結構，是一個建立在廣域網上、采用總中心－分中心－交易成員三層結構的分布式應用系統(tǒng)?？傊行?、分中心主機均采用PC SERVER，總中心和分中心瑞安裝SCO UNIX操作系統(tǒng)、SYBASE數據庫管理系統(tǒng)，分中心WEB服務器安裝了PowerDynamo2.0。使用JavaScript、ASP和Dynamo Script開發(fā)交易系統(tǒng)的Web端應用程序，用PowerBuilder開發(fā)場務管理子系統(tǒng)，使用C語言和SYBASE OPEN CLIENT開發(fā)后臺進程監(jiān)控系統(tǒng)等應用程序。 目前運行的系統(tǒng)涉及的業(yè)務主要包括金融機構間的資金信用拆借、債券的二級市場交易與回購業(yè)務、隔夜拆借交易系統(tǒng)、債券市場一級市場發(fā)行的分銷報價系統(tǒng)等。系統(tǒng)為參與本幣市場交易的用戶提供風險管理、行情信息等各種支持及清算、統(tǒng)計等輔助功能，以保證其日常交易的順利進行。同時，保證市場管理部門對市場交易的日常管理及實時監(jiān)控，保證中央銀行對本幣交易市場的交易狀況及交易成員交易行為的了解和監(jiān)督。 現(xiàn)行系統(tǒng)由于操作平臺相對落后及系統(tǒng)結構方面的缺陷，存在不能滿足業(yè)務處理變化的要求、系統(tǒng)穩(wěn)定性不夠、交易便捷性不夠、系統(tǒng)響應慢等問題，目前已不適應業(yè)務發(fā)展的需要。系統(tǒng)的另外一些不足，包括靈活性不夠、缺乏技術分析工具、與其他交易系統(tǒng)、信息系統(tǒng)整合不足等。為了滿足市場需要、提高系統(tǒng)性能、適應整個交易中心信息化建設的需要，交易中心提出建設中國外匯交易中心新版本幣交易系統(tǒng)。 1．2 開發(fā)過程模型介紹 1．3 SCM工具的選擇及在過程控制中的使用 3.6.1 配置管理工具的選擇 在大型交易軟件的開發(fā)過程中，配置和變更管理也是非常重要的，因為配置和變更管理提供了準則來管理演化系統(tǒng)中的多個變體，跟蹤軟件創(chuàng)建過程中的版本。配置和變更管理描述了如何管理并行開發(fā)、分布式開發(fā)、如何自動化創(chuàng)建工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。 在本幣交易系統(tǒng)的開發(fā)過程中，根據項目的實際情況，項目組選擇了CVS作為版本控制軟件。項目組用一個文件服務器作為CVS的代碼倉庫，然后每個開發(fā)機器上都安裝客戶端軟件，在開發(fā)的時候從服務器下載源代碼或者提交完成的文件。項目組選擇CVS主要使基于以下幾點考慮的： (1) 免費 作為開放源代碼世界的杰作，CVS使免費的。而且世界上有很多杰出的程序員都在維護這個軟件，從而使軟件更趨穩(wěn)定和強大。 (2) 出色的并行開發(fā)支持 CVS能夠支持客戶進行并行開發(fā)，它實現(xiàn)的版本分支功能能夠嘎實現(xiàn)軟件開發(fā)者夢寐以求的許多功能－－多小組并行開發(fā)不同的模塊而不相互干擾，隔離危險或者冒險代碼，在任意版本上打補丁，可靈活定制多種版本的演示模型等等。由于，本幣系統(tǒng)模塊較多，而且是多個項目小組并行開發(fā)，所以CVS的這些強大的功能能夠讓項目組開發(fā)人員大大提高效率，因此它很適合作為本幣系統(tǒng)開發(fā)的版本控制軟件。 當然，在軟件開發(fā)的時候，還有很多的版本控制軟件可以供開發(fā)人員選擇，比如Rational ClearCase和 Microsoft Source safe等等。 （1） Rational Clearcase 和CVS相比較，Clearcase是一款真正的商業(yè)化軟件產品，功能更加強大、全面和完善。它適合管理大型、特大型的軟件項目開發(fā)。但是它的缺點也很明顯，首先是價格昂貴，一般公司很難承受。其實它對服務器性能、網絡帶寬都有很高的要求，這意味著更高的投資。此外，由于clearcase功能比較復雜，因此，開發(fā)人員將會耗費很大的精力才能熟練的使用它的功能。 （2） Microsoft Source Safe 它是微軟公司為Visual Studio配套開發(fā)的一個版本管理系統(tǒng)，它自動集成在Visual Stdio 中，具有圖形用戶界面，管理和使用都比較簡單。但是Source Safe 不具備跨平臺的能力，不支持版本的分支和合并，不支持并行開發(fā)，在一個時間只能有一個人修改某個源文件。因此Source Safe 只適合于開發(fā)團隊在10個人以下的小項目開發(fā)。 經過上面的分析可以看出，用CVS作為大型實時交易軟件的版本控制軟件還是很合適的。它的功能完全符合項目需要，使用方便，而且是免費的軟件。 3.6.2 配置管理計劃的制定 在選擇了一個適合項目開發(fā)的配置管理工具以后，擬訂配置管理計劃也是非常重要的。筆者將以本幣交易系統(tǒng)為例子，說明配置管理計劃的制定。 （1） 配置標識 配置項標識是配置管理的基礎性工作，是管理配置的前提。配置項命名是配置標識的重要工作，所謂標識，其實質就是區(qū)分，在眾多的配置項中合理、科學地命名是最為有效的區(qū)分方法。除為配置項命名外，必要時應提供某些相關信息，比如：配置項組名及其存放位置，子目錄名等；版本信息；作者、修改者、審核者信息。常見的配置項是文檔，代碼。工具以及第三方的產品。本幣交易系統(tǒng)中的文檔主要有：需求分析說明書，詳細設計說明書，主機模塊設計說明書，界面設計說明書等等。對于工具的配置項，要標識出中英文名稱，版本號，提供商和序列號。 （2） 配置基線 基線是已經通過正式復審核和批準的某規(guī)約或產品，它因此可以作為進一步開發(fā)的基礎，并且只能通過正式的變化控制過程的改變。在本幣交易系統(tǒng)的實施過程中將建立以下基線： 1． 需求規(guī)約 2． 概要設計規(guī)約 3． 詳細設計規(guī)約 4． 編碼實現(xiàn) 5． 測試 6． 用戶認可測試 在軟件工程化生產的各個階段中，與本階段的階段產品有關的全部信息在軟件開發(fā)庫存放，與前面各個階段的階段產品有關的信息則在軟件受控庫存放。在研制與開發(fā)階段的階段產品的過程中，開發(fā)者和開發(fā)小組長有權對本階段的階段產品作必要的修改；但是如果開發(fā)者或開發(fā)小組長認為有必要修改前面有關階段的階段產品時，就必須通過項目的配置管理小組辦理正規(guī)的審批手續(xù)。因此，軟件開發(fā)庫屬開發(fā)這個階段產品的開發(fā)者管理，而軟件受控庫由項目的配置管理小組管理。軟件經過組裝與系統(tǒng)測試后，應該送入軟件產品庫，如欲對其修改，必須經軟件配置管理小組研究同意，然后報配置管理委員會批準。 （3） 版本控制 這里所說的版本，不是指單個配置項的版本屬性，而是指配置項形成的集合，可以是某個模塊、子系統(tǒng)或整個軟件系統(tǒng)。版本控制要解決的第一個問題便是版本標識，也就是為區(qū)分不同的版本，要給它們科學的命名。本項目以號碼版本標識法為主，符號版本標識法作為輔助手段，例如版本：V2.0.0(INTEGRATION_TEST)。版本號包括主版本號、副版本號、發(fā)布號，格式。 （4） 發(fā)行管理 版本發(fā)行解決了如何把產品配置成可以使用的方法。由于本項目需要涉及總中心及各分中心的切換，以及需要與各家銀行聯(lián)網調試，因此，對于發(fā)行到外部使用的軟件要進行控制，用SER流程進行控制，keyword為SCM_DELIVERY，表單包含的主要信息如下：產品名稱、版本信息、交付使用者、使用場所、交付方式、交付內容。 軟件配置計劃的制定有助于保證所交付的軟件能夠滿足項目委托書中規(guī)定的各種原則需求，能夠滿足本項目總體設計組制定的軟件系統(tǒng)需求規(guī)格說明書中規(guī)定的各項具體需求。因此，在軟件開發(fā)的過程中，應該嚴格按照配置計劃制定的內容去實施。 二 商業(yè)建模和需求分析 3.2.2系統(tǒng)特性需求 作為一個大型實時的交易系統(tǒng)，客戶對系統(tǒng)提出了非常高的需求，經過總結他們的需求主要集中在以下三點： （1）實時性： 交易系統(tǒng)是業(yè)務處理十分頻繁、數據交換吞吐量很大的系統(tǒng)，業(yè)務處理的速度直接關系到公司的經濟效益和客戶對公司的評價。在客觀條件下，整個廣域網系統(tǒng)必須在大業(yè)務量的情況下同時保持快速的實時響應能力，以保證整個業(yè)務系統(tǒng)的通暢運行。 （2）安全性： 安全性問題主要體現(xiàn)在交易成員資金和交易的安全性以及營業(yè)部內部網絡的安全性，但隨著公司一級的廣域網系統(tǒng)的建立，特別是在本幣交易系統(tǒng)中，系統(tǒng)的安全就顯得更為重要，各個方面充分考慮整個系統(tǒng)的安全性。另外，對系統(tǒng)中所有的重要操作必須絕對留痕，以規(guī)范管理。 （3）可靠性和健壯性： 客戶要求在系統(tǒng)交易的過程中要連續(xù)無故障，因為一旦交易中斷，都會給交易成員帶來損失。系統(tǒng)對用戶的操作順序、輸入的數據進行正確性檢查，并以顯著方式提示錯誤信息。必須使用系統(tǒng)出錯處理機制，當應用軟件系統(tǒng)運行過程中發(fā)生錯誤時，系統(tǒng)將明確提示錯誤信息并指導用戶進行處理。提供系統(tǒng)的運行監(jiān)視和故障恢復機制，生成系統(tǒng)運行的日志信息，跟蹤系統(tǒng)的所有操作，便于即時發(fā)現(xiàn)并排除故障。 通過對系統(tǒng)特性需求的獲取，可以看出，每一個大型實時系統(tǒng)都有它共有的要求，例如，對實時的要求，對可靠性和健壯性的要求。但由于本幣交易系統(tǒng)的特殊性，客戶對系統(tǒng)的安全性也提出了很高的要求。從這點可以看出，在取得系統(tǒng)的需求的時候，不僅僅要把握那些共有的需求，更重要的是挖掘那些隱含的需求，這些需求往往可能 被需求分析人員或者是客戶所忽略，但卻是非常重要的。 3.3.3系統(tǒng)劃分和接口需求 依據交易中心本幣交易系統(tǒng)方案書中的設計目標、設計原則和系統(tǒng)性能要求目標，并根據用戶使用的要求和特點，中國外匯交易中心新版本幣交易系統(tǒng)包括三大子系統(tǒng)：中國外匯交易中心新版本幣交易子系統(tǒng)，中國外匯交易中心新版本幣中介子系統(tǒng)，中國外匯交易中心新版本幣場務管理子系統(tǒng)。（見圖2） 圖2：本幣系統(tǒng)的劃分圖 其中本幣交易子系統(tǒng)是本幣交易系統(tǒng)項目的核心，主要支持銀行間信用拆借、債券回購、債券買賣和債券分銷市場業(yè)務。新版本幣交易系統(tǒng)中介子系統(tǒng)作為交易系統(tǒng)的一部分，為中介的報價、交易和手工錄入提供完善服務。新版本幣場務管理子系統(tǒng)為系統(tǒng)管理員和場務管理員提供方便靈活的管理接口，完成交易系統(tǒng)的交易控制、數據維護、場務管理和信息查詢提供支持，并提供應急交易的功能。 本系統(tǒng)作為交易中心本幣系統(tǒng)的核心系統(tǒng)，是其他系統(tǒng)建設的基礎和數據源，在本系統(tǒng)的建設中主要考慮的外界接口主要有：中國外匯交易中心本幣信息系統(tǒng)接口、中國外匯中心F－風險管理系統(tǒng)接口、債券結算接口、交易成員本方數據存儲接口，（詳見：圖三）： 債券結算 數據下載 F系統(tǒng) 信息系統(tǒng) 打印機 交易子系統(tǒng) 場務子系統(tǒng) 中介子系統(tǒng) 數據庫 圖3：本幣系統(tǒng)的接口圖 作為一個大型的實時交易軟件，系統(tǒng)分割成幾個獨立的子系統(tǒng)這種架構模式是很有用的。這樣既方便軟件的開發(fā)，又方便軟件的維護的工作。因此在進行需求分析的時候，一定要注意把相同的功能模塊集成到一個子系統(tǒng)中去。同時，由于軟件不是孤立存在的，因此，一定要考慮系統(tǒng)和系統(tǒng)之間的接口問題。不光光要考慮對現(xiàn)有系統(tǒng)的接口，還要考慮對以后擴展系統(tǒng)的接口。否則，對以后軟件的使用和擴展將造成很大的麻煩。 3.3.4系統(tǒng)構架需求 新版本幣交易系統(tǒng)的框架是一個具有多層構架的客戶/服務器應用結構。采用中間件技術構建多層客戶/服務器應用結構已經成為應用開發(fā)和運行的主流技術，其核心概念是利用中間件將應用的表示邏輯（客戶界面）、業(yè)務邏輯（服務組件）和數據管理（數據庫）分為三個不同的處理層： 1、表示層提供協(xié)議控制和用戶界面，與系統(tǒng)最終用戶實現(xiàn)直接交互。負責接收用戶的服務請求，通過socket連接向交易前置服務發(fā)送。 2、商業(yè)邏輯層作為中間層實現(xiàn)核心業(yè)務邏輯服務，這些組件由中間件管理，接受客戶的服務請求，向交易主機提交數據操作，并將交易主機的業(yè)務處理結果返回給請求者。 3、數據層負責整個系統(tǒng)中數據信息的存儲、訪問及其優(yōu)化。 通過使用中間層，實現(xiàn)了業(yè)務邏輯與表示邏輯、業(yè)務邏輯與數據管理的分離，使得系統(tǒng)能夠靈活的適應用戶業(yè)務邏輯的變化。(詳見：圖4) 圖4：系統(tǒng)業(yè)務架構圖 之所以采用這種構架主要是因為考慮到軟件的使用者分布在全國各地，這樣采用web界面的訪問方式可以使軟件實現(xiàn)零安裝。而且采用這種MVC的模式，使的業(yè)務邏輯層、表示層和數據管理層分開。這樣有助于軟件的開發(fā)和維護。由于軟件的系統(tǒng)架構就象人的骨架一樣，是整個軟件的脊椎骨，所以在考慮系統(tǒng)架構的時候一定要從用戶的業(yè)務需求出發(fā)，確保軟件的系統(tǒng)架構合理。 3.3.5軟件功能需求 筆者將以本幣交易系統(tǒng)中中介交易子系統(tǒng)為例子來說明定義功能需求的目的以及怎樣定義軟件的功能需求。 本幣交易系統(tǒng)的中介子系統(tǒng)的相關功能包括： 中介成交處理： （1） 錄入成交單：參與交易的雙方成員經過與中介聯(lián)系后達成交易，交易雙方交易員通過電話/傳真?zhèn)魉统山粏谓o中介，中介交易員把交易成交單錄入系統(tǒng)。 （2） 修改成交單：修改當日中介成交單。 （3） 撤消成交單：撤消當日中介成交單。 中介交易處理： （1） 發(fā)送公開報價：向市場全體成員轉發(fā)已收到的成員匿名報價或手工錄入的報價，代理委托成員完成指定交易。 （2） 發(fā)送對話報價：向特定的市場成員表達本方的具體的交易意向，通過選擇委托方發(fā)送給中介的匿名報價并發(fā)送給所選擇特定成員交易員，此報價對委托方具有約束力。 （3） 詢價交談：為達成一致的交易意向，與交易對手就報價中交易各要素進行磋商。同新版交易子系統(tǒng)詢價交談。 （4） 確認成交：對報價指定交易進行確認，經過交易雙方通過報價交談，對于各交易要素達成一致后，交易雙方都有權確認。同新版交易子系統(tǒng)。 （5） 修改報價：為了達到更準確和及時的表達自己的交易意向，修改本方已經發(fā)送但沒有確認成交或應答的報價中一些交易要素。 （6） 撤消報價：取消交易意向，對本方已經發(fā)送但沒有確認成交或者部分沒有成交的報單進行撤銷。 其它： （1） 登錄：中介交易員進入中介交易系統(tǒng)，代理委托成員進行報價、詢價、確認成交以及錄入成交單等。 （2） 查詢統(tǒng)計：可按開始結束日期、委托方、交易方向、債券代碼、等組合查詢，并小計出筆數和交易量。 詳見：圖5 圖5：中介子系統(tǒng)功能需求 通過上述例子可以看出，在需求分析階段，功能需求(functional requirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務，從而滿足了業(yè)務需求。開發(fā)人員和用戶需要對軟件實現(xiàn)的功能達成一致。要對需要的功能和約束進行提取、組織、文檔化。正確的劃分功能需求非常重要，這就需要需求人員能夠正確把握用戶的需求，了解行業(yè)背景，挖掘隱含需求。 3.3.6需求用例和建模 所謂的用例就是軟件的使用者和系統(tǒng)的交互。一個用例就是系統(tǒng)中向用戶提供一個有價值的結果的某項功能。用例捕捉的是功能性需求。所有用例結合起來就構成了“用例模型”，該模型描述系統(tǒng)的全部功能。用例迫使我們從用戶的利益角度出發(fā)進行考慮，而不僅僅是考慮系統(tǒng)應當具有哪些良好功能。用例不僅僅是定義系統(tǒng)的需求的一個非常好的工具，它還可以驅動系統(tǒng)的設計、實現(xiàn)和測試。亦即整個開發(fā)過程。在需求階段我們一般完成用例的定義，在以后的階段中還會有用例的設計等等。下面筆者將以交易子系統(tǒng)中信用拆借公開報價用例來說明用例的定義。 用例名稱：信用拆借公開報價 系統(tǒng)范圍：交易系統(tǒng) 上下文目標：交易員提供本方的初步交易意向，填寫本方公開報價單，并且通過交易系統(tǒng)發(fā)布在交易系統(tǒng)的公開報價欄中，讓所有的其他交易員能夠看到。 前置條件：交易員已經通過身份認證，并具有信用拆借業(yè)務權限 主要角色：信用拆借交易員 成功場景： 交易員發(fā)出“信用拆借公開報價”交易指令； 系統(tǒng)切換到“信用拆借公開報價”窗口； 交易員填寫信用拆借公開報價要素，并提交； 系統(tǒng)校驗信用拆借公開報價，并廣播信用拆借公開報價； 在線交易機顯示信用拆借公開報價。 擴展： 3a.公開報價要素不合法 3a.1、拆借方向未填寫，提示交易員：“請?zhí)顚懖鸾璺较颉?，返回?； 3a.2、公開報價要素數據格式不對，返回失敗信息：“XX數據格式不對” ，返回到3。 4a.數據不合法 4a.1、包格式不對，提示交易員：“公開報價失敗”， 用例失敗 。 備注： 業(yè)務規(guī)則： 1.1、“利率”和“金額”允許報空值（可不填寫具體數值），只表示資金進出方向； 1.2、系統(tǒng)自動生成每筆報價編號，在系統(tǒng)狀態(tài)欄中顯示報價發(fā)送狀態(tài)。 一個完整的用例需要包括以下內容： （1） 名稱： 每個用例都必須有一個區(qū)別于其他用例的名稱。 （2） 用例參與者 一個參與者表示用例的使用者在與這些用例進行交互時所扮演的角色的一個緊密的集合。通常一個參與者代表的角色有：人，硬件設備，或甚至是另外一個系統(tǒng)。 （3） 用例和事件流 用例描述的是一個系統(tǒng)做什么，這可以通過一個足夠清晰的、外部人員很容易理解的文字描述一個事件流，來說明一個用例的行為。書寫這個事件流的時候，應該包含用例何時開始，何時結束，用例合適和參與者交互，什么時候對象被交換，以及行為的基本流和可選擇流。 3.3.7小結 通過對本幣交易系統(tǒng)的需求分析為例子的分析，可以看出最重要的是客戶和系統(tǒng)開發(fā)人員在系統(tǒng)的工作內容方面達成一致，系統(tǒng)開發(fā)人員能夠清晰的了解系統(tǒng)的需求，定義系統(tǒng)的邊界。最后要生成一個用例模型，其中主角代表與系統(tǒng)通信的外部單元，用例代表事務序列，為主角提供可測量的結果值。 三 系統(tǒng)設計與實現(xiàn) 本幣系統(tǒng)的設計主要是為了說明系統(tǒng)總體設計的技術方案和模塊的詳細設計，涉及到系統(tǒng)設計的主要方面，如系統(tǒng)架構、模塊劃分、功能分配、接口設計、運行設計、數據庫設計和出錯處理設計等內容，以向整個開發(fā)期提供關于子系統(tǒng)關系的總體描述，從而作為程序詳細設計或編碼的框架性基礎。 3.3.1總體結構設計 在本文中筆者將以交易子系統(tǒng)的交易處理模塊為例子來闡述總體結構設計。交易處理模塊采用四層架構，在業(yè)務處理中采用交易中間件，分為數據表示層、通信層、業(yè)務處理層和數據層；整個結構基于消息的驅動。（UML圖6） UserInterface：用戶的操作界面，其中分為會員交易前臺界面，中介交易前臺界面，場務管理前臺界面。實現(xiàn)表現(xiàn)層（終端界面）所要求的功能。 NetWork：系統(tǒng)中客戶端和服務器端的通訊采用標準的協(xié)議，該模塊負責兩者之間數據的傳輸工作，檢查通訊故障。 DataProtocol：由于客戶端和服務器端傳輸的數據都采用了標準的XML格式，該模塊一方面對所有發(fā)送的數據按照XML的語法格式進行組織，另一方面對所有收到的數據進行解析； FunctionCase：各子系統(tǒng)業(yè)務處理（場務子系統(tǒng)、中介子系統(tǒng)、交易子系統(tǒng)），實現(xiàn)終端業(yè)務層、交易業(yè)務層和主機業(yè)務層所要求的功能。（中間件服務器） MessageDispatcher：該模塊實現(xiàn)了前置機和交易主機服務器端各模塊之間交互消息的發(fā)送、接收以及分發(fā)功能，實現(xiàn)前置機主機通訊協(xié)議層所要求的功能。（中間件客戶端） Logging：記錄系統(tǒng)運行中的時序信息，包括正常、調試和錯誤信息，幫助診斷系統(tǒng)狀況，測試模塊功能，確定問題的位置?？梢愿鶕渲梦募?，確定輸出的內容。 DataProcess：數據庫的接入，實現(xiàn)主機數據庫通訊協(xié)議層所要求的功能。 體系結構是軟件系統(tǒng)中最本質的東西,體系結構是對復雜事物的一種抽象。良好的體系結構是普遍適用的，它可以高效地處理多種多樣的個體需求。一提起“房子”，我們的腦中馬上就會出現(xiàn)房子的印象（而不是地洞的印象）。“房子”是人們對住宿或辦公環(huán)境的一種抽象。不論是辦公樓還是民房，同一類建筑物（甚至不同類的建筑物）之間都具有非常相似的體系結構和構造方式。如果13億中國人民每個人都要用特別的方式構造奇異的房子，那么960萬平方公里的土地將會變得千瘡百孔，終日不得安寧。 體系結構在一定的時間內保持穩(wěn)定。只有在穩(wěn)定的環(huán)境下，人們才能干點事情，社會才能發(fā)展?？茖W告訴我們，宇宙間萬物無時無刻不在運動、飛行。由于我們的生活環(huán)境在地球上保持相對穩(wěn)定，以致于我們可以無憂無慮地吃飯和睡覺，壓根就意識不到自己是活生生的導彈。軟件開發(fā)最怕的就是需求變化，但“需求會發(fā)生變化”是個無法逃避的現(xiàn)實。人們希望在需求發(fā)生變化時，最好只對軟件做些皮皮毛毛的修改，可千萬別改動軟件的體系結構。就如人們對住宿的需求也會變動，你可以經常改變房間的裝璜和擺設，但不會在每次變動時都要去折墻、拆柱、挖地基。如果當需求發(fā)生變化時，程序員不得不去修改軟件的體系結構，那么這個軟件的系統(tǒng)設計是失敗的。 良好的體系結構意味著普適、高效和穩(wěn)定。 3.3.2功能模塊的設計 本文中筆者將以撤銷本方交易員模塊的設計為例子來闡述交易系統(tǒng)中模塊的設計。 （1）模塊描述 由首席交易員撤銷本方交易員。首席交易員在會員機上將CDlrDelReqMessage請求消息發(fā)給主機，主機Tuxedo服務進程接到此請求，調用管理服務模塊中的撤銷本方交易員服務進程。主機獲取所撤銷的交易員Id，檢查所撤銷的交易員是否已存在，通過驗證后，撤銷交易員到交易員表,并記錄各要素，然后向首席交易員返回成功響應消息。 （2）對象說明 該模塊用到以下方法： CMessage* CManageCommand:: DeleteDealer (CMessage* pMessage) （3）動態(tài)模型 <1>首先接收注銷本方交易員請求消息類CDeleteDealerReqMsg并創(chuàng)建注銷本方交易員請求消息實例； <2>接下來創(chuàng)建數據庫接口實例CDBInterface* pDB=new CDBInterface；注銷本方交易員響應消息實例CDeleteDealerResMsg* pDeleteDealerResMsg; <3>接著調用數據庫接口實例的pDealerModel=pDB->findDealerModel(msgDlrId)方法獲得交易員模式pDealerModel; <4>然后調用DlrId=pDlrDelReqMessage->getDlrId()檢查所注銷的交易員是否存在; <5>調用 strcmp(MemId,pDealerModel->getDlrMemId())方式檢查欲注銷交易員是否屬同一交易成員; <6>調用strcmp(CreatorId,pDealerModel->getDlrCreatorId())方法檢查欲注銷交易員是否由其創(chuàng)建者注銷; <7>調用if(pDealerModel->getDlrState()!=STATE_DEALER_NORMAL)方法檢查欲注銷交易員狀態(tài)是否為正常狀態(tài)（STATE_DEALER_NORMAL）; <8>調用pDealerModel->setDlrStatus(STATE_DEALER_DELETE)方法設置該交易員狀態(tài)位注銷狀態(tài)（STATE_DEALER_DELETE）; <9>調用pResponseMessage=pDeleteDealerReqMsg->toResponse()方法返回注銷本方交易員響應消息。 一個完整的功能模塊設計應該包括模塊描述、對象說明、動態(tài)模型這三大塊內容。模塊描述用來敘述該功能模塊應該實現(xiàn)的功能。對象說明列舉了該模塊使用的方法。 動態(tài)模型說明了該模塊實現(xiàn)該功能的詳細步驟以及它使怎樣和系統(tǒng)交互的。 一般情況下功能模塊是邏輯功能整體，進行具體編碼由接口程序（函數、存儲過程、方法等）進行具體實現(xiàn)。一個功能模塊一般有最少一個或多個接口程序，所以每個功能模塊下有最少一個或多個接口程序描述，而多個接口程序的關系通過功能模塊中的流程邏輯進行說明。接口代碼：函數、存儲過程、方法等的名稱接口功能說明：說明本接口程序的功能。接口輸入參數：給出對每一個輸入項的特性，包括名稱、標識、數據的類型和格式、數據值的有效范圍、輸入的方式。接口返回數據：給出對每一個輸出項的特性，包括名稱、標識、數據的類型和格式，數據值的有效范圍，輸出的形式。 3.3.3用戶界面設計 本幣交易系統(tǒng)的界面總的設計總體原則是：簡潔明了，方便易用。下面筆者以信用拆借的主界面設計來闡述用戶界面的設計。 信用拆借的主界面： 圖7：信用拆借的主界面 信用拆借公開報價所用模型： 顯示名稱 類型 英文名稱(*) 屬性(#) 輸入控件(Table) 備注 編號 int PubBidId 報價方 long PubBidMemId 交易員 long PubBidDlrId 交易方向 enum PubBidDir 0拆入 1拆出 金額 money Amt 利率 rate Ir 期限 short Tl 時間 time PubBidTime 動作： 名稱 操作 說明 打開公開報價框 點中報價，雙擊mouse左鍵 增加公開報價 單擊mouse右鍵 修改公開報價 撤銷公開報價 點中報價，單擊mouse右鍵 打印公開報價 點中報價，單擊mouse右鍵 詳細顯示公開報價方名稱、交易員聯(lián)系方式 點中報價 在界面設計的時候，首先應該畫出界面的樣子，畫圖應該使用專門的軟件，以使畫出來的界面比較逼真并容易識別。接著界面設計應該列出該界面所用的模型，模型應該包括，界面上顯示的元素的名稱、類型、屬性、輸入控件等。最后還應該列出客戶能對界面的操作，以及該操作的聲明。這樣的一個界面設計才是完整且符合要求的。 由于軟件的界面直接和客戶打交道，所以大型軟件的界面設計變的很重要，筆者認為界面設計應該主要做到以下幾點： （1） 界面的合適性 界面的合適性是指界面是否與軟件功能相融洽。如果軟件的界面不適合于軟件的功能，那么界面將毫無用處。所以界面的合適性是界面美的首要因素，它提醒界面的設計者不要片面追求外觀漂亮而導致失真或華而不實。界面的合適性。既提倡外美內秀，又強調恰如其分。對于象大型交易系統(tǒng)這類軟件，界面應該樸實無華，不需要把界面設計的類似于兒童娛樂軟件那樣花哨。 （2） 界面的風格 對于象大型實時交易軟件這樣的商業(yè)應用軟件的界面設計應該注重一致性。設計者必須密切注意在相同應用領域中最流行的軟件的界面，必須尊重用戶使用這些軟件的習慣。例如大多數軟件習慣于設置F1鍵為幫助熱鍵，如果某個設計者別出心裁地讓F1鍵成為程序終止的熱鍵，那么在用戶渴望得到幫助而伸手擊F1鍵的一剎那，他的工作就此結束。因此本幣交易系統(tǒng)使用jbuilder快速地開發(fā)出簡潔美觀的圖形用戶界面。在Internet/Intranet領域，瀏覽器幾乎成了唯一的客戶機程序，因為用戶希望用完全一致的軟件來完成千變萬化的應用任務。 （3） 界面的廣義美 盡管界面的美并沒有增加軟件的功能與性能，卻又是必為可少的。用戶使用界面時，除了直接的感官美感外，還有很大一部分美感是間接的，它們存在于人們的使用體驗中，例如方便，實用等。本幣系統(tǒng)界面的設計的時候，充分考慮到了用戶的方便和實用，為一些用戶常用的功能設置了快捷鍵，而且右鍵實現(xiàn)了很多菜單功能，這樣用戶輕按鼠標就能夠方便的操作。 3.3.4系統(tǒng)出錯處理設計 由于系統(tǒng)采用的是客戶機/服務器和瀏覽器/服務器的綜合應用環(huán)境中，牽涉到的軟硬件資源比較多，無論哪個環(huán)節(jié)出了問題，數據庫訪問都不會成功，應用程序的進一步執(zhí)行都會受到影響。因此我們的應用開發(fā)必須能預先發(fā)現(xiàn)問題，努力解決問題，并以準確無誤的信息通知用戶，從而保證應用程序處理錯誤的強壯性。 （1） 出錯信息分類 出錯信息可以分為三類，他們分別是： <1>通訊線路錯誤, 當網絡通訊出現(xiàn)故障時，可能發(fā)生通訊線路錯誤，因判斷方式和處理方法不同，按照局域網和廣域網劃分，可分為兩類。 <2>數據庫操縱錯誤，開發(fā)應用程序訪問數據庫時，在三個地方可能會導致數據庫訪問錯誤，它們是使用控件函數操作數據庫（提取數據、更新修改），使用嵌入式SQL語句操作數據庫，數據和業(yè)務的邏輯矛盾和錯誤。 <3>系統(tǒng)設計錯誤，用戶常會輸入一些不正確的信息。如果不加以檢測，會導致更嚴重的系統(tǒng)錯誤。輸入數據錯誤包括數據格式錯誤和數據內容（含義）錯誤。導致錯誤的原因是用戶的誤操作。 （2） 出錯處理的對策 出錯處理方法可分三類：重試、取消和退出。對一些較輕的錯誤，如數據格式輸入錯誤，可讓用戶重輸；一些較為嚴重或狀態(tài)不可恢復，但不屬于系統(tǒng)錯誤的錯誤，可以取消該操作。至于嚴重的系統(tǒng)錯誤，如磁盤扇區(qū)損傷不可讀寫，則只能退出系統(tǒng)。 對于一個大型實時交易軟件要想在使用過程中不出現(xiàn)這樣或那樣的問題幾乎是不可能的。這就需要在系統(tǒng)設計的時候充分考慮到各種錯誤情況。首先，可以對出錯的信息進行分類，這樣有助于認識和分解問題，然后可以根據相應的出錯情況提出相應的解決對策?？傊?，一個設計的好的系統(tǒng)能夠有效的對出錯情況進行處理。使軟件更加健壯。 3．3．5系統(tǒng)的實現(xiàn) 系統(tǒng)的實現(xiàn)是指實現(xiàn)在設計中發(fā)現(xiàn)的設計類和子系統(tǒng)，特別是將設計類實現(xiàn)為包含源代碼的文件構件。 本幣交易系統(tǒng)的實現(xiàn)是由14個程序員在客戶處完成的。在開始開發(fā)階段，每個程序員被按照各自的職責分配到不同的任務和時間期限。在項目開發(fā)的過程中，程序員被要求嚴格的按照設計文檔規(guī)定的內容來實現(xiàn)。每寫完一個模塊的代碼，項目組都會在項目經理的組織下對代碼進行review,以確保代碼的質量。由于本幣系統(tǒng)功能模塊比較多，實現(xiàn)起來有難度。為了不使進度拖延，項目組要求每位程序員都撰寫日報，這樣可以方便項目管理者跟蹤項目進度，及時解決在項目實際開發(fā)中遇到的問題。整個項目在開發(fā)過程中采用CVS作為版本控制軟件，所有代碼都在CVS的控制下進行開發(fā)，這樣使軟件開發(fā)過程中的版本得到了跟蹤。 從以上分析可以知道，在過程的這一階段，重點在于管理資源和控制操作，以便優(yōu)化成本、進度和質量。 3.3.5 小結 在大型實時交易軟件的開發(fā)過程的設計階段，應該注意使用基于構件的設計，構件是實現(xiàn)清晰功能的模塊。子系統(tǒng)提供了使用新的及現(xiàn)有構件定義體系結構的系統(tǒng)化方法。所以在清晰的定義了類以后，應該按子系統(tǒng)對類進行分組。同時，在設計中還應該注意把實現(xiàn)工作分為更易于管理的各個部分，并盡可能的讓各個組并發(fā)開發(fā)。 四 系統(tǒng)的測試 3.5.1單元測試 單元測試是針對軟件設計的最小單位——程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)每個程序模塊內部可能存在的差錯。單元測試是程序員的一項基本職責，程序員必須對自己所編寫的代碼保持認真負責的態(tài)度，這是也程序員的基本職業(yè)素質之一。同時單元測試能力也是程序員的一項基本能力，能力的高低直接影響到程序員的工作效率與軟件的質量。在編碼的過程中作單元測試，其花費是最小的，而回報卻特別優(yōu)厚的。在編碼的過程中考慮測試問題，得到的將是更優(yōu)質的代碼，因為在這時程序員對代碼應該做些什么了解得最清楚。如果不這樣做，又要花費許多時間，重新把它弄清楚。在本幣系統(tǒng)的開發(fā)過程中，項目組采用了兩種方法進行單元測試。在本幣系統(tǒng)的開發(fā)過程中，項目組采用了兩種方法進行單元測試： （1）人工靜態(tài)檢查 人工靜態(tài)檢查主要是為了保證代碼算法的邏輯正確性（盡量通過人工檢查發(fā)現(xiàn)代碼的邏輯錯誤）、清晰性、規(guī)范性、一致性、算法高效性。并盡可能的發(fā)現(xiàn)程序中沒有發(fā)現(xiàn)的錯誤。項目組要求每一位程序員在單元測試的時候，都嚴格檢查自己的代碼是否按照在項目開始時候制定的java代碼編寫規(guī)范來書寫。是否在每個模塊前面都要加上注釋，詳細說明這個模塊的作用，作者，傳入的參數，傳出的參數。在模塊完成后，在項目組內部先請其他程序員review。發(fā)現(xiàn)在代碼中可能存在的錯誤和問題。 （2）通過設計測試用例 通過設計測試用例，執(zhí)行待測程序來跟蹤比較實際結果與預期結果來發(fā)現(xiàn)錯誤。統(tǒng)計表明，使用人工靜態(tài)檢查法能夠有效的發(fā)現(xiàn)30%到70%的邏輯設計和編碼錯誤。但是代碼中仍會有大量的隱性錯誤無法通過視覺檢查發(fā)現(xiàn)，必須通過跟蹤調試法細心分析才能夠捕捉到。所以，動態(tài)跟蹤調試方法也成了單元測試的重點與難點。項目組要求程序員編寫測試用例來對自己的代碼進行單元測試。用例由輸入的數據和期望輸出的數據兩方面來構成。輸入數據應該包含合理條件下的輸入和不合理條件下的輸入。 （3） 測試類設計 由于在項目中一個模塊或一個方法（Method）并不是一個獨立的程序，在考慮測試它時要同時考慮它和外界的聯(lián)系，用些輔助模塊去模擬與所測模塊相聯(lián)系的其他模塊。這些輔助模塊分為驅動模塊和樁模塊兩種。所謂的驅動模塊相當于所測模塊的主程序。它接收測試數據，把這些數據傳送給所測模塊，最后再輸出實際測試結果。所謂的樁模塊用于代替所測模塊調用的子模塊。樁模塊可以做少量的數據操作，不需要把子模塊所有功能都帶進來，但不容許什么事情也不做。比如在報表打印模塊的單元測試中編寫了一個界面模塊和一個流數據傳輸模塊作為驅動模塊來進行測試。又比如在編寫界面上的菜單模塊時候，程序員寫了許多小的事件響應模塊來對菜單模塊進行測試。 3.5.2集成測試 在軟件項目中時常有這樣的情況發(fā)生，每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是，模塊相互調用時接口會引入許多新問題。例如，數據經過接口可能丟失；一個模塊對另一模塊可能造成不應有的影響；幾個子功能組合起來不能實現(xiàn)主功能；誤差不斷積累達到不可接受的程度；全局數據結構出現(xiàn)錯誤，等等。集成測試是組裝軟件的系統(tǒng)測試技術，按設計要求把通過單元測試的各個模塊組裝在一起之后，進行集成測試以便發(fā)現(xiàn)與接口有關的各種錯誤。由于大型實時交易系統(tǒng)這樣的大系統(tǒng)，它模塊眾多。因此如果把所有模塊全部組裝起來，然后進行整體測試容易出現(xiàn)混亂，因為在測試的時候可能發(fā)現(xiàn)一大堆的錯誤，而每個錯誤的定位和糾正卻非常的困難，并且如果改正一個錯誤可能會引起其他的錯誤，這樣新舊錯誤混雜，不利于測試的開展。因此本幣系統(tǒng)采用了自頂向下的集成方式，首先從主界面的主控模塊開始，把對該主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代。按照深度優(yōu)先的集成策略，每次只替代一個模塊。每集成一個模塊即進行測試。只有在該模塊通過測試后，才著手替換下一個模塊。為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地重復已做過的測試）。自頂向下集成的優(yōu)點在于能盡早地對程序的主要控制和決策機制進行檢驗，因此較早地發(fā)現(xiàn)錯誤。 在集成測試中尤其要注意關鍵模塊，所謂關鍵模塊一般都具有下述一個或多個特征如：對應幾條需求；具有高層控制功能；復雜、易出錯；有特殊的性能要求。關鍵模塊應盡早測試，并反復進行回歸測試。 3.5.3壓力測試 作為一個成熟的大型實時交易系統(tǒng)，進行壓力測試是必要的也是必須的。因為軟件必須保證在大量用戶并發(fā)訪問的時候也能夠正常工作。本幣交易系統(tǒng)是一個典型的三層C/S架構的交易系統(tǒng)（客戶端/應用服務器/數據庫管理系統(tǒng)），中間層是業(yè)務邏輯層，應用服務器處理所有的業(yè)務邏輯。項目組模擬實際應用的軟硬件環(huán)境，按照正常業(yè)務壓力估算值的1－10倍對系統(tǒng)進行測試，并讓系統(tǒng)長時間工作，以考察被測系統(tǒng)的可靠性，同時還要測試被測系統(tǒng)的響應時間。 在項目開發(fā)過程中，往往壓力測試會被忽略掉，這是很危險的，因為當大量用戶并發(fā)訪問系統(tǒng)的時候會耗費很多服務器資源，搞不好就會把服務器搞的當機。如果這樣那么造成的損失是無法估計的。因此，一定要做好系統(tǒng)的壓力測試，盡早發(fā)現(xiàn)存在的問題。 六 現(xiàn)有軟件開發(fā)過程的探討和比較 4.1大型交易軟件開發(fā)過程的優(yōu)劣 大型交易軟件開發(fā)過程具有很多長處：提高了團隊生產力，在迭代的開發(fā)過程、需求管理、基于組件的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面，針對所有關鍵的開發(fā)活動為每個開發(fā)成員提供了必要的準則、模板和工具指導，并確保全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構，為開發(fā)過程提供較大的通用性。但同時它也存在一些不足： 大型交易軟件開發(fā)過程只是一個開發(fā)過程，并沒有涵蓋軟件過程的全部內容，例如它缺少關于軟件運行和支持等方面的內容；此外，它沒有支持多項目的開發(fā)結構，這在一定程度上降低了在開發(fā)組織內大范圍實現(xiàn)重用的可能性?？梢哉f大型交易軟件開發(fā)過程是一個非常好的開端，但并不完美，在實際的應用中可以根據需要對其進行改進并可以用其他軟件過程的相關內容對大型交易軟件開發(fā)過程進行補充和完善。 4.2和其他軟件開發(fā)過程的比較 CMM（軟件過程能力成熟度模型），它是由卡內基－梅隆大學軟件工程研究院為了滿足美國聯(lián)邦政府評估軟件供應商能力的要求而制定的一個標準，它其實是一個模型，告訴了軟件開發(fā)者要做什么，而不是應該怎么做。因此，我們在軟件開發(fā)的時候，要達到CMM規(guī)定的標準，但這個標準卻不是一個軟件開發(fā)者可以去具體執(zhí)行的具體過程。 敏捷軟件開發(fā)過程了告訴軟件開發(fā)人員該怎么做，但沒有明確的指出做到以后該怎么樣改進。由于敏捷軟件開發(fā)過程不注重設計，強調短周期，簡單設計，快速開發(fā)。這對一個大型的實時交易系統(tǒng)來說是無法想象的。所以它也不太適合作為大型實時交易軟件的開發(fā)過程。 至于個人軟件過程，很容易看出來，它是立足于軟件工程師個體的軟件開發(fā)過程框架模型。它的一些模板，操作步驟，度量標準能夠幫助軟件工程師改進個人的軟件工程技巧，提高他們的開發(fā)效率和代碼質量。 通過上面的分析可以看出，大型實時交易軟件的開發(fā)過程是比較適合這一類軟件的開發(fā)的。 結束語 大型實時交易軟件的開發(fā)過程，在外匯交易中心本幣交易系統(tǒng)的開發(fā)中運用并取得了很大的成功。隨著企業(yè)信息化的不斷深入，客戶對大型實時交易軟件的需求也在不斷的增加。由于大型實時交易軟件功能復雜，模塊眾多，而且對性能和安全性都要求比較高。因此這絕不是靠幾個程序員幾天就能搞出來的。所以這時就迫切需要一套很完善的軟件開發(fā)過程來指導和規(guī)范軟件開發(fā)人員對項目的開發(fā)。以使開發(fā)團隊更有效率，軟件質量更佳。大型實時交易軟件的開發(fā)過程從需求分析，系統(tǒng)設計，系統(tǒng)實現(xiàn)，測試和部署，配置管理等幾個方面，詳細的定義了大型實時交易軟件從開始到項目發(fā)布的具體過程。同時該過程還采用迭代的手段進行開發(fā)，這樣降低了項目的風險，并且也把項目分成了幾個小的階段，有利于開發(fā)。 隨著在項目中不斷的使用和完善這個開發(fā)過程，相信這個開發(fā)過程必將更好的為開發(fā)大型實時交易系統(tǒng)服務。同時也將會擴展到很多類似的大型系統(tǒng)的開發(fā)。 謝辭 畢業(yè)已經近在眼前了，這篇論文業(yè)將結束我四年的大學生活。我只希望，這個句號能夠完美。在這篇論文的完成過程中得到了許多的幫助，所以在這里我要感謝很多人。 首先要感謝的是我的指導老師杜慶峰老師，他的淵博的知識和細心的指導，給了我的論文很大的啟發(fā)。在我求教他的時候，他非常認真的給我進行解答，而且?guī)椭抑С稣撐膬热萆系膯栴}，以他豐富的經驗來給我指出方向，使我受益非淺。沒有他的幫助，我的論文質量將大大的下降。 其次要感謝的是軟件學院的所有的老師，在他們的幫助和教導下，在軟件學院期間我獲得了許多軟件方面的知識，我才能夠有足夠的知識和思考能力來完成這篇論文。 還要感謝在實習期間曾經關心和幫助過我的同事，以及畢業(yè)設計期間乃至整個大學期間關心、幫助過我的老師和同學，謝謝你們。 最后，感謝那些曾經幫助過我的不能一一列出的所有的人，感謝大家！ 參考文獻 【1】 Rational Software Corporation. Rational Unified Process version 2000.02.1, 2000 【2】 Ivar Jacobson,Grady Booch,James Rumbaugh. The Unified Software Development Process, Addison Wesley, 1999.1 【3】 Scott W.Ambler. Enha ncing the Unified Process:Software Process for Large Scale,Mission-Critical Systems A Ronin Internatinal White Paper,2000.9 【4】 《實踐者的研究方法》，ROGER S.PRESSMAN，機械工業(yè)出版社 【5】 《軟件開發(fā)過程與案例》，陳宏剛等，清華大學出版社