用例分析技術小結

前言

   現在RUP如日中天，需求分析是第一步，可以看作是高階系統分析員的必備知識，那麼，如果用物件導向的分析技術來描述需求呢？

   在一個需求分析過程中，主要有專案描述，風險分析，用例圖以及描述，專案建議這幾部分。

  其中最重要的，也是最需要學習的就是用例的描述。那麼用例的描述關鍵點在哪裡呢？

確定系統邊界

   確定清晰的系統邊界，就是要確定系統中有什麼？系統外有什麼？通過執行者和用例來確定系統邊界。

  那麼，我們第一步就是要找出執行者，執行者是一個角色，我們可以根據以下幾個問題來思考決定一下：誰在使用系統？誰在維護？誰在啟動?誰在關閉？誰從這個系統獲得資訊？誰為這個系統提供資訊？是否有自動的事情在預計時間發生？等等方式，來確定執行者。

   找出了執行者，那就要確定用例，用例是系統的一個行為，為執行者產生可以估量的價值結果。

用例的描述一般都是動名詞結構。

需要構建一張表，清楚的以名詞解釋的形式，把用例和執行者進行簡單的定義。

如果用例圖過於大，那就分開，也可以採用包的形式。

其中用例圖的中的箭頭表示是單向還是雙向，要根據交付的資訊看。

如果是外部定時發生的事情，可以把時間也作為執行者。

需求在系統之內，無法被執行者看到，那麼這個需求就不用在用例圖中體現。

歸檔用例

歸檔用例就是把用例用文件的方式表示。基本用例主要包括：前置條件（前置條件就是用例開始時候，必須要處在一個什麼狀態） 後置條件（用例結束，系統處在什麼狀態）事件流。（事件流是一系列的陳述句）。

 事件流中包含一些迴圈語句。可以採用for ,while迴圈。

 用例是一個傳達工具，只有向讀者傳達系統如何工作的時候才有效。

 用例要從執行者的觀點來寫。

 對於非事件流的需求，可以在用例的特殊需求中描述。

事件流分為兩部分：基本路徑和可選路徑。

   一切正常運轉就是基本路徑。

   不同於基本路徑而允許選擇不同的事件序列的路徑，就是可選路徑，也可以說各種異常情況的處理也是可選路徑。

   可選路徑，最好用不同的段落編號來標示。

 什麼是場景？ 場景就是一種貫穿用例的特定路徑。

用例的包含：如果你發現在寫各種用例的時候，要經常copy同一部分的內容，那麼就說明你有了一部分通用的行為，那麼就可以用一種包含關係來抽象這種通用行為。包含用例一定要有被包含用例，這個用例才算完整。

用例的擴充套件：在不改變原始用例的情況下，增加用例的行為。重要關注的一個概念是擴充套件點，當到達這個擴充套件點，如果條件為真，就是這個擴充套件條件的前置條件為真的話，這個擴充套件的步驟將被執行。

用例的繼承：用例的繼承代表一個用例（子）是另外一個用例（父）的特殊實現，執行者的繼承意味著一個執行者（子）可以完成另外一個執行者（父）的任務。

介面：介面不是執行者和用例的一部分。介面是執行者和用例相互作用的一種描述。

 文件中的文字可以簡潔的描述系統，那麼有些文字分支很多的時候，採用圖就是一個非常好的方式，圖形化用例也是一個不錯的手段。我們可以用三種圖來細化和具體化用例。

   活動圖：描述用例的步驟。活動圖描述滿足用例需求而進行的活動以及活動之間的關係。（有些書把活動圖定義為狀態圖的子集）

   時序圖：描述執行者和系統的相互作用。時序圖中，每個實體下面有虛線，代表物件生命週期。確認的返回值，是採用虛線箭頭來表示。

   在學會寫用例以後，那就有一個問題，用例寫到什麼程度好呢? 就是用例細化到什麼程度為好。要回答這個問題，需要考慮三個問題： 誰需要閱讀並審批這個文件？誰需要使用這個文件？我們要這個文件做什麼？用例可能是給終端使用者和開發者的，或者管理者的，決定多少細節放到用例中是一個很重要的事情。可以對同一個用例做不同細節程度的版本，交給不同的人看，要注意維護這種對應關聯關係。

   用例文件模板：

     包括系統簡介，風險因素，系統級用例（一個或者多個反映系統中所有用例和執行者的圖，沒必要包含用例之間的關係，例如包含，擴充套件和泛化），體系結構，子用例，非功能性的需求包括可用性，系統，安全，永續性，冗餘性，效能，規模，標準化等。

   可以通過活動圖來描述和表現用例之間的關係和流程。

劃分大型系統：

   如果是做一個大系統，那麼把大系統劃分為小系統就是一個非常重要的事情！先選出系統中最重要的部分。主要的體系架構有如下幾種：

一、MVC結構，一層用來顯示，一層用來控制，一層用來資料儲存。例如JSP,Struct就是這種架構。

二、管道和過濾器體系結構。主要思想就是一個部分輸入資料，處理資料，然後輸出，下一個部分接收，處理，依次類推，例如freeRadius，JRadius就是這種架構。

三、物件導向的體系結構模式。系統是根據資料來定義，並且和各種功能相聯絡。可以使用用例驗證體系結構，每一個子系統應該有：

       ---單一的功能性

       ---強聚合性---它的各個部分彼此之間具有很強的相互關係

       ----鬆耦合性---其工作的完成不太依賴於其他子系統

       ----與其他子系統最少的通訊----子系統之間不進行大量的通訊。

介面中的操作來自時序圖。將每個子系統看作一個整體的系統，每個系統都有執行者和用例。不斷的把大系統分為各種小系統，當系統足夠小的時候，無需更多的劃分就有足夠的細節來實現。

主題摘要：主題摘要就是指我們在用例中使用或處理的東西。是建立系統的基本元素，是描述域的一種方式。 簡單的尋找主題摘要的方法是：查詢用到的實體或資料。通過時序圖來繪製場景，可以把系統物件換成主題摘要，把子系統也換成系統摘要，這樣，傳送給子系統的訊息就改為傳送給主題摘要和執行者的資訊，並且最重要的是要確定主題摘要的行為，確定主題摘要以及他們的行為，就為類的設計打下了基礎。

  通過時序圖，我們發現主題摘要，也就可以找出摘要必須作出相應得訊息，然後把訊息對應到用例的參與類中，參與類檢視就是告訴我們要開發哪些類。

  用例試圖顯示了系統中的工作流程，是黑盒測試和使用者指南的基礎。

  子系統檢視顯示了構成該系統的子系統，是系統重用和維護的基礎。

用例檢視是展示了系統的外觀，只系統檢視是顯示了構成該系統的子系統，一個是從客戶角度，一個是從開發角度。

通常是在第一次迭代處理風險最高的，第二次迭代處理次之風險。

通過用例來估算工作：

1、  執行者加權

 

執行者型別	描述	因子
簡單	程式介面	1
普通	互動和協議驅動介面	2
複雜	（圖形介面	3

2、  用例加權：

           

用例型別	描述	因子
簡單	最多3個事務，最多5個分析類	5
普通	4-7個事務，5-10個分析類	10
複雜	多於7個事務，多於10個分析類	15

 

事務的概念在這裡是一個路徑，包括可選路徑，是一組原子操作。

用例的加權總數和執行者的加權總數相加，就得到了未經調整的用例點 (UUCP)

3、  技術因子加權：計算專案技術的複雜性，可以利用技術複雜性因子。從0到5確定每一個因子的等級。0等級意味著這個因子與專案不相關，5代表它是最重要的。然後用因子去乘每個因子的權重，然後相加。

     

因子編號	因子描述	權重
T1	分散式系統	2
T2	響應性或吞吐能力	1
T3	終端使用者效率	1
T4	複雜的內部處理	1
T5	程式碼必須可以重用	1
T6	易於安裝	0.5
T7	易於使用	0.5
T8	可移植性	2
T9	易於更改	1
T10	併發	1
T11	包括特殊的安全性	1
T12	為第三方提供直接訪問	1
T13	需要特殊的使用者培訓設施	1

      TCF=0.6+(0.01*TFactor)   TFctor=所有（權重 *  等級）相加之和。

4、  小組的環境因子和權重. 從0到5確定每一個因子的等級。0等級意味著這個因子與專案不相關，5代表它是最重要的。

         

因子編號	因子描述	權重
F1	熟悉RUP	1.5
F2	使用經驗	0.5
F3	物件導向經驗	1
F4	領導分析能力	0.5
F5	動力	1
F6	穩定的需求	2
F7	兼職人員	-1
F8	有難度的程式語言	-1

     EF=1.4+(-0.01*EFactor )    EFactor=所有（權重 *  等級）相加之和 

   最後計算用例點（UCP）

     UCP=UUCP * TCF * EF

    然後進行專案估算，看看F1—F6 有幾個低於3， F7—F8有幾個高於3，然後把這兩個數加起來等於 N

      

N的範圍	UCP工時
N<=2	每個UCP 20個工時
3<=N<=4	每個UCP28個工時
N>5	調整專案

     工時=N* UCP

那麼，採用這種方法，就估算出來了工時.