Exam Prep Idea:Since you will be rusty with coding just before the exam, re-looking at your IA would be a great way to get you back into the swing of things.
Even take a bit of time to do a 1.5 version of the program, based on the "Extensibility List" (formerly your To Do list), and on comments made by your client at the end of your (first) cycle of development.
Firstly, here's a definition of extensibility (from Wikipedia.org): Extensibility is a software engineering and systems design principle where the implementation takes future growth into consideration. The term extensibility can also be seen as a systemic measure of the ability to extend a system and the level of effort required to implement the extension.
For the "Extensibility" section of the IA, here is what it says:
The student should design the product so that it can be maintained by another party and/or be further developed. Therefore the design of the product should include appropriate folder and data structures, intuitive file and/or class naming conventions and, where appropriate, comments in the code.
So this is not so much the quantity of things that could be extended with your program, rather it is the degree to which you have made it easy for someone to extend your program. The main things that this boils down to is good naming conventions and adequate commenting of your code. But there are a couple of other things I'll get you to look at/adjust, too. The "Part 1" below should only take 5 or 10 minutes, and the "Part 3" another 10 to 15 minutes, but the "Part 2" (commenting) could potentially take a lot longer, depending on how much commenting you have done in the process of coding.
Part 1A - Class Structure/Names and Variable Names
In terms of appropriate folder and data structures, for us it's mainly your variable names that is the focus here. So check to make sure all of your variable identifiers would make sense to someone else looking at your program in the future. So variable names such as "s" instead of "student" would be problematic. I think in general you have good variable naming habits, but still, look over your program and be sure.
And while you're at it, do make sure that your variable names all start with a lower case letter, and also that your classes all start with an upper case letter. This is also a good habit of most of you, but I have noted from time to time slip ups in this regard.
If you have to make corrections to variable or class names, make sure you do the re-naming via a right-click and Refactor, Rename.
Part 1B - Commenting
As a general rule, you should comment anything that requires explanation, and not comment things that are obvious. And also, as a rule, you should have been commenting as you coded; it's obviously way easier to comment on something you have just done than to go back weeks or months later and try to do so.
There are two main places you would be expected to have comments:
- Wherever a variable is declared that requires a bit of explanation. (So not, for example int counter or other very obvious variables like String input, but other ones whose purpose you might not understand later on.)
- At the beginning of a method, both pre-conditions, and post-conditions:
• Pre-conditions: The conditions that need to have been done, or need to be true in order for the function to work as intended. If it requires parameters, what those are, and possibly their range/type in order to be valid.
• Post-conditions: What the method should be expected to have accomplished by the time is is finished. If it returns something, what that is, and possibly the expected range of that value. And, particularly if it is a void method, a bit about what it accomplishes when it runs.
How much commenting??
It's likely no coincidence that the word "appropriate" is added into the IA commenting instruction. Commenting *everything* could take you hours. But still, there's a happy medium between that and no commenting at all. So do keep in mind that very little to no commenting will torpedo any good grade for Criterion D.
The main thing is that your program functions, either fully or partially.
(Part 3 - "Extensibility List"
****I make this grey to highlight that it's the least important of the three parts. Look at this as being extra, and something that can be talked about in E - Evaluation.****
Even though commenting is the biggest part of this part of this criterion, and you will have already had pretty good variable naming conventions, there is one other thing I want you to adjust and/or add to. Change your To Do list that you've been keeping at the top of your main GUI class to be an Extensibility List. Look at that list lists and spruce it up a bit to be aimed potentially at another person, or you years later, and so make it to be more descriptive and complete with regard your extensibility ideas.
Keep in mind that this may be all that someone in the future will have to go on, so if you have a few really good ideas about how your program could be expanded and improved, write them down in this list clearly and fully. Don't worry if this commented part of your program goes on for quite a few lines - those lines will potentially be golden to either you or another programmer some time in the future.
One last important point and that is to get rid of any unrealistic/undo-able recommendations in your To Do/Extensibility list. This is mainly because these should project to your stage E - Evaluation. And the part of your evaluation which suggests "next steps" should suggest realistic ones.)
Here is a list of some fictitious things that would be appropriate for an IB CS HL database, at the end of the programming stage:
- "Add saving capabilities to the Chicken database."
- "Add extra JOptionPanes which act as step-by-step instructions to properly go through the input of student information process."
- "Change the sequential search of books to work as a binary search (and so add in sorting methods too)."
- "Add sorting of pineapples, and have all of the products sortable both ascending and descending."
- "Make the table refresh when you click on the tab, rather than when clicking on the Refresh button."
(And that reminds me of an idea I had lately: that in the future, IB CS students could choose as their IA topic extending yours! Cool idea, eh? In fact, we could start to assemble a suite of "IB Office" programs, or an "Upper School Administrative" suite, from which there would be a master-GUI to choose what particular task (i.e. IA) you wanted to work with.)
Does reference to this appear in your main Google doc, or just in your code?
Just in your code, in fact there is no Criterion D document which is submitted; just the video. But as it says in the video instructions, it would be good to mention and show your good variable names and commenting etc. during your video.
So now go on to the video instructions:
-------> Video Instructions <-------