UML 模型化

UML 模型化

UML 是一種模型化語言 (Unified Modling Language)，它提供了一套符號規則給從
事物件導向分析與設計時使用。它使得以物件導向方式開發軟體的團隊一個標準的溝
通方法，同時也讓開發者與使用者可以透過 use case diagram 溝通。

UML 真正的精髓不是在那些圖形與符號，而是在那些圖形與符號之下所蘊含的語意。
事實上 UML 底下隱藏著軟體開發的哲學，若是只學到 UML 的圖形與符號是沒有多大
用處的。我們真正要學的是物件導向分析與設計中的抽象化、模型與問題領域及解法
領域、...等等的方法論，如此才可能增進分析與設計的能力，否則與使用繪圖軟體就
沒有什麼差別了。同時若是你已有物件導向程式設計的經驗，UML 將是一個增進你分
析能力，與再精煉物件導向設計能力的一種工具。畢竟，UML 所提到的東西早已存在
，以前只是缺乏一個統一且有系統的方式來表達，今天 UML 成為標準後，許多觀念
將更容易溝通，而不易產生誤解。

UML 以一種漸進的方式來瞭解系統。首先開發者與使用者使用 UML 從使用者的觀點
來瞭解問題(use case diagram 與 activity diagram)。然後開發者使用 UML 並以
其自己的觀點來瞭解問題(class diagram, sequence diagram,...)。這些清楚的瞭
解使得開發者可以使用 UML 記錄他們發展出的解決方案。最後，UML 會變成系統實
作時的資源。

如果將軟體開發比喻為蓋房子，那麼 UML 的產出文件就好像建築師所繪的建築圖，
而軟體實作者就好比土木承包商。建築師將構想與設計表達於建築圖中，而土木承
包商使用其現有的技術，自由地將建築的模型實現出來，但是土木承包商必須按圖
施工。如此，建築師可以就其專業來設計房屋架構其美學表現，而土木承包商亦可
使用其善長之技術實作之，二者皆可充分發揮其各自的專業，但是又可以互相合作。
傳統上，土木承包商或許可以不需建築師的幫助而自行蓋好一棟小房屋，但是若是
要蓋商業大樓，其間結構的安全等問題則非土木承包商所擅長。今天的軟體愈趨複
雜，若是我們還像以前請土木承包商蓋房屋的方式開發軟體，那麼其後果可想而之。

雖然在小型軟體使用軟體工程的方式影響並不大，但是若不在小型軟體中練習軟體
工程的作法，將來在大型系統必然會手忙腳亂，反而增加失敗的機會。

在使用 UML 開發系統時有一些步驟，在此粗略敘述如下:

需求蒐集 (Requirements Gathering)

在此步驟時，開發者專注於從使用者的觀點來瞭解問題，這時不會考慮技術或設計的問題。如此方可確保開發者能專注於正確的問題，避免對於問題錯誤的瞭解，導致系統後來重大的變更。
在此有一點必須要說明，那就是 Use case 不是物件導向分析與設計的一部分，它只是描述使用者透過系統得到價值的一種敘事性的描述。所以一般使用者也應該看得懂。而開發者與使用者即透過此種方式溝通。
此時可能產生的圖有:Use Case Diagrams, Text Use Case descriptions, Activity diagrams

系統分析 (Analysis)

在此步驟時，開發者以他們自己的觀點對問題進行分析。此時仍然不會考慮技術的問題。這時工作的焦點在於發現系統中角色(物件)，及這些角色(物件)的責任(Responsibilities)。此階段的工作成果將作為後面技術選擇及設計的基礎。此階段的工作屬於概念性(Conceptual)的工作，簡單的說，就是發現物件並找出各物件之間的關係，同時指派各物件的任務。此時產生的 UML 文件可能是草稿的形式，純粹表達出對系統的抽象概念，與任何資訊技術或程式語言沒有關係。
此時可能產生的 UML 圖有:Class Diagrams, Sequence Diagrams, Collaboration Diagrams

技術選擇 (Technology Selection)

顧名思義，此階段的工作是要選擇適當的技術來實現系統需求。此步驟若要做的好，必須對當前技術有相當的瞭解，例如某種技術的特點，有何優點及缺點等，皆必須有相當的認識，否則將造成後來許多問題。
此時沒有 UML 文件產生。

決定系統架構 (Architecture)

將系統猜拆成若干子系統。此時是以一個非常高階的觀點來拆解系統。可能按照 系統間的關係拆解，也可能依照技術因素拆解。
此時可能產生的 UML 圖有: Primarily Class Diagrams, Package Diagrams

設計與實作 (Design and Implementation)

此時以前述步驟的基礎，進行系統類別的設計與實作。此時會將前面所產出的文件更加精製化，以作出完整的 UML 文件。此時也是本發展循環中，最後一次更動系統架構的機會。我們會使用許多設計樣式(Design Pattern)作出具體的類別架構設計，當一切完成時，即選擇一物件導向語言實作系統。同時，在這一連串的步驟中所 產出的文件，可做為系統測試的依據，及系統發展進程的指標。
事實上，這些步驟不一定是循序漸進進行，可能有若干步驟會同時進行，而也不是每
一種 UML 文件都要產生。重點是不要太過拘泥於形式，而是要學習及掌握物件導向
分析與設計的精神與方法。畢竟，在 UML 誕生之前，物件導向方法即已存在，UML 只
不過是將一些不錯的方法整理起來而已，以提供一套大家可以用來溝通的符號罷了。

記住: UML 可以讓你以一套規則模型化系統，但是它不會教你如何去模型化系統，也 不會教你如何實做出有彈性的系統！不會教你如何實做出有彈性的系統！