【正文】 可。它確認(rèn)了一個(gè)經(jīng)常被忽略的事實(shí)，即用戶(hù)需求無(wú)法預(yù)先清晰地說(shuō)明，而是在開(kāi)發(fā)過(guò)程之中不斷地被精確化。加快整個(gè)項(xiàng)目的進(jìn)展。處理關(guān)鍵風(fēng)險(xiǎn)的時(shí)間開(kāi)銷(xiāo)位于進(jìn)度表的前期，此時(shí)，開(kāi)發(fā)人員比較從容。如果是重復(fù)某次迭代過(guò)程，損失的只是一次迭代，而不是全部以前的迭代。在后期，增量通常都是添加性的。當(dāng)然，一項(xiàng)增量并不一定是添加性的。后續(xù)迭代是建立在前導(dǎo)迭代完成的產(chǎn)品之上的。在細(xì)化階段，迭代的目的是進(jìn)行架構(gòu)基線(xiàn)的開(kāi)發(fā)。早期迭代側(cè)重于了解問(wèn)題和技術(shù)。如果一次迭代達(dá)到了目標(biāo)，開(kāi)發(fā)工作便可以進(jìn)入下一次迭代。在一次迭代之中，包括如圖 33 所示的七項(xiàng)活動(dòng)。每個(gè)小項(xiàng)目是指能產(chǎn)生一個(gè)增量的一次迭代。 迭代增量開(kāi)發(fā)開(kāi)發(fā)一個(gè)商業(yè)軟件產(chǎn)品是一項(xiàng)艱巨的工作，可能持續(xù)幾個(gè)月、一年甚至更長(zhǎng)時(shí)間。設(shè)計(jì)工作流程包括一些特定的活動(dòng)，目的在于確定架構(gòu)約束、在架構(gòu)方面具有重要意義的元素以及有關(guān)如何選擇架構(gòu)的指南。RUP 提供了一種有條不紊的系統(tǒng)化方法來(lái)設(shè)計(jì)、開(kāi)發(fā)和驗(yàn)證一個(gè)架構(gòu)。流程初期迭代的重點(diǎn)在于生成并驗(yàn)證一個(gè)架構(gòu)，它在最初開(kāi)發(fā)周期中采用個(gè)可執(zhí)行架構(gòu)原型的形式，并在以后的迭代中逐漸演變成最終系統(tǒng)。事實(shí)上，架構(gòu)和用例必須并行進(jìn)化。在這種情況下，功能與用例相對(duì)應(yīng)，而形式與基本架構(gòu)相對(duì)應(yīng)。僅僅只有其中之一，都是不完整的。如圖 32 所示：圖 32 RUP 架構(gòu)描述浙江工業(yè)大學(xué)碩士學(xué)位論文 19 用例和架構(gòu)之間是相互影響的。4+1 場(chǎng)景模型呈現(xiàn)了 RUP架構(gòu)，軟件架構(gòu)設(shè)計(jì)師和開(kāi)發(fā)人員發(fā)現(xiàn)從不同視角展示該系統(tǒng)有助于更好地理解其設(shè)計(jì)。架構(gòu)時(shí)架構(gòu)設(shè)計(jì)師在構(gòu)件描述中詳細(xì)說(shuō)明的內(nèi)容，架構(gòu)可以控制系統(tǒng)的開(kāi)發(fā)。軟件基本架構(gòu)這個(gè)概念體現(xiàn)了系統(tǒng)中最重要的靜態(tài)和動(dòng)態(tài)特征。我們可以通過(guò)架構(gòu)來(lái)方便地理解系統(tǒng)，可以通過(guò)架構(gòu)來(lái)組織并行高效的開(kāi)發(fā)，可以通過(guò)架構(gòu)來(lái)更好地重用，可以通過(guò)架構(gòu)來(lái)方便地進(jìn)化系統(tǒng)。 以架構(gòu)為中心軟件系統(tǒng)是個(gè)單一的實(shí)體，從不同的視角展示它有助于更好地理解系統(tǒng)的設(shè)計(jì)。RUP 的用例驅(qū)動(dòng)模型如圖 31 所示：圖 31 RUP 用例驅(qū)動(dòng)模型用例與系統(tǒng)架構(gòu)是協(xié)調(diào)發(fā)展的，一部分用例驅(qū)動(dòng)系統(tǒng)架構(gòu)，系統(tǒng)架構(gòu)又反過(guò)來(lái)影響浙江工業(yè)大學(xué)碩士學(xué)位論文 18 另一部分用例的選擇。由此可見(jiàn)，用例不但貫穿于整個(gè)開(kāi)發(fā)過(guò)程的各個(gè)階段，同時(shí)它還把所有階段捆綁在一起，使各個(gè)階段成為緊密聯(lián)系的一個(gè)整體。在實(shí)施階段，根據(jù)設(shè)計(jì)模型中的設(shè)計(jì)類(lèi)，建立實(shí)施模型并將設(shè)計(jì)類(lèi)轉(zhuǎn)化為可執(zhí)行的代碼。分析模型是需求的詳細(xì)的規(guī)格說(shuō)明，將需求用例的事件流，用概念性的類(lèi)之間的協(xié)作來(lái)重新轉(zhuǎn)述，是一個(gè)概念模型。分析與設(shè)計(jì)階段，用例模型經(jīng)由分析模型轉(zhuǎn)化為設(shè)計(jì)模型。用例在各個(gè)階段中擔(dān)負(fù)著各種角色，起著不同的作用。因此，用例不僅啟動(dòng)了開(kāi)發(fā)過(guò)程，而且使整個(gè)開(kāi)發(fā)過(guò)程渾然一體。然而，用例不僅是一種確定系統(tǒng)需求的工具，它還能驅(qū)動(dòng)系統(tǒng)分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試的進(jìn)行，即用例驅(qū)動(dòng)整個(gè)的軟件開(kāi)發(fā)過(guò)程。用例是用戶(hù)與系統(tǒng)的交互的動(dòng)作集合，能夠向用戶(hù)提供有價(jià)值的結(jié)果。通過(guò)用例的驅(qū)動(dòng)，我們可以比較清楚的看一個(gè)軟件系統(tǒng)是如何實(shí)現(xiàn)其功能的。但由于各種軟件項(xiàng)目的具體實(shí)施環(huán)境、開(kāi)發(fā)難度、技術(shù)條件、系統(tǒng)需求的差異，在實(shí)際工作中，不可能完全照搬 RUP 的全部理論，因此開(kāi)發(fā)者必須結(jié)合實(shí)際，對(duì) RUP 進(jìn)行必要的裁剪，從而讓 RUP 更好地服務(wù)于軟件開(kāi)發(fā)過(guò)程。架構(gòu)提供一種結(jié)構(gòu)來(lái)指導(dǎo)迭代過(guò)程中的工作，用例則確定了每一次迭代的目標(biāo)。去掉三個(gè)其中任何一個(gè)，都會(huì)嚴(yán)重地降低統(tǒng)一軟件過(guò)程的價(jià)值。本章是整個(gè)論文研究?jī)?nèi)容的理論支撐。 小結(jié)本章主要介紹了統(tǒng)一軟件過(guò)程 RUP 的組織結(jié)構(gòu)，首先給出簡(jiǎn)要的 RUP 概述；接著介紹了 RUP 的生命周期，給出一個(gè)二維模型，并與傳統(tǒng)的瀑布模型相比較；再次根據(jù)所得RUP 生命周期的二維模型，從橫軸、縱軸角度分別闡述了它的動(dòng)態(tài)組成和靜態(tài)組成。角色、活動(dòng)和工件的關(guān)系如圖 25 所示：圖 25 角色、活動(dòng)和工件的關(guān)系角色的職責(zé)，具體體現(xiàn)在它執(zhí)行活動(dòng)和負(fù)責(zé)工件上。工件可以是：文檔，如商業(yè)理由或軟件架構(gòu)文檔；模型，如用例模型或設(shè)計(jì)模型；模型元素，即模型中的元素，如類(lèi)或子系統(tǒng)。工件 [13,18]，是項(xiàng)目期間由活動(dòng)生成并使用的中間或最終產(chǎn)物。每個(gè)活動(dòng)都要被分配給具體的角色。角色通過(guò)執(zhí)行某些活動(dòng)完成特定工件。需要承擔(dān)一定的職責(zé)和具備相應(yīng)的能力，諸如執(zhí)行某些活動(dòng)和開(kāi)發(fā)某些工件。主要目的是為軟件開(kāi)發(fā)組織提供軟件開(kāi)發(fā)環(huán)境(流程和工具)。配置和變更控制工作流，描述了如何控制軟件項(xiàng)目組內(nèi)部各個(gè)成員的相互關(guān)聯(lián)的工作(如避免重復(fù)無(wú)效的軟件修改，多版本并發(fā)開(kāi)發(fā)的協(xié)調(diào)和控制等等)，以控制和維護(hù)項(xiàng)目制品的完整性。以下做簡(jiǎn)要說(shuō)明：項(xiàng)目管理工作流，描述如何控制軟件項(xiàng)目組內(nèi)部的各個(gè)成員的相互關(guān)聯(lián)的工作。 核心支持工作流核心支持工作流(Core Support Workflow)包括: 項(xiàng)目管理（Project Management）工作流、配置和變更管理(Configuration amp。其主要任務(wù)是將開(kāi)發(fā)的產(chǎn)品提交給用戶(hù)，并作相應(yīng)的系統(tǒng)配置。測(cè)試的結(jié)果將確認(rèn)所完成的系統(tǒng)可以交付使用。主要目標(biāo)是核實(shí)對(duì)象之間的交互及所有構(gòu)件是否正確集成，確定缺陷并確保在部署軟件之前將缺陷解決。實(shí)現(xiàn)的任務(wù)是在預(yù)定的環(huán)境中實(shí)現(xiàn)系統(tǒng)，生成系統(tǒng)的源代碼、可執(zhí)行程序和相應(yīng)的軟件文檔，建立一個(gè)可執(zhí)行的系統(tǒng)。設(shè)計(jì)活動(dòng)以架構(gòu)設(shè)計(jì)為中心，架構(gòu)由若干模型來(lái)表達(dá)。設(shè)計(jì)模型是源代碼的抽象，由設(shè)計(jì)類(lèi)和一些描述組成。使設(shè)計(jì)適合于實(shí)現(xiàn)環(huán)境，最后得到一個(gè)為軟件特定環(huán)境支持的詳細(xì)系統(tǒng)結(jié)構(gòu)描述。需求分析的結(jié)果可以用一個(gè)用例模型表達(dá)，模型中的活動(dòng)者代表外部的與系統(tǒng)交互的單元(人或外部系統(tǒng))，用例代表交互的事務(wù)序列，它為活動(dòng)者提供可度量的結(jié)果值。需求工作流，主要目標(biāo)是描述用戶(hù)的需求，并做到與用戶(hù)和其他涉眾在系統(tǒng)的工作內(nèi)容方面達(dá)成且保持一致，使系統(tǒng)開(kāi)發(fā)人員能夠更清楚地了解系統(tǒng)需求，定義系統(tǒng)邊界，定義系統(tǒng)的用戶(hù)界面。業(yè)務(wù)模型是需求工作流的一種重要輸入，用來(lái)了解對(duì)系統(tǒng)的需求。其主要任務(wù)是對(duì)將來(lái)使用該系統(tǒng)的組織機(jī)構(gòu)或企業(yè)進(jìn)行評(píng)估；理解它們的需要以及要求未來(lái)系統(tǒng)解決的問(wèn)題。各工作流的簡(jiǎn)單介紹如下：業(yè)務(wù)建模工作流 [23,41,42,43]，說(shuō)明如何擬定新目標(biāo)組織的前景，并基于前景來(lái)確定該組織在業(yè)務(wù)用例模型和業(yè)務(wù)對(duì)象模型中的流程、角色以及職責(zé)。核心工作流的迭代開(kāi)發(fā)循環(huán)模型如圖 24 所示：圖 24 核心工作流的迭代開(kāi)發(fā)循環(huán) 核心過(guò)程工作流業(yè)務(wù)建模（Business Modeling） 、需求（Requirements)、分析與設(shè)計(jì)（Analysis amp。RUP 共有 9 個(gè)工作流，其中分為 6 個(gè)核心過(guò)程工作流：業(yè)務(wù)建模、需求、分析和設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、部署工作流；3 個(gè)核心支持工作流：項(xiàng)目管理、配置和變更控制、環(huán)境工作流 [16,17,18]。工作流，是產(chǎn)生具有可觀(guān)察結(jié)果的活動(dòng)序列。RUP 的靜態(tài)結(jié)構(gòu)包括角色（worker） 、工作流程（ workflow） 、活動(dòng)（activities） 、工件（artifact ）四個(gè)基本模型元素 [1,23]。通常，在初始階段，迭代工作重點(diǎn)在于需求捕獲；在細(xì)化階段，重點(diǎn)轉(zhuǎn)移到分析和設(shè)計(jì)；在構(gòu)造階段，實(shí)現(xiàn)是中心活動(dòng)；而移交階段的，中心任務(wù)在于實(shí)施。迭代過(guò)程是導(dǎo)致可執(zhí)行產(chǎn)品版本的完整開(kāi)發(fā)循環(huán)(即從捕獲需求到代碼實(shí)現(xiàn))，是最終產(chǎn)品的一個(gè)子集，從一個(gè)迭代過(guò)程到另一個(gè)迭代過(guò)程遞增式增長(zhǎng)，形成最終的系統(tǒng)產(chǎn)品。此時(shí)，要確定目標(biāo)是否實(shí)現(xiàn)。這一階段的主要任務(wù)有系統(tǒng)的 Beta 測(cè)試、系統(tǒng)性能調(diào)整和人員培訓(xùn)等。此時(shí)，要確定軟件、環(huán)境、用戶(hù)是否可以開(kāi)始系統(tǒng)的運(yùn)作。每一次循環(huán)都將得到一個(gè)更準(zhǔn)確接近未來(lái)系統(tǒng)的模型或原型。構(gòu)造階段的任務(wù)，通過(guò)循環(huán)重復(fù)的工作具體建造軟件系統(tǒng)。2）迭代開(kāi)發(fā)準(zhǔn)備給用戶(hù)的完整產(chǎn)品。 構(gòu)造階段構(gòu)造階段 [36,37]是將主要精力集中在現(xiàn)象設(shè)計(jì)、實(shí)現(xiàn)以及測(cè)試來(lái)充實(shí)一個(gè)完整的系統(tǒng)的階段。生命周期架構(gòu)里程碑為系統(tǒng)的架構(gòu)建立了管理基線(xiàn)并使項(xiàng)目小組能夠在構(gòu)造階段中進(jìn)行衡量。這一階段項(xiàng)目組主要關(guān)注應(yīng)用系統(tǒng)需求展開(kāi)以及確定、開(kāi)發(fā)和驗(yàn)證項(xiàng)目架構(gòu)。4）細(xì)化開(kāi)發(fā)案例并搭建開(kāi)發(fā)環(huán)境。2）設(shè)計(jì)、實(shí)現(xiàn)、驗(yàn)證系統(tǒng)架構(gòu)并建立架構(gòu)基線(xiàn)。這一階段的主要目標(biāo)有:1）更明確的認(rèn)識(shí)需求。生命周期目標(biāo)里程碑評(píng)價(jià)項(xiàng)目基本的生存能力。要理解最初的需求，可能要進(jìn)行業(yè)務(wù)建模及其他基本的建?；顒?dòng)。5）確定循環(huán)什么過(guò)程和使用哪些工具。至少確定一個(gè)可行的系統(tǒng)架構(gòu)，確保在適當(dāng)?shù)娘L(fēng)險(xiǎn)和代價(jià)下創(chuàng)建系統(tǒng)。確定哪些用例是最重要的，識(shí)別系統(tǒng)必須被實(shí)現(xiàn)的功能。識(shí)別出誰(shuí)將使用這個(gè)系統(tǒng)以及系統(tǒng)將為他們帶來(lái)什么好處。圖 23 階段和里程碑 初始階段初始階段 [34,36]是 RUP 生命周期四個(gè)階段中的第一個(gè)階段，該階段主要有 5 個(gè)目標(biāo):1）了解要?jiǎng)?chuàng)建什么樣的系統(tǒng)。在每個(gè)階段結(jié)束時(shí)要依據(jù)里程碑目標(biāo)進(jìn)行工作評(píng)估，以確定是否實(shí)現(xiàn)了該階段的目標(biāo)以及是否可以進(jìn)入下一個(gè)階段。每個(gè)階段都終結(jié)于一個(gè)良好定義的里程碑。在此時(shí)間維上，為了能夠方便地管理軟件開(kāi)發(fā)過(guò)程，監(jiān)控軟件開(kāi)發(fā)狀態(tài)，RUP 把軟件生命周期劃分為若干次迭代，每次迭代生成一個(gè)產(chǎn)品的新版本并依次由四個(gè)連續(xù)的階段組成，每次迭代都應(yīng)完成確定的任務(wù)，正是這些迭代過(guò)程不斷產(chǎn)生系統(tǒng)新的增量，使產(chǎn)品不斷成熟，從低版本軟件不斷過(guò)渡到高版本浙江工業(yè)大學(xué)碩士學(xué)位論文 10 軟件。隨著產(chǎn)品經(jīng)歷了幾個(gè)周期，新一代產(chǎn)品隨之產(chǎn)生。除非項(xiàng)目“死亡” ，否則通過(guò)重復(fù)同樣的起始階段、細(xì)化階段、構(gòu)建階段和移交階段的順序，產(chǎn)品將演進(jìn)為下一代產(chǎn)品，但每一次的側(cè)重點(diǎn)都將放在不同的階段上。在進(jìn)度和工作量方面，所有階段都各不相同。它以術(shù)語(yǔ)周期（Cycle ） 、階段（ Phase） 、迭代（Iteration ）和里程碑（ Milestone）來(lái)表達(dá)。但隨著應(yīng)用的愈廣愈久，該模型的缺乏靈活性；過(guò)于依賴(lài)早期進(jìn)行的唯一的一次需求調(diào)查，不能適應(yīng)需求的變化；單一流程，開(kāi)發(fā)中的經(jīng)驗(yàn)教訓(xùn)不能反饋應(yīng)用于本產(chǎn)品的過(guò)程；風(fēng)險(xiǎn)往往要到后期的開(kāi)發(fā)階段才顯露，因而失去及早糾正的機(jī)會(huì)等缺點(diǎn)也就逐級(jí)暴露了出來(lái)，所以必須尋找有效的解決辦法。RUP 是一個(gè)將用戶(hù)需求轉(zhuǎn)化為軟件系統(tǒng)所需的活動(dòng)集合，該活動(dòng)集合是在過(guò)程的生命周期中完成的。在一個(gè)時(shí)間段內(nèi)，只能作某一個(gè)階段的工作，比如分析、設(shè)計(jì)或者實(shí)現(xiàn)。 RUP 的生命周期軟件開(kāi)發(fā)過(guò)程模型亦被稱(chēng)為軟件生命周期模型，它描述了開(kāi)發(fā)一個(gè)軟件系統(tǒng)必需的所有活動(dòng)和工作產(chǎn)品。RUP 自誕生時(shí)起，就引起了全球軟件行業(yè)的關(guān)注，經(jīng)過(guò)大量商業(yè)實(shí)踐表明，RUP是解決軟件開(kāi)發(fā)過(guò)程中根本問(wèn)題的方怯。RUP 的總體結(jié)構(gòu)如圖21 所示：圖 21 RUP 的總體結(jié)構(gòu)RUP 吸收了多種開(kāi)發(fā)模型的優(yōu)點(diǎn)，具有很好的可操作性和實(shí)用性并且和目前應(yīng)用廣泛的統(tǒng)一建模語(yǔ)言（Unified Model Language，UML）有著良好集成、有多種 CASE 工具進(jìn)行支持、不斷的升級(jí)與維護(hù)，迅速得到軟件開(kāi)發(fā)行業(yè)的廣泛認(rèn)同，越來(lái)越多的軟件開(kāi)發(fā)組織以它作為軟件開(kāi)發(fā)模型框架。所有 RUP 的實(shí)施細(xì)節(jié)及方法引導(dǎo)均以 Web 文檔的方式集成，由 Rational 公司開(kāi)發(fā)、維護(hù)并銷(xiāo)售，為各種軟件開(kāi)發(fā)組織提供了一種有效的分配、管理任務(wù)和職責(zé)的規(guī)范方法，保障開(kāi)發(fā)組織能夠在預(yù)定的進(jìn)度和范圍內(nèi)開(kāi)發(fā)出滿(mǎn)足最終用戶(hù)需要的高質(zhì)量軟件產(chǎn)品。第 7 章是結(jié)論與展望，對(duì)全文進(jìn)行一個(gè)總結(jié)和回顧，并對(duì)下一步工作進(jìn)行展望。主要是根據(jù)第 3 章量體裁衣后的 RUP 過(guò)程來(lái)進(jìn)行系統(tǒng)建模，緊扣它的 3 個(gè)特點(diǎn)，最后介紹了數(shù)據(jù)庫(kù)設(shè)計(jì)。浙江工業(yè)大學(xué)碩士學(xué)位論文 6 第 4 章是對(duì)行政事業(yè)性單位收費(fèi)票據(jù)系統(tǒng)的架構(gòu)和功能分析。首先針對(duì) RUP 用例驅(qū)動(dòng)、以架構(gòu)為中心和迭代增量開(kāi)發(fā) 3 個(gè)特點(diǎn)做了詳細(xì)的介紹并說(shuō)明三者缺一不可的重要性。首先給出簡(jiǎn)要的 RUP 概述；接著介紹了 RUP 的生命周期，并與傳統(tǒng)的瀑布模型相比較；再次根據(jù)所得 RUP 生命周期的二維模型，從橫軸、縱軸角度分別闡述了它的動(dòng)態(tài)組成和靜態(tài)組成。 結(jié)構(gòu)安排根據(jù)上述的研究?jī)?nèi)容，本文的結(jié)構(gòu)安排如下：第 1 章是緒論，首先簡(jiǎn)要介紹了課題研究的背景和意義；接著在研究現(xiàn)狀中針對(duì)傳統(tǒng)的軟件過(guò)程講述了目前幾種面向?qū)ο蟮能浖^(guò)程，相互比較了特點(diǎn)后提出選取 RUP作為本文中課題的軟件過(guò)程；最后介紹了本文的研究?jī)?nèi)容和結(jié)構(gòu)安排。將裁剪后適應(yīng)于實(shí)際系統(tǒng)開(kāi)發(fā)的 RUP 理論轉(zhuǎn)換為用于指導(dǎo)實(shí)際工作的具體步驟，并運(yùn)用 Rational Rose 建模工具，構(gòu)建實(shí)際系統(tǒng)核心用例的需求、分析、設(shè)計(jì)以及實(shí)施模型。簡(jiǎn)要介紹 UML 統(tǒng)一建模語(yǔ)言，理解 UML 和 RUP 相輔相成、密不可分的關(guān)系并使其在 RUP 中正確應(yīng)用。研究?jī)?nèi)容主要包括如下幾點(diǎn)：分析 RUP 的核心思想，尤其抓住它的用例驅(qū)動(dòng)、以架構(gòu)為中心和迭代增量開(kāi)發(fā)的三個(gè)關(guān)鍵點(diǎn)。浙江工業(yè)大學(xué)碩士學(xué)位論文 5 本文的研究?jī)?nèi)容和結(jié)構(gòu)安排 本文的研究?jī)?nèi)容本文主要探討了如何將 RUP 用于組織和開(kāi)發(fā)行政事業(yè)性單位收費(fèi)票據(jù)系統(tǒng)軟件，并分析了其優(yōu)缺點(diǎn)。而 RUP 在推向市場(chǎng)后，憑借 Rational公司和現(xiàn)在 IBM 公司的強(qiáng)大實(shí)力的支持，以其與 UML 的良好集成、有多種 CASE 工具的支持、不斷的升級(jí)與維護(hù)等特點(diǎn)，迅速得到業(yè)界廣泛的認(rèn)同，市場(chǎng)競(jìng)爭(zhēng)力上的巨大優(yōu)勢(shì)是 RUP 被廣泛地用作軟件開(kāi)發(fā)的指導(dǎo)的最重要的原因 [7,27,28]。OPEN 和 OOSP 與 RUP 相比，優(yōu)勢(shì)在于它們都覆蓋了完整的軟件工程過(guò)程，而不僅僅是開(kāi)發(fā)過(guò)程，RUP 中缺少維護(hù)、軟件操作與支持、組織與管理等方面的內(nèi)容；OPEN 與OOSP 都支持多項(xiàng)目，而