1
2
3
4
5
6
7
8
9
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
1
00:00:00,080 --> 00:00:02,190
Now, as we did for the class diagram, let's look at
2
00:00:02,190 --> 00:00:05,440
some creation tips for use case diagrams. The first tip is that
3
00:00:05,440 --> 00:00:09,050
when you define a use case, use a name that communicates purpose.
4
00:00:09,050 --> 00:00:12,080
It should be clear what the use case refers to by just
5
00:00:12,080 --> 00:00:14,320
looking at the name of the use case. Second tip is
6
00:00:14,320 --> 00:00:17,700
to define one atomic behavior per use case. So try not to
7
00:00:17,700 --> 00:00:21,900
put more than one specific scenario into a use case. Why? Because
8
00:00:21,900 --> 00:00:25,380
these will make the use cases easier to understand and better suited
9
00:00:25,380 --> 00:00:28,940
for their roles that we just discussed to define test cases,
10
00:00:28,940 --> 00:00:31,370
to do planning, to define an architecture and so on and
11
00:00:31,370 --> 00:00:34,790
so forth. Define the flow of events clearly. So again, do
12
00:00:34,790 --> 00:00:37,820
it from the perspective of an outsider. An outsider should be able
13
00:00:37,820 --> 00:00:40,390
to read the description of the flow of events and understand
14
00:00:40,390 --> 00:00:43,770
exactly how the system works or how that specific piece of
15
00:00:43,770 --> 00:00:47,572
functionality works. As we suggested for the class diagram, provide only
16
00:00:47,572 --> 00:00:50,450
essential details. So there is no need to provide all the nitty
17
00:00:50,450 --> 00:00:53,720
gritty details about the use case, just provide enough details so
18
00:00:53,720 --> 00:00:57,540
that the use case is complete and understandable. And finally, even
19
00:00:57,540 --> 00:00:59,960
though we didn't cover that, there is a way to factor
20
00:00:59,960 --> 00:01:03,890
common behaviors and factor variants when defining use cases. So I will
21
00:01:03,890 --> 00:01:06,580
encourage you to look at how to do that. For example,
22
00:01:06,580 --> 00:01:09,290
by looking at the additional UML documentation and to try to
23
00:01:09,290 --> 00:01:12,875
factor out this common behaviors and variants. Typical example would be
24
00:01:12,875 --> 00:01:15,550
a system that requires login, like the one that we just discussed,
25
00:01:15,550 --> 00:01:18,350
will probably require an initial login step for each use
26
00:01:18,350 --> 00:01:22,080
case. It is possible that instead of describing the same steps,
27
00:01:22,080 --> 00:01:24,600
or same sub-steps, for each use case, you can factor
28
00:01:24,600 --> 00:01:26,740
that out. And create a use case that you should then
29
00:01:26,740 --> 00:01:29,180
include in your own use cases. As I said, we
30
00:01:29,180 --> 00:01:32,790
didn't cover this for simplicity, but feel free to further read
31
00:01:32,790 --> 00:01:35,450
about UML and to see how you can actually factor out
32
00:01:35,450 --> 00:01:38,890
behaviors and factor variants. Which can be very useful in practice.
|
