在线观看成人日韩福利在线_ Sawin系統分析之窗：應用Rational 工具簡(jiǎn)化基于J2EE的項目（三）

應用Rational 工具簡(jiǎn)化基于J2EE的項目

第 3 部分：轉換到系統模型

Steven Franklin

軟件設計師和過(guò)程專(zhuān)家

2004 年 3 月

本文將繼續通過(guò)這個(gè)全面的應用 RUP 和其他 Rational 工具的樣例項目來(lái)介紹創(chuàng )建項目的 Rational Rose 模型，本文中我們將開(kāi)始創(chuàng )建代表“目前”業(yè)務(wù)情況的系統模型，并將此業(yè)務(wù)模型轉換成為“將來(lái)”的系統模型。

這個(gè)第 3 部分文章重點(diǎn)的介紹了在 Rational Rose 中完成的早期建?；顒?dòng)。首先我們來(lái)對 ASDI 現有的（“as is”）系統進(jìn)行建模，通過(guò)業(yè)務(wù)用例和業(yè)務(wù)對象可以顯示當前事情是如何工作的。我們將從這個(gè)反映現有系統的模型創(chuàng )建出符合 ASDI 新的需求的系統模型，并且將這個(gè)系統模型作為建立軟件的基礎。

伴隨著(zhù)這本文有 2 個(gè)演講稿 (來(lái)自于 Rational 用戶(hù)大會(huì ) 2000) 這里討論了以下主題： Yves Holvoet 的 “維護分析模型與多個(gè)設計模型的同步” 和 Robert Bretall 的 “結構化你的 Rational Rose 模型”。后一個(gè)演講稿附帶一個(gè) Rose 模型。

第 3 部分快照

第 3 部分所使用的工具和技術(shù)：

Rational 統一過(guò)程 (RUP) — 指導軟件開(kāi)發(fā)過(guò)程，對項目的每個(gè)階段提供建議的過(guò)程和工作產(chǎn)物 Rational Rose 企業(yè)版 — 為了創(chuàng )建“目前的”業(yè)務(wù)模型（使用統一建模語(yǔ)言（UML））并在分析線(xiàn)索的基礎上開(kāi)始創(chuàng )建“將來(lái)的”系統模型

被創(chuàng )建的或者被更新的工作產(chǎn)物：

業(yè)務(wù)用例模型（Rational Rose） — 被創(chuàng )建用來(lái)代表系統“目前的”業(yè)務(wù)功能業(yè)務(wù)對象模型（Rational Rose） — 被創(chuàng )建用來(lái)捕獲系統“目前的”業(yè)務(wù)功能是如何被執行的：實(shí)體之間的協(xié)作、實(shí)體之間的交互和相關(guān)的過(guò)程和產(chǎn)物用例模型（Rational Rose） — 不能完全的表示業(yè)務(wù)用例模型；被創(chuàng )建用來(lái)獲取詳細的系統“將來(lái)的”執行功能（它作為構建軟件的基礎）

有太多新的和被改進(jìn)了的 IT 系統在已有系統被了解之前被啟動(dòng)。甚至是當已有系統還缺乏 IT 組件的時(shí)候，有必要在可選的和改進(jìn)的方案被建議之前對當前的業(yè)務(wù)活動(dòng)情況進(jìn)行分析。然而人們總是跳過(guò)或者草草的完成這一步，但是這做會(huì )導致以下的問(wèn)題：

對客戶(hù)的需求的理解不夠充分，減慢接下來(lái)的分析對需求的不正確的解釋不能準確的估計新方案所帶來(lái)的影響，導致當軟件被交付給客戶(hù)使用時(shí)對客戶(hù)的工作產(chǎn)生巨大的震動(dòng)和要求客戶(hù)完全改變現有的工作流程不一致的術(shù)語(yǔ)和概念，導致與客戶(hù)之間產(chǎn)生交流上的誤解和混亂

創(chuàng )建一個(gè)業(yè)務(wù)模型以捕獲“目前的”系統的情況可以是非?？焖俚娜蝿?wù)并能夠產(chǎn)生有用的分析線(xiàn)索，這些線(xiàn)索將簡(jiǎn)化對“將來(lái)的”系統的定義。在創(chuàng )建這個(gè)模型中能夠對我們有幫助的一件事情是工作狀態(tài)（SOW）。雖然 SOW 主要用來(lái)描述“將來(lái)的”系統的需求，但是它也提供了ASDI 的當前業(yè)務(wù)流程的有用的背景信息。

在 Rational 統一過(guò)程（RUP）初始階段部分存在一系列的用于業(yè)務(wù)建模的方法（也是就在我們項目的第 1 階段）。與 ASDI 一起創(chuàng )建一個(gè) IT 系統，我們需要一個(gè)“目前的”模型以捕獲文件的流轉和他們的當前系統的交互活動(dòng)。我們在 Rational Rose 中創(chuàng )建了下列 RUP 工作產(chǎn)物作為業(yè)務(wù)建模工作的部分：

業(yè)務(wù)用例模型，建模“目前的”業(yè)務(wù)功能。業(yè)務(wù)對象模型 (有時(shí)也稱(chēng)作領(lǐng)域模型)，對執行業(yè)務(wù)功能的對象和這些對象之間的關(guān)系進(jìn)行建模。一個(gè)業(yè)務(wù)對象模型可能會(huì )顯示一個(gè)發(fā)票是如何被生成并如何在系統中進(jìn)行流轉，或者顯示了一個(gè)購買(mǎi)請求的開(kāi)始到結束的過(guò)程。

注意在以前的一些項目中，我們跳過(guò)了業(yè)務(wù)建模的步驟，因為我們是建立一個(gè)全新的系統，或者是因為我們已經(jīng)非常好的了解了已有的業(yè)務(wù)模型。但是因為我們對 ASDI 的業(yè)務(wù)是陌生的，因此我們覺(jué)得這一步是十分重要的。

我們也考慮到開(kāi)發(fā)一個(gè)業(yè)務(wù)術(shù)語(yǔ)表（使用 RUP 提供的工作產(chǎn)物模板），但是我們發(fā)現我們的術(shù)語(yǔ)中的大多數是相當標準和明確的，而且這些術(shù)語(yǔ)在我們的業(yè)務(wù)對象模型中被充分的捕獲了。更加復雜或者嚴格的項目將會(huì )從創(chuàng )建業(yè)務(wù)術(shù)語(yǔ)表中獲益以確保在所有產(chǎn)物中的一致性。

當我們使用 Rational Rose 創(chuàng )建我們的模型時(shí)，我們感到僅僅簡(jiǎn)單的創(chuàng )建圖是不夠的。我們發(fā)現僅僅通過(guò)圖的方式表達模型對圖的創(chuàng )建者是容易理解的，但對圖的閱讀者來(lái)說(shuō)卻是很難讀懂的，因此我們?yōu)槊恳粋€(gè)圖附加了文檔（通過(guò)在圖上點(diǎn)擊并在文檔窗口輸入文本）。我們也為圖中的每一項提供了文檔 — 用例、業(yè)務(wù)對象、用戶(hù)或者其他項 — 用一到兩行的文字來(lái)描述每一項的目的。

我們從一個(gè)開(kāi)始點(diǎn)來(lái)創(chuàng )建我們的新模型文件（ASDI.mdl），我們使用符合 RUP 中定義的結構的 Rose 模板（見(jiàn)圖 1）。因為我們在 RUP 中完成大量的工作，這將使我們工作的很好。RUP 的模型模板是可以在啟動(dòng) Rose 時(shí)看到的，我們可以通過(guò)向導來(lái)訪(fǎng)問(wèn)的幾個(gè)模板之一，或者你也可以在 Rose 應用程序的 Frameworks 目錄中找到他們。

圖 1: RUP 模型模板

我們對模板的結構做了一些改動(dòng)以符合我們的需要和選擇。例如，我們直接做了一下的修改：

代替跟蹤被包括的與其他用例分離的用例，我們將這些用例組織到邏輯上包含他們的功能的包中。我們覺(jué)得可以將 <<include>> 原型和 Rational SODA 的報告能力結合起來(lái)，這樣當有必要時(shí)可以允許我們容易的識別被包含的用例。我們刪除了在邏輯視圖（Logical View）下的分析模型。你可以閱讀 Yves Holvoet 的演講稿來(lái)了解分析框架重用和分析/設計用例的正反觀(guān)點(diǎn)的討論。我們決定一個(gè)分層的分析模型是沒(méi)有必要的，因為我們并不期望 ADSI 系統中的多數業(yè)務(wù)模型可以在將來(lái)的項目中被重用。相反，我們允許用例在整個(gè)項目的過(guò)程中得到進(jìn)化。我們首先通過(guò)業(yè)務(wù)組件對設計模型進(jìn)行了劃分，然后再對他們進(jìn)行層次的劃分（這兩個(gè)任務(wù)通常是不同的），而不是一開(kāi)始就對模型進(jìn)行層次劃分。

接下來(lái)我們必須添加一個(gè)計劃（schema）區域到模型中以使數據庫架構師可以跟蹤數據建模的工作。

將 Rose 模型按照不同團隊成員的責任分攤到包中通常是需要花費一定的功夫的。包的結構應該被創(chuàng )建的使在團隊成員之間共享職責相對的簡(jiǎn)單一些，這可以通過(guò)劃分系統成為不同的部分來(lái)實(shí)現：分析（比如，貫穿用例和業(yè)務(wù)對象），體系架構和設計。

我們的團隊雖然不是很大，但我們還是要考慮到在模型之上的協(xié)作問(wèn)題。我有幾個(gè) Rational Rose 的浮動(dòng)的許可證，這足夠我們所有的人同時(shí)訪(fǎng)問(wèn)模型，但是我們也需要使我們能夠并發(fā)的訪(fǎng)問(wèn)模型的某一部分。因此我們使用 Rose 的 “單元控制” 的特性以對模型進(jìn)行適當的分解。

在我們的團隊的組織結構中的角色（如在第 2 部分被描述的）這些角色所擁有的對模型各部分的輸入和更新的指責被顯示在表 1 中。因此，團隊中的其他成員，比如初級的開(kāi)發(fā)人員和項目工程師將只擁有對模型進(jìn)行訪(fǎng)問(wèn)的權限以完成他們的開(kāi)發(fā)工作。

角色輸入/更新職責

組長(cháng)/高級分析人員打包管理

用例模型(業(yè)務(wù)和系統)

業(yè)務(wù)對象模型

體系架構

設計

高級開(kāi)發(fā)人員體系架構

設計

數據庫架構師體系架構

計劃（Schema）設計

表 1: 模型輸入/更新職責

我們對模型進(jìn)行了分解，如圖 2 中顯示的 Rose 圖。此時(shí)這個(gè)模型的結構服務(wù)于我們需要，因為我們有 3 個(gè)人直接的維護這個(gè)模型。將來(lái)，當團隊和項目逐漸擴大時(shí)，這個(gè)模型結構可以被容易的分解為更多的 *.cat 文件。

圖 2: 模型分解

關(guān)于分解 Rose 模型的額外信息可以在 Robert Bretall 的演講稿中找到。這里只指出來(lái)自于它的模型結構討論中的幾個(gè)有價(jià)值的事情：

最好不要將內容放在模型的頂層。（在我們的案例中，所有的信息都被放到了被控制的 *.cat 文件中。）如果你計劃在將來(lái)的項目中重用你的系統模型的某些部分，考慮對分析模型進(jìn)行分層。（你也可以在 Yves Holvoet 演講稿中找到更多相關(guān)的信息。）如果模型的結構是根據 RUP 的指導創(chuàng )建的，Rational 的工具（SoDA ，REI 腳本等）將更加有效的與模型進(jìn)行交互。

使用 Rational Rose 分解模型成為分離的 *.cat 文件是很容易的。如圖 3 所示，我們簡(jiǎn)單的右鍵點(diǎn)擊我們想在單獨的文件中控制的包；然后在上下文菜單中選擇 Units > Control Use-Case Model ，這使我們可以控制這個(gè)包和這個(gè)包中的所有子子項。稍后在項目中，我們將重組一些 *.cat 文件成為幾個(gè)更小的被控制的包以進(jìn)一步的發(fā)布建模的工作產(chǎn)物。

圖 3: 在 Rose 中創(chuàng )建分離的 *.cat 文件

一個(gè)角色（actor）是與系統交互的外界的人或者事物；這既可以是使用系統的人，也可以是其他的接口類(lèi)型。建模系統的用戶(hù)和接口以及他們之間的依賴(lài)是非常有用的；它不僅僅可以給你一個(gè)系統的完整實(shí)體，而且也可以提供給你對于將來(lái)的安全性和角色建模工作的良好信息。

圖 4 顯示了我們如何在 Rose 中將角色容入我們的業(yè)務(wù)模型當中 — 尤其是，在一個(gè)與客戶(hù)服務(wù)相關(guān)的用例圖中，這個(gè)用例圖摘自我們的業(yè)務(wù)用例模型。兩個(gè)特殊的原型類(lèi)被使用：業(yè)務(wù)角色和業(yè)務(wù)用例。 Rose 可以基于原型分配自定義的圖標，并且我們選擇這個(gè)方法為用例和角色分配外表略有不同的圖標 — 加了一條斜線(xiàn) — 因為我們覺(jué)得區別用于構建軟件的系統模型與業(yè)務(wù)模型是重要的。

圖 4: 客戶(hù)服務(wù)的用例模型摘錄

當我們將業(yè)務(wù)用例模型充實(shí)起來(lái)時(shí)，對于業(yè)務(wù)對象模型來(lái)說(shuō)將會(huì )出現一系列好的候選對象。雖然創(chuàng )建一個(gè)“目前的”系統的業(yè)務(wù)模型看起來(lái)要花費大量的工作（主要的工作量是生成圖），但是我們覺(jué)得它是值得的。在我們過(guò)去的“目前的”模型中，已經(jīng)包含了大量的在實(shí)驗室工作簿中的注釋和正式的技術(shù)注釋。為了得到已有業(yè)務(wù)流程的更加清晰和完整的視圖，應該在花費一些時(shí)間在 Rose 中捕獲這個(gè)信息。

有時(shí)人們會(huì )將重點(diǎn)都放到了系統的某個(gè)單獨的部分上，但實(shí)際上系統各部分之間的交互也是非常重要的。充分的考慮整個(gè)系統部分的交互將使系統各部分之間集成的共性和可能性更加明顯。這是為什么我們后來(lái)使用交互圖的原因之一（顯示系統各部分間的交互）以驗證我們的設計；這對在分析和設計中識別流程和固有的缺口是非常關(guān)鍵的。

在項目的早期我們關(guān)注的交互：

業(yè)務(wù)用例對角色（什么樣的個(gè)體和接口訪(fǎng)問(wèn)到我們識別出來(lái)的各種業(yè)務(wù)任務(wù)）業(yè)務(wù)對象對業(yè)務(wù)對象（各個(gè)業(yè)務(wù)對象之間是如何彼此交互的，和他們共享信息的種類(lèi)）用例對用例（任務(wù)彼此之間的依賴(lài)，和被一定的過(guò)程共享的公用任務(wù)）

我們花費了一些時(shí)間在 Rose 中捕獲我們對當前業(yè)務(wù)組織和過(guò)程的理解，結果是生成了對于我們理解現有系統非常有用的業(yè)務(wù)對象模型。在對象模型中的圖（在圖 5 中顯示的是其中的一個(gè)）類(lèi)似于標準的類(lèi)圖、除了他們使用了特殊的原型類(lèi)：業(yè)務(wù)實(shí)體、業(yè)務(wù)控制和業(yè)務(wù)角色。業(yè)務(wù)實(shí)體表示被動(dòng)的領(lǐng)域對象比如發(fā)票或者報告，而業(yè)務(wù)控制是執行功能的對象，可以表示報警或者機械的作用。（業(yè)務(wù)角色在之前已經(jīng)被討論了。）

圖 5: 業(yè)務(wù)對象模型摘錄

我們在業(yè)務(wù)用例建模之后很快開(kāi)始業(yè)務(wù)對象建模。業(yè)務(wù)用例的說(shuō)明文字確定了一系列合適的業(yè)務(wù)對象。如果是跨越多個(gè)用例的對象，比如“購買(mǎi)請求”和“產(chǎn)品”、“產(chǎn)品隊列”和“運輸隊列”是被識別的業(yè)務(wù)領(lǐng)域的關(guān)鍵對象。有時(shí)如果我們意識到它是不合適的或者已經(jīng)被其他對象覆蓋到了，我們將刪除這個(gè)業(yè)務(wù)對象。通過(guò)這種方法，可以快速的在任務(wù)（用例）和事物（業(yè)務(wù)對象）中篩選與 ASDI 業(yè)務(wù)相關(guān)的業(yè)務(wù)對象。

在某些情況下，業(yè)務(wù)對象模型將演化成系統類(lèi)。這對于實(shí)體對象來(lái)說(shuō)基本上是正確的，實(shí)體對象通常被映射為容器類(lèi)或者是數據庫表。在其他一些情況下，業(yè)務(wù)對象模型簡(jiǎn)單的作為一個(gè)為理解客戶(hù)領(lǐng)域的引用的結合點(diǎn)來(lái)使用。我們確認客戶(hù)已經(jīng)完全理解了圖形化的符號和每個(gè)圖的內容，因為他們的檢查和批準是關(guān)鍵的。

總而言之，我們花費了大量的時(shí)間在業(yè)務(wù)建模的工作上。這并不一定是一流的或者是完全的，但是對于我們來(lái)說(shuō)應該是能夠對當前的業(yè)務(wù)流程有一個(gè)足夠的認識。在項目的第一個(gè)或者兩個(gè)月后，我們將很少的提及業(yè)務(wù)模型，但是我們覺(jué)得它是值得花費時(shí)間的，因為它是形成“未來(lái)的”系統的系統模型的一個(gè)必要的步驟。當一個(gè)新成員加入到我們的團隊時(shí)，我們可以通過(guò)瀏覽業(yè)務(wù)模型來(lái)幫助他們來(lái)理解新的領(lǐng)域；然而，一旦對它熟悉了，業(yè)務(wù)模型將很少再被查看，除非是闡明術(shù)語(yǔ)。

計劃“將來(lái)的”系統，我們需要將已經(jīng)用文字形式表示的 SOW 需求(在第 2 部分中被討論的)轉換成為經(jīng)過(guò)深思熟慮的用例。換句話(huà)說(shuō)，通過(guò)對“目前的”系統的業(yè)務(wù)用例的創(chuàng )建（就像早些時(shí)候所討論的），我們準備為“將來(lái)的”系統細化這些用例。這將不是一個(gè)快速的步驟，但是它經(jīng)歷超過(guò)兩周的時(shí)間。（在 RUP 的術(shù)語(yǔ)中，這個(gè)轉換反映了一個(gè)從初始階段到細化階段的逐步轉化過(guò)程。）我們在業(yè)務(wù)建模上所作的工作，獲得了當前系統的經(jīng)驗并將它的功能劃分進(jìn)了業(yè)務(wù)用例，這對我非常有幫助。（ RUP 的文檔顯示了從業(yè)務(wù)用例模型到業(yè)務(wù)對象模型和系統用例模型的演進(jìn)；我們發(fā)現這是非常正確和有幫助的。）

我們并不擔心映射 SOW 需求到“目前的”系統業(yè)務(wù)用例的原因是 SOW 需求中的許多在當前的系統中是不存在的。我們早期所創(chuàng )建的業(yè)務(wù)模型只不過(guò)是一個(gè)臨時(shí)的產(chǎn)物，它用于我們確保我們的團隊理解 ASDI 的當前系統。

一系列的工作簿和工作產(chǎn)物（包括那些后面被列的“引用和其他資源”）解釋了用例建模和理解需求的好處。我們發(fā)現許多被提及的好處是真實(shí)的，雖然定義用例的內容不是瑣碎的任務(wù)。與良好的文字說(shuō)明相比，如果用例沒(méi)有被良好的設計，對于你來(lái)說(shuō)他們當然沒(méi)有用的。

這里是一些開(kāi)始創(chuàng )建用例時(shí)的誤解：

用例被創(chuàng )建的太大或者太小用例在跨越團隊的情況下不一致沒(méi)有對用例分組的包進(jìn)行良好的計劃不合理的對模型的訪(fǎng)問(wèn)進(jìn)行控制，導致在團隊分析協(xié)作的過(guò)程中發(fā)生沖突過(guò)于細致的定義用例，在用例進(jìn)入原型、設計和開(kāi)發(fā)任務(wù)之前就定義每一件事情定義用例時(shí)過(guò)于簡(jiǎn)單，使需求被工程團隊可以有眾多的解釋

結果，我們決定用例建模標準和指南需要被組長(cháng)定義。這些包括下面的指南：

用例典型的獲取 10 到 20 天的開(kāi)發(fā)和單元測試。這不是 RUP 的規則，但是對于我們來(lái)說(shuō)這是一個(gè)好的規則。如果我們發(fā)現用例比這個(gè)標準過(guò)大或者過(guò)小，我們將花費額外的時(shí)間檢查他們以保證他們有合適的范圍。工程團隊必須在早期對包的結構達成一致。這個(gè)結構可能會(huì )變化，但是變化應該首先與團隊進(jìn)行討論。

當決定什么應該包括在我們的用例中時(shí)，我們應該遵從在文章中指出的指南:

標識 — 名稱(chēng)、唯一的 ID、原型、可跟蹤需求和簡(jiǎn)介描述 — 開(kāi)始狀態(tài)、結束狀態(tài)主流程描述和變更注釋 — 臨時(shí)的“便簽簿”注釋

當我們從“目前的”轉移到“將來(lái)的”時(shí)，我們的許多業(yè)務(wù)角色被演化成了系統中真實(shí)的用戶(hù)和接口，雖然有意義的重構是必要的。這是自然的，因為當重新定義其他角色時(shí)新的 IT 方案統一了原有的一些角色。一些業(yè)務(wù)實(shí)體作為抽象的概念消失了，而其他的一些通過(guò)計劃（schema）或者詳細的設計被映射成了類(lèi)。

在圖 6 到圖 9 中顯示了我們早期工作產(chǎn)生的對于“將來(lái)的”系統的用例模型的一部分。通過(guò)圖形、協(xié)作圖和時(shí)序圖以及進(jìn)一步的詳細分析的幫助，它將隨著(zhù)時(shí)間推移而成熟。