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 --- ...- Building a Use Case Diagram - lang_en_vs5.srt | 203 +++++++++++++++++++++ 1 file changed, 203 insertions(+) create mode 100644 usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt (limited to 'usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt') diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt new file mode 100644 index 0000000..4c62396 --- /dev/null +++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt @@ -0,0 +1,203 @@ +1 +00:00:00,080 --> 00:00:02,120 +Now if you want to build a use case diagram for + +2 +00:00:02,120 --> 00:00:04,520 +our example, we have to add the use cases for + +3 +00:00:04,520 --> 00:00:07,710 +these different actors. For instance, if we consider the student + +4 +00:00:07,710 --> 00:00:10,810 +and the registrar, they might be both interacting with the maintain + +5 +00:00:10,810 --> 00:00:14,950 +schedule system, the registrar by updating the schedule and the + +6 +00:00:14,950 --> 00:00:18,125 +students by using the schedule that has been updated by the + +7 +00:00:18,125 --> 00:00:20,860 +registrar. As you can see, different roles for the same + +8 +00:00:20,860 --> 00:00:24,962 +use case. Another possible use case is the request course roster. + +9 +00:00:24,962 --> 00:00:28,520 +And on this case, the professor will request the roster + +10 +00:00:28,520 --> 00:00:31,960 +by interacting with the system. We will continue in this way + +11 +00:00:31,960 --> 00:00:35,270 +by further refining and by further adding use cases as we + +12 +00:00:35,270 --> 00:00:39,240 +identify possible interactions of the actors that we identified with our + +13 +00:00:39,240 --> 00:00:42,380 +system. So in summary, what the use case diagram is doing + +14 +00:00:42,380 --> 00:00:45,370 +is to show the actors and their interaction with the system + +15 +00:00:45,370 --> 00:00:47,680 +through a set of use cases. At this point, it should + +16 +00:00:47,680 --> 00:00:49,990 +be pretty clear that sure, this gives us an idea of + +17 +00:00:49,990 --> 00:00:53,630 +the interactions but we don't really know how these interactions occur. + +18 +00:00:53,630 --> 00:00:55,870 +So there is one piece that is missing, which is how + +19 +00:00:55,870 --> 00:00:58,850 +do we document the use cases, how do we describe what + +20 +00:00:58,850 --> 00:01:02,010 +happens and what these interactions actually are. And that's exactly what + +21 +00:01:02,010 --> 00:01:05,410 +we're going to discuss now, how to document use cases. So the + +22 +00:01:05,410 --> 00:01:09,000 +behavior of a use case can be specified by describing its + +23 +00:01:09,000 --> 00:01:11,650 +flow of events. And it is important to note that the + +24 +00:01:11,650 --> 00:01:15,190 +flow of events should be described from an actor's point of view, + +25 +00:01:15,190 --> 00:01:17,690 +so from the point of view of the external entity that + +26 +00:01:17,690 --> 00:01:22,070 +is interacting with my system. So the description should detail what + +27 +00:01:22,070 --> 00:01:24,480 +the system must provide to the actor when the use case + +28 +00:01:24,480 --> 00:01:28,170 +is executed. In particular, it should describe how the use case + +29 +00:01:28,170 --> 00:01:31,670 +starts and ends. It should describe the normal flow of events, + +30 +00:01:31,670 --> 00:01:34,280 +what is the normal interaction. And in addition to the normal + +31 +00:01:34,280 --> 00:01:37,720 +flow of events, it should also describe possibly alternative flows of + +32 +00:01:37,720 --> 00:01:40,240 +events. For example, in the case in which there are multiple + +33 +00:01:40,240 --> 00:01:44,450 +ways of accomplishing one action or performing a task. And finally, + +34 +00:01:44,450 --> 00:01:47,880 +it should also describe exceptional flow of events. For example, assume that + +35 +00:01:47,880 --> 00:01:50,910 +you are describing a use case for withdrawing money from an + +36 +00:01:50,910 --> 00:01:54,230 +ATM. You may want to describe the normal flow of events in which + +37 +00:01:54,230 --> 00:01:56,590 +I insert my card, I provide my pin and so on. + +38 +00:01:56,590 --> 00:01:59,750 +An alternative one in which, in addition to withdrawing cash, maybe I'll + +39 +00:01:59,750 --> 00:02:02,550 +also first ask for some information about how much money is + +40 +00:02:02,550 --> 00:02:05,390 +in my account. And finally, I may want to also describe an exceptional + +41 +00:02:05,390 --> 00:02:07,900 +flow of events in which I get my pin wrong and, + +42 +00:02:07,900 --> 00:02:11,140 +therefore, I'm not able to perform the operation. One more thing I + +43 +00:02:11,140 --> 00:02:14,140 +want to mention, when we talk about documenting use cases, is + +44 +00:02:14,140 --> 00:02:17,770 +the fact that the description of this information can be provided in + +45 +00:02:17,770 --> 00:02:20,650 +two main ways, in an informal way or in a formal + +46 +00:02:20,650 --> 00:02:23,330 +way. In the case of an informal description, we could just have + +47 +00:02:23,330 --> 00:02:27,540 +a textual description of the flow of events in natural language. + +48 +00:02:27,540 --> 00:02:30,250 +In the case of a formal or structured description, we may use, + +49 +00:02:30,250 --> 00:02:32,610 +for example, pre and post conditions, pseudo + +50 +00:02:32,610 --> 00:02:34,680 +code to indicate the steps. We could + +51 +00:02:34,680 --> 00:02:38,010 +also use the sequence diagrams, which is something that we will see in a minute. -- cgit 1.4.1