UML：Unified Modeling Language，即統一建模語言，簡單地說就是一種有特殊用處的語言。本文是我初步學習UML的學習筆記，對於我們菜鳥碼農來說，讓我們做設計的可能性不大，但至少能看懂是必要的。
一、所謂模型
1.1 模型是對現實的簡化
模型是提供系統的藍圖，模型可是包括詳細計划。也可是是從更高程度考慮系統的總體計划，每個系統可以從不同的方面用不通過的模型來描述。因而每個模型都是在語義上閉合的抽象系統。模型可以是結構性的，強調系統的組織。也可是是行為性的，強調系統的動態方面。
1.2 為什么要建模？
有人雲：建模是為了能夠更好地理解正在開發的系統！
通過建模可以達到如下目的：
1、模型有助於按照實際情況或按照所需的樣式對系統進行可視化；
2、模型能夠規約系統的結構或行為；
3、模型給出了構造系統的模板；
4、模型對做出的決策進行文檔化；
PS：對於一個復雜的系統，如銀行、電信系統建模的重要性就越大。如果不能很好的理解一個復雜系統，盲目開發，失敗的可能性很大。
二、小談UML
2.1 神馬是UML？
統一建模語言(Unified Modeling Language , UML) 是一種繪制軟件藍圖的標准語言，可以用UML對軟件密集的制品進行可視化、詳述、構造和文檔化。
2.2 UML的優點
1、可視化：清晰的模型有利於交流
2、詳述：可以使用UML對分析、設計、實現等決策進行詳細描述
3、構造：把UML描述映射成編程語言
4、文檔化：系統的所有細節都可以是UML進行描述。如：項目計划、發布活動等
2.3 應用領域
1、企業信息系統
2、銀行與金融服務
3、電信
4、國防、航天
5、科學
6、基於Web的分布式服務
三、類圖—分析業務模型
3.1 類
類是一組具有相同屬性、操作、關系和語義的對象描述，一個類可是實現一個或者多個接口。下圖是類在VS里面的圖形表示：
（1）UML預設了四種可見性，分別為公開(public)、私有(private)、保護(protected)、包(package) 減號(-)為私有可見性，加號(+)為公開可見性。可見，上圖中的類圖所有都為public。
（2）在UML中抽象類與普通是同一個是圖表示，只是名字會變成斜體，如下圖所示，調整IsAbstract屬性為True后類名變為斜體：
3.2 關系
關系是事物之間的聯系，在面向對象的建模中，有三種重要的關系是依賴、泛化、關聯。
（1）依賴
依賴是一種使用關系，一個事物使用另一個事物。在圖形上，把依賴畫成一條有方向的虛線，指向被依賴的事物。如果被使用的類發生變化,那么另一個類的操作必然受影響。依賴關系在.net語言中體現為 局部變量、方法的參數或者對靜態方法的調用，如工具類，現實生活中人與錘子。
（2）泛化
在泛化關系中，子類繼承了父類的行為和含義，子類也可以增加新的行為和含義或覆蓋父類中的行為和含義。在圖形上，在泛化畫成一個帶有空心三角行指向父類。泛化在.net中就是一個繼承的關系。
（3）關聯
關聯是一種結構關系，它指明一個對象與另一個對象間的關系。
①相互關聯體現的是兩個類、或者 類與接口之間語義級別的一種強依賴關系，是一種長期的穩定的關系；表現在代碼層面，為被關聯類以類屬性的形式出現在關聯類中，也可能是關聯類引用了一個類型為被關聯類的全局變量。
上圖中ClassA與ClassB相互關聯，在代碼中各自有對方類型實例的一個屬性。
②單向關聯表現在代碼層面，為被關聯類B 以類屬性的形式出現在關聯類 A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；
上圖中Subject關聯Observer，並且是一個一對多的關系，那么在代碼中Subject類中會有一個Observer類對象的集合屬性。
下面我們來看看幾種特殊的關聯關系，他們是：
③聚合關系：
聚合是關聯關系的一種特例，他體現的是整體與部分擁有的關系。此時整體與部分之間是可分離的，他們可以具有各自的生命周期，部分可以屬於多個整體對象，也可以為多個整體對象共享；比如汽車與發動機；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分。
④組合關系：
組合也是關聯關系的一種特例，這種關系比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關系，但此時整體與部分是不可分的，整體的生命周期結束也就意味着部分的生命周期結束。例如：孕婦死了胎兒自然也就死了（有點血腥的例子，抱歉！）；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分。
3.3 接口
接口(interface)如同契約，負責的類必須負責實現它的公開操作，以及負責維護它的公開屬性。
3.4 綜合案例：公司-部門-員工 類圖關系
四、用例圖—描述系統的行為
用例圖用來表達系統對外提供的服務或功能，適合用來作為需求搜集階段的工作。
4.1 用例與執行者
實際設計中，常用用例(UseCase)來表達系統需求或者系統對外呈現的行為。用例采用橢圓圖示，參與者(Actor)是人型圖示。由於它會參與系統的運作，因此它跟用例之間有連接線段。
4.2 包含關系
包含（include）關系指的是兩個用例之間的關系，其中一個用例（稱作基本用例，base use case）的行為包含了另一個用例（稱作包含用例，include case）的行為。如下圖，取款的 時候會包含一個用戶驗證的用例。
4.3 擴展關系
擴展（extend）關系將基本用例中一段相對獨立並且可選的動作，用擴展（Extension）用例加 以封裝，再讓它從基用例中聲明的擴展點（Extension Point）上進行擴展，從而使基用例行為更簡練和目標更集中。如下圖，我們在取完款后，可以打印憑條，也可以不用打印憑條。這個功能就可以使用擴展來表示。
五、活動圖—流程分析利器之一
活動圖通常用來表達業務流程、工作流或系統流程中一連串的動作。在我的實習前期，就經常用到活動圖來繪制需求調研到的業務流程，並將活動圖展示給客戶以確認需求，客戶也能看輕松地看懂。例如，下圖是一個簡單的登陸流程，登陸失敗跳轉到登陸頁面，登陸成功則跳轉到主界面。
PS：每個活動圖只能有一個開始節點,但是可以有多個結束節點
（1）動作
動作（activity）是最重要的組成元素，它代表一個執行步驟。
（2）控制流
帶箭頭的連接線稱為控制流(control flow)。當來源動作結束之后，控制流會啟動目標動作。
（3）對象節點與對象流
對象節點(object node)為矩形圖示，對象流(object flow)的圖示與控制流相同，不過它的其中一個端點必須是對象節點，而另一端必須是其他節點。控制流的兩個端點不可以都是對象節點。對象流不同於控制流，對象流可以攜帶數據或對象。
上圖所示，在登陸成功后，我們將用戶的Session對象傳遞到下一個節點，下一個節點可以使用此對象。
（4）決策與合並
活動流程中，流程交匯點，稱為合並節點(merge node)。一個合並節點會有多條進入線，但是只有一條離開線，合並節點的圖示是大的空心菱形，所有進入合並節點的支流都會經歷同一條離開線。
決策節點(decision node)與合並節點共用圖示，兩者都是大的空心菱形。不過，決策節點只有一個進入線，但有多條離開線。
（5）分叉和連接
分叉表示的是一個控制流被兩個或多個控制流代替，經過分叉后，這些控制流是並發進行的。
連接正好與分叉相反，表示兩個或多個控制流被一個控制流代替。使用分叉需要使用連接把分叉的流匯聚成一個流。
（6）發送信號和接受事件
發送信號操作是一種操作，可以將消息或信號發送給另一個活動。
接受事件操作是一種要在等到消息或信號后才能繼續執行的操作。
如上圖所示，創建發票是一個發送信號，將發票這個消息發給另一個活動：收款。而收款是一個接受事件，它必須等到開完發票才能繼續執行后續操作。
六、時序圖—流程分析利器之二
時序圖，又稱序列圖，用來表達系統內部一群對象的交互情況，它是一種行為圖。水平方向是對象維，垂直方向是時間維。例如：page與action之間的交互情況可以用時序圖來表示，在發送list請求的時候我們需要一個返回結果集。
（1）生命線
生命線(lifeline)代表一個參與交互的實例，它的圖示是頂端連接矩形的虛線，虛線頂部的矩形可以放置生命線的名稱。
（2）執行發生
對象在接收到消息之后執行一項活動，執行期間稱為執行發生(execution occurrence)，它的圖示是長條矩形。
（3）消息
消息(message)的圖示是一條帶箭頭的線段，橫跨在兩個生命線上,對象之間通過發送消息來交互。
（4）終止
生命線有生有滅，終止(stop)就是用來表達生命線終止的時刻。終止的圖示是一個大叉，放置在生命線的虛線底部，代表生命線已經終止。
參考資料
（1）張傳波，《火球——UML大戰需求分析》，http://www.amazon.cn/tushu/dp/B0079FMI40
（2）周猛，《UML統一建模語言基礎》，http://wenku.baidu.com/view/28fe7f65ad02de80d4d840ec.html