Learning by doing

Learning by doing

Well it's been a long hiatus from me here, haven't blogged from weeks seven, eight and nine of the semester. I partly blame the fact that the units I am taking have all swamped me with assignments at once. Although I am usually good with assignments, I submitted two of them at five minutes or so past the submission deadline cut-off - which is unusual for me, I normally get them done ahead of time.

Focusing on the System Analysis assignment for this unit, I am happy that I feel that I have actually learnt quite a great deal from this assignment. All the concepts which were introduced to us at the beginning of this unit, like the phases of the SDLC and the reiterative approach to analysis (and of course design as well, but just not yet for this assignment), just sort of "clicked" as I was doing the assignment.

Learning by doing.

I went through about 23 reiterations in my analysis. I define reiteration here as making a significant change to one of the things the system does, be it in terms of a use case, a class, an event, and sometimes just a change in the approach which gets written down somewhere but doesn't really influence any of the diagrams or models - although I daresay their impact has just been delayed till the design phase perhaps.

The following lists the most major discoveries which resulted in these changes:

• Limiting scope. This was easily the biggest challenge in analysis - defining the automation boundary of the system, and thus deciding exactly what the system does, and what it does not. Implicitly this also defines what inputs and outputs the system requires from the other systems as well as the actors interacting with it.


• The customer doesn't interact directly with the delivery system, and instead interacts only indirectly through the ordering system. This was a spin-off effect from the first point (limiting scope)


• The delivery system does not have to care about whether an order can be filled -  it should assume that the ordering system has already done the prerequisite checks with the inventory system. Similarly, there were many other instances where I found that the delivery system should not assume the responsibilities for certain actions, where they should more logically (and effectively) be done by the other systems/actors iterating with each other, outside of the delivery system. This was, again, a spin off effect from the first point (limiting scope).


• The delivery system does not keep track of the stock in the warehouse; instead, it should keep track of the stock each driver is carrying, because that is really the only information about stock levels the delivery system really has to care about.

These major changes had ripple effects within my analysis. Because if I change one thing in one part/diagram, then another thing in another part/diagram would have to change. And so on and so forth, and sometimes even came full circle. Reiteration can sometimes be a real pain, because you know that when you do something once, it isn't done yet, and you're going to have to come back to it again, and again, and again.

The end result was this:

Event table - from 23 events in assignment 1A, I chopped off eight, as a result of massive scope limitations, bring the number of events down to 15. Then I added another two entirely new events, which I had only thought of as a result of writing my use case narrative, bringing it up to 17.

Use case diagram - I had already made one of these for assignment 1A, which very accurately reflected the event table I had then. After limiting the scope, I decided to redo it all over again. I also collapsed the very complicated use cases into single one, to achieve clarity and presentability in the main use case diagrams; and then created an individual use case diagram for each of the complex use cases which showed its expanded form (child use cases)

The class diagram - Here I think I might have jumped the gun and gone straight into design. One thing I wish I had done better was, to stop my analysis here from becoming too design-ish. In retrospect I think the reason why I did do that was because I had already successfully applied the class diagram modelling techniques learnt in this unit to another unit I am doing, Java 2. In the major assignment for that, I had modelled the entire project (a rental system with a GUI and everything) in VP UML as a domain class diagram. Domain class diagrams were pretty much the only sort of class diagram I knew - I only learnt much later (from the discussions forum) that there were two types of class diagram. Anyhow, at least I know the difference now.

Here are some pretty pictures to that illustrate the process: