Alternatively, if the value is left unspeci?¬?ed, a code generator could produce
the default value.
3. A role (or relationship): Different ways to press a button can be speci?¬?ed as a
new role or a relationship, keeping the button concept in the language
unchanged.
4. A property of the current role: The pressing policy could be speci?¬?ed by
adding a property for the current role that represents a button press.
Other kinds of extensions could be considered, like having the button pressing
policy speci?¬?ed in the family diagram in which the button is ?¬?rst introduced. This
concept, although hardly relevant for our sample case, would keep the behavioral
designs untouched and move the decision to each individual watch product.
View of Variation Creation of a DSM solution should also be inspected from the
variability point of view: howdifferences among applications can be speci?¬?ed. This is
not always a topic for language de?¬?nition since the variation can be handled
elsewhere, typically in a generator. This makes management of variation simple for
developers, as it totally hides it from models. A developer just chooses among
different generators, which actually access exactly the same set of models to produce
the code. For example, the mobile phone case uses the same modeling language but
different generators to produce either Python or C++ code.
Pages:
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439