P13 產出設計文件(5)──記錄Use Case與Module的關聯

等到使用者測試快到結束時，流程上的程式大致也趨近穩定，這個時候就可以開始記錄Use Case與Module之間的使用關聯。這裡的作法與Component Flow、Component Action幾乎雷同，只是層次換到Use Case Flow、Use Case Activity（對應到Module Interface Method）來記錄。

在直覺的設計下，如果目標放在如何完成功能的話，除了會造成處理流程只有達到功能的分解動作而失去層次感，這樣一來作任何修改都面臨無法縮小影響範圍的風險，因為執行順序的分工或是執行動作的深度都涵蓋了所有的層次，使用從上到下都有可能被影響。造船明明只造一個船體並依需要分割艙房即可使用，為什麼要多造出數層看似無用的防水匣門呢？這當然是為了預防“萬一”船體漏水時能夠限制影響的範圍。

系統開發已近尾聲，其實已經可以發現設計的方向可以導成遞迴處理，只要我們的產出是有規律且有層次的，就可以切割為處理方式相同的多個層次。另一方面，設計者在設計時只需要將注意力放在切割後的空間，可以在這限制的範圍內儘情陳設需要的結構而不用擔心影響其他地方；設計的產出遵照設計準則的話，還可以使用一些小工具來產生必要的資訊與文件。

設計的時候多花一些時間安排結構，可以回收的是快速找出問題點、修改時可限制影響範圍、容易讓別人瞭解並使用、減少文件的製作時間以及穩定地重用並擴充。設計時損失的時間可以在未來數倍甚至數十倍地回收回來，這還不足以令人轉變開發系統的觀念嗎？