B11 理論串接實作的瓶頸(1)──Refine Use Case Diagram的原則

剛接觸OOAD後，遇到的第一個小專案很興奮地使用UML來試著記錄需求。直接列出Actor與Use Case是很直覺的工作，除了摸索Rose的功能花了點時間之外，並沒有任何的困難。

作refine的動作時，Use Case不斷地被我思考並拆解為許多小型的Use Case，彼此間的關聯也拉了很多線條。同事看了問說關係看起來很複雜希望我說明一下？我就把我的想法說了一遍，包括如何拆解Use Case，如何用Use Case的關係表達心裡複雜的想法；原本十多個的Use Case就這麼被拆解成四五十個。

同事說需求模型並不是作設計，而是表達需求之間的關聯，。以我的切割方式已經幾近於切出元件的範圍，所以數量變得很多，同時關係彼此間串來串去而使得其他人很難看懂。Use Case的切割要以一個完整的功能為原則，在提取共用者時也得保持被提取的Use Case是一個完整而獨立的功能。

這個原則真的很難拿捏，太過時造成Use Case多而繁瑣，不及時也會形成每個Use Case各自為政，多想、多試、多討論應該是取得較佳平衡點的最好方式。如果在切割與不切割看起來都可以的時候，我傾向以不切割的結論，因為切得過多會增加需求模型的複雜度；而且每個Use Case都要附近詳細規格並列入清單時時檢查進度，這些都會是多投入資源的工作。

好的開始是成功的一半；如果製作了一個很難分析與設計的需求模型，那真的會是個悲慘的開始。