2005/3/2

最近實作專案的設計經驗記錄

注意:由於專案的保密規定,我只能用中性的字眼記錄我的分析過程,所以這篇文章是給我自己看的,主要的分享重點在於:不受分析規定的限制(UML Diagrams的限制),自行運用可以使用的diagrams,製作一份高階、簡單扼要的實作分析文件。

前言:規格書包含兩個部分,一個是說明介面的溝通規格(包含 Send 與 Receive 的介面資訊內容),一個是系統的多張Sequnece Diagrams,說明系統的運作流程。

1. 製作系統流程圖,這個流程圖是根據系統規格書而來的,但是以我們系統的使用者為主角,思考所有可能的情況,會送收什麼訊息,每一項工作如何開始與結束。

2. 介面的規格有兩種Send與Receive,分析時將這些資訊,利用Excel把所有的資料列出來,縱軸是欄位名稱,橫軸是訊息名稱,在列表時將Send/Receive兩種訊息群分開,也要把各訊息未使用的欄位塗黑。這樣做的好處,是可以在兩頁的A4 paper上,很清楚地看到每一個訊息的內容,這樣就不需要把規格書翻來翻去,閱讀時容易混淆,搞不清楚每一個訊息內容的差別。另外這個表格,可以用來當作資料表的一個table,專門用來備份系統send/receive的所有相關訊息,以便未來系統上線運作後,可以查閱系統使用介面時的所有相關資訊。

3. 將Sequence Diagram重新整理成兩類,分屬於不同的角色,原始的規格書,其Sequence Diagram的繪製方式,並不是UML裡面提及的各類別instances的溝通過程,而是一個高層次系統roles之間的溝通過程,所以我們的系統扮演其中一個角色,也就代表sequence diagram上的一個方框。

由於我們的系統行為可以分成兩類,而這些sequence diagrams是以核心系統的角色來排列的,因此我們可以重新以我們的系統為主,排列這些sequence diagrams,這樣就能夠很清楚地瞭解系統的運作。

瞭解運作後,就是根據系統的流程圖與sequence diagrams,繪製系統兩類行為的state diagram,這裡的狀態並不是指UML裡的class的狀態,而是代表上述兩類行為,分別可以產生兩種案件,而這個案件就要由這個狀態圖來描述案件的狀態。

沒有留言:

張貼留言