3. Use cases.md

2. Use cases ============

User	First timer
Login	Sign up
Log out
Edit account
Delete account
Add friends
Add foes
Search for people
Show people in list
Show people in map
Delete friends
Delete foes
Plan route
Edit options

2.1 Definition of the user groups

Guest user

Guest user is a user that is either on the log in or sign up page. He or she may not have registered on the site or maybe just hasn’t logged in yet.

Registered user

When the user logs in, he or she becomes a registered user.

2.2 Use case diagrams

2.3. Use case scenarios

"User wants to login"

• Initial state:

  User is not logged in.

• Normal flow:

  1. User opens the application.
  2. User sees the page with the username and password form and the "Login" button.
  3. Then he/she enters the username and password and clicks "Login".
  4. The user is redirected to the start screen of the application and is now logged in.

• What can go wrong:

  The user mistypes the username or password.

• Other activities going on at the same time:

  Database checks the match with the username and password.

• End state:

  The user is logged in.

"User wants to log out"

• Initial state:

  User is logged in and on the main page.

• Normal flow:

  1. User sees the log out button and clicks it.
  2. The user is redirected to the log in page of the application and is now logged out.

• What can go wrong:

  No user errors exist for logging out.

• Other activities going on at the same time:

  Database logs the user out from the account.

• End state:

  The user is logged out.

"User wants to edit the account"

• Initial state:

  User is logged in and on the main page.

• Normal flow:

  1. User sees the settings button and clicks it.
  2. User is redirected to the settings page.
  3. User sees the "edit account" button and clicks it.
  4. User is redirected to edit account page.
  5. User sees the form with the account information.
  6. User changes the information she or he wants to be changed.
     (If the user wants to chance his or her password, he or she must type the current password and then the new password twice.)
  7. When the wanted changes are made, the user clicks the "save" button.
  8. User is redirected to main page.

• What can go wrong:

  The user mistypes the current password, or the passwords typed in "new password" and "repeat password" are not the same.

• Other activities going on at the same time:

  Database checks the match with the username and password. Database checks that "new password" and "repeat password" are the same. The old account information is deleted from the database and the new information added.

• End state:

  The new account information is saved.

"User wants to delete their account"

• Initial state:

  User is logged in and on the main page.

• Normal flow:

  1. User sees the settings button and clicks it.
  2. User is redirected to the settings page.
  3. User sees the button "delete account" and clicks it.
  4. A pop-up window with "Do you want to delete account?" -text appears with options "yes" and "no".
  5. The user clicks the "yes" option and is redirected to the log in page and the account is deleted.

• What can go wrong:

  No user errors exist for deleting accounts.

• Other activities going on at the same time:

  All the account information is deleted from the database.

• End state:

  The user is logged out and on the log in page. The account is deleted.

"User wants to add friends"

• Initial state:

  User is logged in and on the main page.

• Normal flow:

Option 1 (when the person wanted to add as a friend is online):

1. User sees the people list button and clicks it.
2. User is redirected to people list page.
3. User sees a list of people that are logged in right now.
4. User sees a person who he or she wants to have as a friend.
5. User clicks the light green dot next to that name.
6. The dot becomes bright green and the user is added as a friend.

Option 2 (when the person wanted to add as a friend is offline):

1. User sees the search button and clicks it.
2. User is redirected to search page.
3. User types the name or part of the name of the person he or she wants to have as a friend in the search field.
4. List of matches appear below.
5. User sees a person who he or she wants to have as a friend.
6. User clicks the light green dot next to that name.
7. The circle becomes bright green and the user is now his or her friend.

• What can go wrong:

  User might mistype the name and the person looked for is not shown on the list.

• Other activities going on at the same time:

  When searching for a user, the database shows the persons whose name include the searched word or words.
  When user clicks the light green button and it becomes bright green, the database adds that user to the list of friends.

• End state:

  The wanted user is added to the friend list.

"User wants to add foes"

Adding foes happens the same as adding friends, except the user needs to click the light red button instead of the light green one. After clicking it, it becomes bright red and the person is added to the foe list.

"User wants to delete friends"

• Initial state:

  User is logged in and on the main page.

• Normal flow:

  1. User sees the people list button and clicks it.
  2. User is redirected to the people list page.
  3. User sees the filter button "Friends" and clicks it.
  4. User only sees people marked as friends by the user.
  5. User clicks the green dot next to the selected person's name.
  6. The dot turns light green and the selected person is deleted as a friend.

• What can go wrong:

  No user errors exist for deleting friends.

• Other activities going on at the same time:

  The database does a search with the parameter "friends" set by the user when clicking the "Friends" filter button. The database then returns the users who have a friend status with the user. After the user clicks the bright green button, the friend status of the selected user is deleted from the database.

• End state:

  The selected user is no longer marked as a friend.

"User wants to delete foes"

User can delete foes in the same way as adding them. In this case they click first the "Foes" filter button and then the bright red button next to a person's name, which makes it turn back to a light red button. After this, that user is deleted from the foes list.

"User wants to search for people"

• Initial state:

  User is logged in and on the main page.

• Normal flow:

  1. User sees the search button and clicks it.
  2. User is redirected to the search page.
  3. User types in the search field the name or part of the name of the person the user wants to find.
  4. List of matches appear on the list below.

• What can go wrong:

  User might mistype the name, and the person looked for is not shown on the list.

• Other activities going on at the same time:

  The database does a search with the parameters set by the user when clicking the search button. The database then returns the users whose name includes the searched word or words.

• End state:

  The user sees the search results as a list below on the search page.

"User wants to see the people list"

• Initial state:

  User is logged in and on the main page.

• Normal flow:

  1. User sees the people list button and clicks it.
  2. User is redirected to the people list page.
  3. User sees a list of people that are logged in right now.
  4. (User can choose to see the list of friends or foes by clicking either "Friends" or "Foes" filter button.)

• What can go wrong:

  No user errors exist for checking the people list.

• Other activities going on at the same time:

  The database does a search with the parameters "is_online" when clicking the people list button. The database then returns the users who are online.

• End state:

  The user is on the people list page and sees the list of all the people that are online.

"User wants to see people on the map"

• Initial state:

  User is logged in and on the main page.

• Normal flow:

Scenario 1:

1. User sees the map button and clicks it.
2. User is redirected to the map page.
3. User sees people that are online as dots on the map.
4. (If the dot is green, the person is the user's friend. If the dot is red, the person is the user's foe. If the dot is gray, the person is neither the user's friend or foe.)

Scenario 2:

1. User sees the search button and clicks it.
2. User is redirected to the search page.
3. User types in the search field the name or part of the name of the person the user wants to find.
4. List of matches appear as a list below.
5. User sees the person in the list, whose current location the user wants to see.
6. User clicks the name of the person in the list.
7. If that person is online, the user is redirected to map screen.
8. The person's dot is shown bigger on the map than other dots and next to the dot a small pop-up is opened that tells the person's name.

Scenario 3:

1. User sees the people list button and clicks it.
2. User is redirected to the people list page.
3. User sees the person in the list, whose current location the user wants to see.
4. User clicks the name of the person in the list.
5. If that person is online, the user is redirected to map screen.
6. The person's dot is shown bigger on the map than other dots and next to the dot a small pop-up is opened that tells the person's name.

• What can go wrong:

  In scenarios 2 and 3 it is possible that the person, whose location the user wants to see on the map, logs out at the same moment when the user is redirected to the map screen. In this case, the person's location cannot be shown.

• Other activities going on at the same time:

  The software calculates the location of the users utilizing wifi connections.

• End state:

  The user is on the map screen page and sees the online users as dots.

"User wants to plan a route"

• Initial state:

  User is logged in and on the main page.

• Normal flow:

  1. User sees the plan route button and clicks it.
  2. User is redirected to the plan route page.
  3. User sees a page including fields where the start and destination locations can be typed in. (The locations can also be selected from the map or the user can choose to use the current location.)
  4. User types in the start and end locations.
  5. After the locations have been selected, the user clicks "plan route" button.
  6. The user is redirected to map screen that now shows the route line on the map.

• What can go wrong:

  If the user types in a location not known by the software, an error is returned.

• Other activities going on at the same time:

  The software calculates the location of the users utilizing wifi connections and the shortest route to the destination. The route is calculated so that it is as short as possible but also taking into account that the user doesn't have to walk close to foes.

• End state:

  The user is on the map screen page and sees the route on the map.

"User wants to sign up"

• Initial state:

  User is not logged in and not a registered user.

• Normal flow:

  1. User opens the application and sees the login page.
  2. User sees the "sign up" button and clicks it.
  3. User is redirected to the sign up page.
  4. User types their personal information to the form and clicks the sign up button.
  5. If the information given by the user is in the correct form, the user is redirected to main page and is now logged in.

• What can go wrong:

  The sign up doesn't go through if any of the following cases occur:

  • The username already exists.
  • The given password is less than six characters long.
  • The passwords typed into the fields "new password" and "repeat password" are not the same.
  • The email address doesn't include @ sign.
  • The year of birth is smaller than 1900 or larger than the current year.

• Other activities going on at the same time:

  Database checks if the information given includes any of the cases listed in the previous paragraph. If not, the user information is saved into the database.

• End state:

  The user is registered and logged in their account.

2.4 Depiction of one use case as a flow chart