前言：

用例圖是九種圖中的第一個，因為用例圖是由軟件需求分析到最終實現的第一步，它描述人們希望如何使用一個系統。用例圖從用戶的角度而不是開發者的角度來描述對軟件產品的需求，分析產品所需的功能和動態行為。因此對整個軟件開發過程而言，用例圖是至關重要的，它的正確與否直接影響到用戶對最終產品的滿意程度。

首先當然是參與者，參與者是系統外部的一個實體（可以是任何的事物或者人），它以某種方式參與了用例的執行過程。參與者通過向系統輸入或請求系統輸入某些事件來觸發系統的執行。參與者由他們參與用例時所擔當的角色來表示。 其次就是用例了，用例是對一個系統或一個應用的一種單一的使用方式所作的描述，是關于單個活動者在與新系統對話中所執行的處理行為的陳述序列。 最后就是參與者和用例之間的關系了，參與者和用例之間的關系包括：關聯關系、泛化關系、包含關系和擴充關系。應用這些關系是為了抽取系統中的公共行為和變體。

1、 確定系統所涉及的內容： 首先我們應該對系統的總體信息有個大概的了解，知道系統都涉及到哪些工作內容。系統的總體信息確定之后，就可以確定系統的參與者、確定系統用例了。 2、 確定系統參與者： 確定參與者首先需要分析系統所涉及的問題領域和系統運行的主要任務：分析使用該系統主要功能的是哪些人，誰需要該系統的支持以完成其工作，還有系統的管理者與維護者。 3、 確定系統用例： 用例是系統參與者與系統在交互的過程中所需要完成的事務，識別用例最好的方法就是從分析系統的參與者開始，考慮每個參與者是如何使用系統的。由于系統存在的參與者數量不同，我們可以使用兩種方法來畫用例圖：一種是給不同的參與者單獨畫一個用例圖，這樣看起來比較簡潔；另一種方法是根據參與者之間的關系將系統的用例圖合為一張，但是這樣的用例圖在參與者過多時顯得太過復雜。所以我們在畫用例圖的時候應該視具體而定。 4、 使用UML工具來繪制用例圖。 我們可以使用Rational Rose或者EA來畫用例圖，并把參與者和用例之間的關系補充完整。

附一張機房收費系統的部分用例圖，個人觀點，歡迎大家指正：

后記：

要想過河，一定要從眼前的第一塊石頭搬起！