搞事情之 UML 的用例圖

原文地址：PJ 的 iOS 開發平常

面向對象技術概述

面向對象的基本建模原則：抽象、封裝、繼承和分類。

面向對象的基本軟件工程：OOA（面向對象的分析）、OOD（面向對象的設計）、OOP（面向對象的編程）和OOSM（面向對象的軟件維護）

對象的概念是：對問題域中某個實體的抽象；類的概念是：對具備項目屬性和行爲的一個或多個對象的描述

屬性的定義：描述對象靜態特徵的數據項；服務的定義：描述對象的動態特徵（行爲）的一個操做序列。

類的定義要包括：名稱、屬性和操做三要素。

面向對象呈現設計的三大特性：封裝、繼承和多態。

面向對象的系統分析要確立 3 個系統模型是對象模型、功能模型和動態模型。

用例圖

參與者

參與者是指系統之外的、須要使用系統或與系統交互的外部實體，包括人、設備、外部系統等。

用例

用例是對一個活動者使用系統的一項功能時所進行的交互過程的一個文字描述序列。能夠說，軟件開發的過程是用例驅動的。

用例是對系統行爲的動態描述，屬於 UML 的動態建模部分。UML 中的建模機制包括靜態建模和動態建模兩部分，其中靜態建模機制包括類圖、對象圖、構件圖和部署圖；動態建模機制包括用例圖、順序圖、協做圖、狀態圖和活動圖。

理論上能夠把一個軟件系統的全部用例都畫出來，但實際開發過程當中，進行用例分析時只需把那些重要的、交互過程複雜的用例找出來。不要試圖把全部的需求都以用例的方式表示出來。需求有兩種基本形式：功能性需求和非功能性需求。用例描述的只是功能性方面的需求，那些難以用 UML 表示的需求不少是非功能性需求。

泛化關係

官方解釋：泛化表明通常的與特殊的關係，在用例之間的泛化關係中，子用例繼承了父用例的行爲和含義，子用例也能夠增長新的行爲和含義或覆蓋父用例中的行爲和含義。

PJ 的解釋：子類和父類的關係。

包含關係

官方解釋：包含關係指的是兩個用例之間的關係，其中一個用例（基本用例）的行爲包含了另外一個用例（包含用例）的行爲。

PJ 的解釋：把某一個功能進行重用。

【例 1】銀行的 ATM 系統中，有「存款」、「取款」、「帳戶餘額查詢」和「轉帳」四個用例，都要求用戶必須登陸了 ATM 機。也就是說，它們都包含了用戶登陸系統的行爲。所以，用戶登陸系統的行爲是這些用例中相同的動做，能夠將它提取出來，單獨的做爲一個包含用例。

「存款」、「取款」、「查詢用戶餘額」和「轉帳」是基本用例，「登陸」是包含用例，以下圖所示：

因爲將共同的用戶登陸系統行爲提取出來，「存款」、「取款」、「查詢用戶餘額」和「轉帳」四個基本用例都再也不含有用戶登陸系統的行爲。

【例 2】網上購物系統，當註冊會員在線購物時，網上購物系統須要對顧客的信用卡進行檢查，檢查輸入的信用卡號是否有效，信用卡是否有足夠的資金進行支付。

上圖中有沒有必要將檢查信用的行爲提取出來，單獨構成一個用例（做爲包含用例），當信用檢查的行爲只發生在「在線購物」活動中時，能夠不用提取出來。當信用檢查的行爲還發生在其它活動中時，應該提取出來，以便實現軟件重用。

拓展關係

官方解釋：在拓展關係中，對於拓展用例的執行有更多的規則限制，基本用例必須聲明若干個「拓展點」，而拓展用例只能在這些拓展點上增長新的行爲和含義。

PJ 的解釋：基本用例在知足必定條件後可進行選擇執行拓展用例。

【例 3】圖書借閱系統。當讀者還書時，若是借書時間超期，則須要繳納必定的滯納金，做爲罰款。

綜合

【例 4】 網上購物系統，當註冊會員瀏覽網站時，他可能臨時決定購買商品，當他決定購買商品後，就必須將商品放進購物車，而後下訂單。

若是網上購物系統的需求改成了：註冊會員便可以直接在線購物，又能夠瀏覽商品後臨時決定在線購物，則能夠改成下圖所示：

用例描述

沒有描述的用例就像是一本書的目錄，人們只知道該目錄的標題，但並不知道該目錄的具體內容是什麼，僅用圖形符號表示的用例自己並不能提供該用例所具有的所有信息，必須經過文本的方式描述該用例的完整功能。實際上，用例的描述纔是用例的主要部分，是後續的交互圖分析和類圖分析必不可少的部分。

用例描述了參與者和軟件系統進行交互時，系統所執行的一系列動做序列，所以這些動做序列應該包含正常使用的各類動做序列（主事件流），並且還包含對非正常使用時軟件系統的動做序列（子事件流）。

【例 1】 在銀行 ATM 系統的 ATM 機上「取款」用例一個簡單用例描述能夠採起以下格式

描述項	說明
用例名稱	取款。
用例描述	在儲戶帳戶有足夠金額的狀況下，爲儲戶提供現金，並從儲戶帳戶中減去所取金額。
參與者	儲戶。
前置條件	儲戶正確登陸系統。
後置條件	儲戶帳戶餘額被調整。
主事件流	（1）儲戶在主界面選擇「取款」選項，開始用例（這個詞的出現很重要）。（2）ATM 機提示儲戶輸入欲取金額。（3）儲戶輸入欲取金額。（4）ATM 確認該儲戶帳戶是否有足夠的金額。若是金額不夠，則執行子事件流 b 。若是與主機鏈接有問題，則執行異常事件流 e。（5）ATM 機從儲戶賬號中減去所取金額。（6）ATM 機向儲戶提供要取的現金。（7）ATM 機打印取款憑證。（8）進入主界面。ATM 機提供如下選項：存款、取款、查詢和轉帳。用例結束（這個詞的出現一樣很重要）。
子事件流 b	b1. 提示儲戶餘額不夠。b2. 返回主界面，等待儲戶從新選擇選項。
異常事件流 e	e1. 提示儲戶主機鏈接不上。e2. 系統自動關閉，退出儲戶銀行卡，用例結束。

一個複雜用例主要體如今基本操做流程和可選操做流程的步驟和分之過多，此時，能夠採用「場景（或稱腳本）」的技術來描述用例，而不是用大量的分之和附屬流來描述用例。

用例建模

用例模型主要應用在需求分析時使用。

步驟

• 找出系統外部的參與者和外部系統，肯定系統的邊界和範圍；
• 肯定每個參與者所指望的系統行爲，參與者對系統的基本業務需求；
• 把這些系統行爲做爲基本用例；
• 區分用例的優先級；
• 細化用例。使用泛化、包含、拓展等關係進行處理；
• 編寫每一個用例的用例描述；
• 繪製用例圖；
• 編寫項目詞彙表。

肯定系統邊界

系統邊界是指系統與系統之間的界限。系統能夠認爲是一系列的相互做用的元素造成的具備特定功能的有機總體。不屬於這個有機總體的部分能夠認爲是外部系統。所以系統邊界定義了油誰或什麼參與者來使用系統，系統可以爲參與者提供什麼特定服務。系統邊界決定了參與者。

【例 1】在一個僅爲交易客戶提供買賣基金的基金交易系統中，參與者爲交易客戶，交易客戶可以操做的系統功能有買入基金和賣出基金。所以，系統有兩個用例：買入基金和賣出基金。

進一步分析發現，基金的品種應該存在與該系統中，不然交易客戶沒法進行基金的買賣。但系統已存的兩個用例都不能完成基金品種的管理，因此能夠確認基金品種的管理應該在別的系統中完成。

因此，咱們須要開發這個系統，僅存在兩個用例：買入基金、賣出基金。

【例 2】對例 1 作個調整。在一個既提供基金買賣又提供基金品種錄入的基金交易系統中，交易客戶，可以進行基金的買入和賣出。由於還須要對基金品種進行管理（錄入、修改、刪除和查詢），由基金公司員工進行操做。因此該系統的參與者有交易客戶和基金公司員工。系統邊界能夠改成下圖所示：

如何肯定參與者

• 誰將使用系統的主要功能？
• 誰將須要系統的支持來完成她們的平常工做？
• 誰將必須維護、管理和確保系統正常工做？
• 誰將給系統提供信息、使用信息和維護信息？
• 系統須要處理哪些硬件設備？
• 系統使用外部資源嗎？
• 系統須要與其餘系統交互嗎？
• 誰對系統產生的結果感興趣？

須要注意的問題：

• 只要是參與者，對於子系統而言都是外部的；
• 參與者直接與系統進行交互；
• 參與者指的與系統直接交互時所扮演的角色，而不是特定的人或事物。好比，不是 PJ 與教務系統產生交互而是學生與教務系統產生交互；

如何肯定用例

識別用例能夠從列出的參與者列表中從頭開始尋找，考慮每一個參與者如何使用系統，須要系統提供什麼樣的服務。

• 參與者要向系統請求什麼功能？
• 每一個參與者的特定任務是什麼？
• 參與者須要讀取、建立、撤銷、修改和存儲系統的某些信息嗎？
• 參與者是否有須要通知系統的事件？系統是否有須要通知參與者的事件？
• 這些事件表明了哪些功能？
• 系統須要哪些輸入輸出功能？
• 是否全部的功能需求都被用例使用了？

須要注意如下問題：

• 每一個用例至少有一個參與者；
• 每一個參與者至少一個用例；
• 若是存在沒有參與者的用例，再三檢查後，仍是沒有參與者，能夠考慮把該用例併入其餘用例中；
• 若是存在沒有用例的參與者，再三檢查後，該參與者仍是沒有用例，能夠考慮該參與者是如何與系統產生交互的，或由該參與者肯定一個新的用例，或實際上該參與者自己就是多餘的。

項目詞彙表

這什麼鬼，沒見過，沒據說過......

其餘問題

需求應該有層次的組織

系統的高層需求一版用不超過 12 個左右的用例進行表示，在其下的層次中，用例的數量不該超過當前用例的 5～10 倍。能夠將用例劃分爲業務用例、系統用例和組件用例等。

不要從用例直接推導設計

用例應該描述參與者使用系統所遵循的順序，但用例毫不說明系統內部採用什麼步驟來響應參與者的刺激。

用例包

用例模型的調整

若是兩個用例老是以一樣的順序被激活，可能須要將它們合併爲一個用例。

不要過於詳細

在進行用例描述時尚未考慮系統的設計方案，那麼也不會涉及用戶界面。