Dex Anderson wrote:I'm doing an exercise involving scheduling algorithms and I'm not sure where I should begin.
OK, well looking at your instructions, my first question is: What is "time_quantum" in your command line? Is it the amount of time (presumably in ms) that your simulation should run for? It's the only thing that makes sense to me, but I could be way off base.
So, first thing: get that sorted out (and if you're unsure, ask your teacher before you start writing any code; because if I'm/you're wrong, it could have a major effect on your program).
The next thing to do - again, before you write a line of code - is to understand the problem.
Get out some paper and a pencil and write things out in English (or your native language). Diagrams and imagination can be invaluable too - for example, I'm an old railway buff, so for things like queues, I often think of a tunnel with only one track in it; for something like this, it would probably be more like a railway shunting yard. But the important thing is to be absolutely clear in your mind what you're trying to do, before you commit a single line to Java.
Finally (and only after you've done all of the above), is to start thinking about how you're going to do it; and the main advice I can give you here is to think first about the classes that you're going to need. Java is an object-oriented language, so it works best when it has objects doing the work, rather than reams of procedural code.
Just off the top of my head, it sounds to me as if each line in your file equates to a Process, and the main "mill" of your program is a Scheduler, but don't just take my word for it, think about it. There may well be other classes lurking around; and I suspect that you'll also want some way of encapsulating your FCFS/SRT/RR styles (an enum?).
Simply put: I'd say you're several hours - possibly even a day or two - away from writing any useful code yet. Use that time well.
Bats fly at night, 'cause they aren't we. And if we tried, we'd hit a tree -- Ogden Nash (or should've been).
Articles by Winston can be found here
Oh, and just one other thing: while you're doing all this thinking and planning, give some thought to how you might test your program.
One of the excellent chaps here (Junilu) would probably advise that you actually write those tests first. I'm slightly older-school, but I certainly agree that one of the best times to be thinking about testing is when you're designing.
At the very least, keep a separate sheet of paper for writing down tests that occur to you while you're mulling all this stuff over, because writing the program is just the first stage. You'll then need to be able to prove that it works.