開啟獲取需求的大門——用例圖繪製指南

1.前言

1.1.簡介

使用UML繪製用例圖是表現系統需求的一種方式，是分析獲取需求的一種有效手段。用例圖是瞭解系統的第一個關口，通過用例圖可以知道系統有哪些角色，這角色通過系統能做什麼事情。在用例圖中，會體現與系統互動的參與者、功能模組，以及系統工作的基本流程等。站在客戶的角度上看，用例圖是他們業務領域的邏輯化表達方式；站在軟體供應商的角度上看，用例圖是系統藍圖和開發的依據，這說明用例圖在軟體制作的期間很好的起到了承上啟下的作用。儘管它通常不會展現細節方面，但它是一個可以用於溝通複雜想法的好方式。

1.2.主要元素

1.4.目的

本篇希望作為一篇面向實用性的指南，其目的是為了能夠幫助初學者，快速掌握用例圖的基礎知識和繪製方法，以便於用於實踐中，在實踐中不斷的感悟。另外的一個目的則是作為查閱手冊，如果在實際的工作中遇到了比較模糊的地方，可以通過本篇文章快速查閱回顧知識點，以便解決實際的問題。接下來，本篇將根據用例圖的主要元素逐一展開講解，講解每個元素時，會採用理論和範例並行的講解方式，以便於在每個元素的使用場景上，能夠加深對元素概念的理解。

2.系統邊界

2.1.概述

在UML的用例圖中，我們通常將系統邊界視作我們構建的軟體系統，它可以是網站、軟體元件、業務流程、App等應用程式，亦或是你要開發的任何東西。系統邊界作為用例圖中的元素可以用一個矩形來表示，其名稱位於矩形內的頂部。系統邊界使用矩形元素，實際上僅僅是一個表現形式，它在有些應用場景中甚至是無形的。從概念上來說它屬於一種分析方法，通過邊界可以決定看待系統的抽象層次和視角，進而排除邊界外大量的雜音來降低複雜程度，從而界定系統的範圍，知道系統能幹什麼，系統不能幹什麼。

確定一個邊界，就好比如你決定採用什麼方式來介紹一個事物一樣。人體的器官大約有315個，如果不設定邊界，那麼你介紹器官的時候就會毫無條理、天馬行空。介紹內臟器官（心、肝）的時候一下就跳到介紹外部器官（耳、鼻），到最後聽你介紹的人根本搞不清楚你講的重點。因此，我們需要通過設定邊界，將我們所講的事物確定在同一個領域範圍，並且事物的粒度要保持相同體量。還是回到人體器官上來，如果設定的邊界是內臟器官，此時我們的視角必然在身體內部，抽象出來的事物都屬於該邊界內同粒度的器官（心、肝、肺等）；如果設定的邊界是外部器官，那麼我們的視角必然在身體外部，抽象出來的事物都屬於該邊界內同粒度的器官（眼、耳、鼻、嘴等）；

沒有邊界的地方將會是混沌的，例如你去一所學校去找人，如果學校沒有設定邊界，那麼你找人就像是「大海撈針」，因為所有人都交織在一起。如果學校根據不同領域設定邊界，那麼學校內部就會規劃為：教室、辦公室、圖書館等等區域。那麼此時你找人就不會在茫茫人海中尋找，而是可以針對性有範圍的找，比如找學生可以去教室，找老師可以去辦公室。一個全新的軟體專案對我們來說，也是混沌的，需要我們設定邊界，才能從混沌走向清晰。

總的來說，通過邊界的劃分會影響到我們觀察的事物，從而就決定了抽象層次和視角，使得我們分析事物的粒度可以保持統一，並且讓系統的作用範圍更加清晰。邊界和物件導向同樣都屬於軟體設計領域中的內功，我們並能奢望一朝一夕就將其掌握，我們先做到一個初步的認識，然後在日後的實踐中不斷去感悟和學習。

2.2.範例背景

本文用於講解用例圖使用的應用場景，是來自日常通勤的共用單車。本文將使用共用單車的軟體系統作為範例，以此來展開用例圖的繪製，我會根據用例圖中元素的使用特點，選擇其中常用的功能（掃碼用車、鎖車、付款、退押金）作為素材。在繪製之前，希望大家腦補一下你使用共用單車通勤的場景，這有助於理解其中的業務需求，以便我們有針對性的繪製相應的用例圖。由於這是根據現實生活中已經存在的應用，來反向推匯出與之對應的用例圖的情況，所以我們可以直接將共用單車的軟體視為系統邊界，並將其命名為「共用單車騎行系統」。

3.參與者

3.1.概述

參與者在UML用例圖中是由一個「火柴人」來表示。UML官方對其的定義是：「參與者是在系統之外與系統互動的某人或某事物」。參與者不是系統的組成部分，所以它處於系統的外部。參與者通常是一個使用系統的人，但有時也可以是一個外部系統或外部因素、時間等外部事物。參與者對系統有著明確的目標/願望，並且希望通過與系統互動所產生的結果，可以它的實現目標/願望。由於參與者必須與系統進行互動，因此可以從這個角度去分析獲取那些候選的參與者。

具體來說，識別參與者可以參考以下幾個思路：

系統會被哪些部門使用。這些使用系統的部門使用者，可以根據共同的職責提煉出一個參與者。
誰向系統提供資訊、使用或刪除資訊。對系統資訊進行管理的人員也會作為參與者與系統互動。
誰與系統的需求有關聯。因關聯被動參與到需求的事物，也可能會作為參與者使用到系統中的相關功能。
誰對系統進行維護。日常的維護業務也需要參與者與系統進行互動來完成。
與外部系統是否有互動。這些外部系統往往會成為參與者。
時間參與者，如一些具備定時功能的元件，它會啟用哪些系統定期的、自動執行的業務。

在參與者當中還會分為主要和次要的參與者，主要參與者是主動發起了對系統的使用，通常繪製在邊界的左側；次要參與者與系統的互動是被動的，通常繪製在邊界的右側。例如對於某公司的工資管理系統，公司財務負責人會主動發起工資的發放操作，但實際的資金轉移需要銀行來介入完成，這其中財務負責人就是主要參與者，而銀行由於工資的發放從而介入系統的互動，所以銀行屬於次要參與者。

參與者代表的是特定型別，而不是代表的具體的人或物，參與者相當於根據人或物共同職責提煉出的某類角色。所以在為參與者命名時需要注意，不要定義為某個具體的人或物（張三、發財銀行），而是應當定義具有代表性的名稱（客戶、銀行）。

3.2.範例

當我們去分析一個系統時，不應直接從系統本身具備的功能開始思考，我們應當先思考系統會為誰提供哪些價值，有哪些參與者會與這個系統進行互動來實現目標，因為系統的價值就體現在為參與者實現目標上。對於本範例的「共用單車騎行系統」而言，它可以提供單車的使用為人們帶來交通的便利。作為使用者，他能夠通過系統得到單車的使用。在這個分析中，很明顯，騎行者是對該系統有著明確目標的人，並且他屬於系統外部。所以可以將騎行者定義為「共用單車騎行系統」的參與者。

為了引出主要和次要參與者的使用場景，我們來思考下退押金這個業務。共用單車公司通過繳納押金的手段保證單車在一定程度的安全，作為騎行者而言，在沒有單車使用需求的情況下，可以要求公司退押金。由於「共用單車騎行系統」中沒有包含公司的資金業務，所以該系統想要實現騎行者退押金的目標，必須依靠公司另外的財務系統。當騎行者發起退押金的操作時，「共用單車騎行系統」會向外部的財務系統傳送申請，押金最終會由財務系統打到騎行者的銀行卡上。

對於這個退押金業務場景而言，騎行者是主動發起對系統的使用，而財務系統與系統的互動是被動的。只有騎行者做了一些事之後，財務系統才會參與到系統中來採取相應行動。綜上所述，該業務其中的主要參與者是騎行者，次要參與者是財務系統。下面將這兩個參與者補充到本範例的用例圖中。

5.5.用例的泛化

簡介

泛化關係相當於物件導向三大特徵之一的繼承，該關係可以用於在用例之間或參與者之間。用例和參與者之間的泛化都表面了一種繼承層次，通過繼承層次，繼承派生出的子項可以獲得上層項中全部屬性和行為，並參與上層項中的各種關係。因此，通過泛化關係可以在用例圖中達到更大範圍、高層次的需求複用。

在用例之間的泛化關係當中，父類別稱為泛化用例，子類被稱為特化用例。泛化用例中描述通用行為，而在特化用例中繼承這些通用行為，並在適當地方進行特化。在實際中，泛化用例往往作為抽象用例，這代表它不會產生任何具體的場景範例，僅作為抽象標準（類似介面），參與者只會通過執行特化用例來實現目標。

在實際中，包含關係在用例之間的關係中應用的最多，再者是繼承關係，而泛化關係用的最少。因為對於客戶而言，由於它們往往缺少物件導向的知識，所以難以理解其中的概念。如果僅僅為了將用例之間的可複用部分或用例的可延伸部分描述出來，那麼使用包含關係和擴充套件關係就足夠了，使用用例的泛化很可能增加用例圖的理解成本。

範例

在本範例「共用單車騎行系統」中，我們可以發現付款用例實際上是很寬泛的，因為付款的方式有很多，可以是：賬戶餘額、支付寶、微信、花唄等等方式。所以付款用例代表了一般情況，我們可以將其作為抽象用例，從它身上特化出具體的付款用例。泛化關係是用一條帶空心箭頭的直線表示的，箭頭的方向由特化用例執行泛化用例。下面我們將這個用例的泛化補充到當前範例的用例圖中。

5.6.參與者的泛化

在上文介紹用例泛化的基礎上，在來介紹下參與者之間的泛化是如何運用的。與用例的泛化一樣，參與者之間的泛化也是屬於一種繼承層次，同樣是滿足於更高層次的需求複用，只不過參與者的泛化在實際中使用的更多些。

我們針對本範例的「共用單車騎行系統」，思考這樣一個情況：如果系統要在普通使用者的基礎上推出一個VIP使用者，並且VIP使用者具備普通使用者所有的行為能力，那麼在繪圖時，VIP使用者是不是要將普通使用者的用例和關係都重複畫一遍呢？如果是，那麼後面如果有N個高層級使用者加入，是不是都需要將普通使用者所有的用例都要重複畫一遍呢？顯然這種重複性會讓用例圖的重複度和複雜度會大大提示，從而不堪入目。

對於上面的情況，就屬於我們在參與者中使用泛化關係的場景。通過建立普通使用者和VIP使用者之間的泛化關係，VIP使用者將基礎普通使用者的所有行為，所以在將VIP使用者作為參與者繪製到圖中時，就無需重複的繪製他和普通使用者之間存在的共同用例和關係。

在實際的應用中，我們也應當對所有參與者進行共同性的分析，共同性體現為，多個參與者存在相同的用例。如果存在共同性，我們應當抽象出一個「父類別」參與者，其參與者都直接或間接基礎這個「父類別」參與者。參與者之間的泛化關係也是使用帶空心箭頭的直線表示的，下面我們將VIP使用者和它特有的用例補充到圖中。

6.實踐建議

在客戶能準確全面的基礎上，用例越精簡越好。
用例應使用客戶的語言，需保證客戶能看懂，而不應參與技術性的描述。
在表達用例時要注意輕重之分，對於重點難點用例可通過註釋加以詳述，對於「常識」的用例則可簡言。
用例的粒度應當在同一個系統邊界中保持相同的體量。
不應盲目地從客戶無邊界的想法中直接獲取用例，用例更多地是從客戶對系統的目標中推導，且在系統邊界之內。
用例圖只是一種表現形式，掌握用例圖所承載的需求分析方法才是關鍵。

7.結語

繪製用例圖其實是件很容易的事情，只要你知道每個元素代表的符合，就能照葫蘆畫瓢的繪製出來。但是難點在於其中每個元素都蘊藏著很多複雜的概念，如識別參與者、分析系統邊界、分析用例、定義關係等，這些往往是需要經過一定的系統學習和掌握其中的概念才能做好的事情。所以比起繪製方式而言，更重要的是分析能力和實踐運用能力。

用例圖的構建，對於獲取需求而言，是非常有效的手段。而清晰明確的需求對於一個軟體專案的重要性，毋庸置疑。所以學會用例圖將會是你在獲取需求道路上披荊斬棘的利器。