1 00:00:00,005 --> 00:00:02,005 - [Instructor] We had this product backlog 2 00:00:02,005 --> 00:00:03,005 when we started, 3 00:00:03,005 --> 00:00:06,000 out of which we delivered top three requirements 4 00:00:06,000 --> 00:00:08,000 in previous print. 5 00:00:08,000 --> 00:00:11,001 Now, we move to next set of requirements 6 00:00:11,001 --> 00:00:14,006 in which we need to cater to our registered users. 7 00:00:14,006 --> 00:00:17,003 They need to have their user accounts created 8 00:00:17,003 --> 00:00:19,005 so that they can start recording their meals 9 00:00:19,005 --> 00:00:22,007 and viewing their diet logs. 10 00:00:22,007 --> 00:00:26,001 Since the functionality of creating user accounts 11 00:00:26,001 --> 00:00:29,004 is based on having the customer actually register themselves 12 00:00:29,004 --> 00:00:32,007 with diet consulting services at H+ Sport 13 00:00:32,007 --> 00:00:36,004 and doing all the paperwork and making the payments, 14 00:00:36,004 --> 00:00:37,009 we will take some shortcuts 15 00:00:37,009 --> 00:00:39,007 to simplify the requirements 16 00:00:39,007 --> 00:00:41,003 for our case study. 17 00:00:41,003 --> 00:00:43,001 Let us assume that for now, 18 00:00:43,001 --> 00:00:44,006 the user accounts are created 19 00:00:44,006 --> 00:00:48,006 at the backend by IT admin directly in the database. 20 00:00:48,006 --> 00:00:50,008 So customers register themselves 21 00:00:50,008 --> 00:00:52,008 with diet consulting services. 22 00:00:52,008 --> 00:00:55,004 They are given a user name and password, 23 00:00:55,004 --> 00:00:59,000 which they use to access other functionalities. 24 00:00:59,000 --> 00:01:01,003 If we see the use case diagram view, 25 00:01:01,003 --> 00:01:03,009 we can see that all use cases, 26 00:01:03,009 --> 00:01:05,009 other than search and compare, 27 00:01:05,009 --> 00:01:08,006 require the user to log in. 28 00:01:08,006 --> 00:01:11,003 So we need to implement the login functionality 29 00:01:11,003 --> 00:01:13,009 for all use cases going forward. 30 00:01:13,009 --> 00:01:15,008 It is an included use case 31 00:01:15,008 --> 00:01:19,004 as is shown by include arrows in the diagram. 32 00:01:19,004 --> 00:01:20,009 Let us write user stories 33 00:01:20,009 --> 00:01:22,009 for the other two requirements. 34 00:01:22,009 --> 00:01:26,001 Record a meal and view diet log. 35 00:01:26,001 --> 00:01:28,005 First, user story for recording meals 36 00:01:28,005 --> 00:01:31,009 can be written as a registered user, 37 00:01:31,009 --> 00:01:33,006 I want to record my meals 38 00:01:33,006 --> 00:01:37,003 so that I can maintain my daily diet log. 39 00:01:37,003 --> 00:01:40,007 While this user story seems complete in itself, 40 00:01:40,007 --> 00:01:43,000 it doesn't say how will the user know 41 00:01:43,000 --> 00:01:45,006 if the meal has been recorded. 42 00:01:45,006 --> 00:01:48,009 And so, the next requirement of viewing diet log 43 00:01:48,009 --> 00:01:51,001 becomes closely related to this, 44 00:01:51,001 --> 00:01:53,006 which is as a registered user, 45 00:01:53,006 --> 00:01:55,005 I want to view my diet log 46 00:01:55,005 --> 00:01:58,002 so that I can keep track of what I'm eating. 47 00:01:58,002 --> 00:01:59,009 Each of these two user stories 48 00:01:59,009 --> 00:02:03,003 can also be written as use case specifications. 49 00:02:03,003 --> 00:02:06,006 This time, the actor is a registered user, 50 00:02:06,006 --> 00:02:10,000 and the precondition is that the registered user 51 00:02:10,000 --> 00:02:11,003 should be logged in. 52 00:02:11,003 --> 00:02:13,006 In basic flow, as usual, 53 00:02:13,006 --> 00:02:15,009 the registered user chooses the option 54 00:02:15,009 --> 00:02:17,007 to record a meal. 55 00:02:17,007 --> 00:02:21,002 Red30 offers options to enter meal date, 56 00:02:21,002 --> 00:02:22,009 time and meal type. 57 00:02:22,009 --> 00:02:25,005 We know the possible values for date and time 58 00:02:25,005 --> 00:02:27,001 but what is a meal type? 59 00:02:27,001 --> 00:02:29,000 Well, we want to track breakfast, 60 00:02:29,000 --> 00:02:32,004 lunch, dinner and any other snacking separately. 61 00:02:32,004 --> 00:02:34,009 Once the user provides these inputs, 62 00:02:34,009 --> 00:02:37,001 Red30 asks user to start putting in 63 00:02:37,001 --> 00:02:39,000 what they ate in the meal. 64 00:02:39,000 --> 00:02:42,000 This means selecting different products 65 00:02:42,000 --> 00:02:43,005 and their quantities. 66 00:02:43,005 --> 00:02:47,007 For example, one cup of soup and 1/2 sandwich. 67 00:02:47,007 --> 00:02:49,004 So this tells us that a meal 68 00:02:49,004 --> 00:02:50,008 has several products, 69 00:02:50,008 --> 00:02:53,002 which we will call as servings. 70 00:02:53,002 --> 00:02:56,001 The user continues to add different servings 71 00:02:56,001 --> 00:02:58,005 as needed and then saves the meal. 72 00:02:58,005 --> 00:03:01,007 Similarly, in the view diet log use case, 73 00:03:01,007 --> 00:03:04,007 the actor is a registered user 74 00:03:04,007 --> 00:03:05,009 and the precondition 75 00:03:05,009 --> 00:03:09,002 is that the registered user should be logged in. 76 00:03:09,002 --> 00:03:10,005 In basic flow, 77 00:03:10,005 --> 00:03:12,001 the user chooses the option 78 00:03:12,001 --> 00:03:15,004 to view diet log and Red30 displays a list 79 00:03:15,004 --> 00:03:19,009 of all meals logged so far starting with most recent 80 00:03:19,009 --> 00:03:21,001 at the top. 81 00:03:21,001 --> 00:03:23,001 Now, we have one critical part 82 00:03:23,001 --> 00:03:26,000 of these two use cases left to specify, 83 00:03:26,000 --> 00:03:29,001 and that is the login functionality. 84 00:03:29,001 --> 00:03:31,002 In itself, it is not a use case. 85 00:03:31,002 --> 00:03:32,009 But because this functionality 86 00:03:32,009 --> 00:03:34,009 is common to all other use cases 87 00:03:34,009 --> 00:03:36,004 for registered users, 88 00:03:36,004 --> 00:03:40,001 we have pulled it out as an included use case. 89 00:03:40,001 --> 00:03:41,002 As a user story, 90 00:03:41,002 --> 00:03:44,003 we can state it as a registered user, 91 00:03:44,003 --> 00:03:47,006 I want to log in to Red30 system 92 00:03:47,006 --> 00:03:50,007 so that I can use special features in the system 93 00:03:50,007 --> 00:03:52,003 for registered users. 94 00:03:52,003 --> 00:03:55,006 This means as soon as registered users log in, 95 00:03:55,006 --> 00:03:58,006 they should be able to see some special features. 96 00:03:58,006 --> 00:04:00,006 As use case specification, 97 00:04:00,006 --> 00:04:03,008 the registered user, as a primary actor, 98 00:04:03,008 --> 00:04:07,004 should have access to Red30 application on the web. 99 00:04:07,004 --> 00:04:11,007 In basic flow, the user chooses the login option. 100 00:04:11,007 --> 00:04:15,007 Red30 asks user to enter username and password, 101 00:04:15,007 --> 00:04:17,002 and if they're correct, 102 00:04:17,002 --> 00:04:19,008 Red30 displays special functionalities 103 00:04:19,008 --> 00:04:21,008 for registered users. 104 00:04:21,008 --> 00:04:24,007 If the username or password are incorrect, 105 00:04:24,007 --> 00:04:28,002 then Red30 should ask user to try again. 106 00:04:28,002 --> 00:04:30,004 Now we have written out these use cases, 107 00:04:30,004 --> 00:04:33,009 let's analyze them to move towards some design. 108 00:04:33,009 --> 00:04:37,003 If we look at our record meal use case specification, 109 00:04:37,003 --> 00:04:39,004 we can identity some nouns, 110 00:04:39,004 --> 00:04:42,006 such as registered user, and meal. 111 00:04:42,006 --> 00:04:46,009 Meal has attributes, date, time and meal type. 112 00:04:46,009 --> 00:04:51,000 This gives us our first domain class, meal. 113 00:04:51,000 --> 00:04:54,001 Then, continuing further in the use case, 114 00:04:54,001 --> 00:04:55,007 we find another one. 115 00:04:55,007 --> 00:04:56,008 Serving. 116 00:04:56,008 --> 00:04:58,007 We can infer from the text 117 00:04:58,007 --> 00:05:01,001 that it is a serving of food product 118 00:05:01,001 --> 00:05:03,002 with a certain quantity. 119 00:05:03,002 --> 00:05:06,003 So here is another class called serving. 120 00:05:06,003 --> 00:05:09,004 Notice that serving is added to meal. 121 00:05:09,004 --> 00:05:11,008 So there is a composition relationship 122 00:05:11,008 --> 00:05:13,008 between meal and serving. 123 00:05:13,008 --> 00:05:16,006 If there is no meal, there is no serving 124 00:05:16,006 --> 00:05:19,009 and one serving belongs only to one meal. 125 00:05:19,009 --> 00:05:22,004 Continuing with our login use case, 126 00:05:22,004 --> 00:05:25,005 we see registered user again 127 00:05:25,005 --> 00:05:28,006 that has username and password. 128 00:05:28,006 --> 00:05:32,000 So that gives another class, user. 129 00:05:32,000 --> 00:05:35,006 At present, we are naming it just as a user. 130 00:05:35,006 --> 00:05:39,000 And we also see an association between meal 131 00:05:39,000 --> 00:05:42,002 and user because user records the meal. 132 00:05:42,002 --> 00:05:44,006 At this point, there are several possibilities. 133 00:05:44,006 --> 00:05:48,000 We can create a list of meals in user class 134 00:05:48,000 --> 00:05:50,007 or put username in the meal. 135 00:05:50,007 --> 00:05:52,004 I chose to do the latter. 136 00:05:52,004 --> 00:05:54,003 So this analysis tells us 137 00:05:54,003 --> 00:05:58,002 that we need to add three more classes into our system 138 00:05:58,002 --> 00:05:59,008 and we can also see 139 00:05:59,008 --> 00:06:02,001 that we will need to create all three of them 140 00:06:02,001 --> 00:06:05,000 as tables in our database as well.