How to Identify Actors for iOS Apps - dummies

How to Identify Actors for iOS Apps

By Rajiv Ramnath

Identifying actors in an iOS app requires that you write down their interactions in a step by step format. For example, in Tic-Tac-Toe, there are either two actors who are the players of the game or one human actor who is playing against a computer (which is considered a system actor). The interactions of the actors with the game are as follows:

  1. A player starts a game session.

  2. A player makes a move (that is, places an X or an O in any empty square).

  3. The game ends in either a win or a draw. When the game ends, the players are notified of the result.

  4. A player continues a game session and starts another game.

  5. A player terminates the session, which could happen in the middle of the game or after a game is over.

Here’s the general format of a use case:

  • Title of use case

  • Actor or set of actors interacting with the system

  • Starting point of the interaction, also known as the assumptions necessary for the interaction

  • Short description of the interaction

  • Outcomes of the interaction

Consequently, the use cases for Tic-Tac-Toe are as follows:

  • Use Case 1: Player starts a game session.

    Actor: Player.

    Assumptions: The app is running. One of the players is presented with a user interface option to start a new session.

    Description: This use case describes the interactions that take place when a player creates a new Tic-Tac-Toe session. Starting a session automatically starts a new game.

    Outcomes: Scores are set to 0 for both players. A new game starts, and the players see a blank three by three grid to play on.

  • Use Case 2: Player makes a move.

    Actor: Player (could be Player 1 or Player 2).

    Assumptions: A game session and a game are active.

    Description: Player 1 makes the first move. His move consists of placing an X in an empty square on the game grid. Player 2 goes next by placing an O in an empty square. The players then alternate until the game ends.

    Outcomes: After each move, an X or an O appears in the appropriate square on the grid.

  • Use Case 3: The game ends, and the players are notified.

    Actor: Player (could be Player 1 or Player 2).

    Assumptions: A game session and a game are active. A player (Player 1 or Player 2) just made a move.

    Description: If the move results in every cell in a row, column, or diagonal being filled with the same symbol (either an X or an O), the game ends. The last player to make a move wins, and his tally is incremented accordingly. If the move doesn’t result in a win but all the cells are filled leaving the next player with no place to play, the game ends in a draw.

    Outcomes: The players are notified of the outcome and the updated scores and are asked whether they want to continue the session by playing another game.

  • Use Case 4: Player continues a session.

    Actor: Player (could be Player 1 or Player 2).

    Assumptions: A game session is active. A game has just ended (see Use Case 3), and the players are asked whether they want to continue the session by playing another game.

    Description: A player elects to continue the session by starting a new game.

    Outcomes: A new game begins within the same session.

  • Use Case 5: Player ends a session.

    Actor: Player (could be Player 1 or Player 2).

    Assumptions: A game session is active. A game has just ended (see Use Case 3), and the players are asked whether they want to continue the session by playing another game.

    Description: A player elects not to play another game, so the session terminates.

    Outcomes: The session terminates. Scores are reset. The user is presented with an option to start a new session (see Use Case 1).

This uses a simple notation to demonstrate use cases, but there are many formal formats for documenting use cases. You can find one to suit your taste by searching the web. Just enter the keywords Use case template in your favorite search engine.