We thought it was fair to assume that any digital
watch company worth its salt would already have existing functions to return the
current time, along with functions to store and recall and perform basic arithmetic on
time variables. This meant we could consider the time operations on a high level,
rather than the implementation details of the bits and bytes of data structures to store
time.
The ?¬?rst question to be answered was one about the boundaries of the domain: did
we need to handle dates as well as time? Thinking through the various possible watch
applications, it seemed that most had no connection to dates: an alarm could not be set
for a given date, for instance. In fact, only the basic time display would show dates.
The handling of dates would most likely be identical from watch to watch: a source of
commonality, not of variability. In addition, the behavior of dates is complex, with
weekdays, day numbers, months with different numbers of days, leap years, different
orderings of date elements for different countries, and so on. All in all, it looked like
building a modeling language for handling dates would not result in any productivity
improvements for Secio. Rather than introduce complexity for no gain, we decided to
leave dates out at this point and concentrate on time.
Thinking about the stopwatch application, it seemed there could be two ways to
think about time variables and the underlying platform.
Pages:
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365