來自新浪博客“kslume07”
參與者（actor）在建模過程中是處於核心地位的。UML官方文檔對actor的定義爲：參與者（actor）是在系統之外與系統交互的某人或某事物。“系統之外”的定義說明在參與者和系統之間有一個明顯的邊界，參與者（actor）只可能存在於邊界之外，邊界之內的所有人或者事物都不是參與者。
參與者（actor）還有另外一種叫法：主角。主角這一叫法則很明確的說明了只有主動啓動了業務的，纔是參與者。
發現參與者
誰對系統有明確目標和要求並且主動發出動作？
系統爲誰服務？
首先了解一個概念：涉衆（stakeholder），也稱爲干係人。涉衆是與要建設的這個系統有利益相關的一切人和事，涉衆的利益要求會影響系統的建設。參與者的一個重要來源是涉衆，從涉衆中找出那些直接對系統發出動作，或者直接從系統中接受反饋的涉衆。參與者是涉衆代表，參與者對系統的要求直接影響系統的建設，他們的要求就是系統需求的來源，參與者通過對系統提出要求來獲得他所代表的涉衆的利益。參與者的另一個來源是客戶的崗位設置。
在查找參與者的過程中，嘗試尋找一下問題的答案有助於你確定參與者：
1、誰負責提供、使用或者刪除信息？
2、誰將使用此功能？
3、誰對某個特定功能感興趣？
4、在組織中的什麼地方使用系統？
5、誰負責支持和維護系統？
6、系統有那些外部資源？
7、其他還有那些系統將需要與該系統進行交互？
參與者一定是直接並且主動向系統發出動作並獲得反饋http://www.731job.com的，否則就不是參與者。
業務主角（business actor）
業務主角是參與者的一個版型，特別用於定義業務的參與者，在需求階段使用。業務主角是與業務系統有着交互的人和事物，他們用來確定業務範圍。業務主角的特殊性在於，它針對的是業務人員而非計算機用戶。要建設一個符合客戶需要的計算機系統，首要條件是完全徹底地搞清楚客戶的業務，而不是預想已經有了一個計算機系統
所以在初始需求階段，請務必使用業務主角，時時牢記業務主角是客戶實際業務裏的參與者，沒有計算機系統，沒有抽象的計算機角色。業務主角必須在實際的業務裏能找到對應的崗位或人員。
業務工人（business worker）
在建模過程中，有些人員雖然參與了業務，但是身份很尷尬，因爲他們是被動參與業務的，不好確定其目的是什麼，但是又確確實實在業務過程中做了事情。出現這種困擾的原因是打破了對邊界的定義，這樣的人員實際上應該是邊界內的人員，被稱爲業務工人（business worker）。
如何區分參與者和業務工人呢？最直接的方法是判斷他是出現在系統邊界之內還是在邊界之外。如果邊界不清楚http://www.feifans.com/，可以通過以下三個問題來澄清。
1、 他是主動向系統發出動作的嗎？
2、 他有完整的業務目標嗎？
3、 系統是爲他服務的嗎？
如果以上三個問題的答案都是否定的，那麼他一定是業務工人。
參與者與用戶和角色的關係
用戶（user）是指系統的使用者，通俗一點說就是系統的操作員。用戶是參與者的代表，或者說是參與者的實例或者代理。並非所有參與者都是用戶，但是一個用戶可以代理多個參與者。
角色（role）是參與者的職責。角色是一個抽象概念，從衆多參與者的職責中抽象出來相同的那一部分，將其命名爲角色。一個角色代表了系統中的一類職責。
參與者的核心地位
參與者是涉衆的代表，它代表涉衆對系統的利益要求，並向系統提出建設要求；參與者通過代理給其他用戶或者將自身實例化成爲用戶來使用系統；參與者的職責可以用角色來歸納，用戶被指定扮演哪個或哪些角色因此來獲得參與者的職責。
同時，系統是以參與者的觀點來決定的。參與者對系統的要求對系統的表述完全決定了系統的功能。