本篇文章承接上一篇文章：《UML建模方法論（上）：建模初期準備》，閱讀本篇文章前建議先閱讀上一篇文章。

四、建模第四步：業務建模

業務建模這一塊按照書中的方法來操作需要做很多的工作，包括：

• 業務用例視圖；
• 業務用例場景；
• 業務用例規約；
• 業務規則；
• 業務對象模型；
• 業務用例實現視圖；
• 業務用例實現場景；
• 包圖。

但是我認為我們只需要把握住其中的核心環節進行建模就可以了，而且實際工作中往往沒有那么多的時間給你去做這些，我們需要做的是把握其中20%但提供了80%價值的工作。

所以在業務建模這一塊，我認為只需要做最核心的業務用例視圖建模和業務用例場景建模就可以了。

4.1 業務用例視圖建模

什么是用例圖？

在UML里有一種視圖類型叫用例圖，用例圖采用參與者和用例作為基本元素，以不同的視角展現系統的功能性需求。用例視圖是了解系統的第一個關口，人們通過用例視圖得知一個系統將會做什么。對客戶來說，用例視圖是他們業務領域的邏輯化表達，對建設單位來說，用例視圖是系統藍圖和開發的依據。

而業務用例圖是用例圖的一種，后面的文章我們會講到還有系統用例圖，不同的用例圖有不同的作用，業務用例圖屬于業務建模的一個環節，用圖形化的方式來展現公司開展哪些業務。

如何建立業務用例視圖：

1. 確定業務邊界；
2. 找到業務主角；
3. 獲取業務用例。

4.1.1 定義邊界

什么是業務邊界？

為了實現某類人群共同目標需要完成的事情，工作的集合，本質是業務或者需求的范圍。

邊界的作用：明確需求的范圍，從而讓我們知道哪些需求是我們需要考慮和分析的哪些是不需要考慮的，通過邊界我們劃分了一個系統的功能范圍。

定義邊界的目的：定義邊界的目的是為我們確定一個分析的起點。只有明確了邊界，我們才能確定人群，隨之確定有哪些業務主角，然后才能確定具體需要完成的事情，也就是用例。

如何得到邊界：

1. 如果業務目標比較具體，可以直接從業務目標得出；
2. 如果業務目標范圍比較大可以將業務目標分解為幾個小的目標從而得出我們的邊界。

確定邊界的過程說明：

邊界的確定是一個動態的過程，沒有明確的方法。

所以在需求出來之前，我們必須先設想一個邊界，這個邊界的大小是不確定的，隨著需求的明確，邊界也逐步變得明朗。但是問題出在確定需求靠什么？靠參與者和用例對吧？

而參與者和用例得以明確的前提條件是邊界是確定的，而偏偏這個時候邊界是無法確定的。是的，這是一個矛盾，實際上需求就是在不斷地調整這個矛盾的過程中逐步明確進而更加確定邊界的。這個調整過程不可避免地會導致參與者和用例的變化。

所以需求過程是一個動態的過程，不可能一蹴而就，我們只能把這些不同的結果進行對比、思考、討論，最終希望得到一個更恰當的結果，就像盲人摸象—樣，多方結果的相互印證得出的結論總是會更接近真相。所以在建模過程中，如果對建模結果感到疑惑，就可以試著改變邊界設定，得到不同的參與者和用例，再通過相互印證的方式得到更好的結果。

如何判斷得到的邊界是否合適：

推導出的邊界是沒有正確答案的，所以如何判斷推導出的邊界是否合適呢，有以下兩個參考點：

1. 從該邊界中推導出來的用例數量不能太多，粒度不能太小，這樣這個邊界可能就是合理的；
2. 抓住邊界的本質，本質是業務或者需求的范圍只要這個范圍大小合適，范圍內的需求都互相關聯，基本就差不多了。

以我們之前給出的業務目標來舉例：

目標：幫助銷售部管理好客戶，提高銷售部的工作效率。

按照我們給出的定義：邊界是“為了實現某類人群共同目標需要完成的事情，工作的集合，本質是業務或者需求的范圍”。

因為銷售部人員的共同目標是簽約學員，所以由此推出邊界：“為了簽約學員所需要完成的事情的集合”簡稱：簽約學員。

用圖形的方式表示出來：

包括兩個部分：

1. 邊界名稱：簽約客戶；
2. 邊界的形象化表示：一個空白的邊框。

4.1.2 發現主角

主角的定義：? 主角代表了涉眾利益，站在邊界之外，直接與邊界代表的系統（我們也可以把邊界理解為我們要打造的系統）交互，對系統有著明確的要求并從系統獲得明確的結果。發現主角，我們就從定義開始。

哪些人是業務主角：

1. 系統將要服務的人員，直接與系統交互；
2. 將來要通過系統做事的人；
3. 我們要實現的業務目標是哪些人的目標，是哪些人的期望， 這些人就是業務主角。

找到業務主角的作用：找到主角后我們才能分析出用例有哪些。

如何尋找？

我們已經有了一份涉眾匯總表格，也已經有了邊界定義，我們可以據此來尋找業務主角。

首先根據涉眾匯總表格，我們很容易得到備選的涉眾列表；其次根據所定義的邊界，我們可以從中尋找那些站在邊界外的涉眾。用主角的定義去審查這些備選的涉眾在此邊界內的行為模式，從中找出符合定義的涉眾而形成業務主角。

請注意，不是所有的涉眾都會成為業務主角，只有那些直接與系統交互的涉眾才能被稱為業務主角。

怎么理解這句話呢？舉個例子：CEO是我們的涉眾，CEO的秘書不是我們的涉眾，但是在以后系統建設好后，CEO沒那么多的時間天天操作系統，而是把操作系統的權限給到秘書，那么在我們分析系統時，CEO就不是業務主角，CEO的秘書才是。

另一方面，涉眾利益可以被多個不同的業務主角所代表，這意味著，一個涉眾可以衍生出多個主角。

在尋找業務主角的時候我們要注意區分業務主角和業務工人：業務工人做出的行為都是為了主角的目標服務的，主角會先對系統做出動作，然后業務工人響應。

幫助區分主角或者業務工人的三個問題：

那么如何區分是參與者還是業務工人呢？最直接的辦法當然是判斷是在邊界之外還是邊界之內。如果邊界尚不清楚，可以通過下面的三個問題幫助澄清：

• 他是主動向系統發出動作的嗎？
• 他有完整的業務目標嗎？
• 系統是為他服務的嗎？

舉個例子：

十年以前我們買火車票需要到火車站的柜臺去給售票員說我要買從哪到哪的票，然后把錢給售票員，售票員把票給我們，這樣就完成了一次買票的任務，現在假如我們需要開發一個購票系統，到了分析買票業務的環節，需要建立業務用例視圖，請大家分析一下邊界是什么，業務主角是誰，業務工人又是誰。

分析結果：根據我們之前給出的邊界定義，因為我們要開發一個購票系統，可以得到，我們的業務目標是購票，所以邊界就是“購票”，確定了邊界后我們再確定主角，再根據上面給出的幫助區分主角或者業務工人的三個問題來看：

（1）他是主動向系統發出動作的嗎？

購票這個過程是誰先發起的動作，當然是購票人先提出買票，然后售票員才把票給到購票人，所以購票人是主角，業務工人是售票員

（2）他有完整的業務目標嗎？

這個問題該如何理解，購票人做的事情是到柜臺買票，他的目標很清楚因為要坐車所以要買票，而售票員做的事情是協助購票者購票，那么單純看售票員做的事情對于售票員有意義嗎，

如果沒有購票者那么售票員就不會做這件事情，售票員之所以做這件事，完全是因為有購票者，所以我們說售票員沒有一個完整的業務目標

如果大家對這一點還有一些疑惑的話，可以繼續看后面給出的案例，細細體會

（3）系統是為他服務的嗎？

這個很好理解了，開發出購票系統當然是給購票者用的，所以購票者就是主角。

為什么要分業務主角和業務工人？

因為業務工人是為了幫助主角實現主角的期望，我們可以通過主角的期望推導出業務工人的期望，所以我們只需要找到所有的主角和主角的期望，再從主角的期望推導出業務工人的期望即可，有利于我們清晰的得到相關用例而不至于混亂。

繼續順著我們之前給出的案例做分析：前面我們已經確定了邊界是“簽約學員”，我們再通過上面給出的幫助尋找主角的三個問題來尋找主角：

1. 系統將要服務的人員，直接與系統交互；
2. 將來要通過系統做事的人；
3. 我們要實現的業務目標是哪些人的目標，是哪些人的期望， 這些人就是業務主角。

于是我們從涉眾列表中找到了這樣三個角色，銷售總監，銷售主管，課程顧問，又因為實際業務中銷售主管和課程顧問其實做的工作是完全相同的，可以把銷售主管理解為資歷比較老的課程顧問，所以我們現在將業務主角簡化為2個，銷售總監和課程顧問（行話叫CC）。

確定了主角后我們開始獲取業務用例：

4.1.3 獲取業務用例

什么是業務用例？

業務用例是為了實現業務目標而需要做的一件事或一項工作。

這里一定要注意的是，一個用例是主角對目標系統的一個愿望，一個完整的事件。為了完成這個事件需要經過很多步驟，但這些步驟不能夠完整地反映參與者的目標，不能夠作為用例。

最重要的區分方法是主角完成一個用例所描述的事件后一定有一個有意義的結果，而如果主角只是完成一個步驟的話，單從做完這一個步驟的結果來看是沒有任何意義的，只有做完一連串的步驟，才會有一個有意義的結果。

這點一定要注意，否則你在獲取業務用例環節會找出一堆的用例。

業務用例的作用：捕捉為了實現業務目標而需要做的具體的事件。

發現和定義業務用例的目的：

1. 了解客戶業務構成；
2. 確定業務范圍；
3. 是推導我們后續要講到的系統用例的前提條件。

如何找到業務用例：

獲取業務用例有很多方法，可以從崗位手冊、業務流程指南、職務說明等一些文件中獲得，也可以從涉眾分析中獲得靈感。但是最重要，最有效的方法，就是業務主角訪談，可以通過以下問題引導業務主角代表說出他們的業務需求：

• 您對系統有什么期望？
• 您打算在這個系統里做些什么事情？

（上面兩個問題的目的：發現用例）

• 您做這件事的目的是什么？
• 您做完這件事希望有一個什么樣的結果？

（上面兩個問題的目的：判斷這件事是否真的是用例還是只是一個步驟）

業務用例獲取什么時候結束？

作者的建議是不要追求完美，事實上也不可能有完美。只要感覺到已經把客戶的業務弄清楚了就可以考慮結束，而不必等到事無巨細的每件事都定義得清清楚楚。

繼續分析我們的案例：通過和業務主角進行訪談，我們了解到為了實現簽約客戶這個業務目標，銷售總監和課程顧問需要做下面這些事情。

說明：虛線框中的內容表示的是完成同一件事情的兩種不同場景，用術語來說就是業務用例實現。

至此我們的業務用例視圖模型就建立好了。

4.2 業務用例場景建模

什么是場景？

場景應該怎么理解呢？經常有朋友繪制完用例以后不知如何繪制場景，有朋友認為場景就是活動圖，也有朋友認為場景就是業務流程圖，這些理解都是不完全準確的。

用例，case的含義：

還是從用例說起，讓我們從詞義上好好理解一下。case 這個詞兒大家應該很熟悉， 一個商業項目可以稱為一個case：一個訴訟案件也可以稱為一個case；我們常說做事情要因地制宜，一件件的來，可以說case by case ?？梢?，case 這個詞兒表達的就一個個特定的事件。

用商業項目舉例講述場景：

既然是特定的事件，它必然包含有一個特定的目標、執行人和執行過程。執行人和執行過程，最終是為了達到這個特定目標。

以商業項目為例：最終目標是簽署商業合同，這其中牽涉到策劃、宣傳、調研、談判、法律等很多人和事。商業項目有其既定的程序，也就是按—定的順序來完成這些活動，最終達到商業目的是在正式開展商業項目之前，這個程序應該是被計劃一好了的，這稱之為一個方案，在建模來說，這就是一個場景。

商場如戰場，任何事情都可能發生，所以我們要做好多種可選方案，在建模來說，這就是多個場景。市場瞬息萬變， 再好的商業方案也不能一條道走到黑，當市場發生變化時，方案也要隨之做出調整，在建模來說，這就是分支過程。 另外，我們也不得不考慮到意外情況的發生，要做好應對措施，在建模來說，這就是異常過程。

場景的同義詞：因此，如果你對場景這個詞感到抽象，不好理解，完全可以將其被類比為做一個執行方案、一個行動計劃、一個演練或者一個彩排。

業務用例場景建模的目的：

1. 說明業務用例的執行過程，說明業務主角是如何使用業務用例完成業務目標的。
2. 了解每個業務用例是如何在沒有計算機的情況下實現的，然后推導出系統用例。

輸出：業務用例場景視圖。

用什么視圖繪制場景：繪制業務用例場景我們可以使用，時序圖，交互圖，或活動圖，但是最實用，必須要掌握的是使用活動圖來繪制業務用例場景，所謂活動圖，也就是我們經常見到的泳道圖。

繪制場景的兩個基本要求：

場景隱含著兩個基本要求：一是必須忠實于真實業務，二是一個場景只能描述業務的一種執行方式。也就是說，在描述業務用例場景時不能帶有“設計“思想在里面，或者試圖“抽象”和“優化“業務過程，它必須和客戶認可的實際業務執行一致。同時，不要試圖在一個場景里把業務的所有內容都包括進來，繪制出一幅充滿了判斷分支，像蜘蛛網一樣的活動圖。每一個場景只針對一種業務執行方式，應當清晰而明了。

繼續分析我們的案例：之前給出的每一個業務用例都對應著一個場景，所以在實際工作中我們應該把每一個場景都用活動圖畫出來，但是現在我們只用其中最復雜的一個場景“跟進線索”來舉例并繪制活動圖。

說明：

1. 在這個場景中，CC是業務主角，其他三個角色都是為了配合CC跟進線索從而實現簽約學員這個目標而服務的，整個過程的發起人也是CC，沒有CC，其他三個人就不會做這些事情，所以其他三個人都是業務工人，業務工人只應該出現在業務用例場景圖中，不會在業務用例視圖中出現，雖然這三個人的這些工作也為簽約學員這個目標作出了貢獻。
2. 在繪制業務用例場景時一定要注意的是要忠于實際業務。
3. 我們繪制的業務用例場景圖其實也就是我們平時所說的業務流程圖，是為了反映真實業務而繪制的圖，但是平時大家畫業務流程圖時有固定的章法嗎，是不是感覺按照文章中這樣從業務目標，業務用例，業務場景一步一步推導出來更加的嚴謹呢？

現在我們只畫了一個場景的，在實際工作中我們需要把所有業務目標下分析出的所有業務用例都對應畫出業務用例場景圖，不過有些場景比較簡單，流程比較短，我們也可以省略，這樣我們最終會畫出很多的業務流程圖，但是也不用擔心，畢竟系統是一點一點做出來的，圖也是一點一點畫出來的，至此當我們的業務用例場景圖繪制完畢后，我們的業務建模環節也就告一段落了。

第三篇《UML建模方法論（下）：系統建?！废到y建模也會在接下來的兩天內更新出來~

作者：一點優秀，教育行業產品經理，微信號：gentleman52520，歡迎交流

本文由 @一點優秀 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議