用例圖中擴展關係的用法是否正確？

Question

我開發的圖像搜索

移動應用這是我用例圖

演員=智能手機用戶

系統=客戶端應用程序

查詢在被髮送到服務器之前在客戶端被預先處理（例如，聲音查詢被轉換爲文本查詢）

我應該將這個用例添加到我的圖中嗎？

我認爲這是可能是長時間使用cqse這樣

Answer 1

首先「作爲一般的建議」：？

我要補充這個「不要問浪費你的時間‘’因爲你 是唯一的傢伙誰又能說這只是？問自己：顯示或 加給你的圖中，有什麼樣的好處，你會得到

建模意味着顯示隱藏的細節重要的概念您是 了一個誰將會確定哪些是重要的，什麼是細節。因爲你會執行系統和讓你的手變髒。

其次 「Techically」

擴展意味着 「執行用例/情景」 是可選的或有條件的。

因此，如果「pretreat查詢」[我不知道它是什麼 意味着什麼。不管它是什麼]可選地基於條件執行[ 假設當x條件在「查詢」用例時爲真，則 「pretreat query」用例/場景將被執行]，它在技術上是對的使用擴展關係。 所以你可以自己作出判斷 。

最後：技術上正確並不意味着它是正確的。

只要有可能儘量不要使用「包括」或「擴展」 關係。它們使您的用例和圖表更加複雜。

首先編寫使用您的用例作爲文本然後，如果您發現「相同的 方案」在您的用例中提出它們作爲單獨的用例。使用 「include」將這些常見使用案例/方案附加到主要使用案例/方案中。使用擴展「關係」，每當您發現/發現新的 重要場景可選由主用例執行。

我的個人想法：

對於我來說，你應該甚至不顯示您的圖表中的「創建查詢」 [當然在寫用例，如果所有的這3個用例作出查詢。同樣的方法，把它作爲一個單獨的用例寫出來，然後將主要的用例場景文本包括進去，使用包含關係是節省時間的。這沒有什麼錯。小心我說「在將用例作爲文本寫入」時）。

主要問題是「我應該在我的用例圖中展示它」。所以你應該問，誰會​​閱讀我的用例圖？或者爲什麼我創建這樣的圖表？根據你的情況做出你自己的判斷。務實。

更多信息：

用例是使用系統實現目標「文本故事」的一些演員。 在你的情況下你的演員是智能手機用戶。

那麼問問自己用戶想用你的系統做什麼？

1. 拍照。 [聲音合理]

2. 類型鍵盤 [聲音不好]：爲什麼他/她鍵入鍵盤？她/他的主要目標是什麼？也許你的意思是搜索一張照片......在這種情況下，「打字鍵盤」不是一個很好的用例。要搜索圖片，他可能會用鍵盤圖片名稱來編寫。但鍵入鍵盤不是他/她的主要目標：它是「搜索文本文本」用例的一部分。

3. 說吧？他爲什麼說？記錄他的聲音？或者用聲音搜索照片。又是主要目標？ [通過語音搜索用例]
4. 查詢：查詢是「開發人員」術語。當然，當你實現你的系統時，你需要查詢數據庫。但用例不適用於開發。它們用於捕獲用戶需求。但是，如果在您的使用情況下，你根據查看用戶點在很多使用情況「查詢」做相同的步驟，在使用它「包含」關係是OKEY

5. 款待查詢：[變換聲樂查詢文本查詢]所以這不是一個用例。這可能是步的「語音搜索」的一部分： 當你寫你的使用情況文本「語音搜索」：

   主要手段：

   1. 智能手機用戶告訴畫面名稱的搜索語音。
   2. 圖像搜索應用程序記錄此語音並生成文本查詢。
   3. 圖像搜索應用程序執行此查詢。
   4. 圖片搜索應用程序顯示的查詢

   的結果......

   替代方案

   2）圖像搜索應用程序無法識別的聲音： .....

   對我來說，這甚至會增加不必要的技術細節：我們可能不會提到步驟2.請說： 「圖像搜索應用程序搜索名稱由聲音給出的圖片」。 從語音生成文本查詢是實現細節。您將如何實現。 但用例焦點是「用戶可以使用您的應用程序做什麼」。

不要忘了用例不圖：用例圖是給你的系統的主要功能概述視覺上剛剛好。 用例是「文本故事」。在你的使用情況

，通常用最低擴展，包括泛化關係 diagrams.Do沒有浪費太多時間：

所以有很多的方式來表達他們的用例圖在用例中確定 關係。

對於來自他的暢銷書好，免費使用案例資源檢查Craig Larman與提供的免費章節：

Use Case Primer

Answer 2

首先我會用<<include>>代替<<extend>的。 `<<extend>>爲擴展用例定義了補充和可選行爲，並且擴展用例不需要這種行爲來使其工作。另一方面，<<include>>顯示的行爲是增加了到包含用例。此外，由於此行爲是您在make query用例中所做的操作的一部分;只需在make query用例的描述中對其進行描述即可。