W04 我的設計準則(6)──追溯關聯

所有的單位在操作或使用的同時就發生了關聯。無論是一對一、一對多、多對一或是多對多，關聯都是追蹤影響的最重要依據；唯有透過關聯的追蹤才能發現某個單位的變動範圍到底有多廣泛。

收集範圍與追溯關聯是在求快速開發的同時最易忽略不做的工作。由於程式碼經常變動造成使用關聯頻繁變化，使得修改追溯表的速度根本追不上變動的頻率，長久下來完全沒有人可以追蹤出任一個底層API修改之後向上隔了數個層次的Use Case到底有哪些會被影響。縱使現在的IDE工具可以查出全部的呼叫歷程，但是在出版本前的迴歸測試要如何取得幾十個變更的影響範圍？

無論人對事、事對物、地對事、時對人與事或是事與事之間的全部關聯都應該要記錄下來，不管是做事的SOP或是程式的呼叫也都有使用的關聯，如何快速列出能夠操作目標單位的全部集合雖然不易，卻是在某些狀況下必須得到的結果。程式碼中快速且正確地列出使用集合，正是我要定義程式結構的主要目的。

針對UML裡的Use Case我實測了三種UML軟體：Rose 7.0.0.0、JUDE Community 5.5與Star UML 5.0.2.1570，測試範圍是Actor與Use Case的關聯、Activity與Activity的關聯。Rose明確地標示出三種圖示與兩種關聯；JUDE連Activity都沒被視為保存的單位（這表示activity無法分析是否重用），更不用提關聯；Star UML標示出三種圖示，也在各圖示內管理自己的關聯。

忽略多個Use Case之間的使用關係時，雖然對於單一Use Case可以快速開發，但是就沒法作出最佳化的分析與設計（如果向下的層次也不追蹤使用關係的話）。使用關聯的雜亂是專案產出的品質難以控管的重要因素之一，卻是被許多人所忽略的。