天天看點

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

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

參與者位于邊界之外,邊界之内的都不叫參與者。用一個詞來形容更準确,主角。也就是隻有主動啟動了這個業務的人,才是參與者。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文轉自TBHacker部落格園部落格,原文連結:http://www.cnblogs.com/jiqing9006/p/3381632.html,如需轉載請自行聯系原作者

繼續閱讀