顯示除“<< extend >>”或“<< include >>”之外的UML用例圖的依賴關系

Question

我們如何在“擴展”或“包含”之外的用例之間顯示簡單的依賴關系。 例如，我們想說用例1取決於user1完成的用例2。 可以用一個簡單的箭頭嗎？ 哪個方向？

Answer 1

是。 還有其他依賴項。

直接連接到Use Case的完整類列表（UML 2.5標准的圖18.1）：

• 用例
• 約束
• 演員
• 包括
• 延伸
• 延伸點

但這並不意味着您不能在圖表中使用Use Cases中的其他UML元素。 UML標准不限制圖表中的任何元素。 您甚至可以在一個圖表上使用所有UML元素。 另一方面，那當然是毫無意義的。

例如，可以看到可用的實際集合，例如，查看VP UML的用例調色板上的元素。 除了已經提到的，還有：

• 系統
• 依賴
• 概括
• 實現
• 合作
• 注意
• 錨
• 遏制

在這里，您可以看到帶有解釋的縮短列表。

如您所見，依賴性不僅允許標准（所有都是），而且被廣泛使用。

Answer 2

您有多種可能性來顯示Use-Cases之間的依賴關系。 您可以使用比<< extend >>和<< includes >>更多的關鍵字。

1. << requires >> - 表示UC2首先要求執行UC1。
2. << follow >> - 表示此用例是在另一個用例之后立即執行的。
3. <<類似>> - 意味着，這個用例在結果和前提條件中類似於另一個，但得到不同的活動
4. << equivalent >> - 相同的用例，但有一個不同的名稱。

在你的情況下，我會從actor（user1）到case1繪制一個箭頭，然后case1 << includes >> case2。 您始終需要記住的是圖表的用途。 如果您使用UML作為草圖，那么足以確保圖表是可理解的並且在范圍內。 超出規范不會支持這一點。

Answer 3

你說：“用例1依賴於用戶2完成的用例2”。

你能澄清一下嗎？ UC1如何依賴 UC2？

UC建模可能非常棘手。 建模人員相對容易忘記UC實際上是什么，並在模型中混合其他一些系統問題。

UC模型不應表示從底層系統結構派生的依賴性。 例如，如果UC1實現了也用於UC2實現的組件，則UC模型本身不會顯示這種情況。 您所談論的依賴關系是否成熟？

兩個UC之間的執行順序通常也隱藏在圖中（可以通過前置條件和后置條件間接顯示，但不使用關系）。

我的建議是盡可能簡化UC模型，並將關系限制為適度使用include和extend 。 UC可以被視為交互的抽象，是演員和系統之間的對話。 對話如何依賴於其他對話？