如何在靜態UML模型中表示基於事件的體系結構？

Question

我有一個相當基本的基於C＃事件的系統，但我不確定如何在UML中對它進行建模。我顯然想顯示事件發佈者，訂閱者，處理程序和EventArgs類。我認爲你使用'信號'，但我找不到任何示例。任何人都可以給我一個例子，或者說明白嗎？

感謝

編輯：我創建一個靜態模型，我並不需要通過過程來代表國家或路徑。對不起如果我在最初的問題中沒有說清楚。

Answer 1

使用狀態圖或活動圖。

Answer 2

看起來here爲狀態圖的例子，here爲活動圖，然後選擇適合您需要的東西！

Answer 3

正如lexu和John所指出的那樣，您可以使用狀態圖和活動圖來模擬系統的某些動態方面。

對於您的靜態模型，您可以將類可以處理的事件建模爲操作。您可以使用原型（<<event>>）將這些操作與其他操作（例如，同步調用的方法）區分開來。

Answer 4

我可能只用一個邏輯組件模型來表示源/消費者和刻板的操作來描述互動..

但是作爲左場的想法 - 另一個possbility ocurrs我....

我想知道你是否可以利用BPMN的某些方面。 - 許多uml工具，如sparx ea包含它

其messaage語法應該允許您描述源事件，並且您可能能夠使用池或活動來描述消費者/處理程序 - 而不一定要關心自己內部行爲（我正在考慮類似於bruce siver的「level1」BPMN的抽象級別） 類似地，如果您使用類似於sparx的某些東西，您可能會使用消息傳遞交互來分配有效負載/ EventArgs

;您可能可能會將bpm元素的跟蹤依賴添加到c＃代碼的「真實」類模型中。

Answer 5

「發佈者 - 訂閱者」配對模式（a.k.a「觀察者」）可以在每個編程（語言）框架中實現不同，因此在U.M.L中被設計爲不同。在發送事件（「信號」或「消息」）時，從發佈者（又名「服務器」）發送到任何訂閱者（「客戶端」），有時候需要「ID」來識別來自其他事件的特定事件，其提供的事件，以及還發送的其他參數或數據。

其他答案已經提到，您可能需要（類）圖來描述靜態模型。 （請注意，有一個「聚集」，而不是「成分」，「關聯」可以使用）：

.............................. 
+--------------------------+.. 
|  <<Publisher>>  |.. 
|  VectorDrawApp  |.. 
+--------------------------+.. 
| [+] create()    |.. 
+--------------------------+.. 
| [+] send(EventArgs e) |.. 
+------------+-------------+.. 
............/ \............... 
............\ /............... 
.............|................ 
.............|................ 
+------------+-------------+.. 
|  <<Subscriber>>  |.. 
|   Figure   |.. 
+--------------------------+.. 
| [+] create()    |.. 
+--------------------------+.. 
| [+] receive(EventArgs e) |.. 
+--------------------------+.. 
.............................. 
+--------------------------+.. 
|  <<Event>>   |.. 
|  EventArgs   |.. 
+--------------------------+.. 
| [+] Sender: TObject  |.. 
+--------------------------+.. 
| [+] receive(EventArgs e) |.. 
+------------+-------------+.. 
.............|................ 
.............+................ 
............/ \............... 
...........+---+.............. 
.............|................ 
+------------+-------------+.. 
|  <<Event>>   |.. 
| FillEventArgs: EventArgs|.. 
+--------------------------+.. 
| [+] ForeColor   |.. 
| [+] BackColor   |.. 
| [+] FillStyle   |.. 
+--------------------------+.. 
.............................. 

而且也，你可能需要一個圖來描述動態模式：

......................................... 
+----------------+..+----------------+... 
| <<Publisher>> |..| <<Subscriber>> |... 
| VectorDrawApp |..|  Figure |... 
+--------+-------+..+--------+-------+... 
.........|...................|........... 
.......+-+-+...............+-+-+......... 
.......| |...send(fill)..| |..Fill(). 
.......| +==============>+ +---+..... 
.......| |...............| |...|..... 
.......| |...<<return>>..| |...|..... 
.......| |<--------------+ +<--+..... 
.......| |...............| |......... 
.......+-+-+...............+-+-+......... 
.........|...................|........... 
.........X...................X........... 
......................................... 

UML中的刻板印象，是你的「酒友」， ，並允許你描述或限制演員，對象，類，特質或界面的功能。

當你使用它們，突顯當一個對象或類， 是一類的子類，或者實現， 的接口，是有關那些一直模型活動， ，即使有其他的父類， 或接口。

乾杯。

Answer 6

趨近從實體生活史角問題（事件建模，參考文獻，例如，Jackson System [of] Development）：

UML and Data Modeling: A Reconciliation By David C. Hay 參考。 p.34

Software Evolution with UML and XML edited by Hongji Yang '實體生命歷史 - 問題和問題'，p142 - 我不同意順便說一句，順序診斷。如果限於所討論的實體，則可以相對容易地使用，而狀態診斷。 Software Systems Architecture, Nick Rozanski, Eoin Woods，「信息生命週期模型」，第317頁。