diff options
Diffstat (limited to 'usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt')
| -rw-r--r-- | usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt | 203 |
1 files changed, 0 insertions, 203 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 deleted file mode 100644 index 4c62396..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt +++ /dev/null @@ -1,203 +0,0 @@ -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. |