＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊

前兩個星期有位上過前一期「軟體架構師」課程的學員，他在某大金融單位擔任技術職PM，特地利用週末時間到我家附近，請教我關於他利用 UML 所繪製的設計圖問題。相當認真，所以我很願意陪他一同討論軟體相關議題，順道一同在肯德基吃午餐。總共花了約兩個來小時吧，該學員還要去參加他的讀書會，真是有夠認真啊，不過起碼有討論出一個比較具代表性的使用案例其實現的主要程序描述。

畫出來是否正確或合理與否是一回事，至少他肯利用 UML 表現出他的設計思維就很值得肯定，這才有機會可以指指點點與討論的。

他只畫了使用案例圖與某一結構設計的類別圖，因爲有公司機密問題，這裏就不方便貼出他的原稿。我只就他的設計給予一些建議與修正，並利用他在 Mac 所使用的 UML 工具繪製出來。

• 工程師規劃表達系統需求功能的使用案例 (use case)，往往會以「作業模組」界定爲一個使用案例。這其實不是使用案例，而是一連串活動的業務流程 (或工作流程)，宜應使用 UML活動圖 (activity diagram) 來表達不同期間的作業活動，並經由多個參與的角色協同合作來完成特定的作業目的。至於 Use Case 的界定，應是以「達成某一特定操作目的 (specific goal)」來界定會比較適宜，對比企業流程的話，其實是會對應作業流程內的某一「活動」 (activity)。
  
• 類別 (class) 圖有些太過度設計了，太過使用一些所謂 O.O 的技巧，反而是會造成複雜度的提昇。例如 Factory 機制，在 AP 層去設計它可能沒有意義，因爲往往在底層 Framework 就已有提供 (例如 Spring 早已利用 Container 來「生產」Bean 並控管其 Scope 與 生命週期。

  工程師必須要能確實理解設計目的爲何：爲何制定抽象的介面規格，又爲何需要去擴展 (extend) 一般性類型的行爲。而這些並非是一開始就能考量周到，而是隨着開發/維護的進程持續重構得以有機成長。

  過程中由於沒有帶筆記本，所以乾脆我就在面紙上大概繪製下類別圖與學員確認他的設計想法。 :)
  

• 啊？循序 (sequence) 圖呢？！ 學員沒有表現出來，其實我相當推薦使用案例 (表達系統功能的主題)，再佐以系統循序圖 (表達系統功能實現的主要程序) 就很容易釐出後續實作與結構設計的重點。

  所以我們重新界定並捕捉一些相關於該業務流程的系統功能，再就比較具交易關鍵型的使用案例，先以系統循序圖來實現主要的程序。

  利用系統循序 (system sequence) 圖，就可以很清楚地知道該系統功能 (use case) 的主軸與主要的實現程序 (procedure)，這樣在實作上其實可以很簡單直覺。至於變動性的結構議題，就可以再觀察每一條主要的訊息 (message)，是否存在着業務邏輯的複雜度議題，或者是系統的邊界 (與資料庫/外部系統) 實作技術變動議題，這些就可以各別利用分層結構的框架以 Domain 的物件結構設計來有機成長了。