參與者（actor）：在系統之外與系統互動的某人或某事物。例如，管理員，使用者等等。
參與者位於邊界之外，邊界之內的都不叫參與者。用乙個詞來形容更準確，主角。也就是只有主動啟動了這個業務的人，才是參與者。
第二點要注意的是，參與者可以非人。參與者可以是另乙個計算機系統、乙個計時器、乙個感測器等。任何乙個功能性需求，都有參與者啟動。
我們通過機票預訂系統來分析一些情況。
情況二：假如機票購買者通過呼叫中心，由人工座席操作訂票系統購買機票，那麼人工座席才是真正的參與者，而機票購買者是呼叫中心的參與者。
情況三：如果機票購買者通過呼叫中心的自動語音預定機票而不是通過人工座席，那麼呼叫中心就成為機票預定系統的乙個參與者。
情況四：如果擴大系統邊界，讓呼叫中心成為機票預定系統的乙個子系統，並且假設機票購買者可以自主選擇是通過人工座席、自動語音還是登入**預定機票，那麼機票購買者是參與者，而人工座席則變成業務工人。
業務主角（business actor）：業務主角是參與者的乙個版型。業務主角，針對的是業務人員而非計算機使用者。在沒有計算機系統，這些業務人員 也客觀存在，在引入計算機系統之前他們的業務也一直跑得很順暢。
在建設乙個符合客戶需要的計算機系統之前，首要條件是很好地搞清楚客戶的業務。
在初始需求階段，務必使用業務主角，業務主角是客戶實際業務裡的參與者，沒有計算機系統，沒有抽象的計算機角色。
業務主角，必須在實際業務裡能找到對應的崗位或人員。
業務工人（business worker）：有些人員參與了業務，但是身份很尷尬，他是被動參與業務的。這些在系統邊界內的人員，被稱為業務工人。
通過三個問題，來分析是否是業務工人。
一、他是主動向系統發出動作的嗎？
二、他有完整的業務目標嗎？
三、系統是為他服務的嗎？
如果答案都是否定的，那他一定是業務工人。
涉眾（stakeholder），也稱為干係人。參與者是涉眾代表。例如要建立乙個辦公自動化系統，這兒系統將為所有辦公室文員歸檔和查詢檔案帶來利益。但是並不需要把所有的辦公室文員都找來詢問需求，乙個稱為「文員」的參與者可以代表這批涉眾來向系統提供如何歸檔和如何查詢的要求。
myself：突然感覺，系統的好處就是在於文件的電子化，方便查詢和歸檔。我們目前要為聾校做的系統，也是乙個電子歸檔化的過程。將老師平時的一些電子稿資訊歸檔。但是前提，要有一些基礎資訊的管理。包括老師和學生的一些基礎資訊。學生的健康資訊等。老師上課的資訊與工資資訊等等。學生的聽力資訊管理等等。老師考核資訊管理，學生成績管理。等多角度的文件歸檔與查詢。說白了，就是這樣。沒那麼神秘。
使用者（user）：是指系統的使用者，通俗點說就是系統的操作員。使用者是參與者的代表，或者說參與者的例項或**。並非所有的參與者都是使用者，但是乙個使用者可以**多個參與者。
角色（role）：是參與者的職責。是參與者職責中抽象出相同的那一部分。乙個使用者可以**多個參與者，擁有多個職責，指定為多個角色。
通過這個圖，來理解參與者與各概念之間的關係。
UML核心元素之參與者
一 概述 在系統之外與系統互動的某人或某事物。1 如何找到參與者，確定系統邊界。在乙個業務中可以問自己兩個問題 a.誰對系統有著明確的目標和和要求並且主動發出動作。b.系統是為誰服務。參與者還有另一種叫法 主角。參與者容易讓人誤解為只要參與了業務的，都是參與者，而主角很明確的指出，只有主動啟動這個業...
UML核心元素之參與者
一 概述 在系統之外與系統互動的某人或某事物。1 如何找到參與者，確定系統邊界。在乙個業務中可以問自己兩個問題 a.誰對系統有著明確的目標和和要求並且主動發出動作。b.系統是為誰服務。參與者還有另一種叫法 主角。參與者容易讓人誤解為只要參與了業務的，都是參與者，而主角很明確的指出，只有主動啟動這個業...
UML學習 2 參與者
一 參與者 參與者 在建模過程中處於核心地位。uml官方文件對參與者的定義為 actor是在系統之外與系統互動的某人或某事物 大象 thinking in uml，p39 1.參與者特徵 用例的乙個特徵是 不存在沒有參與者的用例，用例不應該自動啟動，也不應該主動啟動另乙個用例。大象 thinking...