9.3 MODELING LANGUAGE
The initial idea was to have a modeling language for building digital watches. In this
section, we will follow the analysis of the domain and the development of the
language in chronological order.
9.3.1 Reusing Watch Applications in a Family of Watches
It was soon evident that it would be good to break a watch down into its component
applications: time display, a stopwatch, an alarm clock, and so on. Beyond providing a
sensible modularization of the whole watch, this would also allowa watch application
to be reused in different watches. Since these watches would have different physical
designs??”displays, buttons, and so on??”there was a need for some decoupling of
references to these physical elements in the models. For instance, if a model of a watch
application wanted to specify that a certain operation was caused by a certain button,
MODELING LANGUAGE 193
we had to answer questions about whether that button was available in the given
physical watch, whether it would be named in the same way or have the same
semantics, and what to do if no such button existed.
Thinking about this issue prompted the idea of explicitly modeling a whole
group of watches as a family. This would be a separate level of modeling, probably
with its own modeling language. Often in DSM such a level exists, but it is not
always explicitly modeled: it is enough to simply have several products??”watches
in this case??”each built from its own set of models.
Pages:
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358