用例多登錄選項

Question

我有一個用戶可以通過正常登錄，以及社交登錄，如Twitter，Google，Facebook登錄的用例。我畫下面的用例，但不確定它是否正確。

登錄帳戶---延伸--->正常登錄
---延伸---> Twitter的登錄
---延伸--->谷歌登錄
---延伸---> Facebook登錄

Answer 1

<<extends>>反之亦然。

我很累，總是告訴這個，但Login account不是用例。它不會給演員帶來任何價值。這是一個簡單的約束，適用於其他真實用例。

此外：避免使用<<extends>>/<<include>>。它們是您嘗試對您的用例進行功能分析的標誌。相反，綜合使用的案例會產生很大的差異。如果你的用例圖開始像一個蜘蛛網，你的設計就會被破壞。

推薦閱讀：Bittner/Spence。

Answer 2

一般來說，我傾向於同意Thomas Kilian對於登錄用例的小心，因爲他們通常不會通過老闆測試。

如果我做[ - 插入使用案例 - ] 100次，我的老闆會高興嗎？

但用例的使用方式很多，對於很多不同的系統也是如此。如果你的系統是身份驗證服務，那麼我猜登錄可能是一個重要的用例。

無論如何，擴展關係是非常錯誤的。 在社區中，還有一個激烈的爭論是什麼延伸真正意義，以及如何使用它。我通常建議不要使用擴展。 但是如果你想保留它們，那麼你可能需要反過來做。

擴展用例在執行擴展用例（擴展點）的特定位置向擴展用例插入一些特定功能。擴展用例不瞭解擴展用例。

擴展可能不是你在這裏需要的。

我可能不會涉及那麼多的細節，並堅持單一的登錄用例（如果有的話）。你可以使可選場景，對Facebook，微博，谷歌等...

但如果你真的需要在你的用例模型如此詳細的話，我會用概括

正如你所看到的有一個抽象用例登錄。這三個其他的具體的用例從這個用例繼承而來。

在分析中沒有正確或錯誤的答案。只有更好或更差的答案，這一切都很大程度上取決於你的模型的目的。

Answer 3

我認爲你的用例有點過於技術性。在識別用例時，您需要回顧幾次，以確保完整的用例是有意義的。這通常意味着一些用例被合併爲一個用例，其他用例被合併爲一個，其他用例被拆分等。

區分用例時要問的關鍵問題是「這兩個用例對演員有意義的區別？你不應該問「有沒有不同的方法來實現這個功能？」或「實施是否需要支持幾種不同的協議？」這些都是設計問題，應該記錄在用例中，而不是記錄在實現它們的協作中。通過幾種不同的替代協作實現一個用例是UML的完全有效和正常的使用。

在這種情況下，它的問題他們如何登錄或僅是其重要是他們登錄的用戶？我懷疑後者，在這種情況下，應該只有一個用例。