第3章 UML初覽
本章使用一個簡單的例子對UML中所使用的概念和視圖進行初覽。本章的目的是要將高層UML概念組織成一系列較小的視圖和圖表來可視化說明這些概念，說明如何用各種不同的概念來描述一個系統以及如何將各種視圖組織在一起。概括性的說明不可能面面俱到，其中省略了許多概念。要想得到更詳細的說明，可參見下一章對UML各視圖的說明和本書大全部分的有關細節。
本章使用的例子是計算機管理的戲院售票系統。這是一個精心設計的例子，目的是用少量篇幅來強調說明UML的各個組件。這是一個經過有意簡化的例子，忽略了有關細節。除非進行大量的反覆說明，否則一個實際系統的完整模型不可能用這麼少的篇幅來對UML中使用的每種組件進行介紹。
3.1 UML視圖
UML中的各種組件和概念之間沒有明顯的劃分界限，但爲方便起見，我們用視圖來劃分這些概念和組件。視圖只是表達系統某一方面特徵的UML建模組件的子集。視圖的劃分帶有一定的隨意性，但我們希望這種看法僅僅是直覺上的。在每一類視圖中使用一種或兩種特定的圖來可視化地表示視圖中的各種概念。
在最上一層，視圖被劃分成三個視圖域：結構分類、動態行爲和模型管理。
結構分類描述了系統中的結構成員及其相互關係。類元包括類、用例、構件和節點。類元爲研究系統動態行爲奠定了基礎。類元視圖包括靜態視圖、用例視圖和實現視圖。
動態行爲描述了系統隨時間變化的行爲。行爲用從靜態視圖中抽取的瞬間值的變化來描述。動態行爲視圖包括狀態機視圖、活動視圖和交互視圖。
模型管理說明了模型的分層組織結構。包是模型的基本組織單元。特殊的包還包括模型和子系統。模型管理視圖跨越了其他視圖並根據系統開發和配置組織這些視圖。
UML還包括多種具有擴展能力的組件，這些擴展能力有限但很有用。這些組件包括約束、構造型和標記值，它們適用於所有的視圖元素。
表3-1列出了UML的視圖和視圖所包括的圖以及與每種圖有關的主要概念。不能把這張表看成是一套死板的規則，應將其視爲對UML常規使用方法的指導，因爲UML允許使用混合視圖。
表3-1 UML視圖和圖
![t-1.gif]()
3.2 靜態視圖
靜態視圖對應用領域中的概念以及與系統實現有關的內部概念建模。這種視圖之所以被稱之爲是靜態的是因爲它不描述與時間有關的系統行爲，此種行爲在其他視圖中進行描述。靜態視圖主要是由類及類間相互關係構成，這些相互關係包括：關聯、泛化和各種依賴關係，如使用和實現關係。一個類是應用領域或應用解決方案中概念的描述。類圖是以類爲中心來組織的，類圖中的其他元素或屬於某個類或與類相關聯。靜態視圖用類圖來實現，正因爲它以類爲中心，所以稱其爲類圖。
在類圖中類用矩形框來表示，它的屬性和操作分別列在分格中。如不需要表達詳細信息時，分格可以省略。一個類可能出現在好幾個圖中。同一個類的屬性和操作只在一種圖中列出，在其他圖中可省略。
關係用類框之間的連線來表示，不同的關係用連線上和連線端頭處的修飾符來區別。
圖3-1是售票系統的類圖，它只是售票系統領域模型的一部分。圖中表示了幾個重要的類，如Customer、Reservation、Ticket和Performance。顧客可多次訂票，但每一次訂票只能由一個顧客來執行。有兩種訂票方式：個人票或套票；前者只是一張票，後者包括多張票。每一張票不是個人票就是套票中的一張，但是不能又是個人票又是套票中的一張。每場演出都有多張票可供預定，每張票對應一個唯一的座位號。每次演出用劇目名、日期和時間來標識。
3.3 用例視圖
用例視圖是被稱爲參與者的外部用戶所能觀察到的系統功能的模型圖。用例是系統中的一個功能單元，可以被描述爲參與者與系統之間的一次交互作用。用例模型的用途是列出系統中的用例和參與者，並顯示哪個參與者參與了哪個用例的執行。
圖3-2是售票系統的用例圖。參與者包括售票員、監督員和公用電話亭。公用電話亭是另一個系統，它接受顧客的訂票請求。在售票處的應用模型中，顧客不是參與者，因爲顧客不直接與售票處打交道。用例包括通過公用電話亭或售票員購票，購預約票（只能通過售票員），售票監督（應監督員的要求）。購票和預約票包括一個共同的部分—即通過信用卡來付錢（對售票系統的完整描述還要包括其他一些用例，例如換票和驗票等）。
用例也可以有不同的層次。用例可以用其他更簡單的用例進行說明。在交互視圖中，用例做爲交互圖中的一次協作來實現。
![3-2.gif]()
圖3-2 用例圖
3.4 交互視圖
交互視圖描述了執行系統功能的各個角色之間相互傳遞消息的順序關係。類元是對在系統內交互關係中起特定作用的一個對象的描述，這使它區別於同類的其他對象。交互視圖顯示了跨越多個對象的系統控制流程。交互視圖可用兩種圖來表示：順序圖和協作圖，它們各有不同的側重點。
3.4.1 順序圖
順序圖表示了對象之間傳送消息的時間順序。每一個類元角色用一條生命線來表示—即用垂直線代表整個交互過程中對象的生命期。生命線之間的箭頭連線代表消息。順序圖可以用來進行一個場景說明—即一個事務的歷史過程。
順序圖的一個用途是用來表示用例中的行爲順序。當執行一個用例行爲時，順序圖中的每條消息對應了一個類操作或狀態機中引起轉換的觸發事件。
圖3-3是描述購票這個用例的順序圖。顧客在公共電話亭與售票處通話觸發了這個用例的執行。順序圖中付款這個用例包括售票處與公用電話亭和信用卡服務處的兩個通信過程。這個順序圖用於系統開發初期，未包括完整的與用戶之間的接口信息。例如，座位是怎樣排列的；對各類座位的詳細說明都還沒有確定。儘管如此，交互過程中最基本的通信已經在這個用例的順序圖中表達出來了。
![3-3.gif]()
圖3-3 順序圖
3.4.2 協作圖
協作圖對在一次交互中有意義的對象和對象間的鏈建模。對象和關係只有在交互的纔有意義。類元角色描述了一個對象，關聯角色描述了協作關係中的一個鏈。協作圖用幾何排列來表示交互作用中的各角色（如圖3-4）。附在類元角色上的箭頭代表消息。消息的發生順序用消息箭頭處的編號來說明。
協作圖的一個用途是表示一個類操作的實現。協作圖可以說明類操作中用到的參數和局部變量以及操作中的永久鏈。當實現一個行爲時，消息編號對應了程序中嵌套調用結構和信號傳遞過程。
圖3-4是開發過程後期訂票交互的協作圖。這個圖表示了訂票涉及的各個對象間的交互關係。請求從公用電話亭發出，要求從所有的演出中查找某次演出的資料。返回給ticketseller對象的指針db代表了與某次演出資料的局部暫時鏈接，這個鏈接在交互過程中保持，交互結束時丟棄。售票方準備了許多演出的票；顧客在各種價位做一次選擇，鎖定所選座位，售票員將顧客的選擇返回給公用電話亭。當顧客在座位表中做出選擇後，所選座位被聲明，其餘座位解鎖。
順序圖和協作圖都可以表示各對象間的交互關係，但它們的側重點不同。順序圖用消息的幾何排列關係來表達消息的時間順序，各角色之間的相關關係是隱含的。協作圖用各個角色的幾何排列圖形來表示角色之間的關係，並用消息來說明這些關係。在實際中可以根據需要選用這兩種圖。
![3-4.gif]()
圖3-4 協作圖
3.5 狀態機視圖
狀態機視圖是一個類對象所可能經歷的所有歷程的模型圖。狀態機由對象的各個狀態和連接這些狀態的轉換組成。每個狀態對一個對象在其生命期中滿足某種條件的一個時間段建模。當一個事件發生時，它會觸發狀態間的轉換，導致對象從一種狀態轉化到另一新的狀態。與轉換相關的活動執行時，轉換也同時發生。狀態機用狀態圖來表達。
圖3-5是票這一對象的狀態圖。初始狀態是Available狀態。在票開始對外出售前，一部分票是給預約者預留的。當顧客預定票，被預定的票首先處於鎖定狀態，此時顧客仍有是否確實要買這張票的選擇權，故這張要票可能出售給顧客也可能因爲顧客不要這張票而解除鎖定狀態。如果超過了指定的期限顧客仍未做出選擇，此票被自動解除鎖定狀態。預約者也可以換其他演出的票，如果這樣的話，最初預約票也可以對外出售。
狀態圖可用於描述用戶接口、設備控制器和其他具有反饋的子系統。它還可用於描述在生命期中跨越多個不同性質階段的被動對象的行爲，在每一階段該對象都有自己特殊的行爲。
![3-5.gif]()
圖3-5 狀態圖
3.6 活動視圖
活動圖是狀態機的一個變體，用來描述執行算法的工作流程中涉及的活動。活動狀態代表了一個活動：一個工作流步驟或一個操作的執行。活動圖描述了一組順序的或併發的活動。活動視圖用活動圖來體現。
圖3-6是售票處的活動圖。它表示了上演一個劇目所要進行的活動（這個例子僅供參考，不必太認真地憑着看戲的經驗而把問題複雜化）。箭頭說明活動間的順序依賴關係—例如，在規劃進度前，首先要選擇演出的劇目。加粗的橫線段表示分叉和結合控制。例如，安排好整個劇目的進度後，可以進行宣傳報道、購買劇本、僱用演員、準備道具、設計照明、加工戲服等，所有這些活動都可同時進行。在進行彩排之前，劇本和演員必須已經具備。
這個例說明了活動圖的用途是對人類組織的現實世界中的工作流程建模。對事物建模是活動圖的主要用途，但活動圖也可對軟件系統中的活動建模。活動圖有助於理解系統高層活動的執行行爲，而不涉及建立協作圖所必須的消息傳送細節。
用連接活動和對象流狀態的關係流表示活動所需的輸入輸出參數。
![3-6.gif]()
圖3-6 活動圖
3.7 物理視圖
前面介紹的視圖模型按照邏輯觀點對應用領域中的概念建模。物理視圖對應用自身的實現結構建模，例如系統的構件組織和建立在運行節點上的配置。這類視圖提供了將系統中的類映射成物理構件和節點的機制。物理視圖有兩種：實現視圖和部署視圖。
實現視圖爲系統的構件建模型—構件即構造應用的軟件單元—還包括各構件之間的依賴關係，以便通過這些依賴關係來估計對系統構件的修改給系統可能帶來的影響。
實現視圖用構件圖來表現。圖3-7是售票系統的構件圖。圖中有三個用戶接口：顧客和公用電話亭之間的接口、售票員與在線訂票系統之間的接口和監督員查詢售票情況的接口。售票方構件順序接受來自售票員和公用電話亭的請求；信用卡主管構件之間處理信用卡付款；還有一個存儲票信息的數據庫構件。構件圖表示了系統中的各種構件。在個別系統的實際物理配置中，可能有某個構件的多個備份。
![3-7.gif]()
圖3-7 構件圖
圖中的小圓圈代表接口，即服務的連貫集。從構件到接口的實線表明該構件提供的列在接口旁的服務。從構件到接口的虛線箭頭說明這個構件要求接口提供的服務。例如，購買個人票可以通過公用電話亭訂購也可直接向售票員購買，但購買團體票只能通過售票員。
部署視圖描述位於節點實例上的運行構件實例的安排。節點是一組運行資源，如計算機、設備或存儲器。這個視圖允許評估分配結果和資源分配。
部署視圖用部署圖來表達。圖3-8是售票系統的描述層部署圖。圖中表示了系統中的各構件和每個節點包含的構件。節點用立方體圖形表示。
![3-8.gif]()
圖3-8 部署圖（描述層）
圖3-9是售票系統的實例層部署圖。圖中顯示了各節點和它們之間的連接。這個模型中的信息是與圖3-8的描述層中的內容相互對應的。
![3-9.gif]()
圖3-9 部署圖（實例層）
3.8 模型管理視圖
模型管理視圖對模型自身組織建模。一系列由模型元素（如類、狀態機和用例）構成的包組成了模型。一個包(package)可能包含其他的包，因此，整個模型實際上可看成一個根包，它間接包含了模型中的所有內容。包是操作模型內容、存取控制和配置控制的基本單元。每一個模型元素包含於包中或包含於其他模型元素中。
模型是從某一觀點以一定的精確程度對系統所進行的完整描述。從不同的視角出發，對同一系統可能會建立多個模型，例如有系統分析模型和系統設計模型之分。模型是一種特殊的包。
子系統是另一種特殊的包。它代表了系統的一個部分，它有清晰的接口，這個接口可作爲一個單獨的構件來實現。
模型管理信息通常在類圖中表達。
圖3-10顯示了將整個劇院系統分解所得到的包和它們之間的依賴關係。售票處子系統在前面的例子中已經討論過了，完整的系統還包括劇院管理和計劃子系統。每個子系統還包含了多個包。
![3-10.gif]()
圖3-10 包
3.9 擴展組件
UML包含三種主要的擴展組件：約束、構造型和標記值。約束是用某種形式化語言或自然語言表達的語義關係的文字說明。構造型是由建模者設計的新的模型元素，但是這個模型元素的設計要建立在UML已定義的模型元素基礎上。標記值是附加到任何模型元素上的命名的信息塊。
這些組件提供了擴展UML模型元素語義的方法，同時不改變UML定義的元模型自身的語義。使用這些擴展組件可以組建適用於某一具體應用領域的UML用戶定製版本。
圖3-1舉例說明了約束、構造型，和標記值的使用。對劇目類的約束保證了劇目具有唯一的名稱。圖3-1說明了兩個關聯的異或約束，一個對象某一時刻只能具有兩個關聯中的一個。用文字表達約束效果較好，但UML的概念不直接支持文字描述。
TicketdDB構件構造型表明這個是一個數據庫構件，允許省略該構件的接口說明，因爲這個接口是所有數據庫都支持的通用接口。建模者可以增加新的構造型來表示專門的模型元素。一個構造型可以帶有多個約束、標記值或者代碼生成特性。如圖所示，建模者可以爲命名的構造型定義一個圖標，作爲可視化的輔助工具。儘管如此，可以使用文字形式說明。
Scheduling包中的標記值說明Frank Martin要在年底世紀前完成計劃的制定。可以將任意信息作爲標記值寫於一個模型元素中建模者選定的名字之下。使用文字有益於描述項目管理和代碼生成參數。大部分標記值保存爲編輯工具中的彈出信息，在正式打印出的圖表中通常沒有標記值。
![3-11.gif]()
圖3-11 擴展組件
3.10 各種視圖間的關係
多個視圖共存於一個模型中，它們的元素之間有很多關係，其中一些關係列在表3-2中。表中沒有將各種關係列全，但它列出了從不同視角觀察得到的元素間的部分主要關係。
表3-2 不同視圖元素間的部分關係
![t-2.gif]()
| 
