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.