University Homepage School Homepage School Contacts School Search

Note: the following is adapted from notes I sent the tutors. If, after the tutorial and reading this, you are in doubt about something, one thing you could do would be to ask about it on the Forum, where hopefully another student can help, or if not, I'll follow up myself.

Q1

Interface of Party. At the start of the Week 5 tutorial it had an API something vaguely like:

• public constructor Party (v : Venue)
• + bookEntertainer (e : Entertainer)
• + bookFood (f : Food)
• + Money getTotalCost()
• + void pay(m : Money)
• + void partyOver()
• + void cancel()

but with lots of implicit constraints on which messages can be accepted when, without obvious motivation. That's bad; it's going to make the class hard to use. Allowing different elements to be booked in arbitrary order would be an improvement. We'd probably want a no-argument constructor, and maybe a query operation everythingBooked() to check whether everything is ready. What should happen if a client calls bookX twice? You might consider having these operations return error codes, and adding cancelX methods in case the user really means it. How should we handle the fact that cancelling is not always possible? Probably via an error code return value. (Both for the dual booking and for non-allowed cancelling, we could alternatively raise an exception if the client does something they shouldn't. Conventions differ, and people feel strongly for either alternative.)

What about inheritance? Should we design for it and document it, or prohibit it? I'd vote for prohibiting it in this case: inheriting from classes that have non-trivial statecharts tends to be a bit of a nightmare.

Q2

Key section: "An applet can react to major events in the following ways:

• It can initialize itself.
• It can start running.
• It can stop running.
• It can perform a final cleanup, in preparation for being unloaded.

" Since the default implementations of init(), start(), stop(), destroy() in Applet do nothing, the basic PSM should have just one state with all these messages as events on self-transitions (an event that does nothing can't cause a state transition, and it can't matter what order you call them in!).

However, in an actual implemented applet, the methods will do things and so it is possible that there could be a non-trivial state diagram. Moreover, it's possible that we might want to set up an agreement between objects of this class and their clients about what order methods will be called in - recall that this is the main purpose of a PSM.

The JDK documentation for Applet is in some sense backwards: you will see that it is written principally for people implementing subclasses of Applet (the majority), not for the tiny minority who are writing clients of these classes (developers of browsers and appletviewers). The clients are pretty much fixed, and the subclass developers have to fit in! One thing we are told: under destroy(), "The stop method will always be called before destroy." i.e. the browser will ensure this. It's implicit that init() is called before anything else, but as developers of an applet subclass, perhaps we ought not to assume any more than this. For example, perhaps we should write our start() and stop() methods in such a way that they can be called any time after init() has been called and before destroy(), even if they won't do anything much.

In this case, you'll get the start marker to go into one state (AwaitingInitialisation say) from which init() takes it to another (Ready perhaps), from which start() takes it to Running, with stop() taking it back to Ready. start() in the Running state would cause self-transition, as would stop() in the Ready state. destroy() from the Ready state should take us to a stop marker. We don't have to deal with destroy() from the Running state, if we believe the JDK documentation that browsers will always call stop() first: that is, the JDK documentation seems to expect that our protocol will require this. Since we're assuming init() will be called before anything else, we don't have to offer any other transitions from AwaitingInitialisation. Should we allow for init() being called from Ready or Running? It's probably good practice to do so, and both should probably lead to the Ready state, but it wouldn't be out of the question just to forbid this in the protocol, i.e., don't offer init() transitions from those states.

(I have not delved deeply into what the full documentation says or what applets do in practice - from memory, most applets are written simply and robustly enough to cope with "wrong" sequences of messages, and browsers will sometimes do strange things. It's quite likely that some students know more about this than I do.)

Q3

A Date that includes time information is clearly mis-named... For the rest of the question, see the linked pages for comment.

---

This page is maintained by Perdita Stevens (perdita@inf.ed.ac.uk)