DAT 501
Frequently Asked Questions
About [S] 10.14.:7
- When can events start and end?
- You may assume that events start and end at the full hour or at the half hour. So an event could be 10:00–11:30, but never 10:05–11.16.
- Is one month enough?
- Yes, one month is fine. Take June 2003 for concreteness. You might even want to enter the day of the exam. (Of course, you are welcome to make the calendar work for the entire year, using GregorianCalendar for help. It’s not much more difficult. Or very interesting.)
- What about overlaps?
- If the user adds an event that overlaps another, then your application may not crash. At least, it should warn the user that she is creating two appointments at the same time. Whether you chose to allow this or not depends on you—this basically will decide how your Event model works.
- There seem to be very few formal requirements, at least compared to the Wumpus exercise! How should the architecture look? What classes do I need?
- This exercise indeed comes with very little help. However, it
is understood that you must adhere strictly to the MCV
model. For example, you probably want separate model classes
called Event, Day, and Month (but other models would work as
well). Under no circumstances may these model classes perform
controller duties, or have view components. You know the drill by
now. You certainly don’t have free hands!
Honestly, all such decisions are really up to you. This includes lots of User Interface decisions. But we’ll be glad to help. It is probably a good idea to draw a sketch of how you want your user interface to look, and (especially) a UML diagram of your architecture, and show this to one of the teachers for feed-back.
- What about loading and saving calendars?
- The last two lines of the exercise talk vaguely about saving calendars, but let me be a little more precise, since this is a mandatory exercise. It is required that your application allows the entire calendar (i.e., the entire month) to be saved in a file. The easiest way is probably to do this whenever the application is started or quit: look for a file called "~/myCalendar.txt" at startup, and read the data. When the user quits the program, write the new contents into the file. If you are more ambitious, you can do this with a menu, and a file selector, and whatnot—the details of the user interface are up to you. But it is important that the calendar remembers its updates. (Otherwise, it wouldn’t be a very useful calendar, would it?) You will learn about loading and saving in Chapter 11, so by all means ignore it in the beginning, and get the entire thing working without file interaction.
About [S] 9.9.1:1–3
- What are the requirements for this exercise?
- At least the following must work (correctly). Define some rooms
and a treasure hunter, for example,
RoomBehaviour[] house= new RoomBehaviour[4]; house[0]= new BasicRoom("kitchen", "pasta"); house[1]= new VaultRoom("bedroom", "swordfish", new Jewel("diamond")); house[2]= new VaultRoom("library", "gnu", new Jewel("ruby")); house[3]= new VaultRoom("cellar", "swordfish", new GoldCoin()); TreasureHunter dick= new TreasureHunter("Daring Dick", "swordfish");
Now write code that lets Daring Dick enter every room in the house and take all the treasure he can find there (use a for-loop).
Finally, print all the treasure Dick collected by using his getTreasures() method. In the above example, he should have taken the diamond and the golden coin. Show this to the Lab assistant, and you’re finished!
About [S] 5.14:18
- The graphics in the book aren’t very nice
They certainly aren’t! Instead of the character based view in the book you are supposed to draw the scene using the standard Graphics commands. I used a very simple design with rectangles. You are welcome to draw small images of Volvos instead if you are ambitious.
- How many cars are there?
- I strongly suggest to have only two car objects, which magically (and invisibly) travel back to the beginning of the road. (Instead of creating a new object each time a car leaves the road.)
- What about tests?
- Ah! As usual, you have to make sure that every part of you code is traversed at least once. Since much of the behaviour depends on a random number generator, this is difficult to do systematically. This is a well-known and important problem with interactive applications and simulations, and makes testing more difficult but no less important! Thus, for testing I recommend to replace the random number generator by a system that reads the numbers from the user (for example, from the comand line at start-up, or via a dialog) so that you can enforce exactly the delays you want. It probably is a good idea to have the cars report their behaviour (“Waiting off-screen...”, “Holding back for other car”, “Traveled 29 m”, etc.), for example to System.out.
- I can’t get the timing right
- You mean your car doesn’t travel exactly 10 pixels per second? Never mind, the car speed really is not important. As long as your cars flow more or less smoothly across the screen, you’re fine; your program’s “seconds” don’t have to be real life seconds. This is not an exercise about real-time programming.
About [S] 5.8:8
- I seem to do everthing six times over in my program. Is that correct?
- We haven’t seen iteration in the course yet, so yes: you have to
write a lot of similar code six times. To make your life easier you
might want to start solving the exercise with only 3 slices, and then
add the code for the last 3 slices when you got everything working.
Obviously, if you do know how to write a loop in Java, then by all means do so! You don’t have to pretend to know less than you do. But you still need to follow the interface specification—if only because it is much easier for us to grade.
- Where to start?
- Try to solve the exercise without drawing the pie chart itself first. Thus the output view will show show the labels. When this works (including the tests and including the colors) you can start having fun with drawing the chart itself.
- Do I need more tests that (a) and (b)?
- Oh yes. For instance, you need to test every number of slices, including a pie without any slices at all. And you definitely need to report how your system responds to malformed input: negative values, values that don’t add up to 100, etc.
- Should PieChartWriter extend JPanel or JFrame?
- You can do what you want; Chapter 5 is unsure about that
itself. In any case, the setTitle() method should really be part of
the interface specification for the exercise. I recommend to extend
JPanel since many other view object in the book do that as
well.
Update: I wrote Dave about this and he agrees. The book originally used JFrame subclasses in all these cases, which is why there are still some examples left. But the current edition ought to use JPanel.
How are the exams?
The exams are written, and take 5 hours. You write your answers using pen and paper (so computers aren’t involved). You can bring all the written materials to the exam you want, from today’s newspaper to the Encyclopedia Britannica, none of which will help you much. You can’t bring a computer or a mobile phone or similar gimmicks.
I recommend bringing the course book [HR], and maybe you own written notes about lectures and exercises.
What sort of exercises will there be at the FP exam
Unfortunately, I cannot refer you to a previous exam (extenta) because we haven’t used SML in this course before. But I can explain what kind of exercises there will be using [HR].
(On the other hand, you can do that yourself as well: of course I will ask questions about the chapters we covered in class—so you have to know all the SML introduced in the course, including exceptions, datatypes, pattern matching, and so on—, and these questions will be similar to those discussed in the TA sessions. And of course there won’t be any exercises you’ve done before, nor any whose solution you can find in the book. And of course there will be easy exercises to get you started, and a few tough nuts to crack as well, but nothing like [HR] 7.8.)
You can expect the folling type of questions at the FP exam:
- Write an SML declaration to compute a mathematical function. This will typically involve recursion. Examples: [HR] 1.1–1.5 [HR] 2.1, 2.2. This is the easy exercise.
- Write a number of functions that together solve a more involved problem. The three exercises [HR] 2.3–2.5 are a good example of such connected questions. Another example would be [HR] 2.6–2.7. Also, each of [HR] 3.1, 3.2, 3.3, 3.4 would be good exam questions (but the latter would have to be explained better).
- Type checking, as in [HR] 2.8, 2.9.
- Lists and tail recursion. Expect at least one exercise like [HR] 5.2 and the other exercises and examples in that chapter. The questions including datatypes in chapter 7 (for example [HR] 7.4, 7.7) are similar but larger. This question might be combined with other questions to make a larger, more satisfying exam questions consisting of several smaller, connected exercises. For example, [HR] 2.6, 2.7, 5.5 together would make a good exam question of progressing difficulty, which would make up around one third of the exam.
- Recursive datatypes, i.e., the stuff from Chapter 8. A (relatively hard) exam question could consist of [HR] 8.4(a) and 8.4(b) (but [HR] 8.4(c) is probably too difficult). This is a good example of a question that tests you modelling skills (i.e., if you can write a datatype that represents something, in this case Boolean formulas) and your programming skills (i.e., if you can write the code to do something useful with that model, in this case transforming a finite tree).
- Testing. Expect to be asked to construct a set of test cases for one of your solutions, like in [HR] 4.2–4.3.