From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- .../28 - Use Case Example - lang_en_vs5.srt | 243 +++++++++++++++++++++ 1 file changed, 243 insertions(+) create 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 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. -- cgit 1.4.1