1 files changed, 243 insertions, 0 deletions
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt
new file mode 100644
index 0000000..8f8bead
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt
@@ -0,0 +1,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.