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»