用UML做好系統分析
作者 邱鬱惠 發佈於 2008年6月19日
使用UML如何能讓我們做好系統分析的工作呢？就讓我們通過本章的基金模擬項目，先睹 爲快，搶先體驗一番。
CIM-1：定義業務流程
定義及分析業務流程（Business Process）是爲了儘快理清系統範圍，以便估算開發成本及時間，可不是爲了要改造業務流程。系統分析員千萬別誤解了此步驟的目的。所以，系統分析員在定義及分析業務流程時，要記得挑選跟系統有關的業務流程。
CIM-1定義業務流程的生成，主要有如下的業務用例圖和簡述。請看圖2-1的業務用例圖，圖中的每一個業務用例代表一條業務流程，業務執行者則代表位於企業外但會啓動或參與業務流程的人。投資人到銀行臨櫃申購基金，啓動了銀行內部的一段關於申購基金的業務流程。再者，投資人也可能臨櫃辦理贖回基金，這又引發了另一條業務流程。
至於業務用例簡述，簡潔扼要即可，我們主要用它來記錄和區分業務流程。
CIM-2：分析業務流程
通過CIM-1圈出了系統將參與的業務流程之後，針對每一個業務用例，系統分析員得開始分析它的工作流程，並且繪製活動圖（Activity Diagram）與業務人員取得共識。隨後到了CIM-3時，才能夠依此定義出系統可以協助之處，並且規劃出系統範圍。
此處，我們挑選一般的申購基金流程當示範，並繪製出如圖2-2所示的活動圖，展示了單筆申購基金的一般交易流程。
CIM-3：定義系統範圍
經過了CIM-1的定義業務流程，以及CIM-2的分析業務流程之後，終於進入到CIM-3這場壓軸戲了。CIM-1和CIM-2的生成文件，跟CIM-3的生成文件之間，有如下的關聯性：
- CIM-2活動圖中的每一個動作，都可能成爲CIM-3的系統用例。
- CIM-1中的業務執行者，以及CIM-2中的動作負責人，都可能成爲CIM-3的系統執行者（System Actor）。
針對上述的圖2-2一般流程的活動圖，我們分析得出如圖2-3的系統用例圖，以及下述的用例簡述。
PIM-1：分析系統流程
在CIM階段，系統分析員大約花1～2周的時間，儘快生成初步的系統用例，以便讓相關的決策人員可以從中挑選出首期開發的系統用例，而這也就是首期的系統範圍。
隨後，項目正式進入PIM階段，也是正式進入分析階段，所以系統分析員將投入更多的時間，針對首期的系統用例詳述規格，作爲正式需求文件的一部分，也作爲業務人員與開發人員之間的溝通文件。
所以，系統分析員在PIM-1的主要工作，將針對每一個系統用例，分析其內部細節，並編寫詳盡的系統用例敘述（UC Description）。UML並未提出標準的敘述格式可供遵守，不過系統分析員可以在網絡上找到許多實用的用例敘述格式，或者翻閱一些UML或用例相關書籍，也可以發現許多很有特色的用例敘述格式。
此處，我們示範編寫“網絡申購單筆基金”和“網絡申購定期定額基金”的系統用例敘述，如下圖2-4和圖2-5所示：
PIM-2：分析業務規則
企業通過一組規則（Buisness Rules）來控制整體的運作，包括人員、流程、系統、概念的運作，皆受制於業務規則。由此足見業務規則之重要，所以早從PIM-1的系統用例敘述，一直到此處的PIM-2狀態圖以及稍後的PIM-3類圖，我們都會要求系統分析員必需通過這些UML圖，記錄且呈現重要的業務規則。
例如，在經過PIM-1的步驟之後，我們認爲“定期定額申購”是很重要的業務對象，而且涉及許多重要的業務規則，所以決定爲它繪製如圖2-6的狀態圖，以便組織業務規則，同時也對定期定額申購有更深入的理解。
PIM-3：定義靜態結構
在PIM-3中，系統分析員用類圖來表達系統內部的靜態結構。系統只有具備穩定且具彈性的靜態結構，才能夠順應需求變更，迅速支撐多樣化的系統用例。之後，類圖可能通過設計師之手，進行調整，並且成爲程序員最關切的設計圖之一。程序員通常會按照類圖的內容，來編寫並組織源代碼。
在PIM-3的過程中，系統分析員尋找操作絕對優先於尋找屬性。因爲屬性隨處可見，特別是從PIM-1蒐集而來的窗體，裏頭多的是對象必須保存的屬性。而尋找操作就沒這麼直接簡單了，系統分析員必須多動腦筋才能定義出操作，所以先別管屬性了，記得優先找操作。
進行PIM-3時，系統分析員可以通過下列步驟，建立出如圖2-7的類圖：
- 套用交易模式，並且經過調整之後，系統分析員可以獲得初步的靜態結構。
- 分析PIM-2的狀態圖之後，系統分析員可以爲類增加屬性及操作。
- 分析PIM-1蒐集來的窗體，系統分析員可以爲類增加更多的屬性。
- 經過PIM-4的序列圖，系統分析員可以爲類增加更多的操作，並且描述操作的方法。
PIM-4：定義操作及方法
在PIM-4中，系統分析員可以用序列圖來表達，系統內部一羣對象合力完成某一個系統用例時，執行期間的交互情形。之後，序列圖可能通過設計師之手，進行調整，並且成爲程序員最關切的設計圖之二（另一張是類圖）。程序員通常會按照序列圖的內容，編寫出方法的源代碼雛型。
此外，PIM-1的系統用例敘述和PIM-3的類圖，對PIM-4的序列圖有不可或缺的貢獻。從PIM-1的系統用例敘述中，系統分析員可以分析出系統流程。而在PIM-3的類圖中，系統分析員定義出系統內部的靜態結構。隨後，到了PIM-4的序列圖時，則結合了系統用例以及靜態結構兩者。
系統分析員通過序列圖的思考與表達，試圖安排依據類們所生成的一羣對象之間的交互，讓這一羣對象可以合力完成某一個系統用例。同時，在序列圖中，一羣對象交互所引發的操作，則可以反饋給類圖，定義出更多的操作及屬性，甚至發現之前未發現的其他類及關係。
系統分析員可參考下述步驟來繪製序列圖：
- 扮演啓動者的執行者對象放置於序列圖最左方；扮演支持者的執行者對象放至於序列圖的最右方。
- 針對系統用例敘述裏所記載每項流程步驟，判斷執行時需要使用到哪些數據，且可指派擁有該數據的對象負責該項工作。
- 試着執行序列圖，以便調整流程，並且爲操作加上參數。
- 把繪製序列圖時所找到的操作及屬性，反饋給類圖。
以“網絡申購單筆基金”系統用例之主要流程爲例，我們示範繪製出如圖2-8所示的序列圖。
最後，系統分析員可以試着執行一次序列圖的流程，並且爲操作加上參數。增加輸入（in）及輸出（out）參數如下：
- 查詢託售基金清單（out 基金名稱清單）
- 查詢基金名稱（out 基金名稱，基金代號）
- 查詢扣款賬號（out 扣款賬號）
- 單筆申購基金（in 基金代號，申購金額）
- 計算手續費（in 申購金額，out 手續費）
- 查詢銀行折扣（out 銀行折扣）
- 查詢基金管理費（out 基金管理費）
- 查詢綜存賬戶餘額（out 綜存賬戶餘額）
- 查詢綜存賬戶餘額（in 扣款賬號，out 綜存賬戶餘額）
- 確認單筆申購（out 憑證號碼）
- 扣款（）
- 扣款（in 交易金額）
- 設定申購日期（）
- 產生交易編號（out 憑證號碼）
由於，單筆申購和定期定額申購計算手續費的方法相同，所以系統分析員可以將單筆申購類裏的“計算手續費”操作移至申購交易類，並彙總上述序列圖所新增的操作與相關屬性，更新類圖如2-9所示。
在CIM與PIM之後
由於我們採用MDA（Model-Driven Architecture）開發程序，作爲專業分工的依據，因此系統分析員的工作聚焦於CIM與PIM階段，至於PSM及編碼階段，則交由其他的設計師負責之。MDA主要將生成的UML模型，分爲下列三個階段：
- CIM（Computation Independent Model）──聚焦於系統環境及需求，但不涉及系統內部的結構與運作細節。
- PIM（Platform Independent Model）──聚焦於系統內部細節，但不涉及實現系統的具體平臺（Platform）。
- PSM（Platform Specific Model）──聚焦於系統落實於特定具體平臺的細節。例如，Spring、EJB2或.NET都是一種具體平臺。
因此，系統分析員執行了前述的CIM與PIM步驟，並且獲得高質量的生成之後，設計師會依據具體平臺進一步生成PSM階段的設計，並交由程序員按圖編碼，編寫出適用於特定具體平臺的代碼。
本文節選自機械工業出版社新推出的《系統分析師UML實務手冊》中的第2章《做好系統分析》。
《系統分析師UML實務手冊》通過一個完整的仿真實例，介紹了從需求到生成UML的用例圖及其敘述、活動圖、類圖、序列圖和狀態圖等，一應俱全，過程細膩，步驟詳細。主要內容包括：定義業務流程、分析業務流程、定義系統範圍、分析系統流程、分析業務規則、定義靜態結構、定義操作及方法、基金模擬項目、語音備忘器等。
與此同時，機械工業出版社還授權InfoQ中文站獨家爲大家提供額外的樣章進行試讀：歡迎下載第10章《基金模擬項目》