UML -- 使用範例

相當不錯，且完整的一個小小 UML 使用範例

請直接連至 網頁  http://www.csie.nctu.edu.tw/~skyang/umlsamples.htm  觀看

( 為免以後看不到，因此貼於此處，但相關權利屬原作者所有！)

一般的遊戲或虛擬實境軟體把描繪好的 3D 畫面呈現在電腦螢幕上， 但一些環場模擬需要呈現多視角的多重顯示，例如賽車模擬可能需要前後左右四個顯示幕， 來表現四個車窗看到的景物，這個時候就需要用到多重顯示(multi-display)系統。 話說到這裡只是個願景(vision)，接下來實際演練如何使用 UML 規劃出這樣的一個軟體系統。

第一步、需求分析

所有軟體工程最關鍵的第一步就是需求分析，同時也根據這些需求進行技術可行性分析， 以一個多重顯示系統來講，目的當然是能夠多面同步顯示 3D 場景，此外， 根據應用場合列出以下的需求項目(requirement)。

PURPOSE (需求分析)

• 目標：多面同步顯示3D場景
• 需求：
  1. 多面顯示須保證逐畫面同步，否則立體效果(stereo)會失敗。
  2. 多面可顯示不同視角 (viewport)。
  3. 可更換自訂節目，負責描繪各面顯示幕的電腦不需要人為的重新啟動。
  4. 與現有描繪引擎整合，減低應用程式開發負擔。

技術分析

1. 最直觀的多重顯示系統架構就是主從架構(master/slave)， 有一部 master 端的電腦負責模擬運算， 而每一個顯示幕都由一部 slave 個人電腦負責描繪，master 端與 slave 端之間透過網路纜線直接連結。
2. 此外，如果把所有的場景資料都由 master 端即時輸送給 slave 端， 除了增加 master 端的負擔以外， 以現今記憶體輸出入速率與網路纜線傳輸速率尚難達成，故選擇在 slave 端磁碟事先放置與 master 端相同的場景資料，執行時期載入並隨時與 master 端同步，以減低資料的傳輸量。

第二步、靜態建模

權責劃分

簡明的元件部署在日後的分工、維護、延伸、傳承上都是非常關鍵的因素， 根據需求項目，多重顯示軟體系統分為三個角色。在 slave 端放置一支描繪程式當然無庸置疑，而 master 端的軟體分割為固定的 master 端控制元件，以及可替換的 master 端應用程式， 以因應第三項需求項目：可更換自訂節目。

角色(role)	責任(responsibility)
Slave端描繪程式	接受同步訊息描繪3D場景
Master 端控制元件	發出視角設定與同步訊號
Master端應用程式	進行節目流程

部署圖(Depolyment Diagram)

從系統的觀點來看，多重顯示系統是一台 master 主控電腦連接多部 slave 描繪電腦，每一部 slave 電腦可能連接一部投影機，單一組顯示幕的部署圖如下圖， 明確地標示出 slave 端是被 master 端同步的畫面訊號來源。

元件圖(Component Diagram)

元件圖比部署圖更細節地描述各個節點的構成元素，其中 master 端的應用程式是個主動類別，持有控制元件的 dll handle 和主要的 camera 設定， 而 master 端的控制元件根據應用程式的主要 camera 產生各面顯示幕的 camera 設定， slave 端的描繪程式也是個主動類別，持有場景資料，根據接收而得的 camera 設定和同步訊號描繪畫面。

類別圖(Class Diagram)

最細節的類別圖出爐，就可以開始寫程式了，為了需求項目第四項：與現有描繪引擎整合， 所以 master 端的控制元件類別 RACaveRenderer 衍生自描繪引擎的場景描繪類別 RAGraphRenderer，如下圖所示，這個類別儲存主要 camera 設定，持有各 slave 的設定(configuration)和上下傳連線。它的操作有啟用(enable)多重顯示、 描繪畫面(render)、停用(disable)多重顯示。

附註：工研院亦專門為此目的開發了 2D/3D 多重顯示系統， 尚且加入了許多加速與模組擴充功能，其軟體架構不只如本文所描述的這麼單純。

第三步、動態建模

合作圖(Collaboration Diagram)

到此已規劃了多重顯示系統中的各個角色，以及它們不同細節程度的架構描述和權責劃分， 接下來要描述他們是如何動作的。在下圖方格中為各結構體產生的物件實體命名以利分辨， 也可以不命名(例如圖中的應用程式)。沿著圖中訊息的序號，很明白地能夠了解到， 當應用程式呼叫了控制元件 r 的 Render()，控制元件 r 先對 slave 端 s 傳送更新端場景的資料，然後對 s 下達描繪指令。s 描繪完成以後回覆 acknowledgement，然後 r 對 s 下達換畫面的指令、完成一次描繪流程。

順序圖(Sequence Diagram)

在合作圖當中可以描述這三個物件實體的訊息交流， 但是無法描述它們動態生成的因果關係，下面的順序圖把這三個實體橫向排開， 在縱向的時間軸上標註他們的生命週期， 並在時間軸上呈現訊息產生的時間而不只是序號而已。由圖上可以看到， Slave 端描繪程式 s 是先啟動的，接著應用程式啟動了，並由應用程式喚醒控制元件 r， 然後連線、載入場景、描繪畫面。而停用多重顯示的時候，首先 r 與 s 斷線， 然後 r 消滅了、應用程式中止，描繪程式 s 繼續等待著與下一個應用程式連線。

狀態圖(State-Chart Diagram)

把 slave 端的描繪程式下圖分成三個狀態來舉例，收到來自 master 端控制元件的不同訊息，導致它在這三個狀態間跳躍，其實這就是很單純的有限狀態機 (finite state machine)描述法，不需贅述。此外，活動圖(activity diagram)就是眾人皆知的流程圖(flow chart)，在此也不再舉例。

五、以 UML 為基礎的軟體開發流程

UML 圖形和軟體工程之間的關係，就像藍圖和建設工程之間的關係， 把工程粗略地分成設計、實作、驗證三個階段， 這三個階段可能承辦者都是彼此不相識的不同人員， 如下圖，在設計階段產出 UML 圖形以後，負責實作的人便按圖施工， 如果在實作當中發現問題，便回到 UML 圖形上檢討原設計， 更正圖形之後再繼續按圖施工。而實作完成以後，品質管制人員依照 UML 圖形所描述的架構規格和行為，驗證實作是否正確。 在這設計、實作、到驗證完成的期間就算有人員替換，也不會有問題。

懂 UML 圖例不等於會畫 UML 圖，就像不是每個會用 PowerPoint 的人都能做出陳述清晰明確的投影片。UML 不是萬靈丹， 先天不佳的設計或不健康的軟體工程流程，並不會因為使用了 UML 就變良好，最關鍵的仍是從團隊領導者到所有組員對軟體工程的共識， 並一再琢磨自身的塑模觀念與技巧。

在畫 UML 圖的時候，不要老想要把所有的東西塞在同一張圖面上，以免模糊焦點， 寧願分門別類、提綱挈領地多分成幾張圖，這時候善用子系統(或套件)圖示就很重要了。 有許多繪製 UML 圖形的商用軟體兼有管理甚至產生原始程式碼的功能， 筆者奉勸一句：那些功能可以使用但是不能依賴， 程式碼的穩健化和最佳化基本功還是要練習的， 原始程式碼就算是半自動產生的，還是要一行一行自己看過才能校調到最佳狀況。