Figure 30: Device registration of the Google Cloud Messaging service token

4.2.3.1. Send challenge notification

4.2.3.2. Receive Challenge Notification

4.2.3.3. In Game

4.2.3.4. Show profile information

4.2.3.5. Show match history

4.2.3.6. Show leader board

4.3. Wear Client

• 
  Listener Service, a service that start when receive a data map through the Data API, the service is dedicated to start the Game Activity when a match start or a player accept a challenge and to rise a notification sent from the phone.
  
• 
  Wear Lobby Activity, the home layout when the user opens the application with a list with the options profile, match history, leaderboard, achievements and exit. The user can select the options and it will be redirected to the activity with the required information.
  
• 
  Win Activity, activity that control a layout that shows when a team win or lose a match with the final score.
  
• 
  Profile Activity, activity that control a layout that shows the relevant information (photo, name, elo and position) of a player. This activity is reused to show the detail of any other player in the leader board or in the match history.
  
• 
  Leader board Activity, activity that controls a layout that shows in a list the ten first positions in the leaderboard with a photo, the name of the players and the position in a badge. If the user clicks on any of the players in the list, a detail of the selected player’s profile is shown.
  
• 
  History Activity, activity that controls a layout that shows a list of the ten last games played by the user. The list shows the score and an indicator if the user won or lose the game
  
• 
  Detail History Activity, If the player clicks to see the detailed score, an activity will rise with the photos and positions of the teams and the score. Additionally, if the user clicks the photo of any participant player it displays the profile information of the selected player.
  

4.4.1. Use case testing

4.4.2. User Interface Testing

• 
  Design for big gestures [21]: in list menus as the home screen must display at maximum 3 items big enough to cover the screen to be easily touched.
  
• 
  Stream Cards [21]: for the notifications, they were prioritized to be queued when a challenge arrives. If the player does not attend the notification the next one will replace it. The notification can be reused for multiple games without dismissing it.
  
• 
  Do one thing, really fast [21]: Each feature of the application has followed the maximum amount of four touches and swipes to performed the functionality.
  
  • 
    Profile: Open application, touch profile, dismiss card.
    
  • 
    Leader board: Open application, touch leader board, dismiss card.
    
  • 
    Game history: Open application, touch game history, touch summary, dismiss.
    
  • 
    Game: In game interaction, dismiss result card.
    
• 
  Design for the corner of the eye [21]: The application has summarized information on each card to not keep the player too long in the application, so it was decided to check at maximum to have five items per screen that fill the interface that are easy to read.
  
  • 
    Profile: Photo, name, elo, classification.
    
  • 
    Leader board: List with photo and classification.
    
  • 
    Game history: List with indicator of victory or loss, score, text of victory or loss.
    
    • 
      Game summary: Four photos and score.
      
  • 
    Game: Add goal button, add auto goal, remove goal, score.
    
    • 
      End game: result badge and text of victory or loss.
      
• 
  Don’t be a constant shoulder tapper [21]: The application only will notify when the user is challenged vibrating just once per notification.
  

• 
  The objective of creating a multiplayer version of the Table Me application was totally fulfilled developing and adapting the main features of the Table Me application, following the design lineaments of Android and the user’s requirements.
  
• 
  The implementation of the Peer to Peer server with lockstep without simulation using Socket IO to improve the communication allow to the application an easy to use interface in real time to communicate the application with the server allowing to not increment significantly the delay the communication between the items that have a small traffic interaction.
  
• 
  The communication performance given by the application using Android Wear technology in the testing environment gave excellent results with a maximum delay of 1 to 2 seconds to deliver the information to the smartwatch, this delay due to the Bluetooth connection range and obstacles that can be between the devices.
  
• 
  The APIs from the Wearable package used in the project to develop the communication with the application were the Message API due to the easy usage and the functionalities that provide to send appropriately remote procedure call with the games commands (goals, dismiss goals, auto goals) adapting the Peer to Peer server’s structure Finally, the Data API to synchronize large amounts data (profile, leader board, match history) using Assets and supporting basic data types.
  
• 
  The Android Wear application was design to not consume large amounts of energy of the smartwatch during the operation during the game or when the user is consulting information. For this reason, the application does not keep the screen on until the user actively focusses the screen to use it, and the heavy load operations are provided by the service in the phone that runs only when the user request information through an interaction.
  
• 
  The design of the application for the smartwatch was based on sketches previously done by the group in the laboratory, and the last version fulfilled the final user’s expectation giving enhanced and easy to use interfaces during the gameplay and consulting the player information following the design lineaments of Android [21].
  
• 
  The methodology used for the development of the project allowed to create an organize and schedule to deliver the application and deliverables items to fulfill the items to be developed with the approval of the final user on time.
  
• 
  The Android wear technology is advancing faster, allowing different functionalities to be used with the phone or a direct connection with internet, and the basic channels of communications between the devices, offer the basic data exchange and easy to use. It allows an easy and fast development of android wear applications. However, the management of large amount of data to be exchanged via Bluetooth can take too long and present inconsistent data. With the time when the technology migrates to the usage of Wi-Fi or better connection with the smartwatch allow a better network performance.
  

7. Appendixes

1. 
   Introduction
   

• 
  Description of the process followed for the requirement recollection and analysis.
  
• 
  Description of the prioritization process of the requirements to determine the functionalities to implement.
  
• 
  Description of the process for obtaining the use cases.
  
• 
  The domain model of the Server, the Android and the Android Wear applications.
  

2. 
   Process of development of requirements
   

2.2. Refinement of the use cases

2.3. Functional requirements

2.4. Nonfunctional requirements

2.5. Requirement identification

2.6. Requirement specification

• 
  ID: Unique deification of the requirement.
  
• 
  Description: Definition of the requirement.
  
• 
  State: Shows the phase of progress of the requirement in the following classification: Proposed, Validated, Implemented.
  
• 
  Priority: priority of each requirement that is based on the modified formula of Karl Wiegers, that give a score that if is greater than 1 has more priority.
  
• 
  Type: Functional or Nonfunctional.
  
• 
  Relations: Show the relation of the requirement with the other requirements and the use cases, these can be of dependence or realization.
  

• 
  Benefit: relative benefit of the implementation of the requirement.
  
• 
  Penalization: relative penalization if the requirement is not implemented.
  
• 
  Cost: calculation of the relative cost, based in the following factors: complexity, design and code reuse, and documentation needed.
  
• 
  Risk: relative risk based on the technic complexity and the feasibility needed.
  

2.8. Verification and validation

• 
  Is unique?
  
• 
  Is explanatory?
  
• 
  Is consistent?
  
• 
  Is feasible?
  
• 
  Has correct references?
  
• 
  Is precise and not ambiguous?
  
• 
  Us atomic?
  
• 
  Is traceable?
  
• 
  Is a declaration of a necessity and not a solution?
  
• 
  Is it necessary?
  
• 
  Show how to execute it?
  

2.9.1 General traceability

• 
  Use cases: the use cases are used for the identification of the requirements, moreover are necessary to establish the information flow in the different scenarios.
  
• 
  Prioritization table: The table of requirements prioritization to identify easily the order of implementation of which requirements must be implemented in the correct way achieving the essential functionalities of the system. (Annex: Prioritization Table)
  
• 
  Realization Matrix: This matrix is used to identify the relations between the requirements and use cases, so in the same way in a graphic way identify the dependencies between requirements and how to find the prerequisites between them.
  
  • 
    Annex: Realization Matrix for functional requirements.
    

• 
  Use case relations: the use case where the requirement was obtaining, and has a relation that implements it.
  
• 
  Requirement relations: The requirements that are associated and dependent to the requirement.
  

3. 
   Global Description
   

3.1.1. User Graphic Interface

3.1.1.1 Profile information on the smartwatch

After opening the application, the user can use a list of option to select about the user’s profile information and the game. The profile option shows in a similar way as in the Table Me application the basic information of the user. Firstly, the photo, the position in the leader board inside a badge, two bars that indicate proportionally the number of victories (green bar) and number of lost games (red bar). The at the end the name of the user and his/her ELO score.



Figure 39: Profile information

3.1.1.2. Gameplay on the smartwatch

3.1.1.3. Match history on the smartwatch

3.1.1.4. Leader board on the smartwatch

3.1.2. Software and Hardware interface

3.2. Application characterization

• 
  The server application must support multiple client connections in multiple matches.
  
• 
  The server application must allow to create multiple matches.
  
• 
  A client through the TableMe application can create a game notifying the server and the involved players allowing them to use their smartwatches if they have any.
  
• 
  The match host and the players can help to manage a game’s score.
  
• 
  Every player with a smartwatch can score a goal, dismiss a goal or score an auto goal.
  
• 
  All the players and the host will be notified in real time from the server.
  
• 
  The host of the game will see the progress of the game in the user graphic interface of a match from the previous TableMe application.
  

3.4. Restrictions

• 
  Language restriction:
  
  • 
    The clients must be implemented in Android for the Android mobile and Android Wear devices.
    
  • 
    The server must be implemented in Java Script using the platform Node JS.
    
• 
  Programming restriction: The project will be implemented using the Object Oriented paradigm for software development.
  
• 
  Connection restriction:
  
  • 
    The server must admit multiple user connection simultaneously for multiple matches.
    
  • 
    The mobile client must connect to a single server that host the matches.
    
  • 
    The match will be alive until the match host finish the game or it gets disconnected.
    
• 
  Game restriction:
  
  • 
    The system must implement a table foosball match rules with four players, following the lineaments stipulated by the previous TableMe application.
    
• 
  Architecture restriction:
  
  • 
    The system must develop following the Client/Server architecture for the communication for between the server and the mobile devices.
    
  • 
    The system must use the Colyseus multiplayer game architecture for the implementation of the game instances in the clients and the server.
    
• 
  Persistent restrictions:
  
  • 
    The server application must persist the devices registered with a new Google Cloud Messaging token.
    
  • 
    The server will not use a data base for the persistency.
    
  • 
    The persistency will be done through normal files.
    
• 
  User interface restrictions:
  
  • 
    The interfaces of the system will be in English.
    

• 
  The server used in the previous TableMe application will provide information of the user’s profile, and match history. Additionally, the leaderboard of the players.
  
• 
  The mobile devices used must be connected to internet.
  
• 
  The mobile devices may or not have a smartwatch paired.
  
• 
  The requirements of the system are formulated by Marco Marengo though presentations of the application and the guideline of the previous Table Me application.
  

• 
  The mobile and smartwatch devices where the application is installed can execute the application.
  

3.7. Requirement distribution.

7.2 Use Case Specification