For instance,
sending text messages requires that we use a SendSMS operation (see Fig. 1.3) and
give it the right parameters: a mandatory phone number followed by a message
header and message contents.
FIGURE 1.3 Class structure of the application
AN EXAMPLE: MODELING WITH A GENERAL-PURPOSE LANGUAGE 9
After ?¬?nishing the class diagram, we could generate skeleton code and continue
writing the code details, the largest part, manually. Alternatively, we could continue
modeling and create other kinds of designs that cover those parts the class diagram
did not specify. Perhaps even in parallel to static structures, we would also specify
what the application does. Here we would start to think about the application
behavior, such as menu actions, accessing the web, user navigation, and canceling
during the actions.
Modeling Application Behavior In the UML world, we could apply state
machines, collaboration diagrams, or perhaps sequence diagrams to address
application behavior. With a sequence diagram, our designs could look something
like Fig. 1.4.
When specifying the interaction between the objects, we would need to know in
more detail the functionality offered by the device, the APIs to use, what they
return, the expected programming model to be followed, and architectural rules to
be obeyed. We simply can??™t draw the sequence diagram without knowing what the
phone can do! So for many of the details in a design model, we must ?¬?rst consult
libraries and APIs.
Pages:
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41