【導讀】所取得的研究成果。除文中已經(jīng)加以標注引用的內(nèi)容外，本論文不包含其他個人或。學位證書而使用過的材料。對本文的研究作出重要貢獻的個人和集體，均已在文中。以明確方式標明。本人承擔本聲明的法律責任。并向國家有關(guān)部門或機構(gòu)送交論文的復印件和電子版，允許論文被查閱和借閱。索，可以采用影印、縮印或掃描等復制手段保存和匯編本學位論文。過去軟件生命周期方法一直占據(jù)著主導地位，但近年。流，由此面向?qū)ο蟮能浖_發(fā)模式也隨即成為研究的重點。它汲取了面向?qū)ο筌浖こ填I(lǐng)域多年來的優(yōu)秀研究成果,應(yīng)用統(tǒng)一建模語言。進行可視化建模,為面向?qū)ο蟮能浖到y(tǒng)的開發(fā)提供了方法論的指導。開發(fā)過程作為指導，以提高質(zhì)量、開發(fā)效率和復用性等。本文應(yīng)用RUP思想為指導，結(jié)合。系統(tǒng)的詳細需求。

　　

【正文】 。 工作流 ，是產(chǎn)生具有可觀察結(jié)果的活動序列。每個工作 流產(chǎn)生一些有價值的工件。RUP 共有 9 個工作流 ，其中分為 6 個核心過 程工作流 ： 業(yè)務(wù)建模、需求、分析和設(shè)計、實現(xiàn)、測試、部署工作流 ； 3個核心支持工作流 ： 項目管理、配置和變更控制、環(huán)境工作流 [16,17,18]。這 9個工作流 并不是順序執(zhí)行的， 而是 在項目中輪流被使用，在每一次迭代中以不同的重點和強度重復。核心工作流的迭代開發(fā)循環(huán)模型 如圖 24 所示： 圖 24 核心工作流的迭代開發(fā)循環(huán) 核心過程工作流 業(yè)務(wù)建模 （ Business Modeling）、需求（ Requirements)、分析與設(shè)計 （ Analysis amp。 Design） 、實現(xiàn) （ Implement） 、測試 (Test)、部署 （ Deployment)工作流是 RUP 過程中的核心過程工作流 （ Core Process Workflow） ，也是軟件系統(tǒng)開發(fā)的主要的開發(fā)活動。各工作流的簡單介紹如下 ： 浙江工業(yè)大學碩士學位論文 13 業(yè)務(wù)建模工作流 [23,41,42,43]，說明如何擬定新目標組織的前景，并基于前景來確定該組織在業(yè)務(wù)用例模型和業(yè)務(wù)對象模型中的流程、角色以及職責。 它 的目的在于 ： 了解目標組織的結(jié)構(gòu)及機制 ； 了解目標組織中當前存在的問題并確定改進的可能性 ； 確?？蛻?、最終用戶 和開發(fā)人員就目標組織達成共識 ； 導出支持目標組織所需的系統(tǒng)需求。其主要任務(wù)是對將來使用該系 統(tǒng)的組織機構(gòu)或企業(yè)進行評估； 理解它們的需要以及要求未來系統(tǒng)解決的問題。業(yè)務(wù)建模的結(jié)果是建立一個業(yè)務(wù)用例模型和業(yè)務(wù)對象模型。業(yè)務(wù)模型是需求工作流的一種重要輸入，用來了解對系統(tǒng)的需求。業(yè)務(wù)實體是分析設(shè) .計工作流程的一種輸入，用來確定設(shè)計模型中的實體類。 需求工作流，主要目標是描述用戶的需求，并做到與用戶和其他涉眾在系統(tǒng)的工作內(nèi)容方面達成且保持一致，使系統(tǒng)開發(fā)人員能夠更清楚地了解系統(tǒng)需求，定義系統(tǒng)邊界，定義系統(tǒng)的用戶界面。 其主要任務(wù)是采集和評價系統(tǒng)的需求， 重 點是充分考慮系統(tǒng)的實用性。需求分析的結(jié)果可以用一個用例模型表達，模型中的活動者代表外部的與系統(tǒng)交互的單元 (人或外部系統(tǒng) )，用例代表交互的事務(wù)序列，它為活動者提供可度量的結(jié)果值。 分析與 設(shè)計工作流，將需求轉(zhuǎn)換為未來系統(tǒng)的設(shè)計，逐步開發(fā)強壯的系統(tǒng)構(gòu)架。使設(shè)計適合于實現(xiàn)環(huán)境，最后得到一個為軟件特定環(huán)境支持的詳細系統(tǒng)結(jié)構(gòu)描述。 分析設(shè)計的結(jié)果是一個設(shè)計模型和一個可選的分析模型。設(shè)計模型是源代碼的抽象，由設(shè)計類和一些描述組成。設(shè)計類被組織成具有良好接口的設(shè)計包和設(shè)計子系統(tǒng)，而描述 則體現(xiàn)了類的對象如何協(xié)同工作實現(xiàn)用例的功能。設(shè)計活動以架構(gòu)設(shè)計為中心，架構(gòu)由若干模型來表達。 實現(xiàn)工作流， 它的 目的包括以層次化的子系統(tǒng)形式定義代碼的組織結(jié)構(gòu) ； 以組件的形式 (源文件、二進制文件、可執(zhí)行文件 )實現(xiàn)類和對象 ； 將開發(fā)出的組件作為單元進行測試 ； 將各實施人員 (或團隊 )完成的結(jié)果集成到可執(zhí)行系統(tǒng)中。實現(xiàn)的任務(wù)是在預定的環(huán)境中實現(xiàn)系統(tǒng)，生成系統(tǒng)的源代碼、可執(zhí)行程序和相應(yīng)的軟件文檔，建立一個可執(zhí)行的系統(tǒng)。 測試工作流，分 為 單元測試、階段測試和系統(tǒng)測試。主要目標是核實對象之間的交互及所有構(gòu)件是否正確集成 ，確定缺陷并確保在部署軟件之前將缺陷解決。 測試的任務(wù)是對系統(tǒng)進行測試和排錯，保證系統(tǒng)符合預定的要求，獲得一個無錯誤的系統(tǒng)實現(xiàn)。測試的結(jié)果將確認所完成的系統(tǒng)可以交付使用。 部署工作流， 是 為確保最終用戶可以正常使用軟件產(chǎn)品而進行的活動 (如軟件打包、系統(tǒng)配置等 )。 其主要任務(wù)是將開發(fā)的產(chǎn)品提交給用戶，并作相應(yīng)的系統(tǒng)配置。 浙江工業(yè)大學碩士學位論文 14 業(yè)務(wù)建模、需求、 分析與設(shè)計、實現(xiàn)、測試工作流中產(chǎn)生的模型是各個過程成分中的產(chǎn)物，也是下一個過程成分的工作依據(jù)。 核心支持工作流 核心支持工作流 (Core Support Workflow)包括 : 項目管理 （ Project Management）工作流、配置和 變更管理 (Configuration amp。 Change Management)工作流 和環(huán)境 （ Environment）工作流 。以下做簡要說明： 項目管理工作流，描述如何控制軟件項目組內(nèi)部的各個成員的相互關(guān)聯(lián)的工作。目標是為計劃、執(zhí)行和監(jiān)控軟件開發(fā)項目提供可行性指導 ； 為風險管理提供框架和環(huán)境 ；為組織提供過程管理和工具的支持。 配置和 變更控制工作流， 描述了如何控制軟件項目組內(nèi)部 各個成員的相互關(guān)聯(lián)的工作 (如避免重復無效的軟件修 改，多版本并發(fā)開發(fā)的協(xié)調(diào)和控制等等 )，以控制和維護項目制品的完整性。 環(huán)境工作流，描述為支持項目而開發(fā)指南及在配置流程時所需的活動。主要目的是為軟件開發(fā)組織提供軟件開發(fā)環(huán)境 (流程和工具 )。 角色、活動和工件 角色 [39,40]，定義了個人或由若干人所組成小組的行為和責任。 需要承擔一定的職責和具備相應(yīng)的能力，諸如執(zhí)行某些活動和開發(fā)某些工件。在 RUP 中，角色還定義了如何完成工作，所分派給角色的責任既包括某系列的活動，還包括成為產(chǎn)物的擁有者。 角色通過執(zhí)行某些活動完成特定工件。 活動，是 參與項目 的角色為提供符合要求的結(jié)果而進行的工作 ， 具有明確的目的的工作單元， 其內(nèi)容通常表述為創(chuàng)建或更新某些工件，例如一個模型、一個類或一個計劃。每個活動都要被分配給具體的角色。如計劃一個迭代，尋找用例和用例角色等都是一個活動，它們有著各自對應(yīng)的角色，項目經(jīng)理和系統(tǒng)分析員 。 工件 [13,18]，是項目期間由活動生成并使用的中間或最終產(chǎn)物。 工件用于獲取和傳達項目信息。工件可以是 ： 文檔，如商業(yè)理由或軟件架構(gòu)文檔 ； 模型，如用例模型或設(shè)計模型 ；模型元素，即模型中的元素，如類或子系統(tǒng)。為使整個軟件系統(tǒng)的開發(fā)易于管理，工件根據(jù)核心 工作流程組織成各個集。 角色、活動和工件 的關(guān)系如圖 25所示 ： 浙江工業(yè)大學碩士學位論文 15 圖 25 角色、活動和 工件的關(guān)系 角色的職責，具體體現(xiàn)在它 執(zhí)行活動和負責工件上。工件是由活動生產(chǎn)出來 的 —— 工件是活動的輸出，如制定《編碼規(guī)范》 ；而活動本身也可能以工件為輸入 —— 活動可能要求使用工件，如編碼活動要參考《編碼規(guī)范》 ； 另外一種關(guān)系是工件既是活動的輸入又是它的輸出 —— 活動修改工件，如修改《編碼規(guī)范》。 小結(jié) 本章主要介紹了統(tǒng)一軟件過程 RUP 的組織結(jié)構(gòu) ， 首先 給出簡要的 RUP 概述；接著介紹了 RUP 的生命周期 ，給出一個二維模 型，并與傳統(tǒng)的瀑布模型相比較；再次根據(jù)所得RUP 生命周期的二維模型，從橫軸、縱軸角度分別闡述了它的動態(tài)組成和靜態(tài)組成。其中動態(tài)組成從初始、細化、構(gòu)造和移交階段進行分析，靜態(tài)組成中討論了 RUP 的 6 個核心過程工作流和 3 個核心支持工作流，以及角色、活動和工件的關(guān)系。 本章是整個論文研究內(nèi)容的理論支撐。 浙江工業(yè)大學碩士學位論文 16 第 3 章 軟件 開發(fā) 中 RUP 的 應(yīng)用特點 RUP 在應(yīng)用方面 的突出特點可以由用例驅(qū)動、以架構(gòu)為中心、 .迭代增量開發(fā)這三個關(guān)鍵詞來體現(xiàn)，這是 RUP 所特有的。 去掉三個其中 任何一個，都會嚴重地降低統(tǒng)一 軟件過程的價值。就像一張三條腿的凳子，缺一條腿就會站不住，會倒下。 架構(gòu) 提供一種結(jié)構(gòu)來指導迭代過程中的工作，用例則確定了每一次迭代的目標。即具體的迭代工作，由用 例來確定目標，在架構(gòu)確定的結(jié)構(gòu)上進行 。 但由于各種軟件項目的具體實施環(huán)境、開發(fā)難度、技術(shù)條件、系統(tǒng)需求的差異，在實際工作中，不可能完全照搬 RUP 的全部理論，因此開發(fā)者必須結(jié)合實際， 對 RUP 進行必要的裁剪，從而讓 RUP 更好地服務(wù)于軟件開發(fā)過程。 用例驅(qū)動 用例幾乎普遍用來捕獲系統(tǒng)的需求，但在 RUP中，用例不只是捕獲需求的工具，它們還 能夠驅(qū)動整個開發(fā)過程，是貫穿整個開發(fā)過程的線索。通過用例的驅(qū)動，我們可以比較清楚的看一個軟件系統(tǒng)是如何實現(xiàn)其功能的 。 用例驅(qū)動方法自從被提出而又被吸收到 UML中以來，憑借用例模型簡單的圖形符號和接近自然語言的規(guī)格描述來獲取系統(tǒng)與不同用戶進行交互的情況，縮小了用戶、需求分析人員、開發(fā)人員之間的差距，并驅(qū)動著軟件開發(fā)的其它過程，得到了業(yè)界廣泛的接受和大規(guī)模的應(yīng)用。 用例是用戶與系統(tǒng)的交互的動作集合，能夠向用戶提供有價值的結(jié)果。它獲取的是功能需求，所有的用例合在一起，構(gòu)成用例模型，它描述了系統(tǒng)的全部功能，代替了傳 統(tǒng)的系統(tǒng)功能說明。然而，用例不僅是一種確定系統(tǒng)需求的工具，它還能驅(qū)動系統(tǒng)分析、設(shè)計、實現(xiàn)、測試的進行，即用例驅(qū)動整個的軟件開發(fā)過程?；谟美Ｐ?，開發(fā)人員創(chuàng)建一系列的實現(xiàn)這些用例的分析、設(shè)計和實現(xiàn)模型，并審查每一個后續(xù)建立的模型與用例模型是否一致，測試人員測試系統(tǒng)以確定實現(xiàn)模型的構(gòu)件正確實現(xiàn)了用例。因此，用例不僅啟動了開發(fā)過程，而且使整個開發(fā)過程渾然一體。 用例驅(qū)動，表明開發(fā)過程是沿著一個流：一系列從用例得到的工作流（需求、分析、設(shè)計、實現(xiàn)、測試）前進的，用例被確定、分析、設(shè)計、實現(xiàn)，最后用例又成為測試的基浙江工業(yè)大學碩士學位論文 17 礎(chǔ)。 用例在各個階段中擔負著各種角色，起著不同的作用 。 需求階段，用例用于捕獲系統(tǒng)的用戶需求，將系統(tǒng)的功能描述成一系列的行為， 并建立用例模型。 分析與設(shè)計階段 ，用例模型經(jīng)由分析模型轉(zhuǎn)化為設(shè)計模型。分析模型和設(shè)計模型都是由類和說明如何實現(xiàn)用例的用例實現(xiàn)集合組成的。分析模型是需求的詳細的規(guī)格說明，將需求用例的事件流，用概念性的類之間的協(xié)作來重新轉(zhuǎn)述，是一個概念模型。設(shè)計模型是實現(xiàn)的藍圖。 在實施階段，根據(jù)設(shè)計模型中的設(shè)計類，建立實施模型 并將設(shè)計類轉(zhuǎn)化為可執(zhí)行的代碼。 在測試階段，測試人員根據(jù)用例模型中的用例設(shè)計出 測試用例，以此來驗證軟件產(chǎn)品是否符合用戶的需求。 由此可見，用例不但貫穿于整個開發(fā)過程的各個階段，同時它還把所有階段捆綁在一起，使各個階段成為緊密聯(lián)系的一個整體。所以說， RUP 是一種以用例作為驅(qū)動的開發(fā)過程。 RUP 的用例驅(qū)動模型 如圖 31 所示： 圖 31 RUP 用例驅(qū)動 模型 用例與系統(tǒng)架構(gòu)是協(xié)調(diào)發(fā)展的，一部分用例驅(qū)動系統(tǒng)架構(gòu)，系統(tǒng)架構(gòu)又反過來影響另一部分用例的選擇。用例驅(qū)動意味著，在生產(chǎn)最終產(chǎn)品的每個階段，都能回顧一下為用戶實際上做了些什么，從而確保生產(chǎn)出來的產(chǎn)品能夠滿足用戶的真正需要。 浙江工業(yè)大學碩士學位論文 18 以架構(gòu)為中心 軟件系統(tǒng)是個單一的實體，從不同的視角展示它有助于更好地理解系統(tǒng)的設(shè)計。系統(tǒng)的不同視角的展示就是視圖，所有的視圖合在一起展示了架構(gòu)。我們可以通過架構(gòu)來方便地理解系統(tǒng)，可以通過架構(gòu)來組織并行高效的開發(fā)，可以通過架構(gòu)來更好地重用，可以通過架構(gòu)來方便地進化系統(tǒng)。以架構(gòu)為中心意味著，開發(fā)工作在早期階段，就側(cè)重于建立能夠指導系統(tǒng)構(gòu)造的架構(gòu)模式，以保證不僅當前版本、而且產(chǎn)品的整個生命周期都有一個順利的發(fā)展。 軟件基本架構(gòu)這個概念體現(xiàn)了系統(tǒng)中最重要的靜態(tài)和動態(tài)特征。 它刻畫了系統(tǒng)的整體設(shè)計，去掉了細節(jié)部分， 突出了系統(tǒng)的重要特征。 架構(gòu)時架構(gòu)設(shè)計師在構(gòu)件描述中詳細說明的內(nèi)容，架構(gòu)可以控制系統(tǒng)的開發(fā)。軟件架構(gòu)側(cè)重于系統(tǒng)的重要結(jié)構(gòu)元素，如子系統(tǒng)、類、構(gòu)件和節(jié)點，以及這些元素通過接口實現(xiàn)的協(xié)作。 4+1 場景模型呈現(xiàn)了 RUP 架構(gòu)，軟件架構(gòu)設(shè)計師和開發(fā)人員發(fā)現(xiàn)從不同視角展示該系統(tǒng)有助于更好地理解其設(shè)計。這里4+1 指的是：邏輯視圖、實現(xiàn)視圖、過程視圖、部署視圖以及用例視圖。如圖 32 所示： 圖 32 RUP 架構(gòu) 描述 用例和架構(gòu)之間是相互影響的。每個產(chǎn)品都是功能和形式的有機統(tǒng)一。僅僅只有其中之一，都是不完整的。只有平衡 把握這兩個方面才能得到一個成功的產(chǎn)品。在這種情況下，功能與用例相對應(yīng)，而形式與基本架構(gòu)相對應(yīng)。一方面，用例在實現(xiàn)時必須適合于架構(gòu)；另一方面，架構(gòu)必須預留空間以實現(xiàn)現(xiàn)在或?qū)硭行枰挠美?。事實上，架?gòu)和用例必浙江工業(yè)大學碩士學位論文 19 須并行進化。 在 RUP 的整個生命周期中，用例促使各工作流前后銜接，而開發(fā)活動是以架構(gòu)為中心展開的。流程初期迭代的重點在于生成并驗證一個架構(gòu)，它在最初開發(fā)周期中采用個可執(zhí)行架構(gòu)原型的形式，并在以后的迭代中逐漸演變成最終系統(tǒng)。利用該架構(gòu)可以降低性能、吞吐量、容量、可靠性等方面的風險，從而在構(gòu)建階段可以在一個 穩(wěn)固的基礎(chǔ)上完成系統(tǒng)功能的全面添加，而不用擔心破壞系統(tǒng)。 RUP 提供了一種有條不紊的系統(tǒng)化方法來設(shè)計、開發(fā)和驗證一個架構(gòu)。圍繞多種架構(gòu)視圖的概念，以及架構(gòu)模式、設(shè)計規(guī)則， RUP 提供了用于說明架構(gòu)的模 板。設(shè)計工作流程包括一些特定的活動，目的在于確定架構(gòu)約束、 在架構(gòu)方面具有重要意義的元素以及有關(guān)如何選擇架構(gòu)的指南。管理流程將反映出早期迭代計劃如何考慮架構(gòu)設(shè)計以及如何解決主要技術(shù)風險。 迭代增量開發(fā) 開發(fā)一個商業(yè)軟件產(chǎn)品是一項艱巨的工作，可能持續(xù)幾個月、一年甚至更長時間。因此，將一項工作分解成若干更小 的部分或若干小項目是切合實際的。每個小項目是指能產(chǎn)生一個增量的一次迭代。