I am designing an entity/component system where the problem of intra-entity communication is addressed by an event message system. components are broken into two parts, one in the entity and a sort of “entity proxy” in a subsystem, kept in sync through an observer type system. I am attempting an implementation with events and delegates.
I am trying to model the structure of my application’s event/messaging system and I am having trouble with the delegates. The way it is now is a diagram(attached) showing the delegate, eventArgs, and entities in the system, however the nature of their relationships is only being represented as generic associations. I also have a second diagram showing the system’s interfaces. I need to show the events that are raised in these objects, as this where most of the complexity in the system is.
I know I need dynamic collaboration and timing diagrams as well, but I am trying to figure out what kind and how many different event support classes I need as well as what the inheritance structure will look like. I want to give myself a choice of message types that I know will work together. I figure then I can choose an EventArgs derivative and a delegate type from these pre-defined types to reuse at dynamic diagramming and component building time.
The main thing I can’t figure out is whether to model the event as an attribute or operation. I have been trying to use an association class for the delegate and an OnSomeEvent() type operation with an event stereotype. I don’t like this because an event is not an operation. I have protected methods in the code with this On****() naming convention already. The delegate signature, multicast behavior and the observer pattern are not really captured by this approach.
What method are others using to express these complex and tightly coupled classes? The point of the diagrams for me is to both document and more completely understand the interfaces in the system. At this stage in my process I am hoping to freeze the Interfaces and move on to Implementing the components themselves.
I wouldn’t include the signaling character in a static class diagram because signaling (it’s what events are for) is a dynamic behavior. I would take the event delegates as they are (i.e. with their signatures) and include them as ordinary operations of a class. I think this would match the idea that an object is capable of sending an event quite appropirately and it specifies the kind if the event.
Which signals are going where and who is subscribed to whom should be modeled in a dynamic diagram.
EDIT:
Have you considered adding stereotypes like << event >> or << signal >> to classifying attributes on your class ?