Criterion B - Solution Overview

Instructions and Advice - Class Diagrams


Structures to Use

You really should be using either ArrayList or LinkedList, rather than, or in addition to, arrays. So use LinkedList if you are able to apply either a stack or a queue, and an ArrayList for everything else.

You should also look for opportunities to use polymorphism, with both overloaded constructors and overriding, and inheritance, even if pretty simple.


Class Diagrams - You will use UML (Universal Modeling Language) Class Diagrams for this.
For helping you draw your diagrams, you can use either OmniGraffle (a downloadable application) or www.draw.io, free on the internet.

Following is a diagram which shows you exactly how you should do your UML. Pay particular attention to how parameters and return values are put in, along with the + and - of public and protected attributes/methods. If you look at the others suggested by this Google image search in the "Try these too:" area, you will see lots more examples, and though not thoroughly consistent, they will help you get the idea.

UML diagram of a template class

Export your chart as a jpeg and put it in your the Word document you will upload. (And note that with all your OmniGraffle work for your dossier, export before the 14 day trial is up, or you won't be able to.)

GUI Class Example

Likely Classes

I wouldn't want everybody's class structure to be exactly the same, but on the other hand it's perfectly natural that they will be similar.

- For sure you will all have one GUI, and you may even want, for some reason, to have another (ask me how to implement this if you want).
And as attributes, for now, you don't have to put all the elements (all the textFields and buttons etc.), but do put in a representative few, and any major ones, like tables.

- You should all have at least one template class, with its attributes, gets and sets, and probably other methods.

- Very possibly, you will implement inheritnce, so the super class and sub-classes.

- If you will be searching and sorting, I would prefer that you make a separate specialized class for this.

- And then for any other specialized stuff that your program may do, it may very well make sense to do this in a specialized class, from which you make an instance in the GUI.

For an idea of the kinds of class structures that you will have, find any of the quite involved OOP projects we did in class.

"Classic Arrangement" Example UML Diagram

"But, what about changes later on?..."

You need to put as much thought into this as you can at this stage. Along with any flowcharts/algorithms/pseudocode you can come up with after this stage, this is your go-to blueprints from this point on.

In terms of the question of what happens if/when you change things while programming, that is bound to happen for sure, and you're free to make corrections/alterations to your class diagrams as you go through your coding process - in that way it will be a live document. (Though you'll note the one thing that is not allowed, with this being a school project, is you going back after the fact and reverse engineering anything your Criterion B. )

But - and here's the big thing, once again - the more you can make those changes now, with a scratch of the head, and then, right-click delete or type-type-type in Draw.io, the better. Remember: "Weeks of programming can save hours of planning..."