一．建模概述
建模的重要性：
建模是開發優秀軟件的所有活動中的核心部分，其目的是把所要設計的結構和系統的行為溝通起來．並對系統的體系結構進行可視化和控制。建模是為了更好地理解正在構造的系統，並經常提供簡化和復用的機會，同時建模還可以管理風險。
不成功的軟件項目失敗敗原因各不相同，而所有成功的項目的成功原因在很多方面都是相似的：一個成功的軟件組織有很多成功的因素，其中共同的一點就是對建摸的采用。
建模是一項經過檢驗並被廣為接受的工程技術：我們建立的房屋和大廈的建築模型能幫助用戶得到實際建築物的印象：為了分析大風或地震對建築物造成的影響，我們甚至可以建立數學模型。
人對復雜問題的理解能力是有限的、通過建模，縮小所研究問題的范圍。一次只着重研究它的一個方面。這就是Edsger Dijkstra幾年前講的“各個擊破”的基本方法，即先把一個要解決的難題划分成一系列小問題，解決了這些小問題也就解決了這個難題。此外，通過建模可以增強人的智力，一個適當選擇的模型可以使建模人員在較高的抽象層次上工作。
各種工程學科部有其豐富的建模使用歷史。這些經驗形成了建模的四項基本原理，分別敘述如下:
第一，選擇要創建什么模型對如何動手解決問題和如何形成解決方案有着意義深遠的影響。
第二，每一種模型可以在不同的精度級別上表示。
第三，最好的模型是與現實相聯系的。
對軟件領域的結構化分析的致命的缺點就是分析模型與系統設計模型沒有基本的聯系。
第四，單個模型是不充分的。對幾個重要的系統最好用一組幾乎獨立的模型去處理。
根據系統的性質．一些模型可能比另一些模型要重要，例如，對於數據密集型系統．表達靜態設計視圖的模型將占主導地位；對於圖形用屍接口密集型系統，靜態和動態用況視圖就顯得相當重要；在實時系統中，動態進程視圖尤為重要；在分布式系統中，例如web密集型的應用，實現模型和實施模型是最重要的。
建模的種類
對於軟件，有幾種建模的方法：最普遍的兩種方法是從算法的角度建模和面向對象的角度建模。
傳統的軟件開發是從算法的角度進行建模，所有的軟件都用過程或函數作為其主要構造塊。這種觀點導致開發人員把精力集中在控制流程和對大的算法進行分解上。除了用這種方法建立的模型是瞻弱的之外，采用這種方法沒有其他本質上的壞處．當需求發生變化以及系統增長時，用這種方法建造的系統就變得難以維護。
現代的軟件開發采用面向對象的角度進行建模，所有軟件系統采用對象或類作為其主要構造塊。簡單地講，通常要從問題空間或解空間的詞匯中找出對象：類是討具確共同性質的一組對象的描述。每一個對象都有標識(你能夠對它命名，以區別於其他付象)，狀態(通常有一些數據與它相聯系)和行為(使你能夠該對象做某些事，它也能為其他對象做某些事)。
對面向對象系統進行可視化、詳述、構造和文檔化正是統一建模語言UML的目的。
二、UML概述
UML僅僅是一種用於構件軟件藍圖的標准語言，並且僅僅是軟件開發方法的一部分。UML是獨立於過程的，但它貫穿於軟件開發生命期，並能表達系統體系結構的各種不同視圖，最好把它用於以用況為驅動，以體系結構為中心、迭代及增量的過程中。
像UML這樣的語言的詞匯表和規則可以告訴你如何創建或理解結構良好的模型，但它沒有告訴你應該庄什么時候創建什么樣的模型，因為這是軟件開發過程的工作，一個定義明確的過程會紿出如下的指導：決定生產什么制品；由什么樣的活動相人員來創建和管理這些制品；怎樣采用這些制品從整體上去度量和控制項目。
UML不僅是一種可視化的、可用於詳細描述的語言，還是一種構造語言，它雖然不是一種可視化的編程語言，但用UML描述的模型可與各種編程語育直接相連，這意味着一種可能性，即可把用UML描述的模型映射成編程語言，如Java：c++、和visuaI Basic等。甚至映射成關系數據庫的表或面向對象數據庫的永久存儲。對一個事物，如果表示為圖形方式最為恰當，則用UML，而如果表示為文字方式最為恰當，則用編程語言。這種映射允許進行正向工程：從UML模型到編程語言的代碼生成，也可以進行逆向過程：由編程語言代碼重新構造UML模型。逆向工程並不是魔術：除非你對實現中的信息編碼，否則從模型到代碼全丟失這些信息。逆向工程需要工具支持和人的干煩：把正向代碼生成和逆向工程這兩種方式結合起來就町以產生雙向工程。這意味着既能在圖形視圖下工作，又能在文字視圖下工作，這需要用工具來保持二者的一致性。
UML不限於對軟件建摸。事實上，它的表達能力對非軟件系統連摸也是足夠的。例如，立法系統的工作流程，病人保健系統的結構和行為以及硬件設計等。
要學習UML，一個有效的出發點是形成下述語言的概念模型，這要求學習三個要素：（Brian Kernighan和Dennis Ritchie是編程語言c的作者，他們指出學習一門新的編程語言的唯一方法是用它編寫程序，學習UML也是如此，學習UML的唯一方法是用它繪制模型）
u UML的基本構造塊：
事物是對模型中最具有代表性的成分的抽象，關系把事物結合在一起，圖聚集了相關的事物。
1. 事物
ü 結構事物（structrual thing）
它們通常是模型的靜態部分，描述概念或物理元素，共有7種結構事物。這7種元素，即類．接口、協作、用況、主動類、構件和節點，是UML模型中可以包含的基本結構事物，它們也有變體，如參與者、信號、實用程序(一種類)、進程和線程(兩種主動類)、應用、文檔、文件、庫、頁和表(一種構件)等。
² 類（class）
² 接口（interface）
² 協作(collaboration)
² 用況（或成為用例 use-case）
² 主動類（active class）
是這樣的類，其對象至少擁有一個進程或線程，因此它能夠啟動控制活動。主動類的對象所描述的元素的行為與其他元素的行為並發，除了這一點之外，它和類是一樣的-在圖形上，主動類很像類，只是它的外框是粗線，通常它包含名稱．屬性和操作。
² 構件（component）
構件和節點是物理事物，前面五種是描述概念和邏輯事物。構件是系統中物理的、可替代的部件，它遵循且提供一組接口的實現。在一個系統中，你將遇到不同類型的部署構件,如COM+、構件和JavaBeans，以及在開發過程中所產生的制品構件，如源代碼文件。通常構件是一個描述了一些邏輯元素(如類、接口和協作)的物理包。在圖形上，把一個構件畫成一個帶有小方框的距形，通常在矩形中只寫該構件的名稱。
² 節點（node）
節點是在運行時存在的物理元素，它表示一種可計算的資源，它通常至少有一些記憶能力和處理能力。一個構件集可以駐留在一個節點內，也可以從一個節點遷移到另一個節點。在圖形上，把一個節點畫成一個立方體，通常在立方體中只寫它的名稱。
ü 行為事物（behavioral thing）
行為事物是UML模型的動態部分。它們是模型中的動詞，描述了跨越時間和空間的行為，共有兩類主要的行為事物：
² 交互（interaction）
它由在特定語境中共同完成一定任務的一組對象之間交換的消息組成，一個對象群體的行為或單個操作的行為可以用一個交互來描述。交互涉及一些其他元素，包括消息、動作序列(由一個消息所引起行為)和鏈(對象間的連接)。
² 狀態機（status mechine）
它描述了一個對象或一個交互在生命期內響應事件所經歷的狀態序列。單個類或一組類之間動作的行為可以用狀態機來描述，一個狀態機涉及到一些其他元素，包括狀態、轉換（從一個狀態到另一個狀態的流）和事件(觸發轉換的事物和活動(對一個轉換的響應)，在圖形上把一個狀態畫成—個圓角矩形。通常在圓角矩形中含有狀態的名稱及其子狀態。
ü 分組事物（grouping thing）
分組事物是UML模型的組織部分。它們是一些由模型分解成的“盒子”。在所有的分組事物中，最主要的分組事物是包。包(package)是把元素組織成組的機制，這種機制具有多種用途。結構事物、行為事物甚至其他的分組事物都可以放進包內。包不像構件(僅在遠行時存在)，它純粹是概念上的，即它僅在開發時存在。在圖形上，把一個包畫成一個左上角帶有一個小矩形的大矩形，在矩形中通常僅含有包的名稱，有時還有內容。包是用來組織UML模型的基本分組事物：它也有變體，如框架．模型和子系統等(它們是包的不同種類)。
ü 注釋事物（annotation thing）
是UM模型的解釋部分，這些注釋事物用來描述．說明和標注模型的任何元素。有一種主要的注釋事物，稱為注解，注解(note)是一個依附於一個元素或一組元素之上、對它進行約束或解釋的簡單符號、在圖形上，把一個注解畫成一個右上角是折角的矩形，其中帶有文字或圖形解釋。
2. 關系
ü 依賴（dependency）
是兩個事物間的語義關系，其中一個事物(獨立事物)發生變化時會影響另一個事物(依賴事物)的語義。變體有精化、跟蹤、包含和延伸。
ü 關聯（association）
是一種結構關系．它描述了一組鏈。鏈是對象之間的連接。聚合是一種特殊類型的關聯．它描述了整體和部分間的結構關系。在圖形上，把一個關聯畫成一條實線，它可能有方向，偶爾在其上還有—個標記，而且它經常還含有諸如多重性和角色名這樣的修飾。
ü 泛化（generalization）
它是特殊／一般關系，特殊元素（子元素）的對象可替代一般元素（父元素)的對象，用這種方法子元素共享父元素的結構和行為。
指向父元素
ü 實現（raalization）
它是類元之間的語義關系，其中的一個類元指定了由另一個類元保證執行的契約。在兩種地方要遇到實現關系：一種是在按口和實現它們的類或構件之間；另一種是在用況和實現它們的協作之間。
3. 圖（diagram）：UML包括9種圖
ü 類圖（class diagram）
類圖表現了一組對象、接口、協作和它們之間的關系。在對面向對象系統的建模中所建立的最常見的圖就是類圖。類圖給出系統的靜態設計視圖，包含主動類的類圖給出系統的靜態進程視圖。
ü 對象圖（object diagram）
對象圖展觀了一組對象以及它們之間的關系。對象圖描述了在類圖中所建立的事物的實例的靜態快照。和類圖一樣，這些圖給出系統的靜態設計視圖或靜態進程視圖，但它們是從真實的或原型案例的角度建立的。
ü 用況圖（use case diagram）
用況圖展現了一組用況、參與昔(一種特定的類及其它們之間的關
系，用況圖給出系統的靜態用況視圖。這些圖對於系統的行為進行組織和建模是非常重要的。
ü 順序圖（sequence diagram）
ü 協作圖（collaboration diagram）
順序圖和協作圖都是交互圖。交互圖(interaction diagram)展現了一種交互。它由一組對象和它們之間的關系組成，包括在它們之間可能發送的消息。交互圖專注於系統的動態視圖。順序圖是一種強調消息的時間順序的交互圖；協作圖也是一種交互圖，它強凋收發消息的對象的結構組織。順序圖和協作圖是同構的，這意崍着它們是可以相互轉換的。
ü 狀態圖（statechart diagram）
狀態圖體現了一個狀態機，它由狀態、轉換、事件和活動組成。狀態圖專注於系統的動態視圖，它對於接口、類或協作的行為建模尤為重要，而且它強調對象行為的事件順序，這非常有助於對反應式系統建模。
ü 活動圖（activity diagram）
活動圖是一種特殊的狀態圖，它展現了在系統內從一個活動到另一個活動的過程。活動圖專注於系統的動態視圖、它對於系統的功能建模特別重要，並強調對象間的控制流程。
ü 構件圖(component diagram)
構件圖展現了一組構件之間的組織和依賴，構件圖專注於系統的靜態實現視圖。它與類圖相關，通常吧構件映射成一個或多個類。
ü 實施圖（或部署圖 deployment diagram）
實施圖展現了對運行時處理節點以及其中的構件的配置。實施圖給出了體系結構的靜態實施視圖。它與構件圖相關，通常一個節點包含一個或多個構件。
u 支配這些構造塊如何放置在一起的規則
一個結構良好的摸型在語義上是前后一致的，並且與所有的相關模型協調一致，UML有用於描述如下事物的語義規則：
1. 命名為事物、關系和圖起名
2. 范圍給一個名稱以特定含義的語境
3. 可見性怎樣讓其他人使用或看見名稱
4. 完整性事物如何正確一致地相互聯系
5. 執行運行或模擬動態模型的含義是什么
在軟件密集型系統的開發期間所建造的模型往往需要發展變化的方式、在不同的時間進行觀察。由於這個原因，下述的情況是常見的，一些結構良好的模型，也要建造一些這樣的模型：
1. 省略隱藏某些元素以簡化視圖
2. 不完全性可以遺漏某些的元素
3. 不一致性不保證模型的完整性
隨着系統細節的展開和變動，不可麿免地要出現這些不太規范的模型。UML的規則鼓勵(不是強迫)你專注於最重要的分析、設計和實現問題，這些問題將促使模型隨着時間的推移而具有良好的結構。
u 運用於整個語言的一些公共機制。
由於在UML中有4種貫穿整個語言且一致應用的公共機置使得UML變得較為簡單，這4種機制是：
1. 規格況明
UML不只是一種圖形語言，實際上，在它的圖形表示法的每部分背后都有一十規格說明．這個規格說明礎供了對構造塊的語法和語義的文字敘述；例如，在一個類的圖符背后就有一個規格說明：它提供了類所擁有的屬性，操作(包括完整的特征標記)和行為的全面描述。在視覺上，類的圖符可能展示了這個規格說明的一小部分。此外，可能存在着該類的另一個視圖，其中提供了一個完全不同的部件集台，但是它仍然與該類的基本規格說明相一致。UML的圖形表示法用來對系統進行可視化，UML的規格說明用來描述系統的細節，假定把二芒分開，就可能進行增量式的建模。還可以通過以下方式完成：先畫圖，然后對這個模型的規格說明增加語義，或直接創建規格說明，也可能對一個已經存在的系統近行逆向工程，然后再創建作為這些規格說明的投影圖。
2. 修飾
3. 通用划分
第一種方法是對類和對象的划分:UML的每一個構造塊幾乎都存在像類
與對象這樣的二分法，例如，可以有用況和用況實例，構件和構件實例，
節點和節點實例。在圖形上，UML剛與類同樣的圖形符號來表示對象，只是簡單地在對象名的下邊畫一道線，以示與類的區別。
——>三個不同的Customer對象
第二種方法是接口和實現的分離。接口聲明了一個契約，而實現則表示對該契約的具體實施，正負責如實地實現接口的完整語義，UML中，可以既對接口又對它們的實現建摸。幾乎每一個UML的構造塊都有象接口和實現這樣的二分法。例如，用況和實現它們的協作，操作和實現它們的方法。
實現接口Iunknown和Ispelling
4. 擴展機制
UML提供了一種繪制軟件藍圖的標准語言，但是一種閉合的語言即使表達能力再豐富，也難以表示出各種領域中的各種模型在不同時刻所有可能的細微差別，由亍這個原因．UML是可擴展的，可以以受控的方式擴展該語言，UML的擴展機制包括：
ü 構造型（stereotype）
構造型擴展了UML的向匯，它允許你創造新的構造塊，這個新構造塊既可從現有的構造塊派生，又專門針對你要解決的問題。
Overflow異常類
ü 標記值（tagged value）
標記值擴展了uML構造塊的特性．允許你創建上述元素的顆新信息。見上圖的EventQuene類中的vertion＝3.2 author＝egt。
ü 約束（constraint）
約束擴展了UML構造塊的語義，它允許增加新的壩則或修改現有的覘則。如上圖的給方法add()增加的約束（ordered）。
三、體系結構和開發生命周期
軟件體系結構不僅關心結構和行為，而且還關心用法、功能、性能、彈性、復用、可理解性、經濟技木約束及其折衷，以及審美的考慮。最終用戶、分析人員、開發人員、系統集成人員、測試人員、技術資料作者和項目管理者——他們各自帶着項目的不同日程，而且在項目的生命周期內各自在不同的時間、以不同的角度來看系統。所以要開發不同的系統視圖。
u 系統的用況視圖（use case diagram）
由專門描述可被最終用戶、分析人員和測試人員看到的系統行為的用況組成。用況視圖實際上沒有描述軟件系統的組織，而是描述了形成系統體系結構的動力。在UML中，該視圖的靜態方面由用況圖表現，動態方面由交互圖、狀態圖和活動圖表現。
u 系統的設計視圖（design diagram）
u 系統的進程視圖（process diagram）
u 系統的實現視圖（implementation diagram）
u 系統的實施視圖（deployment diagram）
體系結構是—組有關下述內容的重要決策：
u 軟件系統的組織
u 對組成系統的結構元索及其接口的選擇
u 如元素間的協作中所描述的那樣的行為
u 將這些結構和行為元素組合到逐步增大的子系統
u 指導這種組織的體系結構風格：靜態和動態元素及其他們的接口
5種視圖中的每一種視圖都可單獨使用，使不同的人員能專注十他們最為關心的體系結構問題。這5種視圖也可相互作用，如實施視圖中的節點擁有實現視圖的構件，而這些構件又表示了設計視圖和進程視圖中的類、接口、協作以及主動類的物理實現。UML允許表達這5種視圖中的任何一種視圖，也允許表達它們之間的交互。
UML在很大程度上是獨立於過程的，這意味着它不依賴於任何特殊的軟件開發生命周期，然而，為了從UML中得到最大的收益，應該考慮這樣的過程：
u 用況驅動的（use case driven）
u 以體系結構為中心的（architecture centric）
u 迭代的和增量的（iterative and incremental）
初始inception、細化elaboration、構造construct、移交transition等四個部分迭代。
四、用UML繪制模型圖，詳細描述各個構造塊及其組合應用
<一>類class
對系統建模涉及到識別出對於你的特定視圖來說是重要的事物，這些事物形成了正在建模的系統的詞匯表。例如：如果正在建造一所房子，那么像牆、門、窗戶、櫃廚和燈對於房主來說就是重要的事物。在UML中，所有的這些事物都被建摸為類，一個類是對作為詞匯表一部分的一些事物的抽象。類不是個體對象，而是描述一群對象的一個完整集合。它是一組具有相同屬性、操作、關系和語義的對象的描述。
類名有簡單名與路徑名兩種，見上圖，一般第一個字母大寫，屬性名和操作名一般除了第一個單詞的第一個字母不大寫，其他單詞的首個字母大寫，如localAddress、displayResult（）。一個類可以有多個屬性也可以沒有屬性，操作也是如此。屬性還可以表明的類型以及初始值，以及只讀、共享等特性。操作的特征標記可以標識參數名稱、類型、缺省值以及返回類型。
當畫一個類時，不必馬上把每個屬性和操作部顯示出來。事實上，在大多數情況下不能這樣做(有太多的屬性和操作以至於不能把它們放在一張圖中，也可能不應該這樣做，可能只有一些些屬性和操作的一個子集與特定的視圖相關。由於這些原因，可以對一個類進行省略，這意味着可以有選擇地僅顯示類的一些屬性和操作，甚至也可以不顯示任何屬性和操作。空欄並不一定意味着沒有屬性或操作，只是沒有選樣要顯示它們。通過在列表的末尾使用省略號(“…”)，可以明確地表示出實際的屬性和操作比所顯示的要多。為了更好地組織屬性和操作的長列表，可以利用構造型在每一組屬性和操作之前加一個描述其種類的前綴。
職責是類的契約或責任（功能），它是構造型的一個例子。在圖形上，把職責列在類圖符底部的分隔的欄中，如下圖。責職是自由形式的文本，實際上，可以把類的職責寫成一個短語，一個句子或一段短文。屬性、操作和職責是創建抽象聽需要的最常見的特征，事實上，對於大多數要建造的模型，這3種特征的基本形式足以傳達類的最重要的語義。然而，有時需要可視化或詳述其他特征，例如，（對個體的屬性和操作進行可視化，對與特定語言相關的操作特性(如多態性或一致性進行可視化，甚至對類的對象可能產生或操縱的異常事件進行可視化)在UML中能夠表達這些特征以及很多其他特征，但它們被作為高級概念處理。因為有些類是經常出現的，這些抑類的炎是很常見的，並且它們招述了重要的體系結構抽象，所以UML提供了主動類（表示進程和線程）、構件(表爾物理軟件構件)和節點(表示硬件代備等)。最后說明的是類很少單獨存在。確切地講當建造模型時，通常要注重於相互作用的那些類群，—般在UML中，這些類的街體形成了協作，它們常在類圖中被可視化。
為了對系統的詞匯建模．需做如下工作：
u 識別用戶或實現者用於描述問題或解決問題的那些事物，用CRC卡(class-responsibility-)和基於用況分析的技術幫助用戶發現這些抽象；
u 對於每個抽象，識別一個職責集。確信要清楚地定義每個類，而且這些職責要在所有的類之間很好地均衡；
u 提供力實現每個類的職責所需的屬性和操作。
一旦開始對大量的類建模，就要保證你的抽象提供了一個均衡的職責集。這意味着不能讓任何類過大或過小，每一個類應該做好一件事。若抽象出來的類過大，你會發現模型堆以變化且很不容易復用：若抽象出來的類過小，則最后抽象會過多，難以合理地管理和理解。可以使用UML來幫助你可視化和詳述這種職責的均衡。
為了對系統中的職責分布進行建模，要做如下工作：
u 識別一組為了完成某些行為而緊密地協同工作的類；
u 對上述的每一個類識別出一組職責；
u 整體上觀察這些類，把職責過多的類分解成輕小的抽象，把職責過於瑣碎的小類組合成一個大的類，重新分配職責以使每一個抽象合理地存在。
u 考慮這些類的相互協作方式，相應地重新分配它們的職責，以使得協作中沒有哪個類的職責過多或過少。
對非軟件事物建模，應該：
u 對被抽象為類的事物建模．
u 如果要將這些非軟件事物與UML已定義的構造型相區別，就要創建一個新的構造型，並用這個構造型詳述這些新語義，並給出明確的可視化提示。
u 如果破建模的事物是某種本身包合軟件的硬件，考慮把它建模力一種節點，以便能進一步擴充它的結構。
UML主要用於對軟件密集型系統建模，但將它與文本型硬件建模語言(如VHDL)相結合，對硬件系統建模也很有表達力。系統外部的事物通常被描述為參與者。
對簡單類型進行建模，應該：
u 對被抽象為類型或枚舉的事物建模，這可以用帶有適當構造型的類表示符來表示；
u 若需要詳述與該類型相聯系的值域，可以使用約束。
用約束顯示值域，用屬性顯示枚舉值
提示與技巧：
在UML中對類建模時要記住：對最終用戶或實現者來說，各個類都應該映射到某個真實或概念性的抽象：一個結構良好的類，要遵循如下的策略：
u 為取自問題域或解城的詞匯中的事物提供明確的抽象。
u 嵌入一個小的、明確定義的職責集，並且能很奸地實現它們。
u 把抽象的規格說明和它的實現清楚地分開。
u 簡單而且可理解，並具有可適應性和可擴展性。
當用UML繪制一個類時，要遵循如下的策略：
u 僅顯示在該類的語境中對於理解抽象較為重要的類的特性。
u 通過按種類對屬性和操作的長列表分組，來進行組織。
u 把相關的類顯示在相同的類圖中。
類元(classfier)是描述結構特征和行為特征的機制。類元包括類、接口、數據類型、信號構件、節點、用況和子系統。UML中的一些事物沒有實例，例如包和泛化關系就沒有實例。一般而言，有實例的建模元素被稱為類元(關聯和消息有實例，但與類的實例不完全一樣)。更重要的是類元有結構特征(以屬性的形式)和行為特征(以操作的形式)。一個給定的類
元的每個實例共享相同的特征。
屬性的可見性：
<二>關系relation
在UML中，事物之間相互聯系的方式．無淪是邏輯上的還是物理上的，都被建模為關系，在面向對象的建模中，有三種景重要的關系：依賴、泛化和關聯都是定義在類這一級的靜態事物。在UML中，通常在類圖中對這些關系進行可視化。還有其他兩種關系：鏈（它是關聯的實例，描述可能發送消息的對象間的連接）和轉換 (它是狀態機中不同狀態間的連接)。
u 依賴（包括精化、跟蹤和綁定）：類之間的使用關系。箭頭指向被依賴的事物。依賴可
以帶有一個名稱，但很少使用，除非模型有很多依賴，並且要引用它們或作出區別，在一般情況下，用構造型區別依賴的不同含義。
u 泛化：父子繼承關系。通常（但不總是）子類除了具有父類的屬性和操作外，還具有別
的屬性和操作，若子類的操作與父類的操作的特征標記相同，則它重載父類的操
作，這稱為多態性。一個類可以有0個、1個或多個父類。把沒有父類且最少有
一個子類的類稱為根類或基類，把沒有子類的類稱為葉子類。可以說只有一個父
類的類使用了單繼承，也可以說有多個父類的類使用了多繼承。泛化很少有名稱，
但很少使用。除非模型有很多泛化，而且要引用它們或要加以區別，才需要使用
泛化的名稱。
不想讓它有任何對象的非葉子類，通常把這樣的類稱為抽象類(abstract class)。在UML中，通常把抽象類名寫為斜體，以指明這個類是抽象的，如上圖中類Security就是如此。這種規定也適用於操作，如presentValue（），這意味着這樣的操作提供了一種特征標記，但它是不完全的，因此必須在較低的抽象層次用一定的方法實現。
u 關聯：實例之間的結構關系。給定一個連接兩個類的關聯，可以從一個類的對象導航到
另一個類的對象，反之亦然。關聯的兩端都連到同一個類是合法的。這意味着，從一個類的給定對象能連接到該類的其他對象。恰好連接兩個類的關聯叫做二元關聯。盡管不普遍，但可以有連接多於兩個類的關聯，這種關聯叫做n元關聯。
依賴是使用關系．泛化是“is a kind of”關系，它們都是單向的，而關聯描述了類的對象間相互作用的結構路徑，關聯在缺省的情況下是雙向的，但也可以限制它們的方向。
關聯有四個修飾：
名稱：關聯可以有一個名稱，用以描述該關系的性質。為了消除名稱含義的歧義，可提供一個指引讀名稱方向的三角形，給名稱一個方向。雖然是聯可以有名稱，但通常不需要給出名稱。當要明確地給關聯提供角色名時，
或當一個模型有很多關聯，且需要對這些關聯進行查閱或區別時，則要給出關聯的名稱。特別是在有多個關聯連接相同類的情況下，更要給出關聯的名稱。
角色：當一個類處於關聯的某一端時，該類就在這個關系中扮演了一個特定的角色。角色是關聯中靠近它的一端的類對另外一端的類呈現的職責。可以顯式地命名類在關聯中所扮演的角色。相同類可以在其他的關聯中扮演相同或不同的角色。
多重性：關聯表示了對象間的結構關系，在很多連接問題中，指明一個關聯的實例中有多少個相互連接的對象是很重要的，這個“多少”被稱為關聯角色的多重性，把它寫成一個表示取值范圍的表達式或寫成一個具體值。就是說明：在關聯另一端的類的每個對象要求在本端的類必須有多少個對象，可以精確地表示多重性為1(1)、0或1(0．．1)、很多（0…*）、1個或很多(1…*)，甚至可以精確地指定多重性為一個數值如（3）。還可以使用象(0．．1．．3．．4．6．．*)這樣的列表來描述更為復雜的多重性，該例的含義是“除了2或5外的任意數目的對象”。關聯的實例叫做鏈。
聚合：兩個類之間的簡單關聯表示了兩個同等地位類之間的結構關系，這意味着這兩個類在慨念上是同級別的，一個類並不比另一個類更重要。有時要對一個“整體／部分”關系建摸，其中一個類描述了一個較大的事物(“整體”)，它由較小的事物(”部分”)組成，把這種關系稱為聚合。它描述了“has a”的關系，意思是整體對象擁有部分對象。其實聚合是一種特殊的關聯，它被表示為在整體的一端用一個空心菱形修飾的簡單關聯。
Department 和School之間的關系為組合聚合關系。表明一個或多個系只能屬於一個學校。
提示與技巧：
在UML中對關系建模時，要遵循如下策略：
僅當被建摸的關系不是結構關系時，才使用依賴；
僅當關系是“is a kind of”的關系時，才使用泛化；
小心不要引入循環的泛化關系；
往往可以用聚合代替多繼承；
一般要保持泛化關系的平衡，繼承的層次不道太深，大約多於5層就應該想一想。太寬(代之以尋找可能的中間抽象類)
在對象間有結構關系的地方，要以使用關聯為主。
在UML中繪制關系時，要遵循如下策略：
要一致地使用直線或斜線，直線給出的可視化提示強固了相關事物之間的連接都集中到一個共同爭物。在復雜的圖中斜線則經常有更好的空間效果。在同一個圖甲使用兩種線形有助於把人們的注意力引導到不同的關系組。
避免線段文又；
僅顯示對理解特定的成組事物必不可少的關系，應該省略多余的關系，特別是多余的關聯。
<三>公共規范
u 注解（note）是附加在元素或元素集上用來表示約束或解釋的圖形符號，在圖形上，把注解畫成帶有摺角的矩形，在矩形中填寫文字或圖形注釋。表示注釋的注解對模型沒有什么語義影響，這意味着它的內容不會改變它所依附的模型的含義，這是為什么用注解描述像需求、觀察資料、評論和解釋之類事物的原因，也是用注解表示約束的原因。
u 構造型（stereotype)是UML的詞匯的擴展，允許創建與已有的構造塊相加而針對特定問題的新種類的構造塊。在圖形上，把構造型表示成用書名號括起來的名稱，並把它畫在其他的元素名之上。作為一種選擇，可以用一種與構造型相聯系的新圖形表示被構造形化的元素。新構造塊有自己的具體特性（各構造型可以提供自己的標記值集）、語義(各構造型可以提供目己的約束)和表示法(各構造型可以提供自己的圖標)。
u 標記值（tagged value）是對UML元素的特性的擴展，允許在元素的規格說明中創建新的信息。在圖形上，把標記值表示成用花括號括起來的字符串，並把它放在其他的元素名之下。最簡單的形式是把標記值表示成一個由括號括起來的串，並放在另一個元素的名稱之下，這個串包括一個名稱(標記)、一個分隔符(=)和一個（標記的）值。
u 約束(constraint)是對UML元素的語義的擴展，允許增加新的規則或修改已有的規則，在圖形上，把約束表示成用大括號括起來的字符串，並把它J真在關聯的元素跗近，或者通過依賴關系連接到這個（或這些元素）。作為一種選擇，可以在注解中表示約束。可以把約束寫咸自由形式的文本。若要更精確地詳細語義，可以使用UML的對象約束語言(OCL)。如下圖：
u 修飾: 大多數修飾是通過在感興趣的元素附近放—些文字或對基本表示法增加圖形符號表示的。然而，有時要用比簡單文本或圖形符號更能提供細節的事物來修飾元素，諸如類、構件和節點這佯的事物，可以在它們通常的分隔欄的底部增加分隔欄，以填寫這種信息。除非分隔攔的內容很明顯，否則最好對任何分隔欄都顯式地命名，以避免含義混淆。此外還建議盡量少使用分隔欄、因為若過度地使用，會造成圖形混亂。
要對注釋建模，要遵循如下策略：
u 把注釋文本放人注解內，並把該注解放於它所對應的元素附近。可以用依賴關系把注解與對應的元素相連接，以更明確地表明關系。
u 要記住，可以按需要隱藏或顯示模型中的元素。這意味着不必到處顯示可視化的元素上
的注釋，而只有在語境中需要交流這種信息時才顯示圖中的注釋。
u 如果注釋冗長或者包含比純文本更復雜的事物，可考慮把注釋放在外部的文檔中，並把文檔連接或嵌入到依附於模型的相應注解中。
u 當建模演化時，保持那些有意義的記錄結果，並且這些結果不能從模型本身導出，無保留價值的注釋。
當繪制構造型、標記值或約束時，要遵循如下策略：
u 要確認用基本的UML無法表達你要做的事情，如果是常見的建模問題，可能已存在一些標准的構造塊、標記值或約束可滿足你的需要，如果確信沒有已經存在的方法能表達這些語義，才創造新的構造型、標記值或者約束。
u 要少用圖形構造型，你可以用構造型完全改變UML的基本表示法，但這樣做可能會使其他任何人都不理解你的模型；
u 對圖形構造型，可以考慮使用簡單的顏色或陰影，也可使用較復雜的圖標，簡單的表示法一般來說是最好的，即使是最單薄的可視化提示對於理解其含義也大有幫助。
<四>圖diagram
圖是觀察類、接口、構件等基本構造塊的方式。圖是一組元素的圖形表示，經常把大多數圖表示成頂點(事物)和弧（關系）的連通圖。用來從不同的角度對系統進行可視化，因為沒有哪個復雜的系統能僅從一個角度理解其全局，所以UML定義多種圖，使你能分別獨立地注重於系統的不同方面。優秀的圖使得正在開發的系統易於理解和處理，選樣一組正確的圖來對系統進行建模，能促使你對系統提出正確的問題，並有助於表明決策的含義。
在軟件方面，對軟件體手結構進行可視化、詳述、構造和文檔化，有5種最重要的互補視圖：用況視圖、沒計視圖、進程視圖、實現視圖和實施視圖，每一種視圖都包含結構建模(對靜態事物建模)和行為建模（對動態事物建模）。當用UML從任一角度觀察軟件系統時，要用圖去組織感興趣的元素。UML定義了9種圖，可以混合和組配它們來匯集成各種視圖-例如，系統的實現視圖的靜態方面可以用構件圖可視化；同一個實現視圖的動態方面可以用交互圖可視化。類似地，系統數據庫的靜態方面可以用類圖可視化；動態方面可以用協作圖可視化。當然，你可以不限於這9種圖，在UML中，定義這9種圖是因為它們表示了被觀察元素的最常見的組合。為了適應項目或組織的需要，可以創建你自己所需種類的圖，從而以不同的方式對UML元素進行觀察。
靜態圖：類圖、對象圖、構件、實施圖
動態圖：用況圖、順序圖、協作圖、狀態圖、活動圖
*******************************************************************************
在實踐中創建的所有圖都是兩維的，這意味着它們都是繪制在紙上、白板上、信封的背面或計算機顯示器上的，節點和弧的平面圖。UML允許創建三維圖，即有深度的三維圖，允許在模型中“漫游”，一些虛擬現實研完組己顯示了這種UML的高級用法。UML許創建動態圖，並且允許使用顏色和其他的可視提示去“運行”圖，一些工具已經展示UML的這種高級的用法。
系統、子系統、模型、視圖、圖的概念（要仔細品味區別）：系統(system)是一個為完成一定的目的而被組織起來的子系統的集合，這些子系統由一組可能來自不同觀點的模型描述；子系統(subsystem)是一組元素的組合，其中的一些元素構成了其他被包含的元素所提供的行為規格說明；模型(model)是系統的語義閉合的佃象，這意味着它表示對現實的簡化，這種簡化既是完整的又是自相容的，這是力更好地理解系統而建立的。在體系結構的語境中；視圖(view)是對系統模型的組織和結構的投影，注重於系統的一個方面。圖{diagram}是一組元素的圖形表示，通常表示成由頂點(事物)和弧(關系)組成的連通圖。
l 構建類圖
類圖顯示了一組類、接口、協作以及它們之間的關系，是面向對象系統建模中最常見也最重要的一種圖，是構件圖和實施圖的基礎，它對系統的靜態設計進行建模，大部分涉及系統的詞匯建模、協作建模和模式建模。類圖不僅對結構模型的可視化、詳述和文檔化很重要，而且對通過正向與逆問工程構造可執行的系統也很重要。
類圖一般包含：
ü 類
ü 接口
ü 協作
ü 依賴、泛化和關聯等關系
ü 包
ü 子系統
ü 有時還有實例
設計視圖主要在三個方面使用類圖：
對系統的詞匯建模
對簡單的協作建模
對邏輯數據庫的模式建模
使用UML的某些功能，所創建的模型將永遠不會映射成代碼：刨如，若用活動圖對業務過程建模，則很多被建模的活動要涉及列人員而下是汁算機，另一種情況是你所建模的系統的組成部份在你的抽象層次上只是一些硬件(雖然在另一個抽象層次上看，也可以說該硬件包含了嵌入的計算機的軟件)
在大多數情況下，要把所創建的模型映射成代碼。UML沒有指定對任何面向對象編程語言的映射，但UML還是考慮了映射間題。特別是對類圖，可以把類圖的內容清楚地映射到各種工業化的面向對象的語言，如Java．C＋＋，Smalltalk，Effile，Ada，ObiectPascal和Forter。UML也可以被設計得可映射到各種商用的基於對象的語言，如VisicalBasic。
正向上程(forward engineering)是通過到實現語言的映射而把模型轉換為代碼的過程。由於用UML描述的模型在語義上比當前的任何面向對象編程語言都要豐富，所以正向工程將
導致一定信息的損失。事實上，這是為什么除了代碼之外還需要模型的主要原因，像協作這
樣的結構特征和交互這樣的行為特征，在UML中能被清晰地可視化，但源代碼就不會如此清晰。
逆向工程(reverse engineering)是通過從特定實現語言的映射而把代碼轉換為模型的過程。逆向工程會導致大量的多余信息，其中的一些信息屬於細節層次，對建造有用的模型來說過於詳細。同時，逆向工程是不完整的。由於在正向工程中產生的代碼丟失了一些信息，
所以，除非所使用的工具能對原先注釋中的信息(這超出了實現語言的語義)進行編碼，否則就不能再從代碼創建一個完整的模型。
對類圖進行正向工程，要遵循如下的策略：
u 識別映射到所選擇的實現語言的規則，這是你要為整個項目或組織做的事情。
根據所選擇語言的語義，可能要限定對一些UML特性的用法。例如，UML允許對多繼承建模，但smalltalk和JAVA都僅允許單繼承。可以選擇禁止開發人員用多繼承建模(這使得模型依賴於語言)，也可以選擇把這些豐富的特征轉化為實現語言的慣用方法(這樣使得映射更為復雜)。
u 用標記值詳述目標語言。如果需要精確的控制，可以在單個類的層次上做這些事情，也可以在較高的層次上(如協作或包)這樣做。
u 使用工具對模型進行正向工程。
對類圖進行逆向工程，要遵循如下的策略：
u 識別從實現語言或所選的語言進行映射的規則。這是你要為整個項目或組織做的事。
u 使用工具，指向要進行逆向工程的代碼，用工具生成新的模型或修改以前進行正向工程時已有的模型。
u 使用工具，通過查詢模型創建類圖。例如，可以從一個或幾個類開始，然后通過追蹤特定的關系或其他相鄰的類擴展類圖。根據表達你的意圖的需要，顯示或隱藏類的內容的細節。
為了由不同的視圖對系統建模，要遵循如下的策略：
u 決定你需要哪些視圖才能最好地表達系統的體系結構．並暴露項目的技術風險，上面描述的5種體系結構視圖是一個好的開始點。
u 對這樣的每種視圖，決定需要創建哪些制品來捕獲該視圖的基本細節，在大多數情況下，這些制品由各種UML圖組成。
u 作為你的過程策划的一部分，決定你將把哪些圖置於某種形式或半形式的控制之下。對這些圖要安排復審，並把它們作為項目的文檔保存。
u 允許保留廢棄的圖，這些臨時圖仍然有助於探究決策的意圖，也有助於用情況變化進行實驗。
可以對同一模型或不同的模型創建幾種圖，每種圖掩蓋或顯露不同的元素集，並顯示不同層次上的細節，即抽象層次，以達到不同的參與者之間交流目的（比如，程序員工作在較低的抽象層，而系統分析員和用戶工作在較高的抽象層）。
在不同的抽象層次對象統建模，要遵循如下的策略：
u 考慮讀者的需要，從給定的模型開始；
u 如果讀者要用這個模型構造實現，就需要較低抽象層次的圖，這意味着需要揭示許多細節；如他們用這個模型向最終用戶提供概念模型，就需要較高抽象層次的圖，這意味着需要隱藏許多細節。在不同的抽象層次的模型之間進行跟蹤依賴。
用況及其實現：用況模型中的用況要跟蹤到設計模型中的協作；
協作及其實現：協作要跟蹤到共同工作以完成協作的一組類；
構件及其設計：實現模型中的構件要跟蹤到設計模型中的元素；
節點及其構件：實施模型中的節點要跟蹤到實現模型中的構件；
u 根據你在這個從低到高的抽象層次譜系中所處的位置，通過隱藏或揭示模型中的如下4種事物，而在恰當的抽象層次上創建圖：
構造塊和關象：把與圖的內容無關的或讀者不需要的構造塊和關系隱藏起來；
修飾：僅僅顯示對於理解意圖是必要的構造塊和關系的修飾；
流：在行為圖的語境中，僅展開對於理解意圖是必要的那些消息或轉換。
構造型：在用於屬性和操作等單物的分類列表的構造型的語境中，僅顯示對於理解意圖是必要的那些構造塊的項。
參看下列兩個不同抽象級別的交互圖：
對於復雜視圖建摸．要遵循如下的策略：
u 首先要確定不存在任何沒有意義的方法，能用於在較高的抽害層次上表達這種信息，或許要省略一部分圖，並抑制其他部分的細節；
u 如果已經隱藏了能夠隱藏的細節，但圖仍然是復雜的，就考慮把一些元素組織到—些包或者層次較高的協作中，然后僅把這些包或協作畫在圖中；
u 如果圖仍然是夏雜的，就用注解和色彩作為可視化提示，以將用戶的注意力引導到你所強調的重點上
u 如果圖還是復雜的，把它全部打印出來，掛在適宜的大牆上。雖然喪失了聯機形式所帶來交互性，但能夠退后—步研究它的公共模式。