UML表詞圖細(xì)則和應(yīng)用規(guī)定一、概述

UML（統(tǒng)一建模語言）表詞圖是一種用于描述系統(tǒng)用例和用戶交互的圖形化工具，廣泛應(yīng)用于軟件工程領(lǐng)域。它通過清晰的視覺化表達(dá)，幫助開發(fā)者和用戶理解系統(tǒng)功能、交互流程及邊界。本細(xì)則旨在規(guī)范UML表詞圖的繪制標(biāo)準(zhǔn)、應(yīng)用場景及操作流程，確保其在項目開發(fā)中發(fā)揮最大效用。

二、UML表詞圖繪制標(biāo)準(zhǔn)

（一）基本構(gòu)成要素

1.用例（UseCase）

-用例表示系統(tǒng)對外提供的功能或服務(wù)，用橢圓形表示。

-用例名稱需明確、簡潔，如“用戶登錄”“查詢訂單”。

2.參與者（Actor）

-參與者代表與系統(tǒng)交互的外部實體，如用戶、設(shè)備等，用小人圖標(biāo)表示。

-參與者需標(biāo)注名稱，如“管理員”“客戶”。

3.關(guān)系（Relationship）

-關(guān)系包括關(guān)聯(lián)（Association）、依賴（Dependency）和泛化（Generalization）。

-關(guān)聯(lián)表示參與者與用例的交互路徑，用實線帶箭頭表示。

-依賴表示用例間的輔助關(guān)系，用虛線表示。

-泛化表示用例或參與者的繼承關(guān)系，用實線加空心箭頭表示。

（二）繪制規(guī)范

1.布局要求

-參與者位于圖的左側(cè)或右側(cè)，用例位于中央?yún)^(qū)域。

-關(guān)系線應(yīng)避免交叉，優(yōu)先橫向或縱向排列。

2.標(biāo)注要求

-用例名稱需加粗，參與者名稱需斜體。

-關(guān)系線上可標(biāo)注交互條件，如“登錄成功則訪問訂單”。

三、UML表詞圖應(yīng)用場景

（一）需求分析階段

1.確定系統(tǒng)邊界

-通過表詞圖明確系統(tǒng)功能范圍，排除非核心功能。

-示例：電商系統(tǒng)可包含“用戶注冊”“支付”“物流查詢”等用例。

2.定義交互流程

-繪制用例圖，標(biāo)注參與者與用例的交互順序。

-示例：用戶登錄流程可標(biāo)注為“輸入憑證→驗證→進(jìn)入系統(tǒng)”。

（二）系統(tǒng)設(shè)計階段

1.功能模塊劃分

-將復(fù)雜用例拆分為子用例，形成層次化結(jié)構(gòu)。

-示例：訂單管理可拆分為“創(chuàng)建訂單”“修改訂單”“取消訂單”。

2.用戶界面設(shè)計

-基于表詞圖設(shè)計交互界面，確保操作邏輯清晰。

-示例：購物車頁面需包含“添加商品”“調(diào)整數(shù)量”“結(jié)算”等操作。

四、操作流程

（一）繪制步驟

1.確定參與者

-列出所有與系統(tǒng)交互的外部實體。

-示例：在線教育系統(tǒng)參與者包括“學(xué)生”“教師”“管理員”。

2.繪制用例

-根據(jù)需求文檔，將功能點轉(zhuǎn)化為用例。

3.建立關(guān)系

-連接參與者和用例，標(biāo)注交互條件。

4.完善細(xì)節(jié)

-添加注解說明特殊場景，如異常處理流程。

（二）評審與修改

1.團(tuán)隊評審

-組織開發(fā)、測試人員對表詞圖進(jìn)行評審，確保無遺漏。

2.迭代優(yōu)化

-根據(jù)反饋調(diào)整用例邊界或交互邏輯。

五、注意事項

1.更新維護(hù)

-系統(tǒng)需求變更時需同步更新表詞圖，避免脫節(jié)。

2.工具選擇

-推薦使用AxureRP、Visio等建模工具，提高繪制效率。

一、概述

UML（統(tǒng)一建模語言）表詞圖（通常指UML用例圖UseCaseDiagram），是一種核心的UML圖，用于描繪系統(tǒng)的功能視圖，即系統(tǒng)所提供的服務(wù)以及使用這些服務(wù)的外部實體（參與者）。它幫助項目團(tuán)隊，包括開發(fā)人員、業(yè)務(wù)分析師和最終用戶，理解系統(tǒng)的邊界、主要功能和用戶與系統(tǒng)如何交互。表詞圖通過圖形化的方式，將復(fù)雜的系統(tǒng)需求轉(zhuǎn)化為直觀、易于溝通的模型。本細(xì)則旨在提供UML表詞圖的詳細(xì)繪制規(guī)范、標(biāo)準(zhǔn)應(yīng)用流程以及常見實踐，以確保其作為需求分析和溝通工具的有效性和一致性。

二、UML表詞圖繪制標(biāo)準(zhǔn)

（一）基本構(gòu)成要素

1.用例（UseCase）

用例是系統(tǒng)對外提供的、可被參與者明確感知到的功能或價值。它描述了系統(tǒng)為了滿足參與者需求所執(zhí)行的一系列動作序列。

圖形表示：用例通常用橢圓形繪制。

命名規(guī)范：

動詞短語開頭，表示系統(tǒng)做什么，例如：“登錄系統(tǒng)”、“查詢產(chǎn)品信息”、“下訂單”、“生成報告”。

語言應(yīng)清晰、簡潔、無歧義，準(zhǔn)確反映功能目的。

命名應(yīng)站在參與者的角度，描述他們能觀察到的結(jié)果。

標(biāo)注：橢圓形內(nèi)通常包含用例的名稱。有時，為了更詳細(xì)地說明用例的預(yù)條件（執(zhí)行前需滿足的條件）、后置條件（執(zhí)行后系統(tǒng)狀態(tài)）或基本流程，會使用內(nèi)部分隔線，將名稱分為三個部分：頂部分為用例名稱，中間為預(yù)條件，底部為后置條件。但更常見的是在橢圓外部使用注解（Note）或附件（Attachment）來描述這些詳細(xì)信息。

2.參與者（Actor）

參與者是與系統(tǒng)交互的外部實體，可以是人（如用戶、管理員）、其他系統(tǒng)（如外部API、數(shù)據(jù)庫）、或設(shè)備等。參與者代表發(fā)起用例或與用例進(jìn)行交互的對象。

圖形表示：參與者通常用小人圖標(biāo)（人形輪廓）表示。

分類：

內(nèi)部參與者：如果用例是系統(tǒng)內(nèi)部模塊之間調(diào)用，可以使用內(nèi)部參與者，通常用矩形加小人圖標(biāo)表示，并可能標(biāo)注“<<internal>>”。

外部參與者：大多數(shù)情況下指的是與系統(tǒng)邊界之外交互的實體。

命名規(guī)范：參與者名稱應(yīng)具體指明是哪個實體，例如：“普通用戶”、“管理員”、“結(jié)算系統(tǒng)”、“移動應(yīng)用”。

標(biāo)注：參與者名稱通常標(biāo)注在小人圖標(biāo)的下方，并使用斜體（Italic）表示。

3.關(guān)系（Relationship）

關(guān)系定義了參與者與用例之間的連接，以及用例之間的聯(lián)系。常見的用例關(guān)系包括關(guān)聯(lián)（Association）、依賴（Dependency）、泛化（Generalization）和擴(kuò)展（Include）、擴(kuò)展（Extend）。

（1）關(guān)聯(lián)（Association）

表示參與者與用例之間存在較穩(wěn)定、雙向的交互關(guān)系。通常暗示參與者可以多次與用例交互。

圖形表示：用實線連接參與者和用例。

箭頭：箭頭可以指明交互的發(fā)起方向，但通常不強(qiáng)制要求。如果需要強(qiáng)調(diào)，可以用帶箭頭的實線。

標(biāo)注：關(guān)聯(lián)線上可以標(biāo)注交互的頻率、條件或職責(zé)，例如：“每次登錄”、“僅當(dāng)權(quán)限允許”。

（2）依賴（Dependency）

表示參與者或用例之間的弱依賴關(guān)系。通常指一個元素的變更可能影響到另一個元素，但關(guān)系相對較小或臨時。

圖形表示：用虛線連接，并帶一個箭頭指向被依賴的元素。

適用場景：例如，某個用例在執(zhí)行過程中需要調(diào)用另一個小的輔助用例，但這個輔助用例并非該主要用例的常規(guī)部分。

（3）泛化（Generalization）

表示繼承關(guān)系，通常用于表示參與者或用例的共性。子參與者/子用例繼承父參與者/父用例的屬性和關(guān)系。

圖形表示：用實線連接，并帶一個空心箭頭指向父元素。

命名：箭頭旁常標(biāo)注“<<generalization>>”或直接使用“<:”。

適用場景：例如，系統(tǒng)中有多類用戶（如“普通用戶”、“VIP用戶”、“管理員”），它們都有“登錄”這個共同用例，可以通過泛化關(guān)系表示。

（二）繪制規(guī)范

1.布局要求

參與者位置：通常將參與者放置在用例圖的邊緣，左側(cè)或右側(cè)，表示外部實體。有時也可以根據(jù)交互邏輯放在頂部或底部。

用例位置：用例通常位于圖的中心區(qū)域，圍繞參與者排列。

關(guān)系線：關(guān)系線應(yīng)盡量保持簡潔、清晰，避免交叉和過于密集。優(yōu)先使用水平和垂直的直線。使用曲線時，應(yīng)避免過于復(fù)雜的弧度。

視覺平衡：圖形布局應(yīng)保持視覺上的平衡和對稱，便于閱讀和理解。

2.標(biāo)注要求

字體：用例名稱使用常規(guī)字體，參與者名稱使用斜體（Italic）。

顏色：可以使用不同的顏色區(qū)分不同的參與者或用例類型，但需保持一致性。

大小：圖標(biāo)和文字大小應(yīng)適中，保證清晰可辨。

附加信息：對于復(fù)雜的用例，可以使用注解（Note，用矩形加折線邊框表示，并帶箭頭指向被解釋的元素）或附件（Attachment，用矩形加點線邊框表示）來提供預(yù)條件、后置條件、異常流程等詳細(xì)信息。注解和附件可以通過“粘附”線連接到相關(guān)元素。

三、UML表詞圖應(yīng)用場景

（一）需求分析階段

1.確定系統(tǒng)邊界

操作步驟：

(1)收集所有潛在的系統(tǒng)用戶和外部系統(tǒng)交互點。

(2)識別所有需要系統(tǒng)完成的功能點。

(3)在UML表詞圖上，將識別出的外部實體繪制為參與者，將系統(tǒng)功能繪制為用例。

(4)通過觀察參與者與用例的關(guān)系，明確哪些功能是系統(tǒng)核心必須提供的（內(nèi)部用例），哪些是與外部實體交互的界面（外部用例）。

(5)根據(jù)參與者能否直接與用例交互，以及用例是否跨越多個參與者，定義系統(tǒng)的清晰邊界。邊界內(nèi)的用例屬于系統(tǒng)責(zé)任，邊界外的用例由其他系統(tǒng)或外部環(huán)境負(fù)責(zé)。

示例：對于一個在線圖書館系統(tǒng)，參與者可能是“讀者”、“圖書管理員”；用例可能包括“借閱圖書”、“歸還圖書”、“查詢圖書”、“管理讀者”、“管理館藏”。通過繪制，可以清晰界定哪些是讀者可以直接操作的（借閱、歸還、查詢），哪些是管理員專屬的（管理讀者、管理館藏），從而確定系統(tǒng)的功能范圍。

2.定義交互流程

操作步驟：

(1)選擇一個核心用例（如“借閱圖書”）。

(2)識別主要參與者（如“讀者”）。

(3)繪制用例圖，突出顯示該用例及其參與者。

(4)使用文字描述、狀態(tài)機(jī)圖或活動圖（作為補(bǔ)充）來詳細(xì)說明參與者與用例之間的步驟、判斷條件和可能的分支。

(5)標(biāo)注異常情況的處理流程，如“圖書已借出”或“讀者超期未還”時的交互。

示例：在“借閱圖書”用例中，交互流程可能包括：讀者->查詢圖書；系統(tǒng)->返回圖書列表；讀者->選擇圖書；讀者->提供借閱憑證；系統(tǒng)->驗證憑證；系統(tǒng)->檢查圖書狀態(tài)；系統(tǒng)->記錄借閱信息；讀者->獲取圖書。同時，需要定義異常流程，如圖書不可借（讀者->被告知原因）、憑證無效（系統(tǒng)->提示錯誤信息）等。

（二）系統(tǒng)設(shè)計階段

1.功能模塊劃分

操作步驟：

(1)分析高層次的用例，識別出其中包含的復(fù)雜邏輯或可以獨立管理的子功能。

(2)在UML表詞圖上，將一個復(fù)雜的用例拆分為多個更小的、職責(zé)更集中的子用例。這些子用例可以作為未來設(shè)計中的功能模塊或服務(wù)。

(3)繪制新的用例圖，展示這些子用例之間的關(guān)系（如關(guān)聯(lián)、泛化）以及它們?nèi)绾喂餐瑢崿F(xiàn)父用例。

(4)明確每個子用例的輸入、輸出和核心業(yè)務(wù)邏輯。

示例：“管理訂單”這個大用例可以拆分為“創(chuàng)建訂單”、“修改訂單”、“查詢訂單狀態(tài)”、“取消訂單”、“支付訂單”等多個子用例。每個子用例都可以獨立設(shè)計，并通過“管理訂單”這個父用例（或通過聚合關(guān)系）組織起來。

2.用戶界面設(shè)計

操作步驟：

(1)將表詞圖中的用例視為用戶界面上的主要功能入口或頁面/視圖。

(2)分析參與者與每個用例的交互方式，確定界面元素（按鈕、表單、列表等）及其布局。

(3)設(shè)計用例對應(yīng)界面的交互流程，確保符合用戶習(xí)慣和用例描述的操作序列。

(4)UML表詞圖提供了設(shè)計起點，后續(xù)可以使用原型工具（如Axure,Figma）創(chuàng)建更詳細(xì)的線框圖或交互原型。

示例：“查詢產(chǎn)品信息”用例可以對應(yīng)到一個產(chǎn)品搜索頁面，包含搜索框（輸入查詢條件）、搜索按鈕（觸發(fā)用例）、產(chǎn)品列表展示區(qū)（顯示結(jié)果）。交互流程是用戶輸入->點擊搜索->頁面展示結(jié)果。

四、操作流程

（一）繪制步驟

1.確定參與者

具體操作：

(1)回顧需求文檔、用戶訪談記錄或業(yè)務(wù)流程圖，列出所有與系統(tǒng)交互的外部實體。

(2)與項目相關(guān)人員進(jìn)行討論，確認(rèn)參與者的完整性，排除非交互對象（如系統(tǒng)內(nèi)部組件）。

(3)為每個參與者命名，確保名稱準(zhǔn)確反映其身份或角色。

(4)判斷參與者類型（外部/內(nèi)部），并決定是否需要使用小人圖標(biāo)或內(nèi)部參與者表示。

2.繪制用例

具體操作：

(1)基于需求文檔中的功能列表或業(yè)務(wù)用例，將每個功能點或業(yè)務(wù)目標(biāo)轉(zhuǎn)化為一個用例。

(2)為每個用例賦予一個清晰、符合規(guī)范的名稱（動詞短語開頭）。

(3)使用UML工具（如Visio,StarUML,PlantUML,在線繪圖工具）或手繪，繪制橢圓形，并寫入用例名稱。

(4)初步考慮用例的預(yù)條件、后置條件和主要流程，思考是否需要添加內(nèi)部分隔線或計劃使用注解。

3.建立關(guān)系

具體操作：

(1)分析參與者需要執(zhí)行哪些用例，以及用例之間是否存在依賴、繼承等關(guān)系。

(2)使用相應(yīng)的線型（實線、虛線）和箭頭（有/無箭頭）繪制關(guān)系線。

(3)對于關(guān)聯(lián)關(guān)系，考慮是否需要標(biāo)注交互條件或頻率。

(4)對于泛化關(guān)系，確保父元素和子元素都正確繪制，并使用空心箭頭和標(biāo)注。

(5)檢查關(guān)系線的布局，確保清晰、無交叉，符合繪制規(guī)范。

4.完善細(xì)節(jié)

具體操作：

(1)對于復(fù)雜的用例，使用注解（Note）或附件（Attachment）添加預(yù)條件（Precondition）、后置條件（Postcondition）、異常流程（Alternative/ExceptFlow）、基本流程（MainFlow）等詳細(xì)信息。

(2)標(biāo)注圖例（如果圖中有特殊符號或約定）。

(3)添加圖名（如“XX系統(tǒng)用例圖”）和繪制者/日期信息。

(4)整體檢查圖形的清晰度、一致性和準(zhǔn)確性。

（二）評審與修改

1.團(tuán)隊評審

具體操作：

(1)組織需求分析師、開發(fā)人員、測試人員甚至業(yè)務(wù)代表一起審查繪制的UML表詞圖。

(2)檢查用例是否完整、準(zhǔn)確，是否覆蓋了所有需求。

(3)評估參與者與用例的關(guān)系是否合理，系統(tǒng)邊界是否清晰。

(4)討論圖中存在的歧義、遺漏或邏輯錯誤。

(5)收集所有評審人員的反饋意見。

2.迭代優(yōu)化

具體操作：

(1)根據(jù)評審反饋，整理修改意見清單。

(2)修改UML表詞圖，調(diào)整用例名稱、添加/刪除參與者、修改關(guān)系線等。

(3)對于重要的修改，可以再次組織小范圍評審，確保修改符合預(yù)期。

(4)重復(fù)評審和修改過程，直到圖被所有相關(guān)方認(rèn)可，或達(dá)到預(yù)定的迭代次數(shù)/時間點。

(5)最終確認(rèn)的UML表詞圖應(yīng)作為需求規(guī)格的一部分進(jìn)行版本控制。

五、注意事項

1.更新維護(hù)

具體要點：

系統(tǒng)需求是不斷變化的，UML表詞圖也需要同步更新。任何需求變更（如新增功能、修改用例、調(diào)整參與者）都應(yīng)反映在表詞圖上。

建立變更管理流程，確保每次更新都有記錄，并由相關(guān)人員確認(rèn)。

保持表詞圖與需求文檔、設(shè)計文檔等其他相關(guān)文檔的一致性。

定期（如每個開發(fā)迭代結(jié)束時）回顧和審查用例圖，清理過時或冗余的元素。

2.工具選擇

具體建議：

選擇合適的UML建模工具可以提高繪圖效率和準(zhǔn)確性。常見的工具包括：

商業(yè)工具：IBMRationalRose,OracleEnterpriseArchitect,SparxSystemsEnterpriseArchitect,AxureRP(支持部分UML功能),Visio(UML擴(kuò)展包)。

開源工具：StarUML,PlantUML(基于文本描述生成UML圖),ArgoUML。

在線工具：Lucidchart,draw.io(包含UML功能)。

選擇工具時考慮因素：易用性、功能完整性、團(tuán)隊熟悉度、成本、與現(xiàn)有開發(fā)環(huán)境的集成度。

無論使用何種工具，都應(yīng)遵循統(tǒng)一的繪圖風(fēng)格和規(guī)范，確保圖示清晰易懂。

3.溝通協(xié)作

具體要點：

UML表詞圖是溝通工具，應(yīng)使用所有項目成員都能理解的語言和符號。

在團(tuán)隊內(nèi)部推廣標(biāo)準(zhǔn)的繪制規(guī)范和圖例。

在需求討論、設(shè)計評審等會議中使用表詞圖進(jìn)行展示和解釋。

鼓勵團(tuán)隊成員對表詞圖提出疑問和建議，促進(jìn)共同理解。

4.適度復(fù)雜

具體要點：

避免過度建模，只為表達(dá)必要的信息。過于復(fù)雜的用例圖會變得難以閱讀和理解。

對于簡單的系統(tǒng)，一個清晰的用例圖可能就足夠了。對于大型復(fù)雜系統(tǒng)，可以考慮繪制多個用例圖，分別從不同視角（如按模塊、按用戶角色）展示系統(tǒng)功能。

將詳細(xì)的流程信息放在用例描述、活動圖或狀態(tài)機(jī)圖中，而不是過度擁擠在用例圖本身。

一、概述

UML（統(tǒng)一建模語言）表詞圖是一種用于描述系統(tǒng)用例和用戶交互的圖形化工具，廣泛應(yīng)用于軟件工程領(lǐng)域。它通過清晰的視覺化表達(dá)，幫助開發(fā)者和用戶理解系統(tǒng)功能、交互流程及邊界。本細(xì)則旨在規(guī)范UML表詞圖的繪制標(biāo)準(zhǔn)、應(yīng)用場景及操作流程，確保其在項目開發(fā)中發(fā)揮最大效用。

二、UML表詞圖繪制標(biāo)準(zhǔn)

（一）基本構(gòu)成要素

1.用例（UseCase）

-用例表示系統(tǒng)對外提供的功能或服務(wù)，用橢圓形表示。

-用例名稱需明確、簡潔，如“用戶登錄”“查詢訂單”。

2.參與者（Actor）

-參與者代表與系統(tǒng)交互的外部實體，如用戶、設(shè)備等，用小人圖標(biāo)表示。

-參與者需標(biāo)注名稱，如“管理員”“客戶”。

3.關(guān)系（Relationship）

-關(guān)系包括關(guān)聯(lián)（Association）、依賴（Dependency）和泛化（Generalization）。

-關(guān)聯(lián)表示參與者與用例的交互路徑，用實線帶箭頭表示。

-依賴表示用例間的輔助關(guān)系，用虛線表示。

-泛化表示用例或參與者的繼承關(guān)系，用實線加空心箭頭表示。

（二）繪制規(guī)范

1.布局要求

-參與者位于圖的左側(cè)或右側(cè)，用例位于中央?yún)^(qū)域。

-關(guān)系線應(yīng)避免交叉，優(yōu)先橫向或縱向排列。

2.標(biāo)注要求

-用例名稱需加粗，參與者名稱需斜體。

-關(guān)系線上可標(biāo)注交互條件，如“登錄成功則訪問訂單”。

三、UML表詞圖應(yīng)用場景

（一）需求分析階段

1.確定系統(tǒng)邊界

-通過表詞圖明確系統(tǒng)功能范圍，排除非核心功能。

-示例：電商系統(tǒng)可包含“用戶注冊”“支付”“物流查詢”等用例。

2.定義交互流程

-繪制用例圖，標(biāo)注參與者與用例的交互順序。

-示例：用戶登錄流程可標(biāo)注為“輸入憑證→驗證→進(jìn)入系統(tǒng)”。

（二）系統(tǒng)設(shè)計階段

1.功能模塊劃分

-將復(fù)雜用例拆分為子用例，形成層次化結(jié)構(gòu)。

-示例：訂單管理可拆分為“創(chuàng)建訂單”“修改訂單”“取消訂單”。

2.用戶界面設(shè)計

-基于表詞圖設(shè)計交互界面，確保操作邏輯清晰。

-示例：購物車頁面需包含“添加商品”“調(diào)整數(shù)量”“結(jié)算”等操作。

四、操作流程

（一）繪制步驟

1.確定參與者

-列出所有與系統(tǒng)交互的外部實體。

-示例：在線教育系統(tǒng)參與者包括“學(xué)生”“教師”“管理員”。

2.繪制用例

-根據(jù)需求文檔，將功能點轉(zhuǎn)化為用例。

3.建立關(guān)系

-連接參與者和用例，標(biāo)注交互條件。

4.完善細(xì)節(jié)

-添加注解說明特殊場景，如異常處理流程。

（二）評審與修改

1.團(tuán)隊評審

-組織開發(fā)、測試人員對表詞圖進(jìn)行評審，確保無遺漏。

2.迭代優(yōu)化

-根據(jù)反饋調(diào)整用例邊界或交互邏輯。

五、注意事項

1.更新維護(hù)

-系統(tǒng)需求變更時需同步更新表詞圖，避免脫節(jié)。

2.工具選擇

-推薦使用AxureRP、Visio等建模工具，提高繪制效率。

一、概述

UML（統(tǒng)一建模語言）表詞圖（通常指UML用例圖UseCaseDiagram），是一種核心的UML圖，用于描繪系統(tǒng)的功能視圖，即系統(tǒng)所提供的服務(wù)以及使用這些服務(wù)的外部實體（參與者）。它幫助項目團(tuán)隊，包括開發(fā)人員、業(yè)務(wù)分析師和最終用戶，理解系統(tǒng)的邊界、主要功能和用戶與系統(tǒng)如何交互。表詞圖通過圖形化的方式，將復(fù)雜的系統(tǒng)需求轉(zhuǎn)化為直觀、易于溝通的模型。本細(xì)則旨在提供UML表詞圖的詳細(xì)繪制規(guī)范、標(biāo)準(zhǔn)應(yīng)用流程以及常見實踐，以確保其作為需求分析和溝通工具的有效性和一致性。

二、UML表詞圖繪制標(biāo)準(zhǔn)

（一）基本構(gòu)成要素

1.用例（UseCase）

用例是系統(tǒng)對外提供的、可被參與者明確感知到的功能或價值。它描述了系統(tǒng)為了滿足參與者需求所執(zhí)行的一系列動作序列。

圖形表示：用例通常用橢圓形繪制。

命名規(guī)范：

動詞短語開頭，表示系統(tǒng)做什么，例如：“登錄系統(tǒng)”、“查詢產(chǎn)品信息”、“下訂單”、“生成報告”。

語言應(yīng)清晰、簡潔、無歧義，準(zhǔn)確反映功能目的。

命名應(yīng)站在參與者的角度，描述他們能觀察到的結(jié)果。

標(biāo)注：橢圓形內(nèi)通常包含用例的名稱。有時，為了更詳細(xì)地說明用例的預(yù)條件（執(zhí)行前需滿足的條件）、后置條件（執(zhí)行后系統(tǒng)狀態(tài)）或基本流程，會使用內(nèi)部分隔線，將名稱分為三個部分：頂部分為用例名稱，中間為預(yù)條件，底部為后置條件。但更常見的是在橢圓外部使用注解（Note）或附件（Attachment）來描述這些詳細(xì)信息。

2.參與者（Actor）

參與者是與系統(tǒng)交互的外部實體，可以是人（如用戶、管理員）、其他系統(tǒng)（如外部API、數(shù)據(jù)庫）、或設(shè)備等。參與者代表發(fā)起用例或與用例進(jìn)行交互的對象。

圖形表示：參與者通常用小人圖標(biāo)（人形輪廓）表示。

分類：

內(nèi)部參與者：如果用例是系統(tǒng)內(nèi)部模塊之間調(diào)用，可以使用內(nèi)部參與者，通常用矩形加小人圖標(biāo)表示，并可能標(biāo)注“<<internal>>”。

外部參與者：大多數(shù)情況下指的是與系統(tǒng)邊界之外交互的實體。

命名規(guī)范：參與者名稱應(yīng)具體指明是哪個實體，例如：“普通用戶”、“管理員”、“結(jié)算系統(tǒng)”、“移動應(yīng)用”。

標(biāo)注：參與者名稱通常標(biāo)注在小人圖標(biāo)的下方，并使用斜體（Italic）表示。

3.關(guān)系（Relationship）

關(guān)系定義了參與者與用例之間的連接，以及用例之間的聯(lián)系。常見的用例關(guān)系包括關(guān)聯(lián)（Association）、依賴（Dependency）、泛化（Generalization）和擴(kuò)展（Include）、擴(kuò)展（Extend）。

（1）關(guān)聯(lián)（Association）

表示參與者與用例之間存在較穩(wěn)定、雙向的交互關(guān)系。通常暗示參與者可以多次與用例交互。

圖形表示：用實線連接參與者和用例。

箭頭：箭頭可以指明交互的發(fā)起方向，但通常不強(qiáng)制要求。如果需要強(qiáng)調(diào)，可以用帶箭頭的實線。

標(biāo)注：關(guān)聯(lián)線上可以標(biāo)注交互的頻率、條件或職責(zé)，例如：“每次登錄”、“僅當(dāng)權(quán)限允許”。

（2）依賴（Dependency）

表示參與者或用例之間的弱依賴關(guān)系。通常指一個元素的變更可能影響到另一個元素，但關(guān)系相對較小或臨時。

圖形表示：用虛線連接，并帶一個箭頭指向被依賴的元素。

適用場景：例如，某個用例在執(zhí)行過程中需要調(diào)用另一個小的輔助用例，但這個輔助用例并非該主要用例的常規(guī)部分。

（3）泛化（Generalization）

表示繼承關(guān)系，通常用于表示參與者或用例的共性。子參與者/子用例繼承父參與者/父用例的屬性和關(guān)系。

圖形表示：用實線連接，并帶一個空心箭頭指向父元素。

命名：箭頭旁常標(biāo)注“<<generalization>>”或直接使用“<:”。

適用場景：例如，系統(tǒng)中有多類用戶（如“普通用戶”、“VIP用戶”、“管理員”），它們都有“登錄”這個共同用例，可以通過泛化關(guān)系表示。

（二）繪制規(guī)范

1.布局要求

參與者位置：通常將參與者放置在用例圖的邊緣，左側(cè)或右側(cè)，表示外部實體。有時也可以根據(jù)交互邏輯放在頂部或底部。

用例位置：用例通常位于圖的中心區(qū)域，圍繞參與者排列。

關(guān)系線：關(guān)系線應(yīng)盡量保持簡潔、清晰，避免交叉和過于密集。優(yōu)先使用水平和垂直的直線。使用曲線時，應(yīng)避免過于復(fù)雜的弧度。

視覺平衡：圖形布局應(yīng)保持視覺上的平衡和對稱，便于閱讀和理解。

2.標(biāo)注要求

字體：用例名稱使用常規(guī)字體，參與者名稱使用斜體（Italic）。

顏色：可以使用不同的顏色區(qū)分不同的參與者或用例類型，但需保持一致性。

大小：圖標(biāo)和文字大小應(yīng)適中，保證清晰可辨。

附加信息：對于復(fù)雜的用例，可以使用注解（Note，用矩形加折線邊框表示，并帶箭頭指向被解釋的元素）或附件（Attachment，用矩形加點線邊框表示）來提供預(yù)條件、后置條件、異常流程等詳細(xì)信息。注解和附件可以通過“粘附”線連接到相關(guān)元素。

三、UML表詞圖應(yīng)用場景

（一）需求分析階段

1.確定系統(tǒng)邊界

操作步驟：

(1)收集所有潛在的系統(tǒng)用戶和外部系統(tǒng)交互點。

(2)識別所有需要系統(tǒng)完成的功能點。

(3)在UML表詞圖上，將識別出的外部實體繪制為參與者，將系統(tǒng)功能繪制為用例。

(4)通過觀察參與者與用例的關(guān)系，明確哪些功能是系統(tǒng)核心必須提供的（內(nèi)部用例），哪些是與外部實體交互的界面（外部用例）。

(5)根據(jù)參與者能否直接與用例交互，以及用例是否跨越多個參與者，定義系統(tǒng)的清晰邊界。邊界內(nèi)的用例屬于系統(tǒng)責(zé)任，邊界外的用例由其他系統(tǒng)或外部環(huán)境負(fù)責(zé)。

示例：對于一個在線圖書館系統(tǒng)，參與者可能是“讀者”、“圖書管理員”；用例可能包括“借閱圖書”、“歸還圖書”、“查詢圖書”、“管理讀者”、“管理館藏”。通過繪制，可以清晰界定哪些是讀者可以直接操作的（借閱、歸還、查詢），哪些是管理員專屬的（管理讀者、管理館藏），從而確定系統(tǒng)的功能范圍。

2.定義交互流程

操作步驟：

(1)選擇一個核心用例（如“借閱圖書”）。

(2)識別主要參與者（如“讀者”）。

(3)繪制用例圖，突出顯示該用例及其參與者。

(4)使用文字描述、狀態(tài)機(jī)圖或活動圖（作為補(bǔ)充）來詳細(xì)說明參與者與用例之間的步驟、判斷條件和可能的分支。

(5)標(biāo)注異常情況的處理流程，如“圖書已借出”或“讀者超期未還”時的交互。

示例：在“借閱圖書”用例中，交互流程可能包括：讀者->查詢圖書；系統(tǒng)->返回圖書列表；讀者->選擇圖書；讀者->提供借閱憑證；系統(tǒng)->驗證憑證；系統(tǒng)->檢查圖書狀態(tài)；系統(tǒng)->記錄借閱信息；讀者->獲取圖書。同時，需要定義異常流程，如圖書不可借（讀者->被告知原因）、憑證無效（系統(tǒng)->提示錯誤信息）等。

（二）系統(tǒng)設(shè)計階段

1.功能模塊劃分

操作步驟：

(1)分析高層次的用例，識別出其中包含的復(fù)雜邏輯或可以獨立管理的子功能。

(2)在UML表詞圖上，將一個復(fù)雜的用例拆分為多個更小的、職責(zé)更集中的子用例。這些子用例可以作為未來設(shè)計中的功能模塊或服務(wù)。

(3)繪制新的用例圖，展示這些子用例之間的關(guān)系（如關(guān)聯(lián)、泛化）以及它們?nèi)绾喂餐瑢崿F(xiàn)父用例。

(4)明確每個子用例的輸入、輸出和核心業(yè)務(wù)邏輯。

示例：“管理訂單”這個大用例可以拆分為“創(chuàng)建訂單”、“修改訂單”、“查詢訂單狀態(tài)”、“取消訂單”、“支付訂單”等多個子用例。每個子用例都可以獨立設(shè)計，并通過“管理訂單”這個父用例（或通過聚合關(guān)系）組織起來。

2.用戶界面設(shè)計

操作步驟：

(1)將表詞圖中的用例視為用戶界面上的主要功能入口或頁面/視圖。

(2)分析參與者與每個用例的交互方式，確定界面元素（按鈕、表單、列表等）及其布局。

(3)設(shè)計用例對應(yīng)界面的交互流程，確保符合用戶習(xí)慣和用例描述的操作序列。

(4)UML表詞圖提供了設(shè)計起點，后續(xù)可以使用原型工具（如Axure,Figma）創(chuàng)建更詳細(xì)的線框圖或交互原型。

示例：“查詢產(chǎn)品信息”用例可以對應(yīng)到一個產(chǎn)品搜索頁面，包含搜索框（輸入查詢條件）、搜索按鈕（觸發(fā)用例）、產(chǎn)品列表展示區(qū)（顯示結(jié)果）。交互流程是用戶輸入->點擊搜索->頁面展示結(jié)果。

四、操作流程

（一）繪制步驟

1.確定參與者

具體操作：

(1)回顧需求文檔、用戶訪談記錄或業(yè)務(wù)流程圖，列出所有與系統(tǒng)交互的外部實體。

(2)與項目相關(guān)人員進(jìn)行討論，確認(rèn)參與者的完整性，排除非交互對象（如系統(tǒng)內(nèi)部組件）。

(3)為每個參與者命名，確保名稱準(zhǔn)確反映其身份或角色。

(4)判斷參與者類型（外部/內(nèi)部），并決定是否需要使用小人圖標(biāo)或內(nèi)部參與者表示。

2.繪制用例

具體操作：

(1)基于需求文檔中的功能列表或業(yè)務(wù)用例，將每個功能點或業(yè)務(wù)目標(biāo)轉(zhuǎn)化為一個用例。

(2)為每個用例賦予一個清晰、符合規(guī)范的名稱（動詞短語開頭）。

(3)使用UML工具（如Visio,StarUML,PlantUML,在線繪圖工具）或手繪，繪制橢圓形，并寫入用例名稱。

(4)初步考慮用例的預(yù)條件、后置條件和主要流程，思考是否需要添加內(nèi)部分隔線或計劃使用注解。

3.建立關(guān)系

具體操作：

(1)分析參與者需要執(zhí)行哪些用例，以及用例之間是否存在依賴、繼承等關(guān)系。

(2)使用相應(yīng)的線型（實線、虛線）和箭頭（有/無箭頭）繪制關(guān)系線。

(3)對于關(guān)聯(lián)關(guān)系，考慮是否需要標(biāo)注交互條件或頻率。

(4)對于泛化關(guān)系，確保父元素和子元素都正確繪制，并使用空心箭頭和標(biāo)注。

(5)檢查關(guān)系線的布局，確保清晰、無交叉，符合繪制規(guī)范。

4.完善細(xì)節(jié)

具體操作：

(1)對于復(fù)雜的用例，使用注解（Note）或附件（Attachment）添加預(yù)條件（Precondition）、后置條件（Postcondition）、異常流程（Alternative/ExceptFlow）、基本流程（MainFlow）等詳細(xì)信息。

(2)標(biāo)注圖例（如果圖中有特殊符號或約定）。

(3)添加圖名（如“XX系統(tǒng)用例圖”）和繪制者/日期信息。

(4)整體檢查圖形的清晰度、一致性和準(zhǔn)確性。

（二）評審與修改

1.團(tuán)隊評審

具體操作：

(1)組織需求分析師、開發(fā)人員、測試人員甚至業(yè)務(wù)代表一起審查繪制的UML表詞圖。

(2)檢查用例是否完整、準(zhǔn)確，是否覆蓋了所有需求。

(3)評估參與者與用例的關(guān)系是否合理，系統(tǒng)邊界是否清晰。

(4)討論圖中存在的歧義、遺漏或邏輯錯誤。

(5)收集所有評審人員的反饋意見。

2.迭代優(yōu)化

具體操作：

(1)根據(jù)評審反饋，整理修改意見清單。

(2)修改UML表詞圖，調(diào)整用例名稱、添加/刪除參與者、修改關(guān)系線等。

(3)對于重要的修改，可以再次組織小范圍評審，確保修改符合預(yù)期。

(4)重復(fù)評審和修改過程，直到圖被所有相關(guān)方認(rèn)可，或達(dá)到預(yù)定的迭代次數(shù)/時間點。

(5)最終確認(rèn)的UML表詞圖應(yīng)作為需求規(guī)格的一部分進(jìn)行版本控制。

五、注意事項

1.更新維護(hù)

具體要點：

系統(tǒng)需求是不斷變化的，UML表詞圖也需要同步更新。任何需求變更（如新增功能、修改用例、調(diào)整參與者）都應(yīng)反映在表詞圖上。

建立變更管理流程，確保每次更新都有記錄，并由相關(guān)人員確認(rèn)。

保持表詞圖與需求文檔、設(shè)計文檔等其他相關(guān)文檔的一致性。

定期（如每個開發(fā)迭代結(jié)束時）回顧和審查用例圖，清理過時或冗余的元素。

2.工具選擇

具體建議：

選擇合適的UML建模工具可以提高繪圖效率和準(zhǔn)確性。常見的工具包括：

商業(yè)工具：IBMRationalRose,OracleEnterpriseArchitect,SparxSystemsEnterpriseArchitect,AxureRP(支持部分UML功能),Visio(UML擴(kuò)展包)。

開源工具：StarUML,PlantUML(基于文本描述生成UML圖),ArgoUML。

在線工具：Lucidchart,draw.io(包含UML功能)。

選擇工具時考慮因素：易用性、功能完整性、團(tuán)隊熟悉度、成本、與現(xiàn)有開發(fā)環(huán)境的集成度。

無論使用何種工具，都應(yīng)遵循統(tǒng)一的繪圖風(fēng)格和規(guī)范，確保圖示清晰易懂。

3.溝通協(xié)作

具體要點：

UML表詞圖是溝通工具，應(yīng)使用所有項目成員都能理解的語言和符號。

在團(tuán)隊內(nèi)部推廣標(biāo)準(zhǔn)的繪制規(guī)范和圖例。

在需求討論、設(shè)計評審等會議中使用表詞圖進(jìn)行展示和解釋。

鼓勵團(tuán)隊成員對表詞圖提出疑問和建議，促進(jìn)共同理解。

4.適度復(fù)雜

具體要點：

避免過度建模，只為表達(dá)必要的信息。過于復(fù)雜的用例圖會變得難以閱讀和理解。

對于簡單的系統(tǒng)，一個清晰的用例圖可能就足夠了。對于大型復(fù)雜系統(tǒng)，可以考慮繪制多個用例圖，分別從不同視角（如按模塊、按用戶角色）展示系統(tǒng)功能。

將詳細(xì)的流程信息放在用例描述、活動圖或狀態(tài)機(jī)圖中，而不是過度擁擠在用例圖本身。

一、概述

UML（統(tǒng)一建模語言）表詞圖是一種用于描述系統(tǒng)用例和用戶交互的圖形化工具，廣泛應(yīng)用于軟件工程領(lǐng)域。它通過清晰的視覺化表達(dá)，幫助開發(fā)者和用戶理解系統(tǒng)功能、交互流程及邊界。本細(xì)則旨在規(guī)范UML表詞圖的繪制標(biāo)準(zhǔn)、應(yīng)用場景及操作流程，確保其在項目開發(fā)中發(fā)揮最大效用。

二、UML表詞圖繪制標(biāo)準(zhǔn)

（一）基本構(gòu)成要素

1.用例（UseCase）

-用例表示系統(tǒng)對外提供的功能或服務(wù)，用橢圓形表示。

-用例名稱需明確、簡潔，如“用戶登錄”“查詢訂單”。

2.參與者（Actor）

-參與者代表與系統(tǒng)交互的外部實體，如用戶、設(shè)備等，用小人圖標(biāo)表示。

-參與者需標(biāo)注名稱，如“管理員”“客戶”。

3.關(guān)系（Relationship）

-關(guān)系包括關(guān)聯(lián)（Association）、依賴（Dependency）和泛化（Generalization）。

-關(guān)聯(lián)表示參與者與用例的交互路徑，用實線帶箭頭表示。

-依賴表示用例間的輔助關(guān)系，用虛線表示。

-泛化表示用例或參與者的繼承關(guān)系，用實線加空心箭頭表示。

（二）繪制規(guī)范

1.布局要求

-參與者位于圖的左側(cè)或右側(cè)，用例位于中央?yún)^(qū)域。

-關(guān)系線應(yīng)避免交叉，優(yōu)先橫向或縱向排列。

2.標(biāo)注要求

-用例名稱需加粗，參與者名稱需斜體。

-關(guān)系線上可標(biāo)注交互條件，如“登錄成功則訪問訂單”。

三、UML表詞圖應(yīng)用場景

（一）需求分析階段

1.確定系統(tǒng)邊界

-通過表詞圖明確系統(tǒng)功能范圍，排除非核心功能。

-示例：電商系統(tǒng)可包含“用戶注冊”“支付”“物流查詢”等用例。

2.定義交互流程

-繪制用例圖，標(biāo)注參與者與用例的交互順序。

-示例：用戶登錄流程可標(biāo)注為“輸入憑證→驗證→進(jìn)入系統(tǒng)”。

（二）系統(tǒng)設(shè)計階段

1.功能模塊劃分

-將復(fù)雜用例拆分為子用例，形成層次化結(jié)構(gòu)。

-示例：訂單管理可拆分為“創(chuàng)建訂單”“修改訂單”“取消訂單”。

2.用戶界面設(shè)計

-基于表詞圖設(shè)計交互界面，確保操作邏輯清晰。

-示例：購物車頁面需包含“添加商品”“調(diào)整數(shù)量”“結(jié)算”等操作。

四、操作流程

（一）繪制步驟

1.確定參與者

-列出所有與系統(tǒng)交互的外部實體。

-示例：在線教育系統(tǒng)參與者包括“學(xué)生”“教師”“管理員”。

2.繪制用例

-根據(jù)需求文檔，將功能點轉(zhuǎn)化為用例。

3.建立關(guān)系

-連接參與者和用例，標(biāo)注交互條件。

4.完善細(xì)節(jié)

-添加注解說明特殊場景，如異常處理流程。

（二）評審與修改

1.團(tuán)隊評審

-組織開發(fā)、測試人員對表詞圖進(jìn)行評審，確保無遺漏。

2.迭代優(yōu)化

-根據(jù)反饋調(diào)整用例邊界或交互邏輯。

五、注意事項

1.更新維護(hù)

-系統(tǒng)需求變更時需同步更新表詞圖，避免脫節(jié)。

2.工具選擇

-推薦使用AxureRP、Visio等建模工具，提高繪制效率。

一、概述

UML（統(tǒng)一建模語言）表詞圖（通常指UML用例圖UseCaseDiagram），是一種核心的UML圖，用于描繪系統(tǒng)的功能視圖，即系統(tǒng)所提供的服務(wù)以及使用這些服務(wù)的外部實體（參與者）。它幫助項目團(tuán)隊，包括開發(fā)人員、業(yè)務(wù)分析師和最終用戶，理解系統(tǒng)的邊界、主要功能和用戶與系統(tǒng)如何交互。表詞圖通過圖形化的方式，將復(fù)雜的系統(tǒng)需求轉(zhuǎn)化為直觀、易于溝通的模型。本細(xì)則旨在提供UML表詞圖的詳細(xì)繪制規(guī)范、標(biāo)準(zhǔn)應(yīng)用流程以及常見實踐，以確保其作為需求分析和溝通工具的有效性和一致性。

二、UML表詞圖繪制標(biāo)準(zhǔn)

（一）基本構(gòu)成要素

1.用例（UseCase）

用例是系統(tǒng)對外提供的、可被參與者明確感知到的功能或價值。它描述了系統(tǒng)為了滿足參與者需求所執(zhí)行的一系列動作序列。

圖形表示：用例通常用橢圓形繪制。

命名規(guī)范：

動詞短語開頭，表示系統(tǒng)做什么，例如：“登錄系統(tǒng)”、“查詢產(chǎn)品信息”、“下訂單”、“生成報告”。

語言應(yīng)清晰、簡潔、無歧義，準(zhǔn)確反映功能目的。

命名應(yīng)站在參與者的角度，描述他們能觀察到的結(jié)果。

標(biāo)注：橢圓形內(nèi)通常包含用例的名稱。有時，為了更詳細(xì)地說明用例的預(yù)條件（執(zhí)行前需滿足的條件）、后置條件（執(zhí)行后系統(tǒng)狀態(tài)）或基本流程，會使用內(nèi)部分隔線，將名稱分為三個部分：頂部分為用例名稱，中間為預(yù)條件，底部為后置條件。但更常見的是在橢圓外部使用注解（Note）或附件（Attachment）來描述這些詳細(xì)信息。

2.參與者（Actor）

參與者是與系統(tǒng)交互的外部實體，可以是人（如用戶、管理員）、其他系統(tǒng)（如外部API、數(shù)據(jù)庫）、或設(shè)備等。參與者代表發(fā)起用例或與用例進(jìn)行交互的對象。

圖形表示：參與者通常用小人圖標(biāo)（人形輪廓）表示。

分類：

內(nèi)部參與者：如果用例是系統(tǒng)內(nèi)部模塊之間調(diào)用，可以使用內(nèi)部參與者，通常用矩形加小人圖標(biāo)表示，并可能標(biāo)注“<<internal>>”。

外部參與者：大多數(shù)情況下指的是與系統(tǒng)邊界之外交互的實體。

命名規(guī)范：參與者名稱應(yīng)具體指明是哪個實體，例如：“普通用戶”、“管理員”、“結(jié)算系統(tǒng)”、“移動應(yīng)用”。

標(biāo)注：參與者名稱通常標(biāo)注在小人圖標(biāo)的下方，并使用斜體（Italic）表示。

3.關(guān)系（Relationship）

關(guān)系定義了參與者與用例之間的連接，以及用例之間的聯(lián)系。常見的用例關(guān)系包括關(guān)聯(lián)（Association）、依賴（Dependency）、泛化（Generalization）和擴(kuò)展（Include）、擴(kuò)展（Extend）。

（1）關(guān)聯(lián)（Association）

表示參與者與用例之間存在較穩(wěn)定、雙向的交互關(guān)系。通常暗示參與者可以多次與用例交互。

圖形表示：用實線連接參與者和用例。

箭頭：箭頭可以指明交互的發(fā)起方向，但通常不強(qiáng)制要求。如果需要強(qiáng)調(diào)，可以用帶箭頭的實線。

標(biāo)注：關(guān)聯(lián)線上可以標(biāo)注交互的頻率、條件或職責(zé)，例如：“每次登錄”、“僅當(dāng)權(quán)限允許”。

（2）依賴（Dependency）

表示參與者或用例之間的弱依賴關(guān)系。通常指一個元素的變更可能影響到另一個元素，但關(guān)系相對較小或臨時。

圖形表示：用虛線連接，并帶一個箭頭指向被依賴的元素。

適用場景：例如，某個用例在執(zhí)行過程中需要調(diào)用另一個小的輔助用例，但這個輔助用例并非該主要用例的常規(guī)部分。

（3）泛化（Generalization）

表示繼承關(guān)系，通常用于表示參與者或用例的共性。子參與者/子用例繼承父參與者/父用例的屬性和關(guān)系。

圖形表示：用實線連接，并帶一個空心箭頭指向父元素。

命名：箭頭旁常標(biāo)注“<<generalization>>”或直接使用“<:”。

適用場景：例如，系統(tǒng)中有多類用戶（如“普通用戶”、“VIP用戶”、“管理員”），它們都有“登錄”這個共同用例，可以通過泛化關(guān)系表示。

（二）繪制規(guī)范

1.布局要求

參與者位置：通常將參與者放置在用例圖的邊緣，左側(cè)或右側(cè)，表示外部實體。有時也可以根據(jù)交互邏輯放在頂部或底部。

用例位置：用例通常位于圖的中心區(qū)域，圍繞參與者排列。

關(guān)系線：關(guān)系線應(yīng)盡量保持簡潔、清晰，避免交叉和過于密集。優(yōu)先使用水平和垂直的直線。使用曲線時，應(yīng)避免過于復(fù)雜的弧度。

視覺平衡：圖形布局應(yīng)保持視覺上的平衡和對稱，便于閱讀和理解。

2.標(biāo)注要求

字體：用例名稱使用常規(guī)字體，參與者名稱使用斜體（Italic）。

顏色：可以使用不同的顏色區(qū)分不同的參與者或用例類型，但需保持一致性。

大?。簣D標(biāo)和文字大小應(yīng)適中，保證清晰可辨。

附加信息：對于復(fù)雜的用例，可以使用注解（Note，用矩形加折線邊框表示，并帶箭頭指向被解釋的元素）或附件（Attachment，用矩形加點線邊框表示）來提供預(yù)條件、后置條件、異常流程等詳細(xì)信息。注解和附件可以通過“粘附”線連接到相關(guān)元素。

三、UML表詞圖應(yīng)用場景

（一）需求分析階段

1.確定系統(tǒng)邊界

操作步驟：

(1)收集所有潛在的系統(tǒng)用戶和外部系統(tǒng)交互點。

(2)識別所有需要系統(tǒng)完成的功能點。

(3)在UML表詞圖上，將識別出的外部實體繪制為參與者，將系統(tǒng)功能繪制為用例。

(4)通過觀察參與者與用例的關(guān)系，明確哪些功能是系統(tǒng)核心必須提供的（內(nèi)部用例），哪些是與外部實體交互的界面（外部用例）。

(5)根據(jù)參與者能否直接與用例交互，以及用例是否跨越多個參與者，定義系統(tǒng)的清晰邊界。邊界內(nèi)的用例屬于系統(tǒng)責(zé)任，邊界外的用例由其他系統(tǒng)或外部環(huán)境負(fù)責(zé)。

示例：對于一個在線圖書館系統(tǒng)，參與者可能是“讀者”、“圖書管理員”；用例可能包括“借閱圖書”、“歸還圖書”、“查詢圖書”、“管理讀者”、“管理館藏”。通過繪制，可以清晰界定哪些是讀者可以直接操作的（借閱、歸還、查詢），哪些是管理員專屬的（管理讀者、管理館藏），從而確定系統(tǒng)的功能范圍。

2.定義交互流程

操作步驟：

(1)選擇一個核心用例（如“借閱圖書”）。

(2)識別主要參與者（如“讀者”）。

(3)繪制用例圖，突出顯示該用例及其參與者。

(4)使用文字描述、狀態(tài)機(jī)圖或活動圖（作為補(bǔ)充）來詳細(xì)說明參與者與用例之間的步驟、判斷條件和可能的分支。

(5)標(biāo)注異常情況的處理流程，如“圖書已借出”或“讀者超期未還”時的交互。

示例：在“借閱圖書”用例中，交互流程可能包括：讀者->查詢圖書；系統(tǒng)->返回圖書列表；讀者->選擇圖書；讀者->提供借閱憑證；系統(tǒng)->驗證憑證；系統(tǒng)->檢查圖書狀態(tài)；系統(tǒng)->記錄借閱信息；讀者->獲取圖書。同時，需要定義異常流程，如圖書不可借（讀者->被告知原因）、憑證無效（系統(tǒng)->提示錯誤信息）等。

（二）系統(tǒng)設(shè)計階段

1.功能模塊劃分

操作步驟：

(1)分析高層次的用例，識別出其中包含的復(fù)雜邏輯或可以獨立管理的子功能。

(2)在UML表詞圖上，將一個復(fù)雜的用例拆分為多個更小的、職責(zé)更集中的子用例。這些子用例可以作為未來設(shè)計中的功能模塊或服務(wù)。

(3)繪制新的用例圖，展示這些子用例之間的關(guān)系（如關(guān)聯(lián)、泛化）以及它們?nèi)绾喂餐瑢崿F(xiàn)父用例。

(4)明確每個子用例的輸入、輸出和核心業(yè)務(wù)邏輯。

示例：“管理訂單”這個大用例可以拆分為“創(chuàng)建訂單”、“修改訂單”、“查詢訂單狀態(tài)”、“取消訂單”、“支付訂單”等多個子用例。每個子用例都可以獨立設(shè)計，并通過“管理訂單”這個父用例（或通過聚合關(guān)系）組織起來。

2.用戶界面設(shè)計

操作步驟：

(1)將表詞圖中的用例視為用戶界面上的主要功能入口或頁面/視圖。

(2)分析參與者與每個用例的交互方式，確定界面元素（按鈕、表單、列表等）及其布局。

(3)設(shè)計用例對應(yīng)界面的交互流程，確保符合用戶習(xí)慣和用例描述的操作序列。

(4)UML表詞圖提供了設(shè)計起點，后續(xù)可以使用原型工具（如Axure,Figma）創(chuàng)建更詳細(xì)的線框圖或交互原型。

示例：“查詢產(chǎn)品信息”用例可以對應(yīng)到一個產(chǎn)品搜索頁面，包含搜索框（輸入查詢條件）、搜索按鈕（觸發(fā)用例）、產(chǎn)品列表展示區(qū)（顯示結(jié)果）。交互流程是用戶輸入->點擊搜索->頁面展示結(jié)果。

四、操作流程

（一）繪制步驟

1.確定參與者

具體操作：

(1)回顧需求文檔、用戶訪談記錄或業(yè)務(wù)流程圖，列出所有與系統(tǒng)交互的外部實體。

(2)與項目相關(guān)人員進(jìn)行討論，確認(rèn)參與者的完整性，排除非交互對象（如系統(tǒng)內(nèi)部組件）。

(3)為每個參與者命名，確保名稱準(zhǔn)確反映其身份或角色。

(4)判斷參與者類型（外部/內(nèi)部），并決定是否需要使用小人圖標(biāo)或內(nèi)部參與者表示。

2.繪制用例

具體操作：

(1)基于需求文檔中的功能列表或業(yè)務(wù)用例，將每個功能點或業(yè)務(wù)目標(biāo)轉(zhuǎn)化為一個用例。

(2)為每個用例賦予一個清晰、符合規(guī)范的名稱（動詞短語開頭）。

(3)使用UML工具（如Visio,StarUML,PlantUML,在線繪圖工具）或手繪，繪制橢圓形，并寫入用例名稱。

(4)初步考慮用例的預(yù)條件、后置條件和主要流程，思考是否需要添加內(nèi)部分隔線或計劃使用注解。

3.建立關(guān)系

具體操作：

(1)分析參與者需要執(zhí)行哪些用例，以及用例之間是否存在依賴、繼承等關(guān)系。

(2)使用相應(yīng)的線型（實線、虛線）和箭頭（有/無箭頭）繪制關(guān)系線。

(3)對于關(guān)聯(lián)關(guān)系，考慮是否需要標(biāo)注交互條件或頻率。

(4)對于泛化關(guān)系，確保父元素和子元素都正確繪制，并使用空心箭頭和標(biāo)注。

(5)檢查關(guān)系線的布局，確保清晰、無交叉，符合繪制規(guī)范。

4.完善細(xì)節(jié)

具體操作：

(1)對于復(fù)雜的用例，使用注解（Note）或附件（Attachment）添加預(yù)條件（Precondition）、后置條件（Postcondition）、異常流程（Alternative/ExceptFlow）、基本流程（MainFlow）等詳細(xì)信息。

(2)標(biāo)注圖例（如果圖中有特殊符號或約定）。

(3)添加圖名（如“XX系統(tǒng)用例圖”）和繪制者/日期信息。

(4)整體檢查圖形的清晰度、一致性和準(zhǔn)確性。

（二）評審與修改

1.團(tuán)隊評審

具體操作：

(1)組織需求分析師、開發(fā)人員、測試人員甚至業(yè)務(wù)代表一起審查繪制的UML表詞圖。

(2)檢查用例是否完整、準(zhǔn)確，是否覆蓋了所有需求。

(3)評估參與者與用例的關(guān)系是否合理，系統(tǒng)邊界是否清晰。

(4)討論圖中存在的歧義、遺漏或邏輯錯誤。

(5)收集所有評審人員的反饋意見。

2.迭代優(yōu)化

具體操作：

(1)根據(jù)評審反饋，整理修改意見清單。

(2)修改UML表詞圖，調(diào)整用例名稱、添加/刪除參與者、修改關(guān)系線等。

(3)對于重要的修改，可以再次組織小范圍評審，確保修改符合預(yù)期。

(4)重復(fù)評審和修改過程，直到圖被所有相關(guān)方認(rèn)可，或達(dá)到預(yù)定的迭代次數(shù)/時間點。

(5)最終確認(rèn)的UML表詞圖應(yīng)作為需求規(guī)格的一部分進(jìn)行版本控制。

五、注意事項

1.更新維護(hù)

具體要點：

系統(tǒng)需求是不斷變化的，UML表詞圖也需要同步更新。任何需求變更（如新增功能、修改用例、調(diào)整參與者）都應(yīng)反映在表詞圖上。

建立變更管理流程，確保每次更新都有記錄，并由相關(guān)人員確認(rèn)。

保持表詞圖與需求文檔、設(shè)計文檔等其他相關(guān)文檔的一致性。

定期（如每個開發(fā)迭代結(jié)束時）回顧和審查用例圖，清理過時或冗余的元素。

2.工具選擇

具體建議：

選擇合適的UML建模工具可以提高繪圖效率和準(zhǔn)確性。常見的工具包括：

商業(yè)工具：IBMRationalRose,OracleEnterpriseArchitect,SparxSystemsEnterpriseArchitect,AxureRP(支持部分UML功能),Visio(UML擴(kuò)展包)。

開源工具：StarUML,PlantUML(基于文本描述生成UML圖),ArgoUML。

在線工具：Lucidchart,draw.io(包含UML功能)。

選擇工具時考慮因素：易用性、功能完整性、團(tuán)隊熟悉度、成本、與現(xiàn)有開發(fā)環(huán)境的集成度。

無論使用何種工具，都應(yīng)遵循統(tǒng)一的繪圖風(fēng)格和規(guī)范，確保圖示清晰易懂。

3.溝通協(xié)作

具體要點：

UML表詞圖是溝通工具，應(yīng)使用所有項目成員都能理解的語言和符號。

在團(tuán)隊內(nèi)部推廣標(biāo)準(zhǔn)的繪制規(guī)范和圖例。

在需求討論、設(shè)計評審等會議中使用表詞圖進(jìn)行展示和解釋。

鼓勵團(tuán)隊成員對表詞圖提出疑問和建議，促進(jìn)共同理解。

4.適度復(fù)雜

具體要點：

避免過度建模，只為表達(dá)必要的信息。過于復(fù)雜的用例圖會變得難以閱讀和理解。

對于簡單的系統(tǒng)，一個清晰的用例圖可能就足夠了。對于大型復(fù)雜系統(tǒng)，可以考慮繪制多個用例圖，分別從不同視角（如按模塊、按用戶角色）展示系統(tǒng)功能。

將詳細(xì)的流程信息放在用例描述、活動圖或狀態(tài)機(jī)圖中，而不是過度擁擠在用例圖本身。

一、概述

UML（統(tǒng)一建模語言）表詞圖是一種用于描述系統(tǒng)用例和用戶交互的圖形化工具，廣泛應(yīng)用于軟件工程領(lǐng)域。它通過清晰的視覺化表達(dá)，幫助開發(fā)者和用戶理解系統(tǒng)功能、交互流程及邊界。本細(xì)則旨在規(guī)范UML表詞圖的繪制標(biāo)準(zhǔn)、應(yīng)用場景及操作流程，確保其在項目開發(fā)中發(fā)揮最大效用。

二、UML表詞圖繪制標(biāo)準(zhǔn)

（一）基本構(gòu)成要素

1.用例（UseCase）

-用例表示系統(tǒng)對外提供的功能或服務(wù)，用橢圓形表示。

-用例名稱需明確、簡潔，如“用戶登錄”“查詢訂單”。

2.參與者（Actor）

-參與者代表與系統(tǒng)交互的外部實體，如用戶、設(shè)備等，用小人圖標(biāo)表示。

-參與者需標(biāo)注名稱，如“管理員”“客戶”。

3.關(guān)系（Relationship）

-關(guān)系包括關(guān)聯(lián)（Association）、依賴（Dependency）和泛化（Generalization）。

-關(guān)聯(lián)表示參與者與用例的交互路徑，用實線帶箭頭表示。

-依賴表示用例間的輔助關(guān)系，用虛線表示。

-泛化表示用例或參與者的繼承關(guān)系，用實線加空心箭頭表示。

（二）繪制規(guī)范

1.布局要求

-參與者位于圖的左側(cè)或右側(cè)，用例位于中央?yún)^(qū)域。

-關(guān)系線應(yīng)避免交叉，優(yōu)先橫向或縱向排列。

2.標(biāo)注要求

-用例名稱需加粗，參與者名稱需斜體。

-關(guān)系線上可標(biāo)注交互條件，如“登錄成功則訪問訂單”。

三、UML表詞圖應(yīng)用場景

（一）需求分析階段

1.確定系統(tǒng)邊界

-通過表詞圖明確系統(tǒng)功能范圍，排除非核心功能。

-示例：電商系統(tǒng)可包含“用戶注冊”“支付”“物流查詢”等用例。

2.定義交互流程

-繪制用例圖，標(biāo)注參與者與用例的交互順序。

-示例：用戶登錄流程可標(biāo)注為“輸入憑證→驗證→進(jìn)入系統(tǒng)”。

（二）系統(tǒng)設(shè)計階段

1.功能模塊劃分

-將復(fù)雜用例拆分為子用例，形成層次化結(jié)構(gòu)。

-示例：訂單管理可拆分為“創(chuàng)建訂單”“修改訂單”“取消訂單”。

2.用戶界面設(shè)計

-基于表詞圖設(shè)計交互界面，確保操作邏輯清晰。

-示例：購物車頁面需包含“添加商品”“調(diào)整數(shù)量”“結(jié)算”等操作。

四、操作流程

（一）繪制步驟

1.確定參與者

-列出所有與系統(tǒng)交互的外部實體。

-示例：在線教育系統(tǒng)參與者包括“學(xué)生”“教師”“管理員”。

2.繪制用例

-根據(jù)需求文檔，將功能點轉(zhuǎn)化為用例。

3.建立關(guān)系

-連接參與者和用例，標(biāo)注交互條件。

4.完善細(xì)節(jié)

-添加注解說明特殊場景，如異常處理流程。

（二）評審與修改

1.團(tuán)隊評審

-組織開發(fā)、測試人員對表詞圖進(jìn)行評審，確保無遺漏。

2.迭代優(yōu)化

-根據(jù)反饋調(diào)整用例邊界或交互邏輯。

五、注意事項

1.更新維護(hù)

-系統(tǒng)需求變更時需同步更新表詞圖，避免脫節(jié)。

2.工具選擇

-推薦使用AxureRP、Visio等建模工具，提高繪制效率。

一、概述

UML（統(tǒng)一建模語言）表詞圖（通常指UML用例圖UseCaseDiagram），是一種核心的UML圖，用于描繪系統(tǒng)的功能視圖，即系統(tǒng)所提供的服務(wù)以及使用這些服務(wù)的外部實體（參與者）。它幫助項目團(tuán)隊，包括開發(fā)人員、業(yè)務(wù)分析師和最終用戶，理解系統(tǒng)的邊界、主要功能和用戶與系統(tǒng)如何交互。表詞圖通過圖形化的方式，將復(fù)雜的系統(tǒng)需求轉(zhuǎn)化為直觀、易于溝通的模型。本細(xì)則旨在提供UML表詞圖的詳細(xì)繪制規(guī)范、標(biāo)準(zhǔn)應(yīng)用流程以及常見實踐，以確保其作為需求分析和溝通工具的有效性和一致性。

二、UML表詞圖繪制標(biāo)準(zhǔn)

（一）基本構(gòu)成要素

1.用例（UseCase）

用例是系統(tǒng)對外提供的、可被參與者明確感知到的功能或價值。它描述了系統(tǒng)為了滿足參與者需求所執(zhí)行的一系列動作序列。

圖形表示：用例通常用橢圓形繪制。

命名規(guī)范：

動詞短語開頭，表示系統(tǒng)做什么，例如：“登錄系統(tǒng)”、“查詢產(chǎn)品信息”、“下訂單”、“生成報告”。

語言應(yīng)清晰、簡潔、無歧義，準(zhǔn)確反映功能目的。

命名應(yīng)站在參與者的角度，描述他們能觀察到的結(jié)果。

標(biāo)注：橢圓形內(nèi)通常包含用例的名稱。有時，為了更詳細(xì)地說明用例的預(yù)條件（執(zhí)行前需滿足的條件）、后置條件（執(zhí)行后系統(tǒng)狀態(tài)）或基本流程，會使用內(nèi)部分隔線，將名稱分為三個部分：頂部分為用例名稱，中間為預(yù)條件，底部為后置條件。但更常見的是在橢圓外部使用注解（Note）或附件（Attachment）來描述這些詳細(xì)信息。

2.參與者（Actor）

參與者是與系統(tǒng)交互的外部實體，可以是人（如用戶、管理員）、其他系統(tǒng)（如外部API、數(shù)據(jù)庫）、或設(shè)備等。參與者代表發(fā)起用例或與用例進(jìn)行交互的對象。

圖形表示：參與者通常用小人圖標(biāo)（人形輪廓）表示。

分類：

內(nèi)部參與者：如果用例是系統(tǒng)內(nèi)部模塊之間調(diào)用，可以使用內(nèi)部參與者，通常用矩形加小人圖標(biāo)表示，并可能標(biāo)注“<<internal>>”。

外部參與者：大多數(shù)情況下指的是與系統(tǒng)邊界之外交互的實體。

命名規(guī)范：參與者名稱應(yīng)具體指明是哪個實體，例如：“普通用戶”、“管理員”、“結(jié)算系統(tǒng)”、“移動應(yīng)用”。

標(biāo)注：參與者名稱通常標(biāo)注在小人圖標(biāo)的下方，并使用斜體（Italic）表示。

3.關(guān)系（Relationship）

關(guān)系定義了參與者與用例之間的連接，以及用例之間的聯(lián)系。常見的用例關(guān)系包括關(guān)聯(lián)（Association）、依賴（Dependency）、泛化（Generalization）和擴(kuò)展（Include）、擴(kuò)展（Extend）。

（1）關(guān)聯(lián)（Association）

表示參與者與用例之間存在較穩(wěn)定、雙向的交互關(guān)系。通常暗示參與者可以多次與用例交互。

圖形表示：用實線連接參與者和用例。

箭頭：箭頭可以指明交互的發(fā)起方向，但通常不強(qiáng)制要求。如果需要強(qiáng)調(diào)，可以用帶箭頭的實線。

標(biāo)注：關(guān)聯(lián)線上可以標(biāo)注交互的頻率、條件或職責(zé)，例如：“每次登錄”、“僅當(dāng)權(quán)限允許”。

（2）依賴（Dependency）

表示參與者或用例之間的弱依賴關(guān)系。通常指一個元素的變更可能影響到另一個元素，但關(guān)系相對較小或臨時。

圖形表示：用虛線連接，并帶一個箭頭指向被依賴的元素。

適用場景：例如，某個用例在執(zhí)行過程中需要調(diào)用另一個小的輔助用例，但這個輔助用例并非該主要用例的常規(guī)部分。

（3）泛化（Generalization）

表示繼承關(guān)系，通常用于表示參與者或用例的共性。子參與者/子用例繼承父參與者/父用例的屬性和關(guān)系。

圖形表示：用實線連接，并帶一個空心箭頭指向父元素。

命名：箭頭旁常標(biāo)注“<<generalization>>”或直接使用“<:”。

適用場景：例如，系統(tǒng)中有多類用戶（如“普通用戶”、“VIP用戶”、“管理員”），它們都有“登錄”這個共同用例，可以通過泛化關(guān)系表示。

（二）繪制規(guī)范

1.布局要求

參與者位置：通常將參與者放置在用例圖的邊緣，左側(cè)或右側(cè)，表示外部實體。有時也可以根據(jù)交互邏輯放在頂部或底部。

用例位置：用例通常位于圖的中心區(qū)域，圍繞參與者排列。

關(guān)系線：關(guān)系線應(yīng)盡量保持簡潔、清晰，避免交叉和過于密集。優(yōu)先使用水平和垂直的直線。使用曲線時，應(yīng)避免過于復(fù)雜的弧度。

視覺平衡：圖形布局應(yīng)保持視覺上的平衡和對稱，便于閱讀和理解。

2.標(biāo)注要求

字體：用例名稱使用常規(guī)字體，參與者名稱使用斜體（Italic）。

顏色：可以使用不同的顏色區(qū)分不同的參與者或用例類型，但需保持一致性。

大?。簣D標(biāo)和文字大小應(yīng)適中，保證清晰可辨。

附加信息：對于復(fù)雜的用例，可以使用注解（Note，用矩形加折線邊框表示，并帶箭頭指向被解釋的元素）或附件（Attachment，用矩形加點線邊框表示）來提供預(yù)條件、后置條件、異常流程等詳細(xì)信息。注解和附件可以通過“粘附”線連接到相關(guān)元素。

三、UML表詞圖應(yīng)用場景

（一）需求分析階段

1.確定系統(tǒng)邊界

操作步驟：

(1)收集所有潛在的系統(tǒng)用戶和外部系統(tǒng)交互點。

(2)識別所有需要系統(tǒng)完成的功能點。

(3)在UML表詞圖上，將識別出的外部實體繪制為參與者，將系統(tǒng)功能繪制為用例。

(4)通過觀察參與者與用例的關(guān)系，明確哪些功能是系統(tǒng)核心必須提供的（內(nèi)部用例），哪些是與外部實體交互的界面（外部用例）。

(5)根據(jù)參與者能否直接與用例交互，以及用例是否跨越多個參與者，定義系統(tǒng)的清晰邊界。邊界內(nèi)的用例屬于系統(tǒng)責(zé)任，邊界外的用例由其他系統(tǒng)或外部環(huán)境負(fù)責(zé)。

示例：對于一個在線圖書館系統(tǒng)，參與者可能是“讀者”、“圖書管理員”；用例可能包括“借閱圖書”、“歸還圖書”、“查詢圖書”、“管理讀者”、“管理館藏”。通過繪制，可以清晰界定哪些是讀者可以直接操作的（借閱、歸還、查詢），哪些是管理員專屬的（管理讀者、管理館藏），從而確定系統(tǒng)的功能范圍。

2.定義交互流程

操作步驟：

(1)選擇一個核心用例（如“借閱圖書”）。

(2)識別主要參與者（如“讀者”）。

(3)繪制用例圖，突出顯示該用例及其參與者。

(4)使用文字描述、狀態(tài)機(jī)圖或活動圖（作為補(bǔ)充）來詳細(xì)說明參與者與用例之間的步驟、判斷條件和可能的分支。

(5)標(biāo)注異常情況的處理流程，如“圖書已借出”或“讀者超期未還”時的交互。

示例：在“借閱圖書”用例中，交互流程可能包括：讀者->查詢圖書；系統(tǒng)->返回圖書列表；讀者->選擇圖書；讀者->提供借閱憑證；系統(tǒng)->驗證憑證；系統(tǒng)->檢查圖書狀態(tài)；系統(tǒng)->記錄借閱信息；讀者->獲取圖書。同時，需要定義異常流程，如圖書不可借（讀者->被告知原因）、憑證無效（系統(tǒng)->提示錯誤信息）等。

（二）系統(tǒng)設(shè)計階段

1.功能模塊劃分

操作步驟：

(1)分析高層次的用例，識別出其中包含的復(fù)雜邏輯或可以獨立管理的子功能。

(2)在UML表詞圖上，將一個復(fù)雜的用例拆分為多個更小的、職責(zé)更集中的子用例。這些子用例可以作為未來設(shè)計中的功能模塊或服務(wù)。

(3)繪制新的用例圖，展示這些子用例之間的關(guān)系（如關(guān)聯(lián)、泛化）以及它們?nèi)绾喂餐瑢崿F(xiàn)父用例。

(4)明確每個子用例的輸入、輸出和核心業(yè)務(wù)邏輯。

示例：“管理訂單”這個大用例可以拆分為“創(chuàng)建訂單”、“修改訂單”、“查詢訂單狀態(tài)”、“取消訂單”、“支付訂單”等多個子用例。每個子用例都可以獨立設(shè)計，并通過“管理訂單”這個父用例（或通過聚合關(guān)系）組織起來。

2.用戶界面設(shè)計

操作步驟：

(1)將表詞圖中的用例視為用戶界面上的主要功能入口或頁面/視圖。

(2)分析參與者與每個用例的交互方式，確定界面元素（按鈕、表單、列表等）及其布局。

(3)設(shè)計用例對應(yīng)界面的交互流程，確保符合用戶習(xí)慣和用例描述的操作序列。

(4)UML表詞圖提供了設(shè)計起點，后續(xù)可以使用原型工具（如Axure,Figma）創(chuàng)建更詳細(xì)的線框圖或交互原型。

示例：“查詢產(chǎn)品信息”用例可以對應(yīng)到一個產(chǎn)品搜索頁面，包含搜索框（輸入查詢條件）、搜索按鈕（觸發(fā)用例）、產(chǎn)品列表展示區(qū)（顯示結(jié)果）。交互流程是用戶輸入->點擊搜索->頁面展示結(jié)果。

四、操作流程

（一）繪制步驟

1.確定參與者

具體操作：

(1)回顧需求文檔、用戶訪談記錄或業(yè)務(wù)流程圖，列出所有與系統(tǒng)交互的外部實體。

(2)與項目相關(guān)人員進(jìn)行討論，確認(rèn)參與者的完整性，排除非交互對象（如系統(tǒng)內(nèi)部組件）。

(3)為每個參與者命名，確保名稱準(zhǔn)確反映其身份或角色。

(4)判斷參與者類型（外部/內(nèi)部），并決定是否需要使用小人圖標(biāo)或內(nèi)部參與者表示。

2.繪制用例

具體操作：

(1)基于需求文檔中的功能列表或業(yè)務(wù)用例，將每個功能點或業(yè)務(wù)目標(biāo)轉(zhuǎn)化為一個用例。

(2)為每個用例賦予一個清晰、符合規(guī)范的名稱（動詞短語開頭）。

(3)使用UML工具（如Visio,StarUML,PlantUML,在線繪圖工具）或手繪，繪制橢圓形，并寫入用例名稱。

(4)初步考慮用例的預(yù)條件、后置條件和主要流程，思考是否需要添加內(nèi)部分隔線或計劃使用注解。

3.建立關(guān)系

具體操作：

(1)分析參與者需要執(zhí)行哪些用例，以及用例之間是否存在依賴、繼承等關(guān)系。

(2)使用相應(yīng)的線型（實線、虛線）和箭頭（有/無箭頭）繪制關(guān)系線。

(3)對于關(guān)聯(lián)關(guān)系，考慮是否需要標(biāo)注交互條件或頻率。

(4)對于泛化關(guān)系，確保父元素和子元素都正確繪制，并使用空心箭頭和標(biāo)注。

(5)檢查關(guān)系線的布局，確保清晰、無交叉，符合繪制規(guī)范。

4.完善細(xì)節(jié)

具體操作：

(1)對于復(fù)雜的用例，使用注解（Note）或附件（Attachment）添加預(yù)條件（Precondition）、后置條件（Postcondition）、異常流程（Alternative/ExceptFlow）、基本流程（MainFlow）等詳細(xì)信息。

(2)標(biāo)注圖例（如果圖中有特殊符號或約定）。

(3)添加圖名（如“XX系統(tǒng)用例圖”）和繪制者/日期信息。

(4)整體檢查圖形的清晰度、一致性和準(zhǔn)確性。

（二）評審與修改

1.團(tuán)隊評審

具體操作：

(1)組織需求分析師、開發(fā)人員、測試人員甚至業(yè)務(wù)代表一起審查繪制的UML表詞圖。

(2)檢查用例是否完整、準(zhǔn)確，是否覆蓋了所有需求。

(3)評估參與者與用例的關(guān)系是否合理，系統(tǒng)邊界是否清晰。

(4)討論圖中存在的歧義、遺漏或邏輯錯誤。

(5)收集所有評審人員的反饋意見。

2.迭代優(yōu)化

具體操作：

(1)根據(jù)評審反饋，整理修改意見清單。

(2)修改UML表詞圖，調(diào)整用例名稱、添加/刪除參與者、修改關(guān)系線等。

(3)對于重要的修改，可以再次組織小范圍評審，確保修改符合預(yù)期。

(4)重復(fù)評審和修改過程，直到圖被所有相關(guān)方認(rèn)可，或達(dá)到預(yù)定的迭代次數(shù)/時間點。

(5)最終確認(rèn)的UML表詞圖應(yīng)作為需求規(guī)格的一部分進(jìn)行版本控制。

五、注意事項

1.更新維護(hù)

具體要點：

系統(tǒng)需求是不斷變化的，UML表詞圖也需要同步更新。任何需求變更（如新增功能、修改用例、調(diào)整參與者）都應(yīng)反映在表詞圖上。

建立變更管理流程，確保每次更新都有記錄，并由相關(guān)人員確認(rèn)。

保持表詞圖與需求文檔、設(shè)計文檔等其他相關(guān)文檔的一致性。

定期（如每個開發(fā)迭代結(jié)束時）回顧和審查用例圖，清理過時或冗余的元素。

2.工具選擇

具體建議：

選擇合適的UML建模工具可以提高繪圖效率和準(zhǔn)確性。常見的工具包括：

商業(yè)工具：IBMRationalRose,OracleEnterpriseArchitect,SparxSystemsEnterpriseArchitect,AxureRP(支持部分UML功能),Visio(UML擴(kuò)展包)。

開源工具：StarUML,PlantUML(基于文本描述生成UML圖),ArgoUML。

在線工具：Lucidchart,draw.io(包含UML功能)。

選擇工具時考慮因素：易用性、功能完整性、團(tuán)隊熟悉度、成本、與現(xiàn)有開發(fā)環(huán)境的集成度。

無論使用何種工具，都應(yīng)遵循統(tǒng)一的繪圖風(fēng)格和規(guī)范，確保圖示清晰易懂。

3.溝通協(xié)作

具體要點：

UML表詞圖是溝通工具，應(yīng)使用所有項目成員都能理解的語言和符號。

在團(tuán)隊內(nèi)部推廣標(biāo)準(zhǔn)的繪制規(guī)范和圖例。

在需求討論、設(shè)計評審等會議中使用表詞圖進(jìn)行展示和解釋。

鼓勵團(tuán)隊成員對表詞圖提出疑問和建議，促進(jìn)共同理解。

4.適度