我們的例子其實很簡單，它是一個ToDo（待辦事宜）表的維護工具，可以為用戶創建、刪除和管理ToDo信息。ToDo表的信息存貯在文件系統中。
OK,對于這樣一個需求，應該怎樣用UML來描述呢？
首先，我們需要識別系統的用戶和相關的外部系統，在UML中，它們被稱為Actor（角色）。識別Actor是很重要的，它可以幫助我們界定軟件系統的邊界，引導我們發掘用戶的需求，輔助我們設計用戶界面等等，是需求分析階段的第一步。對于我們這個簡單例子，有兩個Actor：ToDo User（系統的用戶） 和 FileSystem（相關外部系統）。
接下來，針對每個Actor，我們開始分析系統的Use Case。Use Case是一個UML中非常重要的概念，在使用UML的整個軟件開發過程中，Use Case處于一個中心地位。
那么，到底什么是Use Case呢？在UML的文檔中，Use Case的定義是：在不展現一個系統或子系統內部結構的情況下，對系統或子系統的某個連貫的功能單元的定義和描述。有點拗口，對吧？其實Use Case就是對系統功能的描述而已，不過一個Use Case描述的是整個系統功能的一部分，這一部分一定要是在邏輯上相對完整的功能流程。
（唔？Use Case也沒什么特別的嘛！怎么這玩意兒會在開發中處于一個中心地位呢？）在使用UML的開發過程中，需求是用Use Case來表達的，界面是在Use Case的輔助下設計的，很多類是根據Use Case來發現的，測試實例是根據Use Case來生成的，包括整個開發的管理和任務分配，也是依據Use Case來組織的。啊，Use Case，簡直太重要了！好了，Use Case就吹到這兒，具體的使用還要在實踐中去體會，“運用之妙，存乎一心”也！
對于每個Actor來說，他都要使用系統的某項功能，所以我們識別和分析Use Case是，要對于每個Actor來逐個進行。對于ToDo User，我們可以輕易的識別出兩個Use Case：Add Task 和 Remove Task。ToDo User主動使用這兩個Use Case所描述的系統功能，所以在我們的Use Case圖上，ToDo User和這兩個Use Case的關系是用從ToDo User發出的箭頭來表示的。對于FileSystem，我們識別出的也是同樣的兩個Use Case，不過這次箭頭從Use Case指向FileSystem，表示FileSystem是被動的。
Use Case可以用很多方式來描述，我們可以用自然語言（英語，漢語，隨您的便），可以用形式化語言（哇！太酷了吧�。�，也可以用各種圖示。在UML中，通常用兩種圖來描述Use Case，它們就是順序圖（Sequence Diagram）和協作圖（Collaboration Diagram）。
交互圖：順序圖和協作圖
從面向對象的角度來看，系統的功能是由一組對象通過相互發送消息來完成的，順序圖和協作圖就是通過描述這樣的對象和消息來描述系統的動態行為的。我們先用一個順序圖來描述Use Case AddTask。
AddTask的功能是向ToDo表中加入一個Task項，它的步驟應該是：
打開加入Task項的窗口；
輸入相應信息；
生成一個Task對象；
把這個Task加入到Task表中。
那么，我們的順序圖就可以畫成：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
