類圖可用來描述系統中各種對象的類型，也可描繪出對象間各種各樣的靜態關係。此外，類圖中也可以秀出類的性質（property）與操作（operation）,以及可應用到對象間連接方式的一些限制（constraint）。在UML中，我們用特性（feature）來代表累的性質與操作這兩種概念。
1、性質
性質代表類的結構特性（structural feature）。雖然只是一個概念，不過它卻可以用兩種非常不同的表示法來呈現：屬性與關聯。
2、屬性
屬性（attributes）表示法用類別四方形中的一行文字來表示性質。完整語法如下：
可見性 名稱 ： 類型 多重性 = 預設值 { 性質 - 字符串 }
如：
-name:string [1] = "Untitled"{ readonly }
在整個語法當中，只有【名稱】部分是必要的。
（1） 可見性標誌代表這個屬性是public、private或protect。
（2） 屬性的名稱大約等同於程序語言中的名稱 -它說明類如何參考這個屬性的。
（3） 屬性的類型代表一種限制條件，說明屬性中究竟可放入哪一種對象。
（4） 關於多重性（multiplicity），稍後再解釋它。
（5） 預設值（default value）說明在新產生的對象中，如果產生過程中沒有指定值給這個屬性，那麼我們就會把這個值指定給屬性。
（6）{性質 - 字符串}允許你指明這個屬性的一些額外性質。
3、關聯
性質的另一種表示法是關聯。屬性中可表示出來的信息，差不多也都可以再關聯中表示出來。
關聯用兩個類別中的實線來表示它，箭頭會有來源類指向目標類。性質的名稱會出現在關聯的目標端，同時還會加上它的多重性。關聯的目標端所連接的類就是這個性質的形態。![]()
一般來說，傾向於把屬性用在小的東西上，例如日期或布爾值等，而且他們通常都是值形態的東西。另一方面，我會把關聯用在有顯著意義的類上，例如客戶或訂單。同時，也傾向於用類四方形畫出圖種有顯著意義的類，這也會導致去用關聯；另一方面，我會把不重要的東西表示成屬性。做出這種選擇，目的主要是爲了要強調出重點。
4、多重性
性質的多重性代表它可能會有多少個對象存在。比較一般的說法是我們可以用一個上限與一個下限來定義多重性。屬性的預設多重性是【1】。雖然UML的超模型中有這條規則存在，不過如果圖中某個屬性沒有標識出多重屬性的話，我們不能因此就假設它的多重性爲【1】，因爲多重性信息可以隱藏起來。
5、雙向關聯
雙向關聯代表一對性質，它們從不同方向彼此連接在一起。如下圖：
Car類中有性質owner:Person[1],而Person類則有性質cars:Car[*]。
6、操作性
操作是類知道該如何達成的一些動作。很明顯地，操作就是類中的方法（method）。
在UML中，操作的完整語法爲：
可見性 名稱（參數列表） ： 返回類型 { 性質 -字符串 }
（1） 可見性是public、private或protect
（2） 名稱是一個字符串
（3） 參數列表是操作會用到的一串參數
（4）返回類型
（5）性質-字符串代表可應用到此操作的一些性質值。
參數列表中的參數是用跟屬性類似的方式來表示的。其語法如下：
方向性 名稱 ： 形態 = 預設值
（1） 名稱、形態與預設值跟屬性中的都一樣。
（2）方向性代表參數是用來輸入（in）、輸出（out）或輸出入（inout）用的。
評註：把會改變跟不會改變類中狀態的操作區分開來是非常有益的事。
UML中將query（查詢）定義成：只會從類中取出值、不會改變系統的狀態的操作。也就說，它不會產生副作用。你可以吧這種操作加上{query}性質字符串。還有，我自己喜歡將會改變狀態的操作加上modifiers（修改）性質字符。
操作指的是我們可呼出對象的某種東西-它代表程序宣告，而方法則是程序本體。這兩種東西在多型存在時，會有很大差異。例如：如果你有一個基類和三個子類，而每個子類都覆蓋基類的getPrice操作。這時候，我們就有一個操作，四個方法。
7、一般化關係
對一般化關係明顯解釋就是繼承（inheritance）。在主流的面嚮對象語言中，子類會繼承超類（superclass）的所有類特性，而且還可能會覆蓋任何超類的方法。
8、相依性
如果我們該某個元素的定義可能會影響到其他元素，那麼這兩個元素間就存在着相依性。對類來說相依性存在的原因有好幾個：某個類會傳送訊息給另一個類；某個類吧另一個類當成一部分資料；某個類把另一個類當成方法中的參數等。
如果系統不斷成長，你必須越來越擔心該任何去控制相依性。如果你沒辦法控制相依性的話，那麼我們系統所做的任何改變都會造成漣漪效應，讓越來越多東西跟着改變。
表1 本書精心挑選出來一些有用的相依性關鍵字：
| 關鍵字 | 意義 |
| call | 來源元素回去調用目標元素的某個操作 |
| create | 來源元素會產生目標元素的實例 |
| derive | 來源元素是由目標元素衍生出來的 |
| instantiate | 來源元素是目標元素的實例 |
| permit | 目標元素允許來源元素去存取目標元素中的私有特性。 |
| realize | 來源元素是目標元素中所定義規格或接口的實現 |
| refine | 修飾代表不同語義等級間的關係。 |
| substiute | 來源元素是可替代目標元素的 |
| trace | 我們用這個相依性來追蹤一些東西，例如從需求到類的相依性，或某個模型中的變動是如何練接到其他模型中變動的。 |
| use | 來源元素在實現時需要用到的目標元素 |
一般性原則是儘量降低相依性，特別是相依性會氾濫到系統的一大片區域時。還有一點要注意的是：我們應該小心避免循環式相依性，因爲它會導致循環性的變動。
9、限制規則
UML允許我們用任何東西來描述限制。唯一的規則是：請把限制放在大括號{}內。
有一種選擇性的做法是：替限制命名時，把名稱放在最前面，後面緊接着一個冒號，像這樣{不允許亂倫：夫妻雙方不能是兄弟姐妹}
10、何時使用類圖
類圖是UML的主幹，因此你可以發現隨時都得到它們。
類別圖的最大麻煩在於裏面包含太多東西了。所以它們可能會被過度使用。下面是一些使用上的提示：
A、不要試着用到所有可以使用的表示法。先簡單用本章所提及的一些東西：包括類別、關聯、屬性、一般化關係與限制等。至於高級的東西，只在你覺得有需要時再去用它們。
B、我發現到概念性的類圖在探索某個企業的領域語言時特別有用。想要這麼做時，你必須努力保持不去討論軟件本身，而且儘可能使用非常簡單的表示法。
C、不要畫出包含所有東西的模型。相反地，把重心放在關鍵地方。持有一些常用的到、時時更新的圖，比起持有很多被人遺忘掉、過時的圖還好。
使用類圖的最大危險在於你可能會過度把焦點放在結構上，而忽略系統中的行爲。