Class 43: Project Discussion

Held Wednesday, April 21

Summary

• Problems with summaries
• Narratives for improving design

Notes

• 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 his class.
• Don't forget: we'll have prospectives on Friday.

General Comments

• 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 to provide.
  • You seem to have made many design decisions without considering alternates.
  • 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 I expected.
• 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? For handlers?

Narratives

• 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.

Initialization

• 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 to do.
• 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.

Interaction

• 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?

Some Design Decisions

• 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 is available?
  • The latter solution would be preferred for an ``industrial strength'' client.
• 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.

History

• Created Monday, January 11, 1999.
• Added short summary on Friday, January 22, 1999.
• Filled in the details on Wednesday, April 21, 1999.