Lecture
Use case diagrams...ah....long live the actors who made our lives so enjoyable.
Users are known as actors well in this role playing game anyway. Games seem to come to my mind when I think of Use Case diagrams. Developing games require a lot of objects interaction within the system as well as User interaction so definately there must be Use Cases to test whether a certain functionality is required, desired or even if its worth implementing.
Lets say an Ogre wielding a club.Most likely whack the player for some damage . The player also can interact with the Ogre thus whacking the Ogre for some damage as well. This would be called an includes relationship. Well obviously 1 whack won't do so hence we then have the repeating message to associate that it will take a couple of twacks before either the Ogre or the Player gets knocked out.
Domain models are static models but use case models are dynamic. I believe the meaning is that domain models are subject to iteration but they are highly fixed to the requirements but the dynamic models require more user interaction and thus requirements change every time on the whim of users also iteratively.
Drawing use cases involves a stick figure defining the role. This role is highly dependent on who the system being developed is catered for. Thinking of roles reminds me of my time playing Neverwinter Nights, following D&D roles. Roles determine who and how will that role affect the usage of the system.
CRUD, create ,read/report ,update, delete....Use cases should cover all the above because then the system can be integrated fully. Like the Ogre above which has to be created by someone, able to report and be read, update its status or on KO be deleted in the system.
Tute
Tute gave some practice on domain modelling and use case diagram...To do a full domain class diagram seems to be quite tedious because of the interpretive nature of the cardinalities.
One thing tht I asked my tutor was regarding the System Sequence Diagram. Can the system actually send messages to the user? I didn't thought about it because the arrow denotes message sending and the dashed line arrow represented return message so I was informed that it is on the perspective on the user not of the system.
For example, System displays a prompt asking for user to click okay or cancel. Wouldn't this be a system sending a message to user. Yes in some way but note that before the system can actually display this mesage the user must first see the message and thus it would look more like , User sends a message to the system I want to do something because I saw this message, system responds by sending the appropiate message back and then the user sends the message in respond to the return message of the system.
Got to start on my assignment 2....
No comments:
Post a Comment