Event tables
Things and processes. The event table is all about finding out and deciding what the things and processes are of the system, that you are going to model; and then listing all these things in a table. The description of the system will, in most cases, be given as a descriptive model - a narrative, perhaps an oral interview or observations made on site - and creating an event table is the 1st step in turning that into a logical model.
My takeaway (and grand summary) of this is that in order to construct an event table you need to be able to decide what are the things that the system has to react to, and then logically, what processes should be triggered as a result of them – which should comes naturally since you already know why this event has to trigger something. Having anchored these two main sticking points, we then go figure out the other rubrics of the event: source, destination, etc; which I guess in practice equates to translating more of the information from the narrative about the system into the event table.
The reason behind the focus on event-driven systems, is that they reflect the expectations of the system in the real world. Systems are not linear programs, like DOS batch files which execute a series of statements from beginning to end; they actually just sit and wait most of the time, intermittently checking to see if the users have done anything to trigger a process. Any screen in a GUI is a good example of this.
In a recent assignment for a Flash game design unit, we were told to create a design specifications document for a flash game we are going to be making this semester. Part of it included storyboarding where we draw diagram of what each screen in the game will look like, and then write some stuff about what happens on each screen - which included expected user interactions, feedback and navigation. This in a sense, was an event table (albeit in a radically different format), because it define the triggers for each action ad the process that each should invoke (some sort of feedback to the user or a navigation to a different screen of the game).
But why logical models?
It doesn't really make sense to do any work, including transforming one sort of model into another, without first knowing why it has to be done, and of course, assessing whether the benefits outweigh the costs of that work (by a significant amount).
The case for modelling is quite compelling though - which must be why a lot of people do it, and expect it of you. I agree with Peter's notion that most of us do it automatically - I find myself doing it naturally all the time: again going back to my flash game design. We were told to choose from 3 broad categories of games, from which we must choose one to develop in the rest of the semester. I didn't really consider the other options much before I knew I wanted to do the battleships game. However, reality dictated that I had better do my homework before deciding on something that I could potentially regret for the rest of the semester, so I actually modelled, by means of a flowchart the entire flow of the game, just to find out really, what the scope of the programming was and what I was in for. It was a scrappy little drawing that did not follow any of the standard conventions - I just used rectangles for processes and diamonds for decisions and a bunch of arrows to link them together.
>>game design flowchart
Anyhow, the more important reasons to model are:
- Divide and conquer: breaking large complex things up into smaller ones, just makes it easier to comprehend and manage than trying to do the same with the entire whole
- Creating a framework for understanding the system
- Aids in communicating ideas about the model with others, especially those without a systems analysis and design background, because it is fairly easy to comprehend drawings
- In my opinion this is the cure-all reason for why to model: If you model following all the nitty gritty rules of a modelling technique with "mathemathical formularity", and have a CASE tool powerful enough, you can actually have the model converted into code for you via an automated algorithm. Now that cannot be beat.
In summary, model so you understand the system yourself better, aids others in understanding and commenting on it, and have to spend much less time coding.
The tricky bits as a systems analyst
The events in an events table indirectly define the scope of a system, by defining what are, and therefore also, what are not, the events which the system has to respond to. Therein lies the importance of deciding what events should be in the event table.
- A transaction may have multiple events, which may be of interest, but not relevant to the system: i.e. the system should not respond to them, and thus these events should not be in the event table
- A transaction may have multiple events, all of which require a response from the system: thus the event table should have separate entries for each of these events
- Recognise what events are business requirements: events which are purely technical, such as “database has crashed”, which is definitely an event that has to trigger some sort of remedial action, should be noted, but note included at this stage (in the vent table). This sort of event will be tackled in the design phase, not in the analysis phase. Only business requirements for now.
- Remember that other than the obvious events that trigger actions, those from external agents, there are also temporal events as well as status events that the system must respond to, must not be overlooked at this stage.
- Temporal: based on the passing of time: deadlines, billing cycles, etc.
- Status:internal events which can impact on the system, and also its response to external and temporal events
No comments:
Post a Comment