ANALYSE DES EXIGENCES D UN JEU BOURSIER EN LIGNE ET

Dimension: px
Commencer à balayer dès la page:

Download "ANALYSE DES EXIGENCES D UN JEU BOURSIER EN LIGNE ET"

Transcription

1 Université de Fribourg, Suisse Département d'informatique Master en gestion d entreprise ANALYSE DES EXIGENCES D UN JEU BOURSIER EN LIGNE ET IMPLÉMENTATION D UN PROTOTYPE D AMÉLIORATION Travail de master Hélène Martenet Route de Choëx 93, 1871 Choëx 1 er rapporteur : Dr. Stefan Hüsemann 2 ème rapporteur : Prof. Dr. Martin Wallmeier Février 2009

2 Résumé I Résumé La BSU est une association d étudiants qui organise des simulations boursières sur Internet. Comme dans beaucoup d association d étudiants, très peu de temps est consacré à l analyse des processus et de l organisation ; il existe ainsi de grands gains d amélioration de l efficacité. Ce travail se concentre sur l amélioration du processus de configuration du jeu. Il aborde les thèmes de la logique financière régissant la simulation, l analyse du système, le recueil des exigences, la conception d une architecture trois couches stricte et l implémentation d un prototype d amélioration en utilisant le Framework.NET 3.5. Abstract The BSU is a student association which organizes Internet based stock exchange simulations. As in most student associations, very little time is devoted to process analysis and organization. Efficiency in this area can therefore be greatly improved. This work focuses on improving the game configuration process. It covers the topics of financial theory governing the simulation, system analysis, requirements engineering, the design of a strict three layered architecture and the implementation of a prototype of improvements using the.net 3.5 framework. Mots clés BSU, Simulation boursière, RUP, instruments financiers, LINQ to SQL, ASP.NET, Architecture en couches, MVC

3 Table des matières II Table des matières 1 INTRODUCTION Problématique Objectifs Façon de procéder LA LOGIQUE MÉTIER: DESCRIPTION DES DIFFÉRENTS OUTILS ET CARACTÉRISTIQUES À PRENDRE EN COMPTE POUR LA CONFIGURATION D UN JEU BOURSIER Portfolio Management Simulation (PMS) Concepts de la simulation Mesures de classification des joueurs Les marchés: SWX Swiss Exchange et Eurex SWX Swiss Exchange Eurex Les outils financiers Actions Obligations Exchange Traded Funds (ETF) Devises Options Les évènements boursiers pouvant perturber le jeu Split Fusion et acquisition Faillite... 28

4 Table des matières III 3 L ANALYSE D UN SYSTÈME D INFORMATION Méthodologie de gestion de projets: Rational Unified Process (RUP) RUP: une méthodologie de gestion de projet Recueil des exigences Analyse et conception Implémentation et test Techniques : Unified Modeling Language (UML) et Prototypage Unified Modeling Language (UML) Prototypage RECUEIL DES EXIGENCES DU SI BSU Analyse préliminaire Le produit: Spécification des exigences logicielles (Software Requirements Specification) Cadre Définitions, acronymes et abréviations Spécification du cas d utilisation (Use-Case Specification) Cas d utilisation UC2 Mettre le jeu en place ANALYSE ET CONCEPTION DU SI BSU Architecture actuelle du système d informations de la BSU Aperçu général Composantes actuelles utilisées lors de la configuration du jeu Conception souhaitée de l application Architecture en couches Model View Controller (MVC) Avantages et inconvénients d une architecture trois couches Conception de l application souhaitée en.net... 67

5 Table des matières IV Architecture en couches en.net Model View Controller en.net Couche de présentation Couche de logique métier Couche d accès aux données IMPLÉMENTATION ET TESTS Implémentation du prototype Le projet «BSUConfiguration» Le projet «BLL» Le projet «DAL» Le projet «Entities» Le projet «CommonObjects» Tests Introduction Cas de test Résumé des tests ANALYSE DU SYSTÈME CONÇU Analyse SWOT RÉSUMÉ ET CONCLUSIONS Résumé des résultats Perspective: d autres améliorations possibles du site de configuration Conclusions BIBLIOGRAPHIE ANNEXE

6 Table des illustrations V Table des illustrations FIGURE 1: LE SYSTÈME ÉLECTRONIQUE DE LA BOURSE SWX SWISS EXCHANGE [SCHNEIDER 2008]... 9 FIGURE 2: ORGANISATION DE LA SWISS [SWX 2008B] FIGURE 3 : L ORGANISATION DU SIX GROUP [SIXGROUP 2009A] FIGURE 4: EVOLUTION DES VOLUMES PAR SEGMENT DE PRODUITS (CONTRATS EN MILLION) [EUREX 2008] FIGURE 5: EVOLUTION DU COURS DE L ETF ISHARES DAX ET DE SON INAV [DEUTSCHEBÖRSE 2008] FIGURE 6: PAY-OFF DU DÉTENTEUR D'UN CALL [WIKIPEDIA 2008] FIGURE 7: PAY-OFF DU DÉTENTEUR D'UN PUT [WIKIPEDIA 2008] FIGURE 8: UNE PAGE DE RUP PERSONNALISABLE GRÂCE À RMC [IBM 2008A] FIGURE 9: VUE D'ENSEMBLE DES CONCEPTS CLÉ DE L'ARCHITECTURE UMA [IBM 2008A] FIGURE 10: LES ASPECTS DYNAMIQUES ET STATIQUES DU RUP [IBM 2008A] FIGURE 11: PATTERN DE CAPACITÉ RECUEIL DES EXIGENCES [IBM 2008A] FIGURE 12: PATTERN DE CAPACITÉ ANALYSE ET CONCEPTION [IBM 2008A] FIGURE 13: PATTERN DE CAPACITÉ IMPLÉMENTATION [IBM 2008A] FIGURE 14: PATTERN DE CAPACITÉ TEST [IBM 2008A] FIGURE 15: EXEMPLE D UN DIAGRAMME DE CAS D UTILISATION FIGURE 16: EXEMPLE D UN DIAGRAMME DE CLASSES FIGURE 17: LE DIAGRAMME «ADMIN» AVEC L UC «METTRE LE JEU EN PLACE» [SHEHU 2008] FIGURE 18: DIAGRAMME D ACTIVITÉS DU UC2 «MISE EN PLACE DU JEU» FIGURE 20: UNE ARCHITECTURE DE SÉCURITÉ EN COUCHES [PFLEEGER 1998, P. 201] FIGURE 21: TROIS TIERS [OLDBY ET DAN 2006] FIGURE 22: LES TROIS COUCHES CLASSIQUES [MITCHELL 2006] FIGURE 23: LE PATTERN MODEL VIEW CONTROLLER [MORTENSEN, MCGOVERN ET LIPTAAK 2003] FIGURE 24: LA COMPOSITION DU SYSTÈME EN DIFFÉRENTS PAQUETS FIGURE 25: PROTOTYPE PAPIER DE LA MISE EN PAGE GÉNÉRALE DU SITE FIGURE 26 : CONFIGURATION DU MENU «GÉNÉRAL» FIGURE 27 : CONFIGURATION DES SOUS-MENUS DE «TITRES» FIGURE 28: ORM FIGURE 29: DIAGRAMME D ENTITÉS FIGURE 30: LES CINQ PROJETS CRÉÉS DANS VS FIGURE 31 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET «BSUCONFIGURATION» FIGURE 32 : CAPTURE D ÉCRAN DU MENU «ACTIONS» FIGURE 33 : LA COMPOSITION DE LA PAGE «PERIODE» FIGURE 34 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET «BLL» FIGURE 35 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET «DAL» FIGURE 36 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET «ENTITIES» FIGURE 37 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET «COMMONOBJECTS» FIGURE 38 : LA MATRICE SWOT [WIKIPEDIA 2009]... 96

7 Table des illustrations VI Table des codes source CODE SOURCE 1 : PARTIE DU CONTENU DU FICHIER DAL.XML CODE SOURCE 2 : LES VARIABLES CURRENTSPIELVARIANTE ET SPIELVARIANTE DU BLL CODE SOURCE 3 : FONCTION UPDATING DÉCLENCHÉE LORS DE L ÉVÈNEMENT ONUPDATING CODE SOURCE 4 : FONCTION «SAVE» DU BLL CODE SOURCE 5 : L UTILISATION DE L ÉVÉNEMENT «ONITEMINSERTING» CODE SOURCE 6 : L IMPLÉMENTATION DE LA FONCTION GETALLDEVISEN() CODE SOURCE 7 : L IMPLÉMENTATION DE LA FONCTION DE MISE À JOUR DES DEVISES... 91

8 Table d abriéviations VII Table d'abréviations ADO.NET EF ADO.NET Entity Framework Ajax Asynchronous JavaScript and XML ASP Active Server Pages BLL Business Logic Layer BSU Börsenspiel der Schweizer Universitäten C# C Sharp c.à.d. c'est-à-dire CD Compact Disc CEF Consolidated Exchange Feed Cf. Confer DAL Data Access Layer DAX Deutscher Aktien IndeX DB DataBase DCF Discounted Cash-Flows DW Datawarehouse ETF Exchange Traded Fund ETL Extract Transform Load ETSF Exchange Traded Structured Fund EUREX European Exchange Ex. Exemple Forex FOReign EXchange HTML Hypertext Markup Language IBM International Business Machines ID Identifiant IIS Internet Information Services inav indicative Net Asset Value IT Information Technology LINQ Language Integrated Query

9 Table d abriéviations VIII MS MSTR MVC OLAP OMG OO ORM OTC PEX-MF PMS QMF RAD RMC RUP SECOM SI SIC SICAV SIX SLI SMF SMI SPEM SPI SQL SWOT SWX UC UMA UML URL Microsoft Microstrategy Model View Controller Online Analytical Processing Object Management Group Object Oriented Object Relational Mapping Over-the-counter Pan-European Exchange Market Feed Portfolio Management Simulation Quote Market Feed Rapid Application Developement Rational Method Composer Rational Unified Process Settlement Communication System Système d informations Swiss Interbank Clearing Sociétés d'investissement à capital variable Swiss Infrastructure and Exchange Swiss Leader Index Swiss Market Feed Swiss Market Index Software Process Engineering Metamodel Swiss Performance Index Structured Query Language Strengths Weaknesses Opportunities Threats Swiss Exchange Use Case Unified Method Architecture Unified Modeling Language Uniform Resource Locator

10 Table d abriéviations IX VB VM VS XML XP Visual Basic Virtual Machine Visual Studio extensible Markup Language extreme Programming

11 1. Introduction 1 1 Introduction 1.1 Problématique L Université de Fribourg a la chance de compter parmi ses associations estudiantines la Börsenspiel der Schweizer Universitäten (BSU). Cette association à but non-lucratif fondée en 1991 organise chaque année divers jeux de simulation boursière sur Internet, dont l un réservé aux étudiants des Hautes Ecoles et Universités Suisses. Cette simulation permet aux étudiants de se familiariser avec les marchés financiers et de faire le lien entre la théorie enseignée aux cours et la pratique. Pour organiser une telle simulation, il faut un groupe d étudiants motivés, qui aient des connaissances et de l intérêt tant dans le domaine de la gestion (surtout de la finance) que dans celui de l informatique. Il est aussi nécessaire d avoir une infrastructure informatique performante qui soit compréhensible non seulement par des informaticiens, mais aussi par des gestionnaires. En effet, souvent, des gestionnaires doivent s occuper de certaines parties de la configuration du jeu comme par exemple: insérer les noms des valeurs et des devises choisies pour le jeu dans la base de données, rentrer les taux d intérêts utilisés pour calculer le classement des joueurs, etc. Ce sont des tâches qui, dans l état actuel de l architecture de BSU, demandent à la personne des connaissances de finances et d informatique. Il en va de même pour la partie de la configuration du jeu qui peut être exécutée seulement par des informaticiens ou personnes avec de bonnes connaissances informatiques : il y aurait un grand gain d efficacité si elle pouvait être faite depuis un seul endroit de l architecture BSU et par une seule personne sans connaissances approfondies de l application. En général, dans les associations d étudiants, très peu de temps est consacré à l analyse des processus et de l organisation; de plus, il existe très peu de documentations des tâches à accomplir et des logiciels. La BSU ne faisant pas exception à la règle, elle possède un grand potentiel d améliorations dans quelques uns de ces processus, notamment dans la procédure de configuration du jeu. Ce présent travail se concentrera donc sur l analyse de cette dernière, des fonctionnalités requises à l intérieur du processus, de la formulation des exigences en découlant, de l implémentation d un prototype d amélioration et de l évaluation de ce dernier.

12 1. Introduction Objectifs L objectif de ce travail est d apporter une réponse aux questions scientifiques suivantes : Quels sont les différents outils financiers et caractéristiques financières à prendre en compte pour la configuration d'un jeu boursier? Comment procéder pour entreprendre un changement dans le système d'information d'une entreprise? Quelles fonctionnalités sont attendues par les parties prenantes pour configurer le jeu? Quels bénéfices peut apporter une architecture en trois couches dans la conception du nouveau système? Quelles technologies devraient être utilisées pour concevoir le système? Est-ce que la nouvelle interface est bénéfique à une meilleure configuration du jeu? Le traitement de ces questions permettra d analyser la procédure de configuration des jeux de la BSU de manière systématique et globale. Ainsi, un prototype d amélioration viable pourra être proposé. 1.3 Façon de procéder Le paradigme de recherche appliqué à ce travail correspond à celui de science de la conception (en anglais design science). Selon [March et Smith 1995], la notion de «science» en technologies de l'information et de la communication (IT, Information Technology) possède une nature duale : elle est composée de la science naturelle, dont le but est d expliquer le pourquoi et le comment des choses, et de la science de la conception, qui, elle, s intéresse à la «création de produits pour atteindre des buts». Contrairement à la science naturelle, la science de la conception ne présente pas de théories, mais elle s efforce plutôt à créer des concepts, des modèles, des méthodes et des implémentations qui soient de valeur. Ses deux activités principales de recherche sont le développement et l évaluation des produits. Comme [March et Smith 1995] le décrit encore, d importantes difficultés en science de la conception proviennent du fait que la performance d un produit dépend fortement de l environnement dans lequel il opère. Dans cette optique, ce présent travaille tentera de fournir une compréhension la plus complète possible de l environnement de la BSU et offrira, dans le chapitre 2, une description détaillée de son monde financier.

13 1. Introduction 3 La méthodologie de gestion de projet Rational Unified Process (RUP) sera utilisée tout au long de la partie de développement du produit. La description de ce processus constituera le thème du chapitre 3. Au chapitre 4 les exigences par rapport au système seront décrites. Elles correspondent aux fonctionnalités requises par le processus de configuration du jeu et constituent un point très important du développement logiciel [Chaos 2001]. Le chapitre 5 décrira l architecture actuelle et désirée du système d information (SI) de la BSU. Les inconvénients et avantages de l architecture désirée seront analysés et sa conception sera détaillée. Les détails de l implémentation et les résultats des tests seront dévoilés au chapitre 6. Finalement, l évaluation du système déterminera si le remplacement du système actuel de la BSU par celui créé lors de ce présent travail constitue un progrès ou non.

14 2. La logique métier 4 2 La logique métier: description des différents outils et caractéristiques à prendre en compte pour la configuration d un jeu boursier Avant de s occuper de la partie technique et de l implémentation d un projet informatique, il est indispensable de s attarder sur la logique métier de celui-ci. Dans le cas de la BSU, la connaissance des principes boursiers sous-jacents à la simulation revêt une importance majeure. Les administrateurs du jeu doivent être familiers, non seulement avec la logique métier implémentée par le programme BSU, mais aussi avec la réalité boursière suisse. En effet, pour des raisons de simplification, cette dernière diffère sur quelques points de celle modélisée dans l application BSU. Il en résulte qu un administrateur averti devrait être conscient de ces différences pour bien configurer la simulation. Dans ce but, ce deuxième chapitre, présente une description pratique du savoir boursier nécessaire et une confrontation directe avec l implémentation faite par la BSU. Il répond à la question: quels sont les différents outils financiers et caractéristiques financières à prendre en compte pour la configuration d'un jeu boursier? Certaines informations utilisées dans ce rapport concernant la BSU proviennent d interviews réalisées auprès des administrateurs et de l analyse du programme même de calcul du jeu (Programme «PMS Administration» cf. chapitre 5.1). 2.1 Portfolio Management Simulation (PMS) Concepts de la simulation La simulation organisée par la BSU pour les étudiants des Hautes Ecoles suisses s appelle Portfolio Mangement Simulation (PMS). Pendant huit semaines, les joueurs gèrent une fortune initiale de CHF un million et peuvent investir dans des instruments financiers décrits dans le chapitre 2.3. Les ordres passés durant la journée sont exécutés aux cours de clôture du jour.

15 2. La logique métier 5 Les participants possèdent deux portefeuilles: 1. un portefeuille, dit Classic, avec une limitation d achat d options à 5% de la valeur du portefeuille à l achat. Deux classements sont calculés sur ce celui-ci: Performance: seule la rentabilité obtenue sur toute la période du jeu compte, Risk Management: rentabilité et risque sont pris en compte grâce au ratio de Sharpe (cf. chapitre 2.1.2). 2. un portefeuille, dit Derivative, constitué seulement d options Eurex: un seul classement Derivative est calculé sur ce portefeuille selon la rentabilité [BSU 2008] Mesures de classification des joueurs Pour établir les classements discutés à la section précédente, il est nécessaire de disposer de deux mesures différentes: l une prenant en compte seulement la rentabilité, l autre combinant cette dernière avec le risque. Rentabilités simples Les rentabilités dites simples ou arithmétiques sont mesurées comme suit: Gain Capital ou Perte R fin ou Investi R fin P fin P P début début où R fin est la rentabilité simple sur la période de jeu; P fin et P début sont les prix du portefeuille à la fin, respectivement au début de la période de jeu [Aftalion 2003, p. 12]. Pour calculer les classements Performance et Derivative, les rentabilités simples pour chacun des portefeuilles sont calculées. Le joueur avec la plus haute rentabilité gagne [BSU 2008]. Sharpe ratio De par sa nature, la simulation boursière contient un biais par rapport à une gestion de portefeuille réelle: comme l argent est fictif, les investisseurs ont une moins grande aversion au risque. Pour remédier à cette distorsion, une mesure de performance prenant en compte non seulement la rentabilité, mais aussi le risque doit être utilisée. Plusieurs mesures existent pour prendre en compte le risque dans les calculs de performance. Le ratio de Sharpe, Treynor et l alpha de Jensen en sont des exemples classiques [Steiner et Bruns 2002, pp ]. A la BSU, c est sur la base du ratio de Sharpe que le classement Risk Management est réalisé [BSU 2008].

16 2. La logique métier 6 Le ratio de Sharpe est la mesure la plus utilisée par l industrie des fonds de placements aux USA. Sa définition ex-post est la suivante: SR PF R PF σ PF R f Où R PF est la rentabilité mesurée du portefeuille PF, R f est le taux d intérêt sans risque, σ PF est la volatilité des rentabilités du portefeuille. SR PF indique la rentabilité reçue en excès du taux sans risque, par unité de risque. Plus le ratio est élevé, meilleure est la rémunération du risque pris par l investisseur, donc meilleure est sa performance. La volatilité est la mesure de risque utilisée ici [Steiner et Bruns 2002, pp ]. Plusieurs limites importantes pour la BSU doivent être observées lors de l utilisation de ce ratio. Premièrement, le ratio de Sharpe dépend du taux d intérêt sans risque utilisé. Plusieurs classements différents peuvent ainsi en résulter; d où l importance du choix du taux d intérêt sans risque. Deuxièmement, les ratios de Sharpe non-positifs et nuls sont inutilisables. Il est en effet possible que la rentabilité d un portefeuille soit inférieure ou égale au taux sans risque. Un classement des portefeuilles par ordre de grandeur de leur ratio de Sharpe conduirait à un résultat erroné [Aftalion 2003, pp ]. Calcul du classement à la BSU A la BSU, le taux d intérêt sans risque utilisé est le taux Libor à 1 mois. Il est actualisé une fois, au début de chaque jeu. La variance est, quant à elle, calculée par le programme à l aide des rentabilités simples journalières des portefeuilles des joueurs. L utilisation des rentabilités simples dans la formule classique de la variance (la formule utilisant une moyenne arithmétique) donne lieu à des erreurs systématiques qui sont généralement d une ampleur moindre. En pratique, cela est fait relativement souvent pour des questions de simplification [Isakov 2006]. L utilisation de rentabilités instantanées serait toutefois plus exacte pour calculer la variance des rentabilités. Une rentabilité instantanée est une rentabilité continûment composée [Hickman, Hunter et Byrd 2002, p. 111]. Elle présente l avantage d être additive et de pouvoir ainsi calculer la variance grâce à une moyenne arithmétique et non géométrique [Hamon 2004, pp ].

17 2. La logique métier Les marchés: SWX Swiss Exchange et Eurex L organisation d une simulation boursière dépend beaucoup des données financières disponibles. Celles utilisées à la BSU proviennent du Financial Quote Service (FQS) 1. FQS est un service de SWX Swiss Exchange qui permet de recevoir les données financières relatives aux titres côtés à SWX Swiss Exchange, SWX Europe, Scoach et Eurex; les données concernant les indices boursiers et les devises sont aussi accessibles [SWX 2008a]. La BSU n utilise actuellement pas de données du marché de produits structurés Scoach, pour cette raison, ce chapitre se concentrera sur SWX Swiss Exchange et Eurex SWX Swiss Exchange Elle est l une des premières bourses entièrement électroniques du monde. Depuis 1996, son système se charge de l envoi de l ordre jusqu au règlement final selon les techniques les plus modernes. Les agents de change ne négocient plus à la criée, mais rentrent leurs opérations dans des ordinateurs installés dans les banques [Novello 2007, p. 84]. Bourse électronique La bourse électronique offre des avantages non négligeables: La liquidité y est accrue, c est-à-dire la probabilité pour un vendeur de trouver un acheteur est plus grande. Il existe une plus grande transparence: tous les cours payés et négociés sont connus; le marché est ainsi visible dans sa totalité. Grâce à la rationalisation des procédures, les coûts de transaction sont moindres. Le négoce est permanent sur tous les titres en quantités illimitées durant toute la journée d ouverture de la bourse [Schneider 2008]. Le négoce à la SWX Swiss Exchange est centralisé et organisé en fonction des ordres («order-driven market»). Ce qui veut dire que la liquidité dans ce marché est garantie par les ordres individuels et ne nécessitent pas de market-making, contrairement à Eurex (cf. chapitre 2.2.2) [SWX 2008b]. 1 FQS détient lui-même ses données des sources Swiss Market Feed (SMF), Quote Market Feed (QMF), Pan- European Exchange Market Feed (PEX-MF), et Consolidated Exchange Feed (CEF). Pour plus d informations cf. SWX (2008a) Financial Quote Service. (dernière consultation: ).

18 2. La logique métier 8 La figure 1 montre le système électronique de la Bourse SWX Swiss Exchange: Le système des négociants est mis à disposition de toutes les banques, suisses et étrangères, pratiquant le négoce commercial des valeurs mobilières et étant admises comme participants associés par la SWX Swiss Exchange [Schneider 2008]. Grâce à cette infrastructure technique indispensable, les agents de change peuvent participer aux opérations [Novello 2007, p. 46]. Le système de la Bourse envoie les informations nécessaires pour le négoce au Système des négociants. Il récolte les ordres d achat et de vente dans un carnet d ordres central et procède au matching d après des règles bien précises [Schneider 2008]. Le Gateway est un portail ou filtre qui a pour fonction d assurer un traitement équitable de tous les membres participants à la Bourse et assure une fonction de sécurité du réseau entre le Système des négociants et le Système de la Bourse [Schneider 2008]. Le Settlement Communication System (SECOM) et le Swiss Interbank Clearing (SIC) sont responsables du settlement (liquidation), respectivement du clearing (compensation). Les transactions sont automatiquement transmises du Système de la Bourse au SECOM et SIC [UBS 2008]. Le Swiss Market Feed (SMF) recense toutes les données du marché en temps réel des titres négociés à la SWX Swiss Exchange [Exfeed 2008]. Il est une des sources du FQS.

19 2. La logique métier 9 Figure 1: le Système électronique de la Bourse SWX Swiss Exchange [Schneider 2008] Organisation de la SWX Swiss Exchange La figure 2 illustre l organisation de la SWX décrite ci-après. SWX Swiss Exchange fait partie à 100% de la division du négoce au comptant (Cash Market Division) 1 du Swiss Financial Market Services AG et offre trois catégories de véhicules d investissement. Celles-ci sont négociées respectivement sur: le marché des actions: actions, parts sociales, bons de participation, bons de jouissance (cf. chapitre 2.3.1) [SWX 2008b]; le marché des emprunts (Bonds): Obligations d'emprunt (straight bonds), Obligations à taux variable (floating rate bonds), Obligations à coupon zéro (zerobonds), Emprunts à double monnaie, Emprunts de rang postérieur, Obligations convertibles (convertible bonds), Emprunts à option et Loan Participation Notes (cf. chapitre 2.3.2) [SWX 2008b]; 1 Une opération au comptant se caractérise par le fait que la conclusion du contrat, la livraison des titres et le paiement ont lieu en même temps, contrairement aux opérations à terme où la livraison et le paiement n ont pas lieu immédiatement à la conclusion du contrat, mais à une date ultérieure fixée à l avance.

20 2. La logique métier 10 le marché des Exchange Traded Funds (ETF), Exchange Traded Structured Funds (ETSF) et des fonds de placement: fonds de placement et fonds individuels, ETFs, ETSFs et sociétés d'investissement à capital variable (SICAV) (cf. chapitre 2.3.3) [SWX 2008b]. Sur le marché des actions de la SWX Swiss Exchange sont traités tous les titres à l exception des titres SMI/SLI. Ces derniers sont négociés sur SWX Europe qui est la bourse helvético-britannique des titres et des ETFs leaders en Europe. SWX Europe est détenue à 100% par SWX Swiss Exchange [SWXEurope 2009]. Depuis le 1er janvier 2007, tous les produits dérivés admis à la SWX Swiss Exchange sont traités sur la plateforme boursière de Scoach. Cette dernière est la première Bourse européenne de produits structurés; Warrants et certificats y sont aussi négociés. Un produit structuré est une combinaison de deux ou plusieurs instruments financiers dont au moins un est un dérivé constituant ainsi un nouveau produit de placement [UBS 2008].Scoach a été crée par Deutsche Börse et SWX Swiss Exchange. L un des plus grands marchés à terme du monde, Eurex, est aussi détenu par les bourses suisse et allemande. Ainsi, SWX Swiss Exchange joue un rôle de premier plan dans les produits dérivés (cf. chapitre 2.2.2) [Novello 2007, p. 85]. Les grands fournisseurs européens d'indices que sont Stoxx et Swiss Fund Data font aussi partie du groupe SWX avec Exfeed, qui est la société responsable des données de marché de la SWX Swiss Exchange et de SWX Europe[SWX 2008b]. Les autres entités du groupe sont SIS Group qui est chargée du traitement et du dépôt des valeurs mobilières suisses et étrangères [SIXSIS 2008] et Telekurs qui est actif dans les domaines des informations financières internationales, des opérations de paiement par cartes et des systèmes des paiements électroniques [Telekurs 2008b].

21 2. La logique métier 11 Figure 2: Organisation de la SWX [SWX 2008b] SWX Swiss Exchange est devenu SIX Swiss Exchange Entre le temps de l écriture et du dépôt de ce présent travail, des changements importants dans la dénomination et l organisation de la SWX on été réalisés. L auteur a jugé nécessaire de les mentionner ci-après. En janvier 2008, SWX Group, SIS Group et Telekurs Group avaient finalisé leur fusion et lancé Swiss Financial Market Services AG dont l organisation a été décrite ci-dessus [Telekurs 2008a]. Le 21 août 2008, Swiss Financial Market Services AG a informé qu'elle allait porter le nom de SIX Group AG, marque faîtière qui signifie Swiss Infrastructure and Exchange (SIX) [SIXGroup 2008b]. La figure 3 illustre l organisation du Group SIX (anciennement Swiss Financial Market Services). Les domaines d activité du groupe sont répartis en négoce de titres, règlement et garde de titres (services titres), acquisition et traitement d informations financières ainsi que trafic des paiements [BankingToday 2009]. Le changement de noms des entreprises consiste à faire précéder les anciens noms des entreprises de l abréviation SIX : SWX Swiss Exchange devient alors SIX Swiss Exchange, Exfeed devient SIX Exfeed, Telekurs devient SIX Telekurs. Les sociétés de l ex-sis Group sont désormais officiellement appelées comme suit : la SIS SegaInterSettle AG devient SIX SIS SA, SIS x-clear AG devient SIX x-clear, SAG SIS Aktienregister AG devient SIX SAG SA etc. [SIXGroup 2008a]. SIX Telekurs se concentre désormais dans l acquisition, le traitement et la diffusion d informations

22 2. La logique métier 12 financières internationales. Ses activités dans le domaine des paiements sont réorganisées dans le domaine d activité des paiements du SIX Group [SIXTelekurs 2009]. Figure 3 : L organisation du SIX Group [SIXGroup 2009a] Conséquences pour la BSU Ce changement d organisation de la Bourse suisse montre à quel point il est important pour la BSU de connaître son environnement financier. En effet, lors des changements mentionnés ci-dessus, le service utilisé pour importer les cours (FQS) a également était modifié, incitant les membres de la BSU à effectuer des changements dans leur programme d importation des cours (cf. chapitre 5.1). Les types d ordres Il existe plusieurs types d ordres possibles à la Bourse: ordre normal (normal order) : c est l ordre le plus fréquent. Il peut être passé en indiquant une limite de cours (ordre limité) ou sans indication de cours (au mieux) [Schneider 2008].Si l ordre ne peut pas être matché, il reste dans le système jusqu'à ce qu'il puisse être exécuté [SIXGroup 2009b](la validité maximale d un tel ordre est d un an) [Schneider 2008].

23 2. La logique métier 13 ordre avec quantité cachée (hidden size order) : il est passé en ne dévoilant qu une partie de la quantité totale ; l autre partie reste cachée. Un code spécial indique aux négociateurs qu il s agit d un ordre avec quantité cachée. Ce type d ordre est utilisé si un négociateur veut exécuter un ordre de taille importante, sans pour autant en dévoiler le volume total aux autres participants du marché. Il peut être passé au mieux ou assorti d une limite de cours [Schneider 2008]. ordre d acceptation (accept order) : il n existe pas de différences fondamentales avec un ordre normal, si ce n est que l ordre d acceptation est exécuté en quelques secondes [SIXGroup 2009b]. Si les volumes offerts sont insuffisants, il n est exécuté que partiellement et le reste de l ordre est immédiatement annulé après son introduction dans le système. S il n y a pas de matching, il n est tout simplement pas exécuté [Schneider 2008]. Le risque est donc que le négociateur reçoive (ou vende) moins de titres que ce qu il souhaite [SIXGroup 2009b]. Ce type d ordre est utile pour accepter un ordre qui se trouve déjà dans le système. Il peut être passé au mieux ou assorti d une limite de cours [Schneider 2008]. ordre fill-or-kill : il constitue une évolution de l'ordre d'acceptation [SIXGroup 2009b]. Soit la totalité des actions demandées peut être achetées en une seule fois, soit l ordre est immédiatement annulé. Il n existe pas d'exécution partielle. Il peut être passé au mieux ou assorti d une limite de cours [Schneider 2008]. ordre à condition (conditional order) : Cet ordre n est exécuté que lorsque le cours du marché atteint le prix de déclenchement (trigger price) préétabli par le négociateur [Schneider 2008]. Il n est transmis au système de la Bourse qu à ce moment là. Dans l'intervalle, il est enregistré localement dans le système de la banque. Cet ordre est utile pour se prémunir des fluctuations de cours en cas d'absence. Il peut être passé au mieux ou assorti d une limite de cours [SIXGroup 2009b]. Les types d ordres à la BSU Pour l instant, les participants à la simulation peuvent seulement passer des ordres «au mieux. Dans le contexte de la BSU, les ordres normaux et les ordres à condition sont intéressants. Dans [Shehu 2008], la possibilité d ajouter des ordres limités au jeu de la BSU a été analysée, elle n est à ce jour pas encore implémentée.

24 2. La logique métier 14 Les commissions et taxes des opérations boursières Les opérations boursières portent les coûts suivants: Courtage: commission que les banques facturent à leurs clients comme prestation de services pour l exécution d ordres boursiers. Chaque banque fixe individuellement son taux. [Zindel 2008] présente une comparaison des frais de courtage appliqués en Suisse en mai Il en ressort qu il existe une grande variation d un établissement bancaire à un autre. Timbre fédéral (droit de timbre de négociation): taxe versée si l un des contractants ou des intermédiaires est un commerçant de titres. Taxe boursière SIX Swiss Exchange : Taxe boursière versée par la banque à la SIX Swiss Exchange. Chaque segment de produit a son tarif de négoce spécifique [Schneider 2008]. Frais à la BSU A la BSU, par simplification, seulement des frais de courtage sont perçus. Les droits de garde ou commissions d'administration, qui sont des frais de gestion perçue par les banques pour conserver les titres en en dépôt, ne sont pas pris en compte non plus Eurex Eurex est l une des bourses de produits dérivatifs leader dans le monde. Elle est une société anonyme détenue à parts égales par Deutsche Börse AG et SIX Swiss Exchange. Son système de bourse électronique lui permet d offrir une large palette de produits internationaux à des coûts relativement avantageux [Novello 2007, p. 151]. La figure 4 illustre l augmentation du nombre de contrats par segment de l année 1999 à 2008 à l Eurex. L évolution de la bourse Eurex suit celle du marché mondial des produits dérivés traités sur des marchés organisés. En effet, comme documenté dans [Novello 2007, p. 150] ce marché «ne connaît pas la crise» et poursuit sa croissance depuis le début du millénaire.

25 2. La logique métier 15 Figure 4: Evolution des volumes par segment de produits (contrats en million) [Eurex 2008] Spécificité du marché des dérivés Par rapport à la SIX Swiss Exchange, Eurex possède quelques spécificités dues à la nature de ses opérations à terme. L une des plus grandes différences est qu Eurex est un marché avec une structure hybride, aussi appelée «quote-and-order-driven-market». Cela signifie que tous les investisseurs peuvent annoncer des prix auxquels ils sont prêts à acheter et vendre («order»); mais en plus, des acteurs spéciaux du marché, nommés «market-makers», doivent faire leurs offres («quotes») pour des produits pour lesquels ils sont responsables [Ranaldo 2007]. Les ordres et les quotes sont insérés tout au long de la journée de négoce dans le carnet d ordre central, où le matching est réalisé [Eurex 2008]. Les market-makers, souvent des employés de banques internationales d investissement, sont obligés, lorsqu ils reçoivent une demande, de soumettre un cours d achat et de vente. Cette demande est appelée «Quote Request» et est, de nos jours, en général, entièrement traitée

26 2. La logique métier 16 par voie informatique: le négociant rentre dans l ordinateur les paramètres requis et le système calcule le prix. L existence de market-makers assure ainsi de la liquidité au marché [Eck, Langer et Riechert 2006, p. 15]. Une autre grande différence de Eurex par rapport à un marché au comptant est l existence de la chambre de compensation (Clearing House). Celle-ci donne l assurance à l acheteur que le contrat sera accompli. Elle gère toutes les transactions, tient les comptes et réalise les appels de marge. Ces derniers sont un mécanisme qui assure que l investisseur ne fera pas défaut si, par exemple, une option devait être exercée par l acheteur [Hull 2003, p. 28]. Le mécanisme de l appel de marge fonctionne comme suit: si un investisseur a vendu par exemple des options, la structure du contrat fait que les flux de trésorerie seront nuls ou négatifs à la date d exercice. Pour se prémunir de ce risque futur, un montant de garantie (la marge) devra être versé sur un compte de dépôt [Eck, Langer et Riechert 2006, p. 102]. Après chaque clôture de bourse, les positions des investisseurs sont évaluées («marked to market») et la marge doit être adaptée en conséquence [Eck, Langer et Riechert 2006, p. 14]. Si l investisseur a acheté une option, ses flux de trésorerie seront nuls ou positifs; il n aura donc pas besoin de constituer une garantie [Hull 2003, p. 163]. Les prix utilisés pour évaluer les positions des investisseurs s appelle cours de compensation (daily settlement price). Le daily settlement price est calculé par Eurex chaque soir grâce au modèle binomial de Cox/Ross/Rubinstein d évaluation d options pour les options sur actions et grâce au modèle de Black/ Scholes 76 pour les options sur indice [Eurex 2008]. Conséquences pour la BSU Ces spécificités de Eurex sont importantes pour la simulation de BSU pour plusieurs points. Premièrement, grâce au market-makers et au daily settlement price, il est possible d avoir un cours (d achat et de vente) tous les jours et une évaluation de l option à chaque clôture de bourse, même si elle n a pas été négociée durant la journée. Ceci rend possible la négociation d option dans la simulation même lorsqu aucun contrat à la bourse Eurex n aura été conclu et qu en conséquence aucun cours de clôture ne sera disponible. Les organisateurs de la BSU évaluent les options, dans ce cas, au prix du daily settlement price. Deuxièmement, actuellement, il n est possible que d acheter des options Eurex dans la simulation BSU. Il n est donc pas nécessaire de prendre en compte l appel de marge pour la simulation.

27 2. La logique métier 17 Les produits négociés à l Eurex Eurex offre une large palette de produits dérivés sur les taux d intérêts, les actions, les indices d action, les indices de volatilité, les ETFs, les crédits, l inflation et le CO2. De plus, l offre de produits ne cesse de grandir. De tous les instruments, les futurs et les options sont les plus négociés [Eurex 2008]. Les produits Eurex négociés à la BSU Pour la simulation de BSU, seulement les options sur action et sur indices sont utilisées actuellement. A l Eurex les options sur action sont de type américain. Les options sur indice sont le plus souvent de type européen [Schneider 2008]. Comme à la BSU, les options ne peuvent pas être exercées, leur type ne représente pas de différence (cf. chapitre 2.3.5). Types d ordres A l Eurex, il existe plusieurs types d ordre: market-order, ordre avec limite, stop et combination [Eurex 2008]. Types d ordres à la BSU A la BSU, seul l ordre market-order existe; c est-à-dire l ordre est exécuté de toutes façons quelque soit le prix. Dans [Shehu 2008], la possibilité d ajouter des ordres limités au jeu de la BSU a été analysée, elle n est à ce jour pas encore implémentée. Coûts des transactions à l Eurex Les coûts de transactions à l Eurex contiennent les frais de négociation et de clearing. Ils varient suivant le produit et groupe de produits [Eurex 2008]. Aux frais demandés par Eurex, s ajoutent ceux du courtier qui peuvent être très différents de l un à l autre [Eck, Langer et Riechert 2006, pp ]. Coûts des transactions à la BSU A la BSU, par simplification, seulement des frais de courtage sont perçus.

28 2. La logique métier 18 Les autres sortes d options négociées en Suisse Les options Eurex ne sont pas les seules qu il est possible de négocier en Suisse. En effet, il en existe deux autres sortes: 1. Warrants: les warrants peuvent être négociés sur la bourse Scoach. Ils sont émis par des sociétés financières, généralement des banques. L une des principales différences par rapport aux options Eurex est qu ils ne peuvent être qu achetés (position dite «long») et non vendus par des investisseurs [Novello 2007, p. 126]. 2. Options over-the-counter (OTC) ou option de gré à gré: le contrat est conclu hors bourse, directement entre l acheteur et le vendeur. L avantage de ce genre d option est qu elles peuvent être taillées sur mesure aux besoins des clients [BankingToday 2009]. A la BSU A la BSU, pour l instant, seulement les options Eurex sont utilisées. 2.3 Les outils financiers Actions Définition Une action est un titre à revenu variable, représentant une fraction du capital propre d'une société anonyme. L'action confère à son détenteur: des droits sociaux: droit de vote à l'assemblée générale, droit de consultation, droit d élire et d être élu lors de l élection d un organe de la société, droit d attaquer les décisions de l assemblée générale, droit de contrôle, des droits patrimoniaux: droit à une fraction des bénéfices, droit de souscription d'actions nouvelles lors d'une augmentation du capital ou droit à une fraction du produit de liquidation en cas de liquidation [UBS 2008]. Valeur La valeur d une action peut être estimée en actualisant les flux futurs qu elle génère: les dividendes et le prix de revente. Cette formule correspond aux cash-flows actualisés (discounted cash-flows ou DCF) [Brealey et Myers 2003, p. 69].

29 2. La logique métier 19 Négoce d actions à la BSU A la BSU, les types d actions suivantes, négociées à la SIX Swiss Exchange et à SWX Europe, sont utilisées: actions au porteur: l action est librement transmissible; actions nominatives: l actionnaire doit être inscrit au registre des actionnaires; la transmission est donc plus restrictive; bons de participation: ce titre peut être émis au porteur ou au nom du participant. Il confère des droits similaires à ceux attachés aux actions ordinaires; à l exception qu il n'incorpore que des droits patrimoniaux; mais pas de droits sociaux. A la BSU, les participants achètent et vendent les actions au cours de clôture du titre, majoré de frais de courtage. Ils reçoivent les dividendes bruts à la date de distribution de ces derniers. Contrairement à la réalité, les participants au jeu ne doivent pas payer l impôt anticipé sur les dividendes [BSU 2008] Obligations Définition Une obligation est un titre à revenu fixe. C'est un emprunt à moyen et long terme négociable, émis par des entreprises ou des organes soumis au droit public [UBS 2008]. Valeur La valeur d une obligation peut aussi être estimée grâce à la formule des cash-flows actualisés (cf. ci-dessus). Elle correspond à l actualisation de tous les flux futurs générés par l obligation: les intérêts et le remboursement final [Brealey et Myers 2003, pp ]. La valeur d une obligation, appelée également dirty price, peut être divisée en: cours pied de coupon ou clean price, exprimé en pourcentage du nominal; coupon couru, exprimé également en pourcentage du nominal. Le dirty price P est le prix payé par l obligataire à l achat. Le coupon couru fl est la multiplication de la fraction de l année par le montant du coupon. Le clean price C est le dirty price sans le coupon couru. Il existe donc la relation: SWX est un clean price [Brealey et Myers 2003, p. 788]. P = C + fl. Le cours publié par la

30 2. La logique métier 20 Négoce d'obligations à la BSU A la BSU, les types d obligations suivantes négociées à la SIX Swiss Exchange sont utilisées: obligation à taux fixe: le paiement de l intérêt correspond à la valeur nominale multipliée par le taux d intérêt; obligation à coupon zéro: sans coupon annuel; mais elle se traite nettement en dessous de sa valeur de remboursement; rente perpétuelle: elle n a pas de délai de remboursement, ni d amortissement. Les obligations à la BSU sont achetées et vendues au clean price; contrairement à la réalité boursière, les intérêts courus ne sont pas pris en compte lors des transactions. Les intérêts sont cependant calculés sur la période de détention des obligations et sont rajoutés au montant des intérêts du compte de dépôt. Il existe ainsi un biais dans le jeu par rapport à la réalité: un joueur de la BSU pourra acheter plus d obligations dans le jeu qu il ne pourrait le faire à la bourse avec la même quantité d argent, du fait qu il ne doit pas payer les intérêts courus. Il pourra ainsi toucher les intérêts sur plus de titres et la valeur de son portefeuille sera plus exposée à la baisse et à la hausse des cours des obligations. Contrairement à la réalité, les participants au jeu ne doivent pas payer l impôt anticipé sur les intérêts Exchange Traded Funds (ETF) Définition Un exchange traded fund (ETF), aussi appelé tracker, est un fonds qui se négocie en bourse et qui reflète l'évolution du cours et du rendement d'un indice sous-jacent [Novello 2007, p. 34]. Ce dernier peut se baser, entre autres, sur le marché des actions, obligations, matières premières, de l immobilier et du marché monétaire [Eibl 2008, pp ].

31 2. La logique métier 21 Les ETFs connaissent un succès grandissant depuis leur apparition en 1993, car ils offrent des avantages non négligeables: Tout d abord, contrairement à des fonds indiciels traditionnels, ils sont négociables en bourse. Des market makers doivent en assurer la liquidité [Novello 2007, p. 34]. Ils possèdent des coûts de gestion généralement inférieurs aux fonds de placement traditionnels, dus, entre autres, à leur réplication purement mathématique de l indice (gestion passive) [Eibl 2008, pp ]. La publication de la valeur nette d inventaire indicative (inav, pour indicative net asset value) en permanence par la bourse fournit à l investisseur la plus haute transparence. Il lui est ainsi possible de connaître en tout temps la différence entre la valeur intrinsèque du ETF et son prix côté en bourse [Eibl 2008, pp ]. Il est possible que le cours de l ETF s élève progressivement au dessus de son indice sousjacent, lorsque des paiements de dividendes des titres composant l indice sont effectués. Cet écart se résorbe lorsque l ETF lui-même verse un dividende [Novello 2007, p. 34]. La société de gestion de l ETF émet de nouvelles parts et les rachète à tout investisseur le désirant. Ceci a pour effet d augmenter la fortune collective et le nombre de parts en circulation, dans le cas d émission et en cas de rachat, et de diminuer la fortune collective et le nombre de parts en circulation. Cette possibilité d acheter et de vendre des parts sur le marché primaire permet que les ETFs se négocient à un cours proche du inav sur le marché secondaire [SWX 2008b]. Valeur La valeur intrinsèque d un ETF est appelée inav [Novello 2007, p. 34]. Elle est calculée par la SIX Swiss Exchange en permanence en additionnant les cours des titres inclus dans le fond et en le divisant par le nombre de parts en circulation [SWX 2008b]. La figure 5 illustre en bleu le cours de l ETF ishares DAX et en noir son inav. Comme il en ressort, les ETFs se négocient à un cours proche de la valeur d'inventaire nette indicative. Seulement pendant un court moment, il existe des différences de quelques centimes. L investisseur a ainsi la sécurité d avoir, en tout temps, un prix juste pour un ETF [Eibl 2008, pp ].

32 2. La logique métier 22 Figure 5: Evolution du cours de l ETF ishares DAX et de son inav [DeutscheBörse 2008] Négoce d ETFs à la BSU Les ETFs ne sont pas encore proposés dans le jeu de la BSU. Cependant, comme leur importance est grandissante, il serait judicieux d y songer. Ils ne nécessitent en plus pas d implémentation spécifique; ils peuvent être traités dans le jeu comme des actions. En effet, comme ces dernières, ils disposent toujours en général d un cours et d une valeur théorique; ils versent des dividendes et leur achat et vente donnent lieu à des commissions de courtage et de bourse. Une des seules différences est que la direction de fonds de l ETF prélève, en plus, des frais de gestion qui se répercutent périodiquement sur l évolution du cours du fonds Devises Définition Une devise est une créance libellée en une monnaie étrangère et payable à l étranger. Elle peut prendre la forme d un avoir en banque ou de papier-valeur [UBS 2008]. La grande différence par rapport au négoce des autres valeurs utilisées dans le jeu de la BSU est que les devises ne sont pas négociées à une bourse; mais OTC: les partenaires traitent ensemble directement. Les grands acteurs de ces échanges sont les banques qui forment un réseau: le marché interbancaire [Metz 2007, p. 19]. Le marché des devises, aussi appelé Foreign Exchange (Forex), est un marché global. Il ne subit aucune restriction temporelle: il est possible de négocier des devises 24h sur 24h. Un jour de négoce commence en Asie, continue en Europe pour finir aux Etats-Unis [Metz 2007, pp ].

33 2. La logique métier 23 Un gros désavantage du négoce de devises est le peu de choix de devises liquides. Il n en existe, en effet, que quelques unes en comparaison avec, par exemple, les actions où il y en a des centaines [Metz 2007, p. 23]. Les frais de transaction sont relativement bas, car en règle générale, seulement le spread (différence avec le cours acheteur et le cours vendeur) est perçu comme frais indirect [Metz 2007, p. 22]. Valeur Pour évaluer le cours de change d une devise, il existe plusieurs modèles qui se concentrent seulement sur quelques facteurs d influence. La théorie de la parité du pouvoir d achat et la parité des intérêts en sont deux exemples connus. Il existe une autre approche de l analyse fondamentale qui consiste à observer toutes les données économiques pertinentes et à en déceler l influence future sur les cours. Des données sur la situation politique et conjoncturelle, sur la politique monétaire, sur les taux d intérêt et la spéculation sont utilisées [Metz 2007, pp ]. Négoce de devises à la BSU A la BSU, les quelques devises les plus liquides du marché sont utilisées. Comme généralement dans la pratique pour un simple dépôt, les joueurs ne reçoivent pas d intérêts. Les frais de transaction sont analogues aux autres titres négociés à la BSU, ce qui est relativement cher en comparaison avec la réalité, où seulement le spread est prélevé. Comme les devises sont négociées en continu et OTC, l importation des cours de change pour le jeu est faite à des heures plus ou moins régulières et provenant du même fournisseur Options Définition Une option est un contrat entre l acheteur de l option, appelé le détenteur, et le vendeur, appelé signataire. Il donne à son détenteur le droit d'acheter (call) ou de vendre (put) jusqu à une date prédéterminée (date d échéance) et à un prix fixé d'avance (prix d exercice) une certaine quantité de marchandises ou un certain nombre de titres (actif sous-jacent), en

34 2. La logique métier 24 contrepartie du paiement immédiat d une prime (prime de l option) au signataire [Brealey et Myers 2003, pp ]. Une option est donc un actif dérivé, c'est-à-dire qu il tire sa valeur de l évolution de l actif sous-jacent. Dans les graphiques et sont illustrés les pay-offs des détenteurs d un call, respectivement d un put en fonction de l évolution du prix du sous-jacent. Le pay-off du détenteur d un call devient positif lorsque le prix du sous-jacent dépasse la prime de l option p payée additionné du prix d exercice K payé. La perte d une position long (position du détenteur) d un call est limitée, tandis que le gain est illimité [Eck, Langer et Riechert 2006, pp ]. Le pay-off du détenteur d un put est maximal, lorsque le prix du sous-jacent est nul. Le gain est ainsi égal au prix d exercice K reçu, moins la prime p payée; il est limité, tout comme la perte qui est, au maximum, égale au montant de la prime p [Hull 2003, pp ]. Figure 6: Pay-off du détenteur d'un call [Wikipedia 2008] Figure 7: Pay-off du détenteur d'un put [Wikipedia 2008]

35 2. La logique métier 25 Deux types d option existent: options américaines: elles peuvent être exercées n importe quand jusqu à l échéance; options européennes: elles peuvent être exercées seulement à la date d échéance [Brealey et Myers 2003, p. 630]. Les options Eurex sont négociées en contrats; ces derniers correspondent à un nombre différents d options suivant l option choisie. Le cours Eurex indique le prix d une option, il faut donc le multiplier par la grandeur du contrat pour connaître le prix de transaction [Eck, Langer et Riechert 2006, p. 101]. Valeur Il existe plusieurs sortes de modèles pour évaluer les options: des modèles analytiques (modèle de Black and Scholes et ses extension) [Hull 2003, pp ], des modèles numériques (modèle binomial, trinomial, simulation de Monte Carlo, etc.) [Hull 2003, pp ] et des modèles d approximation analytique. Ces modèles sont utilisés, entre autres, pour la détermination du prix de compensation (cf. chapitre 2.2.2). Négoce d options à la BSU A la BSU, deux sortes d options Eurex sont négociées: options sur actions: le sous-jacent est une action, options sur indices: le sous-jacent est un indice. L organisation d une simulation boursière avec des options est plus délicate qu avec seulement des produits au comptant. Quelques simplifications doivent être implémentées; les points suivants en sont une illustration: Contrairement au négoce fait à l Eurex, il n est pas possible dans le jeu BSU de devenir signataire d une option. Une position short (position signataire) sur une option est beaucoup plus risquée qu une position long: la perte maximale ne se résume pas à la prime payée au début du contrat (comme pour une position long). Le flux de trésorerie pour une position short est toujours positif à la vente (réception de la prime) et peut se développer négativement par la suite. Pour cela des appels de marge (cf. chapitre 2.2.2) sont faits dans la pratique. Pour la simulation, cela signifie, entre autres, que la valeur de la marge devrait être calculée tous les soirs et que les positions des joueurs prenant trop de risque devraient être fermées.

36 2. La logique métier 26 Dans la simulation, il n est pas non plus possible d exercer des options. La différence entre options américaines et européennes devient alors insignifiante. Il peut être démontré que dans la pratique, en règle générale, il n est de toute façon pas profitable d exercer une option avant sa date d échéance. Il est mieux de la vendre et d acheter l action séparément, plutôt que d exercer l option. Si une option n est pas négociée de la journée à la bourse Eurex, elle ne possède pas de dernier prix (Last Price). Pour continuer de pouvoir l utiliser dans la simulation, il est donc nécessaire d utiliser une autre estimation de sa valeur qui est le cours de compensation (daily settlement price) (cf. chapitre 2.2.2). La transaction des options tombées à un centime est suspendue dans la simulation [BSU 2008]. Dans la réalité, si elles redevenaient attrayantes, elles seraient achetées à un prix plus haut. Le fait de bloquer les options offre aussi la possibilité de se protéger des joueurs qui voudraient influencer le vrai cours des options pour pas cher et gagner la simulation. Le fait de choisir des options pour la simulation avec une échéance plus longue diminue la probabilité d avoir des options à un centime, comme le temps est une composante qui influence positivement le prix des options. Les options avec une échéance plus proche dans le temps sont, toutefois, plus intéressantes à négocier. 2.4 Les évènements boursiers pouvant perturber le jeu Au cours des deux mois de simulation, il est possible que l activité des entreprises suscite des ajustements au niveau du jeu. Ce chapitre décrit brièvement les événements perturbateurs et les actions requises par les administrateurs BSU Split Un split d une action est la division de sa valeur nominale [UBS 2008]. Comme cette opération ne change pas la valeur de l entreprise, elle ne devrait pas modifier la richesse des actionnaires. Toutes choses égales par ailleurs, le prix de l action devrait être divisé par le nombre d actions nouvelles reçues (n) pour une ancienne (m) et le nombre de titres devrait être multiplié par ce même facteur; la richesse devrait ainsi être restée la même [Hull 2003, p. 58]. Pour les options, les spécifications du contrat sont changées pour refléter le changement attendu du prix de l action. Le prix d exercice doit être multiplié par le facteur m/n et le

37 2. La logique métier 27 nombre de titres sous-jacents à un contrat d option doit être multiplié par n/m. Si le prix de l action baisse dans les proportions attendues, la valeur totale du contrat est inchangée [Hull 2003, p. 158]. Traitement d un split à la BSU Dans le jeu, des simplifications ont été introduites: pour les actions, leur nombre reste inchangé, mais leur cours est multiplié par n/m; pour les options, le prix d exercice est multiplié par m/n, le nombre de titres correspondant à un contrat reste le même et le cours est multiplié par n/m Fusion et acquisition Au sens strict du terme, une acquisition signifie qu une société, dite initiatrice, achète une autre société, dite cible. Cette dernière cesse ainsi d exister et seules les actions de l initiatrice continuent d être négociées. Lors d une fusion, les deux entreprises, de tailles plus ou moins égales, s accordent pour continuer leur existence en une seule entité. Les actions des deux sociétés sont remplacées par de nouvelles actions communes [Hickman, Hunter et Byrd 2002, p. 447]. Une offre faite directement aux actionnaires constitue une possibilité de forme d acquisition. Pour protéger les petits détenteurs d actions, la loi oblige les entreprises qui veulent prendre le contrôle à faire une offre à tous les actionnaires [Novello 2007]. A la bourse, deux sortes d offres sont couramment utilisées: Offre publique d achat (OPA): un montant en espèces est offert en échange des actions de la société cible [Weston, Mitchell et Muhlerin 2004, p. 484]. Offre publique d échange (OPE): la société initiatrice propose des titres en échange des actions [Weston, Mitchell et Muhlerin 2004, p. 337]. Ces offres peuvent aussi être hybrides, c'est-à-dire être composées d une partie en liquidités et d une partie en titres [Hickman, Hunter et Byrd 2002, p. 447].

38 2. La logique métier 28 Traitement d une fusion à la BSU Dans la simulation, dès qu une société est rachetée ou fusionne, ses actions et options sont vendues de force au dernier cours en vigueur Faillite Une faillite est la vente forcée de la fortune globale d'un débiteur inscrit au registre du commerce suite à son incapacité de paiement. Le produit de la réalisation est ensuite réparti entre les créanciers [UBS 2008]. Lorsqu une société a fait faillite ses titres ont perdu toute leur valeur. Traitement d une faillite à la BSU Dans le jeu, les actions et options call d une société ayant fait faillite sont évaluées à CHF 0.- Les options put sont vendues de force.

39 3. Analyse d un système d information 29 3 L analyse d un système d information Un projet informatique ne peut être mené à bien s il ne suit pas une méthodologie claire. Ce chapitre apporte une réponse à la question: comment procéder pour entreprendre un changement dans le système d'information d'une entreprise? Pour répondre à cette question, une méthodologie qui a déjà fait ses preuves sera présentée: Rational Unified Process (RUP). Ses disciplines «Recueil des exigences», «Analyse et conception», «Implémentation» et «Test» sont décrites ici, dans le but d être appliquées, dans la partie pratique, aux chapitres 4, 5 et 6. Deux techniques utilisées dans cette démarche aideront le développement: la modélisation et le prototypage. 3.1 Méthodologie de gestion de projets: Rational Unified Process (RUP) RUP: une méthodologie de gestion de projet Définition Rational Unified Process (RUP) est une méthodologie de gestion de projets informatiques. Elle fournit une approche disciplinée pour assigner des tâches et des responsabilités à l intérieur d une organisation de développement. Son but est d assurer la production de logiciels de qualité qui satisfassent les besoins des utilisateurs et dont le développement respecte les contraintes de budget et de temps. RUP a été conçu et documenté en utilisant le langage de modélisation UML (cf. chapitre 3.2.1) [Kruchten 2001, p. 17]. Histoire La première version de RUP, version 5.0, a été crée en 1998 par l entreprise «Rational». Cette dernière a été fondée par les auteurs mêmes des premières versions d UML: Booch, Jacobson et Rumbaugh. RUP est le fruit d un long processus et s inspire des meilleures pratiques de développement. Son architecte chef est Philippe Kruchten. En 2003, Rational est racheté par International Business Machines (IBM). La dernière version (7.0) est sortie avec l annonce de IBM Rational Method Composer (RMC) en novembre 2005 [Perpetua 2008].

40 3. Analyse d un système d information 30 Rational Method Composer (RMC) RMC est un produit commercial pour créer, configurer, visualiser et publier des processus sous forme de pages web. RUP en fait partie intégrante en tant que vaste librairie réutilisable [IBM 2008b]. La figure 8 ci-dessous montre une page du RUP publiée grâce au RMC. RUP est un des processus dits de livraison de RMC. Ces derniers sont des processus complets pour un certain type de projets; ils constituent un point de départ rapide pour planifier et initialiser un projet. Le plus large processus de livraison est le Cycle de vie Classic RUP; il est similaire à RUP version 6.0. Pour des petits projets, le Cycle de vie RUP pour petit projet est préférable. Il ne prescrit ni de discipline de modélisation métier, ni de discipline de déploiement; certains produits ont été abandonnés et quelques autres changements ont été apportés. Le Cycle de vie de modélisation métier et la Modélisation et architecture orientées service RUP constituent deux autres processus de livraison [Admiraal 2007a]. RMC contient aussi des patterns de capacités qui sont des morceaux de processus réutilisables abordant des problèmes communs. Les figures 11 à 14 sont des exemples de patterns de capacités. Le Framework de processus RMC permet ainsi à l expert de processus d adapter RUP à chaque projet en lui mettant à disposition une architecture et des groupes de construction réutilisables [Perpetua 2008]. Figure 8: Une page de RUP personnalisable grâce à RMC [IBM 2008a]

41 3. Analyse d un système d information 31 Principes clés pour le développement guidé par le métier RUP version 7.0 a fait une mise à jour importante de ses meilleures pratiques les appelant dorénavant Principes clés pour le développement guidé par le métier. Elles sont décrites brièvement ci-après: Adapter le processus: la taille du processus de développement doit être adaptée aux besoins du projet. Par exemple, pour un projet limité, impliquant une équipe locale et une technologie connue, le processus devra être constitué de manière simple. Trouver un équilibre entre les priorités des parties prenantes: les parties prenantes aimeraient avoir une application qui effectue exactement ce qu'elles veulent faire tout en minimisant le coût de développement et le temps de planification; cependant, ces buts entrent souvent en conflit. Il est donc nécessaire de gérer les exigences de manière efficace, de les comprendre et de les hiérarchiser. Collaborer entre équipes: ce point répond aux questions: Comment motiver son équipe pour qu'elle soit performante? Comment collaborer au sein d'une équipe logicielle distribuée ou localisée à un même endroit? Comment établir une collaboration entre des équipes de vente, informatiques et de développement logiciel? Démontrer la valeur des itérations: fournir une valeur incrémentielle permet un retour précoce et continu d informations dans le but de pouvoir ajuster les plans, traiter les risques clés tôt dans le cycle de vie, prendre en compte et gérer les changements. Elever le niveau d'abstraction: La modélisation visuelle à l aide d UML et la concentration sur l architecture aident l équipe de développement à élever le niveau d abstraction et évite qu elle passe directement des exigences au code. Pour réduire la complexité, il est aussi important, entre autres, de réutiliser des solutions existantes, d utiliser des langages haut niveau, des Frameworks et des patterns d applications. Concentration continue sur la qualité: dans RUP, le logiciel développé lors de chaque itération est testé parallèlement à sa construction. Cela permet une amélioration perceptible de la qualité [IBM 2008c].

42 3. Analyse d un système d information 32 Unified Method Architecture (UMA) Le méta-modèle sur lequel se base RUP pour décrire ses processus s appelle: Unified Method Architecture (UMA). Il permet de prendre en charge plusieurs modèles de cycles de vie différents: le cycle de vie de développement itératif RUP, les cycles de vie en cascade, etc. La spécification de UMA a elle-même été soumise au Object Management Group (OMG) en tant que proposition de méta-modèle de processus d ingénierie logicielle (Software Process Engineering Metamodel: SPEM 2.0) [IBM 2008a]. Le principe essentiel d UMA consiste en une séparation claire entre le contenu d une méthode et son utilisation dans le déroulement temporel d un processus. Un contenu de méthode décrit en détail les tâches qui doivent être effectuées (indépendamment des dépendances temporelles) pour obtenir un produit et le savoir-faire nécessaire pour y parvenir. Le déroulement d un processus donne au contenu de la méthode une suite temporelle et permet une adaptation à des types de projets très différents [Essigkrug 2007, pp ]. La figure 9 montre une vue d ensemble des concepts clé de l architecture UMA. Les concepts suivants y sont représentés: Un produit (anciennement Artefact): répond à la question: quel est le résultat? Une tâche (anciennement Activité): décrit comment quelque chose doit être réalisé. Un rôle: définit la responsabilité pour certaines tâches. Une activité (anciennement Détail de l'enchaînement d'activité): est l élément constitutif d un processus le plus fondamental. Un pattern de capacité et un processus de livraison: cf. ci-dessus. Des conseils: sont des instructions relatives à, par exemple, des techniques et indications pour construire un produit ou exécuter une activité [Shuja et Krebs 2008, pp ].

43 3. Analyse d un système d information 33 Figure 9: Vue d'ensemble des concepts clé de l'architecture UMA [IBM 2008a] Contrairement à des méthodes séquentielles, comme le modèle en cascade, RUP est une méthodologie basée sur une approche itérative et incrémentale [RSCorp 1998]. La figure 10 montre les deux dimensions sur lesquelles repose RUP: La dimension horizontale: représente l aspect dynamique, c est-à-dire les processus. Un cycle de développement se décompose en phases et en itérations. La dimension verticale: représente le contenu de la méthode ou les disciplines. Ces dernières sont le regroupement le plus global possible des contenus de méthodes et rassemblent toutes les tâches qui correspondent à un domaine particulier [cf.essigkrug 2007]. La surface colorée représente l intensité avec laquelle chaque discipline est exercée à l intérieur de chaque phase. Comme [Brandon 2006, p. 74] le remarque, RUP, de par sa nature itérative, possède beaucoup de chevauchement dans l application de ses contenus de méthodes; par exemple, les composants d une application ne sont pas testés seulement à la fin de la construction, mais régulièrement, dès la phase de création.

44 3. Analyse d un système d information 34 Figure 10: les aspects dynamiques et statiques du RUP [IBM 2008a] Critiques Malgré la flexibilité offerte par RMC pour configurer RUP à ses besoins, de nombreuses critiques se font entendre. [Brandon 2006, p. 75], par exemple, ne considère pas RUP approprié pour tous les projets de développement logiciels. Concrètement, il trouve que pour de gros projets internes et risqués, où il est nécessaire de déployer rapidement une partie du produit, RUP peut être satisfaisant. Wolfgang Hesse fait aussi part de ses critiques dans un de ses plus fameux articles: [Hesse 2003]. Il reproche à RUP, entre autres, son approche trop centrée sur des phases ressemblant beaucoup trop à des phases de modèle en cascade. Il ne peut en découler, d après son analyse, une méthodologie centrée sur l architecture, comme RUP se targue de l être. Dans [Klopper, Gruner et G. Kourie 2007], RUP est encore décrit comme étant très couteux à implémenter. Utilisation de RUP dans ce travail Dans ce travail de master, pour satisfaire le principe clé de RUP «Adapter le processus», une version allégée du processus de livraison pour petits projets servira de fil conducteur. Pour «élever le niveau d abstraction», les techniques de modélisation UML et de prototypage seront utilisées. Les disciplines et techniques utilisées dans ce travail sont décrites plus en détails dans les chapitres suivants.

45 3. Analyse d un système d information Recueil des exigences Le but de la discipline Recueil des exigences est de décrire ce que le système doit faire et permettre aux développeurs et aux clients de se mettre d accord sur cette description. Pour atteindre ce but, les fonctionnalités et contraintes requises doivent être exprimées, organisées et documentées; les compromis et les décisions doivent être également documentés [RSCorp 1998]. Recueillir les exigences des utilisateurs est central pour un projet de développement de logiciel et ne devrait pas être sous-estimé. Pour cette raison, RUP se base sur les cas d utilisation comme fil conducteur tout le long du processus de développement (cf. chapitre 3.2.1). Comme les cas d utilisation sont développés selon les besoins des acteurs, le système aura ainsi plus de chance de correspondre aux attentes des utilisateurs [Shuja et Krebs 2008, p. 103]. La figure 11 montre le diagramme d activités de la discipline Recueil des exigences. Chaque activité indiquée dans ce diagramme se décompose en tâches qui elles-mêmes sont composées d étapes. RUP documente pour chaque activité de chaque discipline quels sont ses composants, les responsables et les produits utilisés et produits créés [IBM 2008a]. Le gros des tâches dans cette discipline relève de la responsabilité de l analyste système. Parmi les tâches importantes les suivantes peuvent être citées : définir un vocabulaire commun pour les utilisateurs finaux et les réalisateurs du projet, identifier les acteurs et les cas d'utilisation (cf. chapitre 3.2.1), développer une vision de ce que le système doit faire, déterminer les demandes des parties prenantes, développer les spécifications supplémentaires, hiérarchiser les cas d'utilisation, structurer le modèle de cas d'utilisation, détailler un cas d'utilisation.

46 3. Analyse d un système d information 36 RUP propose plusieurs produits qui peuvent être livrés par la discipline Recueil des exigences. Dans le cadre de ce travail, le produit Spécification des exigences logicielles (Software Requirements Specification) sera produit (cf. chapitre 3.2.1). Figure 11: Pattern de capacité Recueil des exigences [IBM 2008a]

47 3. Analyse d un système d information Analyse et conception Le but de cette discipline est de montrer comment le système sera implémenté. Elle constitue un pont entre les exigences des utilisateurs et la plateforme technique. Après avoir pris un point de vue utilisateur, on passe ici à une vue architecte qui servira par la suite à l implémentation du logiciel [RSCorp 1998]. La conception réalisée doit: combler toutes les exigences des utilisateurs, posséder une architecture robuste, être adaptée à l environnement d implémentation [Shuja et Krebs 2008, p. 112]. La figure 12 montre l enchaînement d activités de la discipline Analyse et conception. Différentes tâches les composent, dont: L analyse architecturale (pour des réflexions relatives à l architecture cf. chapitre 5 ) Conception d'une interface utilisateur, Création d un prototype de l'interface utilisateur (cf. chapitre 3.2.2), Conception des classes (cf. chapitre 3.2.1), Conception de la base de données, etc. [IBM 2008a]. [Phillips et Kemp 2002] décrit comment la conception d interface utilisateur est prise en charge dans la méthodologie RUP. Dans le cadre de ce présent travail, les produits suivants seront réalisés: un premier prototype de l interface, créé sur papier (cf. chapitre 3.2.2), un prototype évolutif codé qui servira notamment durant les tests de convivialité (cf. chapitre 3.1.4), un modèle de conception (cf. chapitre 3.2.1). Il est important ici de souligner l importance de la collaboration de manière étroite avec les utilisateurs du logiciel, lors de la création du prototype de l'interface utilisateur. Cela peut aider pour la gestion de la convivialité du système, la découverte de nouvelles exigences et le détail des définitions des exigences [IBM 2008a].

48 3. Analyse d un système d information 38 Figure 12: Pattern de capacité Analyse et conception [IBM 2008a] Implémentation et test Implémentation La discipline Implémentation est composée de l implémentation des composants (ou services) et leur intégration successive dans le système. Les tests développeurs, la révision du code et la correction de bogues en font aussi partie [Essigkrug 2007, p. 36].

49 3. Analyse d un système d information 39 Plusieurs rôles sont ainsi engagés dans cette discipline: l architecte logiciel, l intégrateur, l implémenteur 1 et le réviseur technique. La figure 13 montre le pattern de capacité pour cette discipline. Figure 13: Pattern de capacité Implémentation [IBM 2008a] 1 Implémenteur est le terme français utilisé par RUP pour le développeur des composants logiciels.

50 3. Analyse d un système d information 40 Les différents rôles se partagent les tâches suivantes: L architecte logiciel est responsable de la structure physique des composants logiciels et de la façon avec laquelle les classes et les paquets sont organisés dans le système de données. L implémenteur s occupe de l implémentation des composants, des tests développeur et de l exécution de ces derniers. Un test développeur est une suite de tests qui valide le bon fonctionnement du composant, il est composé majoritairement de tests d unité (un test d unité vérifie un objet ou de multiples objets séparément) [IBM 2008a]. L implémenteur doit aussi tester le comportement de son code au runtime. L intégrateur planifie et réalise l intégration des différents composants. Le réviseur technique est responsable de la révision du code. Test La discipline Test joue un rôle prépondérant dans l assurance de la qualité, comme ici il est contrôlé que les logiciels exécutables remplissent les exigences [Essigkrug 2007, p. 38]. Les buts des tests sont donc: de vérifier l interaction entre les objets, de vérifier que l intégration de tous les composants du logiciel soit bien faite, de vérifier que toutes les exigences aient bien été implémentées d identifier et d assurer que les défauts ont été corrigés avant le déploiement du logiciel [RSCorp 1998]. Le RUP propose une approche itérative, ce qui implique que des tests sont réalisés durant toute la durée du projet. De cette manière, les défauts peuvent être détectés le plus tôt possible, réduisant ainsi les coûts pour les réparer [Shuja et Krebs 2008, p. 141]. La figure 14 montre le pattern de capacité proposé pour réaliser les tests. RUP distingue plusieurs risques de qualité, dont ceux de fonctionnalité, de convivialité, de fiabilité, de performance et de prise en charge. Pour chacun des ces domaines, RUP propose des sortes différentes de tests [IBM 2008a]. Dans ce travail, l exécution des tests sera faite de manière implicite en se basant sur la spécification du cas d utilisation modélisant la mise en place du jeu. Les cas d utilisation sont décrits au chapitre

51 3. Analyse d un système d information 41 Figure 14: Pattern de capacité Test [IBM 2008a] 3.2 Techniques : Unified Modeling Language (UML) et Prototypage Unified Modeling Language (UML) UML: un langage de modélisation Unified Modeling Language (UML) est un langage de modélisation dont l objectif initial était de permettre aux informaticiens de représenter un système logiciel et son utilisation prévue dans l entreprise. Ceci devait contribuer à augmenter la rigueur et la qualité de la construction des applications informatiques qu ils développaient [Morley, Hugues et Leblanc 2006, pp ]. UML est un standard non-propriétaire, défini par l OMG. Ses origines remontent vers le milieu des années 90. Les auteurs des premières versions d UML sont les même que RUP, soit Booch, Rumbaugh, Jacobson. Depuis novembre 2007, l OMG diffuse la version UML 2.1.2, et travaille à présent sur la version 2.2 [OMG 2008].

52 3. Analyse d un système d information 42 UML est décrit par un méta-modèle, c est-à-dire un modèle représentant les constituants élémentaires d UML avec leurs règles d utilisation et de syntaxe. Ceci permet, entre autres, d assurer une cohérence entre les différents outils, méthodes et modèles utilisant UML, afin de faciliter l échange entre ateliers [Morley, Hugues et Leblanc 2006, p. 17]. Il ne faut pas confondre UML avec une méthodologie de développement logiciel. UML offre plusieurs types de diagrammes pour pouvoir modéliser différents aspects du processus de développement; mais il ne donne pas de consignes relatives à l utilisation de ces différents modèles dans le processus de développement. Ceci sera la tâche d une méthodologie de développement, comme, par exemple, RUP (cf. chapitre 3.1.1) [IBM 2008c]. Les diagrammes UML de cas d utilisation La discipline recueil des exigences de RUP conseille, pour tous les projets, de créer un modèle UML de cas d utilisation [Admiraal 2007b]. Ce dernier décrit le système d information d après le point de vue des utilisateurs et permet ainsi de mieux intégrer les exigences des utilisateurs dans le processus de développement. Il sert de fil conducteur dans tout le projet; pour cette raison, RUP est dit être basé sur les cas d utilisation [RSCorp 1998]. Un cas d utilisation est une manière spécifique d utiliser un système. Il répond à la question: qu est-ce que l acteur veut atteindre en utilisant le système [Admiraal 2007b]? Un cas d utilisation est un regroupement d activités déclenché par un acteur externe et qui produit un résultat identifiable: une fonctionnalité du système[morley, Hugues et Leblanc 2006, p. 83]. Un modèle UML de cas d utilisation regroupe les cas d utilisation et montre les liens entre ces derniers et les acteurs. Les dépendances entre différents cas peuvent aussi être représentées. Une description textuelle (appelée «spécification du cas d utilisation») complète le modèle; les éléments suivants peuvent y figurer: l objectif du cas, les acteurs pouvant déclencher le cas, l enchaînement d actions, les règles de gestion et les références des documents utilisés ou produits durant les activités du cas [Morley, Hugues et Leblanc 2006, p. 83]. La figure 15 montre une modélisation possible d un automate de l Université de Fribourg. Grâce à ce dernier, un étudiant est capable de charger sa carte, de contrôler les données et de les changer. Ces trois fonctionnalités, l acteur «étudiant» et les relations qui les relient sont illustrés dans le diagramme.

53 3. Analyse d un système d information 43 Dans le présent travail, un diagramme de cas d utilisation modélisant la mise en place du jeu sera décrit en détail. Une analyse préliminaire le complétera. Elle correspondra à une version informelle du produit de RUP «Spécifications supplémentaires» contenant les exigences non fonctionnelles et des exigences fonctionnelles additionnelles. Les diagrammes de cas d utilisation et les spécifications supplémentaires forment ensemble le produit de travail «Spécification des exigences logicielles», en anglais «Software Requirements Specification». Ce dernier décrit toutes les exigences du système ou d une partie du système [Essigkrug 2007, p. 32]. Figure 15: Exemple d un diagramme de cas d utilisation Les diagrammes de classes Les diagrammes de classes font partie des diagrammes les plus utilisés dans la modélisation des systèmes orientés objet [Booch, Rumbaugh et Jacobson 2000, p. 113]. Ils représentent la structure statique en termes de classes et de relations entre ces classes [Muller 2000, p. 92]. Une classe est une description abstraite d un ensemble d objets du domaine d application. Elle est représentée par des rectangles compartimentés: le premier compartiment est obligatoire et contient le nom de la classe, le deuxième et le troisième sont facultatifs est contiennent respectivement les attributs et les opérations de la classe [Muller 2000, pp ].

54 3. Analyse d un système d information 44 Les relations entre les classes décrivent les liens potentiels d un objet vers un autre objet. Ainsi, il est possible pour une classe de posséder avec d autres classes: une relation de dépendance : exprime une relation d utilisation d une classe par une autre. une relation de généralisation : est une relation entre un élément général et un élément dérivé de celui-ci, mais plus spécifique. La relation de généralisation s applique lorsqu il est possible de dire de l élément plus spécifique qu il est «une sorte de» l élément plus général. une relation d association : exprime une relation structurelle qui précise que les objets d une classe sont reliés aux objets d une autre classe [Booch, Rumbaugh et Jacobson 2000, p. 68]. La figure 16 illustre un exemple de diagramme de classes. Les classes «Poisson» et «Oiseau» sont toutes deux des «sortes» d animaux. Pour cette raison elles sont reliées à la classe, dite super-classe, «Animal» par une relation de généralisation. Ainsi, ces deux classes, dites sous-classes, héritent des attributs et méthodes de la super-classe, c est-à-dire que les objets de la classe «Oiseau» et de la classe «Poisson» posséderont automatiquement les attributs «rapidité» et «poids» ainsi que la méthode «manger». Les diagrammes de classes servent à modéliser la vue de conception statique d un système. Ils peuvent notamment être utilisés pour modéliser le vocabulaire du système, modéliser la collaboration entre les classes programmées ou programmer et modéliser un schéma de base de données [Booch, Rumbaugh et Jacobson 2000, p. 116]. Dans le présent travail, le diagramme de classes servira comme modèle de conception des entités (cf. chapitre 5.4.5) [Admiraal 2007b]. Figure 16: Exemple d un diagramme de classes

55 3. Analyse d un système d information Prototypage Le prototypage, comme technique de développement d applications informatiques, a fait son apparition dans la littérature du génie logiciel dans les années 1980, mais n a pas joui d une grande importance dans les textes de systèmes d information jusque dans les années Le développement de technologies basées web et l accent accru mis sur le déploiement rapide des systèmes ont contribué à l augmentation de l utilisation du prototypage dans le domaine du développement logiciel pendant la dernière décennie [Zant 2005]. Le prototypage peut être défini comme étant le processus pendant lequel un modèle opérationnel préliminaire d une application, appelé prototype, est créé [Budde et Züllighoven 1990]. Ce dernier aide au développement d un logiciel à plusieurs niveaux, le plus souvent pour: formuler et évaluer les besoins des utilisateurs, les spécifications et le design du produit; démontrer la faisabilité, la performance, le comportement du système, etc.; identifier et réduire les risques d un mauvais développement du système; mieux communiquer, surtout entre différents groupes; répondre aux questions sur des propriétés du système [Luqi et Steigerwald 1992]; mieux planifier le développement du produit; mieux définir le produit et sa stratégie [Arnowitz, Arent et Berger 2007, pp. 9-16]. Comme décrit dans [Arnowitz, Arent et Berger 2007, pp ], la technique du prototypage peut être introduite à n importe quel stade du développement du logiciel, même à plusieurs stades du processus, dans des buts différents. Il sera ainsi possible, par exemple, non seulement de créer un prototype dans la phase d analyse pour mieux cerner les besoins des utilisateurs, mais aussi de faire un prototype dans la phase d implémentation pour tester les performances de certaines parties du système comme un algorithme ou le système de base de données, etc. [Zant 2005]. Pour être efficace, un prototype doit être construit et modifié rapidement, précisément et sans grandes dépenses. Il ne doit pas être performant, complet, portable ou robuste et il ne doit pas non plus utiliser le même hardware, software ou langage d implémentation que le système à produire [Luqi et Steigerwald 1992].

56 3. Analyse d un système d information 46 [Wood et Kang 1992] présente une vue d ensemble des technologies et de la littérature relatives à la création et l utilisation de prototypes dans le domaine des systèmes logiciels. Il ressort de son analyse que, suivant l auteur, des classifications et une terminologie différentes sont utilisées. [Wood et Kang 1992] propose donc de classifier les approches de prototypage observées d une manière relativement générale, se basant sur plusieurs caractéristiques claires et distinctes, plutôt que sur des abstractions ambigües. Dans [Arnowitz, Arent et Berger 2007, pp ] également, une classification générale est employée; elle se base, entre autres, sur les caractéristiques suivantes: l audience (le public cible du prototype est-il composé du team de programmeurs, des clients, etc.?), la rapidité de développement du prototype, la phase du développement du logiciel dans laquelle le prototype est utilisé, la durée de vie du prototype, la ressemblance du prototype au produit fini. D après [Wood et Kang 1992], une autre classification utile est réalisée selon la fonction du prototype. Un prototype sera ainsi soit: expérimental (appelé aussi rapide, de concept, jetable ou d exploration): il ne sera pas utilisé dans le produit final; ou évolutif: il sera constamment amélioré pour être finalement livré au client comme produit final. La méthodologie RUP (cf. chapitre 3.1.1) reprend cette catégorisation d après la fonction et en rajoute une autre selon le sujet d exploration du prototype. Deux types en ressortent: le prototype de comportement: il explore les comportements spécifiques du système. le prototype de structure: il explore des questions technologiques et architecturales [IBM 2008a]. Dans [Arnowitz, Arent et Berger 2007, pp ], différentes méthodologies et outils sont décrits pour effectuer un prototypage efficace. Il en ressort que, du coin de la nappe de table, au Framework orienté objet en passant par la caméra vidéo et la présentation PowerPoint, quasi n importe quel outil peut être utilisé pour créer un prototype efficace, l importance étant d adapter les moyens au but [Pomberger et Weinreich 1994].

57 3. Analyse d un système d information 47 Dans ce travail de master, un prototype expérimental sur papier de l interface graphique sera créé au début de la phase d analyse et conception (cf. chapitre 0). Il sera utilisé uniquement en interne comme base de développement et de communication. Un prototype évolutif sera ensuite créé en employant le Framework Visual Studio. L audience de ce second prototype sera constituée des utilisateurs finaux.

58 4. Recueil des exigences du SI BSU 48 4 Recueil des exigences du SI BSU Comme expliqué au chapitre 3.1.2, le but de la discipline Recueil des exigences est de décrire ce que le système doit faire et permettre aux développeurs et aux clients de se mettre d accord sur cette description. Ce chapitre répond à la question : quelles fonctionnalités sont attendues par les parties prenantes pour configurer le jeu? Conformément au RUP, la réponse sera donnée sous forme de cas d utilisation (cf. chapitre 3.2.1), de diagrammes d activité et de description textuelle. 4.1 Analyse préliminaire Cette partie a été enlevée du rapport publique. 4.2 Le produit: Spécification des exigences logicielles (Software Requirements Specification) Cadre Comme vu au point 3.2.1, la spécification des exigences logicielles est une description de toutes les exigences du système ou d une partie du système. Le présent chapitre se basera sur le modèle du système de la BSU créé dans [Shehu 2008]. Dans ce dernier, quatre types de fonctionnalités on été recensés et regroupés sous forme de cas d utilisations dans quatre paquets principaux : Admin, Calcul, Inscriptions et Négociation. La configuration du jeu se trouve dans le paquet Admin et constitue le Use Case 2 (UC2) : Paquet Admin : 1. (UC1) Actualiser le site web (par l Administrateur) 2. (UC2) Mettre le jeu en place (par l Administrateur au début de la simulation) 3. (UC3) Configurer la connexion vers la SWX La figure 17 montre le diagramme du modèle des cas d utilisation du paquet Admin avec le cas d utilisation «Mettre le jeu en place».

59 4. Recueil des exigences du SI BSU 49 L UC2 représente notre sujet d analyse et sera décrit plus en détail au point Figure 17: Le diagramme «Admin» avec l UC «Mettre le jeu en place» [Shehu 2008] Définitions, acronymes et abréviations Comme mentionné au chapitre 3.1.2, une tâche importante du Recueil des exigences consiste à définir un vocabulaire commun pour les utilisateurs finaux et les réalisateurs du projet : Administrateur : toute personne autorisée à administrer le jeu ; Calcul du jeu : importation des cours de clôture des titres dans le programme PMS et actualisation des portefeuilles des membres ; Négociation : passation d un ordre boursier dans le jeu PMS ; Période : un jour ouvrable de la bourse pendant le jeu PMS ; Système : le site web de configuration créé pour la configuration des jeux de la BSU; Variante de jeu : Simulation organisée par la BSU et étant composée de jeux (cf. jeu), ex. : la PMS est une variante de jeu ; Jeu : Constituante d une variante de jeu. Les différents jeux (Classic et Derivative) permettent une composition de portefeuille différente ;

60 4. Recueil des exigences du SI BSU 50 Classic : le jeu classique, où l on peut négocier des actions, des obligations, des options, des devises et des fonds ; Derivative : le jeu dérivatif, où seulement des options peuvent être négociées ; Sous-menu «Titres» : font partie des sous-menus «Titres» les menus «Actions», «Obligations», «Options», «Devises», «Fonds» ; Vidage des tables : Action par laquelle les tables utilisées pour le calcul sont vidées et les périodes utilisées dans d autres tables sont remises à zéro ; Menu «Général» : menu contenant toutes les configurations d ordre général d une variante de jeu ; Menu de jeux : Menu «Classic» et «Derivative» correspondant aux jeux contenu dans une variante de jeu ; Joueur : toute personne ayant un compte dans la base de données BSU. 4.3 Spécification du cas d utilisation (Use-Case Specification) Le cas d utilisation UC2 étant le sujet d analyse de ce présent travail, il nécessite une description plus détaillée. Elle sera faite, en premier lieu, sous forme textuelle en suivant certaines règles de structuration pour faciliter l expression, la compréhension et la cohérence. Elle montrera le flux d évènements décrivant les interactions entre les acteurs et le système. Cette forme de description de cas d utilisation est appelée spécification du cas d utilisation dans le RUP. Ce dernier met à disposition des exemples et chablons de spécification de cas d utilisation. En deuxième lieu, un diagramme d activité reprenant la description faite dans la spécification du cas d utilisation UC2 sera créé. Il permettra une vision macroscopique et temporelle du système modélisé Cas d utilisation UC2 Mettre le jeu en place Objectif : Ce cas d utilisation sert à configurer le jeu en début de période de la variante de jeu.

61 4. Recueil des exigences du SI BSU 51 Acteur : L Administrateur Scénario principal : Préconditions : - L Administrateur a un droit d accès sur le système. - La période la variante de jeu n a pas commencé. - Aucun des sous-menus «Titres» n a été configuré en utilisant des périodes. Actions : 1. Le cas d utilisation commence quand l Administrateur s est logué avec succès sur le système. 2. Une page d accueil invite l utilisateur à choisir une variante de jeux à configurer. 3. L Administrateur choisit la variante de jeux. 4. Une page de départ de configuration de la variante de jeu donne une petite explication des étapes à faire. 5. L Administrateur clique sur le menu «Vidage des tables». 6. La page de «Vidage des tables» est affichée avec une explication du procédé. 7. L administrateur appuie sur le bouton pour vider les tables. 8. Le système demande une confirmation de l Administrateur. 9. L Administrateur confirme son action. 10. Le système affiche un message qu il est en train d exécuter l action demandée. Pendant ce temps, il vide les tables (Bank, BedingungManuell, Kurs, Member_Session, Mutation, Portfolio, Rangliste) et met toutes les périodes utilisées dans d autres tables (Allgemein, Titel, Bedingung et BedingungManuell) soit à nul, soit à la période de début du jeu. Quand ces actions sont achevées, il affiche un message que les tables ont été vidées avec succès. 11. L Administrateur clique sur le menu «Périodes». 12. La page «Périodes» est affichée avec une petite explication.

62 4. Recueil des exigences du SI BSU L Administrateur clique sur le lien de la Bourse pour connaître les périodes ouvrables. Après consultation il revient sur le système. 14. L Administrateur sélectionne dans le calendrier du système les jours ouvrables de la Bourse et clique sur le bouton pour sauvegarder les périodes. 15. Le système efface les anciennes périodes et sauvegarde les nouvelles périodes sélectionnées par l Administrateur. Ce faisant, il entre deux fois la première période et nomme la première des deux «Initialisation». La dernière période entrée est nommée «End». Les champs SpielBeginn et SpielEnde de la table Allgemein sont ajustés aux dates choisies. 16. Le scénario principal continue dans les scénarios alternatifs 16.1., 16.2., 16.3., L ordre d exécution de ces scénarios importe peu ; mais ils doivent tous être exécutés. 17. L Administrateur se déconnecte du système. 18. Le cas d utilisation s arrête ici. Postconditions : - Tous les menus d une variante de jeu ont été configurés. Les numéros des scénarios alternatifs correspondent à un branchement alternatif, ex. : 1.a. correspond aux activités à faire à la place des activités du scénario principal commençant au numéro 1. Scénarios alternatifs 1.a. Vidage des tables quand le jeu a déjà commencé Préconditions : - La date actuelle se trouve dans l intervalle des périodes rentrées dans la table «Périodes» (le jeu a déjà commencé). - L Administrateur veut quand même vider les tables. Actions : 1. Le cas d utilisation commence quand l Administrateur s est logué avec succès sur le système. 2. Une page d accueil invite l utilisateur à choisir une variante de jeux à configurer.

63 4. Recueil des exigences du SI BSU L Administrateur choisit la variante de jeux. 4. Une page de départ de configuration de la variante de jeu donne une petite explication des étapes à faire. 5. L Administrateur clique sur le menu «Vidage des tables». 6. Le système affiche une page disant que le vidage des tables ne peut pas être fait avec un lien pour quand même pouvoir y accéder. 7. L Administrateur clique sur le lien pour quand même accéder au vidage des tables. 8. Le cas d utilisation continue au scénario principal à l action Configuration du menu «Général» Préconditions : - Le menu «Périodes» a déjà été configuré. - La variante de jeu n a pas commencé. Actions : 1. L Administrateur clique sur le menu «Général» pour éditer les informations générales du jeu. 2. Le système affiche la page «Général». 3. L Administrateur clique sur le bouton pour éditer toute la table. 4. La table passe en mode éditable. 5. L Administrateur introduit les changements et pèse sur le bouton pour enregistrer la table. 6. Le système enregistre les changements et remet la table en mode lecture. 7. Le cas d utilisation continue au scénario principal à l action 16. Postcondition : - Le menu Général a été configuré.

64 4. Recueil des exigences du SI BSU Configuration des joueurs Préconditions : - Aucune précondition Actions : 1. L Administrateur clique sur le menu «Joueurs». 2. Le système affiche la page «Joueurs». 3. Conditions : L Administrateur veut seulement changer un ou plusieurs des champs «Membre inactif», «Payé» ou «Bloqué» pour un ou des joueurs. - L Administrateur clique dans les cases des champs à changer. - Le système affiche une croix et enregistre les changements directement. 4. Conditions : L Administrateur veut changer des informations autres que «Membre inactif», «Payé» ou «Bloqué» pour un ou des joueurs. - L Administrateur appuie sur la touche «Sélectionner» correspondant au joueur - Le système affiche toutes les informations correspondant à ce joueur. - L Administrateur clique sur le bouton pour éditer toute la table. - La table passe en mode éditable. - L Administrateur introduit les changements et clique sur le bouton pour enregistrer la table. - Le système enregistre les changements et remet la table en mode lecture. 5. Conditions : L Administrateur veut voir des informations autres que «Membre inactif», «Payé» ou «Bloqué» pour un ou des joueurs. - L Administrateur appuie sur la touche «Sélectionner» correspondant au joueur. - Le système affiche les informations concernant le joueur. 6. Le cas d utilisation continue au scénario principal à l action 16. Postcondition : - le menu «Joueurs» a été configuré.

65 4. Recueil des exigences du SI BSU Configuration du ou des menus de jeux Préconditions : - La période de la variante de jeu n a pas commencé. Actions : 1. L Administrateur pèse sur le menu du jeu «Classic». 2. Le système affiche la page de jeu. 3. Condition : L Administrateur veut changer une limite de titre dans le portefeuille. - L Administrateur pèse sur le bouton pour éditer la ligne à changer. - Le champ «limite» sélectionné est mis en mode éditable. - L Administrateur introduit la valeur et clique sur le bouton pour enregistrer. - La ligne est enregistrée. - L Administrateur répète le point 3. pour tous les champs qu il veut changer. 4. Condition : Il existe un jeu «Derivative». Le cas d utilisation continue à l action 1. de ce scénario avec le menu «Derivative». 5. Le cas d utilisation continue au scénario principal à l action 16. Postcondition : - Les menus de jeux ont été configurés Configuration des sous-menus de «Titres» Préconditions : - Les tables ont été vidées. - Les périodes ont été rentrées. Actions : 1. L Administrateur clique sur un des sous-menus de «Titres». 2. Le système affiche la page correspondant à la catégorie de titres sélectionnée.

66 4. Recueil des exigences du SI BSU Condition : L Administrateur veut effacer un titre. - il pèse sur le bouton «effacer» correspondant au titre à effacer. - Le système demande confirmation. - L Administrateur confirme. - Le titre est effacé. 4. Condition : L Administrateur veut créer un nouveau titre. - L Administrateur pèse sur le bouton pour créer un nouveau titre. - Le système affiche un formulaire pour créer un nouveau titre. - L Administrateur remplit le formulaire et appuie sur le bouton pour enregistrer. - Le système enregistre le nouveau titre et le formulaire disparaît. 5. Condition : L Administrateur veut chercher des informations sur un titre. - L Administrateur appuie sur le bouton pour sélectionner le titre. - Une page avec tous les détails du titre est affichée. 6. Condition : L Administrateur veut changer les informations d un titre. - L Administrateur appuie sur le bouton pour sélectionner le titre. - Une page avec tous les détails du titre est affichée. - L Administrateur rentre les changements et clique sur le bouton pour enregistrer. - Le système enregistre les changements. 7. L administrateur répète ce scénario à l action 1. pour chaque sous-menu de «Titres» et pour chaque jeu. 8. Le cas d utilisation continue au scénario principal à l action 16. Postcondition : - Les sous-menus «Titres» ont été configurés.

67 4. Recueil des exigences du SI BSU 57 *a. Un ou plusieurs champs rentrés sont faux. Préconditions : - Une valeur incorrecte a été rentrée dans un champ et l Administrateur a appuyé sur le bouton pour enregistrer les changements. Actions : 1. Le système affiche une erreur. 2. L Administrateur appuie sur le bouton «Back» du navigateur. 3. La page est réaffichée avec les changements non enregistrés. 4. L Administrateur corrige les champs et appuie sur le bouton pour enregistrer les changements. 5. Le cas d utilisation continue au scénario principal là où il s était arrêté. Postcondition : - Les champs ont été enregistrés. *b. L Administrateur reste trop longtemps inactif sur la page. Précondition : - L inactivité de l Administrateur est plus longue que le time out du serveur. Actions : 1. Le système affiche la page de login. 2. L Administrateur rentre son login et son mot de passe et appuie sur Connecter. 3. Le système affiche la page d accueil. 4. Le cas d utilisation continue là où il s est arrêté ou quelques pas avant. Postcondition : - L Administrateur est à nouveau logué. - Le système affiche la dernière page active (ou la page d entrée ).

68 4. Recueil des exigences du SI BSU 58 *c. Un titre ou un joueur recherché n est pas visible sur la page. Précondition : - Un titre ou un joueur recherché n est pas visible sur la page. Actions : 1. Condition : L Administrateur veut faire une recherche par mots clés. - L Administrateur rentre le mot clé (nom, prénom ou pour un joueur ; nom allemand, nom français, ISIN ou nom d importation pour un titre). - Le système recherche et affiche les résultats correspondants ou un message signalant que la recherche n a pas abouti. 2. Condition : L Administrateur veut chercher en triant par colonne. - L Administrateur clique sur le nom de la colonne suivant laquelle il veut trier les lignes. - Le système réaffiche les lignes dans l ordre ascendant de la colonne sélectionnée. Condition : L Administrateur veut trier les lignes dans l ordre descendant : o L Administrateur clique sur la colonne suivant laquelle il veut trier les lignes. Le système réaffiche les lignes dans l ordre descendant de la colonne sélectionnée. - Le cas d utilisation peut continuer à l action 2 de ce scénario ou continuer à l action Condition : L Administrateur veut chercher en choisissant la page à afficher. - L Administrateur clique sur le menu de pagination. - La page correspondante est affichée. - Le cas d utilisation peut continuer au point 2, 3 ou au point Le cas d utilisation continue au scénario principal là où il s était arrêté. Postcondition : - Le titre ou le joueur recherché a été trouvé ou n existe pas.

69 4. Recueil des exigences du SI BSU 59 *d. L Administrateur veut une information sur un champ. Précondition : - L Administrateur veut une information sur un champ. Actions : 1. L Administrateur clique sur l icône d information du champ. 2. Le système affiche l information. 3. L Administrateur appuie sur la croix pour fermer le message. 4. Le message d information disparaît.

70 4. Recueil des exigences du SI BSU 60 Diagramme d activités du cas d utilisation UC2 «Mise en place du jeu» La figure 18 résume l enchaînement des activités à faire lors de la mise en place du jeu. Figure 18: Diagramme d activités du UC2 «Mise en place du jeu»

71 5. Analyse et conception du SI BSU 61 5 Analyse et conception du SI BSU Comme expliqué au chapitre 4, le but de la discipline «Analyse et conception» est de montrer comment le système sera implémenté. Elle constitue un pont entre les exigences des utilisateurs et la plateforme technique. Les questions suivantes trouveront une réponse dans ce chapitre : Quels bénéfices peut apporter une architecture en trois étages (three-tiers architecture) dans la conception du site de configuration? Quelles technologies devraient être utilisées pour concevoir le système? Les patrons de conception (design patterns) et les technologies.net utilisées pour concevoir une telle application seront également sujets de ce chapitre. 5.1 Architecture actuelle du système d informations de la BSU Aperçu général Cette partie a été enlevée du rapport publique Composantes actuelles utilisées lors de la configuration du jeu Cette partie a été enlevée du rapport publique.

72 5. Analyse et conception du SI BSU Conception souhaitée de l application Architecture en couches Architecture Comme écrit dans [Fowler 2003, pp. 1-2], le mot architecture est un terme qui a souvent été décrit dans l industrie logicielle, mais dont la définition ne fait pas l objet d un consensus. Deux éléments sont toutefois récurrents : une architecture est la division de haut-niveau d un système dans ses parties composantes, les décisions architecturales prises sont difficiles à changer. De cette définition découle une certaine subjectivité. En effet, si une partie du système s avère plus simple à changer qu il était supposé l être au départ, il se peut qu il ne s agisse pas de décisions architecturales, mais de «simples» décisions de conception. Layering Une technique qui peut être raisonnablement qualifiée d architecturale s appelle Layering. C est une des architectures les plus employées par les concepteurs logiciels pour diviser un système compliqué [Fowler 2003, p. 17]. Une couche (layer) est un groupe cohérent de fonctionnalités liées. Dans une architecture dite «en couche» stricte, la couche n peut utiliser seulement les services de la couche n-1. En pratique, cette restriction est parfois relâchée [Bass, Clements et Kazman 2003, p. 37]. La figure 20 montre l organisation hiérarchique des couches à l exemple d un module de sécurité.

73 5. Analyse et conception du SI BSU 63 Figure 19: Une architecture de sécurité en couches [Pfleeger 1998, p. 201] Les termes «Layer» et «tier» Les termes couche (layer) et étage (tier) sont souvent l objet de confusion et sont souvent utilisés comme synonymes. Il existe pourtant une distinction entre ces deux termes: «tier» implique une séparation physique sur différentes machines. Tandis que «layer» fait référence à une séparation logique : il n est pas obligatoire d exécuter les différentes couches sur différents nœuds. Par exemple, sur une machine avec une base de données locale, il est possible de faire tourner une application en trois couches sur un «tier». Il est aussi possible de la séparer sur plusieurs composantes physiques comme le montre la figure 21 [Fowler 2003, p. 19]. Figure 20: Trois tiers [Oldby et Dan 2006]

74 5. Analyse et conception du SI BSU 64 Les trois couches principales La partie difficile du layering est de savoir en combien de couches il faut diviser son application et quelles responsabilités leur attribuer. Dans ce présent travail, une architecture en trois couches classique sera appliquée ; en effet, les responsabilités à l intérieur du site de configuration peuvent être très logiquement séparées en trois couches : Une couche de présentation (Presentation layer) : elle est responsable de l interaction entre l utilisateur et le logiciel. Elle doit afficher les informations et interpréter les commandes venant de l utilisateur. Une couche de logique métier (appelée aussi Business logic layer, BLL ou Domain layer) : elle est responsable de l implémentation des règles et des calculs de la logique métier. Elle exécute la logique sur la base des données venant des utilisateurs et de la couche DAL. Une couche d accès aux données (Data Access layer, DAL) : elle s occupe de la communication avec d autres systèmes qui exécute des tâches sur demande de l application. Ces derniers peuvent être des bases de données, des systèmes de messageries, d autres applications, etc. [Fowler 2003, pp ]. La figure 22 illustre l organisation de ces trois couches. Figure 21: Les trois couches classiques [Mitchell 2006]

75 5. Analyse et conception du SI BSU Model View Controller (MVC) Le pattern Model View Controller (MVC) divise l interaction de l interface utilisateur en trois rôles distincts : Modèle : il représente la passerelle à la logique métier ; il est responsable pour les fonctionnalités de l application [Mortensen, McGovern et Liptaak 2003]. Vue : elle s occupe exclusivement de l affichage des informations pour l utilisateur. Controller : il est responsable d interpréter les requêtes de l utilisateur, de manipuler le Modèle et d afficher la Vue appropriée en réponse [Fowler 2003, pp ]. La figure 23 montre l enchaînement d activité déclenché lorsqu un événement est généré par un utilisateur, comme par exemple une requête de page. 1. La requête est interceptée par le Controller. 2. Le Controller évalue l événement et demande au Modèle d exécuter la logique métier nécessaire. 3. Le Modèle exécute les actions demandées et retourne les résultats au Controller. 4. Le Controller détermine la Vue qui doit être affichée. 5. La Vue est chargée. Si elle a besoin d afficher des données provenant d une source de données, elle ne peut les recevoir que par le Modèle. Il lui est en effet impossible d exécuter des actions (comme un appel à une base de données) directement. 6. La Vue est affichée sur l interface utilisateur [Mortensen, McGovern et Liptaak 2003]. Controller 2. User request Model Data Persistence 6. action View 5. Figure 22: le pattern Model View Controller [Mortensen, McGovern et Liptaak 2003]

76 5. Analyse et conception du SI BSU Avantages et inconvénients d une architecture trois couches En général Une division en couches d une application peut apporter plusieurs bénéfices importants : Peu d interdépendance (low coupling) entre les éléments constituant le système. L interdépendance se caractérise par l intensité avec laquelle les éléments sont connectés entre eux : s ils ont connaissance de l existence ou s ils utilisent les services d autres éléments. Peu d interdépendance réduit l impact des changements faits sur le système. Une couche peut être substituée par une autre tant qu elles offrent les mêmes services ; l implémentation est donc secondaire, l interface est primordiale [Oldby et Dan 2006]. Il est ainsi possible, par exemple, d avoir plusieurs couches de présentation différentes (Ex : une interface en ligne de commande et une interface web) qui utilisent la même couche de logique métier [Fowler 2003, p. 17]. Une haute cohésion (high cohesion) à l intérieur de chaque couche. La cohésion désigne l intensité avec laquelle un élément est centré sur ses responsabilités. Ainsi, une couche possédant des responsabilités étroitement liées et n exécutant pas beaucoup de tâches différentes est qualifiée «à haute cohésion». Cette qualité rend le système plus facile à comprendre, à réutiliser, à maintenir et, comme effet secondaire, diminue l interdépendance entre les différentes composantes [Oldby et Dan 2006]. Chaque couche peut être considérée comme un niveau d abstraction supplémentaire et le système peut ainsi être conçu comme une décomposition d un problème complexe en une séquence d étapes abstraites [Pfleeger 1998, p. 202]. Il y a aussi quelques points négatifs à citer : La division du système en différentes couches signifie plus de travail d implémentation au début puisque plusieurs composantes doivent être crées. Le code peut paraître aussi plus compliqué pour des programmeurs moins expérimentés [Oldby et Dan 2006]. Un changement dans une couche peut résulter dans un changement en cascade dans toutes les autres couches. L exemple type représente l addition d un nouveau champ dans la base de données : si celui-ci doit être affiché dans la couche de présentation, le changement devra se faire dans la couche d accès aux données, la couche de présentation et toutes les couches entre deux [Fowler 2003, p. 18].

77 5. Analyse et conception du SI BSU 67 Des couches supplémentaires peuvent nuire à la performance du système. Il est toutefois très probable que l encapsulation des fonctions sous-jacentes dans une même couche permette une optimisation apportant, au final, un gain de performance [Fowler 2003, p. 18]. Spécifique à las BSU Par rapport aux composantes actuelles utilisées pour la configuration du jeu (cf. chapitre 5.1.2), un grand point négatif de la création d une application en couches réside dans la complexité de l architecture résultante. Effectivement, le grand point fort de la configuration du jeu actuelle est que l architecture est extrêmement simple. La configuration du jeu est actuellement très transparente (l administrateur sait toujours quelle donnée est mise dans la base de données!). Pour des développeurs moins expérimentés cette simplicité est un grand avantage qu il ne faut pas sousestimer. De ce fait découle l importance de garder dans la conception du site de configuration une architecture la plus simple possible avec des patterns connus. Une architecture trois couches, avec l utilisation du pattern MVC pour structurer l interaction avec l interface utilisateur, constitue une bonne solution. 5.4 Conception de l application souhaitée en.net Comme vu au point 5.1, l architecture de la BSU repose presque entièrement sur des technologies Microsoft. Pour garder cette homogénéité et utiliser les dernières technologies, le site de configuration se basera sur le Framework ASP.NET 3.5. Ceci nous permettra, entre autres, d utiliser LINQ (cf. chapitre 5.4.5) et les nouveaux contrôles AJAX (cf. chapitre 5.4.3). Le langage choisi sera du C#, car il a l avantage de ressembler beaucoup au Java enseigné à l Université de Fribourg ; ceci simplifiera la maintenance du site. De plus, actuellement, il existe plus de développeurs professionnels C# que VB [Walther 2007, p. 2] ; cet état de fait se reflète, entre autres, dans le nombre d aide en ligne et de livres parus en C#. Ce chapitre se concentre au début sur la conception général du système avec les technologies.net. Ensuite, les trois couches seront décrites plus en détails Architecture en couches en.net Le but de ce chapitre est d examiner comment implémenter l architecture décrite au point avec les technologies.net. Un point crucial représente, dans ce contexte, l accès aux données.

78 5. Analyse et conception du SI BSU 68 Object Relational Mapping (ORM) L accès aux données sera implémenté en utilisant les technologies Object Relational Mapping (ORM) de Microsoft. ORM permet à un programme écrit en un langage orienté objet, de déposer ses objets dans une base de données relationnelle, comme si il s agissait d une base de données orientée objet. Il n est dès lors plus nécessaire d écrire de commandes SQL et la programmation en est facilitée [Flasko 2008]. Les commandes pour manipuler les objets seront faites en Language Integrated Query (LINQ). Ce dernier est une extension des langages.net (dans le cadre du Framework 3.5) avec des capacités d'interrogation des données. Dans le chapitre 6 des exemples de requêtes LINQ seront montrés. Il existe, au moment de la préparation de ce travail, deux technologies ORM de Microsoft qui pourraient être utilisées dans l implémentation de la couche DAL: LINQ to SQL : Permet un mapping direct 1-1 d une base de données Microsoft SQL Server vers des classes.net et la création de requêtes LINQ avec les objets résultants. LINQ to SQL a été développé pour un scénario de conception rapide (RAD : Rapid Application Developement) avec une base de données Microsoft SQL Server où la base de données possède une très grande ressemblance avec le modèle d objets de l application [Flasko 2008]. ADO.NET Entity Framework (ADO.NET EF): Permet un mapping très flexible et la possibilité d avoir une grande divergence entre le stockage des données sousjacentes et le modèle d objets de l application. Il est donc beaucoup plus complexe et flexible que LINQ to SQL et correspond à un scénario d entreprise [Arefin 2008]. Malheureusement, ADO.NET EF 1 était encore en version beta au début de ce présent projet. Pour cette raison, le choix du ORM se restreint à LINQ to SQL. LINQ to SQL L utilisation de LINQ to SQL dans le développement d une application peut diminuer de beaucoup le temps de programmation, certes ; mais pour cela le prix à payer est de 1 ADO.NET Entity Framework est inclus avec le Service Pack 1 du Framework.NET 3.5 et le Service Pack 1 de Visual Studio 2008, sorti le 11 août 2008.

79 5. Analyse et conception du SI BSU 69 disséminer des requêtes LINQ to SQL directement là où le résultat est utilisé. Des requêtes LINQ to SQL doivent ainsi être faites dans la couche métier et dans la couche de présentation. Ceci engendre une dispersion de l accès aux données dans tout le code et va donc à l encontre du modèle en trois couches. Pour garder une architecture en trois couches pure, il est nécessaire de créer une couche d accès aux données séparées. Seulement à l intérieur de cette dernière, il sera possible de faire des requêtes LINQ et de les énumérer. La couche DAL devra retourner des objets et non des requêtes LINQ to SQL. Ainsi les requêtes faites à la base de données ne seront pas lancées depuis n importe quelle partie de l application [Marguerie, Eichert et Wooley 2008, pp ]. Cette séparation stricte en trois couches signifie beaucoup de code de plomberie en plus. Elle est néanmoins nécessaire pour atteindre les avantages d une bonne architecture discutés au point 5.3. Utilisation des données dans la couche de présentation Pour afficher des données dans la couche de présentation, il est possible d utiliser avec LINQ to SQL deux contrôles différents : LinqDataSource : Ce nouveau contrôle permet l utilisation de LINQ dans une page ASP.NET pour chercher et modifier des données. Son grand point positif est qu il diminue très fortement le code à implémenter : les commandes telles que pour la sélection, la mise à jour, l insertion, la suppression, le tri et la pagination sont créées dynamiquement par le contrôle! Cependant, son utilisation suppose une liaison directe de la couche de présentation avec la couche de données, ce qui ne représente pas une bonne pratique de conception [Esposito 2007]. ObjectDataSource : Permet de relier la couche de présentation à des composants de la couche métier. Les méthodes telles que celle pour la sélection, la mise à jour, l insertion, la suppression et le tri doivent être malheureusement toutes créées manuellement [MSCorp 2008]. Seul le ObjectDataSource pourra être utilisé dans ce présent travail, car il est le seul contrôle à permettre une séparation claire en trois couches. Comme soulignée dans [Oldby et Dan 2006], l utilisation de ASP.NET avec Visual Studio incite à relier la couche présentation directement avec la couche d accès aux données!

80 5. Analyse et conception du SI BSU 70 Vue d ensemble Le système a été implémenté en créant des projets différents dans Visual Studio. Ainsi il serait possible de séparer les trois couches sur trois machines différentes (three tiers). La programmation se fera contre une interface et à l aide de pattern qui favoriseront l indépendance des couches. La figure 24 illustre les différents composants du système : BSUConfiguration : correspond à la couche de présentation. Elle est implémentée en un site web ASP.NET. BLL : correspond à la couche métier. Elle est implémentée en une librairie de classes C#. DAL : correspond à la couche d accès aux données. Elle est implémentée en une librairie de classes C#. Entities : correspond au modèle d objets qui sont manipulés dans les trois couches. Elle est implémentée en une librairie de classes C# créé sur la base du modèle de la base de données grâce à la technologie ORM LINQ to SQL (cf. chapitre 5.4.5). CommonObjects : correspond au modèle d objets qui sont manipulés dans les trois couches. Elle est implémentée en une librairie de classes C#. Ses objets sont créés dans le DAL sur la base du fichier DAL.xml. Le fichier DAL.xml et la base de données : ils procurent les données nécessaires à la création des objets selon les classes contenues dans les paquets Entities et CommonObjects.

81 5. Analyse et conception du SI BSU 71 <<use>> DataContext <<use>> Base de données DAL.xml Figure 23: La composition du système en différents paquets Model View Controller en.net ASP.NET n implémente pas le pattern MVC comme vu au chapitre : le Controller n agit pas au niveau de l application, mais au niveau des pages individuelles. L URL ne correspond pas à une action du Controller ; mais à une page sur le disque [MSCorp 2009]. Le pattern implémenté par une page ASP.NET s appelle «Page Controller» [Fowler 2003, pp ]. Une page ASP.NET est divisée en deux parties: la Vue qui contient les différents contrôles et une classe C# qui correspond au Controller. Cette dernière contient des fonctions pour chaque action que le Controller peut prendre quand un évènement est généré et qu il doit traiter la page. Ces fonctions peuvent être reliées au Model et à la Vue résultante [Mortensen, McGovern et Liptaak 2003].

82 5. Analyse et conception du SI BSU 72 Si un Controller au niveau de l application est nécessaire, il peut être créé grâce au HttpHandler, étant donné que ce dernier intercepte les requêtes avant les pages ASP.NET [Oldby et Dan 2006]. Microsoft a sorti une version d un Framework ASP.NET MVC. Ce dernier implémente le pattern MVC comme vu au chapitre ; il est malheureusement pour l instant seulement disponible en version beta [MSCorp 2009] Couche de présentation A côté de la PMS, la BSU organise plusieurs autres simulations boursières. Dans cette optique, il serait souhaitable que le site web puisse être évolutif et permette la configuration également des autres variantes de jeux. Comme illustré dans la figure 25, chaque simulation possédera donc son propre onglet. Il sera généré dynamiquement sur la base des informations concernant les simulations contenues dans le fichier DAL.xml. Le menu s adaptera aussi dynamiquement suivant que la simulation possède uniquement une version Classic ou également une version Derivative. Les informations communes aux deux jeux (Classic et Derivative) seront réunies sous les mêmes points du menu : par exemple les dates du jeu pour le Classic et le Dérivative étant les mêmes, il existera seulement un sous-menu «Périodes». Il en sera de même pour les sous-menus : «Joueurs», «Général» et «Vidage des tables». La mise en page sera réalisée grâce au Master Pages. Ces dernières permettent de donner à un site web une apparence unifiée. La navigation utilisera le Sitemap et le contrôle SiteMapPath pour afficher un «bread crumb». Un bread crumb renseigne l utilisateur sur sa position dans le site. Dû à la création dynamique des onglets et du menu, la navigation devra aussi être ajustée dynamiquement par le Controller. Le login sera géré par les contrôles Login et LoginStatus. Les paramètres de sécurités sont configurables depuis le fichier web.config. Le contrôle Ajax UpdateProgress sera utilisé pour indiquer à l utilisateur que le système est en train d exécuter la requête demandée. Il sera très utile lorsque le système aura besoin de beaucoup de temps pour exécuter une tâche, comme lors du vidage des tables.

83 5. Analyse et conception du SI BSU 73 Comme décrit au chapitre 3.2.2, l implémentation de l interface utilisateur se basera sur un prototype papier. Ce dernier a été créé pour tout le site ; seules quelques illustrations ont été ajoutées à ce présent document. La figure 25 montre la mise en page générale du site avec son menu et ses onglets créés dynamiquement. La figure 26 représente le contenu du menu «Général». Ce dernier se base sur la description du cas d utilisation du chapitre 4.3 ; il représente le scénario alternatif 16.1 : Configuration du menu «Général». La figure 27 se base également sur la description du Use Case 2 et représente le scénario alternatif 16.4 : Configuration des sous-menus de «Titres». Figure 24: Prototype papier de la mise en page générale du site

84 5. Analyse et conception du SI BSU 74 Figure 25 : Configuration du menu «Général». Figure 26 : Configuration des sous-menus de «Titres»

85 5. Analyse et conception du SI BSU Couche de logique métier La couche métier met à disposition de la couche de présentation les fonctions qui ne sont pas en relation avec l affichage des données mais leur traitement. Dans le cas du système de configuration BSU, ces fonctions comprendront, entre autres, la logique de sélection, de mise à jour, d insertion et de suppression d objets. La logique de comparaison entre différentes valeurs sera aussi implémentée dans la couche métier ; elle sera réutilisée dans la couche présentation pour implémenter le tri. En utilisant le ObjectDataSource, toutes ces fonctions doivent être malheureusement créées manuellement, (cf. chapitre 5.1) Couche d accès aux données Les données nécessaires à la création des objets des classes contenues dans les paquets CommonObjects et Entities se trouvent respectivement dans : le fichier DAL.xml, la base de données. DAL.xml Le fichier DAL.xml (cf. Code source 1) contient les données concernant : les différentes variantes de jeux (Ex : PMS, Derivative, Speed), les jeux contenus dans chacune de ces variantes de jeu (Classic et Derivative). Code source 1 : Partie du contenu du fichier DAL.xml Sur la base de ces données, des objets représentant les variantes de jeu et les jeux pourront être créés dans la couche DAL et utilisés dans les autres couches du système. Le fichier DAL.xml contient aussi pour chaque jeu le nom du mapping à utiliser afin de relier chaque jeu à ses données contenues dans la base de données (cf.ci-dessous).

86 5. Analyse et conception du SI BSU 76 La base de données La base de données BSU contient les informations concernant toutes les variantes de jeu dans une seule base de données. Les tables de cette dernière appartiennent, soit à un jeu en particulier, soit elles sont communes à toutes les variantes de jeux. Le nom de la table appartenant à un jeu en particulier commence avec un préfixe correspondant au numéro de jeu, ex. : pour la variante de jeu PMS, le jeu Classic correspond au numéro 2. Toutes les tables contenant des informations concernant uniquement le jeu 2 commenceront donc par le préfixe «_02_» : _02_Periode, _02_Allgemein, etc. Les informations communes à toutes les variantes de jeu sont contenues dans des tables sans préfixe : Ex : Gruppe. Le mappage de la base de données avec les objets se réalise grâce à l intervention du DataContext. Ce dernier réside au cœur de LINQ to SQL. Il est responsable de la majorité du travail, dont : remplir une collection d objets depuis la base de données et gérer la connexion avec cette dernière [Marguerie, Eichert et Wooley 2008, p. 212]. Lors de la création du DataContext, deux éléments sont requis : Le fichier de mappage : il décrit la correspondance entre les tables de la base de données et les classes contenues dans le paquet Entities. Il existe un fichier de mappage par jeu. Le ConnectionString : il contient les informations pour accéder à la base de données. Comme la structure logique des informations sur un jeu est la même pour tous les jeux, les classes contenues dans le paquet Entities ne représentent pas toute la base de données, mais seulement les tables correspondant à un jeu et celles communes à tous les jeux (cf. figure 29). Suivant quel fichier de mappage est passé au DataContext, les entités seront reliées aux tables de la base de données correspondant au jeu: Ex : si le fichier de mappage «mapping02.xml» est passé au DataContext, les objets que le DataContext manipulera seront créés, modifiés et effacés des tables ayant le préfixe _02_ et des tables communes. Les informations concernant la correspondance entre les fichiers de mappage et les jeux peuvent être configurées dans le fichier DAL.xml. En effet, la base de données ne contient aucune information concernant la relation entre les tables et les différents jeux (Ex : seulement les tables avec le préfixe 02 correspondent au jeu Classic du PMS). La configuration du site par le fichier DAL.xml permet de changer la liste des jeux configurables par le système, sans même devoir recompiler l application. Sans un fichier de

87 5. Analyse et conception du SI BSU 77 configuration comme DAL.xml, les informations concernant la correspondance entre les jeux et les tables auraient dues être codées en brut dans le code. Ceci aurait était hautement inflexible. Le fichier DAL.xml contient également le ConnectionString. La figure 28 illustre les composants impliqués dans la création des entités. Mappin06xml Mappin05.xml Mappin04xml Mappin03.xml Mappin02.xml Mappin01.xml DAL.xml Infos sur le mapping + ConnectionString ConnectionString DAL DataContext Base de données Entities Figure 27: ORM Le diagramme de classes de la figure 29 représente les classes créées par mappage de la base de données ; elles sont aussi appelées des entités. Comme vu au chapitre 5.4.1, LINQ to SQL n offre pas une très grande flexibilité pour concevoir les classes à partir du modèle de la base de données. Il n est, entre autres, pas possible de réunir plusieurs tables de la base de données en une seule entité. Ceci implique qu il ne sera pas possible de créer une seule entité des deux tables «Option» et «OptionDetails» ; bien que, logiquement, ces dernières représentent une même classe. Une association pourra néanmoins être créée entre elles. La seule implémentation d héritage que LINQ to SQL arrive à mapper s effectue, lorsque tous les éléments de la hiérarchie se trouvent dans une table. Par chance, c est exactement le

88 5. Analyse et conception du SI BSU 78 cas de la table «Titres». Cette dernière contient les données de toutes les catégories de titres. Il est, dès lors, possible de créer une hiérarchie de classes avec l entité «Titel» comme super-classe et les entités «Aktie», «Obligation», «Devise», «Fond» et «Option» comme sous-classes. La classe «Aktie» est, à son tour, implémentée comme une classe abstraite et possède comme sous-classes les classes «SMIAktie», «SPIAktie» et «AuslandsAktie». Cette figure a été enlevée du rapport publique. Figure 28: Diagramme d entités

89 6. Implémentation et Tests 79 6 Implémentation et Tests Ce chapitre concrétise la conception faite du système au chapitre 5 en une structure de dossiers et fichiers de programmation. L implémentation de l application en trois couches, de façon à ce qu elle soit configurable par le fichier DAL.xml représente un surcroît de programmation considérable par rapport à son pendant en deux couches non configurable (cf. chapitre 5 ). Le sous-chapitre 6.1 illustrera ce fait et montrera l implémentation globale du système. Un deuxième sous-chapitre sera consacré aux tests. 6.1 Implémentation du prototype Ce chapitre se concentre sur l implémentation globale du système et fournit quelques exemples plus détaillés de certaines parties intéressantes du code. La figure 30 montre les cinq projets créés dans VS pour implémenter la structure décrite au chapitre Ce chapitre se compose de cinq sous-chapitres reprenant chacun un de ces projets. Figure 29: les cinq projets créés dans VS Le site de configuration ne devant être utilisé uniquement par l administrateur en charge de la configuration du jeu, le système ne prendra pas en charge la gestion du parallélisme (concurrency). Pour ne pas dépasser le cadre de ce projet, certains autres aspects n ont pas été pris en compte. La gestion des erreurs, entre autres, a été gardée à un niveau basique. Pour de plus amples détails, veuillez consulter le chapitre Le projet «BSUConfiguration» Structure générale Comme expliqué au chapitre 5.4.1, la couche de présentation est créée en ASP.NET 3.5. Les fichiers et dossiers composant ce projet de site web sont illustrés dans la figure 31.

90 6. Implémentation et Tests 80 Figure 30 : Dossiers et fichiers composant le projet «BSUConfiguration» Références La couche de présentation possède des références uniquement sur le modèle d objets contenu dans les projets «Entities» et «CommonObjects» ainsi que sur la couche «BLL». La couche «DAL» n est, conformément à une architecture trois couches stricte, pas référencée par «BSUConfiguration» (cf. chapitre 5.4.1). App_Code Les fichiers se trouvant dans le dossier App_Code contiennent du code qui peut être partagé par plusieurs pages web et qui est compilé dynamiquement par le Framework. App_Code contient dans le présent projet, un contrôle personnalisé pour afficher une alerte avant l effacement d une donnée.

91 6. Implémentation et Tests 81 Les pages aspx Comme vu au chapitre 5.4.2, les pages aspx représentent la Vue, tandis que les classes C# qui les accompagnent («code behind» ou «fichier aspx.cs») représentent les Controllers. Chaque URL correspond à une page aspx. Les données venant de la base de données sont affichées sur la page à l aide des contrôles : GridView : permet d afficher les données de plusieurs objets, DetailsView : permet d afficher les données d un seul objet. Ces deux contrôles se procurent les objets à afficher grâce au contrôle ObjectDataSource décrit au chapitre Les fonctions que ce dernier appelle se situent dans le BLL. Les GridViews et les DetailsView possèdent chacun des bulles d informations décrivant les champs. Ces bulles d informations sont implémentées en JavaScript dans le fichier BSU.Master (cf. ci-dessous). Les GridViews peuvent être triés en cliquant sur les entêtes du tableau. Ces fonctions de tris sont implémentées dans le contrôle lui-même et dans les méthodes de sélection des objets (projet BLL). Les GridViews possèdent également un pager personnalisé pour naviguer entre ses différentes pages. Ce dernier est implémenté dans le code behind. La figure 32 illustre ces différents composants à l aide de la capture d écran du menu «Actions». Ce dernier correspond à la description du cas d utilisation du chapitre 4.3 et représente le scénario alternatif 16.4 : Configuration des sous-menus de «Titres». Tri GridView Bulle d infos Pager Figure 31 : Capture d écran du menu «Actions»

92 6. Implémentation et Tests 82 Comme décrit au chapitre 5.4.3, des contrôles plus avancés tels que le Calendrier et le contrôle Ajax UpdateProgress ont aussi été utilisés, respectivement dans les pages «Périodes» et «Vidage des tables». Ces contrôles permettent de donner à une simple page web un aspect se rapprochant plus à un programme Desktop. La figure 33 montre la capture d écran du menu «Périodes». Ce dernier correspond à la description du cas d utilisation du chapitre 4.3 et représente l action 11 du scénario principal. L implémentation des événements du Controller permet de rendre la page web plus dynamique et d adapter les contrôles à des scénarios moins standards Dans ce projet, ils ont été particulièrement sollicités (cf. ci-dessous). Master Page La mise en page a été réalisée à l aide de Master Pages. Une Master Page permet de partager le même contenu entre plusieurs pages web. Grâce à elle, il est possible de créer, par exemple, une mise en page unifiée ou d afficher le même contenu dans plusieurs pages [Walther 2007, p. 237]. BSU.Master et SpielVariante.Master sont les deux Master Pages utilisées dans ce projet. BSU.Master est appliquée à toutes les pages du site et possède un conteneur de place (PlaceHolder). Dans ce PlaceHolder, il peut y avoir directement le contenu de la page (comme pour la page Default.aspx) ou le deuxième Master Page : SpielVariante.Master. Ce dernier contient le menu de chaque onglet et un PlaceHolder pour le contenu de la page. La figure 33 illustre, comme exemple, les trois différentes parties contenues dans la page «Periode.aspx» : la partie en haut rouge correspond au Master Page BSU.Master, celle de gauche en bleu correspond à SpielVariante.Master, le contenu de la page «Periode.aspx» est affichée en bas à droite. BSU.Master contient le contrôle de login «LoginStatus», les fonctions JavaScript utilisées dans le site, les textes des bulles d informations, le breadcrum et la définition des onglets. Ces deux derniers, tout comme le menu de SpielVariante.Master, sont ajustés dynamiquement dans leur classe C# respective. web.config Le fichier web.config contient les informations de configurations du site web sous forme XML. Les paramètres de sécurités y figurent également. Comme décrit au chapitre 5.4.3, le login est géré par les contrôles Login et LoginStatus se situant respectivement dans la page login.aspx et le fichier BSU.Master.

93 6. Implémentation et Tests 83 Web.sitemap Comme décrit au chapitre 5.4.3, la navigation utilise le fichier XML Web.sitemap et le contrôle SiteMapPath pour afficher le bread crumb. L ajustement dynamique de ce dernier à la structure configurable du site est fait par le Controller. Periode.aspx BSU.Master SpielVariante.Master Figure 32 : La composition de la page «Periode» Quelques détails d implémentation Autant la programmation de scénarios standards en ASP.NET est très facile à réaliser, autant, lorsqu il s agit de sortir des chantiers battus, les choses se compliquent fortement. Les quelques exemples suivants illustrent ces faits. C est dans le DAL qu il sera déterminé avec quelles tables de la base de données les entités devront être reliées. Le DAL détient ses informations depuis le BLL. Ce dernier est responsable, lors de l appel d une fonction concernant la variante de jeu (p. ex. PMS) d appeler à son tour les fonctions relatives à chacun des jeux Classic et Derivative composant la variante de jeu. L appel initial des fonctions se fait depuis la couche de présentation. C est, en effet, dans cette dernière que chaque opération (création, mise à jour, effacement) effectuée sera directement associée à un jeu ou à une variante de jeu. Ainsi lors de, par exemple, la sélection d une action, il sera toujours nécessaire de préciser non seulement l ID de l action, mais aussi avec quel jeu ou variante de jeu elle est reliée. L ObjectDataSource (cf. chapitre 5.4.1) a besoin de connaître les méthodes de création, mise à jour et effacement du BLL pour pouvoir travailler. Grâce à son attribut

94 6. Implémentation et Tests 84 «DataObjectTypeName», il lui est possible de prendre en paramètre directement des objets. Le problème c est que, lorsque l ObjectDataSource travaille avec des objets, il lui est possible de prendre, certes, d autres paramètres pour la méthode de sélection, mais pas pour la méthode de mise à jour. Cela lui est impossible, même en passant par le code C#. La seule solution serait de ne pas travailler avec des objets, ce qui demanderait de passer une à une chaque valeur de chaque objet et de renoncer aux avantages offerts par la programmation Orientée objet (OO). Ceci revient à dire qu il est possible de demander la mise à jour, par exemple, d un titre avec un ID spécifique ; mais qu il n est pas possible de lui dire à quel jeu ce titre appartient. Il a donc fallu trouver une astuce pour quand même transmettre au DAL l identité du jeu associé. Ceci a été fait en rajoutant au BLL deux variables : currentspiel : représente le jeu currentspielviante : représente la variante de jeu Le Code source 2 montre le code rajouté au BLL. On y voit les deux variables et leur «setter» respectif. Code source 2 : Les variables currentspielvariante et spielvariante du BLL Ces variables sont actualisées depuis la couche de présentation avant chaque mise à jour grâce à l implémentation de l évènement OnUpdating. Ce dernier est déclenché juste avant chaque mise à jour.

95 6. Implémentation et Tests 85 Le Code source 3 montre comment les valeurs sont prises depuis le Controller pour les passer au BLL. Code source 3 : fonction updating déclenchée lors de l évènement OnUpdating Toutes les fonctions d insertion et de mise à jour «save» du BLL prennent, dès lors, seulement l objet à mettre à jour en paramètre et retire l information concernant le jeu depuis la variable currentspiel (cf. Code source 4). Code source 4 : fonction «save» du BLL Cette façon de procéder permet, certes, de détourner le problème de paramètre de la fonction update ; mais le BLL étant une classe statique, il restreint l utilisation du site en écriture à un seul utilisateur. Cette restriction n est, dans le cas de la BSU, pas problématique, étant donné que seul un administrateur du jeu détiendra les droits de configuration du jeu (cf. chapitre 6.1). Un autre problème survenu lors de la programmation concerne l insertion de nouvelles actions dans la page «Aktie.aspx». L entité «Action» étant un type abstrait (cf. chapitre 5.4.5), il est possible en tant que tel de le mettre à jour, de l effacer ; mais il n est pas possible ni de créer un type abstrait «Action», ni de mettre à jour sa catégorie d actions (Ex : de changer une action étrangère en une action suisse). Pour créer une action, il a fallu mettre comme valeur de l attribut «DataObjectTypeName» d ObjectDataSource un type d action concret (Ex : SMIAktie). Ceci donne l impression au

96 6. Implémentation et Tests 86 ObjectDataSource qu il va créer une action du type concret SMI. Puis, utiliser l événement «OnItemInserting», qui est déclenché juste avant que l action soit insérée, pour changer la nature de l objet au type d action sélectionné par l utilisateur. Le Code source 5 montre l implémentation de la fonction de l événement OnItemInserting. Code source 5 : L utilisation de l événement «OnItemInserting» En ce qui concerne le changement de catégorie d action, LINQ ne permettant pas de le faire, il aurait été possible de l implémenter avec une commande SQL de plus bas niveau. Ceci n a cependant pas été jugé nécessaire ; il n est dès lors pas possible pour un utilisateur de changer la catégorie d une action une fois celle-ci créée. Le dernier point délicat commenté dans ce rapport concerne les entités «Option» et «OpionDetails». Comme commenté au chapitre 5.4.5, ces deux entités ne devraient en former qu une si LINQ to SQL le permettait. La solution implémentée a permis, néanmoins, de les relier par une association (cf. figure 29). L ObjectDatasource de la page «Option.aspx» possède comme unique valeur de l attribut «DataObjectTypeName» l entité «Option», c.-à-d. toutes les opérations d insertion, de mise à jour et d effacement auront comme paramètre l entité «Option». A chacune de ces opérations, la fonction de l événement correspondant devra effectuer les mêmes opérations, par derrière, également sur l entité «OptionDetails» pour qu une option «entière» (OptionDetails inclus) soit traitée. Le code de ces fonctions étant trop grand pour être inclus dans ce rapport, il se trouve dans les fonctions «inserting», «deleting» et «updating» du fichier Option.aspx.cs disponible sur le CD accompagnant ce rapport.

97 6. Implémentation et Tests Le projet «BLL» Structure générale Comme expliqué au chapitre 5.4.1, la couche de logique métier a été implémentée sous forme de projet de librairie C#. Les fichiers et dossiers composant ce projet sont illustrés dans la figure 34. Figure 33 : Dossiers et fichiers composant le projet «BLL» Références La couche BLL possède des références uniquement sur le modèle d objets contenu dans les projets «Entities» et «CommonObjects» ainsi que sur la couche «DAL», conformément à une architecture en trois couches stricte (cf. chapitre 5.4.1). Classes C# Deux classes composent le projet BLL : BLLFacade.cs : contient toutes les méthodes de logique métier appelées par la couche de présentation. Les méthodes de mise à jour, création et effacement d entités en font, entre autres, partie. Elle est implémentée en tant que classe statique. Comparison.cs : contient tous les comparateurs nécessaires à l implémentation du tri dans la couche de présentation. Comme expliquées au chapitre 5.4.1, l utilisation de l ObjectDataSource dans notre architecture contraint à l implémentation manuelle du tri. Quelques détails d implémentation Une particularité dans l implémentation du DAL consiste en l existence des variables «currentspiel» et «currentspielvariante» discutée au point

98 6. Implémentation et Tests Le projet «DAL» Structure générale Comme expliqué au chapitre 5.4.1, la couche d accès aux données a été implémentée sous forme de projet de librairie C#. Les fichiers et dossiers composant ce projet sont illustrés dans la figure 35. Figure 34 : Dossiers et fichiers composant le projet «DAL» Références La couche DAL possède des références uniquement sur le modèle d objets contenu dans les projets «Entities» et «CommonObjects», conformément à une architecture en trois couches stricte (cf. chapitre 5.4.1). Classes C# La couche DAL a été implémentée en utilisant, entre autres, le pattern «Facade». Ce patron de conception permet de cacher un sous-système derrière un seul objet. Ce dernier présente une unique interface unifiée et porte la responsabilité de collaborer avec les composants du sous-système [Larman 2006, p. 462].

99 6. Implémentation et Tests 89 Le fichier DALFacade.cs avec son interface IDALFacade.cs représente l objet Facade et enveloppe ainsi le sous-système composé des classes : KategorienManager.cs : implémente le sous-système responsable des fonctions relatives aux entités «Kategorien», PeriodenManager.cs : implémente le sous-système responsable des fonctions relatives aux entités «Periode», SpielerManager.cs: implémente le sous-système responsable des fonctions relatives aux entités «Spieler», SpielManager.cs: implémente le sous-système responsable des fonctions relatives aux entités «Spiel», TitelManger.cs: implémente le sous-système responsable des fonctions relatives aux entités «Titel». Dal.xml Le rôle du fichier DAL.xml ainsi que le fonctionnement de chaque composant impliqué dans le processus de ORM sont expliqués au chapitre Le DALFacade lit les informations concernant les jeux depuis le fichier DAL.xml et, pour chaque jeu, instancie toute la liste des Managers ci-dessus. Ces derniers sont reliés chacun à leur DataContext, lequel leur fournit, depuis la base de données, les entités de leur jeu respectif. Le DALFacade parse également le fichier DAL.xml pour pouvoir instancier les objets des classes BSUSpiel et BSUSpielVariante contenues dans CommonObejcts (cf. chapitre 6.1.5). Quelques détails d implémentation L implémentation de la couche DAL avec LINQ to SQL illustre à quel point ce dernier est plus approprié à un scénario de développement RAD qu à la création d une architecture trois couches. Le premier obstacle rencontré réside dans la mise à jour des entités dans la base de données. Dans une première phase, les objets ont été créés à partir de la base de données et passés jusqu à la couche de présentation sous forme de liste d objets. Ils ont ainsi été détachés de leur DataContext (duquel ils n auraient pas été détachés dans un scénario RAD). L exemple du Code source 5 montre la fonction du DAL implémentée dans le TitelManager pour chercher toutes les devises. On y reconnaît l appel au DataContext pour récupérer la table d entités «Titel» et la requête LINQ pour récupérer uniquement les titres

100 6. Implémentation et Tests 90 correspondant à des devises. Il est important de remarquer que la requête est exécutée à l intérieur du DAL et retourne une liste d objets, conformément au principe d une architecture trois couches. Code source 6 : l implémentation de la fonction getalldevisen() Dans une seconde étape, une entité «Devise» a été modifiée dans la couche de présentation et la fonction de mise à jour du DAL a été appelée. Lors de cet appel, l objet était donc détaché de son DataContext. Le problème c est que LINQ to SQL veut gérer tous les objets à travers du DataContext afin que tous les changements faits puissent être suivis et enregistrés ultérieurement dans la base de données [Strahl 2007]. Beaucoup d implémentations différentes de la fonction de mise à jour ont été testées. La seule ayant fonctionné est celle illustrée dans le Code source 7. Elle implique que l entité à mettre à jour soit recréée depuis la base de données (cette entité sera ainsi attachée au DataContext) et que les valeurs de l entité passée en paramètre (qui, elle est détachée du DataContext) soient mise à jour une à une. Cette solution n est peut-être pas optimale ; mais elle comporte, néanmoins, l avantage de fonctionner. Le dernier point documenté dans ce rapport concerne la table de la base de données contenant les périodes de jeu (table 0x_Periode, «x» étant le numéro du jeu). Cette dernière est la seule table dont les ID doivent commencer à 0 et être consécutifs. Lorsque des entrées sont effacées de la table, la base de données continue à incrémenter la valeur des ID suivants. LINQ to SQL ne permettant pas de réinitialiser les ID, il a fallu utiliser une fonction de plus bas niveau SQL pour pouvoir garantir que les ID puissent être remis à zéro. Après chaque effacement de périodes, la fonction SQL réinitialise donc le compteur d ID à zéro.

101 6. Implémentation et Tests 91 Code source 7 : L implémentation de la fonction de mise à jour des devises Le projet «Entities» Structure générale Comme expliqué au chapitre 5.4.1, le modèle d objets sert à passer des informations entre les couches. Il est composé des projets «CommonObjects» et «Entities». Les fichiers et dossiers composant le projet «Entities» sont illustrés dans la figure 36. Ce dernier est implémenté sous forme de projet de librairie C#. Références Le modèle d objets ne fait référence à aucun autre projet. Classes C# La classe entities_ cs contient les classes représentant les informations de la base de données. Elle a été générée grâce à l outil SqlMetal et au designer de LINQ to SQL. Dans une première étape, le diagramme d entités (fichier bsu_ dbml) a été créé depuis la base de données en utilisant SqlMetal. Il a été, ensuite, modifié dans le designer pour obtenir

102 6. Implémentation et Tests 92 le diagramme d entités de la figure 29. Sur la base de ce dernier, SqlMetal a créé la classe entities_ cs et les fichiers de mappage (cf. chapitre 5.4.5). Figure 35 : Dossiers et fichiers composant le projet «Entities» Le projet «CommonObjects» Structure générale Le projet «CommonObjects» fait partie du modèle d objets du système. Il est implémenté sous forme de projet de librairie C#. Les fichiers et dossiers composant ce projet sont illustrés dans la figure 37. Références Le modèle d objets ne fait référence à aucun autre projet. Classes C# Les classes BsuSpiel et BsuSpielVariante représentent les jeux et les variantes de jeux. Les données du DAL.xml sont utilisées pour créer leurs instances. Figure 36 : Dossiers et fichiers composant le projet «CommonObjects»

ACTIONS ET OBLIGATIONS Les placements financiers en quelques mots

ACTIONS ET OBLIGATIONS Les placements financiers en quelques mots Aperçu des actions et des obligations Qu est-ce qu une action? Une action est une participation dans une entreprise. Quiconque détient une action est copropriétaire (actionnaire) de l entreprise (plus

Plus en détail

CHAPITRE 17. Opérations relatives aux titres. - Les bourses sont des marchés qui fonctionnent dans le cadre du jeu de l offre et de la demande.

CHAPITRE 17. Opérations relatives aux titres. - Les bourses sont des marchés qui fonctionnent dans le cadre du jeu de l offre et de la demande. CHAPITRE 17 Opérations relatives aux titres - Les bourses sont des marchés qui fonctionnent dans le cadre du jeu de l offre et de la demande. - Il y a par ex: o Bourses des valeurs pour le commerce des

Plus en détail

Performance creates trust

Performance creates trust Performance creates trust Vontobel Mini Futures Futures Investissement minimum, rendement maximum Vontobel Investment Banking Vontobel Mini Futures Investir un minimum pour un maximum de rendement Avec

Plus en détail

COMPRENDRE LA BOURSE

COMPRENDRE LA BOURSE COMPRENDRE LA BOURSE Les options Ce document pédagogique n est pas un document de conseils pour investir en bourse. Les informations données dans ce document sont à titre informatif. Vous êtes seul responsable

Plus en détail

Avertissement sur les risques liés aux instruments financiers Clients professionnels

Avertissement sur les risques liés aux instruments financiers Clients professionnels Avertissement sur les risques liés aux instruments financiers Clients professionnels 07/10/2014 Le présent document énonce les risques associés aux opérations sur certains instruments financiers négociés

Plus en détail

En millions CHF ou selon indication 2014 2013

En millions CHF ou selon indication 2014 2013 32 Distribution de dividendes Les réserves distribuables sont déterminées sur la base des capitaux propres statutaires de la maison mère Swisscom SA et non sur les capitaux propres figurant dans les états

Plus en détail

La présente recommandation s applique pour la première fois aux périodes annuelles ouvertes à compter du 1 er janvier 2007 ou ultérieurement.

La présente recommandation s applique pour la première fois aux périodes annuelles ouvertes à compter du 1 er janvier 2007 ou ultérieurement. Umbruch franz. 30.8.2006 16:06 Uhr Seite 183 Instruments financiers dérivés La présente recommandation s applique pour la première fois aux périodes annuelles ouvertes à compter du 1 er janvier 2007 ou

Plus en détail

Options. Brochure destinée aux investisseurs particuliers BASIC. Société du groupe KBC. Publié par KBC Securities en collaboration avec Euronext

Options. Brochure destinée aux investisseurs particuliers BASIC. Société du groupe KBC. Publié par KBC Securities en collaboration avec Euronext Brochure destinée aux investisseurs particuliers Publié par KBC Securities en collaboration avec Euronext p. 2 Index 1. Options call et put 3 2. Acheteur et vendeur 4 3. Standardisation 5 Valeur sous-jacente

Plus en détail

Produits financiers dérivés. Octobre 2007

Produits financiers dérivés. Octobre 2007 Produits financiers dérivés Octobre 2007 Plan Généralités sur les produits dérivés Les contrats Forward Les contrats Futures Les swaps Les options «plain vanilla» Les options exotiques Page 2 Généralités

Plus en détail

Tarif. Placements et conseils financiers

Tarif. Placements et conseils financiers Tarif Placements et conseils financiers Tables des matières 4/5 Mandat de conseil «BCVs Supervision» 6/7 Mandat de gestion «BCVs Star Select» 8/9 Mandat de gestion «BCVs Active Portfolio» 10 Mandat de

Plus en détail

Reverse Convertibles

Reverse Convertibles Reverse Convertibles Le prospectus d émission du titre de créance complexe a été approuvé par la Bafin, régulateur Allemand, en date du 24 Novembre 2010. Ce document à caractère promotionnel est établi

Plus en détail

Chapitre 5 : produits dérivés

Chapitre 5 : produits dérivés Chapitre 5 : produits dérivés 11.11.2015 Plan du cours Options définition profil de gain à l échéance d une option déterminants du prix d une option Contrats à terme définition utilisation Bibliographie:

Plus en détail

SIMULATEUR DE NÉGOCIATION TMX GUIDE PRATIQUE. Reshaping Canada s Equities Trading Landscape

SIMULATEUR DE NÉGOCIATION TMX GUIDE PRATIQUE. Reshaping Canada s Equities Trading Landscape SIMULATEUR DE NÉGOCIATION TMX GUIDE PRATIQUE Reshaping Canada s Equities Trading Landscape OCTOBER 2014 Horaire des marchés Toutes les données de marché du simulateur sont différées de 15 minutes (sauf

Plus en détail

Gestion de portefeu ille

Gestion de portefeu ille CYCLE SUPERIEUR AUDIT ET CONTRÔLE DE GESTIO Semestre : 8 Module : Gestion de portefeu ille Évaluation des actifs à revenu fixe I- Mesure du rendement des obligations II- Les risques de placement des titres

Plus en détail

FINANCE DE MARCHÉ Devoir n 1 novembre 2002

FINANCE DE MARCHÉ Devoir n 1 novembre 2002 FINANCE DE MARCHÉ Devoir n 1 novembre 2002 Exercice 1 Le 13 octobre (N), votre responsable financier vous donne l ordre de vendre au SRD 50 actions ZZZ au cours limite de 180. a- Expliquer en quoi consiste

Plus en détail

LES FONDS D INVESTISSEMENT. La façon la plus accessible de diversifier vos placements

LES FONDS D INVESTISSEMENT. La façon la plus accessible de diversifier vos placements LES FONDS D INVESTISSEMENT La façon la plus accessible de diversifier vos placements Gestion professionnelle, diversification et liquidité De plus en plus de gens prennent conscience de la différence entre

Plus en détail

INSTRUMENTS FINANCIERS ET RISQUES ENCOURUS

INSTRUMENTS FINANCIERS ET RISQUES ENCOURUS INSTRUMENTS FINANCIERS ET RISQUES ENCOURUS L objet de ce document est de vous présenter un panorama des principaux instruments financiers utilisés par CPR AM dans le cadre de la fourniture d un service

Plus en détail

1741 SWITZERLAND EQUAL WEIGHTED INDEX. Règlement

1741 SWITZERLAND EQUAL WEIGHTED INDEX. Règlement 1741 SWITZERLAND EQUAL WEIGHTED INDEX Règlement Version du 01.07.2015 SOMMAIRE 1 Introduction 3 2 Spécifications de l indice 4 3 Univers de l indice 5 4 Adaptations périodiques ordinaire 6 5 Adaptations

Plus en détail

Cornèr Banque (Luxembourg) S.A. Risques associés aux profils de gestion

Cornèr Banque (Luxembourg) S.A. Risques associés aux profils de gestion Cornèr Banque (Luxembourg) S.A. Risques associés aux profils de gestion 1 Introduction Gestion patrimoniale mobilière Gestion patrimoniale fonds d investissement Gestion en placements alternatifs Gestion

Plus en détail

Commerzbank AG Certificats Factors

Commerzbank AG Certificats Factors Commerzbank AG Certificats Factors Corporates & Markets Produits présentant un risque de perte en capital. Les instruments dérivés présentés sont soumis à des risques (voir les facteurs de risque sur la

Plus en détail

Formation ESSEC Gestion de patrimoine

Formation ESSEC Gestion de patrimoine Formation ESSEC Gestion de patrimoine Séminaire «Savoir vendre les nouvelles classes d actifs financiers» Les options Plan Les options standards (options de 1 ère génération) Les produits de base: calls

Plus en détail

Comptes statutaires résumés Groupe Delhaize SA

Comptes statutaires résumés Groupe Delhaize SA Comptes statutaires résumés Groupe Delhaize SA Le résumé des comptes annuels de la société Groupe Delhaize SA est présenté ci-dessous. Conformément au Code des Sociétés, les comptes annuels complets, le

Plus en détail

AVERTISSEMENT ET INFORMATION SUR LES RISQUES LIES A LA NEGOCIATION DES CONTRATS A TERME ET DES ACTIONS

AVERTISSEMENT ET INFORMATION SUR LES RISQUES LIES A LA NEGOCIATION DES CONTRATS A TERME ET DES ACTIONS Le présent document énonce les risques associés aux opérations sur certains instruments financiers négociés par Newedge Group S.A. pour le compte d un client «le Client». Le Client est informé qu il existe

Plus en détail

Juillet 2007. Directives concernant l information des investisseurs sur les produits structurés

Juillet 2007. Directives concernant l information des investisseurs sur les produits structurés Juillet 2007 Directives concernant l information des investisseurs sur les produits structurés Directives concernant l information des investisseurs sur les produits structurés Table des matières Préambule...

Plus en détail

Principes de Finance

Principes de Finance Principes de Finance 12. Théorie des options I Daniel Andrei Semestre de printemps 211 Principes de Finance 12. Théorie des options I Printemps 211 1 / 43 Plan I Introduction II Comprendre les options

Plus en détail

Méthodes de la gestion indicielle

Méthodes de la gestion indicielle Méthodes de la gestion indicielle La gestion répliquante : Ce type de gestion indicielle peut être mis en œuvre par trois manières, soit par une réplication pure, une réplication synthétique, ou une réplication

Plus en détail

Norme comptable relative aux placements dans les entreprises d assurances et/ou de réassurance NC31

Norme comptable relative aux placements dans les entreprises d assurances et/ou de réassurance NC31 Norme comptable relative aux placements dans les entreprises d assurances et/ou de réassurance NC31 OBJECTIF DE LA NORME 01 L entreprise d assurance et/ou de réassurance doit disposer à son actif, en couverture

Plus en détail

reverse exchangeable notes Guide Explicatif

reverse exchangeable notes Guide Explicatif reverse exchangeable notes Guide Explicatif www.warrants.commerzbank.com Un coupon attrayant? De plus en plus d investisseurs découvrent les avantages des Reverse Exchangeable Notes (REN) avec un coupon

Plus en détail

Options, Futures, Parité call put

Options, Futures, Parité call put Département de Mathématiques TD Finance / Mathématiques Financières Options, Futures, Parité call put Exercice 1 Quelle est la différence entre (a) prendre une position longue sur un forward avec un prix

Plus en détail

COMPRENDRE LA BOURSE

COMPRENDRE LA BOURSE COMPRENDRE LA BOURSE Les positions vendeuses sur les options, ou vente d options Ce document pédagogique n est pas un document de conseils pour investir en bourse. Les informations données dans ce document

Plus en détail

FICHE. L évaluation d une obligation 1 DÉFINITION D UNE OBLIGATION 2 LES CARACTÉRISTIQUES D UNE OBLIGATION

FICHE. L évaluation d une obligation 1 DÉFINITION D UNE OBLIGATION 2 LES CARACTÉRISTIQUES D UNE OBLIGATION L évaluation d une obligation FICHE 2 1 DÉFINITION D UNE OBLIGATION Une obligation est un titre de créances négociables représentatif d une fraction d un emprunt émis par l État ou par une entreprise.

Plus en détail

Les obligations. S. Chermak infomaths.com

Les obligations. S. Chermak infomaths.com Les obligations S. Chermak Infomaths.com Saïd Chermak infomaths.com 1 Le marché des obligations est un marché moins médiatique mais tout aussi important que celui des actions, en terme de volumes. A cela

Plus en détail

Comprendre les produits structurés

Comprendre les produits structurés Comprendre les produits structurés Sommaire Page 3 Introduction Page 4 Qu est-ce qu un produit structuré? Quels sont les avantages des produits structurés? Comment est construit un produit structuré? Page

Plus en détail

Titres RBC liés à des obligations de sociétés non protégés avec remboursement de capital, série 1F

Titres RBC liés à des obligations de sociétés non protégés avec remboursement de capital, série 1F RBC Marchés des Juin 2014 TITRES LIÉS À DES TITRES D EMPRUNT I SOLUTIONS DE PLACEMENT GLOBALES RBC Titres RBC liés à des obligations de sociétés non protégés avec remboursement de capital, série 1F Durée

Plus en détail

Distribution 2013 Dividende en actions Information aux actionnaires Résumé

Distribution 2013 Dividende en actions Information aux actionnaires Résumé Distribution 2013 Dividende en actions Information aux actionnaires Résumé 20 mars 2013 Disclaimer Le présent document ne constitue pas une offre de vente ou une incitation à souscrire des titres de Credit

Plus en détail

ECOLE DES HAUTES ETUDES COMMERCIALES DE L UNIVERSITE DE LAUSANNE. Professeur Matière Session. A. Ziegler Principes de Finance Automne 2005

ECOLE DES HAUTES ETUDES COMMERCIALES DE L UNIVERSITE DE LAUSANNE. Professeur Matière Session. A. Ziegler Principes de Finance Automne 2005 ECOLE DES HAUTES ETUDES COMMERCIALES DE L UNIVERSITE DE LAUSANNE Professeur Matière Session A. Ziegler Principes de Finance Automne 2005 Date: Lundi 12 septembre 2005 Nom et prénom:... Note:... Q1 :...

Plus en détail

Rachat d'actions de Logitech International S.A. Modification du programme de rachat du 10 août 2010

Rachat d'actions de Logitech International S.A. Modification du programme de rachat du 10 août 2010 Rachat d'actions de Logitech International S.A. Modification du programme de rachat du 10 août 2010 Le 10 août 2010, Logitech International S.A., Apples (la «Société» ou «Logitech»), a initié un programme

Plus en détail

Exercice du cours Gestion Financière à Court Terme : «Analyse d un reverse convertible»

Exercice du cours Gestion Financière à Court Terme : «Analyse d un reverse convertible» Exercice du cours Gestion Financière à Court Terme : «Analyse d un reverse convertible» Quand la trésorerie d une entreprise est positive, le trésorier cherche le meilleur placement pour placer les excédents.

Plus en détail

Finance de marché Thèmes abordés Panorama des marches de capitaux Fonctionnement des marchés de capitaux Le marché des obligations Le marchés des

Finance de marché Thèmes abordés Panorama des marches de capitaux Fonctionnement des marchés de capitaux Le marché des obligations Le marchés des FINANCE DE MARCHE 1 Finance de marché Thèmes abordés Panorama des marches de capitaux Fonctionnement des marchés de capitaux Le marché des obligations Le marchés des actions Les marchés dérivés Les autres

Plus en détail

Énoncé des principes et objectifs de placement du portefeuille à long terme de l Université d Ottawa

Énoncé des principes et objectifs de placement du portefeuille à long terme de l Université d Ottawa Énoncé des principes et objectifs de placement du portefeuille à long terme de l Université d Ottawa 1. But de l Énoncé L Énoncé des principes et objectifs de placement («l EPOP») décrit les objectifs,

Plus en détail

Economie Monétaire et Financière

Economie Monétaire et Financière Economie Monétaire et Financière Jézabel Couppey- Soubeyran et Bruno Tinel Université Paris 1 Panthéon- Sorbonne Licence 2 ème année. Dossier de TD n 3 : Taux d intérêt Partie I : Capitalisation et actualisation

Plus en détail

Comparaison du Règlement de dépôt ancien et nouvel de Credit Suisse AG

Comparaison du Règlement de dépôt ancien et nouvel de Credit Suisse AG Comparaison du Règlement de dépôt ancien et nouvel de Credit Suisse AG Règlement de dépôt ancien (12.2011) Règlement de dépôt nouveau (12.2013) Règlement de dépôt Dispositions générales Art. 1 Champ d

Plus en détail

1741 SWITZERLAND EQUAL WEIGHTED INDEX

1741 SWITZERLAND EQUAL WEIGHTED INDEX 1741 Switzerland Index Series 1741 SWITZERLAND EQUAL WEIGHTED INDEX Règlement Version du 01.07.2015 1741 Switzerland Equal Weighted Index 2 SOMMAIRE 1 Introduction 3 2 Spécifications de l indice 4 3 Univers

Plus en détail

A l attention des porteurs de parts français du fonds commun de placement «EasyETF Stoxx Europe 600»

A l attention des porteurs de parts français du fonds commun de placement «EasyETF Stoxx Europe 600» Paris, le 8 août 2013 A l attention des porteurs de parts français du fonds commun de placement «EasyETF Stoxx Europe 600» Madame, Monsieur, Vous êtes détenteurs de parts du fonds commun de placement (FCP)

Plus en détail

Amendements de la Norme internationale d information financière 7 Instruments financiers: Informations à fournir

Amendements de la Norme internationale d information financière 7 Instruments financiers: Informations à fournir Amendements de la Norme internationale d information financière 7 Instruments financiers: Informations à fournir Le paragraphe 27 est modifié. Les paragraphes 27A et 27B sont ajoutés. Importance des instruments

Plus en détail

la force d un placement la certitude d un coupon élevé

la force d un placement la certitude d un coupon élevé placements la force d un placement la certitude d un élevé optinote multiwin brut de durant 5 ans protection du capital liée à l période de souscription du 9 mai 2011 au 8 juillet 2011 clôture anticipée

Plus en détail

RISQUES ET NATURE SPECIFIQUES DES PRINCIPAUX INSTRUMENTS FINANCIERS

RISQUES ET NATURE SPECIFIQUES DES PRINCIPAUX INSTRUMENTS FINANCIERS RISQUES ET NATURE SPECIFIQUES DES PRINCIPAUX INSTRUMENTS FINANCIERS La présente section vise à vous communiquer, conformément à la Directive, une information générale relative aux caractéristiques des

Plus en détail

LES TURBOS. Investir avec du levier sur les indices et les actions!

LES TURBOS. Investir avec du levier sur les indices et les actions! LES TURBOS Investir avec du levier sur les indices et les actions! Produits présentant un risque de perte en capital, à destination d investisseurs avertis. Émetteur : BNP Paribas Arbitrage Issuance B.V.

Plus en détail

I. Étude comparative des Compartiments absorbé et absorbant

I. Étude comparative des Compartiments absorbé et absorbant Amundi Funds Société d investissement à capital variable de droit luxembourgeois Siège social : 5, Allée Scheffer L-2520 Luxembourg R.C.S. de Luxembourg B-68.806 (la «Société») Cher Actionnaire, Luxembourg,

Plus en détail

NoventusCollect. Règlement de placement Selon les disposition de l ordonnance OPP 2

NoventusCollect. Règlement de placement Selon les disposition de l ordonnance OPP 2 NoventusCollect Règlement de placement Selon les disposition de l ordonnance OPP 2 Édition 2004 Placements en pool de type K Table des matières A Généralités 3 Art. 1 Objectifs de la politique de placement

Plus en détail

Mardi 23 octobre 2007. Séminaire. Schumann-bourse

Mardi 23 octobre 2007. Séminaire. Schumann-bourse Mardi 23 octobre 2007 Séminaire Schumann-bourse La Bourse : environnement économique et monétaire Définition de la bourse et de son rôle dans l'économie Influence des taux d'intérêts Déterminer les cycles

Plus en détail

Chapitre 2 : l évaluation des obligations

Chapitre 2 : l évaluation des obligations Chapitre 2 : l évaluation des obligations 11.10.2013 Plan du cours Flux monétaires, prix et rentabilité Bibliographie: caractéristiques générales Berk, DeMarzo: ch. 8 obligations zéro-coupon obligations

Plus en détail

Schéma F Description de la valeur pour options standard 1 RENSEIGNEMENTS GÉNÉRAUX RELATIFS AUX ÉMETTEURS OU AUX DONNEURS DE SÛRETÉS...

Schéma F Description de la valeur pour options standard 1 RENSEIGNEMENTS GÉNÉRAUX RELATIFS AUX ÉMETTEURS OU AUX DONNEURS DE SÛRETÉS... Table des matières Schéma F Description de la valeur pour options standard Table des matières Schéma F Description de la valeur pour options standard 1 RENSEIGNEMENTS GÉNÉRAUX RELATIFS AUX ÉMETTEURS OU

Plus en détail

COMPRENDRE LA BOURSE

COMPRENDRE LA BOURSE COMPRENDRE LA BOURSE La fiscalité simplifiée des valeurs mobilières Ce document pédagogique n est pas un document de conseils pour investir en bourse. Les informations données dans ce document sont à titre

Plus en détail

Exchange Traded Funds (ETF) Mécanismes et principales utilisations. 12 Mai 2011

Exchange Traded Funds (ETF) Mécanismes et principales utilisations. 12 Mai 2011 Exchange Traded Funds (ETF) Mécanismes et principales utilisations 12 Mai 2011 Sommaire I Présentation du marché des ETF II Construction des ETF III Principales utilisations IV Les ETF dans le contexte

Plus en détail

Multi Defender VONCERT

Multi Defender VONCERT Multi Defender VONCERT sur le SMI, EuroStoxx 50 et le S&P 500 Vous souhaitez profiter de la hausse de cours potentielle de grands indices boursiers sans pour autant exclure des corrections de cours? Le

Plus en détail

Comment prendre soin de son argent? Programme de préparation à la retraite 26 mars 2010 Marie-Pierre Fleury

Comment prendre soin de son argent? Programme de préparation à la retraite 26 mars 2010 Marie-Pierre Fleury Comment prendre soin de son argent? Programme de préparation à la retraite 26 mars 2010 Marie-Pierre Fleury Menu Introduction Devises Taux d intérêt Immobilier Obligations Actions Fonds de placement Fiscalité

Plus en détail

RÉSUMÉ (TRADUCTION) Credit Suisse International

RÉSUMÉ (TRADUCTION) Credit Suisse International RÉSUMÉ (TRADUCTION) Credit Suisse International Notes zéro coupon, liées à un indice, remboursables automatiquement, d un montant maximum total de EUR 100.000.000, échéance 2011, Série NCSI 2006 469 ISIN

Plus en détail

DISCOUNTED CASH-FLOW

DISCOUNTED CASH-FLOW DISCOUNTED CASH-FLOW Principes généraux La méthode des flux futurs de trésorerie, également désignée sous le terme de Discounted Cash Flow (DCF), est très largement admise en matière d évaluation d actif

Plus en détail

PRISMA Risk Budgeting Line 5

PRISMA Risk Budgeting Line 5 Fiche d information 1 er octobre2015 PRISMA Fondation Place Saint-Louis 1 Case postale 1110 Morges 1 www.prisma-fondation.ch info@prisma-fondation.ch Tél. 0848 106 106 Fax 0848 106 107 Fiche d information

Plus en détail

Souscrire ou acheter des obligations

Souscrire ou acheter des obligations 034 Souscrire ou acheter des obligations L e s M i n i - G u i d e s B a n c a i r e s Juillet 2009 Sommaire 2 4 6 8 12 16 20 24 Souscrire ou acheter des obligations Qu est-ce qu une obligation cotée?

Plus en détail

RAPPORT INTERMÉDIAIRE DE LA DIRECTION SUR LE RENDEMENT DU FONDS OBLIGATIONS CANADIENNES FMOQ AU 30 juin 2015

RAPPORT INTERMÉDIAIRE DE LA DIRECTION SUR LE RENDEMENT DU FONDS OBLIGATIONS CANADIENNES FMOQ AU 30 juin 2015 RAPPORT INTERMÉDIAIRE DE LA DIRECTION SUR LE RENDEMENT DU FONDS OBLIGATIONS CANADIENNES FMOQ AU 30 juin 2015 Le présent Rapport intermédiaire de la direction sur le rendement du Fonds obligations canadiennes

Plus en détail

LES MARCHÉS DÉRIVÉS DE CHANGE. Finance internationale 9éme ed. Y. Simon & D. Lautier

LES MARCHÉS DÉRIVÉS DE CHANGE. Finance internationale 9éme ed. Y. Simon & D. Lautier LES MARCHÉS DÉRIVÉS DE CHANGE 1 Section 1. Les instruments dérivés de change négociés sur le marché interbancaire Section 2. Les instruments dérivés de change négociés sur les marchés boursiers organisés

Plus en détail

Certificats Cappés (+) et Floorés (+)

Certificats Cappés (+) et Floorés (+) Certificats Cappés (+) et Floorés (+) Produits présentant un risque de perte en capital, à destination d investisseurs avertis. Pour investir avec du Levier sur les indices CAC 40 ou DAX Même dans un contexte

Plus en détail

Canada. Extrait de : Statistiques bancaires de l'ocde : Notes méthodologiques par pays 2010

Canada. Extrait de : Statistiques bancaires de l'ocde : Notes méthodologiques par pays 2010 Extrait de : Statistiques bancaires de l'ocde : Notes méthodologiques par pays 2010 Accéder à cette publication : http://dx.doi.org/10.1787/bank_country-200-fr Canada Merci de citer ce chapitre comme suit

Plus en détail

QU EST-CE QUE LE FOREX?

QU EST-CE QUE LE FOREX? Chapitre 1 QU EST-CE QUE LE FOREX? 1. INTRODUCTION Forex est la contraction de foreign exchange qui signifie «marché des changes». C est le plus grand marché du monde. Le volume journalier moyen des transactions

Plus en détail

CANDRIAM BONDS Société d Investissement à Capital Variable 14, Porte de France L 4360 Esch-sur-Alzette R.C.S. Luxembourg B-30659 AVIS AUX ACTIONNAIRES

CANDRIAM BONDS Société d Investissement à Capital Variable 14, Porte de France L 4360 Esch-sur-Alzette R.C.S. Luxembourg B-30659 AVIS AUX ACTIONNAIRES AVIS AUX ACTIONNAIRES I) FUSIONS Le conseil d administration de la SICAV Candriam Bonds (ci-après la «SICAV») a décidé, en conformité avec les dispositions de l article 27 des statuts de la SICAV (ci-après

Plus en détail

UNIVERSITÉ DE SFAX École Supérieure de Commerce

UNIVERSITÉ DE SFAX École Supérieure de Commerce UNIVERSITÉ DE SFAX École Supérieure de Commerce Année Universitaire 2003 / 2004 Auditoire : Troisième Année Études Supérieures Commerciales & Sciences Comptables DÉCISIONS FINANCIÈRES Note de cours N 7

Plus en détail

d ETF : Sept règles à suivre

d ETF : Sept règles à suivre The Les buck meilleures stops pratiques here: Vanguard en matière money de négociation market funds d ETF : Sept règles à suivre Etude de Vanguard Décembre 2014 Joel M. Dickson, PhD ; James J. Rowley Jr.,

Plus en détail

PHILEAS L/S EUROPE. Part I EUR Code ISIN : FR0011023910 OPCVM de droit français géré par PHILEAS ASSET MANAGEMENT

PHILEAS L/S EUROPE. Part I EUR Code ISIN : FR0011023910 OPCVM de droit français géré par PHILEAS ASSET MANAGEMENT INFORMATIONS CLES POUR L INVESTISSEUR Ce document fournit des informations essentielles aux investisseurs de cet OPCVM. Il ne s agit pas d un document promotionnel. Les informations qu il contient vous

Plus en détail

SHARE DU COMPARTIMENT SHARE JAPAN

SHARE DU COMPARTIMENT SHARE JAPAN SHARE (ci-après la «Société») Société d Investissement à Capital Variable Siège social : 12, rue Eugène Ruppert, L-2453 Luxembourg R.C.S. Luxembourg N B 28.744 AVIS AUX ACTIONNAIRES DU COMPARTIMENT SHARE

Plus en détail

NOTE 21 TRÉSORERIE ET AUTRES PLACEMENTS DE TRÉSORERIE

NOTE 21 TRÉSORERIE ET AUTRES PLACEMENTS DE TRÉSORERIE NOTE 21 TRÉSORERIE ET AUTRES PLACEMENTS DE TRÉSORERIE Valeur brute Dépréciation Valeur nette Valeur brute Dépréciation Valeur nette Disponibilités 138-138 105-105 Dépôts à terme et assimilés à moins de

Plus en détail

Une opportunité de diversification et des coupons élevés en livre turque.

Une opportunité de diversification et des coupons élevés en livre turque. Crédit Agricole (A+ / Aa3) Une opportunité de diversification et des coupons élevés en livre turque. À QUOI VOUS ATTENDRE? P. Crédit Agricole CIB est une obligation émise en livre turque (TRY) par Crédit

Plus en détail

produits non garantis en capital Négocier en direct vos Warrants, Turbos et Certificats

produits non garantis en capital Négocier en direct vos Warrants, Turbos et Certificats Nouveau Négocier en direct vos Warrants, Turbos et Certificats négocier en direct vos Warrants, Turbos et Certificats Pour la première fois en France, il est possible de négocier en direct les Warrants,

Plus en détail

RÈGLE 3400 RESTRICTIONS ET INFORMATIONS À FOURNIR RELATIVES À LA RECHERCHE

RÈGLE 3400 RESTRICTIONS ET INFORMATIONS À FOURNIR RELATIVES À LA RECHERCHE RÈGLE 3400 RESTRICTIONS ET INFORMATIONS À FOURNIR RELATIVES À LA RECHERCHE Introduction La présente Règle établit les règles que les analystes doivent suivre lorsqu ils publient des rapports de recherche

Plus en détail

AVERTISSEMENT SUR LES RISQUES LIES A LA NEGOCIATION DES CONTRATS A TERME CLIENTS NON PROFESSIONNELS

AVERTISSEMENT SUR LES RISQUES LIES A LA NEGOCIATION DES CONTRATS A TERME CLIENTS NON PROFESSIONNELS Avant d utiliser un contrat à terme (produits dérivés, contrat à terme ferme ou contrat d option) le client (l investisseur) doit apprécier les risques liés a l utilisation de contrats à terme. Il doit

Plus en détail

AGF OCTOPLUS. Caractéristiques financières

AGF OCTOPLUS. Caractéristiques financières Code Isin : FR0007082755 NOTICE D'INFORMATION AGF OCTOPLUS FONDS A FORMULE AVERTISSEMENT Le FCP AGF OCTOPLUS est construit dans la perspective d un investissement sur la durée totale de vie du FCP, et

Plus en détail

SWX Swiss Exchange Directive 16: Taxes (art. 23 RM)

SWX Swiss Exchange Directive 16: Taxes (art. 23 RM) SWX Swiss Exchange, Ce document contient les dispositions relatives aux taxes imputées aux participants par la SWX. Les données figurant dans ce document sont sans effet contraignant et n'engagent en rien

Plus en détail

Circulaire de la Commission fédérale des banques : Obligation de déclarer les transactions boursières

Circulaire de la Commission fédérale des banques : Obligation de déclarer les transactions boursières Circ.-CFB 04/3 Obligation de déclarer Page 1 Circulaire de la Commission fédérale des banques : Obligation de déclarer les transactions boursières (Obligation de déclarer) du 19 août 2004 (Dernière modification

Plus en détail

Indices de stratégie de SIX Structured Products. Les indices de référence pour les produits structurés

Indices de stratégie de SIX Structured Products. Les indices de référence pour les produits structurés Indices de stratégie de SIX Structured Products Les indices de référence pour les produits structurés Misez sur nos indices Stratégie La procédure de sélection Possibilité de comparaison grâce aux indices

Plus en détail

Quels sont les risques sous-jacents liés au trading sur indice boursier?

Quels sont les risques sous-jacents liés au trading sur indice boursier? Indices boursiers Factsheet Introduction Trading sur indice boursier Les indices boursiers proposés sur les plateformes eforex de Swissquote sont des contrats sur dérivés de gré à gré (OTC) dont le sous-jacent

Plus en détail

Dérivés Financiers Caractéristiques des contrats d options

Dérivés Financiers Caractéristiques des contrats d options Dérivés Financiers Caractéristiques des contrats d options Owen Williams Grenoble Ecole de Management Accréditations > 2 Introduction Une option donne au détenteur le droit de faire quelque chose dans

Plus en détail

Fiche info-financière Assurance-vie pour la branche 23 AG Fund+ 1

Fiche info-financière Assurance-vie pour la branche 23 AG Fund+ 1 Fiche info-financière Assurance-vie pour la branche 23 AG Fund+ 1 Type d assurance-vie Assurance-vie individuelle dont le rendement est lié à des fonds d investissement (branche 23). Garanties En cas de

Plus en détail

Dans un premier temps, nous nous limiterons aux actions et aux obligations.

Dans un premier temps, nous nous limiterons aux actions et aux obligations. LA BOURSE 1. GENERALITES 1.1 Définition La bourse est un marché où se réunissent périodiquement acheteurs et vendeurs d un même bien ou service, dans le but d être complètement renseignés sur l état des

Plus en détail

LES TURBOS INFINIS. Investir avec un levier adapté à votre stratégie!

LES TURBOS INFINIS. Investir avec un levier adapté à votre stratégie! LES TURBOS INFINIS Investir avec un levier adapté à votre stratégie! Produits présentant un risque de perte en capital, à destination d investisseurs avertis. Émetteur : BNP Paribas Arbitrage Issuance

Plus en détail

Obligation structurée

Obligation structurée Obligation structurée Une obligation pas comme les autres Sommaire Introduction 5 Nature de l investissement 7 Avantages et inconvénients 7 Mécanismes de performance 8 Avec ou sans protection du capital

Plus en détail

Reporting titre par titre des établissements de crédit

Reporting titre par titre des établissements de crédit Reporting titre par titre des établissements de crédit Banque centrale du Luxembourg Sommaire 1 Introduction...3 2 Les données à transmettre à la BCL...5 2.1 Aperçu général...5 2.2 Les titres soumis à

Plus en détail

Comment prendre soin de son argent? Programme de préparation à la retraite ONU 28 avril 2009 Marie-Pierre Fleury

Comment prendre soin de son argent? Programme de préparation à la retraite ONU 28 avril 2009 Marie-Pierre Fleury Programme de préparation à la retraite ONU 28 avril 2009 Marie-Pierre Fleury Se poser quelques questions : Dans quel pays vais-je vivre? Quels seront mes besoins (somme à évaluer / an)? Que veux-je faire

Plus en détail

Barrier Reverse Convertible

Barrier Reverse Convertible PROSPECTUS SIMPLIFIE Barrier Reverse Convertible Sous-jacents: Nestlé - Novartis - Roche Coupon: 5.30% Barrière In Fine 79.00% - Maturité: 28.04.2017 Ce produit structuré n est pas un placement collectif

Plus en détail

MARCHES FINANCIERS Licence 3 Monnaie Finance Université Panthéon-Assas Paris 2 2014 2015

MARCHES FINANCIERS Licence 3 Monnaie Finance Université Panthéon-Assas Paris 2 2014 2015 MARCHES FINANCIERS Licence 3 Monnaie Finance Université Panthéon-Assas Paris 2 2014 2015 Christophe CHOUARD et Sébastien LOTZ Informations financières omniprésentes: Indices boursiers - CAC 40, DJIA, Euro

Plus en détail

NOTICE MÉTHODOLOGIQUE SUR LES OPTIONS DE CHANGE

NOTICE MÉTHODOLOGIQUE SUR LES OPTIONS DE CHANGE NOTICE MÉTHODOLOGIQUE SUR LES OPTIONS DE CHANGE Avec le développement des produits dérivés, le marché des options de change exerce une influence croissante sur le marché du change au comptant. Cette étude,

Plus en détail

Aperçu des prix des opérations de placement. Édition de janvier 2015

Aperçu des prix des opérations de placement. Édition de janvier 2015 Aperçu des prix des opérations de placement Édition de janvier 2015 2 Aperçu des prix des opérations de placement Remarques générales Remarques générales Votre conseiller/conseillère à la clientèle vous

Plus en détail

Tarifs des principales opérations sur titres

Tarifs des principales opérations sur titres Deutsche Bank Tarifs des principales opérations sur titres Tarifs d application à partir du 01/07/2015 06764 Cette brochure livre un aperçu des tarifs d application pour les opérations les plus courantes

Plus en détail

Swiss Life lance sa huitième unité de compte structurée : Objectif Juillet 2011

Swiss Life lance sa huitième unité de compte structurée : Objectif Juillet 2011 Communiqué de presse 6 mai 2011 Swiss Life lance sa huitième unité de compte structurée : Objectif Juillet 2011 Cet instrument financier, qui est une alternative à un placement risqué en actions, n est

Plus en détail

Mises de fonds et documentation requise

Mises de fonds et documentation requise Mises de fonds et documentation requise VÉRIFICATION DE L AVOIR PROPRE L avoir propre est le montant que l emprunteur verse à titre de mise de fonds à l achat de cette propriété. Les exigences relatives

Plus en détail

g e gamme 2 Les Turbos d investissements in mme d investissements intellig d i ti t i t lli t Que sont les Turbos?

g e gamme 2 Les Turbos d investissements in mme d investissements intellig d i ti t i t lli t Que sont les Turbos? Equity First une gamme d invest First une gamme d investisseme une gamme d investissements in ga d investissements intelligents Eq intelligents Equity First une gam Equity First une gamme d invest First

Plus en détail

COMPRENDRE LA BOURSE

COMPRENDRE LA BOURSE COMPRENDRE LA BOURSE Les obligations Ce document pédagogique ne constitue pas une incitation à investir et n est pas un conseil en investissement. Le Client qui souhaite un conseil en investissement avant

Plus en détail

Chapitre 20. Les options

Chapitre 20. Les options Chapitre 20 Les options Introduction Les options financières sont des contrats qui lient deux parties. Les options existent dans leur principe depuis plusieurs millénaires, mais elles connaissent depuis

Plus en détail

Table des matières. Chapitre 1

Table des matières. Chapitre 1 Table des matières Chapitre 1 Les objectifs de la planification financière et les objectifs de placement 1 Les objectifs de la planification financière personnelle 1 Premier objectif: atteindre un certain

Plus en détail

Catégorie d actif Minimum Cible Maximum. Actions 45 % 55 % 70 % Revenu fixe 20 % 30 % 45 % Alternatifs 0 % 15 % 25 %

Catégorie d actif Minimum Cible Maximum. Actions 45 % 55 % 70 % Revenu fixe 20 % 30 % 45 % Alternatifs 0 % 15 % 25 % Énoncé des principes et objectifs de placement du portefeuille à long terme de l Université d Ottawa 1. But de l Énoncé L Énoncé des principes et objectifs de placement («l EPOP») décrit les objectifs,

Plus en détail