第5章 需求 之 系統用例圖
愛情不是你想賣，想買就能賣。
《愛情買賣》；詞：何欣，曲：周洪濤，唱：慕容曉曉；2009
讓我們把思考的邊界從組織縮小到要研究的系統。有了業務模組化的鋪墊，系統的用例圖已經呼之欲出，但是我們還是要先來講解一下系統執行者和系統用例的要點，再看看如何從業務序列圖映射出系統用例圖。
執行者和用例的概念在業務模組化的章節已經出現過。現在要研究的執行者和用例，與業務模組化時研究的執行者和用例相比，不同之處是研究對象，之前研究組織，現在研究系統。
5.1 系統執行者要點
系統執行者的定義：在所研究系統外，與該系統發生功能性互動的其他系統。
5.1.1 系統是能獨立對外提供服務的整體
封裝了自身的資料和行為，能獨立對外提供服務的東西才能稱為系統。不了解這一點，模組化人員很容易把“添加一些功能”當作“研發新系統”。如圖5-1所示，系統對外提供了某些服務，這些服務被分為A和B兩組，但不能說有A和B兩個系統。這個錯誤其實就是“從需求直接映射設計”的錯誤，如果沒有很好了解第1章所闡述的“需求和設計的差別”，模組化人員很容易犯這樣的錯誤。
圖5-1 錯誤：把功能分包當成系統
圖5-2中A系統和B系統各自封裝，通過接口協作，這種情況下可以稱為兩個系統（或子系統、元件）。
圖5-2通過接口協作的兩個系統
例如，模組化人員說“我們在做一個積分兌換系統”，畫出用例圖如圖5-3。
圖5-3 錯誤：胡亂劃分系統
實際上哪裡有那麼多系統，隻是同一系統上的功能分包而已，資料都是共享的。正确的用例圖應如圖5-4。
圖5-4 系統隻有一個
5.1.2 系統邊界是責任的邊界
系統執行者不是所研究系統的一部分，是該系統邊界外的另一個系統。這裡的系統邊界不是實體的邊界，而是責任的邊界。
現在大多數的軟體運作形态是分布式的。一個系統可能有一部分元件部署在移動終端，其他部分元件可能部署在不同實體位置的Web伺服器、應用伺服器等等，導緻模組化人員會不自覺地認為自己在做多個系統，然後針對每個部分畫用例圖。其實他所研發的隻有一個系統，上面這些元件都屬于系統的設計。涉衆根本不在意系統劃分成幾個元件以及元件之間如何分布和互動。模組化人員如果沒有學會從涉衆視角看問題，隻是從自己角度看問題，就會犯這樣的錯誤。甚至有的人根據研發團隊分幾個組來判斷目前在做幾個系統，說兩個就兩個，說三個就三個，根本不管在客戶眼裡人家要幾個。
嚴格來說，即使是“單機”的系統，運作形态也是“分布式”的，分布在CPU、高速緩存、主存、輔存等多個部位，網際網路可以看作更大的“單機”。
圖5-5 “分布式”沒什麼特别
如果根據責任來劃分邊界，那麼一個系統在所研究系統之外的意思是：實作它不屬于所研究系統的研發團隊的責任——可能是父母通過生物編碼實作，也可能是其他公司的程式員編碼實作。這意味着一個系統可以分布在多個實體位置，也意味着同一個實體位置可以存在多個系統。
手機裡裝了很多軟體，實體邊界似乎說不清道不明，但從責任上看，哪一段代碼是Google的程式員寫的，哪一段代碼是騰訊的程式員寫的，哪一段代碼是本公司的程式員寫的，清清楚楚明明白白。
圖5-6是一個通過實體位置來劃分系統的錯誤例子。做一個通過手機遙控電視的控制軟體，因為想到系統将來部署時可能會有一部分部署在手機端，另一部分部署在電視端。模組化人員按照實體位置把系統分為手機端、電視端兩個系統畫在業務序列圖上，映射到系統用例圖時，得到兩張系統用例圖。
圖5-6錯誤的遙控軟體用例圖
正确的用例圖應如圖5-7所示。
圖5-7 正确的遙控軟體用例圖
邊界越模糊，越需要執行者來幫助理清。有的模組化人員覺得自己所研發的系統“比較特别”，執行者很難界定，幹脆認為“執行者”不适合他們所研發的系統。仔細觀察可以發現，該人員所在團隊的成員對系統的責任範圍根本沒有形成共識，而且扯了幾個月了還是扯不清楚。這樣的想法相當于認為“把公雞殺了，天就永遠不會亮了”。
5.1.2 系統執行者和系統有互動
外系統必須和系統有互動，否則不能算是系統的執行者。
如圖5-8，一名旅客來到火車站售票視窗，告訴售票員目的地和車次，售票員使用售票系統幫助旅客購買火車票。這個場景中，和火車票售票系統互動的是售票員，他是售票系統的執行者，旅客不是。有的模組化人員碰到類似問題時會情不自禁地把旅客當作執行者，因為他覺得售票員是在執行旅客的指令（也許旅客又是執行其配偶的指令），或者覺得旅客比售票員重要，如果不把旅客當作執行者的話旅客的利益就會被忽略。
圖5-8 旅客不是售票系統的執行者
系統執行者和重要無關。系統執行者隻關注哪個外系統和所研究系統接口。這個外系統可能連人都不是，更談不上重要不重要了。從平時的工作和生活經驗我們也可以知道，當系統執行者當得最歡、整天和電腦手機打交道的人，多半不是什麼大人物，而是一線的打工仔，例如營業員、辦事員、客服等。大人物雖然偶爾也會用軟體系統看看報表，但更多時間恐怕不是敲鍵盤點手機，而是摸高爾夫球杆。
和重要有關的概念是涉衆。在上面提到的售票系統的“售票員→售票”用例中，旅客是很重要的涉衆，而且用例不止這麼一個涉衆。售票員在售票的時候，好多雙眼睛在盯着看呢。
| 旅客：擔心出錯票，更擔心拿到了錯票自己還不察覺；擔心票是打出來了，資訊卻沒有儲存下來；擔心指定日期沒那個車次的票… 售票員：擔心操作太複雜，一天下來手指麻木；擔心不好用，出錯票被扣錢… 火車站上司：擔心售票員玩忽職守，出錯票引起糾紛；擔心重複出票造成糾紛… |
用例必須在它的路徑、步驟和補充限制中考慮這些涉衆的利益。
火車票售票系統現在已經提供了旅客自行購票的接口，例如網際網路購票、售票機等。這種情況下，旅客也是售票系統的執行者，不過“售票員→售票”和“旅客→購票”是兩個不同的用例，它們關注的涉衆利益不完全相同，相應的需求自然也不同。旅客不是天天都買票，是以和旅客打交道的用例，互動界面可以淺顯一點，互動節奏可以慢一點，甚至可以賣賣廣告，而且要特别注意并發容量、網絡安全等問題；售票員一天要賣幾百上千張票，和售票員打交道的用例，互動應該直截了當。
接下來是一個經常引起争議的問題：還是以售票系統的“售票員→售票”用例為例，假設在售票員售票過程中，旅客前面也有一個界面向旅客回報他關心的資訊，比如餘票、目前選擇的票等，甚至還可以根據旅客的目的地播放當地旅遊景點的廣告。這種情況下，旅客是售票系統的執行者嗎？
依然不是，因為系統要完成用例不需要等待旅客的響應。旅客就算睡着了也不影響用例的完成。如果售票過程中需要旅客有意識地按鍵确認一下，否則票就出不來，那就不一樣了，旅客就成了售票系統的“售票員→售票”用例的（輔）執行者。
5.1.3 互動是功能性互動
上面說的互動還引出一個問題：假設售票員使用滑鼠和售票系統互動，按道理，比起售票員來，滑鼠離售票系統更近，為什麼不把滑鼠作為售票系統的執行者呢？還有，假設售票系統運作在Windows作業系統之上，那麼Windows是不是售票系統的執行者？
辨識的要點就是：執行者和系統發生的互動是系統的功能需求。如圖5-9上部的序列圖所示，售票員能自如地辨認并控制滑鼠，是因為她的大腦裡安裝了如何使用滑鼠的專家系統（可能是老師也可能是父母安裝的）。猴子的大腦裡沒有這個系統，是以它很可能看到滑鼠就一把抓起來往嘴裡送。滑鼠的移動和點選如何變成有效的輸入事件，則由作業系統（包含了滑鼠驅動程式）負責。以上這些互動都不是售票系統的核心域概念，售票員和售票系統之間的互動才是，是以售票員才是售票系統的執行者。
圖5-9 售票系統的功能需求
Windows也不會成為售票系統的執行者，因為售票系統和Windows之間的互動很可能隻是開發人員的設計，不是需求。涉衆隻是要求系統又快又好又穩定，并不在意作業系統用Windows還是Linux。如果涉衆明确要求作業系統必須是Windows，那麼Windows就會成為需求，但也隻是設計限制類型的需求，不會成為功能需求。
當然，如果所研究系統是滑鼠驅動程式，滑鼠會成為合适的執行者，因為這時和滑鼠之間的互動成為滑鼠驅動程式的功能需求。
5.1.4 系統執行者可以是人或非人系統
系統執行者可以是一個人腦系統，也可以是一個非人智能系統，甚至是一個特别的外系統——時間。在軟體業的早期，一個系統的執行者往往全部都是人。随着時間的推移，系統的執行者中非人執行者所占的比例越來越多。現在一個新系統上線，可能隻有一半的接口是和人打交道，另一半接口是和非人智能系統打交道。如圖5-10所示。
圖5-10 從“執行者都是人”到“執行者有一些是人”
用例的優勢在這裡得到了展現。用例技術中“執行者”和“涉衆”的概念，把演員和觀衆分開了。演員（執行者）在台上表演，觀衆（涉衆）在台下看，演員表演什麼是由觀衆的口味決定的，演員可以不是人，但觀衆肯定是人。演員如果是人類，那麼在觀衆席上也會有一個位置，不過在第幾排就不知道了。
用例使用“執行者”和“涉衆”代替了原來的“使用者”，這是一個非常大的突破。“使用者”這個詞混淆了演員和觀衆的差別。過去經常說“找使用者調研需求”，這是錯誤的。所謂“使用者”，就是上台表演的人類演員。找使用者調研需求，相當于找演員問劇本應該是什麼内容，豈不是很荒謬？劇本應該由編劇向觀衆調研編寫出來，然後由各路演員在台上演繹。
上面已經說過，在台上當“使用者”當得越歡的涉衆，往往在涉衆排行榜上排位越靠後。整天操作電腦搞得手僵脖子硬的“使用者”，有幾個是職位高的呢？真正位高權重的涉衆，雖然偶爾也會上台表演，但更多時候是坐在台下看戲。模組化人員如果過多地關注“使用者”，花在重要的前排涉衆身上的時間可能就不夠了。
像“使用者故事”這樣的方法在開發一些面向大衆的網際網路系統時還能應付，因為這類系統的執行者往往屬于前排涉衆。如果開發涉衆較多、利益沖突微妙的系統，應該采用用例這樣更嚴謹的需求技能。
越來越多的系統執行者不是人類，也就是說沒有“使用者”。兩個電腦系統互動的需求，難道就不用做了，或者可以随便做？非也。那隻是相當于上台表演的不是人，是功夫熊貓、變形金剛和喜羊羊灰太狼，但是台下對表演說好說壞的觀衆依然是人。建立“執行者和系統在台上表演，涉衆在台下看表演”的概念，在執行者為非人系統時對捕獲需求很有幫助。
5.2 【步驟】識别系統執行者
5.2.1 從業務序列圖映射系統執行者
如果沒有做業務模組化，識别系統執行者隻能靠頭腦風暴。可以思考類似下面的問題：什麼人會使用系統來工作？什麼人負責維護系統？系統需要和哪些其他智能系統互動？有沒有定時引發的事件？
有了業務模組化，就不需要頭腦風暴了，直接從業務序列圖映射即可。業務序列圖上，和所研究系統有實線相連的對象映射為所研究系統的執行者。圖5-11是某個房屋中介組織“尋找租客線索”的業務序列圖，從中可以看出，和線索管理系統互動（有實線相連）的有線索部經理、外呼人員、電信電話系統和CRM，它們就是線索管理系統的執行者。映射到系統用例圖如圖5-12。
本書為了講解需要，故意把系統執行者和系統用例分成兩次識别，此處隻識别系統執行者。實際工作中，系統執行者和系統用例是一起識别的。
圖5-11 業務序列圖：尋找租客線索
圖5-12 從業務序列圖映射得到系統執行者
圖5-12中執行者不再帶有斜杠，因為這時候研究對象是系統。有的執行者畫在邊界框左邊，有的則畫在右邊，是為了友善表達主執行者和輔執行者。這方面内容稍後再詳述。
本書不提供練習題答案，請掃碼或通路http://www.umlchina.com/book/quiz5_1.htm完成線上測試，做到全對，自然就知道答案了。
1. 以類似_______這樣的系統為研究對象時，“列印機”作為執行者是合适的。
A) Word
B) 财務報表系統
C) Photoshop
D) 列印管理器
2. 市民想給交通卡充值，來到營業點把錢和卡一起遞給營業員，營業員操作“充值系統”充值。針對“充值系統”的執行者，以下看法正确的是
A) 執行者應是市民，因為市民比營業員重要，而且營業員最終執行的是市民的指令。
B) 執行者應該是充值系統，因為充值由充值系統完成
C) 執行者應該是營業員，系統執行者與重要無關
D) 市民和營業員一起作為執行者
3. 根據以下業務序列圖，請問屬于“一卡通系統”執行者的是（可多選）
A) 外來辦事人員 B) 一卡通系統
C) 大院門口保安 D) 受訪人
E) 來車監控系統 F) 時間
4. 以下說法正确的是（多選）：
A) 業務執行者不一定是系統執行者。
B) 系統執行者一定是業務執行者。
C) 系統執行者一定是業務勞工。
D) 系統執行者一定要和系統互動。
E) 系統執行者一定是系統的涉衆。
F) 系統的涉衆一定是系統執行者。
5. 作為新一代的需求技術，用例用“執行者”取代了“使用者”，關于這兩個概念，以下說法正确的是（本題可多選）
A) 實際上是一回事，某些方法學家炒作概念而已。
B) “使用者”把演員和觀衆混在一起了。
C) “執行者”指的是“客戶”，比“使用者”更加值得關注。
D) “執行者”可以不是人，“使用者”預設是人。
E) “執行者”不一定直接使用系統，“使用者”一定直接使用系統。
F) “執行者”之間可以有泛化關系，“使用者”沒有。
6. 類似“使用者故事”之類的需求描述方式，在開發一些面向大衆的網際網路系統時還能應付，原因是：
A) 網際網路比較注重創新，使用者故事也比較注重創新。
B) 網際網路比較注重靈活，使用者故事更靈活。
C) 網際網路系統的“使用者”和前排涉衆重疊程度較高。
D) 故事的方式更适合和低學曆的大衆溝通。
5.3 系統用例要點
5.3.1 價值是買賣的平衡點
系統用例的定義：系統能夠為執行者提供的、涉衆可以接受的價值。和第3章的業務用例相比較，研究對象從組織變成了系統。要了解好系統用例，重點依然是之前所強調的買賣平衡點、期望和承諾平衡點。
以取款機為例，“儲戶→登入”不是它的用例，因為儲戶對取款機的期望以及取款機能做的承諾不隻是登入。或者這樣思考：取款機不能這麼叫賣：“來啊來啊！我這裡能登入啊”，然後儲戶就說“哇，真棒，這正是我想要取款機提供的服務，好，我去用一用”。
或者可以設想可能觀察到的場景：
張三要出差，發現身上沒現金，到取款機那裡取現金，然後離開取款機忙别的去了。
客戶給張三卡裡轉了5000元，電話請張三查收，張三到取款機那裡看看自己的卡目前餘額多少，腦子裡想想是不是比之前多了5000，然後離開取款機忙别的去了。
以上兩個場景在典型的業務流程中可以觀察到，而下面的場景就比較離譜了：
************，張三到取款機那裡登入，然後離開取款機忙别的去了。
是以，取款機正确和錯誤的用例如圖5-13所示。
圖5-13 取款機的用例
用例之前的許多需求方法學，把需求定義為思考系統“做什麼”，用例把需求提升到思考系統“賣什麼”的高度。這種思考是非常艱難的，因為它沒有标準答案，隻有最佳答案，而得到這個最佳答案不是靠拍腦袋，而是要通過揣摩涉衆得到。要得到合适的用例，需要有一顆善于體察他人的心。如果模組化人員總是習慣于從自己的角度想問題，那麼讓他思考“什麼是系統應該提供的價值”有時甚至會讓他痛苦到想要逃避，或者幹脆用功能、特性等模糊不清的詞語代替。
但是逃是逃不開的，生活中處處都需要這樣的思考。人們求職、求偶不就是要搞清楚“我”這個人腦系統應該賣給誰，賣什麼服務的最佳答案嗎？我會吃喝拉撒，你不願意為此給我報酬；你想要長生不老，我又提供不了這麼大的價值。要找到一個我能幹好而且你又樂意買單的平衡點，确實很難。
例如，“程式員”這個人腦系統為它的老闆提供的用例是什麼？安裝開發工具？編碼？為公司賺錢？答案是編碼，這是老闆對程式員的期望以及程式員可以提供的承諾的平衡點，或者說，這是程式員能賣，老闆願意買的價值。程式員不能因為裝了個Visual Studio就理直氣壯向老闆要報酬，老闆不給就生氣；程式員按要求編出了代碼，老闆就不能因為銷售部門不給力或經濟崩潰導緻賺不到錢而責怪程式員。正确和錯誤的用例如圖5-14所示。
圖5-14 程式員人腦系統的用例
程式員如果擺錯了自己的位置，沒有好好完成編碼的本職工作，反倒是動不動向老闆上“萬言書”，對公司的發展方向大放厥詞，老闆是不會喜歡的，因為他不期望從程式員身上“購買”這個服務（用某知名企業上司人的話說就是：有精神病就送醫院，沒精神病就辭退）。
可見，搞清楚自己的“用例”，認清自己的定位，對人生多麼重要。如果您不斷通過用例思維來思考系統的價值，就能訓練出越來越強大的發現價值的能力。無論打工還是創業，這種發現價值的能力都可以讓您受益。
5.3.2 價值不等于“可以這樣做”
回到上面取款機的例子，可能有人會“較真”了：什麼，你說沒有人會登入了就離開？我今晚下班就去取款機那裡登入一下就走人給你看！那麼我們來看看下面的例子：
電視台記者小崔經受着失眠的痛苦，經常精神恍惚。有一天晚上他在取款機取現金時，居然恍惚到把銀行卡往取款機一插就走開了。回家之後，發現自己可能會丢錢，心裡居然生出一種舒适感，過一會就安然入睡了。小崔嘗到這個甜頭後，幹脆睡不着時就跑到樓下取款機插一張卡，回家後果然酣然入睡。在小崔看來，千金難買安穩覺，這樣做是劃算的。
請問：如果世界上确實有小崔這樣的人，那麼插卡是取款機的用例嗎？
不是。理由：小崔不是取款機的目标執行者。雖然取款機無法防止小崔這樣做，但取款機被擺在大街上的初衷不是為小崔這樣的人這麼用的。當然，不排除有廠家看到“類小崔人群”的痛苦，分析背後的心理後，制造出面向“類小崔人群”的助眠專用取款機。那已經是另外一款産品了。
再看下面的例子。一個辦公系統，科員有兩個用例A和B。科長比科員級别高，是以除了自己的用例，還可以使用科員的用例。處長級别最高，想做什麼就做什麼，沒人敢攔着。是以，模組化人員畫出了圖5-15這樣的蜘蛛網用例圖，把執行者和用例的關系誤解成了權限管理。
圖5-15 蜘蛛網用例圖
用例的執行者隻是表明這個用例是為這一類執行者而做，但不代表系統一定要有權限控制以防止其他的人或電腦系統使用該用例。即使系統确實需要有權限控制，而且角色的劃分和執行者相近，也要把這兩者分開，更不可以因為系統不設權限控制，是以把執行者的名字合并為“使用者”。圖5-15應改成圖5-16。
圖5-16 明确用例為誰而提供
一罐可樂打開放在那裡，烏鴉路過也可以喝，可樂本身并沒有權限管理防止烏鴉喝它，但烏鴉仍然不是可樂的執行者，因為烏鴉不是可樂的目标客戶。
了解了上面兩個要點，經常被讨論的“粒度”困惑就不存在了。用例不是面團，任由模組化人員關在辦公室裡亂捏——“我覺得那個用例粒度大了，捏小一點，那個用例粒度小了，捏大一點”，你以為你爸是李剛，随便做點什麼都有人買單嗎？模組化人員隻能根據目标涉衆心中對系統的期望來确定系統應該提供什麼樣的服務。
有的書中給出“最佳粒度原則”，例如：一個系統的用例最好控制在××個之内、一個用例的基本路徑最好控制在×步到×步之間……這些是沒有根據的。市場需要各種各樣的系統，有功能衆多的也有功能單一的，有一步到位的也有互動複雜的。應該把屁股坐到涉衆那邊去，揣摩涉衆的心理，實事求是寫下來。不過，“粒度”、“層次”這些概念迎合了模組化人員的“設計瘾”，很容易誤導模組化人員。
如果模組化人員在粒度問題上熱烈争吵，糾纏不清，有可能已經犯了錯誤。最常犯的錯誤是把步驟當作用例。如圖5-17，右側的“驗密碼”和“扣除金額”其實隻是用例“取現金”的步驟（一眼可以看出其主語是系統），不是用例。Include（包含）關系也不是這樣用的。Include的目的是為了複用在多個用例中重複出現的步驟集合，形狀往往是多個用例Include一個用例。看到這種一個用例Include許多個用例的形狀，基本上可以判斷它犯了把步驟當作用例的錯誤。正确的做法是：把右側的“驗密碼”和“扣除金額”作為步驟寫在用例規約中。
圖5-17 錯誤：把步驟當作用例
5.3.3 CRUD用例的根源是從設計映射需求
打開一些用例圖，映入眼簾的用例是四個四個一組的。仔細一看，剛好對應了資料庫的四種操作。相當于把資料庫的各個表名加上新增、檢索、修改、删除就得到了用例的名字。很多用例書籍和文章都提到了這個典型的錯誤，有的模組化人員就學乖了，幹脆把每四個用例合并，改名叫管理××（或××管理），如圖5-18——可惜，依然是換湯不換藥。
圖5-18 從資料庫視角得到的用例
乍一看好像也可以了解。不管前面的業務多複雜，到資料庫這一層，不都是新增、檢索、修改、删除嗎？有位開發人員和我說過，“潘老師，我找到了抑制需求變更的好方法，把資料庫的表和字段當成需求不就行了嗎？業務變來變去，資料庫的表和字段是相對穩定的。”我還見到過這樣的軟體系統：在界面上把所有的“新增”功能都放在一起，根本不管這些功能是給不同的人在不同時間和不同業務流程中使用的。程式員肯定想“反正都是資料庫裡新增一條記錄嘛”。
問題在于：做需求的目的不是為了安慰自己或走過場，而是讓系統更加好賣。需求工作中，我們所寫的每一個字，所畫的每一張圖都必須對好賣有推動作用，否則還不如不做。是以即使再難，也隻能從涉衆的視角來定義需求，不能貪圖友善選擇一個自己熟悉的視角應付了事。如果允許應付了事，我還有更好的絕招：我就是程式，程式就是我。您問我，某某系統的需求是什麼？我回答：就是0和1的組合。對嗎？對得不得了。可惜，這種正确而無用的廢話，對做出好賣的系統沒有幫助。
圖5-19 從涉衆視角得到的才是用例
如何避免這樣的錯誤呢？老老實實去研究業務流程，做好業務模組化，盡量從業務序列圖中映射出系統用例，這樣得到的系統用例是不會騙人的。新增、修改、删除、查詢、管理、改變狀态……這些詞是資料庫的“鳥語”，不是領域裡的“人話”。業務流程中不會有人說，小張等一下，我到系統哪裡去做一下發票管理，隻會說，我去開一張發票，我去廢棄一張發票，我去開一張紅字發票……而且，這些事情以不同的頻率發生在不同的業務流程中。是以圖5-18的用例圖應該修改為圖5-20。
圖5-20 “說人話”的正确用例
還會有人有困惑。例如圖5-20的發票系統，可以猜想系統會儲存有開票員的資訊，那難道不能有“添加開票員”、“删除開票員”、“編輯開票員”等用例嗎？當然可以。關鍵是“系統應該有這個用例”這個結論是如何推導出來的。
因為資料庫裡有一個“開票員”表，是以應該有“添加開票員”、“删除開票員”、“編輯開票員”、“檢索開票員”等用例。這個思路是錯的。
當開票量較大而且需要即時開票時，如果隻有一個開票員無法應付，需要增加開票員，這樣就可以獨立開票而且明确責任，是以系統需要為管理者提供一個“添加開票員”的用例。這個思路是可以的，而且我們還可以看到這裡提到了領域知識，後面寫用例規約時尋找到的涉衆利益也豐富得多。
有些模組化人員懶得思考，幹脆一口咬定“有些系統用例就是在業務流程中無法展現”，這怎麼可能呢？認真思考、如實描述改進之後的業務流程應該是怎樣的，肯定能找到。系統都是在業務流程中起作用的，不會有人無緣無故突然就使用系統來做事情，沒有認真去觀察而已。
5.3.4 從設計映射需求錯誤二：“複用”用例
CRUD實際上就是從設計映射需求，導緻“複用”用例的一種情況。再看圖5-21的例子：
圖5-21 “複用”用例錯誤示例——缺陷管理系統
從不同的業務序列圖分别映射得到系統有右邊四個用例，但有的模組化人員會動起心思：這些實作起來不都是針對“缺陷”表來“Select ××× from 缺陷 where ×××”嗎，合并成一個用例“檢索缺陷”（CRUD來了）多好！于是得到左邊的結果。實際上，右邊這四個用例面對的執行者不同，背後的涉衆利益也有差别。
用例是涉衆願意“購買”的、對系統的一種“用法”，隻要涉衆願意“購買”，當然是越多越好。同樣的制作材料，變出更多可賣的價值，說明您的設計能力強，制作成本低，何樂而不為？
可惜模組化人員經常會犯傻，不自覺地合并用例，相當于告訴涉衆說，你真笨，你買我這些功能，其實我隻用了同樣幾個類靈活組裝出來。幹脆，你成本價把我的零件買走，自己去組裝吧！首先，研發團隊這邊賺不到錢；其次也是更關鍵的是：顧客是不樂意買的，因為市場有分工，顧客有他自己最值得做的事情做，否則他幹嘛不幹脆自己開個廠組裝賺錢？
說到這裡，可能有人就會說了：哇，這樣的話我故意把用例搞多一點，搞他1000個用例，那不是亂套了？——“我爸是李剛”的感覺又來了，用例是你搞出來的嗎，是客戶樂意“買”才有的。如果說真的按照“賣”的思路去找，确實是這麼多，那是好事來着！事實上，往往用例的大量膨脹根本不是因為這個，而是因為模組化人員把很多不是用例的步驟當成用例畫出來了！
害怕用例多了會導緻工作量大增，背後可能隐藏着這樣的問題：研發團隊做分析設計時缺乏循序漸進的抽象能力，隻會把需求直通通地映射，是以害怕用例變多，或者在發現“此處似乎可以抽象”時害怕此時不抽象以後就忘記了。研發團隊分析設計能力不足，會反向損害需求的品質，進而損害系統在市場上的競争力。
我們來看現實生活的例子。面館老闆的賺錢之道是用少量的材料（設計元件）靈活組合出不同的需求（用例）賣給不同的顧客。同樣是以面粉、肉、菜為主原料，面館就可以做出許多的“用例”：饅頭、包子、花卷、燒餅、餃子、馄饨、鍋貼、燒麥、春卷、油條、發糕……拉面、刀削面、擀面、擦面、哨子面、扯面、油潑面、擔擔面、拌面、焖面、面疙瘩、揪面片、手擀面、拉條子、炒面……臊子面、沙茶面、茄丁面、酸菜面、雞蛋面、蝦仁面、牛肉面……
我去面館就餐，點了一碗馄饨。過了一會，老闆端來一碗餃子。我說，“老闆，這是餃子，不是馄饨！”老闆肯定不能嘲笑我，“笨，餃子和馄饨98%是一樣的，都是面粉和肉菜的組合，制作工藝也差不多，你就将就着吃吧！”，要是這樣我會扭頭就走，到隔壁吃去了。老闆可以把餃子端回後廚，經過快速分解，重新組合，幾分鐘之後餃子變成了馄饨，然後又端出來給我。我并不了解馄饨哪裡來的，隻要味道比隔壁的好，價格又公道，我就吃呗。
遺憾的是，許多研發團隊沒有能力低成本把餃子變成馄饨，而倒掉重做一鍋成本又太高，隻好哄顧客“其實你要的就是餃子”、“我們的馄饨就是這個特點”。顧客第一次可能會将就，下次就不再光顧了，畢竟街上的面館不止你這一家。
講到這裡，就要來說一個需求的基本要點：需求不考慮“複用”，如果在考慮“複用”，要警惕自己是不是已經轉換到了設計視角來思考問題。
再舉幾個類似的"複用"用例錯供參考。
圖5-22犯的錯誤和圖5-21一樣。因為最終結果都是導緻資料庫的“保單”表裡增加一行，模組化人員幹脆讓幾個執行者共用一個用例“新增保單”。
圖5-22 錯誤：因資料庫都是添加保單記錄而“複用”用例
正确的用例圖如圖5-23。
圖5-23 正确的用例圖
客戶在家裡通過網絡投保，操心的是“可别上當”；客戶代表錄入自己代理的客戶的保單時，操心的是“傭金要高”；内勤面對堆積如山的待錄入保單，操心的是“省力一點”。從“賣”的角度來看，這是系統的三種不同用法，背後的涉衆利益不同。不能用“都是往資料庫的保單表裡插入一條記錄啊”這樣的理由合并而抹殺其中的差别。
下一個錯例如圖5-24。因為顧客、店員和經理都參與了退貨的流程，幹脆共用一個用例“退貨”。
圖5-24 錯誤：因為參與同一業務流程而“複用”用例
正确的用例圖如圖5-25。
圖5-25 正确的用例圖
圖5-17、圖5-22和圖5-24的錯誤用例圖有一個共同點：多個執行者指向同一個用例。如果已完工的用例圖不應該出現這樣的形狀，如果出現，可以有兩種修改方法。要是我們揣摩系統的這個用例針對這幾個執行者來說并無差別，就泛化出抽象的執行者，或者不需要泛化關系，直接用單個更合适的執行者代替；反之，如果對不同執行者來說有差別，就把該用例分成幾個不同的用例。後一種往往更常見。如圖5-26所示。
圖5-26 出現多執行者指向同一用例時的修改
5.3.5 系統用例不存在層次問題
系統用例的研究對象就是某特定系統，不是組織，也不是系統内的元件。如果存在“層次”上的疑惑，背後的原因是研究對象不知不覺改變了。
像醫院資訊系統的用例，有人會畫成圖5-27，原因可能是前面沒有畫業務用例圖和業務序列圖，是以模組化人員頭腦裡不知不覺把醫院資訊系統的價值和醫院的價值混在一起了。
圖5-27 錯誤的“高層”用例：混淆組織的價值和系統的價值
再看圖5-28中的防汛系統用例圖，把系統的願景當成“高層”用例了。
圖5-28 錯誤的“高層”用例：把願景當作用例
以上錯誤是因為缺少業務模組化導緻研究對象不知不覺改變。下面的錯誤更常見——為系統的“子產品”畫用例圖。如圖5-29，模組化人員覺得系統的用例比較多，是以把用例分了包，認為“記錄出車”、“記錄違章”等是“車輛管理子產品”的用例。
圖5-29 錯誤：子產品的用例
圖5-29是錯誤的。用例很多時可以将用例分包，但用例包是從外部對系統用例所做的分包，裡面的用例依然是系統的用例，不是用例包或“子產品”的用例。正确的圖如圖5-30所示，用例包的命名保留領域詞彙即可，删掉“管理”、“子產品”等字眼。
圖5-30 用例仍然是系統的用例
圖5-29的錯誤實際上就是第1章提到的“從需求直接映射設計”的錯誤，從外部（功能分包）直接映射内部（構成元件）。我們可以說吃喝拉撒是“人”的功能，但不能說是“吃喝拉撒子產品”的功能。從内外兩個角度分割系統是有差別的，如圖5-31所示。
圖5-31 内外分割系統的差別
上面說的是内外不分的情況。假設模組化人員已經清楚内外的差別，他了解的子系統确實就是子系統。那麼，可不可以如圖5-32為子系統畫用例圖，友善分包給研發團隊各小組開發？
圖5-32 可以這樣畫子系統的用例嗎？
答案仍然是否定的，理由是：客戶找你買的是整個系統，他不關心内部分成幾個子系統以及它們之間如何協作，這不屬于需求。如果要表達這些内容，可以用類圖、序列圖、元件圖等表達，不需要用例圖。
經常在這個地方“我爸是李剛”的思想又冒頭了——如果我在研發團隊内部把它當成幾個獨立系統來開發，那麼分别畫用例圖不行嗎？假如您看到這裡，也剛好冒出這樣的想法，原因可能是還沒有學會從賣的角度看需求，那麼真應該從頭在閱讀本書。要是反複閱讀了還是無法了解，有可能您真的是“我爸是李剛”，也有可能您不适合做需求工作，本書不必再看下去了。
5.3.6 用例的命名是動賓結構
用例的命名是動賓結構，例如“取款”。動詞前面可以加狀語，賓語前面可以加定語，把一句話的主語砍掉，剩下的可以作為用例的名字。
起名時要注意弱動詞。用例之前的需求技術，可能是以“名字+動詞”的形式命名系統的功能，例如“發票廢棄”，後來要改成用例的動賓結構了，有的模組化人員就在前面加一個弱動詞“進行”，就變成了“進行發票廢棄”，這個也是不合适的。
如果“名詞+動詞”已經成為行業中的一個術語，也未必要嚴格的動賓結構。例如“成果分析”在某行業是一個術語，也就不必硬要倒過來變成“分析成果”了。
本書不提供練習題答案，請掃碼或通路http://www.umlchina.com/book/quiz5_2.htm完成線上測試，做到全對，自然就知道答案了。
1. 以取款機為研究對象，“登入”不是用例，但是，以_____這樣的系統為研究對象時，“登入”作為用例是合适的。
A) 支付寶
B) 指紋掃描器
C) 門禁
D) OA系統
2. 以取款機為研究對象，“輸入密碼”不是用例，但是，以_____這樣的系統為研究對象時，“輸入密碼”作為用例是合适的。
A) 密碼保險箱
B) 支付寶
C) 門禁
D) 指紋掃描器
3. 經過連續八輪不勝，穿着綠色球衣的主隊終于2:1險勝客隊。主場球迷小張興奮至極，從球場出來後經過街邊一台取款機時，掏出一把鑰匙在取款機外殼刻了幾個字“**永遠争第一”。請問，“刻字”是不是取款機的用例？
A) 是。沒有人強迫小張，這是他自願做的。
B) 不是。用例應該是“支援球隊”。
C) 不是。取款機擺在那裡的初衷不是為了讓人刻字。
D) 不是。小張并沒有從刻字獲得任何好處。
4. 員工小張每天早上到辦公室第一件事就是打開電腦，登入辦公系統後掃兩眼今天該做的事情有哪些，然後就離開電腦做事情去了。以辦公系統為研究對象，以下說法正确的是：
A) “登入”不是用例，用例是“檢視當日任務”。
B) “登入”不是用例，因為小張不登入也可以看到自己的任務。
C) “登入”是用例，因為小張登入後已經達到使用系統的目的，然後離開了。
D) “登入”是不是用例，應該按照辦公系統的研發團隊在開發時劃分子產品的情況而定。
5. 我們經常會聽到有人說“系統分為幾個功能子產品”。針對“功能子產品”，以下說法正确的是：
A) 它把外部和内部混在一起了。
B) 它可以看作是用例的一種分包。
C) 它相當于系統的内部元件。
D) 它相當于系統的低層用例。
6. 主執行者和輔執行者的差別是
A) 主執行者直接和系統互動，輔執行者間接和系統互動
B) 主執行者發起用例，輔執行者被動參與
C) 主執行者發送資料，輔執行者接收資料
D) 主執行者是人，輔執行者不是人
7. 為了保障學校的安全，學校安裝了監控系統。系統按照一定的頻率不停拍攝訪客的影像，顯示給坐在監控室裡的保安看。根據以上描述，最合适的用例圖是：
A)
B)
C)
D) 主執行者是人，輔執行者不是人
8. 根據以下業務序列圖，請問屬于“一卡通系統”用例的是（可以多選）
A) 外來辦事人員→登記
B) 一卡通系統→判斷黑名單
C) 大院門口保安→記錄來訪人員資訊
D) 受訪人→确認來訪
E) 來車監控系統→儲存車牌資訊
F) 時間→檢查是否來車
9. 以下用例圖的錯誤應該如何改正？
A) 送出維修單資訊是客服的責任，應該删掉
B) 将<<include>>箭頭方向反過來
C) 右邊四個隻是步驟不是用例，删掉
D) 标出各用例的先後順序
E) 将<<include>>改成<<extend>>
F) 将右邊四個放在下一層次用例包中
10. 以下形狀中，哪些是已完成的用例圖可以出現的？（多選）
A)
B)
C)
D)
5.4 【步驟】識别系統用例
業務序列圖中，從外部指向所研究系統的消息，可以映射為該系統的用例。我們從圖5-11的業務序列圖上找出從外部指向“線索管理系統”的消息，如圖5-33所示，然後映射成“線索管理系統”的用例圖，如圖5-34。
圖5-33 在業務序列圖上找到從外部指向所研究系統的消息
圖5-34 從業務序列圖映射得到系統用例
圖5-34的用例圖中，有的箭頭是從執行者指向用例，這樣的執行者稱為用例的主執行者，有的箭頭是從用例指向執行者，這樣的執行者稱為用例的輔執行者。主執行者主動發起用例的互動，輔執行者在互動的過程中被動參與進來。UML标準中，執行者和用例之間沒有要求使用箭頭，但我認為加上箭頭表示主輔執行者是有意義的，建議還是加上。
輔執行者這個概念是被誤用比較多的。最常見的錯誤是把資訊的接收者或者将來可能使用資訊的人當成輔執行者。還是以圖5-34中線索管理系統為例，有人可能畫成圖5-35，因為他認為線索部經理使用線索管理系統配置設定名單給外呼人員，箭頭代表資料的流動方向，是以畫一個箭頭指向外呼人員。
實際上，箭頭代表的是責任配置設定，圖5-35的意思是：線索部經理使用線索管理系統配置設定名單的過程中需要外呼人員的幫忙，如果外呼人員睡着了沒有響應，用例的目标就受到影響。顯然，這不符合事實，是以，外呼人員不是“配置設定名單”用例的輔執行者，應該從圖上删掉它。
圖5-35 錯誤：把可能會用到所産出資訊的人當作輔執行者
另一種輔執行者的誤用剛好反過來，把資訊的來源當作輔執行者。如圖5-36，模組化人員認為外呼人員要想使用線索管理系統來檢視本人當天名單，“依賴于”線索部經理事先配置設定好名單。這同樣是錯誤的，在用例進行過程中不需要線索部經理的參與，是以，線索部經理不是“檢視本人當天名單”用例的輔執行者，應該從圖上删掉它。
圖5-36 錯誤：把提供用例所需資訊的人當作輔執行者
以上錯誤的原因很多是因為前面沒有畫業務序列圖，導緻模組化人員在畫系統用例圖的時候産生焦慮，總是希望在圖上多放一些資訊，以免自己忘記了。
一般來說，輔執行者是非人智能系統的情況較多，人腦系統作為輔執行者的情況比較少，是以碰到輔執行者是人的時候，要多留心。
圖5-37展示了輔執行者是人的例子。營業員使用營業系統為顧客辦卡，在用例互動過程中，需要顧客配合輸入賬戶密碼，否則辦卡用例不能成功，這時顧客是合适的輔執行者。
圖5-37 合适的輔執行者