Event table takeaways

Last week saw the event table assignment for this unit due. It was only a tiny 5% assignment, but still was tricky getting done - compounded by the fact that I had another assignment due on the same day. We had to create event tables for the new delivery system for Max Fizz, and I got stuck at 12 events for a really long time. I was pretty sure that I had everything covered, but for some reason still only had 12 events – up till 11:30pm, an hour before it was due, and then almost suddenly I managed to crunk another 10 out for 22.

I submitted my assignment about half an hour early, then I went back to how modelling was an iterative process – so I decide to draw use case model. It was a pretty dodgy use case model as it turned out, it being the 1st time and all. However, it did serve its intended purpose, because as I was drawing the use case model, I realised that it was basically a stripped down version of an event table (much less detail); and it showed the links between the processes and the actors much more clearly.

With this different perspective on, what was effectively the same information and events, it was much clearer which events should be grouped together in a use case, and which use cases were missing and such. I was able to refine, and make much clearer – the events in my event table. From this experience, I think the best way to go about making an event table is actually to create a use case model alongside it. Doesn’t have to be a proper UML one – just one that gives you a rough idea of the connections between the processes and actors. It was only after that that I finally felt that I had event tables all figured out in my head – and it was a nice feeling, because that had eluded me up until ... half an hour after the submission deadline!! But, at least I learnt something interesting.

How to go about doing an event table (my way)

After having done the event table, and learning the hard way, here’s how I would go about doing it the next time I have to:

1. ID the actors or external agents


2. Draw a table with 3 columns: Input, Process, and Output


3. Think of the various events, and fill in these columns


4. Now expand the table to have 5 columns: Event, Trigger, Source, Response, and Destination




1. Note that at this stage it‘s still missing the “use case column”




5. Expand input into trigger and source




1. Trigger = what the source’s input was


2. Source = the actor who performed the input




6. Expand process into event and response




1. Event = description of process


2. Response = what happens in the process




7. Expand output into response and destination




1. Response = what the output is (note that response is derived from both process and output columns in the previous 3 column table)


2. Destination = the actor who receives the output




8. Now draw the use case, drawing the processes inside the ovals (not use cases yet)




1. You’ll notice that some processes may be similar when they have links to the same actors


2. Replace those processes with a single process (giving it a logical name)


3. The name of this new process becomes the use case for all the events which it combined




9. Expand the table to have all six columns, copying the use cases for the events from the event table

Event table legend

What do the columns in the final event table really mean? This is my aggregated understanding from lectures, plus doing the assignment, plus forum posts. (see previous post)

Event	The thing which causes the system to do something
Trigger	How the system knows the event has occurred
Source	The actor which triggers the event (if internally triggered by state change or time lapse, then the source is “System”)
Use case	What the system does when the event occurs. A general form of the process, i.e. several processes may fall under the same use case
Response	What happens as a result of the event
Destination	The actor which receives the response