2014-01-06 21 views
1

我有一個懷疑涉及UML使用案例圖。有關與類型描述字段相關的UML用例圖的一些說明?

如果我有,我有以下情況的應用程序:

用戶可以點擊一個按鈕在一個名爲標籤我的雲端顯示,顯示虛擬驅動器列表的視圖。在這種觀點我也有一個按鈕,命名爲:添加新的虛擬驅動器,如果此按鈕,用戶點擊可以添加一個新的虛擬驅動器

那麼什麼是虛擬光驅是不是很重要,不管在這個特定的如果虛擬驅動器是我係統上的虛擬硬盤。

所以我必須用UML 用例圖來正式確定這種情況。

演員用戶與我的應用程序進行交互

所以我認爲,我有一個代表situationmin這對我的雲端按鈕,用戶點擊看到的第一個使用案例當前可用的虛擬驅動器列表。

使用的這種使用情況是這樣的一個表rappresentation:

ID:UC01用例:關於可用 虛擬驅動器顯示的詳細信息

說明:功能操作表示用戶的請求 以顯示有關其有權訪問的虛擬驅動器的詳細信息 。

類型: PRIMARY,是由用戶直接調用的系統的函數。

參與者:用戶(主要演員),應用程序/服務器(次要演員)。

前提條件:用戶必須在該系統和 圖形界面,允許 相互作用與它必須已經顯示被記錄。

主要方案(操作的正常過程):上 用戶點擊我的雲端按鈕 到主表格菜單和關於可用的虛擬驅動器 詳細 信息將顯示在一個表。

後置在成功的情況下:對於每個可用的虛擬驅動器是 顯示以下 信息:某些信息(這裏並不重要)。

後置失敗的情況下:沒有預料到這種情況時, 應該有 未能執行此操作的任何情況下。

好的,我認爲這個模板是正確的,並且前面的用例是可以的。在這個時候,我只是有一個疑問與以前的模板類型場。

我有:

類型: PRIMARY,是由 用戶直接調用的系統的功能。

我在搜索關於這個描述字段的信息,而且我什麼也沒找到......所以推理我已經這樣解釋了:「如果用戶直接調用系統函數的用例類型表示此功能有初級的類型字段的值」

是它好不好?

現在我必須表示與第二個功能相關的用例:重要的觀察結果是我可以執行第二個操作(添加一個新的虛擬驅動器)只有當我第一次運行第一個操作時(顯示列表可用的虛擬驅動器)。

所以我有這樣的事情:

ID:UCO 2使用案例:一個新的虛擬驅動器添加到繳費 虛擬驅動器的列表

說明:代表功能操作用戶的請求到新的虛擬 驅動器添加到虛擬繳費驅動器的列表。

類型: ?????????????

參與者:用戶(主要演員),應用程序/服務器(次要演員)。

前提條件:用戶必須登錄到系統中,用戶必須證明相關我的雲端按鈕視圖

後置條件在成功的情況下:出現一個新的觀點,即允許用戶在一個新的虛擬 驅動器添加到虛擬繳費驅動器的列表。

發生失敗時的後續條件:這種情況不是預期的,應該沒有發生 執行此操作失敗的情況。

現在我的疑問是關於類型這個二次使用案例的描述字段。

此功能由用戶直接調用的話,使用前面的推理,這必須PRIMARY(如前面的用例)

但在其他地方(在另一個例子中),我發現,在這種類型描述字段的值必須是SECONDARY因爲它依賴於第一個用例(因爲用戶首先必須調用顯示所有可用虛擬驅動器列表的操作,然後他可以添加一個新的虛擬驅動器)

S o,你能幫我對這個話題做一些澄清嗎?

TNX

安德烈

回答

1

就像你在這個問題上絆倒了,你的讀者可能不熟悉使用的術語(「類型=主」)。然而,你的反對意見是要明確一點。

所以我會去儘可能明確的解決方案:

您可以使用<<extend>>關係從UC 2至UC 1澄清關於UC 1.依賴性下降書面情況說明在UC前提描述其中規定純文本中執行順序的依賴性。

用例並不意味着在執行時間或順序中指定依賴關係。如果你需要,使用UML活動圖或UML序列圖,因爲它們使得這更清晰。您還可以大大降低您的意見被意外忽略的風險。

在你的圖中,你可以放一個UML註釋,提示這些UC有另一個圖。一些工具允許超鏈接到另一個圖表。