XTendTraders.com Trading room simulator

Transcription

1 XTendTraders.com Trading room simulator BELGHITI ALAOUI Mohammed IMAFA BEN HAMOUDA Ahmed IMAFA EL FERACHI Anas AL EL HAJJI Khalil AL Polytech Nice Sophia Antipolis SI4 AL/IMAFA

2 1 CONTENTS 1 CONTENTS INITIAL NEEDS REPORT SPECIFICATIONS PRODUCT DEFINITION Main Use Case Use case: Visit Use case: Trade PRODUCT ANALYSIS Data base design (With UML) Sequence diagrams PRODUCT DESIGN Software architecture Classes diagram Activity diagrams for orders placement Activity diagrams for orders execution GUI Models PROJECT MANAGEMENT Work environement Versioning Project management DIFFICULTIES FUTURE ANNEX GUI models Screen shots of the real application: Gantt diagram:...23 Polytech Nice Sophia Antipolis SI4 AL/IMAFA 2

3 2 INITIAL NEEDS REPORT The main goal of this project is to create a trading room simulator in order to train future traders. This web application will offer the main trading functionalities and many features related to the financial word like a news section, historical and real time charts, stock s analysis... 3 SPECIFICATIONS Our application is a trading room simulator that can be used by multiple users. The simulator uses real data streams (NASDAQ), Google flow for analysis and Yahoo finance for real time charts and information. The simulator uses fake money and does not permit real actions on the market. A user needs an authentication to access the trading room. A non authenticated user can only consult information. A non registered user can create an account and get registered. Every user, once registered, gets a stock portfolio with an initial amount of cash that can be customized by the application administrator. When an authenticated user buys stocks, the equivalent amount of cash is debited and the stocks bought are added to his portfolio. When an authenticated user sells stocks, they are removed from his portfolio, and the equivalent amount of cash is credited on his account. The application does not permit short selling. The application does not manage its own orders book, as it uses the real flows; the price of the stocks depends on the orders book of the real stock market. i.e. selling or buying stocks does not affect the actual market price Polytech Nice Sophia Antipolis SI4 AL/IMAFA 3

4 4 PRODUCT DEFINITION 4.1 Main Use Case There are five different actors for our application: The Google data stream: Google. The Yahoo data stream: Yahoo. The authenticated user: Trader. The non authenticated user: Visitor. The administrator: Admin The main use case diagram shows the interaction of the different actors and the web application: Polytech Nice Sophia Antipolis SI4 AL/IMAFA 4

5 4.2 Use case: Visit A visitor can visualize stocks information and market s information but cannot trade. Use case diagram: Activity diagram: Polytech Nice Sophia Antipolis SI4 AL/IMAFA 5

6 Cockburn-like scenarios: Authenticate Use case: authenticate Primary actor: Visitor Precondition: The visitor is connected and has chosen authenticates Primary scenario: 1. The visitor enters his username and password 2. The username and the password are correct Post condition: The user is authenticated Extensions: 2a The username and the password are incorrect, we return to Visit View analysis/charts Use case: View analysis/news Primary actor: Visitor Secondary actors: Data streams Precondition: The visitor is connected and has chosen analysis Primary scenario: 1. The visitor views the analysis and the news of the wanted stock Post condition: The visitor is connected Extensions: 1a Google flow doesn t answer, no technical analysis 1b Yahoo finance flow doesn t answer, no fundamental analysis (news) 1c Both data streams doesn t answer, no technical analysis, no fundamental analysis 4.3 Use case: Trade Once a user has authenticated, he can access to all the features of the web application, the sections described before and the trading room, of course he cannot authenticate anymore since he is already logged in. Polytech Nice Sophia Antipolis SI4 AL/IMAFA 6

7 Use case diagram: Activity diagram: Polytech Nice Sophia Antipolis SI4 AL/IMAFA 7

8 Cockburn-like scenarios: Place order Use case: place order Primary actor: Trader Secondary actors: Yahoo Precondition: The user is authenticated and has chosen place order Primary scenario: 3. The user selects the stock 4. The user selects the limit type 5. The user selects buy 6. The user enters the quantity 7. The user has enough cash (including pending orders) Post condition: The order is added to the orders queue Extensions: 5a The user selects sell 6a The user enters the quantity 7a The user has enough stocks 7b The user doesn t have enough cash, The order is not added to the orders queue, we return to Trade. 7C The user doesn t have enough stocks, The order is not added to the orders queue, we return to Trade. Polytech Nice Sophia Antipolis SI4 AL/IMAFA 8

9 5 PRODUCT ANALYSIS 5.1 Data base design (With UML) 5.2 Sequence diagrams View analysis/news: The trader or the visitor access the analysis section View stocks: The trader or the visitor access the stocks information section Polytech Nice Sophia Antipolis SI4 AL/IMAFA 9

10 Manage orders: The trader manages old and pending orders Place order: The trader places a buying order Polytech Nice Sophia Antipolis SI4 AL/IMAFA 10

11 6 PRODUCT DESIGN 6.1 Software architecture For our project we have decided to follow a distributed programming process to develop a multi-tiers application where the presentation, the application processing, the data management and data storage are separate processes. This kind of architecture provides us a model to create a flexible and reusable application. This architecture allows us to develop all these tiers in the same time. In our case: The presentation layer (or the client tier) is based on the web browser that displays the dynamic HTML pages. The application processing is based on JSP pages and some Java classes for the information processing and analyzing and other Java classes for the database interaction. We divided this layer into two sub tiers: o The web tier is composed of JSP pages that interact directly with browser. o The business tier is composed of application processing, analyzing classes and data management classes that interact with the database. The data storage is based on a MySQL Database. Web Browser Presentation tier Web tier JSP pages Business tier Business classes Data access classes Data storage tier MySQL database Polytech Nice Sophia Antipolis SI4 AL/IMAFA 11

12 Making the choice for each technology that we will use for each tier weren t an easy step, because of the large programming languages, technologies and servers available in the market. After a long debate we finally decided that we will use for the presentation layer HTML5 with bootstrap library of Twitter because of its great esthetic potential and because of it being a new promising HTML version. Concerning the web and business tier we chose JSP and JAVA to profit of the Java AJAX simplicity and efficiency of java, in order to have the possibly to compile this JSP and JAVA files on a free server like Apache Tomcat, and also to use the previous courses of J2EE seen during this semester. Finally for the data storage tier, we selected from all the free SQL database servers a MySQL server. In addition of being the world's most used relational database management system, MySQL is easy to use with the JAVA languages. 6.2 Classes diagram Polytech Nice Sophia Antipolis SI4 AL/IMAFA 12

13 6.3 Activity diagrams for orders placement Buy order placement: When a user wants to buy stocks, if he has enough cash (including the pending orders), the order is added to the queue. Activity diagram: Sell order placement: When a user wants to sell stocks, it s like for buying but here we check that the user has the stocks he wants to sell, and has the sufficient amount of them, if the test succeeds, the order is added to the cue. Polytech Nice Sophia Antipolis SI4 AL/IMAFA 13

14 Activity diagram: 6.4 Activity diagrams for orders execution Buy order execution: Buying at the best limit: If there are enough stocks on sale, the users gets the totality of the order, else he gets the ones on sale and for the others the order stays pending until there are enough on sale at the same or a lower price than the price at the moment of the order placement. At the end of the operation, the user s cash is updated, the stocks are bought are added to his portfolio, and if there the totality wasn t available, the order is updated (Quantity, comments, status). Buying at a fixed limit: Once the price of the stock reaches the fixed price or a lower one, the user gets the stocks available, if there are enough stocks the user gets the totality of the order, else he gets the ones available, and the updated order stays in the queue for the others. The rest of the stocks will be bought once there are enough on sale at the fixed price or a lower one. At the end of the operation, the user s cash is updated, the stocks are bought Polytech Nice Sophia Antipolis SI4 AL/IMAFA 14

15 are added to his portfolio, and if there the totality wasn t available, the order is updated (quantity, comments, status). Sell order execution: For the sell order execution, it s like the buy order execution. We just check that there is enough requests for the stocks we want to sell. And we proceed the same way when the requests are lower than the amount we sell, we sell the requested stocks, update the user s cash, portfolio, and then the order (Quantity, comments, status). 6.5 GUI Models Because of their size, the models are put in the annex section of this report. Polytech Nice Sophia Antipolis SI4 AL/IMAFA 15

16 7 PROJECT MANAGEMENT 7.1 Work environement To carry out well our project, we used different environments: Astah Community for design and UML diagrams. NetBEANS IDE for the code development (Java classes, JSP pages, JavaScript files ). GlassFish Server for the web application deployment. MySQL Data base for the data persistence. 7.2 Versioning Concerning the versions management, we used the SCRUM method, based on the separation of the work into different parts, called sprints; in our case we have 3 different versions: V 1.0 : o Users registration. o Users authentication. o Order s placement at the market price. o Orders consulting. V1.5 : o Charts consulting. o Analysis consulting. o News consulting. o Stocks consulting. V2.0 : o Order s placement at a price limit. o Traders ranking consulting. o Visitors access. 7.3 Project management For the general project management, we made a Gantt diagram that describes the entire project from the beginning, we started by defining the project specifications, then for the product definition, we tried to make some prototypes that helped us deciding what features we could develop and what was technologies we should aim. Once the prototypes were completed, we started the development of the different versions. Each version had some features in addition to all the features that were in the version before. For the Gantt diagram, report to the annex section. Polytech Nice Sophia Antipolis SI4 AL/IMAFA 16

17 8 DIFFICULTIES We encountered many problems during the development of our web application, some of them were easily resolved and some others needed more time and resources; here s a list of the main difficulties faced during our project: - The parsing of stocks data streams: The file returned contained values separated by, while the values themselves contained sometimes,, so we had to separate one simple request into three different ones. - Orders execution: This part was one of the most difficult parts in the project development, we had to take into consideration all the parameters, do the right transaction (At market, at limit) and finally update the order depending on how the execution went. - Sessions management: We had to make the difference between simple visitors and registered users, they have some sections in common but the visitor can t trade. - Multiple simultaneous users: We used an httpsession object to save the identity of the user on the client side then use it for each request to the server. Therefore no user s information is kept on the server. - Data base s requests optimization: To avoid having many requests from different clients that could be answered with only one request to the data base. We chose to create objects on the server containing all the wanted information, this way, the server don t access the data base for each request. 9 FUTURE The project we realized has many features but we want to improve it and make it better. First we want to deploy the application on a server and see how it reacts to real users with many simultaneous orders. Once it is stable, we will of course try to improve it with some new feature that we didn t have the time to implement; we made a small list of these features: - An interface for the administrator of the web application. - A profile management section, where users can modify all their information. - Add other data streams for other markets. - Add other order types order types. Polytech Nice Sophia Antipolis SI4 AL/IMAFA 17

18 10 ANNEX GUI models Homepage: Header Login bouton XtendTraders Presentation Player Rankings Latest Financial News Footer Registration page: Header Login bouton Registration fields Footer Polytech Nice Sophia Antipolis SI4 AL/IMAFA 18

19 Trading page: Header Trading header Logout bouton Fields of order transmissio n Week chart Real time prices Ask and Bid table Live charts Footer Trading page: Portfolio Header Trading header Logout bouton Portfolio Cash and Worth Footer Polytech Nice Sophia Antipolis SI4 AL/IMAFA 19

20 Trading page: Orders Header Logout bouton Trading header Pending orders Footer Trading page: Analysis Header Trading header Logout bouton Technical Analysis Fundamental analysis Footer Polytech Nice Sophia Antipolis SI4 AL/IMAFA 20

21 Screen shots of the real application: Polytech Nice Sophia Antipolis SI4 AL/IMAFA 21

22 Polytech Nice Sophia Antipolis SI4 AL/IMAFA 22

23 Gantt diagram: Polytech Nice Sophia Antipolis SI4 AL/IMAFA 23