Similarly, in the banking domain, everybody knows what a bank day
means. If the semantics of a particular concept cannot be de?¬?ned, most likely it
is not a relevant concept for a language either.
. They establish a natural mapping to the actual problem being addressed by
DSM. This makes model creation easier in the ?¬?rst place and enables modeling
operations like reusing model elements at the domain level. A close mapping to
the domain also makes models easier to read, understand, remember, check, and
communicate with.
IDENTIFYING AND DEFINING MODELING CONCEPTS 229
Not all problem domain concepts are suitable language concepts. Concepts that
every feature, application, or product always has should not normally be part of the
language. Why would we want to model something that is always the same? Instead
they should be provided via components and code libraries or produced by the
generator. In modeling languages, only those concepts that allow describing variation
should be considered. Perhaps it is easiest to consider variation as a property of the
language element. For example, buttons in a digital wristwatch (Chapter 9) need to be
differentiated and thus the button concept has a property to specify its name.Variation
can also be expressed by connecting language elements with each other. For instance,
in the watch case an action does not have any properties of its own, but the action
modeling concept is needed to specify how time variables are modi?¬?ed, alarms used,
and icons shown and hidden.
Pages:
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415