一、UML(Unified Modeling Language)統一建模語言。其結構如下
二、詳解（因為歷年軟考題主要出用例圖和類圖（多重度問題），所以本文主要回憶這兩個圖）
1、用例圖
解析：用例模型描述的是外部執行者所理解的系統功能。用例模型用於需求分析階段，它的建立是系統開發者和用戶反復討論的結果，表明了開發者和用戶對需求規格達成共識。
用例三要素：參與者（Actor）、用例（Use Case）、包含和擴展（Include and Extend）
在歷年的軟考下午題中都會考到用例圖，題型大部分為填用例或參與者，遇到這樣的問題只要是仔細讀題的都可以作對，還有一個考點就是填關系名稱。用例圖中的關系主要是包含和擴展。下面舉例說明什么是包含和擴展。
引用於《http://www.cnblogs.com/fan0136/archive/2008/12/14/1354730.html》
（1）包含(include)
包含關系：使用包含（Inclusion）用例來封裝一組跨越多個用例的相似動作（行為片斷），以便多個基（Base）用例復用。基用例控制與包含用例的關系，以及被包含用例的事件流是否會插入到基用例的事件流中。基用例可以依賴包含用例執行的結果，但是雙方都不能訪問對方的屬性。
包含關系對典型的應用就是復用，也就是定義中說的情景。但是有時當某用例的事件流過於復雜時，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個被包含的用例；相反，用例划分太細時，也可以抽象出一個基用例，來包含這些細顆粒的用例。這種情況類似於在過程設計語言中，將程序的某一段算法封裝成一個子過程，然后再從主程序中調用這一子過程。
例如：業務中，總是存在着維護某某信息的功能，如果將它作為一個用例，那新建、編輯以及修改都要在用例詳述中描述，過於復雜；如果分成新建用例、編輯用例和刪除用例，則划分太細。這時包含關系可以用來理清關系。
（2）擴展(extend)
擴展關系：將基用例中一段相對獨立並且可選的動作，用擴展（Extension）用例加以封裝，再讓它從基用例中聲明的擴展點（Extension Point）上進行擴展，從而使基用例行為更簡練和目標更集中。擴展用例為基用例添加新的行為。擴展用例可以訪問基用例的屬性，因此它能根據基用例中擴展點的當前狀態來判斷是否執行自己。但是擴展用例對基用例不可見。
對於一個擴展用例，可以在基用例上有幾個擴展點。
例如，系統中允許用戶對查詢的結果進行導出、打印。對於查詢而言，能不能導出、打印查詢都是一樣的，導出、打印是不可見的。導入、打印和查詢相對獨立，而且為查詢添加了新行為。因此可以采用擴展關系來描述：
用例圖做題中葯注意的幾點：
①正確識別參與者：角色不僅可以由人承擔，還可以是其它系統、硬件設備，甚至是時鍾。
②參與者一定在系統之外，不是系統的一部分。
2、類圖和對象圖
解析：所謂類是一類具有相同特征的對象的描述。對象是類的實例。類由類的名字、屬性、操作構成。分別分布在三格上中下的位置。
重點一：類之間的關系
①依賴關系（dependency）
有兩個元素X，Y，如果修改元素X的定義可能會引起對另一個元素Y的定義的修改，則稱元素Y依賴於元素X。用帶箭頭的虛線表示依賴關系
引起依賴的原因有一個類向另一個類發送消息；一個類是另一個類的數據成員；一個類是另一個類的某個操作參數等。
②泛化關系（Generalization）
泛化關系描述了一般事物與該事物中的特殊種類之間的關系，也就是父類與子類之間的關系。繼承關系是泛化關系的反關系，也就是說子類是從父類中繼承的，而父類則是子類的泛化。使用帶空心箭頭的實線表示，箭頭指向父類。
③關聯關系（association）
關聯表示兩個類之間存在某種語義上的聯系。例如，一個人為一家公司工作，一家公司有許多辦公室。那么人和公司、公司和辦公室之間存在某種語義關系。
關聯關系提供了通信的路徑，它是所有關系中最通用、語義最弱的。用一條實線來表示。
3.1聚合關系（aggregation）
聚合是一種特殊形式的關聯。聚合表示類之間的關系式整體與部分的關系。例如一個轎車包含4個車輪、一個方向盤、一個發動機和一個底盤，這就是聚合。用一個帶空心菱形的實線表示
3.2組合關系（composite）
如果聚合關系表示部分的類的存在，與表示整體的類有着緊密的關系，例如公司和部門之間的關系，那么就應該使用組合關系來表示。在UML中使用帶有實心菱形的實線表示
④實現關系（Implementation ）
實現關系式用來規定接口和實現接口的類或組件之間的關系。接口是操作的集合，這些操作作用於規定類或組件的服務、用帶有空心箭頭的虛線表示
重點二：多重度問題
最常見的多重性有：0..1 ; 0..* ; 1..1 ; 1..* ; *
多重性用來說明關聯的兩個類之間的數量關系，例如：
- 書與借書記錄之間的關系就應該是1對0..1的關系，也就是一本書可以有0或者1個借書記錄；
- 經理與員工之間的關系則應為1對0..*的關系，也就是一個經理可以領導0個或多個員工；
- 學生與選修課程之間的關系就可以表示為0..*對1..*的關系，也就是一個學生可以選擇1門或多門課程，而一門課程有0個或多個學生選擇。
軟考UML部分的基礎分析的部分就到這里，具體在做題的時候一定要認真審題，不要錯過任何信息，也不要自以為是，要以題干為基礎進行分析。在歷年的UML題型中，大部分會考到以下幾部分：
【問題一】（5分）根據說明中的描述，給出圖中A1和A2..An所對應的參與者,U1和U2..Un所對應的用例，以及（1）、（2)..(n)中所對應的關系。
仔細審題圈出能做出操作的參與者，根據具體題干進行填空。在題干中尋找動賓短句，根據題意填空。這幾分是很容易得到的，但是還是要細心，如果填反了一樣沒有分。
至於填關系的題，不是《include》就是《extend》，所以要分析題干，根據上文對包含和擴展關系的分析來填空。還有一個技巧就是如果箭頭萬眾歸一，指向大的用例，則一般都是擴展，如果是萬箭齊發，指向小的用例，則大部分都是包含。
【問題二】（7分）根據說明中的描述，給出圖中缺少的C1~Cn所對應的類名以及（3）~（n）處所對應的多重度。
本題找對應的類名不是難點，難點是容易弄反，所以還是要細心。難點還有多重度的分析，每次做模擬題都會錯一兩個，一個就是1分，這分好得也好丟，關鍵看題干分析，只要是認真細心的人就一定會分析正確，如果懶得思考的人就很難做對。考試的時候是現場直播，沒有演習，所以要付出百分百的腦力去分析它，啃透它消化它。
【問題三】（3分）圖中的類圖設計采用了某某設計模式，請說明該模式的內涵。
多么無恥的出題者啊，光是有設計模式的大題、上午題還是不過癮，還嵌在UML里一道題。23個設計模式雖然看類圖能回想起來設計模式的內涵但是就是有人無法用具體的語句來描述出來。這就是得靠總結，靠背。真煩！這也是UML題不能得滿分的原因。
總結這么多，還是一點，做UML題就是要心細、細心的分析。