第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) 故事的方式更适合和低學曆的大衆溝通。 |
《軟體方法》其他章節：
http://www.umlchina.com/book/softmeth.htm