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.

I'm not planning to make solutions for the Week 4 tutorial, as such, because it is sufficiently open ended that students will come up with many different correct answers. Here are a few notes on what to look out for, though. Do pass on any questions, points of confusion, common errors. The students will need to be up to date on the course and its reading to be able to do this tutorial sheet, of course (and if you haven't come across robustness analysis before, so will you!)

Question 1

My first thought is that a good set of lists with tickyboxes beside things to be done might be a lot more cost-effective than a software system here. Maybe combined with an Excel spreadsheet or two. Don't spend too long on this, but do make sure they see that an OO software system isn't the only solution!

Question 2

There are different solutions but I'd expect to see:

Almost certainly: Party, Venue, Entertainer, Caterer, Food (better name?), Invitee

Maybe: Quote, Deposit, Questionnaire

Discuss: Date, Time - probably no need to have classes for these as they can probably be taken from some library.

Relationships: should come out in the wash; most associate to Party; could discuss aggregation.

Watch out for nouns that don't become classes (such as Elephant!). Don't labour this, as for most students it's probably easy, but if necessary, discuss the reasons why nouns might not become classes - e.g. they are duplicates, they're vague, they refer to things outside the scope (e.g. Business), they refer to actors (e.g. Client - although there might be a need to also have a representation of the client inside the system, e.g., to store name and address and bank details; but we have no real indication of that in this case)

Question 3

Different ways to split up are possible but I'd expect to see use cases such as

• Generate quotes for party
• Book party
• Pay deposit
• Arrange guest list
• Pay balance

Point to discuss: who is an actor? Only outside entities that actually interact with the system. So if the client is visiting a web page to look at the quotes, confirm their choice etc., then fine, they are represented by an actor Client. If an invitee is just receiving an invitation by post, they are not represented by an actor.

Use case descriptions: should be written clearly, in the active voice ("the client selects..." not "... is selected by the client", in short simple sentences. May, or need not, be presented with the steps/sentences numbered; may, or need not, separate out the alternate courses into a separate section.

Don't spend long on this part as use cases are not the focus of this course - they are mostly assumed from Inf2C-SE.

Question 4-6

will be totally dependent on what they choose to do. Watch out for:

• premature design
• violations of the robustness diagram rules
• controllers that are too complex (if the name of a controller, to be fully descriptive, would have to have "and" or "then" in it, be suspicious)
• objects that do nothing but store data, especially if there is functionality acting on that data in a different class - consider moving the functionality to where the data is
• getting bogged down in UI design (at this stage you probably do want to identify what screens there are and the navigation paths between them, but not more).

---

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