The various stages in the development of a computer program are : Show
Problem Definition:
Program Design:
Coding:
Debugging:
Testing:
Documentation:
Maintenance:
The goal of Chapter 1 is to provide you with a general background about computers and programs. In Chapter 2, you will start creating programs in C++. To prepare you for writing your first program, the book presents the following step by step process. Step 1. Define what the program should do
In any level of software creation ranging from your first home work to a team creating a new iPhone app, it is essential to have a clear understanding of what the program will do and not do. You should consider the following:
Programmers are often presented with a set of requirements which define the inputs, the functionality, and the output. The software engineering classes, CS 361 and CS 362, will include instruction on requirements gathering and assessment. One of things that make programming so interesting is that there are unlimited ways to write a program to meet a set of requirements or serve a specific purpose. This allows extreme amounts of creativity. It is pretty exciting when someone asks you "can you create a program to do this super cool thing?" and you can say yes! Step 2. Visualize the program running on the computer
Once you know what the program needs to do, start conceptualizing what the program will look like. You can do this in your mind but as programs get more complex, it can be helpful to create mockups or diagrams of input and output screens. As you start programming, I think you will notice that you start paying more attention to the software you use and what you like and don't like about an application. CS 352, Introduction to usability engineering, will teach you ways to assess and improve the usability of software. Step 3. Use design tools to create a model of the program
Before you start actually writing code, it is very helpful to create a model of the program. Some simple modeling tools are hierarchy charts, flow charts, and pseudocode. Hierarchy chartsA hierarchy chart is a graphical representation of the structure of a program. Boxes are used to represent each step in the program and boxes are connected to show relationships between steps. The most important step or task is listed at the top of the chart and subtasks are then listed in subsequent levels of the chart. See page 20 in the book for an example of a hierarchy chart. Hierarchy charts typically end up with a pyramid shape. Flow chartsA flow chart like a hierarchy chart lists tasks in boxes but in a flow chart there is a defined flow or logical sequence of steps from a starting point to an ending point. PseudocodePseudocode is cross between human language and computer language. Basically, you describe what the program needs to do in simple statements or lines that you write without worrying about the exact syntax of the language. For example, if a program included a task to search a directory for all text files, the pseudocode might look like the following: create empty list for saving text files get a list of all files in the directory for each file in the directory list if file is a text file save file name in list of text filesStep 4. Check the model for logical errors
Logic errors are mistakes that cause a program to produce erroneous results. Trace through your flow chart or pseudocode and make the each step produces the desired results. Make sure your model considers all possible cases. In the pseudocode example above for searching a directory for text files, my model should properly handle cases where the directory does not exist, the directory is empty and the directory includes no text files. Bugs or crashes in computer programs often result from unexpected or unusual situations because the programmer builds the program based on typical or expected inputs and results. Step 5. Write the program source code
After understanding the purpose of the program and developing a model of the program, start writing the program using the tool of your choice. Since source files are simple text files, you can write programs in simple text editors but many programmers prefer to use IDEs which includes features to color text by purpose such as comments, keywords, and variables, to highlight syntax errors as soon as you create them and to use auto completion to reduce the amount of typing required. Step 6. Compile the source code
Build the program using the compiler. The compiler checks for syntax errors and creates a machine code version of your program. Step 7. Correct any errors found during compilation
If the compiler reports errors, fix them and recompile the program. Step 8. Link the program to create an executable program
As noted earlier, many IDEs link the program and create the executable automatically. However, you may find classes or tools where you will need to link the object files to create the final executable program. Step 9. Run the program using test data for input
When you successfully build or compile a program, you have created a program without syntax errors. However, it is important to check for logic errors. Remember, successful compilation does not mean your program will run correctly. Test your program with both expected and unexpected inputs. Step 10. Correct any errors round while running the program
If you find logic errors in your program, you have to correct them. However, unlike syntax errors where the compiler will tell you that you have an error on a specific line, you must find logic errors by yourself. We will cover debugging techniques in a separate set of notes but techniques include running a program line by line and by watching the values of variables as the computers executes the steps of your program. Step 11. Validate the results of the program
This is a final test to validate that your program solves the problem specified in step 1. This testing should run through all steps of the program from beginning to end. Some suggestions on the programming steps
The book presents a very orderly progression of creating a program which is a good starting point. However, I would suggest breaking down steps 5 through 9 into smaller components. would never write an entire program before compiling and testing. Consider the following:
The reason for breaking a program up into components is that it is often easier to debug from a known point of where things work. For example, I build and test the first component and everything works. After I add the second component, the program logic is broken. Since the first component had worked, I would focus my debugging on the second "new" task. If you write the entire program before testing, you have to consider that the error could be happening anywhere in the program. Video: Beginning to programDemo Video: C++ programming on flip |