UML建模方法論(中):業(yè)務(wù)建模
本篇文章承接上一篇文章:《UML建模方法論(上):建模初期準備》,閱讀本篇文章前建議先閱讀上一篇文章。
四、建模第四步:業(yè)務(wù)建模
業(yè)務(wù)建模這一塊按照書中的方法來操作需要做很多的工作,包括:
- 業(yè)務(wù)用例視圖;
- 業(yè)務(wù)用例場景;
- 業(yè)務(wù)用例規(guī)約;
- 業(yè)務(wù)規(guī)則;
- 業(yè)務(wù)對象模型;
- 業(yè)務(wù)用例實現(xiàn)視圖;
- 業(yè)務(wù)用例實現(xiàn)場景;
- 包圖。
但是我認為我們只需要把握住其中的核心環(huán)節(jié)進行建模就可以了,而且實際工作中往往沒有那么多的時間給你去做這些,我們需要做的是把握其中20%但提供了80%價值的工作。
所以在業(yè)務(wù)建模這一塊,我認為只需要做最核心的業(yè)務(wù)用例視圖建模和業(yè)務(wù)用例場景建模就可以了。
4.1 業(yè)務(wù)用例視圖建模
什么是用例圖?
在UML里有一種視圖類型叫用例圖,用例圖采用參與者和用例作為基本元素,以不同的視角展現(xiàn)系統(tǒng)的功能性需求。用例視圖是了解系統(tǒng)的第一個關(guān)口,人們通過用例視圖得知一個系統(tǒng)將會做什么。對客戶來說,用例視圖是他們業(yè)務(wù)領(lǐng)域的邏輯化表達,對建設(shè)單位來說,用例視圖是系統(tǒng)藍圖和開發(fā)的依據(jù)。
而業(yè)務(wù)用例圖是用例圖的一種,后面的文章我們會講到還有系統(tǒng)用例圖,不同的用例圖有不同的作用,業(yè)務(wù)用例圖屬于業(yè)務(wù)建模的一個環(huán)節(jié),用圖形化的方式來展現(xiàn)公司開展哪些業(yè)務(wù)。
如何建立業(yè)務(wù)用例視圖:
- 確定業(yè)務(wù)邊界;
- 找到業(yè)務(wù)主角;
- 獲取業(yè)務(wù)用例。
4.1.1 定義邊界
什么是業(yè)務(wù)邊界?
為了實現(xiàn)某類人群共同目標需要完成的事情,工作的集合,本質(zhì)是業(yè)務(wù)或者需求的范圍。
邊界的作用:明確需求的范圍,從而讓我們知道哪些需求是我們需要考慮和分析的哪些是不需要考慮的,通過邊界我們劃分了一個系統(tǒng)的功能范圍。
定義邊界的目的:定義邊界的目的是為我們確定一個分析的起點。只有明確了邊界,我們才能確定人群,隨之確定有哪些業(yè)務(wù)主角,然后才能確定具體需要完成的事情,也就是用例。
如何得到邊界:
- 如果業(yè)務(wù)目標比較具體,可以直接從業(yè)務(wù)目標得出;
- 如果業(yè)務(wù)目標范圍比較大可以將業(yè)務(wù)目標分解為幾個小的目標從而得出我們的邊界。
確定邊界的過程說明:
邊界的確定是一個動態(tài)的過程,沒有明確的方法。
所以在需求出來之前,我們必須先設(shè)想一個邊界,這個邊界的大小是不確定的,隨著需求的明確,邊界也逐步變得明朗。但是問題出在確定需求靠什么?靠參與者和用例對吧?
而參與者和用例得以明確的前提條件是邊界是確定的,而偏偏這個時候邊界是無法確定的。是的,這是一個矛盾,實際上需求就是在不斷地調(diào)整這個矛盾的過程中逐步明確進而更加確定邊界的。這個調(diào)整過程不可避免地會導(dǎo)致參與者和用例的變化。
所以需求過程是一個動態(tài)的過程,不可能一蹴而就,我們只能把這些不同的結(jié)果進行對比、思考、討論,最終希望得到一個更恰當(dāng)?shù)慕Y(jié)果,就像盲人摸象—樣,多方結(jié)果的相互印證得出的結(jié)論總是會更接近真相。所以在建模過程中,如果對建模結(jié)果感到疑惑,就可以試著改變邊界設(shè)定,得到不同的參與者和用例,再通過相互印證的方式得到更好的結(jié)果。
如何判斷得到的邊界是否合適:
推導(dǎo)出的邊界是沒有正確答案的,所以如何判斷推導(dǎo)出的邊界是否合適呢,有以下兩個參考點:
- 從該邊界中推導(dǎo)出來的用例數(shù)量不能太多,粒度不能太小,這樣這個邊界可能就是合理的;
- 抓住邊界的本質(zhì),本質(zhì)是業(yè)務(wù)或者需求的范圍只要這個范圍大小合適,范圍內(nèi)的需求都互相關(guān)聯(lián),基本就差不多了。
以我們之前給出的業(yè)務(wù)目標來舉例:
目標:幫助銷售部管理好客戶,提高銷售部的工作效率。
按照我們給出的定義:邊界是“為了實現(xiàn)某類人群共同目標需要完成的事情,工作的集合,本質(zhì)是業(yè)務(wù)或者需求的范圍”。
因為銷售部人員的共同目標是簽約學(xué)員,所以由此推出邊界:“為了簽約學(xué)員所需要完成的事情的集合”簡稱:簽約學(xué)員。
用圖形的方式表示出來:
包括兩個部分:
- 邊界名稱:簽約客戶;
- 邊界的形象化表示:一個空白的邊框。
4.1.2 發(fā)現(xiàn)主角
主角的定義:? 主角代表了涉眾利益,站在邊界之外,直接與邊界代表的系統(tǒng)(我們也可以把邊界理解為我們要打造的系統(tǒng))交互,對系統(tǒng)有著明確的要求并從系統(tǒng)獲得明確的結(jié)果。發(fā)現(xiàn)主角,我們就從定義開始。
哪些人是業(yè)務(wù)主角:
- 系統(tǒng)將要服務(wù)的人員,直接與系統(tǒng)交互;
- 將來要通過系統(tǒng)做事的人;
- 我們要實現(xiàn)的業(yè)務(wù)目標是哪些人的目標,是哪些人的期望, 這些人就是業(yè)務(wù)主角。
找到業(yè)務(wù)主角的作用:找到主角后我們才能分析出用例有哪些。
如何尋找?
我們已經(jīng)有了一份涉眾匯總表格,也已經(jīng)有了邊界定義,我們可以據(jù)此來尋找業(yè)務(wù)主角。
首先根據(jù)涉眾匯總表格,我們很容易得到備選的涉眾列表;其次根據(jù)所定義的邊界,我們可以從中尋找那些站在邊界外的涉眾。用主角的定義去審查這些備選的涉眾在此邊界內(nèi)的行為模式,從中找出符合定義的涉眾而形成業(yè)務(wù)主角。
請注意,不是所有的涉眾都會成為業(yè)務(wù)主角,只有那些直接與系統(tǒng)交互的涉眾才能被稱為業(yè)務(wù)主角。
怎么理解這句話呢?舉個例子:CEO是我們的涉眾,CEO的秘書不是我們的涉眾,但是在以后系統(tǒng)建設(shè)好后,CEO沒那么多的時間天天操作系統(tǒng),而是把操作系統(tǒng)的權(quán)限給到秘書,那么在我們分析系統(tǒng)時,CEO就不是業(yè)務(wù)主角,CEO的秘書才是。
另一方面,涉眾利益可以被多個不同的業(yè)務(wù)主角所代表,這意味著,一個涉眾可以衍生出多個主角。
在尋找業(yè)務(wù)主角的時候我們要注意區(qū)分業(yè)務(wù)主角和業(yè)務(wù)工人:業(yè)務(wù)工人做出的行為都是為了主角的目標服務(wù)的,主角會先對系統(tǒng)做出動作,然后業(yè)務(wù)工人響應(yīng)。
幫助區(qū)分主角或者業(yè)務(wù)工人的三個問題:
那么如何區(qū)分是參與者還是業(yè)務(wù)工人呢?最直接的辦法當(dāng)然是判斷是在邊界之外還是邊界之內(nèi)。如果邊界尚不清楚,可以通過下面的三個問題幫助澄清:
- 他是主動向系統(tǒng)發(fā)出動作的嗎?
- 他有完整的業(yè)務(wù)目標嗎?
- 系統(tǒng)是為他服務(wù)的嗎?
舉個例子:
十年以前我們買火車票需要到火車站的柜臺去給售票員說我要買從哪到哪的票,然后把錢給售票員,售票員把票給我們,這樣就完成了一次買票的任務(wù),現(xiàn)在假如我們需要開發(fā)一個購票系統(tǒng),到了分析買票業(yè)務(wù)的環(huán)節(jié),需要建立業(yè)務(wù)用例視圖,請大家分析一下邊界是什么,業(yè)務(wù)主角是誰,業(yè)務(wù)工人又是誰。
分析結(jié)果:根據(jù)我們之前給出的邊界定義,因為我們要開發(fā)一個購票系統(tǒng),可以得到,我們的業(yè)務(wù)目標是購票,所以邊界就是“購票”,確定了邊界后我們再確定主角,再根據(jù)上面給出的幫助區(qū)分主角或者業(yè)務(wù)工人的三個問題來看:
(1)他是主動向系統(tǒng)發(fā)出動作的嗎?
購票這個過程是誰先發(fā)起的動作,當(dāng)然是購票人先提出買票,然后售票員才把票給到購票人,所以購票人是主角,業(yè)務(wù)工人是售票員
(2)他有完整的業(yè)務(wù)目標嗎?
這個問題該如何理解,購票人做的事情是到柜臺買票,他的目標很清楚因為要坐車所以要買票,而售票員做的事情是協(xié)助購票者購票,那么單純看售票員做的事情對于售票員有意義嗎,
如果沒有購票者那么售票員就不會做這件事情,售票員之所以做這件事,完全是因為有購票者,所以我們說售票員沒有一個完整的業(yè)務(wù)目標
如果大家對這一點還有一些疑惑的話,可以繼續(xù)看后面給出的案例,細細體會
(3)系統(tǒng)是為他服務(wù)的嗎?
這個很好理解了,開發(fā)出購票系統(tǒng)當(dāng)然是給購票者用的,所以購票者就是主角。
為什么要分業(yè)務(wù)主角和業(yè)務(wù)工人?
因為業(yè)務(wù)工人是為了幫助主角實現(xiàn)主角的期望,我們可以通過主角的期望推導(dǎo)出業(yè)務(wù)工人的期望,所以我們只需要找到所有的主角和主角的期望,再從主角的期望推導(dǎo)出業(yè)務(wù)工人的期望即可,有利于我們清晰的得到相關(guān)用例而不至于混亂。
繼續(xù)順著我們之前給出的案例做分析:前面我們已經(jīng)確定了邊界是“簽約學(xué)員”,我們再通過上面給出的幫助尋找主角的三個問題來尋找主角:
- 系統(tǒng)將要服務(wù)的人員,直接與系統(tǒng)交互;
- 將來要通過系統(tǒng)做事的人;
- 我們要實現(xiàn)的業(yè)務(wù)目標是哪些人的目標,是哪些人的期望, 這些人就是業(yè)務(wù)主角。
于是我們從涉眾列表中找到了這樣三個角色,銷售總監(jiān),銷售主管,課程顧問,又因為實際業(yè)務(wù)中銷售主管和課程顧問其實做的工作是完全相同的,可以把銷售主管理解為資歷比較老的課程顧問,所以我們現(xiàn)在將業(yè)務(wù)主角簡化為2個,銷售總監(jiān)和課程顧問(行話叫CC)。
確定了主角后我們開始獲取業(yè)務(wù)用例:
4.1.3 獲取業(yè)務(wù)用例
什么是業(yè)務(wù)用例?
業(yè)務(wù)用例是為了實現(xiàn)業(yè)務(wù)目標而需要做的一件事或一項工作。
這里一定要注意的是,一個用例是主角對目標系統(tǒng)的一個愿望,一個完整的事件。為了完成這個事件需要經(jīng)過很多步驟,但這些步驟不能夠完整地反映參與者的目標,不能夠作為用例。
最重要的區(qū)分方法是主角完成一個用例所描述的事件后一定有一個有意義的結(jié)果,而如果主角只是完成一個步驟的話,單從做完這一個步驟的結(jié)果來看是沒有任何意義的,只有做完一連串的步驟,才會有一個有意義的結(jié)果。
這點一定要注意,否則你在獲取業(yè)務(wù)用例環(huán)節(jié)會找出一堆的用例。
業(yè)務(wù)用例的作用:捕捉為了實現(xiàn)業(yè)務(wù)目標而需要做的具體的事件。
發(fā)現(xiàn)和定義業(yè)務(wù)用例的目的:
- 了解客戶業(yè)務(wù)構(gòu)成;
- 確定業(yè)務(wù)范圍;
- 是推導(dǎo)我們后續(xù)要講到的系統(tǒng)用例的前提條件。
如何找到業(yè)務(wù)用例:
獲取業(yè)務(wù)用例有很多方法,可以從崗位手冊、業(yè)務(wù)流程指南、職務(wù)說明等一些文件中獲得,也可以從涉眾分析中獲得靈感。但是最重要,最有效的方法,就是業(yè)務(wù)主角訪談,可以通過以下問題引導(dǎo)業(yè)務(wù)主角代表說出他們的業(yè)務(wù)需求:
- 您對系統(tǒng)有什么期望?
- 您打算在這個系統(tǒng)里做些什么事情?
(上面兩個問題的目的:發(fā)現(xiàn)用例)
- 您做這件事的目的是什么?
- 您做完這件事希望有一個什么樣的結(jié)果?
(上面兩個問題的目的:判斷這件事是否真的是用例還是只是一個步驟)
業(yè)務(wù)用例獲取什么時候結(jié)束?
作者的建議是不要追求完美,事實上也不可能有完美。只要感覺到已經(jīng)把客戶的業(yè)務(wù)弄清楚了就可以考慮結(jié)束,而不必等到事無巨細的每件事都定義得清清楚楚。
繼續(xù)分析我們的案例:通過和業(yè)務(wù)主角進行訪談,我們了解到為了實現(xiàn)簽約客戶這個業(yè)務(wù)目標,銷售總監(jiān)和課程顧問需要做下面這些事情。
說明:虛線框中的內(nèi)容表示的是完成同一件事情的兩種不同場景,用術(shù)語來說就是業(yè)務(wù)用例實現(xiàn)。
至此我們的業(yè)務(wù)用例視圖模型就建立好了。
4.2 業(yè)務(wù)用例場景建模
什么是場景?
場景應(yīng)該怎么理解呢?經(jīng)常有朋友繪制完用例以后不知如何繪制場景,有朋友認為場景就是活動圖,也有朋友認為場景就是業(yè)務(wù)流程圖,這些理解都是不完全準確的。
用例,case的含義:
還是從用例說起,讓我們從詞義上好好理解一下。case 這個詞兒大家應(yīng)該很熟悉, 一個商業(yè)項目可以稱為一個case:一個訴訟案件也可以稱為一個case;我們常說做事情要因地制宜,一件件的來,可以說case by case 。可見,case 這個詞兒表達的就一個個特定的事件。
用商業(yè)項目舉例講述場景:
既然是特定的事件,它必然包含有一個特定的目標、執(zhí)行人和執(zhí)行過程。執(zhí)行人和執(zhí)行過程,最終是為了達到這個特定目標。
以商業(yè)項目為例:最終目標是簽署商業(yè)合同,這其中牽涉到策劃、宣傳、調(diào)研、談判、法律等很多人和事。商業(yè)項目有其既定的程序,也就是按—定的順序來完成這些活動,最終達到商業(yè)目的是在正式開展商業(yè)項目之前,這個程序應(yīng)該是被計劃一好了的,這稱之為一個方案,在建模來說,這就是一個場景。
商場如戰(zhàn)場,任何事情都可能發(fā)生,所以我們要做好多種可選方案,在建模來說,這就是多個場景。市場瞬息萬變, 再好的商業(yè)方案也不能一條道走到黑,當(dāng)市場發(fā)生變化時,方案也要隨之做出調(diào)整,在建模來說,這就是分支過程。 另外,我們也不得不考慮到意外情況的發(fā)生,要做好應(yīng)對措施,在建模來說,這就是異常過程。
場景的同義詞:因此,如果你對場景這個詞感到抽象,不好理解,完全可以將其被類比為做一個執(zhí)行方案、一個行動計劃、一個演練或者一個彩排。
業(yè)務(wù)用例場景建模的目的:
- 說明業(yè)務(wù)用例的執(zhí)行過程,說明業(yè)務(wù)主角是如何使用業(yè)務(wù)用例完成業(yè)務(wù)目標的。
- 了解每個業(yè)務(wù)用例是如何在沒有計算機的情況下實現(xiàn)的,然后推導(dǎo)出系統(tǒng)用例。
輸出:業(yè)務(wù)用例場景視圖。
用什么視圖繪制場景:繪制業(yè)務(wù)用例場景我們可以使用,時序圖,交互圖,或活動圖,但是最實用,必須要掌握的是使用活動圖來繪制業(yè)務(wù)用例場景,所謂活動圖,也就是我們經(jīng)常見到的泳道圖。
繪制場景的兩個基本要求:
場景隱含著兩個基本要求:一是必須忠實于真實業(yè)務(wù),二是一個場景只能描述業(yè)務(wù)的一種執(zhí)行方式。也就是說,在描述業(yè)務(wù)用例場景時不能帶有“設(shè)計“思想在里面,或者試圖“抽象”和“優(yōu)化“業(yè)務(wù)過程,它必須和客戶認可的實際業(yè)務(wù)執(zhí)行一致。同時,不要試圖在一個場景里把業(yè)務(wù)的所有內(nèi)容都包括進來,繪制出一幅充滿了判斷分支,像蜘蛛網(wǎng)一樣的活動圖。每一個場景只針對一種業(yè)務(wù)執(zhí)行方式,應(yīng)當(dāng)清晰而明了。
繼續(xù)分析我們的案例:之前給出的每一個業(yè)務(wù)用例都對應(yīng)著一個場景,所以在實際工作中我們應(yīng)該把每一個場景都用活動圖畫出來,但是現(xiàn)在我們只用其中最復(fù)雜的一個場景“跟進線索”來舉例并繪制活動圖。
說明:
- 在這個場景中,CC是業(yè)務(wù)主角,其他三個角色都是為了配合CC跟進線索從而實現(xiàn)簽約學(xué)員這個目標而服務(wù)的,整個過程的發(fā)起人也是CC,沒有CC,其他三個人就不會做這些事情,所以其他三個人都是業(yè)務(wù)工人,業(yè)務(wù)工人只應(yīng)該出現(xiàn)在業(yè)務(wù)用例場景圖中,不會在業(yè)務(wù)用例視圖中出現(xiàn),雖然這三個人的這些工作也為簽約學(xué)員這個目標作出了貢獻。
- 在繪制業(yè)務(wù)用例場景時一定要注意的是要忠于實際業(yè)務(wù)。
- 我們繪制的業(yè)務(wù)用例場景圖其實也就是我們平時所說的業(yè)務(wù)流程圖,是為了反映真實業(yè)務(wù)而繪制的圖,但是平時大家畫業(yè)務(wù)流程圖時有固定的章法嗎,是不是感覺按照文章中這樣從業(yè)務(wù)目標,業(yè)務(wù)用例,業(yè)務(wù)場景一步一步推導(dǎo)出來更加的嚴謹呢?
現(xiàn)在我們只畫了一個場景的,在實際工作中我們需要把所有業(yè)務(wù)目標下分析出的所有業(yè)務(wù)用例都對應(yīng)畫出業(yè)務(wù)用例場景圖,不過有些場景比較簡單,流程比較短,我們也可以省略,這樣我們最終會畫出很多的業(yè)務(wù)流程圖,但是也不用擔(dān)心,畢竟系統(tǒng)是一點一點做出來的,圖也是一點一點畫出來的,至此當(dāng)我們的業(yè)務(wù)用例場景圖繪制完畢后,我們的業(yè)務(wù)建模環(huán)節(jié)也就告一段落了。
第三篇《UML建模方法論(下):系統(tǒng)建?!废到y(tǒng)建模也會在接下來的兩天內(nèi)更新出來~
作者:一點優(yōu)秀,教育行業(yè)產(chǎn)品經(jīng)理,微信號:gentleman52520,歡迎交流
本文由 @一點優(yōu)秀 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
文章中提到‘業(yè)務(wù)建模這一塊按照書中的方法來操作需要做很多的工作’,請問業(yè)務(wù)建模的書有哪些推薦?
業(yè)務(wù)工人按照定義,應(yīng)該是“位于系統(tǒng)邊界內(nèi),被動參與了業(yè)務(wù)的執(zhí)行過程的人”,給劃到系統(tǒng)邊界外了
PEST
在業(yè)務(wù)目標那里,文中說業(yè)務(wù)目標是“幫助銷售部管理好客戶,提高銷售部的工作效率”,然后下文又說,目標是簽約客戶。我的理解是目標分兩塊,一塊管理客戶,一塊提高效率,然后簽約客戶是管理客戶中的一個用例,不知道我這么理解有沒有什么錯誤?或者作者為什么是文中那么理解的?
而且UML建模語言本身沒有這么強調(diào)業(yè)務(wù)視圖,業(yè)務(wù)用例圖,他們其實都是用例圖。
整個過程的發(fā)起人也是CC,沒有CC,其他三個人就不會做這些事情,所以其他三個人都是業(yè)務(wù)工人,業(yè)務(wù)工人只應(yīng)該出現(xiàn)在業(yè)務(wù)用例場景圖中,不會在業(yè)務(wù)用例視圖中出現(xiàn),雖然這三個人的這些工作也為簽約學(xué)員這個目標作出了貢獻。 這句話有問題吧,可以在業(yè)務(wù)視圖中出現(xiàn)吧,業(yè)務(wù)主角視圖中不應(yīng)該出現(xiàn)。要不業(yè)務(wù)視圖也太狹隘不完整了。
語言再簡練點就好了,饒了一大堆,好像簡單幾段話就能說明白。
看起來很繞的文章,UML是不是把簡單的理論復(fù)雜化了,雖然看著高大上,但是感覺很繞
運營建模就是把目標和過程拆解,找到北極星指標的各個因子然后系統(tǒng)化的連接的過程。
其實平時自己做的時候也差不多是這樣的 只是很多過程直接在腦海里潛意識就形成了 實操中不會把每一個都寫得那么細