INVESTMENT GAME IN SOCIAL NETWORK Academic Advisor: Dr. Yuval Alovici Professional Advisor: Dr. Mayer Goldberg Team Members: Ido Bercovich Dikla Mordechay Lilach Tesler

Background Many people may have heard about Investment Games, which provides investment companies the ability to attract new clients. Our team decided that we can create our own game which will be a new, funnier and more exciting investment game known as Trading Champions. This will be a game that can attract also people who are not interested in real investments, but just looking for the thrill in the investment world. A game involving competition, strategy and luck. The game will be an online game in the social networking site Facebook.

The Problem Domain  The world of trading seems to be a dark world, and can be a bit frightening for the average person. It seems that you have to be a genius in order to understand this world, and it can seem impossible to make any money.  We want to make this world a more understandable and reachable place for all users.

System Architecture Internet clients server data

Functional Requirements  User Mode: User will be able to perform the following functions: View My Stocks, View All Stocks, View Stock, Buy Stock, Sell Stock, Search Stock, View newspaper, View weekly expert advice, See friends/other participants rank, Ask For Advice, Give An Advice

Functional Requirements (cont’)  Admin Mode: User will be able to perform the following functions: Add Stock issue (Add Company), Publish/Edit/Change the newspaper.

Non-Functional Requirements  Speed, Capacity & Throughput: Real time database capacity. The Database should be able to hold the data for all the time. There will not be a maximum number of users in the website application. Speed of buying request – Maximal time: 1.5 sec Speed of selling request – Maximal time: 1.5 sec Speed of query– 5 sec Speed of update bills- 3 sec Log in – immediate. Throughput of buy & Throughput of sell – immediate Throughput of a query – 5 sec Throughput of founding a new company – dependant on the user.

Non-Functional Requirements  Safety & Security: Since we are offering access to the game through the Facebook website, we will only allow authorized users to the site. No encryption is needed, and will not be used.  Portability The system is accessed from the web and therefore will be available from all web application. The website will be available in English at first and later in other languages, according to the requirements of our clients.  Reliability Our system database will be save on decentralized database, backup will be saved on distributed servers as the MySQL supplies. The system will be updated in real-time, so the data will have to be saved as fast as possible. If for some reason the connection to the server will fall, the user will see his changes after re logging into the system.

Non-Functional Requirements  Usability The user of our system is a simple user, without former knowledge of the stock market. The website will be friendly and “flat”, the user will not have to wonder around to find what he wants, and everything will be available in the simplest way.  Availability The system will always be available 24 hours a day.

Use case Diagram  להשלים!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Use-case 3: Buying stocks Primary Actor: A simple user Stakeholders & Interests: A registered user who wants to buy stocks of a company. Precondition: The user logged in, the user has enough money to buy the stocks and the stocks are on sale. Post condition: The amount of money of the user will reduce in the cost of the stocks and the stocks will be under the user ownership. Main (Success) Scenario: 1) The user is logged in. 2) The system logs in the user. 3) The system updates the amount of money and stocks the user own. 4) The user picks a company he wants to buy its stocks. 5) The user buys the stocks. 6) The system will reduce in the cost of the stocks from the users’ money and moving the stocks to the user ownership.

Use-case 4: Selling stocks Primary Actor: A simple user Stakeholders & Interests: A registered user who wants to sell a stocks of a company. Precondition: The user logged in, the user owns the stocks. Post condition: The amount of money the user has will be added in the cost of the stocks, and the stocks will no longer be under the user’s ownership. Main (Success) Scenario: 1) The user is logged in. 2) The system logs in the user. 3) The system updates the amount of money and stocks the user own. 4) The user picks company stocks he wants to sell. 5) The user advertises the stocks he want to sell and their price. 6) The system advertises the user proposal.

Use-case 5: Searching for stocks by name Primary Actor: A simple user Stakeholders & Interests: A registered user who is looking for a stock. Precondition: The user logged in. Post condition: If such stock exists the user will see it. Main (Success) Scenario: 1) The user types the name of the stock he is looking for. 2) The system performs a search for the specified name. 3) The system presents the wanted stock.

Use-case 10: adding a company Primary Actor: An Administrator Stakeholders & Interests: An administrator who wants to add new stocks to the game. Precondition: The name of the company is not in the system, the amount of stocks is positive. Post condition: A new company is added to the market and its stocks are on sale. Main (Success) Scenario: 1) The user clicks “add new company”. 2) The user enters the name of the company and the number of stocks. 3) The system creates a new company and puts its stocks up for sale.

Risks  Risk: The System may have many requests at a given time point.  Solution: Using the reliable erlang gen_server, which can handle many requests.  Risk: The Site should be available 24 hours a day.  Solution: Using gen_server code swapping, no restart needed for update.