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

注意：由於專案的保密規定，我只能用中性的字眼記錄我的分析過程，所以這篇文章是給我自己看的，主要的分享重點在於：不受分析規定的限制（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的狀態，而是代表上述兩類行為，分別可以產生兩種案件，而這個案件就要由這個狀態圖來描述案件的狀態。