Pretty much what the lecture this week was about.
Events tables – the deceptive little bastards
Event tables are a tricky business. I thought they were a no-brainer after the lecture – seemed too easy. Then a week later, we had to do an event table during the tute, and it was tricky as. Went back home and read the text, which helped a bit, but not much; and then I concluded then they were deceptive little bastards; gives you the false impression of being really easy, but when you actually buckle down and get cracking you realise that it is actually much harder.
Thank goodness for the moodle forums though, Peter’s answered my questions quick, and now I’ve got down 12 events in a table. I feel that this isn’t quite enough, although I think that I have pretty much covered everything a system needs to do. I am tempted to draw a use-case diagram so that I’ll “realise” what I have missed out on.
My questions (with Peter’s answers):
- After attempting to do an actual event table in the workshop - it suddenly became unclear what the distinction between some of the 6 columns are -
From what I gather, there doesn't seem to be any difference between the event, use case and, sometimes, response columns - even in the RMO case study's example they appear to be the same thing, just phrased differently.
Has anyone come up with a way of thinking about what each column "means”, that would make the distinction between these columns clearer? - The difference between them becomes clearer as you model. The event is the event, the "use case" is the process that the event triggers. To start with - your first drafts they will be very similar - almost the same words. but later, as you think about it, and collect more events, you should notice - at least for some use cases - that they are started by more than one event. So after a while the event names will stay the same but the process/use case names will get more refined and less in number.
Does that help? - Aha - each use case is a collection of similar events, or events which happen to trigger similar processes. (Is that right?)
Thanks - Spot on.
To start with - when you first draft - it might not be obvious what's similar/the same - but later it becomes more obvious.
Sometimes there is a lot - sometimes not much. - I was thinking of something along similar lines: I have several events which trigger other events - which seem to me at least - legitimate events in their own right.
In the lecture, however, it was mentioned to be careful not to have the process that is triggered by event A become a separate event B; seems like yet another grey area... because the system does have to react to both events, but at the same time one is precedent to the other - so one of these two rules has to give way. - Yep it is a grey area.
As long as the decisions you make - in your opinion leave the table easier to understand - then that's OK. The model rules are supposed to make things clearer but the world is complex, they can't always.
In the lecture I'm not sure I was definitive - didn't mean to be smile - I wanted to stress the need to be careful with events (usually sub events) that will usually be better described in the detail of the process description. However, that's not always the case, so as long as you make it clear where an event is a sub event and which event "owns" it then that's a good solution (simply done with a numbering scheme). Early on (like for assignment 1a), before you have made the process descriptions, you are more likely to want to show those sub-events in the event table, and that's fine.
Other questions:
- If you have an event, the use case/response etc for which depend on some condition, do you set it up as two events (ie one where the condition is true, and one where it's not) or do you set it up as one event and give it a more general use case which could handle both conditions?
- Great question.
I'd probably model it myself as one event and have two processes in the process column and make a note to explain when each one is appropriate. But I don't think it would be wrong to model it as two events - giving them similar names but maybe using the name to show the condition. 'Event X when A = true" and Event X when A = false" that sort of thing.
Also, not wrong to give it a more general use case to handle both conditions. We are about to see the detail of modelling use cases. use cases can have different scenarios. Say for the RMO case study in the text, they have a single use case for sales, but different scenarios of web sales, phone sales and mail order sales. Could easily and reasonably model that as three different use cases.
Data flow diagrams
DFDs are something we’ve learnt to some extent in Databases, and had a brief introduction to in IT in organisations. In Databases we learnt the symbols that comprise a DFD and basically had to design a database based on that. In IT in organisations we just learnt that there was such a thing, and that there was this process of “exploding” each of the process in the higher level diagram to get the lower level ones.
Both these concepts were reiterated in the lecture, along with some new stuff:
· Context diagrams are DFD which consists of just one central / main process and a bunch of external agents, and the Data flows between them. The other two possible elements, the data stores (internal) and real-time links are not allowed in this.
· When you explode a context diagram, you get a single diagram 0 (as there is only one process). When you explode the diagram zero, you get one diagram 1 for each process in the diagram 0.
· The processes are numbered with an indexed system. E.g. no number in the context diagram, 1 in the diagram 0, 1.1 in the diagram 1, and so on.
One interesting thing is that if a system is complex enough, when exploding a context diagram, you need not necessarily go straight to a diagram 0, but you can create yet another context diagram for subsystems of the main system.
The capacity of the human mind
The magic number is 7. The human mind can keep track of about 7 things at once – so keep this in mind when creating diagrams. This number was not just cooked up for the purposes of the unit, or standardisation within the faculty, which is what I thought at first, but is actually based on psychological studies by George Miller: The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information
Caulfield’s claim to fame
What is now the de facto standard systems analysis and design, information engineering, came about mostly out of frustration out of the fact that processes are volatile; and the data that is collected is mostly the same. Thus the traditional approach toward systems analysis and design which revolved around modelling the processes and then figuring the data out was given the boot, and replaced with the approach of modelling the data needed in the system, and then figuring out the processes. This new technique was popularised by academics at Caulfield campus (woot) twenty years ago.
This fits with how systems are designed nowadays, where after designing the database, if the database design is done correctly, the rest of the work is just in designing the interfaces the user has to interact with.
Edit: P.S. In spite of the title, note the distinct lack of a mention of a rick roll again up until now. I refuse to be part of this internet phenomenon - or as I think of it, a LOLcat following the herded masses - because it just isn't that funny.
No comments:
Post a Comment