UML--核心元素之參與者Actor


參與者(actor):在系統之外與系統交互的某人或某事物。例如,管理員,用戶等等。

參與者位於邊界之外,邊界之內的都不叫參與者。用一個詞來形容更准確,主角。也就是只有主動啟動了這個業務的人,才是參與者。

第二點要注意的是,參與者可以非人。參與者可以是另一個計算機系統、一個計時器、一個傳感器等。任何一個功能性需求,都有參與者啟動。

 

我們通過機票預訂系統來分析一些情況。

情況一:機票購買者通過登錄網站購買機票,那么機票購買者就是參與者。

 

情況二:假如機票購買者通過呼叫中心,由人工座席操作訂票系統購買機票,那么人工座席才是真正的參與者,而機票購買者是呼叫中心的參與者。

 

情況三:如果機票購買者通過呼叫中心的自動語音預定機票而不是通過人工座席,那么呼叫中心就成為機票預定系統的一個參與者。

 

情況四:如果擴大系統邊界,讓呼叫中心成為機票預定系統的一個子系統,並且假設機票購買者可以自主選擇是通過人工座席、自動語音還是登錄網站預定機票,那么機票購買者是參與者,而人工座席則變成業務工人。

 

 業務主角(business actor):業務主角是參與者的一個版型。業務主角,針對的是業務人員而非計算機用戶。在沒有計算機系統,這些業務人員 也客觀存在,在引入計算機系統之前他們的業務也一直跑得很順暢。

在建設一個符合客戶需要的計算機系統之前,首要條件是很好地搞清楚客戶的業務。

 

在初始需求階段,務必使用業務主角,業務主角是客戶實際業務里的參與者,沒有計算機系統,沒有抽象的計算機角色。

業務主角,必須在實際業務里能找到對應的崗位或人員。

業務工人(business worker):有些人員參與了業務,但是身份很尷尬,他是被動參與業務的。這些在系統邊界內的人員,被稱為業務工人。

通過三個問題,來分析是否是業務工人。

一、他是主動向系統發出動作的嗎?

二、他有完整的業務目標嗎?

三、系統是為他服務的嗎?

如果答案都是否定的,那他一定是業務工人。

 

涉眾(stakeholder),也稱為干系人。參與者是涉眾代表。例如要建立一個辦公自動化系統,這兒系統將為所有辦公室文員歸檔和查找文件帶來利益。但是並不需要把所有的辦公室文員都找來詢問需求,一個稱為“文員”的參與者可以代表這批涉眾來向系統提供如何歸檔和如何查詢的要求。

 

myself:突然感覺,系統的好處就是在於文檔的電子化,方便查詢和歸檔。我們目前要為聾校做的系統,也是一個電子歸檔化的過程。將老師平時的一些電子稿信息歸檔。但是前提,要有一些基礎信息的管理。包括老師和學生的一些基礎信息。學生的健康信息等。老師上課的信息與工資信息等等。學生的聽力信息管理等等。老師考核信息管理,學生成績管理。等多角度的文檔歸檔與查詢。說白了,就是這樣。沒那么神秘。

 

用戶(user):是指系統的使用者,通俗點說就是系統的操作員。用戶是參與者的代表,或者說參與者的實例或代理。並非所有的參與者都是用戶,但是一個用戶可以代理多個參與者。

 

角色(role):是參與者的職責。是參與者職責中抽象出相同的那一部分。一個用戶可以代理多個參與者,擁有多個職責,指定為多個角色。

通過這個圖,來理解參與者與各概念之間的關系。

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM