ooad1-1  Exercise 1: Which Mode?
==================================

(a) Splitting a billing feature with a colleague: SKETCH.
    Draw the three or four main classes and the arrows between them on a whiteboard. Leave out attributes, types and every operation that is not part of the argument. Photograph it or redraw it as text if it will matter next week; otherwise let it go.
(b) Handing a payment-gateway design to an outsourced team: BLUEPRINT.
    The reader cannot ask you across the desk, so be precise about the interface they must implement: operations with parameter and return types, error cases, and a sequence diagram of the critical exchange. Date it and say who owns it, because it will drift.
(c) A new teammate's first day: SKETCH (the "big picture" kind).
    A component sketch of five or six boxes and one sequence diagram of the most common request. Leave out everything a newcomer can read in the code later. The aim is orientation, not completeness.
(d) A tool that generates code from the diagram: PROGRAMMING-LANGUAGE mode.
    Here the diagram is the source, so it must be complete and exact, and edited with the tool. This is the rare mode, and chapter 10 covers why it is uncommon.
(e) A ten-line throwaway script: NO DIAGRAM.
    Modelling is for ideas that are expensive to get wrong, shared, or not yet understood. A script run once is none of these.

WHY THIS WORKS AS AN ANSWER
---------------------------
Each answer follows from three questions: who is the reader, how long will the diagram live, and what does it cost to be wrong? A diagram for a colleague standing next to you can be vague; one for a team you cannot talk to must be precise; one that generates code must be exact. Answer (e) matters as much as the others: knowing when not to model is part of the skill.