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