UML 用例圖

Question

我正在為以下場景繪制 UML 用例圖：

1. 外部系統提供了一個事件 - 我認為這里的演員將是生成的事件
2. 系統攝取事件
3. 系統豐富活動
4. 系統將豐富的事件與系統中存在的一些數據相關聯
5. 如果系統發現一個命中通知被發送給人類演員
6. 如果不是，則丟棄事件

所以我的 2 個參與者是：這個外部系統生成的事件和接收通知的用戶。

• 事件調用用例Ingest 事件用例
• 外部用戶使用接收通知用例

現在，我不確定如何對我的初始列表中的其他項目進行建模，這些項目應該完全建模。

我應該有類似的東西：

• 事件（參與者）- 生成通知（用例）- 用戶（參與者）
• 然后生成通知用例和其他用例之間的一些關系：攝取事件、豐富事件、關聯事件？

我應該完全模擬丟棄事件嗎？

謝謝！

Answer 1

讓我們看看定義。

演員

我將使用UML 規范18.1.3.1 節中的定義

Actor 對實體所扮演的角色類型進行建模，該實體與其關聯的用例的主題進行交互（例如，通過交換信號和數據）。 參與者可能代表人類用戶、外部硬件或其他系統所扮演的角色

它清楚地列出了誰/什么可以成為演員的詳細名單。 在您的情況下，它是一個與您的系統交互的External System ，因此它是您的 Actor。 另一個 Actor 自然是User 。

用例

在這里，我將使用 Alistair Cockburn 的“編寫有效用例”一書（第 1.1 節）中的定義來支持自己。

用例捕獲系統利益相關者之間關於其行為的契約。 用例描述了系統在各種條件下的行為，因為它響應來自一個利益相關者（稱為主要參與者）的請求。 主要參與者發起與系統的交互以完成某個目標。 系統響應，保護所有利益相關者的利益。 根據提出的特定請求和請求周圍的條件，可以展開不同的行為序列或場景。 用例將這些不同的場景收集在一起。

在您的情況下，很明顯，一旦External System （主要參與者）提供事件，處理就會由您的系統執行，直到通知User （次要參與者）或事件被丟棄。 為了實現這一目標，似乎不需要延遲或進一步的交互，所以它顯然只是一個用例， Ingest event 。

通過通知User結束的處理將是您的主要路徑，而事件被丟棄的路徑將是替代路徑甚至是負面路徑（取決於您如何看待它）。

如果您將丟棄視為替代路徑，則應將與User關聯的多重性建模為0..1以顯示User並不總是得到通知。 如果您將此視為負面路徑，則不必這樣做，因為這些被視為“失敗路徑”，因此並非 UC 的所有任務都必須發生。 不過我會非常小心。 由於您希望丟棄是定期發生的事情，因此它似乎是一種替代途徑而不是消極途徑。

替代方法

我的模型中的假設是您主動通知User （例如向他發送推送、郵件或執行其他操作）。

盡管您只是創建了一個通知並且User必須主動閱讀它，但也有可能。 在這種情況下， User根本不是Ingest event的Ingest event 。 相反，作為Ingest event的結果，您會創建一個通知（在 UC 圖上不可見）。 此外， User需要一個額外的用例來Read notifications ，其中他是主要（發起）Actor。

總結 (TL;DR)

您的場景中只有一個用例： Ingest event 。

您的演員是： External System （主要）和User （次要，多重性0..1 ）。

Answer 2

• 對於您的演員： Event不是演員。 Event是一個事件。 如果您沒有特定名稱，則將其稱為External system 。
• Ingest event可以作為 UC。
• 我猜想豐富與Ingest event 。 丟棄它也是如此。 兩者都是用例內的活動。
• 關聯並發送給用戶將是 (UC---Actor) Inform User --- User 。
• 不通知用戶將是Inform User活動中的一個路徑。

一般來說：

• 用例顯示了所考慮的系統為其參與者之一提供的附加價值。
• 用例不是功能（那些隱藏在 UC 的活動中）。
• 如果 UC 沒有增加價值，那就不是用例。