This partial link is
represented with a dotted line in Fig. 1.1.
If we inspect the round-trip process in more detail, we can also see that mappings
between structural code and models are not without problems. For example, there
are no well-de?¬?ned mappings on how different relationship types used in class
diagrams, such as association, aggregation, and composition, are related to program
FIGURE 1.1 Aligning code and models
CODE-DRIVEN AND MODEL-DRIVEN DEVELOPMENT 5
code. Code does not explicitly specify these relationship types. One approach to
solve this problem is to use just a single source, usually the code, and show part of
it in the models. A classical example is to use only part of the expressive power of
class diagrams. That parts is, where the class diagram maps exactly to the class
code. This kind of alignment between code and models is often pure overhead.
Having a rectangle symbol to illustrate a class in a diagram and then an equivalent
textual presentation in a programming language hardly adds any value. There is
no raise in the level of abstraction and no information hiding, just an extra
representation duplicating the same information.
In model-driven development, we use models as the primary artifacts in the
development process: we have source models instead of source code. Throughout
this book, we argue that whenever possible this approach should be applied
because it raises the level of abstraction and hides complexity.
Pages:
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34