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
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
1
00:00:00,140 --> 00:00:02,310
So, as we did for the previous cases, now let's look
2
00:00:02,310 --> 00:00:06,890
at an example. Let's consider a specific use case, maintain curriculum, in
3
00:00:06,890 --> 00:00:10,570
which we have the registrar that interacts with the system to do
4
00:00:10,570 --> 00:00:14,320
operations for maintaining the curriculum. And, let's define the flow of events
5
00:00:14,320 --> 00:00:17,040
for this use case. To do this, we're going to go back, as
6
00:00:17,040 --> 00:00:20,380
usual, to the description of our system. So this is the one
7
00:00:20,380 --> 00:00:22,670
that you already saw several times, but I would like for you
8
00:00:22,670 --> 00:00:25,080
to do something. I would like for you to stop the video,
9
00:00:25,080 --> 00:00:27,890
look back at the spec, the one that is shown here.
10
00:00:27,890 --> 00:00:30,850
And write on your own, what you think is the informal flow
11
00:00:30,850 --> 00:00:35,060
of events that categorizes the interaction of the registration manager with
12
00:00:35,060 --> 00:00:37,500
the system. And it is very important that you keep in mind
13
00:00:37,500 --> 00:00:40,140
something as you're doing that. You should keep in mind that,
14
00:00:40,140 --> 00:00:41,940
as it always happens, when extracting
15
00:00:41,940 --> 00:00:44,270
requirements from an initial specification, in
16
00:00:44,270 --> 00:00:47,570
particular an informal one like this one, a high-level one, you
17
00:00:47,570 --> 00:00:50,130
will have to be able to read between the lines and fill
18
00:00:50,130 --> 00:00:52,690
in the blanks. That is, you have to provide the information
19
00:00:52,690 --> 00:00:55,770
for the missing parts using your domain knowledge. So try to
20
00:00:55,770 --> 00:00:58,820
do that exercise. Read the description, and see how you will
21
00:00:58,820 --> 00:01:02,470
define the steps, the flow of events for the maintain curriculum use
22
00:01:02,470 --> 00:01:06,230
case. If you're done with that, now let's see the possible
23
00:01:06,230 --> 00:01:09,080
informal paragraph that describes that flow of events. And the one
24
00:01:09,080 --> 00:01:12,070
I'm providing now is just one possibility, based on my experience
25
00:01:12,070 --> 00:01:15,040
and based on the way I see this possible flow of events.
26
00:01:15,040 --> 00:01:17,950
So yours might look different, of course. In my case, because
27
00:01:17,950 --> 00:01:20,880
the description was measuring the fact that every user has got
28
00:01:20,880 --> 00:01:23,590
a log-in and a password. I decided that the first step
29
00:01:23,590 --> 00:01:27,120
should be that the registrar logs onto the system and enters his
30
00:01:27,120 --> 00:01:30,390
or her password. As it normally happens with password protected systems,
31
00:01:30,390 --> 00:01:32,660
if the password is valid, the registrar will get into the
32
00:01:32,660 --> 00:01:35,870
system. And the system at this point should ask to specify
33
00:01:35,870 --> 00:01:40,810
a semester for which the maintain curriculum activity has to be performed.
34
00:01:40,810 --> 00:01:44,290
The registrar will therefor enter the desired semester. The interface
35
00:01:44,290 --> 00:01:46,740
I envisioned is one in which the system will prompt
36
00:01:46,740 --> 00:01:50,690
the registrar to select the desired activity. Add, delete, review,
37
00:01:50,690 --> 00:01:53,560
or quit. And if the registrar selects add, the system
38
00:01:53,560 --> 00:01:56,060
will allow the registrar to add a course to the
39
00:01:56,060 --> 00:01:59,660
course list for the selected semester. Similarly, if the registrar
40
00:01:59,660 --> 00:02:02,550
selects delete, the system will let the registrar delete a
41
00:02:02,550 --> 00:02:05,840
course from the course list for the selected semester. And again
42
00:02:05,840 --> 00:02:08,660
similarly, if the registrar selects review, the system will
43
00:02:08,660 --> 00:02:12,030
simply display the course information in the course list for
44
00:02:12,030 --> 00:02:15,230
the selected semester. And finally, if the registrar selects quit,
45
00:02:15,230 --> 00:02:18,110
the system will simply exit and our use case will
46
00:02:18,110 --> 00:02:21,150
end. So, again, there's the main knowledge that goes into
47
00:02:21,150 --> 00:02:23,620
this. But this is a good example of how you
48
00:02:23,620 --> 00:02:27,960
can refine the initial description to identify these scenarios that
49
00:02:27,960 --> 00:02:30,830
then you will use to specify and implement your system.
50
00:02:30,830 --> 00:02:33,770
And as we discussed a few minutes ago, we provided the information
51
00:02:33,770 --> 00:02:37,420
that is requested for the use case, how the use case starts,
52
00:02:37,420 --> 00:02:40,620
by logging into the system. And how it ends, by selecting quit.
53
00:02:40,620 --> 00:02:43,294
We described the normal flow of events. And, of course, these flow
54
00:02:43,294 --> 00:02:46,580
of events could be improved, because right now even though we described
55
00:02:46,580 --> 00:02:50,020
how the use case starts and ends, we just described one possible
56
00:02:50,020 --> 00:02:53,340
flow of events. But there's many alternative ways we could provide and
57
00:02:53,340 --> 00:02:55,890
we do not describe any exception of flow of events. So this could
58
00:02:55,890 --> 00:02:58,540
be the starting point for multiple use cases, or
59
00:02:58,540 --> 00:03:02,092
for use cases just richer and contains more information, more
60
00:03:02,092 --> 00:03:04,474
steps to a richer flow. But you should have
61
00:03:04,474 --> 00:03:06,510
gotten the idea of what a use case should be.
|
