Analyse des Processus de configuration d`un jeu boursier en

Transcription

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
1er rapporteur : Dr. Stefan Hüsemann
2ème rapporteur : Prof. Dr. Martin Wallmeier
Février 2009
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
Table des matières
Table des matières
1
2
INTRODUCTION ...................................................................................................1
1.1
Problématique ...........................................................................................1
1.2
Objectifs ...................................................................................................2
1.3
Façon de procéder .....................................................................................2
LA LOGIQUE MÉTIER: DESCRIPTION DES DIFFÉRENTS OUTILS ET
CARACTÉRISTIQUES À PRENDRE EN COMPTE POUR LA CONFIGURATION D’UN
JEU BOURSIER ...................................................................................................... 4
2.1
Portfolio Management Simulation (PMS) .................................................... 4
2.1.1 Concepts de la simulation .................................................................. 4
2.1.2 Mesures de classification des joueurs................................................. 5
2.2
Les marchés: SWX Swiss Exchange et Eurex.............................................. 7
2.2.1 SWX Swiss Exchange ......................................................................... 7
2.2.2 Eurex ............................................................................................... 14
2.3
Les outils financiers .................................................................................. 18
2.3.1 Actions ............................................................................................. 18
2.3.2 Obligations ...................................................................................... 19
2.3.3 Exchange Traded Funds (ETF) ........................................................ 20
2.3.4 Devises ............................................................................................ 22
2.3.5 Options ............................................................................................ 23
2.4
Les évènements boursiers pouvant perturber le jeu .................................... 26
2.4.1 Split ................................................................................................. 26
2.4.2 Fusion et acquisition ........................................................................ 27
2.4.3 Faillite ............................................................................................. 28
II
Table des matières
3
L’ANALYSE D’UN SYSTÈME D’INFORMATION ..................................................... 29
3.1
Méthodologie de gestion de projets: Rational Unified Process (RUP) ........ 29
3.1.1 RUP: une méthodologie de gestion de projet .................................... 29
3.1.2 Recueil des exigences ....................................................................... 35
3.1.3 Analyse et conception....................................................................... 37
3.1.4 Implémentation et test ...................................................................... 38
3.2
Techniques : Unified Modeling Language (UML) et Prototypage.............. 41
3.2.1 Unified Modeling Language (UML) ................................................. 41
3.2.2 Prototypage ..................................................................................... 45
4
RECUEIL DES EXIGENCES DU SI BSU ................................................................. 48
4.1
Analyse préliminaire ................................................................................. 48
4.2
Le produit: Spécification des exigences logicielles (Software
Requirements Specification) ..................................................................... 48
4.2.1 Cadre ............................................................................................... 48
4.2.2 Définitions, acronymes et abréviations ............................................. 49
4.3
Spécification du cas d’utilisation (Use-Case Specification) ....................... 50
4.3.1 Cas d’utilisation UC2 Mettre le jeu en place .................................... 50
5
ANALYSE ET CONCEPTION DU SI BSU ............................................................... 61
5.1
Architecture actuelle du système d’informations de la BSU....................... 61
5.1.1 Aperçu général ................................................................................ 61
5.1.2 Composantes actuelles utilisées lors de la configuration du jeu........ 61
5.2
Conception souhaitée de l’application ....................................................... 62
5.2.1 Architecture en couches ................................................................... 62
5.2.2 Model View Controller (MVC) ......................................................... 65
5.3
Avantages et inconvénients d’une architecture trois couches ..................... 66
5.4
Conception de l’application souhaitée en .NET ......................................... 67
III
Table des matières
5.4.1 Architecture en couches en .NET...................................................... 67
5.4.2 Model View Controller en .NET ....................................................... 71
5.4.3 Couche de présentation .................................................................... 72
5.4.4 Couche de logique métier ................................................................. 75
5.4.5 Couche d’accès aux données ............................................................ 75
6
IMPLÉMENTATION ET TESTS ............................................................................. 79
6.1
Implémentation du prototype..................................................................... 79
6.1.1 Le projet « BSUConfiguration » ....................................................... 79
6.1.2 Le projet « BLL » ............................................................................. 87
6.1.3 Le projet « DAL » ............................................................................ 88
6.1.4 Le projet « Entities » ........................................................................ 91
6.1.5 Le projet « CommonObjects » ......................................................... 92
6.2
Tests ......................................................................................................... 93
6.2.1 Introduction ..................................................................................... 93
6.2.2 Cas de test ....................................................................................... 93
6.2.3 Résumé des tests .............................................................................. 94
7
ANALYSE DU SYSTÈME CONÇU ........................................................................... 95
7.1
8
Analyse SWOT ......................................................................................... 95
RÉSUMÉ ET CONCLUSIONS ............................................................................... 100
8.1
Résumé des résultats ............................................................................... 100
8.2
Perspective: d’autres améliorations possibles du site de configuration .... 101
8.3
Conclusions ............................................................................................ 102
BIBLIOGRAPHIE ........................................................................................................ 104
ANNEXE .................................................................................................................... 110
IV
Table des illustrations
V
FIGURE 1: LE SYSTÈME ÉLECTRONIQUE DE LA BOURSE SWX SWISS E XCHANGE [SCHNEIDER 2008]................... 9
FIGURE 2: ORGANISATION DE LA SWISS [SWX 2008B] ................................................................................... 11
FIGURE 3 : L’ORGANISATION DU SIX GROUP [SIXGROUP 2009A] .................................................................. 12
FIGURE 4: E VOLUTION DES VOLUMES PAR SEGMENT DE PRODUITS (CONTRATS EN MILLION) [E UREX 2008] ...... 15
FIGURE 5: E VOLUTION DU COURS DE L’ETF ISHARES DAX ET DE SON INAV [DEUTSCHEBÖRSE 2008] ............ 22
FIGURE 6: PAY-OFF DU DÉTENTEUR D'UN CALL [WIKIPEDIA 2008] .................................................................. 24
FIGURE 7: PAY-OFF DU DÉTENTEUR D'UN PUT [WIKIPEDIA 2008] .................................................................... 24
FIGURE 8: UNE PAGE DE RUP PERSONNALISABLE GRÂCE À RMC [IBM 2008A]............................................... 30
FIGURE 9: VUE D'ENSEMBLE DES CONCEPTS CLÉ DE L' ARCHITECTURE UMA [IBM 2008A] ............................... 33
FIGURE 10: LES ASPECTS DYNAMIQUES ET STATIQUES DU RUP [IBM 2008A] .................................................. 34
FIGURE 11: PATTERN DE CAPACITÉ RECUEIL DES EXIGENCES [IBM 2008A] ..................................................... 36
FIGURE 12: PATTERN DE CAPACITÉ ANALYSE ET CONCEPTION [IBM 2008A] ................................................... 38
FIGURE 13: PATTERN DE CAPACITÉ IMPLÉMENTATION [IBM 2008A] ............................................................... 39
FIGURE 14: PATTERN DE CAPACITÉ TEST [IBM 2008A] .................................................................................. 41
FIGURE 15: EXEMPLE D’UN DIAGRAMME DE CAS D’UTILISATION ..................................................................... 43
FIGURE 16: EXEMPLE D’UN DIAGRAMME DE CLASSES ..................................................................................... 44
FIGURE 17: LE DIAGRAMME « ADMIN » AVEC L’UC « METTRE LE JEU EN PLACE » [SHEHU 2008] .................... 49
FIGURE 18: DIAGRAMME D’ACTIVITÉS DU UC2 « MISE EN PLACE DU JEU » ..................................................... 60
FIGURE 20: UNE ARCHITECTURE DE SÉCURITÉ EN COUCHES [PFLEEGER 1998, P. 201] ...................................... 63
FIGURE 21: TROIS TIERS [OLDBY ET DAN 2006] ............................................................................................. 63
FIGURE 22: LES TROIS COUCHES CLASSIQUES [MITCHELL 2006] ..................................................................... 64
FIGURE 23: LE PATTERN MODEL VIEW CONTROLLER [MORTENSEN, MCGOVERN ET LIPTAAK 2003] ................ 65
FIGURE 24: LA COMPOSITION DU SYSTÈME EN DIFFÉRENTS PAQUETS ............................................................... 71
FIGURE 25: PROTOTYPE PAPIER DE LA MISE EN PAGE GÉNÉRALE DU SITE ......................................................... 73
FIGURE 26 : CONFIGURATION DU MENU « GÉNÉRAL ». ................................................................................... 74
FIGURE 27 : CONFIGURATION DES SOUS-MENUS DE « TITRES » ....................................................................... 74
FIGURE 28: ORM .......................................................................................................................................... 77
FIGURE 29: DIAGRAMME D’ENTITÉS .............................................................................................................. 78
FIGURE 30: LES CINQ PROJETS CRÉÉS DANS VS ............................................................................................... 79
FIGURE 31 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET « BSUCONFIGURATION » ..................................... 80
FIGURE 32 : CAPTURE D’ÉCRAN DU MENU « ACTIONS ».................................................................................. 81
FIGURE 33 : LA COMPOSITION DE LA PAGE « PERIODE » ................................................................................. 83
FIGURE 34 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET « BLL » ............................................................... 87
FIGURE 35 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET « DAL » .............................................................. 88
FIGURE 36 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET « ENTITIES » ........................................................ 92
FIGURE 37 : DOSSIERS ET FICHIERS COMPOSANT LE PROJET « COMMONOBJECTS » .......................................... 92
FIGURE 38 : LA MATRICE SWOT [WIKIPEDIA 2009] ....................................................................................... 96
VI
Table des codes source
CODE SOURCE 1 : PARTIE DU CONTENU DU FICHIER DAL. XML ........................................................................ 75
CODE SOURCE 2 : LES VARIABLES CURRENTSPIELVARIANTE ET SPIELVARIANTE DU BLL ................................. 84
CODE SOURCE 3 : FONCTION UPDATING DÉCLENCHÉE LORS DE L’ÉVÈNEMENT ONUPDATING ............................ 85
CODE SOURCE 4 : FONCTION « SAVE » DU BLL .............................................................................................. 85
CODE SOURCE 5 : L’UTILISATION DE L’ÉVÉNEMENT « ONITEMINSERTING » .................................................... 86
CODE SOURCE 6 : L’IMPLÉMENTATION DE LA FONCTION GETALLDEVISEN() .................................................... 90
CODE SOURCE 7 : L’IMPLÉMENTATION DE LA FONCTION DE MISE À JOUR DES DEVISES ..................................... 91
VII
Table d‘abriéviations
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
VIII
MS
Microsoft
MSTR
Microstrategy
MVC
Model View Controller
OLAP
Online Analytical Processing
OMG
Object Management Group
OO
Object Oriented
ORM
Object Relational Mapping
OTC
Over-the-counter
PEX-MF
Pan-European Exchange Market Feed
PMS
Portfolio Management Simulation
QMF
Quote Market Feed
RAD
Rapid Application Developement
RMC
Rational Method Composer
RUP
Rational Unified Process
SECOM
Settlement Communication System
SI
Système d’informations
SIC
Swiss Interbank Clearing
SICAV
Sociétés d'investissement à capital variable
SIX
Swiss Infrastructure and Exchange
SLI
Swiss Leader Index
SMF
Swiss Market Feed
SMI
Swiss Market Index
SPEM
Software Process Engineering Metamodel
SPI
Swiss Performance Index
SQL
Structured Query Language
SWOT
Strengths Weaknesses Opportunities Threats
SWX
Swiss Exchange
UC
Use Case
UMA
Unified Method Architecture
UML
Unified Modeling Language
URL
Uniform Resource Locator
IX
VB
Visual Basic
VM
Virtual Machine
VS
Visual Studio
XML
eXtensible Markup Language
XP
eXtreme Programming
1. Introduction
1
Introduction
1.1
Problématique
1
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.
1. Introduction
1.2
2
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.
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.
2. La logique métier
2
4
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)
2.1.1
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.
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].
2.1.2
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:
R
Gain ou Perte
fin
Capital
Investi
ou
R
P fin
fin
P début
P début
où Rfin est la rentabilité simple sur la période de jeu; Pfin et Pdé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. 604-612]. A la BSU, c’est sur la base du ratio de
Sharpe que le classement Risk Management est réalisé [BSU 2008].
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
R
PF
PF
R
f
σ PF
Où RPF est la rentabilité mesurée du portefeuille PF, Rf est le taux d’intérêt sans risque, σPF
est la volatilité des rentabilités du portefeuille.
SRPF 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. 604-606].
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. 150-152].
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. 40-41].
2.2
7
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.
2.2.1
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. http://fqs.swx.com/ (dernière consultation: 23.09.08).
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.
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.
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].
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
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].
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.
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 2008. 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.
2.2.2
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.
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
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.
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. 105-106].
Coûts des transactions à la BSU
A la BSU, par simplification, seulement des frais de courtage sont perçus.
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
2.3.1
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].
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].
2.3.2
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. 52-53].
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
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.
2.3.3
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. 13-14].
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. 17-23].
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. 25-26].
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. 25-26].
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.
2.3.4
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. 20-21].
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. 53-76].
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.
2.3.5
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
24
contrepartie du paiement immédiat d’une prime (prime de l’option) au signataire [Brealey et
Myers 2003, pp. 333-334].
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. 59-61].
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. 171-175].
Figure 6: Pay-off du détenteur d'un call [Wikipedia 2008]
Figure 7: Pay-off du détenteur d'un put [Wikipedia 2008]
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. 287-310], des modèles
numériques (modèle binomial, trinomial, simulation de Monte Carlo, etc.) [Hull 2003, pp.
411-453] 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.
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.
2.4.1
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
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.
2.4.2
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].
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.
2.4.3
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.
3. Analyse d’un système d‘information
3
29
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)
3.1.1
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].
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]
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].
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. 23-25].
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. 63-67].
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.
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.
3.1.2
35
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.
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]
3.1.3
37
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].
38
Figure 12: Pattern de capacité Analyse et conception [IBM 2008a]
3.1.4
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].
39
Plusieurs rôles sont ainsi engagés dans cette discipline: l’architecte logiciel, l’intégrateur,
l’implémenteur1 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.
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 3.2.1.
41
Figure 14: Pattern de capacité Test [IBM 2008a]
3.2
Techniques : Unified Modeling Language (UML) et Prototypage
3.2.1
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. 14-17]. 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].
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.
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. 9294].
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
3.2.2
45
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 1990.
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. 115-117], 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].
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. 109-133] é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. 137-170], 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].
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.
4. Recueil des exigences du SI BSU
4
48
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)
4.2.1
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 ».
49
L’UC2 représente notre sujet d’analyse et sera décrit plus en détail au point 4.3.1.
Figure 17: Le diagramme « Admin » avec l’UC « Mettre le jeu en place » [Shehu 2008]
4.2.2
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 ;
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é.
4.3.1
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.
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.
52
13. 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.,
16. 4. 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.
53
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. 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 6.
16.1. 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.
Postcondition :
-
Le menu Général a été configuré.
54
16.2. 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.
Postcondition :
-
le menu « Joueurs » a été configuré.
55
16.3. 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 ».
Postcondition :
-
Les menus de jeux ont été configurés.
16.4. 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.
3. 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.
Postcondition :
-
Les sous-menus « Titres » ont été configurés.
56
*a.
57
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 :
-
*b.
Les champs ont été enregistrés.
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…).
*c.
58
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 email 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 3.
3. 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 4.
4. 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.
*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.
59
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 »
60
5. Analyse et conception du SI BSU
5
61
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
5.1.1
Aperçu général
5.1.2
Composantes actuelles utilisées lors de la configuration du jeu
5.2
Conception souhaitée de l’application
5.2.1
Architecture en couches
62
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é.
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]
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. 19-21].
La figure 22 illustre l’organisation de ces trois couches.
Figure 21: Les trois couches classiques [Mitchell 2006]
5.2.2
65
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. 330-331].
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
1.
request
2.
4.
User
3.
6.
Model
Data
Persistence
action
View
5.
Figure 22: le pattern Model View Controller [Mortensen, McGovern et Liptaak 2003]
66
Avantages et inconvénients d’une architecture trois couches
5.3
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].
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.
5.4.1
Architecture en couches en .NET
Le but de ce chapitre est d’examiner comment implémenter l’architecture décrite au point
5.2.1 avec les technologies .NET. Un point crucial représente, dans ce contexte, l’accès aux
données.
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 EF1 é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.
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. 488-496].
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 !
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.
71
<<use>>
<<use>>
DataContext
Base de
données
DAL.xml
Figure 23: La composition du système en différents paquets
5.4.2
Model View Controller en .NET
ASP.NET n’implémente pas le pattern MVC comme vu au chapitre 5.2.2 : 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. 340-343].
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].
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 5.2.2 ; il est malheureusement
pour l’instant seulement disponible en version beta [MSCorp 2009].
5.4.3
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.
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
Figure 25 : Configuration du menu « Général ».
Figure 26 : Configuration des sous-menus de « Titres »
74
5.4.4
75
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
5.4.5
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).
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
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
Entities
Base de
données
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
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
6. Implémentation et Tests
6
79
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 5.4.1. 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 8.3.
6.1.1
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.
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.
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 5.4.1. 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 ».
GridView
Bulle d’infos
Tri
Pager
Figure 31 : Capture d’écran du menu « Actions »
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.
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
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.
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
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.
6.1.2
87
Le projet « BLL »
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.
Une particularité dans l’implémentation du DAL consiste en l’existence des variables
« currentSpiel » et « currentSpielVariante » discutée au point 6.1.1.
6.1.3
88
Le projet « DAL »
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].
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 5.4.5.
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).
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
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.
91
Code source 7 : L’implémentation de la fonction de mise à jour des devises
6.1.4
Le projet « Entities »
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_20081215.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_20081215.dbml) a été créé depuis la
base de données en utilisant SqlMetal. Il a été, ensuite, modifié dans le designer pour obtenir
92
le diagramme d’entités de la figure 29. Sur la base de ce dernier, SqlMetal a créé la classe
entities_20081215.cs et les fichiers de mappage (cf. chapitre 5.4.5).
Figure 35 : Dossiers et fichiers composant le projet « Entities »
6.1.5
Le projet « CommonObjects »
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 »
6.2
93
Tests
Comme vu au chapitre 3.1, le RUP est basé sur les cas d’utilisation. Les tests du système se
basent donc sur la description de l’UC2 Mettre le jeu en place, faite au chapitre 4.3. Une
grande partie des tests ont été réalisés de façon implicite et manuelle tout au long du projet.
Pour illustrer la façon de procéder, un cas de test pour le scénario principal de l’UC2 a été
décrit ci-après. Les résultats ont été rassemblés dans le résumé de test.
6.2.1
Introduction
Les tests à l’intérieur du tableau sont à exécuter séquentiellement. Les ID des tests
correspondent aux numéros des activités du scénario principal auxquelles ils sont rattachés.
Seul l’onglet correspondant au PMS doit être testé systématiquement. Les tests sont à
réaliser ave les navigateurs Mozilla FireFox version 3.0 et MS Internet Explorer version 6.
6.2.2
Cas de test
Tableau 1 : Cas de test
Test ID
But
Actions
7
Les tables du
jeu vont être
vidées
Dans le menu
« Vidage des tables »,
cliquer sur le bouton
« Vider les tables »
14
Les périodes
sont entrées
dans la base
de données
Dans le menu
« Périodes »,
sélectionner et
désélectionner des
jours, des semaines,
des mois (depuis
différents mois).
Cliquer sur
« sauvegarder les
dates »
Résultat attendu (messages affichés)
Pour les deux jeux contenus dans
la variante de jeu :
Les tables1 sont vidées
les périodes reliées par clé
étrangère d’autres tables2 sont soit
à null, soit à la période avec ID 0
Le message « les tables ont été
vidées avec succès » affiché
Pour les deux jeux contenus dans
la variante de jeu :
Les nouvelles périodes figurent
dans la table des périodes
Elles sont affichées dans le
GridView de la page
Les champs SpielBeginn et
SpielEnde de la table Allgemein
sont mis à jour
Le DetailsView du menu
« Général » affiche les nouveaux
champs début du jeu et fin du jeu
1
Tables vidées : Bank, BedingungManuell, Kurs, Member_Session, Mutation, Portfolio, Rangliste
2
Tables utilisant les périodes : Allgemein, Titel, Bedingung et BedingungManuell
6.2.3
94
Résumé des tests
Les tests avec les ID 7 et 14 ont produit les résultats conformément au cas de test ci-dessus.
Aucune erreur n’a été signalée.
Lors des autres tests faits implicitement, il a été observé que l’affichage des fonctions
JavaScript ne se faisait pas correctement avec Internet Explorer. Avec FireFox, par contre,
aucun problème d’affichage n’a été signalé.
7. Analyse du système conçu
7
95
Analyse du système conçu
La transition de l’ancien vers le nouveau système a déjà commencé avec l’installation du
logiciel sur le serveur de la BSU et la création de tutoriels pour les administrateurs. La
configuration de la prochaine simulation pourra donc se faire avec le nouveau programme.
Mais avant cette étape, il reste, selon la démarche de design science (cf. chapitre 1.3) à
répondre à cette dernière question: est-ce que le nouveau système est bénéfique à une
meilleure configuration du jeu? Ce faisant, l’évaluation ne doit pas se baser uniquement sur
le produit; mais elle doit aussi prendre en compte l’environnement pour lequel il a été créé.
7.1
Analyse SWOT
L’acronyme SWOT fait référence aux mots anglais Strengths (forces), Weaknesses
(faiblesses), Opportunities (opportunités), Threats (menaces). Sa traduction française MOFF
Menaces, Opportunités, Forces, Faiblesses est moins couramment utilisée. L’analyse SWOT
est le résultat d’une étude menée par Albert S.Humphrey en 1960. L’objectif de cette
dernière était de comprendre pourquoi les planifications d’entreprise échouent [Chapman
2008].
Cette méthode d’analyse est devenue aujourd’hui, un outil universel d’aide à la décision.
Bien qu’elle soit utilisée abondamment comme instrument de stratégie et de marketing dans
les entreprises, cette technique peut être utilisée dans une variété d’autres situations où il est
nécessaire d’analyser une situation présente d’une manière structurée [Atkinson 1998].
L’analyse SWOT distingue deux aspects :
L’aspect interne, qui comprend les forces et les faiblesses du domaine d'activité
L’aspect externe, qui comprend les opportunités et les menaces présentes dans
l'environnement.
Une matrice, dite « matrice SWOT » peut ainsi être créée résumant les forces, faiblesses,
opportunités et menaces. La figure 38 illustre une telle matrice.
Pour cette partie d’évaluation du prototype, le produit créé sera donc analysé par rapport aux
quatre points suivants :
Forces : quelles sont les caractéristiques intrinsèques au produit qui plaident en
faveur de son utilisation dans le cadre de la configuration du jeu BSU par rapport à
l’ancienne solution?
96
Faiblesses : quelles sont les caractéristiques intrinsèques au produit qui plaident en
défaveur de son utilisation dans le cadre de la configuration du jeu BSU par rapport à
l’ancienne solution?
Opportunités : Comment l’environnement du prototype peut se développer ou réagir
à son utilisation et qui pourrait plaider en faveur de son utilisation par rapport à
l’ancienne solution dans le cadre de la configuration du jeu BSU ?
Menaces : Comment l’environnement du prototype peut se développer ou réagir à
son utilisation et qui pourrait plaider en défaveur de son utilisation par rapport à
Origine externe
Origine interne
l’ancienne solution dans le cadre de la configuration du jeu BSU ?
Utile
Néfaste
pour atteindre l‘objectif
pour atteindre l‘objectif
S W
O T
Forces
Faiblesses
Opportunités
Menaces
Figure 37 : la matrice SWOT [Wikipedia 2009]
Forces
Grâce au nouveau système, la procédure de configuration peut être exécutée
beaucoup plus rapidement et simplement : Des procédures qui devaient être faites
manuellement sont maintenant exécutées automatiquement. Les données qui
devaient être entrées à plusieurs endroits possèdent désormais un masque commun
d’entrée. La configuration se fait à l’aide d’un seul programme.
La procédure peut être exécutée par une seule personne sans connaissances
informatique : l’interface web est facile d’utilisation et possède des explications
concernant chaque champ à rentrer et étape à exécuter.
97
L’interface permet une vue unifiée et claire de toutes les données concernant la
simulation : Il n’est plus nécessaire de rechercher les informations dans les
différentes tables de la base de données à l’aide de recherche SQL. Toutes les
données sont disponibles par l’interface web.
Le programme est flexible : le site permet de configurer non seulement la variante de
jeu « PMS », mais aussi toutes les autres simulations que la BSU organisera et ceci
sans même recompiler le code.
L’application possède une architecture claire et bien documentée pour faciliter les
développements ultérieurs: le programme utilise une architecture trois couches
stricte, documentée en détails dans ce rapport.
Le programme utilise les dernières technologies : ce prototype se base sur le
Framework .NET 3.5 et jouie ainsi des derniers avancements technologiques.
Le programme peut être accédé à distance : La couche de présentation étant
implémentée comme page web, il est possible pour l’administrateur d’effectuer la
configuration depuis chez lui, à travers le réseau.
Faiblesses
La procédure de configuration est moins transparente qu’avec l’ancien système :
comme l’administrateur interagissait directement avec la base de données, l’ancien
système possédait l’avantage que l’administrateur savait exactement quelle donnée
avait été rentrée où dans le système. Avec le nouveau système, il doit faire confiance
au programme.
L’architecture de la BSU est plus complexe : l’architecture du nouveau programme
est plus complexe que l’ancien (cf. chapitre 5.3). Les administrateurs de la BSU
devront s’occuper d’un programme en plus.
Choix technologique : Le choix de LINQ to SQL n’est pas adapté à une architecture
trois couches. De plus, de par sa nouveauté, peu de gens connaissent LINQ. Comme
elles ne sont pas enseignées à l’Université de Fribourg, les technologies .NET sont
moins connues des étudiants que par exemple celles du monde Java.
98
Opportunités
L’utilisation du nouveau système peut inciter les administrateurs à moderniser
d’autres parties de la BSU : le gain d’efficacité obtenu et la modernité du logiciel
peuvent servir de motivation pour d’autres améliorations des processus de la BSU.
La compréhension et la motivation des administrateurs peuvent être accrues par
l’utilisation du nouveau système : la nouvelle interface facilite la compréhension
qu’ont les gestionnaires du système. La procédure de configuration dure moins
longtemps et leur permet ainsi de se concentrer sur d’autres activités.
Menaces
Sécurité : comme la nouvelle interface facilite beaucoup l’accès aux données, les
données des utilisateurs (surtout les mots de passe en clair). sont plus vulnérables
aux abus. Les mauvaises manipulations du site sont aussi plus probables, comme les
commandes sont plus faciles à exécuter (il existe certes des messages
d’avertissement, mais il est toujours possible de les ignorer). Si la page web n’est pas
suffisamment sécurisée, elle pourrait aussi être victime d’une attaque.
Choix technologiques : il est possible que Microsoft se concentre sur son nouveau
Framework ORM (ADO.NET EF) et que LINQ to SQL ne soit plus supporté.
Des changements dans la base de données signifieraient une grande adaptation du
code : contrairement à l’Entity Framework, LINQ to SQL ne permet pas d’isoler le
programme des changements faits dans la base de données. Chaque changement fait
dans la base de données nécessite une nouvelle génération des classes à l’aide de
SqlMetal [Hoffman 2006].
Les administrateurs de l’informatique connaissent moins bien le fonctionnement du
jeu : comme les administrateurs ne doivent plus directement rentrer les valeurs dans
la base de données, il est possible qu’à long terme, ils connaissent moins bien le
fonctionnement interne du jeu.
Le programme ne soit pas utilisé par les administrateurs : il est possible que certains
administrateurs préfèrent continuer à utiliser l’ancienne méthode qui leur procure
une vue plus transparente sur la procédure de mise en place du jeu.
99
Cette analyse SWOT a permis de prendre en compte, non seulement le programme créé,
mais aussi de l’analyser dans le contexte de son utilisation. Comme [March et Smith 1995]
l’a défini, en science de la conception, le progrès est atteint lorsque des technologies
existantes sont remplacées par d’autres plus efficaces. La nouvelle interface de configuration
constitue indéniablement un progrès. Il faudra, tout de fois, faire attention aux menaces et
essayer d’exploiter au mieux possible les opportunités reportées ci-dessus.
8. Résumé et conclusions
8
Résumé et conclusions
8.1
Résumé des résultats
100
Quels sont les différents outils financiers et caractéristiques financières à prendre en
compte pour la configuration d'un jeu boursier?
Ce travail a d’abord décrit la logique métier. Le monde financier de la BSU a été
systématiquement comparé avec la réalité boursière. Il en est ressorti que les simplifications
apportées à la simulation PMS résident surtout dans les sortes d’instruments financiers
négociables, les types d’ordre possibles, les types de frais, la gestion des options et les cours
de négociation (à la BSU, les ordres sont toujours passés au cours de clôture).
Comment procéder pour entreprendre un changement dans le système d'information d'une
entreprise?
La méthodologie RUP a ensuite été étudiée. Il en est ressorti que, pour le présent projet, une
version allégée du « processus de livraison pour petit projets » serait le mieux adapté. Les
diagrammes de classes, de cas d’utilisation, ainsi qu’un prototype expérimental sur papier et
un prototype évolutif codé ont été jugé nécessaires pour soutenir le développement.
Quelles fonctionnalités sont attendues par les parties prenantes pour configurer le jeu?
Le recueil des exigences a été appliqué conformément au RUP. Les résultats ont été décrits
sous forme de cas d’utilisation, de diagramme d’activité et de description textuelle. Il en est
ressorti, entre autres, qu’il était important que l’interface incluse les instructions de
configuration, qu’elle offre des fonctionnalités de recherche et qu’elle automatise les
procédures.
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?
Les principes d’architecture et les patrons de conception utilisés dans le développement du
système ont été étudiés. Il en est ressorti qu’une architecture trois couches stricte rend le
système plus facile à comprendre, à réutiliser et à maintenir. Les technologies .ASP.NET et
LINQ to SQL ont été choisies pour le développement. Cette dernière technologie s’est
avérée, toutefois, être peu propice à un développement trois tiers.
Est-ce que la nouvelle interface est bénéfique à une meilleure configuration du jeu?
Une analyse SWOT est venue aider à évaluer le prototype d’amélioration. Il en est ressorti,
notamment, que grâce au nouveau système, la procédure de configuration peut être exécutée
101
beaucoup plus rapidement et simplement qu’auparavant. Une seule personne sans
connaissances informatique peut se charger de toute la procédure. L’interface offre une vue
unifiée et claire de toutes les données concernant la simulation. La nouvelle interface est
donc très clairement propice à une meilleure configuration du jeu.
8.2
Perspective: d’autres améliorations possibles du site de
configuration
Le site de configuration répond aux exigences listées au chapitre 4 et a été testé avec succès.
Cependant, des améliorations supplémentaires pourraient être apportées au système. Elles
n’ont pas encore été implémentées pour ne pas dépasser le cadre de ce travail. Elles
comportent les points suivants :
La gestion des erreurs et la validation des champs sont très minimales. Pour avoir un
système robuste, il serait nécessaire de les améliorer.
Le système a été conçu pour configurer le PMS et toutes les autres simulations
fonctionnant d’après le même principe. La BSU organise un autre type de
simulations comportant des conditions pour l’achat et la vente de titres. Ces dernières
ne sont, pour l’instant, pas configurables par le système; mais elles pourraient très
facilement y être intégrées.
Le système pourrait être complété par une fonction permettant d’importer les options
déjà rentrées du jeu Classic vers la version Derivative. Cela rendrait la configuration
de la simulation encore plus rapide.
Le site pourrait être rendu compatible à MS Internet Explorer.
Les instructions de configuration affichées par le site pourraient être contenues dans
un ficher XML. Ainsi, il ne serait plus nécessaire de recompiler après chaque
changement de code.
S’il devenait nécessaire que plusieurs personnes utilisent le site en même temps, il
faudrait gérer l’écriture simultanée des utilisateurs dans la base de données
(concurrency).
Il serait judicieux de reconsidérer le choix de la technologie d’ORM. En effet, la
modélisation permise par LINQ to SQL n’est pas optimale (cf. chapitre 5.4.5) et avec
LINQ to SQL l’implémentation n’est pas à l’abri des changements faits dans la base
de données (cf. chapitre 7.1).
Le logiciel pourrait être internationalisé, c.à.d. adapté à des langues et des cultures
différentes, et traduit.
8.3
102
Conclusions
Ce travail s’est construit autour de la méthodologie de gestion de projet RUP. L’application
de cette dernière a fourni une approche très structurée et a permis de construire un logiciel
respectant les exigences des utilisateurs. Cependant, même en ayant utilisé une version
extrêmement allégée du RUP pour petit projet, la compréhension de la structure du RUP, de
son métamodèle et de ses différents rôles a représenté un grand investissement en temps.
Etant donné que ce projet a été réalisé par une seule personne, une approche moins lourde,
comme par exemple : Extreme Programming (XP), aurait été plus appropriée.
Comme [Larry et Lucy 2001] le décrit, les modèles qui sont développés originairement pour
soutenir la conception de composants logiciels et leurs interactions ne sont pas
nécessairement adaptés pour organiser l’interface graphique et l’interaction de ce dernier
avec les utilisateurs. Ceci s’est avéré totalement vrai lors de la spécification du cas
d’utilisation du présent travail. Les différentes options présentes à l’intérieur de l’interface
ne peuvent pas toutes être modélisées par un scénario de cas d’utilisation. Une technique
plus visuelle et moins narrative, par exemple un storyboard, est plus adéquate.
Le but du système initial était de prendre en charge uniquement la configuration de la
simulation PMS. Cependant, la possibilité qu’offre LINQ to SQL de prendre différents
fichiers de mappage en paramètre a incité l’auteur à créer un site qui puisse prendre en
charge toutes les simulations de la BSU. Ceci a certes suscité un plus grand effort de
programmation, mais ce dernier a été largement récompensé.
Il n’en va malheureusement pas de même pour la programmation d’une architecture trois
couches en ASP.NET et LINQ to SQL. Bien que les contrôles ASP.NET et la formulation
des requêtes LINQ soient intuitifs et permettent d’accélérer le développement, leur
utilisation pour créer une architecture trois couches s’apparente beaucoup au parcours du
combattant. En utilisant ces techniques, le temps nécessaire au développement du site de
configuration aurait été nettement inférieur, si les couches du système avaient été mélangées
(cf. chapitre 6.1). Le ADO.NET EF (cf. chapitre 5.4), s’il n’avait pas encore été en version
béta au début du projet, aurait constitué une solution, certes plus complexe, mais aussi plus
adaptée au présent projet.
L’analyse de la logique financière s’est montrée très utile lors de la conception du
programme. En effet, comme il existe très peu de documentation des programmes et de la
base de données, l’analyse préliminaire a permis de mieux comprendre et modéliser la
103
simulation. L’auteur est toutefois d’accord avec [Teuffer 2002, p. 46] que certaines relations
entre les champs de la base de données de la BSU sont « déconcertantes ».
Ce travail a permis à l'auteur de se familiariser avec les technologies ASP.NET et LINQ to
SQL qu'il ne connaissait pas. Cette démarche a exigé de lui qu'il approfondisse ses
connaissances dans les trois domaines très distincts de la finance, de la gestion de projets et
de la programmation. Etant donné que ses intérêts personnels et ses études l'ont porté à
l'intersection de ces différents domaines, le thème de ce travail de Master l'a d'emblée
passionné. De plus, l'intérêt et l'attachement de l'auteur pour la BSU l'ont motivé et ont
allégé les heures de « tribulations ».
Bibliographie
104
Bibliographie
Admiraal, H. (2007a) Differences between RUP versions 6 and 7.
http://home.versatel.nl/hadmiraal/rup/doc/DifferencesRUP6-7.pdf (dernière
consultation: 12.12.2008).
Admiraal, H. (2007b) Pitfalls using UML in RUP.
http://members.tele2.nl/hadmiraal/rup/doc/PitfallsUMLinRUP.pdf (dernière
Aftalion, F. (2003) La nouvelle finance et la gestion des portefeuilles. Economica, Paris.
Arefin, M. (2008) Difference between LINQ to SQL and the Entity Framework.
http://dotnethitman.spaces.live.com/blog/cns!E149A8B1E1C25B14!195.entry
(dernière consultation: 28.01.2009).
Arnowitz, J., Arent, M. et Berger, N. (2007) Effective prototyping for software makers (The
Morgan Kaufmann series in interactive technologies). Elsevier, Amsterdam.
Atkinson, K. (1998) SWOT analysis: a tool for continuing professional development. In
International Journal of Therapy and Rehabilitation,, Vol. 5 (8), 08.1998, pp. 433 435.
BankingToday (2009) Trafic des paiements - SIX Group.
http://www.bankingtoday.ch/fr/lehrmittel/lektionen/16zvk/index.html (dernière
Bass, L., Clements, P. et Kazman, R. (2003) Software architecture in practice (SEI series in
software engineering). Addison-Wesley, 2nd, Boston etc.
Booch, G., Rumbaugh, J. et Jacobson, I. (2000) Le guide de l'utilisateur : UML. Eyrolles,
Paris.
Brandon, D. M. (2006) Project management for modern information systems. IRM Press,
Hershey.
Brealey, R. A. et Myers, S. C. (2003) Principes de gestion financière. Pearson Education, 7e
éd., Paris.
BSU (2008) Börsenspiel der Schweizer Universitäten. http://www.unifr.ch/bsu (dernière
Budde, R. et Züllighoven, H. (1990) Prototyping revisited. In The 1990 IEEE International
Conference on Computer Systems and Software Engineering, Tel - Aviv, Israel, pp.
418 - 427.
Chaos (2001) Extreme Chaos. Standish Group International.
Chapman, A. (2008) Swot Analysis.
http://www.businessballs.com/swotanalysisfreetemplate.htm (dernière consultation:
08.01.2009).
Bibliographie
105
DeutscheBörse (2008) iShares DAX (DE). http://www.boerse-frankfurt.de/DE/
index.aspx?pageID=105&ISIN=DE0005933931 (dernière consultation: 02.10.08).
Eck, C., Langer, M. et Riechert, M. (2006) Eurex Futures und Optionen. Finanzbuch
Verlag, München.
Eibl, H. (2008) ETFs Exchange Traded Funds. FinanzBuch Verlag, München.
Esposito, D. (2007) LinqDataSource vs ObjectDataSource vs SqlDataSource.
http://weblogs.asp.net/despos/archive/2007/09/24/
linqdatasource-vs-objectdatasource-vs-sqldatasource.aspx (dernière consultation:
20.09.2008).
Essigkrug, A. (2007) Rational Unified Process kompakt. Elsevier Spektrum Akad. Verl., 2.
Aufl., Heidelberg München.
Eurex (2008) Eurex. http://www.eurexchange.com/index.html (dernière consultation:
25.09.08).
Exfeed (2008) SIX Exfeed. http://www.exfeed.com/index.html (dernière consultation:
23.09.08).
Flasko, E. (2008) Introducing LINQ to Relational Data. http://msdn.microsoft.com/en-us/
library/cc161164.aspx (dernière consultation: 11.12.2008), Microsoft Corporation.
Fowler, M. (2003) Patterns of enterprise application architecture (The Addison Wesley
signature series). Addison-Wesley, Boston etc.
Hamon, J. (2004) Bourse et gestion de portefeuille. Economica, Paris.
Hesse, W. (2003) Dinosaur Meets Archaeopteryx? or: Is there an Alternative for Rational's
Unified Process? In Software and Systems Modeling (SoSyM), Vol. 2 (4), pp. 240247.
Hickman, K. A., Hunter, H. O. et Byrd, J. W. (2002) Foundations of corporate finance.
South-Western, 2nd, Cincinnati Ohio etc.
Hoffman, K. (2006) LINQ to Entities vs. LINQ to SQL - What should I use and when?
http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm (dernière
Hull, J. (2003) Options, futures, & other derivatives (Prentice Hall finance series.
Options/futures/derivatives). Prentice-Hall : Pearson Education International, 5th,
Upper Saddle River NJ.
Hüsemann, S. (2007) Roadmap BSU. Document interne de la BSU, BSU, Fribourg.
IBM (2008a) Rational Method Composer. 7.2, Software, [fichiers obtenus de
file:///C:/Program%20Files/IBM/RMC72/rmc/RUP.fr/LargeProjects/index.htm#].
IBM (2008b) Rational Method Composer. http://www-01.ibm.com/software/awdtools/rmc/
features/index.html?S_CMP=wspace (dernière consultation: 16.10.2008).
Bibliographie
106
IBM (2008c) Rational Unified Process. http://www-01.ibm.com/software/awdtools/rup/
(dernière consultation: 16.10.2008).
Isakov, D. (2006) Gestion de Portefeuille: Les mesures d'évalutation de la performance.
Support de cours, Département de gestion d'entreprise, Université de Fribourg,
Fribourg.
Klopper, R., Gruner, S. et G. Kourie, D. (2007) Assessment of a framework to compare
software development methodologies. In Proceedings of the 2007 annual research
conference of the South African institute of computer scientists and information
technologists on IT research in developing countries, ACM, Port Elizabeth, South
Africa, pp. 56 - 65.
Kruchten, P. (2001) The rational unified process : an introduction (The Addison-Wesley
object technology series). Addison-Wesley, 2nd , 5th print., Boston.
Larman, C. (2006) Applying UML and patterns : an introduction to object-oriented analysis
and design and iterative development. Prentice Hall PTR, 3rd , 7th printing, Upper
Saddle River, N.J.
Larry, L. C. et Lucy, A. D. L. (2001) Structure and style in use cases for user interface
design. In Object modeling and user interface design: designing interactive systems,
Addison-Wesley Longman Publishing Co., Inc., pp. 245-279.
Luqi, L. et Steigerwald, R. (1992) Rapid software prototyping. In the Twenty- Fifth Hawaii
International Conference on System Sciences, Vol. 2, pp. 470-479
March, S. T. et Smith, G. (1995) Design and natural science research on information
technology. Elsevier Science Publishers B. V., pp. 251-266.
Marguerie, F., Eichert, S. et Wooley, J. (2008) LINQ in Action. Manning, Greenwich.
Metz, D. (2007) Devisenhandel. FinanzBuch Verlag, München.
Mitchell, S. (2006) Tutorial 2: Creating a Business Logic Layer.
http://msdn.microsoft.com/en-us/library/aa581779.aspx (dernière consultation:
11.12.08), Microsoft Corporation.
Morley, C., Hugues, J. et Leblanc, B. (2006) UML 2 pour l'analyse d'un système
d'information : le cahier des charges du maître d'ouvrage. Dunod, 3e éd., Paris.
Mortensen, M. K., McGovern, R. et Liptaak, C. (2003) ASP.NET and Struts: Web
Application Architectures. http://msdn.microsoft.com/en-us/library/
aa478961.aspx#aspnet-aspnet-j2ee-struts_topic4 (dernière consultation: 11.12.08),
Microsoft Corporation.
MSCorp (2008) LinqDataSource Web Server Control Overview.
http://msdn.microsoft.com/en-us/library/bb547113.aspx (dernière consultation:
MSCorp (2009) ASP.NET MVC. http://www.asp.net/mvc/ (dernière consultation:
Muller, P.-A. (2000) Modélisation objet avec UML. Eyrolles, 7e tirage 2000, Paris.
Bibliographie
107
Novello, P. (2007) Bourse : guide de l'investisseur. P. Novello, 3e éd., actualisée et augm.,
Genève.
Oldby, N. K. E. et Dan, M. B. (2006) Application design of a layered architecture in
ASP.NET 2.0 - and a comparison between J2EE and .NET Rapport technique, ITUniversity of Copenhagen (ITU) Copenhagen [obtenu le 02.01.2009 de
http://decorus.dk/blog/wp-content/uploads/writings/4week_application_design.pdf].
OMG (2008) Catalog Of OMG Modeling And Metadata Specifications.
http://www.omg.org/technology/documents/modeling_spec_catalog.htm (dernière
Perpetua (2008) Rational Unified Process (RUP).
http://perpetuastudents.wordpress.com/2008/01/21/rational-unified-process-rup/
(dernière consultation: 16.10.2008), Perpetua Knowledge Services-Students Centre.
Pfleeger, S. L. (1998) Software engineering : theory and practice. Prentice Hall, Upper
Saddle River, N.J.
Phillips, C. et Kemp, E. (2002) In support of user interface design in the rational unified
process. IEEE Computer Society Press, pp. 21-27.
Pomberger, G. et Weinreich, R. (1994) The Role of Prototyping in Software Development. In
Conference on the Technology of Object-Oriented Languages and Systems (TOOLS
Europe '94), Prentice Hall, Versailles, France.
Ranaldo, A. (2007) Introduction to market microstructure Support de cours, Département de
gestion, University of Zurich, Zurich [obtenu le 02.01.2009 de
http://www.ranaldo.net/pdf/Unizh/2007-8/Slides/Intro.pdf].
RSCorp (1998) Rational Unified Process - Best Practices for Software Development Teams.
Rational Software White Paper TP-026A Rev 11/98 [obtenu le 12.12.2008 de
http://www.cvc.uab.es/shared/teach/a20363/rup_bestpractices.pdf].
Schneider, F. (2008) BankingToday.ch Verlag SKV, Classeur 2: Opérations financières et
négoce, Zürich.
Shehu, E. (2008) Analyse d'un système d'information et extension de celui-ci par de
nouvelles fonctionnalités. Travail de séminaire, Département d'informatique (DIUF),
Université de Fribourg, Fribourg [obtenu le 02.01.2009 de
http://diuf.unifr.ch/is/seminar_thesis].
Shuja, A. K. et Krebs, J. (2008) IBM rational unified process reference and certification
guide : solution designer. IBM Press, Upper Saddle River,, N.J.
SIXGroup (2008a) Communiqué de presse - Les sociétés SIS rebabtisées.
www.sag.ch/sag/fr/pressrelease-081003-sis-companies.pdf (dernière consultation:
01.01.09).
SIXGroup (2008b) Communiqué de presse - Pour l’infrastructure de la place financière
suisse, de bons chiffres semestriels et une nouvelle marque, SIX Group
http://www.six-group.com/media_releases/online/
media_release_200808210657_fr.pdf (dernière consultation: 02.01.2009).
Bibliographie
108
SIXGroup (2009a) Domaines d'activité. http://www.six-swiss-exchange.com/about_us/
company/business_fields_fr.html (dernière consultation: 02.01.2009).
SIXGroup (2009b) Types d'ordres. http://www.six-swiss-exchange.com/marketpulse/
knowhow/exchange/trading/other_fr.html (dernière consultation: 02.01.2009).
SIXSIS (2008) SIX SIS AG. https://www.sec.sisclear.com/sec/cm/index.htm (dernière
SIXTelekurs (2009) SIX Telekurs. http://www.telekurs-financial.com/
fr/tkfich_index/tkfich_company.htm (dernière consultation: 01.01.09).
Steiner, M. et Bruns, C. (2002) Wertpapiermanagement : professionelle Wertpapieranalyse
und Portfoliostrukturierung. Schäffer-Poeschel, 8., überarb. und erw. Aufl.,
Stuttgart.
Strahl, R. (2007) LINQ to SQL and attaching Entities. http://www.west-wind.com/
WebLog/posts/134095.aspx (dernière consultation: 02.01.2009).
SWX (2008a) Financial Quote Service. http://fqs.swx.com/ (dernière consultation:
23.09.08).
SWX (2008b) SWX. http://www.swx.com/index.html (dernière consultation: 23.09.08).
SWXEurope (2009) About SWX Europe. http://www.swxeurope.com/about.html (dernière
Telekurs (2008a) SIX Telekurs - L'Histoire. http://www.telekurs-financial.com/fr/
tkfich_index/tkfich_company/tkfich_company_history.htm (dernière consultation:
02.01.09).
Telekurs (2008b) Telekurs. http://www.telekurs.com/fr/tkhoch_home.htm (dernière
Teuffer, T. (2002) Data Warehouse zur Online-Analyse von Börsendaten - Modellierung,
Implementation und Aufsetzung. Travail de Master, Département d'Informatique
(DIUF), Université de Fribourg, Fribourg [obtenu le 02.01.2009 de
http://diuf.unifr.ch/is/master_thesis].
UBS (2008) Glossar. http://www.ubs.com/1/g/about/bterms.html (dernière consultation:
24.09.08).
Walther, S. (2007) ASP.NET 3.5 Unleashed. Sams, Chicago.
Weston, J. F., Mitchell, M. L. et Muhlerin, J. H. (2004) Takeovers, restructuring, and
corporate governance. Pearson Prentice Hall, 4th ed, Upper Saddle River N.J.
Wikipedia (2008) Options. http://fr.wikipedia.org/wiki/Option (dernière consultation:
01.10.08).
Wikipedia (2009) SWOT. http://fr.wikipedia.org/wiki/SWOT (dernière consultation:
01.01.2009).
Bibliographie
109
Wood, D. P. et Kang, K. C. (1992) A Classification and Bibliography of Software
Prototyping. Technical Report CMU/SEI-92-TR-13, Software Engineering Institute,
Carnegie Mellon University, Pittsburgh (Pennsylvanie) [obtenu le 12.12.2008 de
http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr13.92.pdf].
Zant, R. F. (2005) Hands-on prototyping in system analysis and design. In Issues in
Information Systems, Vol. VI (No.1), pp. 10-14.
Zindel, S. (2008) Les frais de négoce peuvent varier du simple au centuple. In Bilan
(No.250), 21.05.2008 [obtenu le 02.12.2008 de http://www.bilan.ch/
les-frais-de-negoce-peuvent-varier-du-simple-au-centuple].
Annexe
Annexe
110

Analyse des Processus de configuration d`un jeu boursier en

Transcription

Documents pareils

Télécharger - Alliance Police Nationale

FluidControl Unit FCU 8000 Série Accessoires

Périnée - Formation d`échographie 3d

Press Book - Connecting

pour l`heure une piste est en cours de reflexion concernant la

Présentation de la technologie

Commentaires du texte

read more

et membres du Bureau Composition du Conseil d`Administration