本篇文章承接上一篇文章：《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建模方法論（下）：系統建模》系統建模也會在接下來的兩天内更新出來~

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

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

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部