From 8a7dfa0972c83fd811a4296e7373574bea4a28d0 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 19 Jul 2020 20:34:40 +0700 Subject: [usth/ICT2.7] Remove Udacity transcribes --- .../28 - Use Case Example - lang_en_vs5.srt | 243 --------------------- 1 file changed, 243 deletions(-) delete mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt (limited to 'usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt') 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. -- cgit 1.4.1