9.4.
While one part of a member of the product family of Watches would thus
specify the behavior of the Watch, a second part was needed to specify the physical
details of theWatch. Mostly these would be the domain of an industrial designer, but
the behavioral part would also need some of that information. In particular, if we
wanted to generate a Java applet as a Watch emulator, we would need to know
three things: the buttons on the watch, the icons it had, and the number of digit pairs it
could display. The ?¬?rst two could in theory have been found by trawling through the
set of applications and including all referenced buttons and icons, but this was not how
we wanted things to work. We wanted a Stopwatch application, say, that used Up,
Down, and Mode, to be usable in a watch without a Mode button, for example one
containing only the Stopwatch application. Similarly, rather than have an error if an
application tried to turn on an icon that was not present in the physical watch, we
would simply do nothing at that point. This made the watch applications more
reusable, and allowed the application modeler to concentrate on the application itself,
without having to know beforehand the exact details of the physical watches in which
it would be used.
We decided to call a member of the product family a Watch Model??”???model???
being used in the sense of ???a Corvette is a car model,??? rather than ???a graphical model
of a car.
Pages:
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376