IME Design Fest - Let's have fun with OO Design!

Design Team Process Guidelines

  • Introduction of the participants
  • Reading of the documents
  • List of discussion subjects (each member can add questions/points to the list).
  • Planning of discussion. List unclear requirements, open questions, proposals.
  • Discussion. This discussion should try to follow the planning.
  • Sketch of object design models. Sketch the models and highlight patterns. Allow multiple models to develop in parallel.
  • Visit other group(s).
  • List fudge areas — the areas where there is a disagreement or where choices are made without a solid basis.
  • Try to evaluate design models on their strengths and weaknesses.

The Moderator

The moderator is helping the group of designers to make progress. She or he will guide the group in the process, but definitely not in content. The moderator's primary responsibility is to prevent the group from wasting time. For this reason, she will follow a program of milestones (milepebbles?) to prevent the group from getting stuck in a certain phase.

The moderator will:

  • Assure a fair chance for all participants to say their opinion.
  • Reduce the influence of single persons.
  • Indicate progress or absence of this to the group.
  • Summarize what the group has done so far to get to a common understanding.
  • Ask questions to make the group aware of missed areas.
  • Solve clashes between personalities by clearly stating the difference and leaving it at that.
  • Plan a time to see the results of other groups.

 The moderator will not:

  • Steer the group into a certain direction.
  • Give "expert" advice.
  • Show bias.

The Recorder

The recorder is responsible for a report about the session's results to be added to the course web page by October 15th. This responsibility does not imply that the recorder must do all the work, it means only that she/he is the one that coordinates this activity; she/he will delegate some of the tasks to fellow group members who will gently agree to help. Other people can gather documentation (e.g., someone else could be the one at the drawing object diagrams).

The recorder will:

  • Truly, accurately record the spirit of the session, not unbalanced by the recorder's view.
  • Ask for clarification when things are not clear.
  • Join the discussions if they wish.
  • Assist the moderator in summarizing
  • Submit a report, by adding the group's results to our Design Fest web page at Stoa.

The recorder will not:

  • Steer the session.
  • Emphasize her/his own opinions in the report. 

Suggested Deliverables

Assumptions
list of any assumptions made during the session, including and especially assumptions about scope, architecture, existence of other modules or services, implementation environment, and implementation language.
Class Model
list of classes and diagram of relationships; should show, at least, inheritance relationships, aggregation relationships, and uses relationships. Anything more starts to delve into specific methodologies and languages, so make sure they are mentioned in the Assumptions.
Class Interactions
describe the methods used when classes interact, some examples are: via parameters, common data area (e.g., persistent database), import/export file, or XML stream. In many cases, the class interactions can be described with some sort of interaction diagram. A really detailed design will identify formats, acceptable values, and their meaning.
Interfaces
describe how does the system just designed interacts with the outside world (this may already be in the problem description)
Component Model (optional)
if applicable, provide a description of each component, its purpose and its interfaces
Persistent Data Model (optional)
identify which classes need to be persistent, if any.
Error handling (optional)
for the ambitious team, describe how the system will gracefully handle errors, such as bad input, or system failures (network, DB, etc.). This may require additional descriptions in the other deliverables.
Class Details (optional)
describe each class including name, purpose, role in a pattern (if applicable), attributes, states (if complex), method names, interesting algorithms for methods

 

Problems

Each group must choose one of the following problems and bring it, in printed or electronic form, for the class of October 5th. Each member of the group must read the problem statement before the class and have his/her own copy.

 

  1. NASA JPL's Flight/Ground/Test Event Logging Facility
  2. Joseph Bergin's Visual Computer Science Laboratory
  3. Larry Best's Workflow Application - Delinquency Collections
  4. Alistair Cockburn's  Alistair Cockburn's Vending Machine 
  5. Jim Helioti's Outer Space Battle Game
  6. Henry Baragar and Gail E. Harris's Personal Expense Account Manager

 

 

Submission

 

The exercise submission must be done here.