用例分析技術學習體會（1）

用例分析學習筆記（1）

這幾天看了《用例分析技術》一書，感覺收益頗大，以前雖然也會或一些程式的流程圖但都是天馬行空，從來沒有什麼規律與計畫，想到了什麼就新增上什麼。在編碼的時候就是丟三拉四，經常是在程式除錯的時候，才想起忘了這個判斷，那個條件等等，總是弄得人焦頭爛額，很是疲憊不堪。

可是在經過用例分析技術的學習後，突然發現原來以前出現的那些問題可以這麼簡單地解決。特別是對於那些具有很多使用者，處理流程特別複雜的系統，採用用例分析是乙個不錯的選擇，它能為我們規劃出乙個清晰的整個事務的流程。廢話不多說了：

在進行用例分析之前，必須了解專案的範圍，也就是說要清晰確定系統的邊界，一般來說系統的邊界通過確定系統的執行者和用例來確定。

1.1執行者的確定

在確定執行者是必須注意到乙個問題就是，我們並不關心執行者的數量，我們只關心執行者的種類，即任何執行相同事務的人或者系統都同意歸納為乙個執行者。

1.2

用例的確定

在確定了執行者之後，我們比須為每個執行者定義清晰的用例，即每個執行者對系統操作了些什麼，對系統有什麼樣的功能需求，系統內部的變化要不要通知執行者。執行這怎樣來作業系統，具體的流程是什麼。在這個時候我們要對它有乙個大略的分析。

在確定了所有的用例之後，我們必須把所有的用例列在一張表上，並對其有詳細的描述，同時如果用例過多，我們可以採用包圖，對乙個業務活動中的所有用例進行封裝，使系統看起來更加的清晰。

1.3

歸檔用例

這個是用例分析中非常重要的一步，我們必須對每個用例有清晰的認識，識別每個用例屬於哪乙個業務活動（其實在用例確定的包圖就進行了用例歸檔）。

同時我們還應該把用例分為基本路徑與及可選路徑，基本路徑就是該業務活動正常操作時必須經過的路徑。而可選路徑指的是在該業務活動中產生了什麼異常，或者產生錯誤等的處理

1.4轉化為圖形表示

採用uml

的活**，時序圖對以上列出的用例表進行轉化，使開發人員對系統由乙個更加直觀的認識。

這僅僅是我閱讀該書的一點體會。詳細的介紹參考《用例分析技術》一書！