Section 11.2

Top-down implementation

Think about the above code. 'Get computer move' might be tricky. It probably involves random numbers in range 1 to 9, checking that a position is empty etc. To get the program working we could use this stub:

private sub getComputerMove()
    move = CInt(inputBox("Enter computer's move: 1 to 9"))
end sub

Section 11.3

Bottom-up programming

What might a bottom-up approach to oxo be? We might say that we know we will need to check if a win happens, so our first step is to write code to check this (assume we check for an 'x' win)

private sub checkWin()
    if ( (b1="x") and (b2 = "x") and (b3="x") ) or _       ' top row
       ( (b4="x") and (b5 = "x") and (b6="x") ) or _       ' 2nd row

       ...etc

end sub

Bottom-up programming can be useful when you are new to programming - it is less abstract. It might also be useful to explore if something is feasible. For example, say you have been given the job of writing a video editor. How will 'cut' and 'paste' work with massive video files? You might do the code for this part first, so you can see if it is fast enough, rather than leave it till the final stages of the project. Some programmers do top-down and bottom-up together.

Section 11.4

Event-driven programming

Where does top-down design come in here? If the task to be performed when (e.g.) a button is clicked, we can put the task in a procedure. If this task is big, we can use more procedures. As an example, if we must do the task 'sort mailing list and send letter' when a button is clicked, we might have:

private sub Button1_click(....)
    sortList()
    sendLetters()
end sub

private sub sortList()
   ...to do

end sub

private sub sendletters()
    createLetters()           ' to do
    addAddressesToLetters()   ' to do
end sub

It might cross your mind that - if we have 9 buttons on screen for noughts and crosses, how do we avoid having masses of identical code for each button? We can still use procedures, as in

private sub Button1_click(....)
   move = 1           ' global  (or a parameter for handleMove)
   handleMove()
end sub

private sub Button2_click(....)
   move = 2
   handleMove()
end sub

private sub handleMove()
checkState()
if game = "running" then   ' not over yet
    get computer move
    check state
    if game = "running" then
        not over yet
    else
        computer's move ends game
...etc

Section 11.5

XP - Extreme programming

• pair programming - 2 programmers to a PC
• a client on-site, so the team can ask questions immediately (look at the chapter on testing for an e.g. of this).
• extensive automated tests, which run without user interaction (so they are easy to run). Testing is done - for example - every day.
• a no-overtime policy, to avoid stress and errors (hence the term 'extreme' is a misnomer.)
• incremental changing - a part of a program is written and tested, then new parts are added and tested (as opposed to writing the whole thing in one go, and testing it at the end).
• welcoming change - in the sense that if the client suggests a change, then XP is flexible enough to handle this - we would not begin the whole project again ,or bin masses of design docs. XP does not put a value on lots of design docs.

Section 11.6

Prototyping

The problem was that when the client saw the finished program months later, it was the wrong kind of thing (the spec was very technical, and the client could not really follow it?)

Nowadays, to ensure that the client knows what they are getting, a prototype is often created. For programs with a major user-interface, this might be a mock-up of the form, showing what facilities will be there - but they will not actually work. Now the client can be asked:

    'is this what you want?'

If not we modify the prototype. In this way, the specification will be more accurate, and the client is clearer about what they are getting.

In our oxo game, a prototype might show that we need some kind of delay before the computer shows its chosen move. When there is no delay, the computer's move comes immediately after the user's move, making the user look stupid for spending a few seconds on their move. Maybe we display a 'Computer thinking...' message ?

VB is one of the best prototyping languages because forms are easy to create, and there is a huge list of extra controls that can be added.  

Section 11.7

Object-oriented design (OOD)

The next step is to decide what properties the board has - what do we need to do to the board? We probably want to find out the state of a particular board position, and to initialise the board (and other actions as well...

The programmer can code this object, which is accessed like we access controls - with the dot notation. We might then use the board object by:

board.initialise

centreBox = board.getState(5)

Note that the VB controls were planned in an OO way. A button is very complex internally, However, we simply manipulate it by e.g:

Button1.Text = "Go"

problems....to do