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