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
|
1
00:00:00,100 --> 00:00:02,510
As I mentioned when we started talking about use cases, use
2
00:00:02,510 --> 00:00:06,040
cases are fundamental in UML, and in general. So, now I
3
00:00:06,040 --> 00:00:08,510
would like to discuss why they're so important and what are
4
00:00:08,510 --> 00:00:11,900
the different roles that use cases can play. The first obvious one
5
00:00:11,900 --> 00:00:15,510
is for requirements elicitation. It is much easier to describe what
6
00:00:15,510 --> 00:00:17,650
the system should do if we think about the system in
7
00:00:17,650 --> 00:00:21,070
terms of scenarios of usage. Rather than trying to describe the
8
00:00:21,070 --> 00:00:25,450
whole functionality of the system at once. So, use cases can help
9
00:00:25,450 --> 00:00:28,890
performing a more effective requirement solicitation. As we will
10
00:00:28,890 --> 00:00:31,700
see when we discuss the unified software process, they can
11
00:00:31,700 --> 00:00:34,980
be used for architectural analysis. So, use cases are the
12
00:00:34,980 --> 00:00:38,165
starting point for the analysis of the architecture of the
13
00:00:38,165 --> 00:00:40,765
system that can help identify the main blocks of
14
00:00:40,765 --> 00:00:44,016
the system. And therefore, can help define in the initial
15
00:00:44,016 --> 00:00:47,360
architecture. And as I said, we'll talk more extensively about
16
00:00:47,360 --> 00:00:50,460
that. They can be used for user prioritization. For example,
17
00:00:50,460 --> 00:00:53,230
imagine to have multiple actors in the system, and you
18
00:00:53,230 --> 00:00:56,160
might want to prioritize some of them. For instance, using
19
00:00:56,160 --> 00:00:59,810
again the banking system example, we might want to first
20
00:00:59,810 --> 00:01:03,477
provide functionality for the administrators of the bank. And only
21
00:01:03,477 --> 00:01:06,384
in a second time provide functionality for the customers, because
22
00:01:06,384 --> 00:01:09,342
of course, if the administrator cannot perform any operation, the
23
00:01:09,342 --> 00:01:12,030
customers cannot use the system. So again, they can be
24
00:01:12,030 --> 00:01:15,980
used to prioritize the users. Or the actors, and therefore
25
00:01:15,980 --> 00:01:19,390
define which part of the system should be built in which order.
26
00:01:19,390 --> 00:01:22,120
Related to this point, they can be used for planning. If I
27
00:01:22,120 --> 00:01:25,000
know which pieces of functionality I need to build and in which
28
00:01:25,000 --> 00:01:27,980
order, I can better plan the development of my system. And again,
29
00:01:27,980 --> 00:01:31,280
we will see how this becomes very important in many different software
30
00:01:31,280 --> 00:01:35,037
life cycles. So, both in the unified software process, for instance, but
31
00:01:35,037 --> 00:01:38,570
also in more agile development processes. And finally, use cases can be
32
00:01:38,570 --> 00:01:40,980
used for testing. If I have an early description of what the
33
00:01:40,980 --> 00:01:44,290
system should do, what are the main pieces of functionality of the system. And I
34
00:01:44,290 --> 00:01:46,700
know how the interaction between the actors and
35
00:01:46,700 --> 00:01:49,510
the system is, I can easily define test
36
00:01:49,510 --> 00:01:52,010
cases, even before writing the code, even before
37
00:01:52,010 --> 00:01:54,180
defining my system. And when we discuss testing,
38
00:01:54,180 --> 00:01:57,590
we will get back to this and talk a little more extensively about this, as well.
|
