使用案例圖的UML風格指南

許多專家學者認為，如果把UML2的十三款圖簡化一下，大概會剩下三款圖，使用案例圖是其中一款，另外雀屏中選的兩款圖分別是類別圖和循序圖。

使用案例通常用來表達系統的功能觀，它的組成元素很簡單，就是「使用案例」（use case）、參與者（actor）和兩者之間的關係線。簡單來說，使用案例代表系統對外提供的服務或功能，而參與者則是位於系統外部，會直接接觸系統並啟動使用案例的使用者，或者是支援使用案例的其他連線系統。

請看到圖1的範例，這是一張自動櫃員機（ATM）的使用案例圖。圖中的人型圖示便是代表位於自動櫃員機外部的參與者，顧客會啟動使用案例，以便獲取系統提供的服務；至於，銀行主機則是連線系統，它扮演支援角色的參與者，會與自動櫃員機保持連線，提供立即性的支援。在這張圖中，橢圓代表使用案例，此處我們僅繪製出三個使用案例，分別為：查詢餘額、提款和轉帳，代表自動櫃員機對外提供的三項服務。

原著書中關於使用案例圖的指南共有二十九條，編號由58到86，共分為四組：使用案例、參與者、關係和系統範圍，所以我們接下來會依此分為四個次小節，本期先介紹前兩節共十一條指南。

使用案例
使用案例採用橢圓圖示，它的名稱可放置於橢圓內部或外部下方，通常用來表示系統對外提供的服務或功能。跟使用案例有關的指南不多，只有三條，分別說明如下：

指南58 以「強動詞」作為使用案例名稱的起頭（Begin Use-Case Names with a Strong Verb）

指南59 使用領域術語為使用案例名稱（Name Use Cases Using Domain Terminology）

使用案例名稱以動詞為首，這是我們在實務上或教學上經常告訴學員的，不足為奇。系統啟動使用案例時，是在「做事」，使用動詞為首才能夠突顯系統在動作。

老實說，我是直到看到這一條指南，才發現它提到「強」（strong）這個形容詞。也就是說，有相對於強的「弱動詞」（weak verb）了。我不知道怎麼分辨強弱，不過原著作者在書中倒是有提到，諸如「處理」（process）、「執行」（perform）、「進行」（do）這些動詞都是屬於較不明確的弱動詞，請你比較圖2和圖3在使用案例名稱上的不同。

雖然，我還是無法得知如何區分強動詞與弱動詞，不過可以從上述的範例中發現，「處理」（process）、「執行」（perform）、「進行」（do）這些動詞似乎比較不特定，隨意替換也無所謂，如下：

● 「執行」餘額查詢，換成「處理」餘額查詢。
● 「處理」提款交易，換成「進行」提款交易。
● 「進行」轉帳動作，換成「執行」轉帳動作。

這樣一分析下來，就覺得確實使用強動詞會比弱動詞明確多了。在實務上，我也常見團隊成員以「管理」、「維護」這些動詞為使用案例名稱的起頭，我總覺得這些詞很不明確，會請成員或學員少用。如果套用這條指南的話，這兩個詞或許也可以歸類為弱動詞。

至於，在為使用案例命名時，盡量使用領域術語，那是因為使用案例圖通常用來捕捉系統需求，所以很可能會拿它來跟使用者溝通需求。因此，以使用者慣用的領域術語命名，會比用開發人員慣用的科技術語來得容易理解與溝通。

指南60 以使用案例的堆放順序「暗示」其發生時間（Imply Timing Considerations by Stacking Use Cases）

通常，使用案例的擺放位置並沒有特別的涵義，可是這條指南卻建議我們，可以用使用案例堆放的順序來暗示發生的時間順序。

例如，我們如果在一般的線上購物網站購物，執行使用案例的順序大抵會是先瀏覽商品、然後將打算購買的商品加入購物車、接著登入會員、最後才會結帳，所以我們可以依照這樣的順序由上而下堆疊使用案例，如圖4所示。

不過，有些會員可能習慣一開始就會先登入會員，接著才會去進行瀏覽商品等等的動作，這種情況下，使用案例的執行順序就跟圖4的堆疊順序不同了。也就是因為如此，這條指南說可以使用堆疊順序「暗示」（imply）執行順序，它並非是固定的執行順序。

如果，你在實務上想用這條指南的話，或許可以拿堆疊順序來暗示出現頻率最高的執行順序。不過，切記，UML並沒有對使用案例的位置做這樣的規定，你可以在你帶領的專案中使用這條指南，但是當你看到其他人繪製的使用案例圖時，千萬別自顧自地加上這項涵義喔！參與者
參與者（actor）是指位於系統外部的物件，它會在參與使用案例執行期間，與系統產生交換資訊的互動行為。常見如一般的人類使用者、公司組織、連線的資訊系統、或者連線的硬體設備，都是極為常見的參與者。

請看圖5的使用案例圖，參與者採用人型圖示，參與者的名稱放置於人型圖示下方。在圖5的範例中，會員在使用信用卡刷卡付款時，會與購物網站有一連串的互動，期間購物網站還會與另一信用卡系統互動，連線驗證並取得信用卡消費的正式授權。會員是一般的人類使用者，而信用卡系統則是屬於連線的資訊系統。

接續的指南編號61到68都跟參與者有關，一共有八條，比跟使用案例有關的指南更多，我們來仔細研究看看吧！

指南61 把主要參與者放置於圖面的左上角（Place Your Primary Actor（s） in the Top Left Corner of the Diagram）

通常，我們會把參與者依其重要性分為兩大類：一類是扮演啟動角色，會主動向系統提出需求者，稱之為「主要參與者」（primary actor）。可以說，系統所提供的使用案例中，絕大部分的使用案例都是為了滿足主要參與者的需求。

另一類的參與者扮演支援角色，主要在支援系統執行使用案例，它會跟系統協力提供完整的服務給主要參與者，這類參與者一般稱之為「次要參與者」或「支援性參與者」。

在西方的書寫及閱讀習慣中，以版面的左上角為起始點，所以這條指南才會建議我們將重要的主動參與者放置於圖面的左上角或左側，把扮演支援角色的參與者放至於圖面的右側。

比方說，在圖6的購物網站的範例中，會員是我們最重要的主要參與者，所以可以將它放置於使用案例圖的左側，而信用卡系統則扮演支援角色，它是次要參與者，可以放置於圖面的右側。

指南62 參與者放置於使用案例圖的邊框外（Draw Actors on the Outside Edges of a Use-Case Diagram）

有時候，我們會在使用案例圖內，以大方框表示系統範圍，如圖7的大方框代表購物網站。前面提過，參與者位於系統外部，但會與系統產生互動，而使用案例則是代表系統對外提供的服務，所以位於系統內部，因此在圖面上就必須將兩者分別放置於大方框的內外了。

不過，我們從參與者與使用案例的定義上頭，其實很明顯可以得知兩者分別位於系統內外，所以即便在使用案例圖面上未繪製出大方框，系統範圍仍舊存在於兩者之間。

指南63 用單數的、領域相關的名稱來為參與者命名（Name Actors with Singular, Domain-Relevant Nouns）

參與者代表使用者所扮演的一種角色（role），所以在命名上，適合採用單數名稱。比方說，一個提供雙方通話的通訊平臺，其使用者分別扮演撥話方或受話方兩種不同的角色，所以將通話雙方區分兩個不同的參與者，如圖8所示。

再者，系統應用於某一個領域中，而參與者通常是跟領域相關的角色，所以儘可能採用領域人士熟悉的名詞做為參與者的名稱，這樣將有助於開發人員與使用者、領域人士之間的溝通。

指南64 每個參與者關聯到一個或多個使用案例（Associate Each Actor with One or More Use Cases）

每一個參與者至少會參與一個使用案例，而每一個使用案例也至少會有一個參與者參與其中。位於系統外部的物件有許多，但只有會與系統產生互動的物件，才是使用案例的參與者。也就是說，每一個參與者當然至少會參與一個使用案例，否則它就不符合參與者的定義了，不是嗎？
不過，比較值得注意的是，是不是每一個使用案例都至少會有一個參與者參與其中呢？是不是每個使用案例都會至少有一個人類使用者，或是連線資訊系統、硬體設備來啟動它呢？如果，有些使用案例是定時啟動的，那啟動它的參與者是誰呢？

例如，微軟的Word有一個自動存檔的功能，只要編輯經過一段時間，它就會自動執行存檔的功能。顯然，使用者會啟動手動存檔的使用案例，但是自動存檔呢，啟動它的參與者是誰？關於這個疑問，我們得留待第68條指南，再見分曉，如圖9所示。

指南65 以角色命名參與者，不以職務頭銜命名（Name Actors to Model Roles, Not Job Titles）

理論上，我也都知道以角色命名參與者，會比以職務頭銜命名參與者更佳。不過，實務上，卻是有難為之處。

以職務頭銜命名有兩個常見的問題：其一，常見多個不同職務的使用者，都具有職權可以啟動相同使用案例，因此形成多個參與者關聯到相同使用案例的情況，造成使用案例圖面上的混亂。

比方說，在醫療系統的範例中，醫生可以使用資訊系統親自查詢病歷，可是有時候醫生會請護士幫忙查詢病歷，或者請護理長幫忙查詢病歷，所以形成三個參與者連接到同一個使用案例的情況，如圖10所示。可是，在執行查詢病歷這個使用案例期間，並不是三個參與者需要同時參與，反而是只需要三者中的一個就可以啟動使用案例了。

化解上述範例圖面複雜度的方法之一，採用角色命名，不以職務頭銜命名。請看圖11，我們使用「操作員」這個角色名稱做為參與者的名稱，無論真實世界中，醫生、護理長或是護士來使用醫療系統都無妨，只要他們是扮演操作員這個角色即可。

以角色命名看起來挺好，不過我在實務上的經驗，卻不是這麼一回事。一則，職務頭銜對使用者而言，是很直覺且眾所皆知的名詞，所以如果要改用角色命名，反而需要花更多的時間去命名並達成共識。二則，即便花了時間訂出了角色名稱，也達成共識了，還需要再多一道對應手續，說明哪些職務頭銜可以扮演哪些角色，像是額外產生圖12來說明醫生、護理長和護士都可以具備操作員的資格。

後來，我在實務上退而求其次的作法是，還是使用職務頭銜命名參與者，不過在使用案例圖面上僅留下最重要的參與者，如圖13所示。不過，我會在使用案例敘述中列出哪些參與者可以啟動該使用案例，如圖14所示。這樣不僅可以降低圖面的複雜度，也不需要特別花時間去尋找角色名稱，甚至還得花時間說明職務頭銜與角色之間的對應關係。

指南66 使用《system》標示系統參與者（Use 《system》 to Indicate System Actors）

參與者不侷限是人類使用者，它也可以是連線的資訊系統，特別是支援性的參與者，很多都是連線的資訊系統。這條指南建議我們，遇到這類參與者時，可以採用《system》字標，明確指出它是一個連線的資訊系統。

譬如圖15的範例中，信用卡系統是購物網站的連線系統，它會支援購物網站執行刷卡結帳的使用案例，所以我們可以套用《system》字標明確指出它是一個連線的資訊系統。

指南67 不允許參與者之間有互動（Don’t Allow Actors to Interact with One Another）
通常，數個不同的參與者同時參與一個使用案例時，這些參與者之間鮮少有互動。由於UML語法中，參與者之間並無互動關係，所以如果真遇到參與者彼此之間有互動時，也請不要在使用案例圖面上繪製出參與者彼此之間的互動，不過倒是可以在使用案例敘述中記錄這項互動關係。

指南68 用「時間」參與者標示預定事件（Introduce an Actor Called “Time” to Initiate Scheduled Events）

還記得前面提到，如果使用案例不是由人類使用者啟動，而是系統定時啟動的話，那這類使用案例的參與者為何？這是十分常見的情況，指南建議我們設置一個名為「時間」（time）的參與者，舉凡遇到這類定時啟動的使用案例，就以「時間」做為啟動它的主要參與者。

所以，微軟Word的自動存檔使用案例，它的啟動者可以是一個名為「時間」的參與者，代表這個使用案例是定時啟動的，不是由一般的人類使用者手動啟動的，如圖16所示。

下一期，將介紹其餘兩組使用案例圖的UML風格指南，包括關係以及系統範圍。

作者簡介：
邱郁惠
研究OOAD、UML、MDA十餘年，經歷過顧問、專案、教學及寫作工作。離職後創辦UML Blog推廣UML，組織《UML互助會》社群定期舉辦軟體技術講座，出版多本UML專業書籍與電子書。目前擁有OCUP/UML三級認證、PMP認證。

相關連結─
沒時間讀 UML/OOAD 書之挑讀筆記 第6回 The Elements of UML 2.0 Style（1）
沒時間讀 UML/OOAD 書之挑讀筆記 第7回 The Elements of UML 2.0 Style（2）