面向對象問題解決的核心是構建一個模型。該模型從其通常復雜的現實世界中抽象出基本問題的基本細節(jié)。幾個建模工具被包裹在UML ? 的標題下，代表統(tǒng)一建模語言?。本課程的目的是介紹UML的重要亮點。

UML的中心是我們在這里描述的九種建模圖。

• 用例圖

• 類圖

• 對象圖

• 序列圖

• 協作圖

• 狀態(tài)圖

• 活動圖

• 組件圖

• 部署圖

本課程的某些部分包含具有更詳細信息的頁面的鏈接。每個部分都有簡短的問題。使用它們來測試您對本節(jié)主題的理解。

為什么UML很重要？

從建造業(yè)的角度來看，我們來看看這個問題。建筑師設計建筑。建筑商使用設計來創(chuàng)建建筑物。建筑越復雜，建筑師和建筑師之間的溝通越重要。藍圖是建筑師和建筑商必須學習的標準圖形語言，作為其交易的一部分。

寫作軟件與建筑物不同。底層系統(tǒng)越復雜，每個參與創(chuàng)建和部署軟件的人之間的溝通就越重要。在過去十年中，UML已經成為分析師，設計師和程序員的軟件藍圖語言。它現在是軟件貿易的一部分。UML讓所有人從業(yè)務分析師到設計人員到程序員一個常見的詞匯來談論軟件設計。

UML適用于面向對象的問題解決。任何有興趣學習UML的人都必須熟悉面向對象問題解決的基本原則 - 這一切都是從構建模型開始的。甲模型是根本問題的抽象。該領域是問題來自的實際世界。

模型由通過發(fā)送彼此消息進行交互的對象組成。把一個對象看成是“活著的”。對象有他們知道的東西（屬性）和他們可以做的事情（行為或操作）。對象屬性的值決定其狀態(tài)。

類是對象的“藍圖”。類將屬性（數據）和行為（方法或函數）包裝到單個不同的實體中。對象是實例的類。

用例圖

用例圖從外部觀察者的角度描述系統(tǒng)的作用。重點是什么樣的系統(tǒng)呢，而不是如何。

用例圖與情景密切相關。一個情景是當某人與系統(tǒng)進行交互時會發(fā)生的情況的示例。這是一個診所的場景。

一個 用例是單個任務或目標的場景概要。一個演員是誰或什么啟動與該任務有關的事件。演員只是人或物體的角色。下面的圖片是醫(yī)療診所的預約用例。演員是病人。actor和用例之間的連接是通信關聯（簡稱為通信）。

隱藏圖像

演員是棒人物。用例是橢圓形。通信是將演員與用例聯系起來的線條。

用例圖是一組actor，用例和通信。我們已經將“約會”作為四個演員和四個用例的圖表的一部分。請注意，單個用例可以有多個actor。

隱藏圖像

用例圖在三個方面有所幫助。

• 確定特征（要求）。隨著系統(tǒng)的分析和設計的形成，新的用例經常會產生新的需求。

• 與客戶溝通。他們的簡明易懂使得用例圖成為開發(fā)人員與客戶溝通的好方法。

• 生成測試用例。用例情景的收集可能會為這些場景提供一套測試用例。

類圖

類圖通過顯示系統(tǒng)的類和它們之間的關系來概述系統(tǒng)。類圖是靜態(tài)的 - 它們顯示出什么交互，但不會發(fā)生什么交互。

下面的類圖從零售目錄模擬客戶訂單。中央階級是秩序。與此相關的是客戶進行購買和付款。一個付款是三種：現金，檢查，或信用。該訂單包含OrderDetails（行項目），每個都有其關聯的項目。

隱藏圖像

UML類符號是一個矩形，分為三個部分：類名，屬性和操作。抽象類的名稱，如Payment，以斜體表示。類之間的關系是連接鏈接。

我們的類圖有三種關系。

• 關聯 - 兩個類的實例之間的關系。如果一個類的實例必須知道另一個類才能執(zhí)行其工作，則有兩個類之間的關聯。在圖中，關聯是連接兩個類的鏈接。

• 聚合 - 一個類屬于一個集合的關聯。聚合具有指向包含整體的部分的鉆石端。在我們的圖中， Order有一個OrderDetails的集合。

• 泛化 - 一個繼承鏈接，表示一個類是另一個類的超類。泛化有一個指向超類的三角形。付款是現金，支票和信用證的超類。

協會有兩方面。結束可能有一個角色名稱來澄清協會的性質。例如， OrderDetail是每個訂單的一個訂單項。

一個 關聯上的導航箭頭顯示可以遍歷或查詢關聯的方向。一個的OrderDetail可以查詢有關其項目周圍，而不是其他方式。箭頭還可以讓您知道誰擁有該協會的實施; 在這種情況下， OrderDetail有一個項目。沒有導航箭頭的協會是雙向的。

該 關聯端的多重性是與另一端的單個實例相關聯的類的可能實例的數量。倍數是單個數字或數字范圍。在我們的示例中，每個訂單只能有一個客戶，但客戶可以有任意數量的訂單。

這個表給出了最常見的多重性。

每個類圖都有類，關聯和多重性。導航和角色是放置在圖中以提供清晰度的可選項。

軟件包和對象圖

為了簡化復雜的類圖，您可以將類分組 包。一個包是邏輯上相關的UML元素的集合。下面的圖是一個業(yè)務模型，其中類被分組成包。

隱藏圖像

軟件包顯示為頂部小標簽的矩形。包名稱在標簽上或矩形內。虛線箭頭是依賴關系。一個包裝取決于另一個包裝是否可能會在第一個更改中強制更改。

對象圖顯示實例而不是類。它們用于解釋具有復雜關系的小件，特別是遞歸關系。

這個小類圖顯示，大學部可以包含很多其他部門。

隱藏圖像

下面的對象圖實例化了類圖，用一個具體的例子代替了它。

隱藏圖像

對象圖中的每個矩形對應于單個實例。實例名稱在UML圖中加下劃線。只要圖意義仍然清晰，可以從對象圖中省略類或實例名稱。

序列圖

類和對象圖是靜態(tài)模型視圖。 互動圖是動態(tài)的。他們描述對象如何協作。

一個 序列圖是一個交互圖，詳細介紹了如何執(zhí)行操作 - 發(fā)送什么消息以及什么時間。序列圖按時間組織。隨著時間的推移，您在頁面下滑。根據參與消息序列的時間，從左到右列出了操作中涉及的對象。

以下是進行酒店預訂的序列圖。啟動消息序列的對象是一個預留窗口。

隱藏圖像

的預約窗口發(fā)送makeReservation（）消息到HotelChain。所述HotelChain然后發(fā)送makeReservation（）消息到飯店。如果酒店有空房，那么預訂和確認。

每條垂直虛線都是a 生命線，表示對象存在的時間。每個箭頭都是一個消息調用。箭頭從發(fā)送者到頂部接收機生命線上消息的激活條。激活條表示消息的執(zhí)行持續(xù)時間。

在我們的圖表中，酒店發(fā)出一個自我呼叫以確定房間是否可用。如果是這樣，酒店將創(chuàng)建一個預訂和確認。自我呼叫上的星號意味著迭代（以確保在酒店的每一天的可用空間）。方括號[]中的表達式是一個條件。

該圖有一個澄清 注意，這是一個狗耳朵的矩形內的文本。Notes可以放在任何一種UML圖中。

協作圖

協作圖也是交互圖。它們傳達與序列圖相同的信息，但它們專注于對象角色，而不是發(fā)送消息的時間。在序列圖中，對象角色是頂點，消息是連接鏈接。

隱藏圖像

對象角色矩形用類或對象名稱（或兩者）標記。類名前面是冒號（：）。

協作圖中的每個消息都有一個 序列號。頂級消息編號為1.相同級別的消息（在相同呼叫期間發(fā)送）具有相同的十進制前綴，而后綴為1,2等，根據發(fā)生的時間。

狀態(tài)圖

對象有行為和狀態(tài)。對象的狀態(tài)取決于當前的活動或狀態(tài)。一個狀態(tài)圖顯示了對象的可能狀態(tài)和導致狀態(tài)改變的轉換。

我們的示例圖模擬了網上銀行系統(tǒng)的登錄部分。登錄包括輸入有效的社會保險號碼和個人身份證號碼，然后提交信息進行驗證。

登錄可以分為四個不重疊的狀態(tài)：獲取SSN，獲取PIN，驗證和拒絕。從每個國家來的都是一套完整的確定后續(xù)狀態(tài)的轉換。

隱藏圖像

國家是圓角矩形。過渡是從一個國家到另一個國家的箭頭。觸發(fā)過渡的事件或條件寫在箭頭旁邊。我們的圖有兩個自我轉換，一個是獲取SSN，另一個在獲取PIN。

初始狀態(tài)（黑色圓圈）是一個虛擬的開始動作。最終狀態(tài)也是終止動作的虛擬狀態(tài)。

由于事件或條件而發(fā)生的動作以表單/動作表示。當處于“ 驗證”狀態(tài)時，對象不會等待外部事件觸發(fā)轉換。相反，它執(zhí)行一個活動。該活動的結果決定了其后續(xù)狀態(tài)。

活動圖

一個 活動圖本質上是一個花哨的流程圖。活動圖和狀態(tài)圖與之相關。雖然狀態(tài)圖將焦點集中在正在進行過程（或作為對象的進程）上的對象上，活動圖集中在單個進程中涉及的活動流?；顒訄D顯示了這些活動如何依賴于彼此。

對于我們的例子，我們使用了以下過程。

“通過ATM從銀行帳戶提款”。

活動的三個課程（人員等）是客戶，ATM和銀行。該過程從頂部的黑色起始圓開始，并在底部的同心白/黑停止圓處結束?；顒邮菆A角矩形。

隱藏圖像

活動圖可以分為對象 決定哪個對象負責哪個活動的泳道。單身轉換出來的每一項活動，將其連接到下一個活動。

過渡可能 分支到兩個或多個相互排斥的轉換。保護表達式（在 []內））標記從分支出來的轉換。一個分支及其后續(xù)合并標記分支的末端在圖中顯示為空心鉆石。

過渡可能 叉進入兩個或更多的并行活動。叉和隨后從叉子出來的螺紋的連接在圖中顯示為實心條。

組件和部署圖

甲組件是一個代碼模塊。組件圖是類圖的物理類型。部署圖顯示了軟件和硬件的物理配置。

以下部署圖顯示了涉及房地產交易的軟件和硬件組件之間的關系。

隱藏圖像

物理硬件由節(jié)點組成。每個組件都屬于一個節(jié)點。組件顯示為在左上角有兩個選項卡的矩形。