圖 1、電子商務 Component Diagram
圖 1、電子商務 Component Diagram是筆者過往曾經做過的項目(專案)，各位可以猜猜這張圖是在專案執行過程的哪個階段製作的? RA、SA、SD、DEV…哪個階段呢? 答案將在最後的結論當中揭曉。
對很多人來說 Component Diagram 代表的是靜態結構的組成，用來表達的通常是系統、子系統與各個模組之間的關連性，私下跟許多友人探詢後，發現很多人都覺得這類的 UML 圖型較不常用，更意外的是，這麼好用的圖例，很多人根本沒在專案中用過它！這是怎麼一回事？為什麼我每個專案都一定會出現至少一次的圖，卻在其他人的專案中鮮少出現？到底是哪一方面出現了差異？
先解釋一下這張圖好了，圖中有1) 產品結構管理模組、2) 訂單處理模組、3) CRM 資料交換模組、4) 授權處理模組、5) 物流處理模組、6) ERP 資料交換模組等六個模組；每個模組負責的主要功能分別用不同的介面分別定義，例如產品結構管理模組必須具備1) 商品結構定義、2) 替代商品維護、3) 商品資料查詢等三大功能，其他模組也有各自具備的功能，個模組之間的相互串連則透過相依關係去表達，從圖例當中可以看到，訂單處理模組將會使用到產品結構管理模組的商品資料查詢，而物流處理模組則會使用到訂單處理模組所提供的各項功能。
註：由於筆者所使用的免費工具目前尚無法完整表達 UML 2.0 的圖例，所以，採用相依關係，一般而言本相依關係可以換成 UML 2.0 的 Required Interface
從Component Diagram的結構當中，我們可以清楚的了解到各個模組之間的關連性與每一個模組的功能特性，也就是說，這張圖表達了本專案應該要完成的功能與範疇(Scope)，各位讀者如果花一點點時間去看這張圖，大概也可以猜出這個專案到底在做甚麼了吧？這就是筆者堅持要畫這張圖的原因之一，讓第一次專案團隊能對專案範疇有正確的概念，也知道類似的功能要放在哪一個模組裡頭。
另外，這張圖對筆者而言還有另外幾個重點，其中一個重點是適度切割功能，如果系統的功能無法被適度切割，我們怎能確保自己不會迷思在一堆的需求當中呢？就像在一團打結的繩索中抽絲剝繭，這是一個過程，不但能確實釐清專案的各種需求，也是確保專案不致迷航的一盞明燈。
第二個重點是，釐清元件之間關聯性，Component Diagram結構當中的相依關係代表者元間之間的依存度，這樣的依存關係也可以作為開發時程的重要參考依據；例如：物流處理模組需要使用訂單處理模組，訂單處理模組需要使用產品結構管理模組，本例的合理的開發次序是 1) 產品結構管理模組、2) 訂單處理模組、3) 物流處理模組，人力與時程安排便可依此為佐證。
在釐清元件之間關聯性的過程中，還可以協助分析設計人員找到系統可能發生異常的部分，下圖是典型的循環相依案例，從圖例中，我們看到訂單處理模組需要CRM 資料交換模組，CRM 資料交換模組也需要訂單處理模組，如果系統採取這種設計方式將可能導致日後無法抽換其中任何一的模組，因此，設計人員必須解構 & 改進這方面的設計，如此才能提升系統的穩定度並增加日後擴充的彈性。
對很多人來說 Component Diagram 代表的是靜態結構的組成，用來表達的通常是系統、子系統與各個模組之間的關連性，私下跟許多友人探詢後，發現很多人都覺得這類的 UML 圖型較不常用，更意外的是，這麼好用的圖例，很多人根本沒在專案中用過它！這是怎麼一回事？為什麼我每個專案都一定會出現至少一次的圖，卻在其他人的專案中鮮少出現？到底是哪一方面出現了差異？
先解釋一下這張圖好了，圖中有1) 產品結構管理模組、2) 訂單處理模組、3) CRM 資料交換模組、4) 授權處理模組、5) 物流處理模組、6) ERP 資料交換模組等六個模組；每個模組負責的主要功能分別用不同的介面分別定義，例如產品結構管理模組必須具備1) 商品結構定義、2) 替代商品維護、3) 商品資料查詢等三大功能，其他模組也有各自具備的功能，個模組之間的相互串連則透過相依關係去表達，從圖例當中可以看到，訂單處理模組將會使用到產品結構管理模組的商品資料查詢，而物流處理模組則會使用到訂單處理模組所提供的各項功能。
註：由於筆者所使用的免費工具目前尚無法完整表達 UML 2.0 的圖例，所以，採用相依關係，一般而言本相依關係可以換成 UML 2.0 的 Required Interface
從Component Diagram的結構當中，我們可以清楚的了解到各個模組之間的關連性與每一個模組的功能特性，也就是說，這張圖表達了本專案應該要完成的功能與範疇(Scope)，各位讀者如果花一點點時間去看這張圖，大概也可以猜出這個專案到底在做甚麼了吧？這就是筆者堅持要畫這張圖的原因之一，讓第一次專案團隊能對專案範疇有正確的概念，也知道類似的功能要放在哪一個模組裡頭。
另外，這張圖對筆者而言還有另外幾個重點，其中一個重點是適度切割功能，如果系統的功能無法被適度切割，我們怎能確保自己不會迷思在一堆的需求當中呢？就像在一團打結的繩索中抽絲剝繭，這是一個過程，不但能確實釐清專案的各種需求，也是確保專案不致迷航的一盞明燈。
第二個重點是，釐清元件之間關聯性，Component Diagram結構當中的相依關係代表者元間之間的依存度，這樣的依存關係也可以作為開發時程的重要參考依據；例如：物流處理模組需要使用訂單處理模組，訂單處理模組需要使用產品結構管理模組，本例的合理的開發次序是 1) 產品結構管理模組、2) 訂單處理模組、3) 物流處理模組，人力與時程安排便可依此為佐證。
在釐清元件之間關聯性的過程中，還可以協助分析設計人員找到系統可能發生異常的部分，下圖是典型的循環相依案例，從圖例中，我們看到訂單處理模組需要CRM 資料交換模組，CRM 資料交換模組也需要訂單處理模組，如果系統採取這種設計方式將可能導致日後無法抽換其中任何一的模組，因此，設計人員必須解構 & 改進這方面的設計，如此才能提升系統的穩定度並增加日後擴充的彈性。
圖 2、循環相依案例
最後一個要點是其他文章中提到的 “測試優先”，有了功能分割與元件化設計之後，測試也能聚焦，每一個模組都可以有足夠的測試案例去維持該元件的品質，後續整合測試就會相對容易，投入的人力、物力與時間也會比較容易掌握，相對的，客戶將會更加滿意專案的執行成果。
結語回到文章剛開始的問題，猜猜這張Component Diagram是在專案執行過程的哪個階段製作的? 答案是一開始的企劃階段，企劃階段製作 Component Diagram的好處很多，希望各位透過本文能有所認識，趕快開始善用這張圖吧！
關於適度切割功能這點，筆者的期待是，適度切割功能達到可重用(Reuse)的地步，可重用的概念一直是軟體設計與開發者期待物件導向能帶來的優勢之一，但是我們怎樣找到可以重用的元件呢？
如何解構循環相依？請各位讀者自行思考囉，日後有空再跟各位分享囉。 ^_^
強力推薦：敏捷溯模(Agile Modeling)
沒有留言:
張貼留言