第 4 部分 ：分析和工具的進展
Steven Franklin
軟件設(shè)計師和過程專家
2004 年 4 月
在這個展示了 RUP 和其他 Rational 工具使用的樣例項目的接下來的階段，用例通過添加文檔和可跟蹤性到需求被細(xì)化，并且使用的工具和技術(shù)被評估和選擇。
這個第 4 部分文章的重點在于 ASDI 項目的細(xì)化階段，尤其是在用例分析方面（細(xì)化我們的用例以對工作狀態(tài)（SOW）添加可跟蹤性，并且標(biāo)準(zhǔn)化和生成用例文檔）并選擇合適的工具和技術(shù)。
| 第 4 部分快照 |
在第 4 部分演示的工具和技術(shù)：
產(chǎn)生或者被更新的產(chǎn)物：
|
細(xì)化并文檔化用例
圖 1 顯示了在 ASDI 項目的第 1 階段（RUP 的初始和細(xì)化階段）中的用例的演化。就像我們在第 3 部分討論的，我們在初始階段創(chuàng)建了業(yè)務(wù)用例，然后在細(xì)化階段的初期將業(yè)務(wù)用例轉(zhuǎn)換成體現(xiàn)了“目前的”系統(tǒng)的用例?，F(xiàn)在我們是在細(xì)化階段的最激烈的時刻，我們正準(zhǔn)備細(xì)化我們的用例，為系統(tǒng)完成向詳細(xì)需求的轉(zhuǎn)換。這個演進是自然形成的，因為直到斷定了是否我們開始定義的用例是正確的，我們才可以為用例進行更為詳細(xì)的信息添加。一旦詳細(xì)的系統(tǒng)需求被完成，我們將它作為一個正式的交付物被 ASDI 審查通過。
 |
| 圖 1: 第 1 階段用例的演進 |
標(biāo)準(zhǔn)化用例文檔
在我們與 ASDI 對用例進行非正式的檢查的會議中我們對用例進行了注釋。用例圖和包也被我們的高級團隊成員定期的檢查了，一個“健全的” 檢查將帶來以下的結(jié)果：
我們現(xiàn)在的重點是記錄我們已經(jīng)了解到的東西。我們與 ASDI 在用例文檔的形式上達(dá)成了一致，并且我們非常高興他們愿意接受在 Rose 模型 中對每一個用例直接添加文檔的方式。這對于我們來說，事情變得更加簡單了，因為這意味著更低的對文檔美觀的期望。
在多個團隊成員共同工作的情況下，我們發(fā)現(xiàn)我們需要標(biāo)準(zhǔn)化與每個用例相關(guān)聯(lián)的文檔。因此，我們起草一份用例的文檔模板，并應(yīng)用于 Rose 模型的每個用例中。在圖 2 中顯示的內(nèi)容是被粘貼到每個用例作為模板的文檔窗口。注意我們在這個模板中使用術(shù)語 “variation” 作為對 RUP 可選流概念的速記標(biāo)記。
 |
| 圖 2: 用例文檔模板 |
在項目的后來，我們意識到在模型（*.mdl 和 *.cat）文件中有大量 ASCII 形式的文檔，使模型的加載慢了下來。感謝我們的快速的電腦，這個副作用還可以被容忍，但是在后來的項目中我們使用了更加正式的方法來維護用例的內(nèi)容，通過一個自定義接口的方式（就像在文章 Fine Tuning Rose to Complement Your Process 所討論的那樣）。另一個可選的方法是使用 Rose 附帶單獨的 Microsoft Word 文檔到用例的特性（通過右鍵點擊用例并從上下文菜單中選擇 New > File ）。
用例的可跟蹤性
ASDI 原來的期望是 SOW 將最終成為一個大的文字形式的文檔。我們通過與他們的不斷的討論，最終他們意識到這種方法的缺點，并作出了讓步的姿態(tài)。他們現(xiàn)在明白了使用用例的好處并很快的掌握了相關(guān)的概念，并理解了使用用例將給他們一種不需要對模型進行預(yù)排的非常強大并適當(dāng)?shù)姆答伒姆绞?。無論如何，一個好的時間和精力的分配已經(jīng)進入了 SOW ，可以理解 ASDI 希望我們能夠確保不會遺漏任何在 SOW 中被捕獲的東西。
為了提供這個保證，我們使用了 Rational 的工具來建立在 SOW 需求和我們的相當(dāng)穩(wěn)定的用例之間的可跟蹤性。首先我們通過 RequisitePro 將 Rose 模型與被管理的需求文檔關(guān)聯(lián)起來，通過選擇 Tools > Rational RequisitePro > Associate Model to Project 并選擇 SOW 。然后我們相應(yīng)的映射每一個用例到主 SOW 需求，通過右鍵點擊用例并在上下文菜單中選擇 Requirement Properties > New 。如圖 3 所示，我們展示了一個 SOW 需求列表，并從中選擇適當(dāng)?shù)男枨蟆?/p>
 |
| 圖 3: 關(guān)聯(lián)需求與用例 |
我們已經(jīng)在模型中建立起了這些關(guān)聯(lián)，我們可以跟蹤需求到用例，相反也可以。雙向的可跟蹤性是十分重要的，因此我們既可以發(fā)現(xiàn)遺漏的需求也可以發(fā)現(xiàn)新添加的需求。遺漏某一需求是不可接受的，跟蹤需求到用例可以使我們很容易的發(fā)現(xiàn)我們的任何遺漏。添加需求而沒有清晰的調(diào)整將導(dǎo)致項目范圍的蔓延并對項目的時間計劃和預(yù)算有著負(fù)面的影響。為了防止這一切，我們應(yīng)該跟蹤所有的用例到每一個存在的 SOW 需求或者變更請求。
不像跟蹤需求到用例，反方向的跟蹤經(jīng)常被忽略，但是我們可以很容易的在 Rose 中完成這一點。為了瀏覽與一個用例相關(guān)聯(lián)的 SOW 需求，我們簡單的在 Rose 模型中右鍵點擊用例，并選擇從上下文菜單中選擇 View RequisitePro Association 。這會彈出一個窗口指示哪一個 SOW 需求是被選擇的用例跟蹤的，如圖 4 所示。如果用例沒有被映射到一個 SOW 需求，底部的兩個域?qū)@示 “NONE” 。我們也可以通過 Rational SoDA 產(chǎn)生更加復(fù)雜的跟蹤報告。
 |
| 圖 4: 被 Rose 報告的對于一個用例的 SOW 需求 |
注意在這個方法中使用一個捷徑是重要的。通過我們使用的方法，我們可以僅僅可以每次關(guān)聯(lián)一個用例到一個需求，反之亦然；然而，一個用例實際上是可以跟蹤回到幾個需求的，同樣一個需求可能分布到多個用例中。我們不必苦惱映射多對多的關(guān)系。我們直接將用例關(guān)聯(lián)到 SOW 中的需求，但是更好的方法是引入一個被 RequisitePro 管理的用例規(guī)格文檔，它包含很多用例需求的文字描述并可以實現(xiàn)多對多的映射。（詳細(xì)的描述可以在 Rational 白皮書 Use Case Management with Rational Rose and Rational RequisitePro 中被找到。）我們現(xiàn)在覺得用例規(guī)格文檔是我們不應(yīng)該跳過的重要步驟。
用例文檔的檢查周期
我們與 ASDI 都明白文檔頻繁的檢查周期會導(dǎo)致無止境的循環(huán)下去。結(jié)束任何文檔都是困難的，因為每一次閱讀文檔時檢查人員經(jīng)常會產(chǎn)生一些新的想法。在迭代的方法中，相同的 “何時結(jié)束的” 的挑戰(zhàn)也會出現(xiàn)在軟件的文檔和其他任務(wù)中。為了滿足 ASDI 對關(guān)于結(jié)束的關(guān)心，我們描述了我們對用例文檔的檢查周期將是什么樣的，我們努力的借用了 RUP 中所描述的概念（見圖 5）。
 |
| 圖 5: 文檔檢查周期圖 |
就像你所看到的，我們的每一個文檔都經(jīng)過了一系列的迭代。對于我們來說找到一個工具來支持它是重要的，我們在 Rational SoDA 中發(fā)現(xiàn)這樣一個工具，它允許我們生成 Rose 模型以外的文檔。雖然對文檔直接做修改是誘人的，但是這將帶來文檔與模型不同步的風(fēng)險。如果你將在一個或其他的文檔中投入精力，更好的方法是在模型中投入精力。除了你開發(fā)的軟件用戶手冊以外，模型幾乎是可以在軟件被交付后還可以繼續(xù)被引用和維護的產(chǎn)物。
通過使用 SoDA ，產(chǎn)生報告是簡單的。為客戶的檢查生成用例文檔，我們從 Rose 的 報告菜單中選擇 SoDA Report ，這將出現(xiàn)一個報告模板的列表，如圖 6 所示。從中我們選擇 a RUP use-case model survey 模板。
 |
| 圖 6: SoDA 報告選擇 |
每一個模板提供了一個缺省的報告（作為 Microsoft Word 文檔）伴隨一個空的部分和相應(yīng)的內(nèi)容表格（TOC）。圖 7 顯示了我們選擇報告的 TOC 。我們通過與 ASDI 檢查 TOC 開始，并且我們查看了我們的用例以決定是否需要在報告中根據(jù)我們的需要進行合適的裁剪。
|
| 圖 7: SoDA use-case survey 報告（TOC） |
你可能想知道在寫任何實際的內(nèi)容之前，為什么我們擔(dān)心與 ASDI 一起檢查 TOC 。我們發(fā)現(xiàn)這是一個重要的步驟。有時 ASDI 給我們一個 DID （數(shù)據(jù)項描述），它對正式的交付物提供一個 TOC ，但是我們發(fā)現(xiàn)在開始充實內(nèi)容之前根據(jù) TOC 從 ASDI （或者內(nèi)部的團隊檢查人員）得到信息是有用的。有時我們在每一個部分填寫顯示我們將如何細(xì)化的標(biāo)題，但是在首次的 TOC 檢查時幾乎沒有任何的段落內(nèi)容。
后續(xù)的文章部分將討論 Rational SoDA 和 模板定制的更加詳細(xì)的信息。
細(xì)化：不只是用例
為了使生活更加有難度， ASDI 期望我們在繼續(xù)隨后的任務(wù)之前創(chuàng)建用例文檔。我們必須提醒他們用例文檔直到軟件被交付才會被 “完成” ，除非他們不想讓我們在需求變化或者新需求出現(xiàn)時更新用例。我們說服了他們，他們不會對完成的 里程碑甚至是 自信的里程碑感興趣。然而，他們希望放一個檢查標(biāo)記到下一個要做的 “詳細(xì)的用例文檔”項，因為它是十分成熟的，我們同意這個觀點。
真正的挑戰(zhàn)是說服 ASDI 所有需要的活動應(yīng)該是并行的發(fā)生，而不是所有的里程碑都是按照順序被交付的。我們把它作為在項目早期的一個常規(guī)的關(guān)注點，它仍然沒有被完全的解決。為了讓他符合用例分析的一些活動，我們提出了這兩個觀點：
我們非常高興 ASDI 同意模擬和原型作為分析階段的有用的部分。這使我們可以在用例分析被完成前進入到架構(gòu)的和工具的選擇問題中。
選擇工具和技術(shù)
工具和技術(shù)選擇從來就不是微不足道的任務(wù)，雖然它常常被忽略。團隊經(jīng)常根據(jù)啟動成本、“小工具因素”、好奇心或者對工具和技術(shù)的忠心來作出選擇，相反，他們應(yīng)該考慮生產(chǎn)成本、可靠性、可得到的培訓(xùn)、團隊技能和特性標(biāo)準(zhǔn)。在評估過程中添加一些正式手續(xù)可以確保工具的選擇使基于項目需要的而不是個人主觀的意見。
正式的工具評估
一個在 RUP 中很少關(guān)注的地方是團隊挑選現(xiàn)貨（off-the-shelf）— 也稱作商業(yè)現(xiàn)貨供應(yīng) (COTS) — 工具的過程?？梢粤私膺@個過程領(lǐng)域知識的一個地方是卡內(nèi)基－梅隆軟件工程學(xué)院（SEI），那里有 COTS-Based Systems Initiative 關(guān)注于 COTS 產(chǎn)品的選擇和采納的策略。特別有趣的是 SEI 的 product feature checklist ；雖然它更關(guān)注于選擇軟件系統(tǒng)的組件和框架，但是其中的很多策略也可以被用于選擇軟件開發(fā)工具、Web 服務(wù)、數(shù)據(jù)庫等等。
工具選擇標(biāo)準(zhǔn)
ASDI 向我們展示了這些他們覺得將影響我們的工具選擇的標(biāo)準(zhǔn)：
應(yīng)用服務(wù)器的選擇
我們擁有 J2EE 應(yīng)用服務(wù)器的經(jīng)驗，因此我們非常幸運 ASDI 選擇基于 Java 方案。不過在我們還是快速的評估了象 Perl/CGI 和 PHP 這樣的入門級的 Web 方案之后的計算技術(shù)（主要是 Microsoft .NET/DNA）。
我們一致發(fā)現(xiàn) Orion Application Server 是友好的并是最成本有效的開發(fā)環(huán)境。在那里 Orion 唯一評分低的方面是 供應(yīng)商的穩(wěn)定性和支持。提供 Orion 產(chǎn)品的公司是非常小的并且不具備象 BEA 的 WebLogic 或者 IBM 的 WebSphere 的能力和信譽。然而在與 ASDI 的檢查人員討論后，我們互相同意 Orion 的 J2EE 標(biāo)準(zhǔn)遵從的好處足以抵消這些風(fēng)險。如果第二階段開發(fā)需要，仔細(xì)的開發(fā)將可以確保我們擁有輕便的可以移植到其他應(yīng)用服務(wù)器方案的代碼。因此我們選擇了 Orion — 這意味這啟動成本為零，因為 Orion 是免費的。
Web 服務(wù)器選擇
Orion 帶有高速的內(nèi)建的 Web 服務(wù)器，因此當(dāng) Orion 被選定后 Web 服務(wù)器的選擇過程也就有了結(jié)論。它主要的競爭對手是 Apache 。然而，在 Orion 網(wǎng)站上顯示 Orion 已經(jīng)在某些測試方面達(dá)到并超過了 Apache 。
數(shù)據(jù)庫選擇
使用哪一個數(shù)據(jù)庫的選擇不是顯而易見的。數(shù)據(jù)庫通常不會執(zhí)行高負(fù)載，但是它需要有豐富的特性支持。比如，復(fù)雜的數(shù)據(jù)關(guān)系要求有完全的引用完整性限制。同時，系統(tǒng)必須可以 24 小時不間斷運行，因此我們希望它具有熱備功能、復(fù)制、其他的可用性和容錯特性。我們是否會用到所有的特性將在以后被決定。
我們覺得 PostgreSQL 僅僅是一個有資格的開放源碼的候選者。它有很好的 ANSI SQL 支持和引用完整性，并且只要并發(fā)用戶的增長不太大它可以保持良好的性能。然而，數(shù)據(jù)存儲需要更多的來自于一個供應(yīng)商的 committed 支持。此外，我們覺得 PostgreSQL 在線支持（比如用戶社區(qū)討論）對我們來說是不夠的。MySQL 實際上是更加流行的開放源碼的數(shù)據(jù)庫，但是它缺少太多的特性（比如，外鍵支持）。
然后我們轉(zhuǎn)到主流的數(shù)據(jù)庫：DB2， Oracle， and Microsoft SQL。我們在 Oracle 上有著豐富的經(jīng)驗，但是新的處理器單元價格模式對于我們的這個應(yīng)用來說是過于昂貴了。Oracle 的每 MHz 每 CPU 的基本負(fù)荷，意味著 ASDI 將為系統(tǒng)忍受高的生產(chǎn)環(huán)境成本，除非他們愿意將 Oracle 安裝在一臺 P-133 的機器上。Microsoft SQL 被淘汰了，因為它是基于私有平臺的。如果創(chuàng)建一個基于 DNA 的方案，Microsoft SQL 自然是首選的，但是對于 J2EE 來說很少被選擇的。
最后，我們選擇了 DB2 ，我們的調(diào)查表明 DB2 對 SQL 有著非常優(yōu)秀的支持、強大的容錯特性、公道的價格模式和正在增長的和被培訓(xùn)的在線用戶集合。 IBM 的 JDBC 驅(qū)動是高性能的，而且他們的個人版可以被免費的用于開發(fā)團隊中。不幸的是，我們?nèi)狈?DB2 的技能，這就意味著一些培訓(xùn)在原型活動期間被需要。
你也許正想知道對于 ASDI 首選的 OODB 的選擇發(fā)生了什么。在通過原型和探索產(chǎn)品后，我們很快個到了結(jié)論，使用 OODB 得到的好處不足以抵消它帶來的風(fēng)險。關(guān)于這個的更多思想，看下面的文章 引用和其他資源 。
集成開發(fā)環(huán)境（IDE）選擇
在這一點上，我們不想使用任何高端的 IDE 產(chǎn)品，有幾個原因：
相反，我們混合使用了以下工具：
很自然，這些工具可通過使用 Rational 工具來彌補在測試、調(diào)優(yōu)和代碼覆蓋上的缺乏。
總結(jié)
在這個階段我們看到了用例的演進（通過可跟蹤性和文檔化）并且通過 ASDI 參與的用例的檢查，我們快速的發(fā)現(xiàn)我們是自由主題方式的專家。這通常是軟件開發(fā)項目中的最大挑戰(zhàn)之一，因此早期的并有效地建立這種關(guān)系才是真正的勝利。我們與 ASDI 的關(guān)心通常是很好的。他們很快的理解并同意了基于 RUP 的開發(fā)過程而沒有花費我們太多的精力。這是令人驚訝的，被他們給的首選的瀑布型的開發(fā)最終取得了這個和約。很多被 RUP 鼓勵的迭代和增量開發(fā)的方法被良好的進行了調(diào)整，并且 ASDI 也看到可好處。
我們幸運的是工具的選擇相當(dāng)?shù)暮唵危⒃陧椖康脑缙诒煌瓿伞ational 的一些工具被用來節(jié)省我們的時間。在之前的項目中我們使用 Excel 來管理需求，但是我們發(fā)現(xiàn) Rational RequisitePro 是一流的并是完整的方案。此外， Rational SoDA 報告可以大大的降低我們的文檔生成的成本。因為這個項目是我們第一次使用 SoDA，我們非常高興 ASDI 對標(biāo)準(zhǔn)的 SoDA 模板表示滿意。
計劃未來
到現(xiàn)在為止，我們把焦點放到了需求相關(guān)的產(chǎn)物上，并且花費了相對來說不多的時間來評估技術(shù)并創(chuàng)建原型以支持工具的選擇?，F(xiàn)在對我們來說重要的是通過創(chuàng)建更有挑戰(zhàn)的原型來揭示系統(tǒng)更加復(fù)雜的領(lǐng)域，并開始在實際的開發(fā)中使用工具。我們是否會用到 XML ？如果會用到，我們應(yīng)該使用什么樣的解釋器？我們需要什么樣的安全機制？我們應(yīng)該使用 Enterprise JavaBeans 嗎？象這些問題我們將很快有答案。
換句話說，是時候從分析轉(zhuǎn)移到架構(gòu)和設(shè)計了 — 盡可能快而不是晚，因為大多數(shù)的技術(shù)風(fēng)險將在接下來的幾周顯現(xiàn)出來。我們有一個很好的功能基線包含一系列定義良好的用例。對于我們來說避免分析麻痹大意和維護前進的動力是重要的。
主要風(fēng)險
沒有新的風(fēng)險被識別出來；實際上我們的風(fēng)險列表比以前更短了。因為 ASDI 同意對于這個項目 OODB 是不合適的，我們因此不再有技術(shù)上的風(fēng)險要管理。他們也放松了對我們的交付產(chǎn)物的正規(guī)形式和他們預(yù)想的結(jié)構(gòu)，并且他們毫無保留的批準(zhǔn)了我們的基于 RUP 框架的文檔。
在我們關(guān)心的剩余時間和工作量的問題上，當(dāng)我們增加了對所需能夠的理解和對技術(shù)熟悉后，我們覺得預(yù)算更加符合項目情況了。更進一步的技術(shù)探索勿庸置疑的將揭開新的挑戰(zhàn)。
