在使用UML畫圖之前，相信很多人跟我一樣是用Office Visio來描述系統架構與流程圖，通常扣掉比較有統一規則的流程圖、有限狀態機之類的圖型之後，其他需要的描述就是天馬行空自行去發揮，既自由又被老師說看不懂。在知道有UML之後，就開始嘗試導入UML的方式來做系統方面的分析。一開始真的挺辛苦的，對圖型定義的了解不夠，很多想法不知道怎麼用內建的圖型去表示，因此還是嚮往從前的天馬行空方式。不過使用UML的優點在於圖形的意義與描述的方式上已經有一個標準化的定義，因此只要是同樣有了解UML的人，在閱讀你的圖形上，可以快速上手而不需要猜測圖形的意義。而老闆覺得圖形太醜的時候，也可以解釋這是標準圖形了，頂多加點立體感但不會要你去畫出全新又需要漂漂亮亮的圖了。
UML基本元素
Grady Booch, James Rumbaugh, Ivar Jacobson合著的The Unified Modeling Language User Guide經過張裕益漢化之後的翻譯本裡面告訴我們UML的分成要素為：1. Things 2. Relationships 3. Diagrams。當然細分還有很多的元素，但是基本的組成方式就是由Things做基礎描述後，Relationships做為Things之間關聯性的補充，最後形成一個有意義的Diagram。
Things詳細解釋時，可以再細分為四大項十一個子項，如圖所示：
Relationships細分下去為下列四項，如圖所示：
Diagramsy在UML 1.1規範了9個Diagrams，如圖所示：
#07/25/07
UML塑造系統架構
用圖形的方式讓專案各種不同定位之人員描述與檢查系統時，可以根據不同的定位，著重於各自需求的圖形做檢查。整個系統在架構的過程中，必須十分謹慎的決定系統的組織以及定義各元件、介面與行為，藉此逐漸形成一個子系統，再進而組合成一個大規模的系統。在系統的描述上，大規模的系統概念圖將由Use Case Diagram所主導，而根據各定位分別去描述細項的功能，進而完整塑造出整個系統的架構，下圖所示是一個系統描述時，在於Use Case Diagram描述下，將透過四個View分別描述更細節的流程。
Design View - 以系統設計的觀點去詳細描述Class、Interace、Collaboration以所有組成的問題與解決方案。通常與此階段的描述中，靜態的內容將交由Class Diagram與Object Diagram；動態的內容將交由Collaboration Diagram、Statechart Diagram、Activity Digram來補充。
Process View - 以系統的行程觀點記錄系統於同時進行與同步進行之各Thread/Process。此觀點主要為了描述系統的效能與擴充性，方便針對系統的整體輸出效率上做檢視。於靜態的描述上，仍然適合使用Class Diagram；動態的描述則主要使用Collaboration Diagram、Statechart Diagram
Implementation View - 以實作系統作為觀點時，將強調系統發行的設定與管理。而設定與管理主要必須將系統各自獨立的元件與檔案以各種方式組合，建立一個提供服務的系統。於主要於靜態的描述上交由Component Diagram；動態的描述上則經由Collaboration Diagram、Statechart Diagram、Activity Diagram來進行補充。
Deployment View - 此觀點主要是描述系統硬體配置狀態，藉此描述所需設備之硬體個節點狀態與配置情形，藉此方便系統安裝與建置。在靜態描述上主要透過Deployment Diagram來描述；動態的補充上則交由Collaboration Diagram、Statechart Diagram、Activity Diagram。
#07/29/07
沒有留言:
張貼留言