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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
1
00:00:00,080 --> 00:00:02,120
Now if you want to build a use case diagram for
2
00:00:02,120 --> 00:00:04,520
our example, we have to add the use cases for
3
00:00:04,520 --> 00:00:07,710
these different actors. For instance, if we consider the student
4
00:00:07,710 --> 00:00:10,810
and the registrar, they might be both interacting with the maintain
5
00:00:10,810 --> 00:00:14,950
schedule system, the registrar by updating the schedule and the
6
00:00:14,950 --> 00:00:18,125
students by using the schedule that has been updated by the
7
00:00:18,125 --> 00:00:20,860
registrar. As you can see, different roles for the same
8
00:00:20,860 --> 00:00:24,962
use case. Another possible use case is the request course roster.
9
00:00:24,962 --> 00:00:28,520
And on this case, the professor will request the roster
10
00:00:28,520 --> 00:00:31,960
by interacting with the system. We will continue in this way
11
00:00:31,960 --> 00:00:35,270
by further refining and by further adding use cases as we
12
00:00:35,270 --> 00:00:39,240
identify possible interactions of the actors that we identified with our
13
00:00:39,240 --> 00:00:42,380
system. So in summary, what the use case diagram is doing
14
00:00:42,380 --> 00:00:45,370
is to show the actors and their interaction with the system
15
00:00:45,370 --> 00:00:47,680
through a set of use cases. At this point, it should
16
00:00:47,680 --> 00:00:49,990
be pretty clear that sure, this gives us an idea of
17
00:00:49,990 --> 00:00:53,630
the interactions but we don't really know how these interactions occur.
18
00:00:53,630 --> 00:00:55,870
So there is one piece that is missing, which is how
19
00:00:55,870 --> 00:00:58,850
do we document the use cases, how do we describe what
20
00:00:58,850 --> 00:01:02,010
happens and what these interactions actually are. And that's exactly what
21
00:01:02,010 --> 00:01:05,410
we're going to discuss now, how to document use cases. So the
22
00:01:05,410 --> 00:01:09,000
behavior of a use case can be specified by describing its
23
00:01:09,000 --> 00:01:11,650
flow of events. And it is important to note that the
24
00:01:11,650 --> 00:01:15,190
flow of events should be described from an actor's point of view,
25
00:01:15,190 --> 00:01:17,690
so from the point of view of the external entity that
26
00:01:17,690 --> 00:01:22,070
is interacting with my system. So the description should detail what
27
00:01:22,070 --> 00:01:24,480
the system must provide to the actor when the use case
28
00:01:24,480 --> 00:01:28,170
is executed. In particular, it should describe how the use case
29
00:01:28,170 --> 00:01:31,670
starts and ends. It should describe the normal flow of events,
30
00:01:31,670 --> 00:01:34,280
what is the normal interaction. And in addition to the normal
31
00:01:34,280 --> 00:01:37,720
flow of events, it should also describe possibly alternative flows of
32
00:01:37,720 --> 00:01:40,240
events. For example, in the case in which there are multiple
33
00:01:40,240 --> 00:01:44,450
ways of accomplishing one action or performing a task. And finally,
34
00:01:44,450 --> 00:01:47,880
it should also describe exceptional flow of events. For example, assume that
35
00:01:47,880 --> 00:01:50,910
you are describing a use case for withdrawing money from an
36
00:01:50,910 --> 00:01:54,230
ATM. You may want to describe the normal flow of events in which
37
00:01:54,230 --> 00:01:56,590
I insert my card, I provide my pin and so on.
38
00:01:56,590 --> 00:01:59,750
An alternative one in which, in addition to withdrawing cash, maybe I'll
39
00:01:59,750 --> 00:02:02,550
also first ask for some information about how much money is
40
00:02:02,550 --> 00:02:05,390
in my account. And finally, I may want to also describe an exceptional
41
00:02:05,390 --> 00:02:07,900
flow of events in which I get my pin wrong and,
42
00:02:07,900 --> 00:02:11,140
therefore, I'm not able to perform the operation. One more thing I
43
00:02:11,140 --> 00:02:14,140
want to mention, when we talk about documenting use cases, is
44
00:02:14,140 --> 00:02:17,770
the fact that the description of this information can be provided in
45
00:02:17,770 --> 00:02:20,650
two main ways, in an informal way or in a formal
46
00:02:20,650 --> 00:02:23,330
way. In the case of an informal description, we could just have
47
00:02:23,330 --> 00:02:27,540
a textual description of the flow of events in natural language.
48
00:02:27,540 --> 00:02:30,250
In the case of a formal or structured description, we may use,
49
00:02:30,250 --> 00:02:32,610
for example, pre and post conditions, pseudo
50
00:02:32,610 --> 00:02:34,680
code to indicate the steps. We could
51
00:02:34,680 --> 00:02:38,010
also use the sequence diagrams, which is something that we will see in a minute.
|
