關於UML的問題用例圖

我在創建的示例應用程序中爲各種場景創建用例圖。這是純粹的學習，實際上並沒有超越UML圖規劃階段實現。關於UML的問題用例圖

這個移動應用程序的概念是一個健身計劃。用戶可以輸入他在健身房中所做的事情，可以看到他的活動結果等。一次只有一個用戶，認爲是iPhone應用程序。

所以，我是否正確地假設這樣的事情將會涉及的唯一的演員將是應用程序用戶本身？其他一切都將由系統處理。

因此，爲了我的問題的目的，我想列出應用程序用戶在使用此應用程序時可能遇到的5個假設情形。

1. User creates an account in the application 
2. User creates his own custom exercise he can perform 
3. User checks his fitness stats/activity/data (whatever you wanna call it) 
4. User exercises! (Records new data into the application)

所以我的問題是，這一切都將被編譯成1個單一的UML用例圖？那麼它會看起來像A還是B？

Use Case Choices

因此，對於這樣的應用程序將所有由應用用戶的可能用途被封裝成一個單一的用例圖（A）？還是應該將它分解爲每個場景（B）的多個用例圖？還是我一起錯過了大局？用例圖假設是隱藏實現細節還是應該進一步闡述？我沒有使用任何< <擴展>>或< <這裏包括>>關係，因爲我不確定是否應該進入更深入的實現細節。

想法？

來源

2014-04-02 asdf

選擇A是首選，因爲它讓讀者一眼就能看到更廣泛的用例。隨着您擁有更多參與者，這變得更加重要：應用程序用戶，技術支持，系統管理員等。一些用例被多個參與者使用，並且通過在單個關係圖上包含多個參與者和多個用例而變得清晰。

來源

2014-04-02 15:07:46 Bruce

現在將A作爲整個系統的用例圖，然後針對每個個案更詳細地分析實施細節的用例圖。感謝您的回覆 – asdf

嵌套用例圖沒有太多價值。它們應該用來顯示系統的範圍和行爲的背景，所以它們應該處於高水平。深入探索用例往往最終會出現在捕獲特定場景的活動圖和序列圖中。 – Bruce

A是definitelly更好。

始終組相關一個圖表上的用例（或其他元素）可幫助讀者理解上下文。

這方面可以有很多的東西，比如： - 一個功能模件 - 單個演員使用情況 - 所有的用例（如果問題是小 - 使用情況下可從同一頁面訪問，像你的）。 - 不管你覺得有用

有一個圖上單一的UC只有缺點： - 更多的圖表繪製（少生產力/效率） - 用例之間的關係丟失（少清晰度） - 模型較大並且難以搜索，導航，維護

還要記住UC是一組場景而不是單個場景！

來源

2014-04-09 10:09:34 Aleks

關於UML的問題用例圖

回答

相關問題