1 files changed, 127 insertions, 0 deletions
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt
new file mode 100644
index 0000000..ccf7d0e
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt
@@ -0,0 +1,127 @@
+1
+00:00:00,080 --> 00:00:02,190
+Now, as we did for the class diagram, let's look at
+
+2
+00:00:02,190 --> 00:00:05,440
+some creation tips for use case diagrams. The first tip is that
+
+3
+00:00:05,440 --> 00:00:09,050
+when you define a use case, use a name that communicates purpose.
+
+4
+00:00:09,050 --> 00:00:12,080
+It should be clear what the use case refers to by just
+
+5
+00:00:12,080 --> 00:00:14,320
+looking at the name of the use case. Second tip is
+
+6
+00:00:14,320 --> 00:00:17,700
+to define one atomic behavior per use case. So try not to
+
+7
+00:00:17,700 --> 00:00:21,900
+put more than one specific scenario into a use case. Why? Because
+
+8
+00:00:21,900 --> 00:00:25,380
+these will make the use cases easier to understand and better suited
+
+9
+00:00:25,380 --> 00:00:28,940
+for their roles that we just discussed to define test cases,
+
+10
+00:00:28,940 --> 00:00:31,370
+to do planning, to define an architecture and so on and
+
+11
+00:00:31,370 --> 00:00:34,790
+so forth. Define the flow of events clearly. So again, do
+
+12
+00:00:34,790 --> 00:00:37,820
+it from the perspective of an outsider. An outsider should be able
+
+13
+00:00:37,820 --> 00:00:40,390
+to read the description of the flow of events and understand
+
+14
+00:00:40,390 --> 00:00:43,770
+exactly how the system works or how that specific piece of
+
+15
+00:00:43,770 --> 00:00:47,572
+functionality works. As we suggested for the class diagram, provide only
+
+16
+00:00:47,572 --> 00:00:50,450
+essential details. So there is no need to provide all the nitty
+
+17
+00:00:50,450 --> 00:00:53,720
+gritty details about the use case, just provide enough details so
+
+18
+00:00:53,720 --> 00:00:57,540
+that the use case is complete and understandable. And finally, even
+
+19
+00:00:57,540 --> 00:00:59,960
+though we didn't cover that, there is a way to factor
+
+20
+00:00:59,960 --> 00:01:03,890
+common behaviors and factor variants when defining use cases. So I will
+
+21
+00:01:03,890 --> 00:01:06,580
+encourage you to look at how to do that. For example,
+
+22
+00:01:06,580 --> 00:01:09,290
+by looking at the additional UML documentation and to try to
+
+23
+00:01:09,290 --> 00:01:12,875
+factor out this common behaviors and variants. Typical example would be
+
+24
+00:01:12,875 --> 00:01:15,550
+a system that requires login, like the one that we just discussed,
+
+25
+00:01:15,550 --> 00:01:18,350
+will probably require an initial login step for each use
+
+26
+00:01:18,350 --> 00:01:22,080
+case. It is possible that instead of describing the same steps,
+
+27
+00:01:22,080 --> 00:01:24,600
+or same sub-steps, for each use case, you can factor
+
+28
+00:01:24,600 --> 00:01:26,740
+that out. And create a use case that you should then
+
+29
+00:01:26,740 --> 00:01:29,180
+include in your own use cases. As I said, we
+
+30
+00:01:29,180 --> 00:01:32,790
+didn't cover this for simplicity, but feel free to further read
+
+31
+00:01:32,790 --> 00:01:35,450
+about UML and to see how you can actually factor out
+
+32
+00:01:35,450 --> 00:01:38,890
+behaviors and factor variants. Which can be very useful in practice.