Concepts that can be identi?¬?ed from the combination of existing concepts should
also usually be excluded. For example, in the mobile phone case (Chapter 8), there is
no explicit button concept that the user presses to indicate navigation paths in the
application. Unlike in the watch example, where the number of buttons and their
labels can vary, in the mobile phone case they are implicitly presented with the
different navigation relationships: one for default selection, one for cancelling, and
one for accessing menus. As alternative navigation paths need to be speci?¬?ed anyway,
a special button concept in the language would be unnecessary. Keeping the language
smaller is better, as then it becomes easier to learn and use.
Sources for Modeling Concepts Identi?¬?cation of the relevant concepts in the
language is largely dependent on creative insights and experience in the domain. It
helps if one has been involved in making similar kinds of applications in the past.
Whenever possible, you should consult people more experienced in the domain, such
as problem domain experts, architects, and lead developers. Their insights and
opinions are often the main source for creating the DSM solution. You can interview
them, observe their work routines, and use other mechanisms that reveal problem
domain characteristics.
Pages:
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416