2007年7月3日 星期二

B15 理論串接實作的瓶頸(2)──Activity Diagram的意義

Activity Diagram是用來說明Use Case內的動態流程,使用者操作步驟、系統當下該有的反應、與外部系統的互動都該在這份圖裡呈現。Activity的意義幾乎等於流程圖,但是如果把Activity Diagram畫得像流程圖,就極為可能造成系統界限與動作責任畫分不清楚的風險。

Activity Diagram裡有個叫swim lane的有用元件,我們可以使用它來基本地切分使用者動作、系統反應與外部系統的責任區塊。製作Activity時同樣像畫流程圖那樣依序加入,但加入時務必決定好該Activity在哪一塊區域內發生的。使用者作了什麼操作後進入系統處理,系統在內部如何處理、有什麼改變,改變之後如何與Actor互動,在這裡都依照發生的地方加以區隔開來。

這樣做有什麼好處呢?流程不是完全都一樣嗎?從整個操作順序與功能目的來看是沒什麼不同,但是從swim lane的權責角度來看就有很大的差異。使用者區塊代表的是人的動作,我們可以依區塊內的順序撰寫測試個案以及驗收時要交付的操作手冊;系統區塊代表的是需要開發的動作,在使用者的什麼動作後該有什麼樣的反應、做什麼樣的事是未來設計的依據;外部系統區塊代表的是系統與其他系統的互動,可以知道在什麼時間點要與外部系統有什麼樣的關聯,回傳的結果要如何處理等等。

把所有Activity放在所屬的swim lane對於系統開發的影響是非常大的,如果沒有注意到這個地方會使得動作無法明確區分而造成設計時的混亂。同樣地,在購買OOAD相關書籍時只要翻開Activity Diagram的範例,用有沒有swim lane的存在來得知作者有沒有過成功的實作經歷。

沒有留言:

張貼留言