4

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

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

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

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

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

4

2 回答 2

4

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

哪些信号在哪里，谁订阅了谁，应该在动态图中建模。

编辑：

您是否考虑过添加诸如<< event >>或<< signal >>之类的刻板印象来对类的属性进行分类？

于 2012-07-02T19:05:07.673 回答
1

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

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

附带说明一下，UML 是一种半正式语言，它使得诸如两个不相关状态机之间的事件排序之类的事情无法保证，尽管这可以通过使用诸如MARTE之类的 UML 配置文件来定义（我已经很久没有看看它，所以事情可能已经改变了）

于 2012-07-02T19:20:34.750 回答