＊＊ 本文同步發表於 FB 社團－軟體設計鮮思維 ＊＊
這是月初的授課—「系統需求分析與整理」，其中一位上課學員拿他們的實際案例提供參考的。
先來瞧瞧這張看似很複雜的作業流程圖，主要是要描述當客戶單位提出報修需求時，維修單位的報價與維修的相關作業活動。
圖、原稿—客戶維修報價作業流程
這是一張典型 SA 所繪製的業務流程 （business process)圖，是否使用 UML 語法來表示，那並不重要。最主要的問題是，大多單位往往都認為這類業務流程的表達，必須要描述得很「精確」，才可以轉移到實作的階段。所以為了要能取得「精確」的結果，就需要不斷地開會與確認 (還含時常爭執各據的論點)，秏上個把個月才能有產出，然後再轉移到實作階段。
但是無論再如何精細，我發現到有一個相當有趣的現象，在這類環境下的 Programmer，往往都還是覺得不夠精細。
「越是想表達得精確，Programmer 越會嫌不夠精確！」
這就是典型的瀑布式 (waterfall)系統分析。這類所謂「精確」的業務流程圖，耗費太多在需求分析的時間，且由於描述了太多細節，反而讓實作寫碼不容易抓到適切的焦點，因而導致 Programmer 不知道如何寫出較具「彈性」可包容變動細節的程式碼，當然相對日久也就會把不精確的細節當成是一種無法 Coding 的藉口。
所以，上述如此好像「鉅細靡遺」的設計圖，主要的問題在哪裡？ 其實簡單的說，它早已違背了軟體設計至高無上的原則—封裝 (encapsulation)。
- 把資料細節呈現出來 (資料導向的思維)。
- 設計圖內描述了企業邏輯 (business logic)。
- 過早把資訊系統角色帶入。
先前針對上圖幾個問題，個人以前就發表過：「大業務流程塑模的MSS三層次原則」。簡而言之，設計圖要能：
- 讓設計表現簡潔易讀並易於調整修正。
- 具有層次感，每一個層級適時表現出焦點。
好的設計與呈現，是要能包容會變化的「細節」。不是一開始就要做精，而是懂得如何掌握可以獨立持續開發與實作的目標框架，以此為主軸，逐漸地往精確度收斂，卻又可以包容「善變的細節—欄位資訊與業務邏輯」。
這裡仍是以個人所發表的「MSS (Multiple/Single Process, System Functions」塑模三層次，就從多個作業流程的表達—利用火箭圖，以及單一作業流程的活動 (activity)這兩個層次，並以 UML 語法來重整原稿。至於系統功能的使用案例圖 (use case diagram)，先略過未提。如何從單一作業流程的活動圖，以此為引導轉為資訊系統的使用案例模型，可以參考個人另一篇文：「從企業流程(活動)圖找出資訊系統的使用案例」。
第一層：火箭圖
原稿的作業流程看似很複雜？ 但過濾掉資料與業務邏輯後，其實作業活動相當單純，也只有三類的作業流程而已：報修、報價、維修 作業流程。
圖、重整後的活箭圖—客戶維修報價作業流程 Overview
從上述火箭圖主要是要表達有幾個作業流程、它們之間的主要輸入—輸出的關係為何。還有更重要的是，突顯出各自作業流程所要達成的目標 (goal)與價值 (value)為何。
第二層：活動圖
每一個作業流程，當然有各自細部的作業活動，這時就是利用「封裝」的觀念，把相對各自流程的活動表達在下一個相對細部的層級。下列三張為利用 UML 活動圖 (activity diagram)所繪製而成。
圖、重整—報修作業流程活動圖
圖、重整—報價作業流程活動圖
圖、重整—維修作業流程活動圖
每一個作業流程的內部活動有各自要表達的操作目的，彼此之間只透過起點 (entry point)與終點 (end point)的事件啟始與產出 (artifacts)來關聯，但每一個作業流程的活動均有著各自的獨立與單一性 (atomic)，所以才得以各自維護與延展功能活動，焦點也相對明確許多。
一直重複提醒的問題，活動圖當然是以「活動 (activity)」為主體，而表單資料則是被「封裝」在各自的活動細節內部。同理，業務邏輯當然也是與資料同時被「封裝」在各自所屬的活動內部。不要再把資料當成活動主體，那是導致業務流程圖紊亂的元兇!
再則一個重點再次的提醒，作業流程圖的活動係以「人本」的角度來看來人工作業的流程，此時最好也不要「資訊系統」這個角色放進來。因為，「系統」這個字眼其實沒有想像得簡單，SA 往往都是把「功能模組」看待為單一系統，因而導致流程活動內有好幾個所謂的「系統」參與，這樣錯誤的解讀當然會造成未來實作的謬誤。
簡而言之，SA 不要也不應該自作主張把「系統」加入作業流程活動內；單純一些，僅以「人本」的角度來表達作業活動，不用管是否這些活動是否未來需要資訊系統的參與，如此反而可以讓活動圖很單純。
總之，系統的定義，應是團隊基於「架構 (architecture)」整體性的考量來決定出來的。當決定了系統的開發/維護範圍 (boundary)後，SA 即可以以此作為界限，來找出該系統應實現 (realize)的系統功能（system functions)了。如此第三個層級—資訊系統所提供的功能表達，如利用使用案例模型 (use case model)，就更能進一步清晰明確地表達出來；利用這個層級所分析出的系統功能，更易於橋接到實作寫碼的階段，反之也相對易於調整與維護。