|
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!)
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).
A really common error is to have a class called System, because that term comes up a lot in text about the system to be built! This invites the design error sometimes called "God class" - having a class that has all the responsibilities, all the behaviour, leaving everything else as only containers for data. You might mention this, and discuss the difference between this (putting all the behaviour in one giant class, whose code is then unreadable and unmaintainable) and the Facade patter that we'll meet later. In Facade, there is a class that is the public face of a subsystem - outside clients always contact the Facade instance to ask for services from the subsystem, and the Facade object forwards requests to the appropriate object inside the system. In this pattern, the Facade's own code will be very simple. However, it shields the outside world from knowledge of the structures inside the subsystem, which means these can be changed easily if later desired.
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. This can sometimes seem like an artifical distinction, but it's the consequence of "you have to stop somewhere" in modelling the system. There is a field of Business Process Modelling, which has its own modelling languages (e.g. BPMN) that are adapted to modelling business processes rather than software... but that's outwith the scope of this course.
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. Alastair Cockburn's book Effective Use Cases is a great reference for anyone who wants to read up on that. Don't spend long on this part as use cases are not the focus of this course - they are mostly assumed from Inf2C-SE. In a SEOC exam, I might assume people knew what use cases were and could read a use case diagram, but I would not ask them to write a use case or draw a use case diagram.
perdita@inf.ed.ac.uk)
|
Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: school-office@inf.ed.ac.uk Please contact our webadmin with any comments or corrections. Logging and Cookies Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh |
