1. 基本概念
UML建模是以人為本的，沒有人就沒有接下來的故事。
參與者（actor）在建模的過程中是處於核心地位的。官方定義為：是在系統之外與系統交互的某人或某事物。
1.1 參與者位於邊界之外
主動啟動業務的，就是參與者。
1.2 參與者可以非人
當某些需求沒有人參與時，需求的啟動者即為參與者。
2. 發現參與者
詢問以下問題幫助確定參與者：
- 誰負責提供、使用或刪除信息？
- 誰將使用此功能？
- 誰對某個特定的功能感興趣？
- 在組織中的什么地方使用系統？
- 誰負責支持和維護系統？
- 系統有哪些外部資源？
- 還有哪些其他系統將需要與該系統進行交互？
- 情況一：機票購買者通過登錄網站購買機票，那么機票購買者就是參與者。
- 情況二：機票購買者通過呼叫中心，由人工座席操作訂票系統來購買機票，那么人工座席才是真正的參與者，而機票購買者實際上是呼叫中心的參與者。
- 情況三：如果機票購買者通過呼叫中心的自動語音預定機票而不是通過人工座席，那么呼叫中心就成為機票預訂系統的一個參與者。這是一個參與者非人類的例子。
- 情況四：如果擴大系統邊界，讓呼叫中心成為機票預訂系統的一個子系統，並且假設機票購買者將可以自主選擇是通過人工座席、自動語音還是登錄網站來預定機票，那么機票購買者是參與者，而人工座席則變成業務工人。
3. 業務主角
業務主角（business actor）是參與者的一個版型，在需求階段使用，是與業務系統有着交互的人和事物，用來確定業務的范圍。
業務主角的特殊之處在於，他針對的是業務人員，是客戶實際業務里的參與者，而不是計算機用戶。
4. 業務工人
處於系統邊界內，就不再是參與者，但是確實參與了業務的執行過程，就被成為業務工人（business worker）。
如情況四中的人工座席。
如何分辨是參與者還是業務工人呢？
最直接的辦法是判斷在邊界之外還是邊界之內。如果邊界尚不清楚，通過以下三個問題幫助澄清：
- 它是主動向系統發出動作的嗎？
- 他有完整的業務目標嗎？
- 系統是為他服務的嗎？
如果是否定的，則是業務工人。
5. 參與者與涉眾的關系
涉眾（stakeholder），也稱為干系人。涉眾是與要建設的這個系統有利益相關的一切人和事，涉眾的利益會影響系統的建設。
- 並不是所有的涉眾都是系統的參與者，與系統的建設存在利益關系即為涉眾；
- 而參與者是涉眾代表，它們的要求是系統需求的來源。
6. 參與者和用戶的關系
用戶（user）是指系統的使用者，通俗來說就是系統的操作員。
- 用戶是參與者的代表；
- 並非所有的參與者都是用戶，但是一個用戶可以代理多個參與者。
7. 參與者與角色的關系
角色（role）是參與者的職責。一個角色代表了系統中的一類職責。
由於一個用戶可以代理多個參與者，因此一個用戶可以擁有多個職責，也就是可以被指定多個角色。
8. 參與者的核心地位
- 參與者是涉眾的代表，他代表涉眾對系統的利益要求，並向系統提出建設要求；
- 參與者通過代理給其他用戶或者將自身實例化為用戶來使用系統；
- 參與者的職責可以用角色來歸納，用戶被指定扮演哪個或哪些角色，來獲得參與者的職責。
9. 檢查點
通過一個檢查點列表來保證發現的參與者是正確的：
- 是否您已經找到所有的參與者？也就是說，是否您已經對系統環境中所有角色都進行了說明和建模？雖然您應該檢查這一點，但是要到您找到並說明了所有用例后才能將其確定。
- 每個參與者是否至少涉及到一個用例？刪除未在用例說明中提及的所有參與者，或與用例無通信關聯關系的所有參與者。
- 您是否列出至少兩名可以作為特定參與者的人員？如果不能，請檢查參與者所建模的角色是否為另一角色的一部分。如果是這樣，您應該將參與者與另一參與者合並。
- 是否有參與者擔任與系統相關的相似角色？如果有，您應該將它們合並到一個主角中。通信關聯關系和用例說明表明參與者和系統是如何相互關聯關系的。
- 是否有兩個參與者擔任與用例相關的同一角色？如果有，您應該利用參與者泛化關系來為它們的共享行為建立模型。
- 特定的參與者是否將以幾種（完全不同的）方式使用系統？或者，他使用用例是否出於幾個（完全不同的）目的？如果是這樣，您也許應該有多個參與者。
- 參與者是否有直觀名稱和描述性名稱？用戶和客戶是否都能理解這些名稱？參與者的名稱務必要與其角色相符。否則，應對其進行修改。