第 4 部分 ：分析和工具的進展

Steven Franklin
軟件設計師和過程專家
2004 年 4 月

在這個展示了 RUP 和其他 Rational 工具使用的樣例項目的接下來的階段，用例通過添加文檔和可跟蹤性到需求被細化，并且使用的工具和技術被評估和選擇。

這個第 4 部分文章的重點在于 ASDI 項目的細化階段，尤其是在用例分析方面（細化我們的用例以對工作狀態（SOW）添加可跟蹤性，并且標準化和生成用例文檔）并選擇合適的工具和技術。

在第 4 部分演示的工具和技術：

• Rational Rose 企業版 — 用于用例細化
• Rational SoDA — 為客戶檢查的低成本的產生用例文檔的工具
• Rational RequisitePRo — 用于治理 SOW 需求和用例之間的可跟蹤性

產生或者被更新的產物：

• Rational Rose 模型 — 被修改并在用例的各個方面添加了更加具體的內容
• 用例報告 — 用 Rational SoDA 從 Rose 用例中生成
• RequisitePro 數據庫 — 被更新以包括SOW 需求和用例之間的可跟蹤性

細化并文檔化用例
圖 1 顯示了在 ASDI 項目的第 1 階段（RUP 的初始和細化階段）中的用例的演化。就像我們在第 3 部分討論的，我們在初始階段創建了業務用例，然后在細化階段的初期將業務用例轉換成體現了“目前的”系統的用例?，F在我們是在細化階段的最激烈的時刻，我們正預備細化我們的用例，為系統完成向具體需求的轉換。這個演進是自然形成的，因為直到斷定了是否我們開始定義的用例是正確的，我們才可以為用例進行更為具體的信息添加。一旦具體的系統需求被完成，我們將它作為一個正式的交付物被 ASDI 審查通過。

標準化用例文檔
在我們與 ASDI 對用例進行非正式的檢查的會議中我們對用例進行了注釋。用例圖和包也被我們的高級團隊成員定期的檢查了，一個“健全的” 檢查將帶來以下的結果：

• 將不穩定的或者遺漏的方面反饋給組長
• 有用的分析建議、模式和功能分解方面的考慮
• 一致的系統視圖
• 工程團隊對具體需求的交流

我們現在的重點是記錄我們已經了解到的東西。我們與 ASDI 在用例文檔的形式上達成了一致，并且我們非常興奮他們愿意接受在 Rose 模型 中對每一個用例直接添加文檔的方式。這對于我們來說，事情變得更加簡單了，因為這意味著更低的對文檔美觀的期望。

在多個團隊成員共同工作的情況下，我們發現我們需要標準化與每個用例相關聯的文檔。因此，我們起草一份用例的文檔模板，并應用于 Rose 模型的每個用例中。在圖 2 中顯示的內容是被粘貼到每個用例作為模板的文檔窗口。注重我們在這個模板中使用術語 “variation” 作為對 RUP 可選流概念的速記標記。

在項目的后來，我們意識到在模型（*.mdl 和 *.cat）文件中有大量 ASCII 形式的文檔，使模型的加載慢了下來。感謝我們的快速的電腦，這個副作用還可以被容忍，但是在后來的項目中我們使用了更加正式的方法來維護用例的內容，通過一個自定義接口的方式（就像在文章 Fine Tuning Rose to Complement Your Process 所討論的那樣）。另一個可選的方法是使用 Rose 附帶單獨的 Microsoft Word 文檔到用例的特性（通過右鍵點擊用例并從上下文菜單中選擇 New > File ）。

用例的可跟蹤性
ASDI 原來的期望是 SOW 將最終成為一個大的文字形式的文檔。我們通過與他們的不斷的討論，最終他們意識到這種方法的缺點，并作出了讓步的姿態。他們現在明白了使用用例的好處并很快的把握了相關的概念，并理解了使用用例將給他們一種不需要對模型進行預排的非常強大并適當的反饋的方式。無論如何，一個好的時間和精力的分配已經進入了 SOW ，可以理解 ASDI 希望我們能夠確保不會遺漏任何在 SOW 中被捕捉的東西。

為了提供這個保證，我們使用了 Rational 的工具來建立在 SOW 需求和我們的相當穩定的用例之間的可跟蹤性。首先我們通過 RequisitePro 將 Rose 模型與被治理的需求文檔關聯起來，通過選擇 Tools > Rational RequisitePro > Associate Model to Project 并選擇 SOW 。然后我們相應的映射每一個用例到主 SOW 需求，通過右鍵點擊用例并在上下文菜單中選擇 Requirement Properties > New 。如圖 3 所示，我們展示了一個 SOW 需求列表，并從中選擇適當的需求。