如何在静态UML模型中表示基于事件的体系结构?

“发布者-订阅者”对模式(也称为“观察者”)可能在每个编程(语言)框架中实现不同,因此在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...........
.........................................

在U.M.L.,刻板印象是你的“酒友”, 特性,或接口。

使用它们时,当对象或类, 是类或实现的子类, 这些都是模型,即使有其他父类,

干杯

正如lexu和John所指出的,您可以使用状态图和活动图对系统的一些动态方面进行建模。

对于静态模型,可以将类可以作为操作处理的事件建模。你可以使用刻板印象( <<event>> )将这些操作与其他操作区分开来(例如,同步调用的方法)。

使用状态图或活动图。

看 here 有关状态图和 here 对于活动图,请选择适合您需要的!

我可能只会使用逻辑组件模型来表示源/消费者,并使用定型操作来描述交互。。

然而,作为一个左外野的想法,我想到了另一种可能性。。。。。

我想知道您是否可以利用BPMN的某些方面许多uml工具(如sparx ea)都包括它

它的消息语法应该允许您描述源事件,并且您可以使用池或活动来描述使用者/处理程序,而不必担心内部行为。(我正在考虑一个类似于bruce siver的“level1”BPMN的抽象级别) 类似地,您可以使用消息传递交互来指定有效负载/事件参数

如果你;如果使用类似于sparx的东西,您可能会将bpm元素的跟踪依赖性添加到c#代码的“真实”类模型中。

从实体生命史角度探讨问题(事件建模,参考,例如。, Jackson System [of] Development ):

UML and Data Modeling: A Reconciliation By David C. Hay 参考第34页

Software Evolution with UML and XML edited by Hongji Yang “实体生命历史-问题与问题”,第142页 -我不同意,顺便说一句,如果仅限于所讨论的实体,序列图可以相对容易地使用,而状态图则在 Software Systems Architecture, Nick Rozanski, Eoin Woods ,“信息生命周期模型”,第317页。