許小史

在客戶需求收集與界定分析-2的章節有針對性，我們會提供出：

• 客戶的原始需求
• 將客戶需求轉換成條列式需求
• 將條列是需求尋找主詞，動詞與受詞
• 發現系統的重要關係者
• 發現系統交互界面
• 分析出流程最小單位並推測出使用個案
• 分析並排除出使用個案的活動圖
• 呈現作業的操作雛形

將所有客户的需求經由上述的幾項進行分析完成之後，便可以確定目前要執行的這一套系統，會跟哪一些系統有交集，進行整理之後便可以歸整出整套系統的全貌，並將以繪製可以產出整個系統的架構圖，如圖1. 系統架構示意圖。

如果再將分析後的接口也整合進去之後，便可以得到系統與系統間的通訊關係，並展開整個系統的溝通架構圖，如圖2. 系統溝通架構示意圖。

最後將功能清單與畫面整合之後，整個系統的全貌大致就出現了，加以歸整分類之後，便可以展開系統的功能架構圖出來，如圖3. 功能架構示意圖

上述幾項經過整理之後，便可以整理出客戶需求規格書，也就是藍圖匯報的主要產出。與客戶說明需求時，經由這幾項規格彙整，基本上便可與客戶進行需求的確認。
但是如果要接著往下分析時，可能就不會是這樣便可以完成的，因此如果我們要移交給後續系統分析人員進行處理時，就還需要在往下分析下去，除非接下來接手的人員就是你自己，又或者是說接下來要接手的人員，你已經跟他合作很久，他非常清楚知道他要怎麼做，又或者是你知道接下來接手的人員是一個經驗相當的人員，不然單就從雛形、使用個案與活動圖，要讓分析人員自行轉換成有哪一些類別或是哪一些作業，中間的間距仍舊是有點太大，因此我們可以再幫分析設計的人員再多分析出一個強韌分析圖。

這個強韌分析圖主要是再做一件事情，就是需要將使用個案與接下來系統分析設計人員要做的類別圖或循序圖建立起一個關係，因為要從使用者案直接跳到類別循序圖，中間的間距有點大，因此可以透由這個強韌分析圖 (Robustness Analysis)，拉近兩邊的關係，如圖4. 所表示的 (本圖是參考來自中山大學吳仁和教授簡報內容)， Use case to sequence diagram is not easy，所以他建議走下面的這一條路，經由 Robustness Analysis 分析之後，再轉去做 Sequence Diagram 會比較清晰，也不會做錯。

在 Robustness Analysis 中他分成了四樣東西，分別是：

• Actor 行為者：這個與之前所談過的 Actor 一致，這裡就不多述，請參閱前面的章節說明
• Boundary 邊界：Boundary 可以被定義成 UI / Protocol / Interface ... 甚至是 File，他是一個沒有自我行為的物件，主要是定義 Actor 與作業間中間的介面，因此如果 Actor 是人員，那 Boundary 就可能是 UI，如果 Actor 是其他系統，那 Boundary 就應該會是接口、File、Table，又或是 Protocol 之類的，主要還是要看需求而定
• Control 控制：Control 是在描述這個需求的主要控制流程與控制整個商業邏輯的控制者，一般來說比較會是一個商業邏輯物件( Business logic Object )，整個強韌分析圖最主要的目的之一就是要分析出Control。
• Entity 實體：最後是 Entity，Entity 基本上就是這個商業邏輯物件在執行完這個需求之後的產出這個產出大多會是一個 Table，例如：如果 Control 是 Model 分類資訊處理者，那他的 Output 就可能會是「Model 分類資訊主表」；另外 Entity 不一定是只有產出，基本上就是要描述出控制者這個物件會使用到哪一些是屬於 Entity 的資訊，因此有可能會是 Table、View、MQ...等又或者是 File之類的。

另外針對 Robustness Analysis 他也是有一個準則的，他的準則如下，如圖5. Robustness Analysis 準則

• Actor 可以直接對 Boundary
• Actor 不能直接對 Control
• Actor 不能直接對 Entity
• Actor 不能直接對 Actor
• Boundary 可以直接對 Control
• Boundary 可以直接對 Actor
• Boundary 不能直接對 Boundary
• Boundary 不能直接對 Entity
• Control 可以直接對 Boundary
• Control 可以直接對 Control
• Control 可以直接對 Entity
• Control 不可以直接對 Actor
• Entity 可以直接對 Control
• Entity 不可以直接對 Entity
• Entity 不可以直接對 Boundary
• Entity 不可以直接對 Actor

有沒有可能會有與準則相抵觸的狀況，答案是有可能，例如說 DBA (Database Administrator)， DBA 是一個 Actor，他就有可能會直接還操作 Database，但是面對到這種狀況，基本上我的想法是還是要將他導回到正常的流程定義，這時候 DBA 是 Actor，Database 就會是 Interface 也就是邊界 Boundary，那 Control 就會是 SQL 的 Stored Procedure、Function ... 等，Entity 就是他操作的 Table ，主要想表達的是，雖然我們會遇到一些狀況會與準則衝突，但是為了要能與外界接軌，還是要將整個流程引導回正常準則，這樣別人才能一看你的圖便可了解你的圖內容代表的意義。

另外還有一個非常重要的問題是，當我們在做 Robustness Analysis 時，又或者是系統分析設計人員接手到客戶需求規格時，發現到 Control 與 Control 之間有著一條直接的連線時，表示這兩個物件之間有一個緊密的強耦合關係，這裡必須要先說明 Control 控制者這個物件在我們的定義中，會將它視為是一個主要物件，所謂的主要物件是指這個使用者需求的商業邏輯物件的主要處理者，簡單說就是一個商業邏輯物件，當發現兩個商業邏輯物件出現了一個強偶合關係存在時，如圖6 Robustness Analysis 示意圖

這時候我們就知道在這兩個主要物件之間，會存在一個次要的物件，這個次要物件主要就是用來解決物件與物件之間的耦合性，以物件導向的宗旨來看，物件要達到耦合力低內聚力高，我們也經常聽到這句話，但是到底什麼是耦合力低內聚力高，而物件導向中要達到絕對的內聚力高，沒有耦合性那是比較不可能的，除非我們將整套系統都採用外掛的方式執行，但是這樣的系統執行效能上又會變成很大的致命傷，又或者是我們目前這套系統是一個很小型的 Utility，絕對不會有所謂的耦合，這樣就有這可能性。

但回到正題，如果發現關係是必然存在那又要如何建立一個高內聚力，低耦合力呢? 這時就回到我們剛剛談到的那個所謂次要物件上，這個所謂的次要物件基本上就是我們常常聽到的設計模式 (Design Patterns)；這是強韌分析圖中第二重要的部分，就是要找出這些物件間的所有耦合，只要在強韌分析圖當中發現有 Control 與 Control 之間存在一個直接的連線關係時，就表示在這一個地方未來將會架設一個 Design Patterns 在這裡，因為其實 Design Patterns 主要的目的就是為了要來解決物件與物件之間的耦合性，Design Patterns 之所以稱之為 Design Patterns，基本上它就是在設計階段的時候，就必須要加入到你的設計中，它是你設計的一個很重要的環節，而不是在你寫程序的時候，忽然靈感一來覺得這裡需要架設一個 Pattern，那裏需要架設一個 Abstract Factory，這邊又可以來一個 Prototype 的方式在任意的添加，這樣的做法基本上我們會稱之為 anti-pattern (反面模式)，也就是所謂的因為物件導向而物件導向，又或因為 Design Patterns 而 Design Patterns 的做法。

我們可以看到圖6. Robustness Analysis 示意圖，系統架構師在分析完客戶的需求之後，為了要能夠讓系統分析設計師順利地往下執行下去，最後我們都會產出這樣的一個 Robustness Analysis，來協助後續的系統分析設計作業，並且在做完者樣的強韌分析之後，我們也大致可以產生出一份 Table 清單以及物件清單，有了這份清單，系統分析設計人員在繼續往下分析時，可以更加容易上手。

圖7. 物件清單示意圖

到這裡便是我們整個在製作藍圖設計時，會產出的相關活動從需求擷取，到需求條列、需求分析、情境分析、雛型設計、流程釐清到最後的分析接軌，這一連串的作業便可以完成了客戶需求規格書的產出，基本上它完成了部分系統分析的內容，但是這部分基本上就很難界定，因此如果客戶需求規劃與系統分析設計是屬於不同的人時，必須要有當責的認知，彼此都要能在跨出一步，相互干涉到彼此的一部份，這樣才能夠更加順利的進行。
到這裡便是我們整個在製作藍圖設計時，會產出的相關活動從需求擷取，到需求條列、需求分析、情境分析、雛型設計、流程釐清到最後的分析接軌，這一連串的作業便可以完成了客戶需求規格書的產出，基本上它完成了部分系統分析的內容，但是這部分基本上就很難界定，因此如果客戶需求規劃與系統分析設計是屬於不同的人時，必須要有當責的認知，彼此都要能在跨出一步，相互干涉到彼此的一部份，這樣才能夠更加順利的進行。