08 June 2013

Hangman - Part 5

More Diagrams

This will be the last of the diagrams don't worry. These are great diagrams too, they tell make our lives so much easier when it gets to implementation.


Sequence Diagrams

These diagrams will show the sequence of events in our program. It follows the use cases and has all the classes we gleaned previously. Diagrams 001 and 003 are pretty basic so I'll talk mostly on diagram 002. Look over 001 first just to get comfortable.
Sequence diagram 001
Sequence diagram 001
Alright let's not get too comfortable. This may scare you. Don't worry I'm here to help you along.
Sequence diagram 002
Sequence diagram 002
Bam! that's a big picture. Alright, so you can see the classes game and word. Diagram 001 gets us into a game and diagram 002 is starting/playing/ending the game. The diagram is read top to bottom like a book. As we move down the diagram we go forward in time. This helps us visualize the progression of events.

The first thing the game does is start playing music. It calls it's own method startMusic(). It then goes through drawing the screen by drawing the stand and then calling word's method getLength() so that it knows how many lines to draw. The dotted line under getLength() show a return. User doesn't get any returns because game just updates the screen. An alternative way would be to have all the display and show methods be returns to the users actions. When game calls a method from word there's a block on word's dotted line. This signifies that word has control and when it returns game will be in control again. If you look at one of the hasLetter() calls there's stuff inside of the parentheses and at the end. Inside you see an argument that game is passing. I've already given it a name of letter. At the end is the return type that word will send back. The int is the position in the word where the letter(s) appear.

That wasn't too confusing now was it? Sequence diagrams are great because they take care of most of the coding work! Obviously we will need to add logic to the methods but at least we know what methods will be called and when. When we get to implementation we'll need other helper methods and maybe helper classes which is OK. These are just the main calls. For example, how we draw these things will depend on the language, platform, and framework that we decide to use. They will all have different ways of drawing to the screen but we can have the same method call displaySuccess() and internally it calls other helper methods to get the job done.

Sequence Diagram 003
Sequence diagram 003

Communication Diagrams

These diagram display the same information as the sequence diagrams but in a different fashion  Instead of showing events in time they show relationships. Lets look at the first one.
Communication diagram 001
Communication diagram 001
The methods are all listed still but they are numbered with directions. Our game is pretty simple so the benefits of seeing the information doesn't seem that great. Lets say though that our program's sequence diagram had 10 classes passing messages back and forth. It can easily get confusing trying to determine who's talking to who. This format lets us see exactly that user never talks with anyone but game. We knew that before but it's much easier to see here.
Communication Diagram 002
Communication diagram 002

Communication Diagram 003
Communication diagram 003
That's it for today. Next week I'll put up final GUI images and then we'll be ready to code!

No comments:

Post a Comment