SIMULATEUR DE MARCHE FINANCIER

Transcription

1 SIMULATEUR DE MARCHE FINANCIER HichemBostangi - Mohamed Fenina - Benjamin Guillet Arnaud Izard Génie logiciel & Base de données avancées Année Encadré par A.M. Hugues 1

2 Sommaire I. Présentation du projet... 3 II. Cahier des charges Généralités Acteurs Fonctionnalités... 4 a. Visiter le site... 4 b. Gérer le portefeuille... 7 c. Gérer le compte utilisateur Contraintes... 7 III. Définition du produit Diagramme de haut niveau Cas d utilisation : visiter le site Cas d utilisation : jouer a. Gérer le profil b. Gérer le portefeuille Cas d utilisation : mener IV. Analyse Diagramme ORM Réalisation du cas d utilisation : visiter le site Réalisation du cas d utilisation : jouer V. Conception Diagramme de classes Diagramme d états/transitions de la classe Ordre Maquette des écrans a. Page d accueil : b. Analyse technique : VI. Diagramme de déploiement VII. Gestion de projet Environnement de travail a. Visual Paradigm b. Microsoft Project c. Dropbox Gestionnaire de versions Gestion de projet a. Diagramme WBS b. Diagramme de GANTT c. Rapports d activités VIII. Annexes Classe «Carnet» permettant la gestion des ordres

3 I. Présentation du projet On se propose de réaliser un simulateur de salle de marchés utilisable par plusieurs joueurs et mené par un meneur de jeu. Chaque joueur possède un portefeuille, vide au départ, constitué de produits financiers. Chaque joueur a également un compte en banque géré par la banque où sera pris le montant de ses achats et reversé le montant de ses ventes. La gestion de ce compte ne fait pas partie du logiciel à fournir, le système de la banque est simplement consulté et informé des transactions sur le portefeuille. Chaque joueur se connecte au simulateur par le biais d un login et d un mot de passe. Les fonctionnalités proposées au joueur sont celles proposées à un trader intervenant sur le marché des actions/options (consultation du portefeuille et des cours du marché, achat, vente, <). On pourra vendre ou acheter une action/option selon différentes modalités : au prix du marché, ou bien à un prix déterminé à l avance, c est-à-dire au moment où le titre a un cours égal à celui prévu dans l ordre de vente ou d achat. On ne permet pas la vente à découvert. Le logiciel devra gérer un carnet d ordres mémorisant l ensemble des ordres de ventes et d achat pour chaque titre. Ce carnet est trié par ordre de prix de ventes/achats croissants, ainsi une transaction ne pourra se réaliser que lorsqu une contrepartie sera trouvée. Ce carnet d ordre est visible par les joueurs. Parmi les fonctionnalités proposées, on souhaite également fournir une aide à la décision sous la forme de graphes d analyse technique (chandeliers japonais, bandes de Bollinger<) L interface fournira une aide en ligne sur les produits et le vocabulaire financiers. Le meneur de jeu pourra introduire des discontinuités dans le modèle en simulant des évènements macro-économiques (crack boursier<). Pour cela on simulera des ordres d achats/ventes fictifs que le meneur de jeu lancera en cas de besoin. 3

4 II. Cahier des charges 1. Généralités Le but de ce projet est de réaliser une application disponible en ligne, permettant de simuler un marché financier, qui peut être utilisable par plusieurs joueurs. 2. Acteurs Les acteurs sont des entités externes au système qui interagissent avec lui. Dans notre cas de simulateur de marché, ceux-ci sont présentés comme suit : Internautes : Il existe différents types d internautes. Tous peuvent visiter le site et accéder au simulateur de marché. Tous les internautes ont également la possibilité de consulter une aide en ligne, les cours des actifs boursiers et les aides à la décision. En revanche, seuls les internautes en possession d un compte ont la possibilité de gérer un portefeuille, i.e. acheter ou vendre des produits financiers (actions et options). Il existe enfin un troisième type d'internaute : le meneur de jeu. Son rôle est de maintenir le système, d initialiser le marché, d introduire des discontinuités dans le modèle en simulant des événements macro-économiques. Contrairement au joueur inscrit sur le site, il ne possède pas de portefeuille. Banques : Les joueurs informent de leurs gains et pertes, et consultent via le simulateur leurs comptes en banque (capital de départ de euros pour tous les joueurs). 3. Fonctionnalités a. Visiter le site Aide en ligne L interface fournit une aide en ligne sur les produits et le vocabulaire financier. Elle se présente sous la forme d un mot accompagné de sa définition. Aide technique L interface fournit une aide à la décision sous la forme de graphes d analyse technique : 1 ) Chandeliers japonais: ils représentent le cours d'une valeur sur une période passée et sont supposés donner des indications sur le cours futur.le chandelier rouge représente un chandelier baissier (il est aussi souvent représenté en noir), tandis que le chandelier vert représente un chandelier haussier (il est aussi souvent représenté par un chandelier blanc). 4

5 Figure 1 : Exemple de chandeliers japonais Pour dessiner un chandelier japonais, il est nécessaire de connaître le cours d'ouverture, le cours de clôture, le plus haut ainsi que le plus bas de la journée. Un chandelier est composé d'un corps (partie large) et généralement de deux ombres (ligne verticale située en dessus et en dessous du corps). Un chandelier vert ou blanc signifie que la clôture a été faite en dessus du cours d'ouverture, à l'opposé, un chandelier rouge ou noir signifie que la clôture a été faite en dessous du cours d'ouverture. 2 ) Bandes de Bollinger : elles sont un outil d'analyse économique développées par John Bollinger. Elles sont utilisées en finance de marché pour des analyses techniques et permettent d'évaluer l'évolution probable de prix ou d'indices. Les bandes de Bollinger sont constituées de trois courbes, une courbe calculant la moyenne mobile des données sur N périodes, et deux autres courbes de part et d'autre de la moyenne mobile, situées chacune à une distance de deux fois l'écart-type sur les N périodes sur lesquelles on a calculé la moyenne mobile. Figure 2 : Bandes de Bollinger utilisées pour évaluer l'indice CAC40 sur un an 5

6 Si l'on admet l'hypothèse de la loi normale pour les valeurs, alors 95% des valeurs observées se trouvent statistiquement situées entre les deux bandes extrêmes. 3 ) RSI (Relative Strength Index):Proposé par J. Welles Wilder en 1978, le RSI est un indicateur avancé d'analyse technique. Il a vocation à repérer la puissance d'un mouvement (indiquer si le mouvement s'essouffle) et à indiquer si l'on est en situation de sur-achat ou de sur-vente. Sa formule est la suivante : RSI = 100 *100 / (1 + H / B)], ou autrement écrit: RSI = [H / (H + B)] * 100, avec les paramètres : H: moyenne des hausses (variations de cours positives) au cours des n derniers jours. B: moyenne des baisses (variations de cours négatives) au cours des n derniers jours. En pratique, lorsque le marché est très régulièrement en hausse ou en forte hausse, le RSI tend vers 100. En revanche, lorsque le marché est très régulièrement en baisse ou en forte baisse, le RSI tend vers 0. 4 ) MACD (de l anglais MovingAverage Convergence Divergence, ou convergence et divergence des moyennes mobiles) est un indicateur boursier qui consiste en l étude des graphiques de cours dans le but d'identifier les tendances et d'anticiper l'évolution des marchés. La MACD représente l'écart des moyennes mobiles aux cours, et sa courbe se trace sur le graphique de l'évolution du cours - en se fixant une ligne zéro de la MACD. Elle se calcule instantanément par la formule suivante : MACD = MME (Source, MME Courte) MME (Source, MME Long) où MME correspond aux moyennes mobiles. On utilise habituellement les moyennes mobiles à 12 et à 26 périodes. L'analyse de la MACD permet d'anticiper techniquement l'évolution des marchés. Ainsi, il est préconisé d'acheter lorsque la courbe de MACD rapide coupe à la hausse la ligne de signal lente, en effet, les croisements identifient les changements dans l'équilibre des pouvoirs entre haussiers et baissiers. À l'inverse, le franchissement à la baisse de la courbe de signal lente par celle de la MACD rapide est un signal de vente. Consulter les cours Les flux boursiers seront simulés par des modèles mathématiques qui fournissent les cours à intervalles réguliers. Ces modèles sont décrits dans le cours de mathématiques. Un meneur de jeu pourra initialiser le marché et d introduire des discontinuités dans le modèle en simulant des évènements macro-économiques. S inscrire et s authentifier 6

7 L inscription consiste à renseigner des informations telles que le nom, prénom et adresse e- mail. Ces informations seront vérifiées avant d être validées afin d éviter qu un internaute s inscrive plusieurs fois. Après validation, l'internaute choisit un login (sous réserve de disponibilité) et un mot de passe, qui lui permettront de s authentifier. C est une fois qu il s est authentifié que l internaute devient un joueur et a accès aux différentes fonctionnalités du simulateur. b. Gérer le portefeuille Consulter le portefeuille Chaque joueur possède un portefeuille, vide au départ, constitué d actions et d options. Une fois authentifié, le joueur peut à tout moment consulter son portefeuille. Passer un ordre Pour passer un ordre, le joueur doit entrer un certain nombre de paramètres. Les ordres d achat et de vente (sur un même actif) ne sont validés qu à partir du moment où les prix concordent. Le joueur ne pourra passer des ordres d achat que si son solde est suffisant car la vente à découvert n est pas autorisée. L ensemble des ordres d achat et de vente pour chaque actif sont répertoriés dans un carnet d ordres, visible sur l interface du jeu. Les ordres ne sont valables que pendant une journée. c. Gérer le compte utilisateur Une fois connecté, l'internaute peut modifier ses informations personnelles (nom, prénom et adresse ), ses informations bancaires (RIB) ainsi que son mot de passe. 4. Contraintes Chaque joueur ne possède qu un seul portefeuille, c est-à-dire que le triplet nom/prénom/adresse mail est unique. On ne peut s authentifier que lorsque l on est inscrit. Chaque information bancaire d un joueur correspond au Relevé d Identité Bancaire unique à un joueur. Un ordre n est valable que jusqu à la fin de la journée. Lorsque la banque met à jour les comptes, les ordres non validés sont alors supprimés. 7

8 III. Définition du produit 1. Diagramme de haut niveau Le diagramme de haut niveau sert à identifier les fonctionnalités principales du système ainsi que les acteurs (primaires et secondaires) qui interagissent avec celui-ci. Figure 3 : Diagramme de haut niveau 8

9 2. Cas d utilisation : visiter le site - Diagramme de cas d utilisation : Figure 4 : Diagramme du cas d'utilisation : "visiter le site" - Diagramme d activité(visitez le site) : Figure 5 : Diagramme d'activités : "Visiter le site" 9

10 - Scénarii Cockburn del UC «Visiter»: a. Scénario du sous cas d utilisation : «S authentifier» Acteur : Internaute non connecté. Pré condition : L internaute a choisi «s authentifier». Scénario primaire : 1. Un formulaire s affiche comportant les champs «Login» et «Mot de passe». 2. L internaute entre les informations demandées, il valide 3. Le login et le mot de passe sont corrects, ceci termine le scenario P1 Variantes : 3a. Le login est incorrect. Un message s affiche signalant l erreur, retour à la page d'accueil comportant un lien d'inscription ou d authentification. 3b. Le mot de passe est incorrect. Un message s affiche signalant l erreur ainsi qu un lien proposant de renvoyer le mot de passe par mail, retour à la page d'accueil. Post condition: L internaute est authentifié et peut commencer à jouer *L'internaute est limité à un nombre d'essais précis d'authentification. * L internaute peut à tout moment interrompre l opération et retourner à la page d'accueil. b. Scénario du sous cas d utilisation «S inscrire» Acteur: Internaute non connecté Pré condition: L internaute a choisi«s inscrire». Scénario primaire : 1. Un formulaire apparait comportant les champs «login», «mot de passe» et «confirmer mot de passe». 2. Le joueur remplit les champs et valide. 3. Le système vérifie l unicité du login. 4. Le login est unique, le système vérifie la concordance des champs «mot de passe» et «Confirmer mot de passe» 5. Les deux champs concordent. L opération est terminée. Variantes : 3a. L internaute n est pas encore inscrit et doit renseigner les champs «nom», «prénom» et «mail». 3b. La boite mail n existe pas, retour en 2. Post condition : Le login est créé. Un formulaire demandant de renseigner le nom, le prénom, le mail ainsi que le numéro de compte en banque s affiche. 10

11 c. Scénario du sous cas d utilisation : «Consulter les cours» Acteur : Joueur/Meneur/Internaute Pré condition : L utilisateur est connecté et a choisi de consulter les cours. Scénario primaire : 1. L utilisateur choisit une société à étudier 2. Le système affiche le nom, le montant du dernier échange, la variation du titre ainsi que les montants des ordres d achats et de ventes. Post condition : L utilisateur est connecté d. Scénario du sous cas d utilisation : «Consulter l aide» Acteur : Joueur/Meneur/Internaute Pré condition : L internaute est connecté sur la page d accueil. Scénario primaire : 1. Un glossaire s affiche. 2. L internaute cherche la définition dans la liste. 3. Il la trouve, l opération est terminée. Variantes : 3a. L internaute ne trouve pas le mot, il peut écrire un mail à l administrateur, pour lui suggérer de l ajouter. L opération est terminée. Post condition : L internaute est connecté. * L internaute peut à tout moment interrompre l opération. e. Scénario du sous cas d utilisation : «Consulter l analyse technique» Acteur : Joueur/Meneur Pré condition : L internaute est connecté sur la page d accueil. Scénario primaire : 1. Une page s affiche demandant à l utilisateur de sélectionner un actif dans la liste. 2. L internaute sélectionne un actif et une liste d indicateur apparait, l opération est terminée. Post condition : L internaute est connecté. 11

12 3. Cas d utilisation : jouer a. Gérer le profil - Diagramme de cas d utilisation : Figure 6 : Diagramme de cas d'utilisation : "Gérer le profil" 12

13 - Scenarii Cockburn de l UC «Gérer le profil»: a. Scénario du sous cas d utilisation «Modifier Coordonnées Bancaires» Acteur : Joueur Pré condition : Le joueur est authentifié et a choisi de modifier ses coordonnées bancaires Scénario primaire : 1. Le système affiche le RIB actuel 2. Le joueur entre son Relevé d Identité Bancaire. 3. Le joueur valide. 4. Le système sauvegarde le nouveau RIB Post condition : Le RIB est modifié Données : RIB b. Scénario du sous cas d utilisation «Consulter Solde» Acteur : Joueur Pré condition :Le joueur a choisi de consulter le solde Scénario primaire : 1. Le Système affiche la valeur actuelle du solde. Post condition : Le joueur a consulté le solde de son compte. Données : Solde c. Scénario du sous cas d utilisation «Modifier Informations Personnelles» Acteur : Utilisateur Pré condition: L utilisateur est authentifié. Scénario primaire : 1. Le joueur se rend sur la page de modification du compte personnel 2. Le Système affiche la valeur actuelle des informations personnelles 3. Le joueur édite ces valeurs. 4. Le joueur valide. 5. Le système enregistre les nouvelles informations personnelles Variantes : 5a. Le système ne valide pas les informations personnelles. Retour a 2. Post condition : Le joueur est authentifié Données : Informations personnelles (nom, prénom, mail, mot de passe, login). 13

14 b. Gérer le portefeuille - Diagramme de cas d utilisation Figure 7 : Diagramme de cas d'utilisation : "Gérer le portefeuille" - Diagrammes d activités (Gérer le portefeuille) Figure 8 : Diagramme d'activités : "Gérer le portefeuille" 14

15 - Scénarii Cockburn de l UC «Gérer le portefeuille» a. Scénario du sous cas d utilisation «Consulter le portefeuille» Acteur : Joueur Pré condition : Le joueur a choisi «consulter portefeuille» Scénario primaire : 1. Le système affiche une page comportant la liste des actifs rangés par ordre alphabétique qui indique le nom, le nombre d actifs dans le portefeuille, ainsi que le cours de ceux-ci et la valeur totale de tout le portefeuille 2. Le joueur accède à un ordre bien particulier où il trouve toutes ses variations de prix. Post condition : Le joueur est renseigné. Données : Actif en portefeuille(nom, nombre, cours), Ordre, valeur totale de tout le portefeuille b. Scénario du sous cas d utilisation «Entrer les paramètres de l ordre» Acteur : Joueur, Meneur Pré condition : L acteur a choisi «passer l ordre» Scénario primaire : 1. Le système propose de choisir entre action ou option. 2. L acteur choisit option. 3. Le système affiche un formulaire comportant les champs «Actif», «Quantité», et «prix» 4. L acteur remplit les champs. Variantes : 2a. L acteur choisit action et continue le reste des étapes comme pour celles de l option. Post condition : Le joueur a entré les paramètres mais l ordre n est pas encore passé Données : Actif (Nom, Quantité, prix), ordre, action, option 15

16 - Diagrammes d activités (Passer un ordre) Figure 9 : Diagramme d'activités : "Passer un ordre" c. Scénario du sous cas d utilisation «Vérifier les paramètres d achat» Acteur : Joueur, Meneur Pré condition: L acteur a entré les paramètres Scénario primaire : 1. Le joueur choisit «Acheter» 2. Le système consulte le solde du joueur 3. Le compte en banque est suffisamment fourni. Une demande de confirmation s affiche. 4. Le joueur entre son mot de passe pour confirmer. 5. Le mot de passe est correct, l ordre est enregistré. Variantes : 2.a l acteur est un meneur, passer à 4. 3.a Le compte n a pas un solde suffisant pour la somme précisée dans le formulaire, le système le signale, et il retape un nouveau solde cohérent. 5.a Le mot de passe est incorrect, l erreur est signalée, un lien s affiche proposant de rappeler le mot de passe. 5.b Après trois tentatives, l ordre est annulé, retour à 1. Post condition : L ordre est passé Données : mot de passe, solde, ordre. 16

17 d. Scénario du sous cas d utilisation «Vérifier les paramètres des ventes» Acteur : Joueur, Meneur Pré condition: L acteur a entré les paramètres de vente Scénario primaire : 1. Le joueur clique sur «Vendre» 2. Le système consulte le portefeuille. 3. Le portefeuille est suffisamment fourni. 4. Le joueur entre son mot de passe pour confirmer. 5. Le mot de passe est correct, l ordre est enregistré. Variantes : 2.a L acteur est un meneur, passer à 4. 3.a Le portefeuille n a pas l actif désigné en quantité précisée, retour à 3. 5.a Le mot de passe est incorrect, l erreur est signalée, un lien s affiche proposant de rappeler le mot de passe. Retour à 6. 5.b Après trois tentatives, l ordre est annulé, retour à 1. Post condition : L ordre est passé Données : Actif (Nom, Quantité, prix), joueur, mot de passe, ordre 4. Cas d utilisation : mener - Diagramme de cas d utilisation : Figure 10 : Diagramme de cas d'utilisation : "Mener" - Scenarii Cockburn de l UC «Mener»: a. Scénario du sous cas d utilisation «Introduire un ordre fictif» Cas d utilisation : Introduire un ordre fictif Pré condition : le meneur est authentifié Scénario primaire : 1. Le système affiche la page pour introduire un ordre. 17

18 2. Le meneur choisit le titre sur lequel il souhaite passer un ordre. 3. Le système affiche le carnet d ordre concernant ce titre. 4. Le meneur fixe la quantité de titres qu il souhaite acheter. 5. Le meneur fixe le prix d achat du titre. 6. Le meneur confirme sa transaction. 7. Le système valide l ordre ; 8. Le système met à jour le carnet d ordre du titre concerné. Variantes : 4a. Le meneur fixe la quantité de titres qu il souhaite vendre 5a. Le meneur fixe le prix de vente du titre. 7a. Le système ne valide pas l ordre. Retour en 2) Post condition : Le système est modifié. Données nécessaires : Ordres, titres b. Scénario du sous cas d utilisation «Changer l'échelle de temps» Cas d utilisation : Changer l'échelle de temps Pré condition : le meneur est authentifié Scénario primaire : 1. Le système affiche la page permettant de changer l'échelle de temps. 2. Le meneur choisit l'échelle de temps désirée. 3. Le meneur confirme son choix. 4. Le système valide le changement. 5. Le système met à jour la variable correspondant à l'échelle de temps. Variantes : 4a. Le système ne valide pas le changement. Retour en 2) Post condition : Le système est modifié. Données nécessaires : Echelles de temps disponibles 18

19 IV. Analyse 1. Diagramme ORM Nom a /est de a /est de a /est de U Prenom Mail Quantité a /est de a /est de Mot de passe Type Date d'emission a /est de a /est de a /est de Login Prix Unitaire a /est de a /est de Solde Joueur (ID Joueur) a /est de passe /est passé par RIB Achat Ordre (ID Ordre) Vente passe /est passé par "Portefeuille Actif" Meneur (ID Meneur) possède /appartient Code Actif Concerne /fait partie de possède /est le code de change /est changé par des /de Nombre Actif Portefeuille Actif (ID Actif) possède /est affecté à Prix Actif Echelle de temps Option Action concerne /est concerné de /a Nom Société coute /est la prime de se termine /est la date d'échéance Prime a pour strike /est le strike date d'echéance Prix d'exercice Figure 11 : Diagramme ORM 19

20 2. Réalisation du cas d utilisation : visiter le site - Diagramme de séquences du scénario : «S inscrire» - Diagramme de séquences du scénario : «S authentifier» 20

21 - Diagramme de séquences du scénario : «Consulter les cours» - Diagramme de séquences du scénario : «Consulter l analyse technique» - Diagramme de séquences du scénario : «Consulter l aide» 21

22 3. Réalisation du cas d utilisation : jouer - Diagramme de séquences du scénario : «Passer un ordre de vente» - Diagramme de séquences du scénario : «Passer un ordre d achat» 22

23 V. Conception 1. Diagramme de classes 2. Diagramme d états/transitions de la classe Ordre 23

24 3. Maquette des écrans a. Page d accueil : b. Analyse technique : 24

25 VI. Diagramme de déploiement 25

26 Remarques sur la base de données : La structure base de données est classique. L application gère les inscriptions/authentifications via une table joueur qui contient les informations personnelles. Le joueur se connecte avec un couple /mot de passe, et nous avons imposé l unicité sur l (On peut penser que l application s en sert pour envoyer des mails de confirmation au joueur, donc on ne peut pas avoir 2 joueurs avec la même adresse mail). Chaque table possède un champs ID, qui fait office de clé primaire (qui est donc utilisé pour les jointures). On spécifie dans les annotations JPA que la stratégie de génération est = GenerationType.AUTO) private Long id; On a alors pu remarquer que cela entraînait la création dans la base PostgreSQL d une table sequence qui gère ce mécanisme. Nous avons également utilisé les transactions pour garantir l intégrité de notre base de données à tout moment. Par exemple, lorsque 2 ordres correspondant sont associés, une transaction doit être persistée, les 2 ordres doivent être supprimés, et les soldes des joueurs doivent être mis à jour. Il fallait donc que cette série d action soit exécutée entièrement ou pas du tout, d où l utilisation des transactions : //On crée la transaction Transaction transaction = new ransaction(calendar.getinstance().gettime(),o.getprix(),o.getquantite(),joueur, o.getjoueur(), action); em.gettransaction().begin(); em.persist(transaction); em.remove(o); //On supprime l'ordre o.getquantite()); //On met a jour le solde des joueurs joueur.setsolde(joueur.getsolde() + o.getprix() * o.getquantite()); o.getjoueur().setsolde(o.getjoueur().getsolde() - o.getprix() * em.gettransaction().commit(); 26

27 VII. Gestion de projet 1. Environnement de travail a. Visual Paradigm Visual Paradigm est un logiciel d UML. Il nous a permit de générer tous les diagrammes utilisés lors du projet. b. Microsoft Project Microsoft Project est un logiciel de gestion de projet développé par Microsoft. Nous l avons utilisé pour planifier et suivre l avancement du projet, ainsi que pour produire les diagrammes de gestion de projet. c. Dropbox Dropbox est un outil de stockage et de partage de fichiers en ligne. Il a été utile pour permettre à chaque membre du projet de pouvoir disposer à tout moment des fichiers du projet. 2. Gestionnaire de versions Nous avons utilisé Subversion comme gestionnaire de versions. Cet outil, distribué sous licence Apache et BSD, est utilisable depuis l IDE NetBeans. Il suffit de cliquer sur le projet, de choisir Subversion, et l utilisateur peut choisir de mettre à jour les fichiers du projet comme de publier ses fichiers pour les autres membres du groupe de projet. 3. Gestion de projet a. Diagramme WBS 27

28 28

29 b. Diagramme de GANTT 29

30 c. Rapports d activités. Hichem Bostangi - Semaine 41: Découverte du sujet (2h) - Semaine 42: Rédaction du diagramme de cas d utilisation et du scénario Cockburn du sous cas d utilisation «visiter». (2h) - Semaine 43: Rédaction des diagrammes d activité (Visitez le site). - Semaine 44 : Rédaction de l ORM correspondant au sous cas d utilisation «visiter» ainsi que du rapport de projet. (4h) - Semaine 45 : Rédaction des diagrammes de séquences. (4h) - Semaine 46 : Elaboration d un algorithme pour l'affichage des chandeliers japonais. (8h) - Semaine 47 : Création des graphiques d évolution du cours de l'action et des chandeliers japonais. (4h) - Semaine 48 : Implémentation des outils de la classe «analysetechnique», «Courbe» et «Chandelier». (6h) Mohamed Fenina - Semaine 41: Découverte du sujet (2h) - Semaine 42: Rédaction des diagrammes des cas d utilisation concernant la gestion de portefeuille. (2h) - Semaine 43 : Rédaction des diagrammes d activité de consulter le portefeuille et passer l ordre. Rédaction de l ORM qui correspond à ces diagrammes d activité(2h) - Semaine 44 : Rédaction des diagrammes de séquences et d état-transition de la classe Ordre. (4h) - Semaine 45 : Rédaction du rapport (Gestion du portefeuille) - Semaine 46 : Elaboration d un algorithme pour le type d ordre et implémentation des outils de la classe «ordre» (10h) - Semaine 47 : Implémentation des outils de la classe «ordre» (8h). - Semaine 48 : Implémentation des outils de la classe «ordre» et élaboration de la présentation pour la soutenance (6h). Benjamin Guillet - Semaine 41: Découverte du sujet (2h) - Semaine 42: Rédaction du diagramme de cas d utilisation et du scénario Cockburn du sous cas d utilisation «mener». (2h) - Semaine 43: Rédaction de l ORM correspondant au sous cas d utilisation «mener» ainsi que du rapport de projet (4h) - Semaine 44 : Rédaction des diagrammes de séquences et d état-transition de la classe Ordre. (4h) 30

31 - Semaine 45 : Rédaction du rapport (Analyse technique & gestion de projet) (2h) - Semaine 46 : Création du site web (maquette) (5h) - Semaine 47 : Implémentation des outils «modifier les infos» et «lexique» (6h) - Semaine 48 : Rédaction du rapport et préparation de la soutenance (présentation Powerpoint) (5h) Arnaud Izard - Semaine 41: Découverte du sujet (2h) - Semaine 42: Création du sous cas d utilisation de «Gérer Profil». Création du diagramme d activité et des scénarios Cockburn associés.(2h) - Semaine 43: Création de l ORM et du DDL relatif au cas «Gérer le profil».(2h) - Semaine 44 : Implémentation de la base de données (4h) - Semaine 45 : Implémentation de la fonctionnalité d inscription (3h) - Semaine 46 : Implémentation de la récupération des ordres (4h) - Semaine 47 : Intégration des modules de chacun (5h) - Semaine 48 : Finitions Site (3h) VIII. Annexes 1. Classe «Carnet» permettant la gestion des ordres public class Carnet { private EntityManager em; private Action action; public Carnet (EntityManager em,action action){ this.em = em; this.action = action; } public Vector<Object[]> getordresachat(){ Query query = em.createnativequery("select count(*),sum(quantite),prix FROM Ordre WHERE type = 1 AND action_id = "+action.getid()+" GROUP BY ordre.prix ORDER BY prix DESC"); return (Vector<Object[]>) query.getresultlist(); } public Vector<Object[]> getordresvente(){ Query query = em.createnativequery("select count(*),sum(quantite),prix FROM Ordre WHERE type = 2 AND action_id = "+action.getid()+"group BY ordre.prix ORDER BY prix ASC"); return (Vector<Object[]>) query.getresultlist(); } public Vector<Object[]> getordresachat(joueur joueur){ Query query = em.createnativequery("select quantite, prix FROM Ordre WHERE type = 1 AND action_id = "+action.getid()+" AND joueur_id = "+joueur.getid()+" ORDER BY prix DESC"); 31

32 } return (Vector<Object[]>) query.getresultlist(); public Vector<Object[]> getordresvente(joueur joueur){ Query query = em.createnativequery("select quantite, prix FROM Ordre WHERE type = 2 AND action_id = "+action.getid()+" AND joueur_id = "+joueur.getid()+" ORDER BY prix ASC"); return (Vector<Object[]>) query.getresultlist(); } public void gererordre(double prix, int quantite,int type, Joueur joueur){ if(type == 1){//Passer un ordre d'achat /* On récupere les ordres de ventes ayant un prix inferieur ou égal * au prix de notre ordre, triés par quantité. */ Query findallvente = em.createnamedquery("ordre.findsellbylimitprice"); findallvente.setparameter("prix", prix); Vector<Ordre> ventes = (Vector<Ordre>) findallvente.getresultlist(); if( ventes.size() == 0 ){ // s'il n'y a pas de contrepartie adaptée, on persite l'ordre Ordre ordre = new Ordre(prix, quantite, Calendar.getInstance().getTime(), Calendar.getInstance().getTime(), type, action,joueur); em.gettransaction().begin(); em.persist(ordre); em.gettransaction().commit(); return; } for(int i = 0 ; i < ventes.size() ; i++){// On itère sur les ordres de ventes existants Ordre o = ventes.get(i); if (o.getquantite() < quantite){//si il n'y en a pas assez, //On crée la transaction Transaction transaction = new Transaction(Calendar.getInstance().getTime(),o.getPrix(),o.getQuantite(),joueur, o.getjoueur(), action); em.gettransaction().begin(); em.persist(transaction); em.remove(o); //On supprime l'ordre //On met à jour le solde des joueurs joueur.setsolde(joueur.getsolde() - o.getprix() * o.getquantite()); o.getjoueur().setsolde(o.getjoueur().getsolde() + o.getprix() * o.getquantite()); em.gettransaction().commit(); //On gère l'ordre avec une quantité plus faible gererordre(prix, quantite-o.getquantite(), 1, joueur) } else if (o.getquantite() == quantite){//si il y en a en quantité exacte //On crée la transaction Transaction transaction = new Transaction(Calendar.getInstance().getTime(),o.getPrix(),o.getQuantite(),joueur, o.getjoueur(), action); em.gettransaction().begin(); em.persist(transaction); em.remove(o); //On supprime l'ordre 32

33 o.getquantite()); * o.getquantite()); } //On met a jour le solde des joueurs joueur.setsolde(joueur.getsolde() - o.getprix() * o.getjoueur().setsolde(o.getjoueur().getsolde() + o.getprix() em.gettransaction().commit(); else if (o.getquantite() > quantite){//si il y en a en quantité supérieure //On crée la transaction Transaction transaction = new Transaction(Calendar.getInstance().getTime(),o.getPrix(),quantite,joueur, o.getjoueur(), action); em.gettransaction().begin(); em.persist(transaction); //On met à jour le solde des joueurs joueur.setsolde(joueur.getsolde() - o.getprix() * quantite); o.getjoueur().setsolde(o.getjoueur().getsolde() + o.getprix() * quantite); } //On met a jour la quantite pour l'ordre trouvé o.setquantite(o.getquantite() - quantite); em.gettransaction().commit(); } }//boucle sur les ordres de vente else if(type == 2){//Passer un ordre de vente /* On récupere les ordres d'achat ayant un prix superieur ou égal * au prix de notre ordre, triés par prix. */ Query findallachat = em.createnamedquery("ordre.findbuybylimitprice"); findallachat.setparameter("prix", prix); Vector<Ordre> achats = (Vector<Ordre>) findallachat.getresultlist(); if( achats.size() == 0 ){ // s'il n'y a pas de contrepartie adaptée, on persite l'ordre Ordre ordre = new Ordre(prix, quantite, Calendar.getInstance().getTime(), Calendar.getInstance().getTime(), type, action,joueur); em.gettransaction().begin(); em.persist(ordre); em.gettransaction().commit(); return; } for(int i = 0 ; i < achats.size() ; i++){// On itere sur les ordres de ventes existants Ordre o = achats.get(i); if (o.getquantite() < quantite){//si il n'y en a pas assez, //On crée la transaction Transaction transaction = new Transaction(Calendar.getInstance().getTime(),o.getPrix(),o.getQuantite(),joueur, o.getjoueur(), action); em.gettransaction().begin(); em.persist(transaction); em.remove(o); //On supprime l'ordre //On met a jour le solde des joueurs joueur.setsolde(joueur.getsolde() + o.getprix() * o.getquantite()); o.getjoueur().setsolde(o.getjoueur().getsolde() - o.getprix() * o.getquantite()); 33

34 //On gère l'ordre avec une quantité plus faible gererordre(prix, quantite-o.getquantite(), 2, joueur); em.gettransaction().commit(); } else if (o.getquantite() == quantite){//si il y en a en quantité exacte //On crée la transaction Transaction transaction = new Transaction(Calendar.getInstance().getTime(),o.getPrix(),o.getQuantite(),joueur, o.getjoueur(), action); em.gettransaction().begin(); em.persist(transaction); em.remove(o); //On supprime l'ordre em.gettransaction().commit(); //On met a jour le solde des joueurs joueur.setsolde(joueur.getsolde() + o.getprix() * o.getquantite()); o.getjoueur().setsolde(o.getjoueur().getsolde() - o.getprix() * o.getquantite()); em.gettransaction().commit(); } else if (o.getquantite() > quantite){//si il y en a en quantité supérieure //On crée la transaction Transaction transaction = new Transaction(Calendar.getInstance().getTime(),o.getPrix(),quantite,joueur, o.getjoueur(), action); em.gettransaction().begin(); em.persist(transaction); * quantite); } //On met a jour le solde des joueurs joueur.setsolde(joueur.getsolde() + o.getprix() * quantite); o.getjoueur().setsolde(o.getjoueur().getsolde() - o.getprix() //On met a jour la quantite pour l'ordre trouvé o.setquantite(o.getquantite() - quantite); em.gettransaction().commit(); } } } }//boucle sur les ordres d'achats 34

35 2. Réalisation d un chandelier Japonais Ci-dessous, un chandelier japonais issu de l analyse de données extraites de notre base (correspondant réellement aux actions des joueurs). Il se reporte à l action qui a eu le comportement suivant : 35

36 Il y a donc eu une transaction à l ouverture au prix de 20, puis une transaction a 15, et une transaction à la fermeture au prix de 22. Sur le diagramme des chandeliers japonais, la barre horizontale inferieure est le prix d ouverture, la barre horizontale supérieure est le prix de fermeture, et la barre verticale descend jusqu au minimum atteint dans la journée. Il n y a pas de barre verticale sur le dessus car le maximum atteint est le prix de fermeture. 36