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
data
Internet
server
clients
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.
