OOPS97 Workshop: What Makes a Good Design?

Meeting Summary

6:30 pm Wednesday 13th March 1996

Meeting led by: Charles Weir (see his home page)

This note contains two sections. The first is a summary of the key points which came from the workshop. The second is the raw list of bullet points from the workshop posters. Enjoy!

Key Points

Roles

1. Leader, scribe

Requirements

1. Identify them
2. Ask questions
3. Prioritise them
4. Make sure you're solving the right problem.

Notation

1. Must agree a single common notation.

Techniques

1. CRC, Use Cases, JAD simulation, scenarios.
2. Have software objects as well as real-world ones.
3. Ignore implementation issues

Process

1. Tackle sub-problems or alternative approaches in small goups.
2. Take the best features of a number of designs (considering the trade-offs of each).
3. Be prepared to scrap designs.
4. Don't design by committee.
5. Iterative design.
6. Encourage positive attitudes.
7. Set a timetable; vote

Involve others

1. Peer reviews
2. Discuss initial designs with another team.

Documentation

1. Record the team's reasoning.
2. Keep a brainstorm log.

Bullet Points from Each Poster

• Know your methods
• Ignore implementation issues
• Make sure you're solving the right problem
• Make sure you have peer reviews.

• Using 1 common notation
• Identify full requirements through use cases/CRC (JAD simulation)
• Discuss initial designs with another team
• Identify software objects as well as real-world objects
• Encourage positive attitudes to a design

• Independent peer review -> leverage beneficial features
• Design for reuse - each design has different trade-offs. Take best features of each
• Reach agreement about requirements - can save arguing
• Tackle sub-problems (alternative approaches) in small groups. Confer frequently.

• Force decision
  -timetable
  -agenda
  -voting
  -leadership
• Revisit specification
• Documentation
  -Brainstorm log
  -Record reasoning.

• Plan: set an agenda for the group's focus of attention
• Find a common methodology that all share
• Produce more that 1 solution and specify target circumstances
• Keep it simple

• Common notation helps
• Use cases & CRC cards
• Help discover the objects' behaviour
• Separating control of objects from their behaviour helps with reuse

• Write down a list of requirements first
• Research limitations of environment
• Agree notations to use
• Prototype individually and synthesise

• Be prepared to scrap a design
• Don't design by committee - design then discuss
• Iterative design
• Agree & adhere to a notation
• Be receptive to the ideas & viewpoints of others - they'll be more receptive of yours

• Use consistent notation
• Elect a scribe
• Prioritise requirements
• Work through a scenario - highlights areas of responsibility of objects
• Use CRC to further co-operation between designers

• Know your methods
• Ignore implementation issues!
• Make sure you're solving the right problem & asking the right questions!
• Have peer reviews