UML用例圖的問題

Question

我有一個關於用例圖中幾個問題：

• 如果我的系統中已註冊/登錄用例的客人，是否應該爲管理員啓用，用戶（我只是想澄清，如果我有登錄系統，我假設管理員，用戶等是誰已登錄到系統的人，所以我跳過他們與記錄的東西）？

• 如果我的系統有一個學生演員，即正在簽署個人研討會/課程，我是否（或已被允許）在爲他們唱歌之後爲他們製作用例，並且應該還有是那些2

• 如果我的老師從學生演員繼承之間的關係，因爲他可以瀏覽課程呢？ （等管理？）

• 是我支付的設置是否正確？

Answer 1

1. 請記住，這些是角色而不是人。管理員可以是客人，只要他們的行爲完全像猜測，沒有特殊的功能或規則。但是，在登錄過程中，用戶角色可能會更改，成爲管理員。注意你在某種意義上缺少認證用戶，每個需要安全性的用例都應該包含它，通常不會擴展。
2. 僅當它與系統交互時，例如觸發自動完成或以某種方式進行跟蹤。關係通常不是必需的，協會可以幫助傳達一些不明確的東西，但我不確定在這種情況下會發生什麼。
3. 不是，真的那麼這個角色是任何用戶一旦通過認證就可以瀏覽課程。你可以有學生，管理員，教師是子類型的認證或相關人等
4. 依賴。首先，你從來不會同時付費和註冊，所以從用戶的角度來看，這是不合時宜的。 UML中還有其他一些方法可以將課程支付的這一約束連接起來。流程圖，狀態圖等。由於付款確實是一項長期運行的交易，難以確定。我將親自展示學生和外部支付系統與「支付」用例進行交互。

記住，除非您在大多數時間生成代碼，否則UML是關於溝通的，因此瞭解您的受衆。不要害怕使用評論或約束，如果這是作業，使用約束並獲得一些真正的觀點。甚至可能會限制簽名和付費課程用例。

Answer 2

1. 如果您希望管理員能夠登錄，在那他將有一個用例。我同意他很可能不會註冊，所以也許你想打破註冊/登錄到兩個用例？
2. 您不必製作「Take Class」用例。只有這樣做，如果這就是用戶將如何與系統進行交互。我的猜測是，他不會在系統中「帶」課，在這種情況下，它不會成爲系統的使用案例。
3. 我會認爲你不想從學生繼承。首先，從現實的角度來看，這是沒有意義的。那意味着一位老師是一名學生。您可以將該行爲提取到另一個父類，但這可能會導致層次太大而令人困惑。
4. 如果你問它是否是正確的說「簽署課程」包括「付出當然，」那麼也許，它可能更好地使用擴展。

另一項建議。在演員和用例之間的黑色箭頭（通常意味着UML中的「依賴」）應該可能是雙向的，不帶箭頭的行（通常稱爲「關聯」）。至少這就是UML標準所說的。