21.08.2013 Views

Software Engineering for Students A Programming Approach

Software Engineering for Students A Programming Approach

Software Engineering for Students A Programming Approach

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

142 Chapter 11 ■ Object-oriented design<br />

Game<br />

Defender<br />

Alien<br />

Laser<br />

Figure 11.2 The non-library classes involved in the game program<br />

are displayed. Another object is a random number generator, created from the library<br />

class Random, to control when the alien launches bombs.<br />

We have now identified the classes that make up the game program.<br />

We now scan the specification again, this time looking <strong>for</strong> verbs that we can attach<br />

to the above list of objects. We see:<br />

display, move, hit, launch, click, win, lose<br />

Again, some of these words are mentioned more than once. For example, both the<br />

alien and the defender move. Also all the objects in the game need to be displayed.<br />

We now allocate methods to classes, with the help of the specification. This concludes<br />

the design process.<br />

Now although we used the specification to arrive at classes and methods, we could<br />

have used an alternative <strong>for</strong>mulation of the specification, use cases. Use cases were<br />

explained in Chapter 4 on requirements specification. A use case is a simple, natural<br />

language statement of a complete and useful function that a system carries out. For the<br />

game, some use cases are:<br />

■ defender move – when the user moves the mouse left and right, the defender<br />

object moves left and right on the screen<br />

■ fire laser – when the player clicks the mouse, a laser is launched upwards from the<br />

defender object<br />

■ laser hits alien – when a laser hits the alien, the player wins and the game is over<br />

Notice that some of the use cases are not initiated by the user of the system. Instead<br />

they are initiated by objects within the game, such as when an alien launches a bomb.<br />

A complete set of use cases constitutes a specification of what a system should do.<br />

We can then use them to derive classes and their methods. Again, we seek verbs (which<br />

are the classes) and verbs (which are the methods). Fortunately use cases are very suited<br />

to this process, because they emphasize actions acting on objects. So, <strong>for</strong> example,<br />

the use case defender move implies that there is an object defender that embodies<br />

methods moveLeft and moveRight.<br />

Bomb

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!