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