UML學習之路 - Relationships

Relationship -Dependency

Dependency負責描述Things之間的相依關係，並且有方向性的描述，下圖描述Car依賴Driver提供駕駛能力，因此以Class Car為出發點將虛線箭頭指向Object Driver。

Relationship -Generalization

Generalization是表示Things之間繼承關係所使用，如下圖為Child繼承自Parent所做的關係描述。

Relationship -Association

Association為描述兩個Thing之間互相連結的關係，如下圖Worker與Company之間是彼此不可或缺的一部分。Worker必須要有Company而Company也必須擁有Worker，兩者之間不需要方向性來描述。

#07/29/07

UML學習之路 - Class Diagram

程式設計師最快了解的Diagram

Class Diagram在Object-Oriented的設計上，幾乎與程式開發有最直接的映射關係。在Class Diagram中的經常性出現的Things主要為是OO語言中的Class、Interface與Object等，於程式中直接出現的元件。而Relationships就是在補充描述Class之間或與Inteface、Object之間的關係而存在。

Thing - Class

Thing - Class的圖形如下，Class主要圖形為一個矩形，分隔成3個Row：第一個Row上面填寫Class Name；第二個Row為Attributes；第三個Row內為Operation或稱之為Method。

在圖形的描述中，Attribute與Operation的名稱之前，將會有一個符號表示該項目的Scope範圍。有效範圍的描述如下表：

Thing - Interface

Thing - Interface的圖形如下，Interface的圖形非常的簡單，就是一個圓圈的形態，旁邊用文字註明該Interface名稱即可。

Thing - Object

Thing - Object的圖形如下。Object圖型描述也是十分簡單，類似於Class的方式，但是不描述Attributes/Operations，僅文字註明該Object名稱即可。

#07/29/07

UML DIY - 1. 定義最基礎的interface

學習程式最能夠記住的方法就是實作它
為了深刻記住UML原理，我決定慢慢的用程式語言的方式來描述他，雖然可能要花一段時間才能夠完整的呈現，但是相對的對於觀念以及使用上將會更深刻。


我們知道UML組成最基本為Things、Relationships、Diagrams。因此我預計用三個interface來描述這三個基本組成元素。

interface UML.Basic.Thing.IThing{
  function GetID():String; // 取得Things's ID
};
interface UML.Basic.Relationship.IRalationship{
  function GetID():String; // 取得Relationship's ID
  function GetSourceThing():UI.Basic.Thing.IThing;
  // 取得Relationship補充描述之來源Thing元素。
  function GetDestinationThing():UI.Basic.Thing.IThing;
  // 取得Relationship補充描述之目的Thing元素。
};
interface UML.Basic.Diagram.IDiagram{
  function GetID():String; // 取得Diagram's ID
  function GetThings():Array; // 取得此Diagram內所有Things
  function GetRelationships:Array; // 取得此Diagram內所有Relationships
};

UML本身是一個用圖形表示的語言，因此每一個元素一定連帶有一個表示圖形與圖形位置顏色之類的相關訊息，也表示我們需要設計一個IGrahpic去描述基本圖形。

interface UML.Basic.IGraphic{
  function GetRectangle():flash.gemo.Rectangle;
  function GetColor():fl.motion.Color;
  function GetBackgroundColor:fl.motion.Color;
  function Redraw():Void;

UML學習之路

剛開始使用UML的困擾

在使用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