If we wouldn??™t do that our models
would not be consistent. This inconsistency might be ?¬?ne for sketching but not for
model-driven development.
Implementing the Application The example models described earlier are
clearly helpful for understanding and documenting the application. After all the modeling
work, we could expect to get more out of the created models too. Generate
code perhaps? Unfortunately a skeleton is the best we can generate here and then
10 INTRODUCTION
FIGURE 1.4 A view of the application behavior
11
continue by modifying the generated code to implement the functionality and
logic??”the largest part of the application. To get the ?¬?nished application, we would
implement it by writing the application code.
At this point, our models and code start to be separate. During the programming,
we will face aspects that were inadequately speci?¬?ed, false, or totally ignored while
modeling. It is also likely that our design models did not recognize the architectural
rules that the application must follow to execute. After all, UML models did not
know about the libraries, framework rules, and programming model for our mobile
applications. As the changes made to the code during implementation are no longer
in synch with the designs, we need to decide what to do with the models. Should we
take the time to update the models or ignore them and throw them away? Updating
the models requires manual work as the semantics of the code is different than
most of the concepts used in UML models.
Pages:
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43