In other words, the language de?¬?ner should
focus more on the problem domain than its code (the solution domain in Jackson,
1995). Naturally, while aspiring toward a higher level of abstraction, we need to keep
in mind that ultimately we need to have the ability to generate code from models too.
Starting from domain concepts is always better, though: adding coding concepts later
on is usually easier than vice versa.
Problem domain concepts also have other characteristics that make them good
candidates for the language:
. They are usually already known and used. They can be found while
communicating with customers but also among development teams. It is not
necessary for the languages to introduce new concepts: they can build on
existing ones when possible. Using concepts that are already in use is also
relevant for the acceptance of DSM. People are comfortable with the concepts,
and they don??™t need to invest in learning new languages. In addition to concepts,
it is often a good approach to base the notation of the language on problem
domain symbols already in use (see Section 10.6).
. Problem domain concepts usually have established semantics in place. The
language de?¬?ner can then base the language on existing de?¬?nitions and, if they
are not fully available, can ask domain experts. For example, in the domain of
mobile User Interface (UI) applications, developers know the concept of the
soft key: two or more keys whose functions change based on the application
context.
Pages:
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414