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