【UML實戰智慧第10回】用模型走查找出UML軟體無法查驗的問題

程式設計師在編寫完程式碼、交付之前，可以先進行人工的「代碼走查」（code walkthough），以便確保程式碼的品質。

同樣地，系統分析師在做完每一個使用案例，並且將使用案例涉及的領域概念，也同步萃取彙整到領域模型之後，也是可以學習代碼走查的精神，也來先進行人工的「模型走查」（model walkthough）。

一般來說，從業務流程、使用案例到領域模型，甚至是功能架構、畫面雛型、操作流程、實體關聯圖（Entity-Relational Diagram），其實彼此之間都存在一些關聯性，有些關聯性很明顯直觀，有些關聯性潛藏其中需要動動腦、仔細思考推敲過後才能發現。

這些關聯性很多無法透過UML軟體工具來查驗，只能透過人工方式走查一下，找出模型中遺漏的、矛盾的、不合理的、不適當的或者不一致的地方。所以，接下來，就讓我們以使用案例為單位，一個一個仔細走查一番吧！

查詢基金基本資料
關於查詢基金基本資料這個使用案例，系統分析師初步產出的項目有：如圖1的使用案例圖、圖2的查詢基金基本資料的使用案例敘述、如圖3彙整過後的領域模型。

走查功能架構圖與使用案例圖
首先，我們可以先確認，是否可以從功能架構圖追蹤到使用案例圖，這是需求管理很重要的一環。如果，系統分析師可以直接採用使用案例做為功能架構圖中的功能，這樣就最好不過了。

請你看到圖4的示意圖，這邊要走查的是比較簡單直觀的一致性問題，看看功能架構圖中的系統、功能模組、使用案例的名稱是否與使用案例圖中的元素一致，或者是可以直覺對應追蹤得到，這樣也是可以的。

另外，還要查看一下，使用案例所歸屬的功能模型是否正確無誤。若是功能模組和底下的功能，是客戶╱使用者（甲方）在徵求建議書（RFP）中明文規定的，那就沒什麼爭議；要是系統分析師自己訂的，可能要再徵求或取得客戶的同意，看看功能模組的切割、名稱、底下的功能歸屬是否恰當，這樣可能會比較妥當些。

走查使用案例圖

接著，我們來走查查詢基金基本資料的使用案例圖和敘述。一開始，最基本的檢查是圖示擺放的問題，看看參與者是否擺放在系統方框外部、使用案例是否擺在系統方框內部，如圖5所示。

不要小看圖示擺放的位置，這不是因為機車、龜毛，主要是因為UML是一個圖形語言，所以有些圖示其擺放的位置是有規範的。譬如，參與者是指系統外部的實體，所以當然要擺放在系統方框外部。另外，使用案例是指系統提供的服務或功能，所以當然得擺在系統方框內部。

此外，若是有擺放功能模組的話，也要記得擺放在系統方框內部，因為功能模組本來就是系統的內部結構。再者，也可以像此處的做法，在系統方框和功能模組方框最上方，使用雙角箭號標示出《系統》和《功能模組》以示區分，這樣會更明確清楚些。

走查使用案例敘述
接著，我們再來查看使用案例圖和使用案例敘述用語一致性的問題。首先，建議使用案例敘述中的流程，每一個步驟都以參與者和系統為起頭。無論是主要參與者或次要參與者，都可以做為步驟句子的起頭。

系統是指提供使用案例的基金系統，使用案例敘述中可以簡略寫「系統」即可，如圖6。

接著，我們繼續走查使用案例圖與敘述發現兩項疑點，如下：

1. 從使用案例圖面及敘述看起來，查詢基金基本資料這個使用案例的啟動者是銀行客戶，但是銀行客戶會直接使用基金系統來查詢基金基本資料嗎？

2. 再者，銀行內部的人員都沒有查詢基金基本資料的需求嗎？

參與者最好可以直接使用系統
向系統分析師詢問之後，才了解銀行客戶其實不會直接使用基金系統，而是透過網路銀行連進來基金系統，才能夠查詢得到基金基本資料，就如同圖7的示意圖。

在這種情況下，建議改用直接連線到基金的網路銀行，做為啟動使用案例的主要參與者，可能會比較恰當。這樣一來，我們就可以從使用案例圖面上，立即判斷出這是個不需要設計畫面雛型的使用案例，如圖8所示。

千萬別小看這樣的判斷，系統分析師多提供一個畫面雛型、系統設計師多設計一個畫面、程式設計師多實作一個畫面、甚至得請美編人員設計版面，這都是需要多花時程和成本的。專案時程估算的不準確，都是一點一滴的不準確累積起來的，所以可以兼顧到的，就盡量兼顧到吧！

多個主要參與者的處置

暫時解決了第一個疑點，而剛才的第二個疑點是－銀行內部的人員像是理財專員等等的人員，都沒有查詢基金基本資料的需求嗎？還是說，理財專員也是透過網路銀行連線到基金系統的。這個疑點可能會涉及到，是否有遺漏了畫面雛型的情況。系統分析師向客戶╱使用者詢問的結果是，確實需要多設計一個畫面雛型，讓理財專員可以在銀行現場中能夠直接使用基金系統，來查詢基金的基本資料。

如果要在使用案例圖面上，同時滿足銀行客戶透過網路銀行查詢基金基本資料，而且理財專員也可以在銀行現場查詢基金基本資料的話，可以有下列三種表示法，如圖9、圖10和圖11所示。

請你先看到圖9，切分成兩個名稱一樣的使用案例，只是其中一個使用案例多了（含UI）的字眼。這有兩個問題：

1. 只有一兩個這種情況的使用案例時，還可以勉強接受，可是如果這樣情況的使用案例多出現幾個，可就吃不消了，這會造成使用案例圖面上雜亂不堪。

2. 同時考慮使用案例敘述的內容，可能會有多處步驟都相同，甚至全數相同的狀況。因為這兩個使用案例的差別，可能只是在是否需要透過圖形介面操作；或者由網路銀行自行提供圖形介面，而基金系統僅提供網路服務（Web Service）供基金系統調用。

接著來看圖10，兩個參與者共用一個使用案例，而且也使用{or}字眼來限制兩者不會同時參與這個使用案例。換句話說，某一個時刻下，系統正在執行查詢基金基本資料的使用案例時，參與者可能是銀行客戶或者是理財專員，二擇一。

特別注意，如果沒有標示{or}的話，意味著系統在執行使用案例時，需要兩個參與者同時參與才行。所以，在查詢基金基本資料的案例中，圖11所要傳達的概念，是不正確的。

最後來看圖12，在參與者端使用{or其他參與者1,其他參與者2}的方式，來表達多個不同的參與者的情況。經由與系統分析師們開會討論的結果，決定統一採用圖12的表示法，既簡潔又可以明確列出所有參與者。

不過，在跟系統分析師們會議時，系統分析師提出了一個疑問，就是到底使用案例圖面上要留理財專員還是網路銀行呢，如圖13所示。最後，我們討論的結果是留下理財專員，因為這個參與者會涉及到畫面雛型，把它留在使用案例圖面上可以提醒系統分析師別遺漏了畫面雛型。

多個主要參與者的使用案例敘述
還沒完呢，最後我們還得修改使用案例敘述，讓它可以與圖12可以搭配起來，主要修訂下列三處，如圖14：

1. 增加一個主要參與者欄位，用來說明查詢基金基本資料這個使用案例，可以有兩個主要參與者。

2. 在原先的主要流程處，標示出（for理財專員），同時也將主要流程中有提及主要參與者的地方，一併改成「理財專員」。

3. 由於，網路銀行所需要的資料項目不同，所以我們增加了一個主要流程（for網路銀行）。

補上畫面雛型和操作流程

此外，還需要補上一個給理財專員使用的畫面雛型，如圖15所示。

最後，還可以請系統分析師提供一些簡單的操作流程，如圖16。

找出遺漏的資料項目
走查使用案例敘述與領域模型的要點主要是，查看是否有遺漏資料項目（屬性）、業務規則和重要動作（操作）。這類單純查詢資料的使用案例通常只要注意有沒有遺漏屬性，像是此處可以找到的資料項目，如下：

● 基金：基金名稱、基金編號、目前淨值、幣別、經理人名稱、最低投資金額、手續費費率、管理費費率。

● 基金公司：基金公司名稱、基金公司編號。

由於，查詢基金基本資料涉及到基金公司和基金，所以我們先把這兩個類別找出來，如圖17所示，方便一一比對屬性名稱是否一致，以及是否有漏列了屬性。

找出遺漏的業務規則或重要動作
接著，我們還要走查是否有遺漏了業務規則和重要動作，但是這種簡單查詢資料庫的使用案例，比較不會有需要計算、查驗的業務規則。這類單純涉及資料庫處理的使用案例，最重要的動作大約就是存取資料庫了。

不過，資料庫的動作不算是涉及領域的重要動作，它只能算是重要的系統動作，況且存取資料庫的動作可以由系統設計師或程式設計師自行處理。所以，我們不打算把資料庫的動作列入領域模型中。

修改畫面雛型
如果，有畫面雛型的話，也可以一併比對畫面雛型上的用詞，看看是否有需要調整之處。畫面雛型的用詞不一定需要跟領域模型一模一樣，但是遇到不一致之處，還是可以詢問一下。像是原先畫面雛型（前面的圖15）中的「淨值」一詞，系統分析師詢問過客戶╱使用者的意見之後，就決定改成「目前淨值」，如圖18所示。