1 files changed, 203 insertions, 0 deletions
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.