在uml的世界裡共有九種圖，分為兩類：靜态圖和動态圖，用例圖是靜态圖的一種。我們常聽到的一句話：業務為王。可見了解業務是何等重要。映射到我們軟體開發過程中，就是需求分析。也就是說，在軟體開發過程中，需求分析是最重要的，隻有需求做好了，你才可能設計出所謂的好軟體。如果需求都沒搞明白，那麼做出來的軟體，不管你的界面是多麼的炫，使用的技術是多麼的先進，那都是白扯。最終的結果就是，你的軟體是個廢物。而用例圖，就是幫助我們了解業務，确定需求的，它是需求分析階段使用的最重要的一種圖。它的重要性不言而喻，我認為uml九種圖中，用例圖處于霸主地位。然而，就是如此重要的一個圖，卻似乎沒有得到人們足夠的重視。也許有人會認為，用例圖随便畫畫，有那麼個意思就完了。殊不知你每天抱怨加班，抱怨客戶修改需求的原因，可能就是因為用例圖沒有畫好。是以呢，認真對待用例圖吧。
下面，就說一下用例圖中那些被部分人忽視和個人認為比較重要的一些東西。
首先，畫用例圖的過程，就是确定需求的過程。在确定參與者和用例的時候，有一個比較重要的概念——邊界，然而本人水準實在有限，難以給大家把這個比較抽象的概念解釋清楚，這裡隻是跟大家提一下，具體的了解還得靠大家自己去悟。下面我說一下用例。
用例分為：業務用例、概念用例、系統用例。通常咱們說的用例指的是系統用例，而由于這三種用例其實差别不是很大，這就導緻好多人忽視了業務用例和概念用例的存在，認為咱們常說的系統用例就是我們和客戶溝通時用的圖。其實不然，真正完成需求分析師與客戶溝通的用例是業務用例，業務用例中使用的一些名詞什麼的，幾乎全部來源與客戶的業務，隻有這樣才不至于客戶不了解我們的意思。概念用例則是需求分析師把業務用例精化、抽象成系統用例的過程中用到的一種用例。而我們大部分人看到的用例自然而然就是系統用例啦，換言之，系統用例就是給我們程式設計人員看的，是需求分析師辛辛苦苦得到的最終結果，它貌似與客戶已經木有多大關系了（這裡指客戶不接觸系統用例）。之是以好多人會讓系統用例去做本屬于業務用例的工作，就是因為這兩個家夥真的是太像了。而好多人又奉行一個原則：王八排隊——大概（蓋）齊，是以這種誤解也就比較容易了解啦，這裡我就不啰嗦啦。
然後呢，說說用例圖涉及到的幾種關系。
參與者與用例之間的關系：關聯關系，這個不必我多說，大家都懂。
用例與用例之間的關系：包含關系、擴充關系、實作關系。
包含關系：包含用例表示的是“必需”而不是“可選”，這意味着如果沒有包含用例，基本用例是不完整的，同時如果沒有基本用例，包含用例是不可能單獨存在的。給大家看看包含關系的執行個體：
ps：使用者要登入，就必須驗證使用者id，如果不驗證，使用者登入用例就不完整。
這裡再給大家介紹一下精化關系。先看圖：
ps：其實在系統用例中，并沒有精化關系或者說是有精化關系，但是精化關系完全等同于包含關系。那麼為什麼還要有精化這個概念呢？這就涉及到業務用例和概念用例了，需求分析是一個過程，精化關系就是在這個過程中使用的關系。可能在需求分析初期，客戶告訴你我需要使用者登入、使用者下線等等業務，而随着需求分析的深入，進一步細化使用者登入，得到了驗證使用者id等幾個用例。也就是說”使用者登入“這個業務用例精化出”驗證使用者id“等概念用例。等到所有的需求都明白了，需要定稿形成系統用例的時候，精化關系就被包含關系代替了。
擴充關系：擴充表示的”可選“，而不是”必需“，這意味着即使沒有擴充用例，基本用例也是完整的。如果沒有基本用例，擴充用例是不可能單獨存在的。如果有多個擴充用例，同一時間用例執行個體也隻能使用其中一個。看一個例子：
ps：查詢消費資訊時，可以導出excel，可以列印消費資訊，當然也可以隻看消費資訊。但是同一時間，你隻能導出excel或者列印消費資訊。
實作關系：這種關系比較簡單，大家看個例子就懂了。
到此為止，關于用例圖我就說完了，歡迎大家拍磚！