|
CSE Home | About Us | Search | Contact Info |
It means you need to describe the overall organization of the code into directories, files, and classes and/or functions. So first give the names of each of the source code files and summarize what is contained in each one. Then give an overview of each method/function in each file.
Start at the beginning. When the program starts running, what code is first executed. What does that code do? Then continue to describe, in order of events, what functions get called and what each of the functions called does. Due to branches (for example, if/else statements), there may be multiple paths that a program execution could possibly follow. Describe all significant paths.
Don't say much about the unimportant functions. Just mention them and say that they are unimportant.
This is what you should ask yourself: Is this important to someone considering a change to the TuxType program? (An example of a change is the addition of Dvorak support, but that is not the only significant change that could be made to this program.) If it could be important to anyone considering a significant change to TuxType, describe it in detail. If not, gloss over it.
It is very possible that you won't understand how all the functions work. Can you figure out what the function is supposed to do, even if you don't know how it does that? Often, that will be enough. At any rate, don't agonize over any pieces of code that aren't clear. This is a long assignment.
Any nontrivial piece of code is long. You need to do the best job you can given how much time you have to do it. Remember, the software engineer never has enough time. If you produce a document by Monday morning that is useful to someone trying to make a change to the code, then you have done your job. So make value judgements -- what do you need to spend time on and what don't you? What functions can you label as "minor" or "unimportant"? Which ones do you really need to understand in order to have any idea how the program operates? What parts of the function do you really need to look at, and which can you gloss over?
Just do the best job you can.
Yes. You don't need to describe anything twice. Just say, "This function is similar to the function [blah], with the following differences: [explain differences, if any]".
Hmm... ok. The important thing is to use your own judgement. There is more than one way to summarize the TuxType code. There are many ways that you can describe the Dvorak change. The important thing is to present a coherent document that is useful.Here are some functions that you may not need to look at much:
There are even more functions that can be considered unimportant, but I leave it up to you to decide which ones they are.
- All of the functions in graphics.c
- All of the functions related to the Practice screens
Don't take this hint to mean that I don't think you should include these functions in your description of the Dvorak change. You are free to use any piece of the code to describe your approach to the Dvorak change. You are free to describe any part of the code you think is important. This is only a hint for those who feel overwhelmed.
Department of Computer Science & Engineering University of Washington Box 352350 Seattle, WA 98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to vibha] |