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.