How to represent an event based architecture in a static UML model?

Question

I have a fairly basic C# event based system but I'm not sure how I model it in UML. I obviosuly want to show the event publisher, subscriber, handlers and EventArgs classes .. I think you use 'signals' but I can't find any examples. Can anyone point me to an example or shed any light?

Thanks

Edit: I am creating a static model, I don't need to represent state or paths through the process. Sorry If i didn't make that clear in the initial question..

Answer 1

Approaching the problem from an entity life history angle (event modelling, ref., e.g., Jackson System [of] Development):

UML and Data Modeling: A Reconciliation By David C. Hay Ref. p.34

Software Evolution with UML and XML edited by Hongji Yang 'Entity Life Histories - issues and problems', p142 - I disagree btw, a sequence diag. could be employed relatively easily if restricted to the entity in question, while a state diag. is successfully illustrated in Software Systems Architecture, Nick Rozanski, Eoin Woods, 'Information Lifecycle Models', p 317.

Answer 2

The "Publisher-Subscriber" pair pattern (a.k.a "Observer"), may be implemented different in each programming (language) framework, therefore, designed different, in U.M.L.

Any way, conceptually, when an event ("signal" or "message") is sent, from a publisher (a.k.a "server") to any subscriber ("client"), sometimes, an "id" to identify a particular event, from other events, its provided, and some additional parameters or data its also sent.

As other answers already mention, you may require a (class) diagram to describe the static model. (Note that there is a "aggregation", not "composition", "association" can be used):

..............................
+--------------------------+..
|      <<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            |..
+--------------------------+..
..............................

And also, you may require a diagram to describe the dynamic model:

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

Stereotypes, in U.M.L., are your "drinking buddies", and allow you to describe or restrict what an actor, object, class, trait, or interface does.

When you use them, highlight when an object or class, are subclasses of a class, or implement, an interface that is relevant to the activities, that are been model, even if there are other parent classes, or interfaces.

Cheers.

Answer 3

I'd probably just use a logical component model to represent the sources/consumers and stereotyped operations to describe the interactions..

However as a left-field idea - another possbility ocurrs to me.....

I wonder if you might make use of some aspects of BPMN. - a number of uml tools such as sparx ea include it

Its messaage syntax should allow you to describe source events, and you might be able to describe consumers/handlers using pools or activities- without necessarily haing to concern yourself with the internal behaviour.(i'm thinking of a level of abstraction similar to bruce siver's "level1" BPMN) Similarly, you might use messaging interactionns to sepcify the payloads/EventArgs

if you;re using somthing similar to sparx, you could probably add trace dependiencies from the bpm elements to the "real" class model of the c# code.

Answer 4

As indicated by lexu and John, you can use statecharts and activity diagrams to model some of the dynamic aspects of your system.

For your static model, you can model the events a class can handle as operations. You can use a stereotype (<<event>>) to differentiate these operations from others (e.g. synchronously called methods).

Answer 5

look here for examples of state diagram and here for activity diagram, then choose what fits your needs!

Answer 6

Use a state diagram or an activity diagram.