Week 6:Use Case Modeling

Last week we started on use case modeling and how the event table assist in designing use case diagram. We touched on the rules, the diagrams and the way to interpret the use case models. The use case diagram puts how words in the event table into a diagram to see the system and how actors or users interact with the system.

After a thorough walkthrough of the use case diagram, we went on to activity diagram and the class diagram. In the class diagram, we discuss how objects in the system gets created and how they interact with each other. Also what are the attributes and function the object has.

After confusing us with so many diagrams, Rob threw in another diagram; sequence diagram. ARGHZ!!! Well... The sequence diagrams shows how a use case goes through all the functions till it ends. It mimics almost like the activity diagram but it shows how the objects interact with each other.

All in all, the diagrams go through a flow. We start off with the events table. After stating all the possible events we move on to drawing the use case diagram. The use case diagram now shows the functions of the system and the boundary of where the user stands against the system. From the use case diagram, we design the class diagram so as to design the database. This would be objects that will be in or out of the system. Lastly, we draw the sequence diagram to explain further or more in-depth.

Sometimes we take a step back to the previous diagram to cross-reference it. It ties up the loose ends of the system and makes it more robust. I guess its how this diagrams comes together in relation and how we use them to design successful systems. Even though more than 50% of systems fail. :D

Event Table is ready!!

I've completed my event table. As with all assignments, one will worry whether is this the correct answers or even the correct way of answering it. Well.. Here goes nothing!!

Week 5: More Analysis and More Diagrams...

We are heading into the main part of the unit, about designing systems and drawing diagrams. Not just drawing, we have to learn to see how users interact with the system and what operations they do with the system. As we know, systems are meant to assist users to ease their workflow or increase efficiency. If a system is designed badly, or does not meet the users' requirements, it is badly designed.

We touched more on certain diagrams and did a sample during the tutorial. It was a reminder of my past experience while having internship. The only difference was the stress or pressure is not present. Hehe...

Last week we touched on event table, which is the upcoming assignment. Now we start another diagram, data flow diagram(DFD). The DFD is able to show how the levels of interaction from users to the system and datastores. There is alway a context level that shows what are the major operations or functions this system is going to handle. As we enter each function, there are more operations which we can go deeper. As we go deeper, the more intricate the operations become.

Week 4 Revised

During the tutorial, we interviewed our tutor to find out the events and requirements of the system. It was a little nerve-wrecking initially but David made it very enjoyable which reduced the stress level inside me.

We started by activating our recording mechanism and by doing that, we learn a very valuable lesson from David.

"When you are recording a conversation, it is polite to ask the person if they mind that the conversation is being recorded," said David. I would say that would be the one lesson that is not covered in the unit but a valuable life lesson.

We continued the interview and got what we wanted. I would say not fully what we want or covers all that is required, but that some what mimics real life systems design. A single interview usually don't give you all the requirements. That depends on the size of the system.

Week 4: Analyze the Analysis

We discussed about analysis this week. We discussed how to put our analysis into models. Models such as the use case model, event table, class diagram and many more. We put more emphasis on the event table as it is the upcoming requirement for our assignment.

An event can be classified under three different types; External, Temporal and State(Internal). External events are events that happen outside the system, usually initiated by an external agent or factor. A simple example would be a passenger pressing the lift button to call for the lift. Temporal events occurs when the system reaches a certain point in time. An example to that would be daily backups by the servers. By a certain time listed by the Administrators, the system will execute a backup event. The internal or state event is stuff that happens inside the system. This events are very minute like the system accessing the database.

We went on to talk about things. Things that affect the system one way or another. I think they are just things that interact with the system or a word/noun to describe something. I do not know for sure what it is but that will have to leave to the reading up then...

Week 3 Revised

It's another roller coaster week. Assignments are getting dued and work load is increasing as the week advances. The nightmare seems to be happening all over again. I do not think i can survive this semester! Noooooo~~

That is the usual thinking of a student. No matter where he/she is studying, a student goes through phases just like how a caterpiller morphs into a butterfly.

This week i didn't do much revision regarding this topic. Most of my time dedicated to this unit is concentrated towards the formulation of questions for the upcoming interview. I have been through job interviews, i have conducted job interviews, i have even participated in a systems interview. Like i said before, i'm not good at it as i've only experienced. Experience does helps, but it does not makes you prepared for the coming.

After this... I guess its full steam assignment work.