The common way to use UML for
modeling starts with de?¬?ning the use cases, as illustrated in Fig. 1.2. For each
identi?¬?ed use case, we would specify in more detail its functionality, such as
actions, pre- and postconditions, expected result, and possible exceptions. We
would most likely describe these use cases in text rather than in the diagram. After
having speci?¬?ed the use cases, we could review them with a customer through a
generated requirements document or, if the customer can understand the language,
at least partly with the diagram.
Although use cases raise the level of abstraction away from the programming
code, they do not enable automation via code generation. Use case models and their
implementation stay separate. Having identi?¬?ed what the customer is looking for,
we would move to the next phase of modeling: De?¬?ne a static structure of the
application with class diagrams, or alternatively start to specify the behavior using
sequence diagrams or state diagrams. A class diagram in Fig. 1.3 shows the
structure of the application: some of the classes and their relationships.
While creating the class diagram, we would start to consider the application
domain: what widgets are available and how they should be used, where to place
FIGURE 1.2 Use cases of the conference application
8 INTRODUCTION
menus, what is required to send text messages, and so forth.
Pages:
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39