1. Generic Simulator for Users' Movements and Behavior in Collaborative Systems

2. Academic advisor: Yuval Alovich Yuval Alovich Professional advisor: Lina Shlangman Lina Shlangman

3. Generic Simulator for Users' Movements and Behavior in Collaborative Systems Members: Gilad Ivry Gilad Ivry Mattan Margalith Mattan Margalith Niv Saar Niv Saar Alex Surguch Alex Surguch

4. Project Description In this project we will develop an application which simulates location based collaborative systems in big communities. In the simulator we will use real movement patterns derived from locations of people recorder over time. We will also combine different user behaviors in collaborative systems.

5. Project Purpose In order to launch a new cellular application, the customer wishes to simulate the usage of the application, and it’s spread in a given population at a given time.

6. Problem Domain  a lot of users  A LOT of statistics  A lot of parameters that will define the behavior of the scenario.  Different user types (groups) that behave and use the application differently.  Non- deterministic behaviors at most.

7. Problem Domain- Example Consider a communication service that enables every user to ask and reply to messages that are regarded to his whereabouts, using a cell phone.

8. Problem Domain- Example For instance, a person at his house in Ramat- Gan wants to know how crowded the Mall in Azriely Towers is.

9. Problem Domain- Example He then sends a query, using the system, and his message is routed to a group of users at the relevant location, using a smart selection algorithm that chooses each individual in this group.

10. Problem Domain- Example The receivers may respond or discard the message, but the relevant replies are routed back to the user, which now has an answer to his query, in a matter of minutes.

11. Solution Our solution is to build a generic simulator that will:  enable the user to configure a wide range of parameters and settings, thus manipulating every aspect of the scenario.  Run different scenarios, inject events and view the properties of different groups  Gather, display and compare variant statistical data.

12. Solution GUI Simulator Selection Incentives Query Evaluation Location Prediction DB

13. Functional Requirements Configure the System's users. The client will have the option of defining groups of users in accordance to these properties: -Number of users. -The distribution of the users on the map. -Statistical data (user's satisfaction, probability of sending and receiving messages).

14. Functional Requirements Configure the System's users' movement. The Client will have the option of choosing a method of defining the users movement: -Using DB. The entire scenario is pre- defined in an external DB which the Client provides. -Using the wizard, the client can choose between modes (static, probable movement)

15. Functional Requirements Configure the System's Events. The client will have the option of defining special events. The Configuration options will include: -Number of events. -Location of each event. -Statistical data – the affect that the event causes to the users' behavior. The configuration may be via DB or using the wizard.

16. Functional Requirements Choosing Algorithms The client will have the option of choosing between pre-set selection algorithms. Start simulation Running a scenario

17. Functional Requirements Graph visualization The client will be able to choose a statistical data from a wide array of options, and the visual representation of the chosen data will be displayed.

18. Non-Functional Requirements  Speed, Capacity & Throughput:  The application must launch in less than 2 seconds.  Each transaction of the system, tick, should be processed in under one second (under the assumption that the system has no more than 100,000 users, otherwise, computation time may rise), and the display of the GUI should refresh during this period of time, or during other user configured time.  The system is a web application and can support up to 10 users simultaneously.

19. Non-Functional Requirements  Reliability:  This system will remain online at all times. The system will be able to recover from data crashes and restore the data of previous runs from the DB.  Safety & Security:  The system's code will be protected by the server that it is loaded on.  The simulator does not require any permissions or security levels.

20. Non-Functional Requirements o Portability:  The application will run on a Microsoft Windows operation system and will be operable for Explorer and Firefox browsers only. o Usability: Extensive learning of the software use will be difficult and is suited to expert users only (knowledge of the algorithms, probabilities and etc.). For novice users, a setup wizard will be provided, which enables a quick and simple definition of the simulation.

21. Use Cases

22. Use case ID: 1  Use case name: configure simulation properties  Primary actors: User  Description: The user will configure all the properties and input all the necessary initial data that are needed in order to run the simulation.  Trigger: The user will ask to configure new simulation.  Pre-conditions: None

23. Use case ID: 1  Post-conditions: The new system configuration has been saved in the DB and the simulator is initialized with all the inserted data  Flow of events: The user chooses the amount of simulated entities that will participate in the simulation. The user chooses the general statistics for the simulated entities. The user chooses how to arrange the simulated entities in the map.

24. Use case ID: 1 The user chooses how the simulated entities will move on the map. The user chooses the length of the simulation (number of ticks) and the duration of each tick in hours. The user configures the special events. The user configures how to generate the requests. The user chooses the algorithms that he wants the simulation to work with.  Alternative flows: User can return to the previous step in the wizard

25. Use case ID: 2  run the simulation  Primary actors: User  Description: The user will activate the simulation  Trigger: User presses the run simulation button.  Pre-conditions: a configuration for the simulation has been loaded.  Post-conditions: all the data from the simulation is saved in the DB and displayed for the user  Flow of events: User presses the start simulation button.  Alternative flows: None.

26. Use case ID: 2