Unfortunately, sequence diagrams would not be enough for specifying the
application behavior as they don??™t adequately capture details like alternative choices
or decisions. We can apply other behavioral modeling languages, like activity
diagrams or state diagrams, to specify these. Figure 1.5 illustrates an activity diagram
that shows howthe application handles conference unregistration. This model is partly
related to the code, for example, through services it calls, but not adequately so that it
could be used for code generation.We could naturally ?¬?ll more implementation details
into the activity diagram and start using the activity modeling language as a
programming language, but most developers switch to a programming language to
make it more concise.
If we were to continue our example, the activity diagrams could be made to
specify other functions as well, but to save space we have omitted them. We should
also note that there is no explicit phase or time to stop the modeling effort. How can
we know when the application is fully designed without any guidance as to what
constitutes a full design? If we had UML fever (see Bell, 2004), we could continue
the modeling effort and create further models. There are still nine other kinds of
modeling languages. Should we use them and stop modeling here or should we have
stopped earlier? Since development is usually iterative in this model creation
process, we most likely would also update the previously made class diagrams,
sequence diagrams, activity diagrams, etc.
Pages:
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42