【正文】 管理流程將反映出早期迭代計劃如何考慮架構(gòu)設(shè)計以及如何解決主要技術(shù)風險。圍繞多種架構(gòu)視圖的概念，以及架構(gòu)模式、設(shè)計規(guī)則， RUP 提供了用于說明架構(gòu)的模 板。利用該架構(gòu)可以降低性能、吞吐量、容量、可靠性等方面的風險，從而在構(gòu)建階段可以在一個穩(wěn)固的基礎(chǔ)上完成系統(tǒng)功能的全面添加，而不用擔心破壞系統(tǒng)。 在 RUP 的整個生命周期中，用例促使各工作流前后銜接，而開發(fā)活動是以架構(gòu)為中心展開的。一 方面，用例在實現(xiàn)時必須適合于架構(gòu)；另一方面，架構(gòu)必須預(yù)留空間以實現(xiàn)現(xiàn)在或?qū)硭行枰挠美?。只有平衡把握這兩個方面才能得到一個成功的產(chǎn)品。每個產(chǎn)品都是功能和形式的有機統(tǒng)一。這里4+1 指的是：邏輯視圖、實現(xiàn)視圖、過程視圖、部署視圖以及用例視圖。軟件架 構(gòu)側(cè)重于系統(tǒng)的重要結(jié)構(gòu)元素，如子系統(tǒng)、類、構(gòu)件和節(jié)點，以及這些元素通過接口實現(xiàn)的協(xié)作。 它刻畫了系統(tǒng)的整體設(shè)計，去掉了細節(jié)部分，突出了系統(tǒng)的重要特征。以架構(gòu)為中心意味著，開發(fā)工作在早期階段，就側(cè)重于建立能夠指導(dǎo)系統(tǒng)構(gòu)造的架構(gòu)模式，以保證不僅當前版本、而且產(chǎn)品的整個生命周期都有一個順利的發(fā)展。系統(tǒng)的不 同視角的展示就是視圖，所有的視圖合在一起展示了架構(gòu)。用例驅(qū)動意味著，在生產(chǎn)最終產(chǎn)品的每個階段，都能回顧一下為用戶實際上做了些什么，從而確保生產(chǎn)出來的產(chǎn)品能夠滿足用戶的真正需要。所以說， RUP 是一種以用例作為驅(qū)動的開發(fā)過程。 在測試階段，測試人員根據(jù)用例模型中的用例設(shè)計出測試用例，以此來驗證軟件產(chǎn)品是否符合用戶的需求。設(shè)計模型是實現(xiàn)的藍圖。分析模型和設(shè)計模型都是由類和說明如何實現(xiàn)用例的用例實現(xiàn)集合組成的。 需求階段，用例用于捕獲系統(tǒng)的用戶需求，將系 統(tǒng)的功能描述成一系列的行為， 并建立用例模型。 用例驅(qū)動，表明開發(fā)過程是沿著一個流：一系列從用例得到的工作流（需求、分析、設(shè)計、實現(xiàn)、測試）前進的，用例被確定、分析、設(shè)計、實現(xiàn)，最后用例又成為測試的基浙江工業(yè)大學(xué)碩士學(xué)位論文 17 礎(chǔ)?；谟美Ｐ停_發(fā)人員創(chuàng)建一系列的實現(xiàn)這些用例的分析、設(shè)計和實現(xiàn)模型，并審查每一個后續(xù)建立的模型與用例模型是否一致，測試人員測試系統(tǒng)以確定實現(xiàn)模型的構(gòu)件正確實現(xiàn)了用例。它獲取的是功能需求，所有的用例合在一起，構(gòu)成用例模型，它描述了系統(tǒng)的全部功能，代替了傳統(tǒng)的系統(tǒng)功能說明。 用例驅(qū)動方法自從被提出而又被吸收到 UML中以來，憑借用例模型簡單的圖形符號和接近自然語言的規(guī)格描述來獲取系統(tǒng)與不同用戶進行交互的情況，縮小了用戶、需求分析人員、開發(fā)人員之間的差距，并驅(qū)動著軟件開發(fā)的其它過程，得到了業(yè)界廣泛的接受和大規(guī)模的應(yīng)用。 用例驅(qū)動 用例幾乎普遍用來捕獲系統(tǒng)的需求，但在 RUP中，用例不只是捕獲需求的工具，它們還能夠驅(qū)動整個開發(fā)過程，是貫穿整個開發(fā)過程的線索。即具體的迭代工作，由用 例來確定目標，在架構(gòu)確定的結(jié)構(gòu)上進行 。就像一張三條腿的凳子，缺一條腿就會站不住，會倒下。 浙江工業(yè)大學(xué)碩士學(xué)位論文 16 第 3 章 軟件 開發(fā) 中 RUP 的 應(yīng)用特點 RUP 在應(yīng)用方面 的突出特點可以由用例驅(qū)動、以架構(gòu)為中心、 .迭代增量開發(fā)這三個關(guān)鍵詞來體現(xiàn)，這是 RUP 所特有的。其中動態(tài)組成從初始、細化、構(gòu)造和移交階段進行分析，靜態(tài)組成中討論了 RUP 的 6 個核心過程工作流和 3 個核心支持工作流，以及角色、活動和工件的關(guān)系。工件是由活動生產(chǎn)出來 的 —— 工件是活動的輸出，如制定《編碼規(guī)范》 ；而活動本身也可能以工件為輸入 —— 活動可能要求使用工件，如編碼活動要參考《編碼規(guī)范》 ； 另外一種關(guān)系是工件既是活動的輸入又是它的輸出 —— 活動修改工件，如修改《編碼規(guī)范》。為使整個軟件系統(tǒng)的開發(fā)易于管理，工件根據(jù)核心工作流程組織成各個集。 工件用于獲取和傳達項目信息。如計劃一個迭代，尋找用例和用例角色等都是一個活動，它們有著各自對應(yīng)的角色，項目經(jīng)理和系統(tǒng)分析員 。 活動，是 參與項目的角色為提供符合要求的結(jié)果而進行的工作 ， 具有明確的目的的工作單元， 其內(nèi)容通常表述為創(chuàng)建或更新某些 工件，例如一個模型、一個類或一個計劃。在 RUP 中，角色還定義了如何完成工作，所分派給角色的責任既包括某系列的活動，還包括成為產(chǎn)物的擁有者。 角色、活動和工件 角色 [39,40]，定義了個人或由若干人所組成小組的行為和責任。 環(huán)境工作流，描述為支持 項目而開發(fā)指南及在配置流程時所需的活動。目標是為計劃、執(zhí)行和監(jiān)控軟件開發(fā)項目提供可行性指導(dǎo) ； 為風險管理提供框架和環(huán)境 ；為組織提供過程管理和工具的支持。 Change Management)工作流 和環(huán)境 （ Environment）工作流 。 浙江工業(yè)大學(xué)碩士學(xué)位論文 14 業(yè)務(wù)建模、需求、 分析與設(shè)計、實現(xiàn)、測試工作流中產(chǎn)生的模型是各個過程成分中的產(chǎn)物，也是下一個過程成分的工作依據(jù)。 部署工作流， 是 為確保最終用戶可以正常使用軟件產(chǎn)品而進行的活動 (如軟件打包、系統(tǒng)配置等 )。 測試的任務(wù)是對系統(tǒng)進行測試和排錯，保證系統(tǒng)符合預(yù)定的要 求，獲得一個無錯誤的系統(tǒng)實現(xiàn)。 測試工作流，分 為 單元測試、階段測試和系統(tǒng)測試。 實現(xiàn)工作流， 它的 目的包括以層次化的子系統(tǒng)形式定義代碼的組織結(jié)構(gòu) ； 以組件的形式 (源文件、二進制文件、可執(zhí)行文件 )實現(xiàn)類和對象 ； 將開發(fā)出的組件作為單元進行測試 ； 將各實施人員 (或團隊 )完成的結(jié)果集成到可執(zhí)行系統(tǒng)中。設(shè)計類被組織成具有良好接口的設(shè)計包和設(shè)計子系統(tǒng)，而描述則體現(xiàn)了類的對象如何協(xié)同工作實現(xiàn)用例的功能。 分析設(shè)計的結(jié)果是一個設(shè)計模型和一個可選的分析模型。 分析與 設(shè)計工作流，將需求轉(zhuǎn)換為未來系統(tǒng)的設(shè)計，逐步開發(fā)強壯的系統(tǒng)構(gòu)架。 其主要任務(wù)是采集和評價系統(tǒng)的需求， 重 點是充分考慮系統(tǒng)的實用性。業(yè)務(wù)實體是分析設(shè) .計工作流程的一種輸入，用來確定設(shè)計模型中的實體類。業(yè)務(wù)建模的結(jié)果是建立一個業(yè)務(wù)用例模型和業(yè)務(wù)對象模型。 它 的目的在于 ： 了解目標組織的結(jié)構(gòu)及機制 ； 了解目標組織中當前存在的問題并確定改進的可能性 ； 確?？蛻簟⒆罱K用戶和開發(fā)人員就目標組織達成共識 ； 導(dǎo)出支持目標組織所需的系統(tǒng)需求。 Design） 、實現(xiàn) （ Implement） 、測試 (Test)、部署 （ Deployment)工作流是 RUP 過程中的核心過程工作流 （ Core Process Workflow） ，也是軟件系統(tǒng)開發(fā)的主要的開發(fā)活動。這 9個工作流 并不是順序執(zhí)行的， 而是 在項目中輪流被使用，在每一次迭代中以不同的重點和強度重復(fù)。每個工作流產(chǎn)生一些有價值的工件。它們分別描述了軟件開發(fā)過程“誰”“什么時候”“如何”“做”某事以及怎樣實現(xiàn) 某一特定的目標。 RUP 的靜態(tài)組成 在 RUP 生命周期的二維結(jié)構(gòu)圖的縱軸上表現(xiàn)了過程的靜態(tài)結(jié)構(gòu)。在各階段中，每個過程工作流各有不浙江工業(yè)大學(xué)碩士學(xué)位論文 12 同的重點。 RUP 的每個階段都由一個或多個連續(xù)的迭代組成。 移交階段的終點是第四個里程碑 ： 產(chǎn)品發(fā)布 (Product Release)里程碑。 移交階段 移交階段 [38,39]是系統(tǒng)正式投入運行前的階段，要達到的主要目標是確保軟件完全滿足用戶需求。構(gòu)造階段結(jié)束時是第三個重要的里程碑 ： 初始功能（ Initial Operational） 里程碑，它決定了產(chǎn)品是否可以在測試環(huán)境中進行部署。每一次的循環(huán)都包含了常規(guī)的軟件生命周期階段的活動 ： 分析、設(shè)計、實現(xiàn)、測試等。通過描述剩余的用例和其他需求、補充設(shè)計細節(jié)、實現(xiàn)并測試軟件來開發(fā)出系統(tǒng)的第一個可運行的 版本。這一階段的主要目標為 ： 1） 降低開發(fā)成本并實現(xiàn)部分的并行開發(fā)。此時，要檢驗詳細的系統(tǒng)目標和范圍、架構(gòu)的選擇以及主要風險的解決方案[14]。細化階段結(jié)束時是第二個重要的里程碑 ： 生命周期架構(gòu) （ Lifecycle Architecture）里程碑。 細化階段的主要任 務(wù)： 在初始階段的工作基礎(chǔ)上，收集更詳細的系統(tǒng)需求，進行高層次的系統(tǒng)分析和設(shè)計，確定系統(tǒng)的特征和基本的系統(tǒng)架構(gòu)，編制系統(tǒng)構(gòu)造計劃，確定開發(fā)所需要的活動和資源。 浙江工業(yè)大學(xué)碩士學(xué)位論文 11 3） 化解主要風險，制定更精確的時間表和費用估算。對系統(tǒng)的大部分需求達成更明確的認識。 細化階段 細化階段 [35,36]是建立系統(tǒng)架構(gòu)的基線，以便為構(gòu)造階段的主要設(shè)計和實施工作提供一個穩(wěn)定的基礎(chǔ)的 階段。初始階段結(jié)束時是第一個重要的里程碑 ： 生命周期目標 (Lifecycle objective)里程碑。 在 初始階段，項目組集中精力理解最初的需求，確定范圍并組織項目。 4） 了解與項目相關(guān)的成本、時間表和風險。 3） 制定至少一個可行的方案。 2） 確定系統(tǒng)的主要功能。確定系統(tǒng)的外貌、范圍和邊界。 如圖 23所示為各階段和里程碑的關(guān)系。其實，每個階段就是兩個主要里程碑之間的時間跨度。 軟件生命周期被分解為周期，每一個周期工作在產(chǎn)品新的一代上， RUP 將周期又劃分為初始 （ Inception） 、細化 （ Elaboration） 、構(gòu)造 （ Construction） 和移交 （ Transition） 四浙江工業(yè)大學(xué)碩士學(xué)位論文 10 個連續(xù)的階段 [12,14,23]。 RUP 的動態(tài)組成 在 RUP 生命周期的二維結(jié)構(gòu)圖 （圖 22） 的橫軸上包含階段和迭代兩項內(nèi)容，這兩項即是開發(fā)過程沿時間的動態(tài)組織結(jié)構(gòu) [10]。這些隨后的周期成為演進周期。盡管不同的項目有很大的不同，但一個中等規(guī)模項目的典型初始開發(fā)周期應(yīng)預(yù)先考慮到工作量和進度間的分配 ，如表 21 所示 ： 表 21 項目工作量和進度分配表 起始 細化 構(gòu)建 移交 工作量 ~5% 20% 65% 10% 進度 10% 30% 50% 10% 通過這四個階段就是 一個開發(fā)周期，每次經(jīng)過這四個階段就會產(chǎn)生一代軟件?？v軸以內(nèi)容來組織為自然 的邏輯活動，體現(xiàn)開發(fā)過程的靜態(tài)結(jié)構(gòu)，用來描述它的術(shù)語主要包括活動（ Activity）、產(chǎn)物（ Artifact）、工人（ Worker）和工作流（ Workflow） ， 縱軸表現(xiàn)了過程的靜態(tài)結(jié)構(gòu)。 上圖中 橫軸代表了制訂開發(fā)過程時的時間，體現(xiàn)了過程的動態(tài)結(jié)構(gòu)。 圖 22 RUP 生命周期的二維結(jié)構(gòu) [1] 瀑布模型強調(diào)開發(fā)的階段性、早期計劃及需求調(diào)查等，它在降 低軟件的復(fù)雜度、促進浙江工業(yè)大學(xué)碩士學(xué)位論文 9 軟件開發(fā)工程化方面有顯著的作用。 而 RUP 的生命周期可用二維結(jié)構(gòu)來描述，如圖 22 所示 ，該圖的一次循環(huán)代表了統(tǒng)一過程的一次生命周期。 傳統(tǒng)的軟件開發(fā)模型 (如瀑布模型 )通常是一個一維的模型， 開發(fā)工作劃分為多個連續(xù)的階段 [1,7]。其主要特點包括： 迭代地開發(fā)軟件； 管理需求； 應(yīng)用基于構(gòu)件的 架構(gòu) ； 為軟件建立可視化的模型； 不斷驗證軟件質(zhì)量； 控制軟件的變更。 RUP 的核心思想在于：它是以 用例（ Use Case）為驅(qū)動，以 架構(gòu)為中 心的迭代化開發(fā)浙江工業(yè)大學(xué)碩士學(xué)位論文 8 過程。 RUP 又是一個通用框架，各個組織可根據(jù)自身情況及項目規(guī)模等對 RUP進行裁剪和改進，以制定出合乎需要的軟件工程過程 [12]。 浙江工業(yè)大學(xué)碩士學(xué)位論文 7 第 2 章 RUP 的組織結(jié)構(gòu) RUP 概述 RUP（ Rational Unified Process）是由 Rational公司開發(fā)的一種軟件工程過程，主要由 Ivar Jacobson 的 The Objectory Approach和 The Rational Approach發(fā)展而來 ， 是文檔化的軟件工程產(chǎn)品 [10,11,13]。 第 6 章 介紹了 行政事業(yè)性單位收費票據(jù)系統(tǒng) 的實現(xiàn)，包括開發(fā)工具選擇、部分實現(xiàn)技術(shù) 和 主要功能實現(xiàn)界面 等。 第 5 章 著重講述了基于 RUP 的 行政事業(yè)性單位收費票據(jù)系統(tǒng) 的設(shè)計過程。接著簡單介紹了 UML 統(tǒng)一建模語言， 并說明其與 RUP 密不可分的關(guān)系， 最后 描述了對 RUP 過程 的裁剪研究。 第 3 章是 主要 是對軟件開發(fā)中 RUP 的應(yīng)用特點進行研究。 第 2 章 介紹了 RUP 的組織結(jié)構(gòu)。 最終選用合適的 開發(fā)工具 和技術(shù)將行政事業(yè)性單位收費票據(jù)系統(tǒng)完整 實現(xiàn)，并投入使用。 分析設(shè)計了“ 行政事業(yè)性單位收費票據(jù)系統(tǒng) ”的整體框架和系統(tǒng)軟件功能模塊。 根據(jù)實際項目的具體情況，對 RUP 的通用框架進行裁剪，使其更好地服務(wù)于軟件開發(fā)過程。理論研究和實際運用相結(jié)合，通過對 RUP 的理論探討及如何運用到實際開發(fā)工作中的方法研究，結(jié)合相應(yīng)的科研課題 —— 行政事業(yè)性單位收費票據(jù)系統(tǒng) ，運用RUP 架構(gòu) 整個系統(tǒng)核心用例的軟件模型。 因此，本文選取的課題，希望對 RUP 方法及其應(yīng)用進行深入研究和探討，并以 行政事業(yè)性單位收費票據(jù)系統(tǒng) 的實際開發(fā)為例，按照 RUP 安排該軟件系統(tǒng)的開發(fā)過程，用UML 來描述系統(tǒng)分析和設(shè)計的成果，這樣從需求分析開始，到最終系統(tǒng)的實現(xiàn)，便成功地完成了該項目的整個開發(fā)過程。但 OPEN 和 OOSP 共同的缺點在于它們在市場營銷方面做得不夠，在市場上缺乏