Class 43: Project Discussion
Held Wednesday, April 21
- Problems with summaries
- Narratives for improving design
- Hopefully, we'll have a discussion of UML on Friday. This entails
me learning UML by Friday, so it's somewhat iffy.
- I'd appreciate it if some of you would attend Clif's class today
(2:15-3:05). I'll give one unit of extra credit for anyone who attends
- Don't forget: we'll have prospectives on Friday.
- Clif and I were generally displeased with the summaries that you
gave us. Why?
- There were too few details on your own parts; from my perspective,
many of you didn't spend enough time thinking about necessary
classes and ramifications of your design decisions.
- There were even fewer details on what you expected other classes
- You seem to have made many design decisions without considering
- Many of you failed to make distinctions between internal methods
(which are an implementation issue) and external methods (which
were the focus of this assignment).
- There was surprisingly little consideration of what might go wrong.
- The blame for this is mixed; while I expected you to consider these
issues in more detail, I didn't provide you with an example of what
- We'll do our best to visit these issues more carefully today,
through the use of examples.
- For those of you building GUIs, we were concerned to see that
- Few of you had actually sketched the GUIs; that's an important
part of your first design.
- Few of you considered how many classes you might need. For example,
should you have separate classes for each window? For each button?
- We will do our best to tease out some issues and details through the
use of narratives. I'll begin the narrative and then ask appropriate
groups to continue at appropriate points.
- Clif and I will fill in for the missing groups.
- In each case, we should consider
- What the user does (types)
- What information the component needs in order to start up
- What the component does (vaguely) when it starts
- What other components it interacts with, and what it needs them
- I'm the administrator. I sit down to start the artist client.
(This is similar for art and buyer clients, too.)
- I'm the administrator. I sit down to start the database.
- I'm the administrator. I sit down to start the reporter.
- I'm a runner. I sit down to start the runner client.
- In these cases, we should again consider
- What the user does/types
- What information the user needs to type
- What the component does in response (generally)
- What components it uses and what it expects them to do
- What response it gives
- I'm the administrator. I want to enter a new piece of art. What
do I do?
- I'm the administrator. I want to check the status of a buyer. What
do I do?
- I'm the administrator. I want to get a list of all the earnings
for all the artists, ranked from lowest to highest. What do I do?
- I'm the administrator. I want to set policies for sending art to
auction. What do I do?
- When a GUI makes a request from the database (via the network),
does it get a return value (thereby ``timing out'' until a response
comes in), or does it supply a function to call when the response
- The latter solution would be preferred for an ``industrial strength''
- What kinds of requests do we make from the database?
- The base request is: Give me the object with key K.
- However, the GUIs don't necessarily know the keys. Hence, we also
need to support ``Give me all the objects of type A that
contain B within field C''.
- What kinds of responses should we get?
- What kinds of errors?
- Will the GUIs support multiple windows (so that I can, for example,
work on two artists at once)?
- One alternative is to require the user to open multiple copies of
the same program; this is less appealing.
- Created Monday, January 11, 1999.
- Added short summary on Friday, January 22, 1999.
- Filled in the details on Wednesday, April 21, 1999.