如何在UML类图中最好地表示c#.net事件构造？

我正在设计一个实体/组件系统，其中通过事件消息系统解决实体内通信的问题。组件分为两部分，一部分在实体中，另一部分在子系统中，通过观察者类型的系统保持同步。我正在尝试使用事件和委托实现

我试图对我的应用程序的事件/消息传递系统的结构进行建模，但我与代理之间遇到了问题。现在的方式是一个图表（附件），显示系统中的委托、事件参数和实体，但是它们之间关系的性质仅表示为通用关联。我还有第二个图表显示了系统的接口。我需要显示在这些对象中引发的事件，因为这是系统中最复杂的部分

我知道我也需要动态协作和时序图，但我正在试图弄清楚我需要哪种类型和多少不同的事件支持类，以及继承结构是什么样的。我想给自己一个消息类型的选择，我知道将一起工作。我想，然后我可以从这些预定义类型中选择EventArgs派生类型和委托类型，以便在动态图表和组件构建时重用

我无法弄清楚的主要问题是，是将事件建模为属性还是操作。我一直在尝试为委托使用关联类，并使用带有事件原型的OnSomeEvent（）类型操作。我不喜欢这样，因为事件不是操作。我已经用****（）命名约定保护了代码中的方法。委托签名、多播行为和观察者模式并不是通过这种方法真正捕获的

其他人使用什么方法来表示这些复杂且紧密耦合的类？对我来说，图表的要点是记录并更全面地理解系统中的接口。在我的过程的这个阶段，我希望冻结接口并继续实现组件本身。

---

我不会在静态类图中包含信令字符，因为信令（事件的用途）是一种动态行为。我会按照事件代表的实际情况（即带有他们的签名），将其作为类的普通操作包含在内。我认为这符合这样一种观点，即一个对象能够非常恰当地发送一个事件，并且它指定了该事件的类型

应该在动态图中对哪些信号要发送到哪里以及谁订阅了哪些信号进行建模

编辑：

---

您是否考虑过在类的属性分类中添加诸如或之类的原型？

从静态角度查看模型时，事件和委托被认为是简单的方法。一些工具通过提供原型或标记来扩展规范，以将您的方法显示为事件/委托，并将它们与普通方法区分开来

另一方面，事件和委托参数应建模为类。当时间因素添加到模型中时，事件是有意义的，在这种情况下，您可以使用UML元素（支持消息传递）

---

另一方面，UML是一种半形式化语言，这使得诸如两个不相关的状态机之间的事件排序之类的事情无法得到保证，尽管这可以通过使用UML概要文件来定义，例如（我很久没有看到它了，所以事情可能已经发生了变化）

我发现了通用事件处理程序（事件处理程序）昨天，我想我将删除自定义委托并尝试您的建议。还有一个图表显示了实现此处所示接口的类的更多细节。这个图表是因为需要定义我在第一次尝试建模开始新游戏/地图初始化用例时引用的类型。它似乎每次交互都会添加两个新类！我明白了为什么团队在游戏项目中如此常见。