Vous êtes sur la page 1sur 69

Universit de Fribourg, Suisse Dpartement d'informatique Bachelor en informatique

MISE EN PLACE DUNE ARCHITECTURE DE TYPE SOA POUR UN


PROJET INFORMATIQUE

Travail de bachelor

Bschi Mathias Chemin des coliers 8 1163 Etoy mathias.bueschi@unifr.ch

Dr. Stefan Hsemann

Janvier 2011

ABSTRACT
La recherche de solutions visant faciliter lintgration entre de nombreuses applications htrognes est de nos jours ncessaires dans un monde o la complexit des systmes dinformations ne cesse de crotre. Larchitecture oriente services (SOA) est lun des modles intressants permettant de faire face cette problmatique. Ce travail vise dans une premire partie mettre en exergue les concepts qui entourent la SOA en y apportant une description suffisante afin daborder par la suite les aspects architecturaux de la SOA. Le mapping relationnel-objet, permettant de relier le modle relationnel dune base de donnes un modle objet, sera abord sous un angle thorique et pratique en vue de son intgration dans la SOA. s Enfin les connaissances assimiles dans la premire partie seront utilises pour laborer une architecture SOA dans le cadre de lassociation Brsenspiel der Schweizer Universitten (BSU). Limplmentation dune partie de larchitecture sera effectue. Il sagira de la partie de calcul des portefeuilles des joueurs pour le jeu Portfolio Management Simulation (PMS). Une des volonts de ce travail sera damener au systme dinformations (SI) de la BSU une capacit saligner plus facilement avec les processus de lassociation.

MOTS-CLS
BSU, PMS, association, bourse, architecture, SOA, systme, information, portefeuille, UML, .NET, persistance, mapping, relationnel-objet

Table des matires

Table des matires


1 INTRODUCTION ....................................................................................................... 6 1.1.1 Problmatique ...................................................................................... 6 1.1.2 Objectifs ................................................................................................ 6 1.1.3 Dmarche utilise ................................................................................. 8 2 ARCHITECTURE DE SI ............................................................................................. 9 2.1 2.2 2.3 Dfinition et analyse dune architecture du systme dinformation (SI) ....... 9 Aperu de larchitecture de type SOA ......................................................... 10 Dfinition dun modle de rfrence SOA et conception dune architecture de rfrence SOA ..................................................................... 13 2.4 3 Utilit dune architecture structure et planifie .......................................... 14

PRSENTATION DU MAPPING RELATIONNEL-OBJET ............................................ 15 3.1 3.2 3.3 Dfinition ..................................................................................................... 15 Rle dans larchitecture de type SOA .......................................................... 15 Outils de mapping relationnel-objet existants.............................................. 16

STRUCTURE GNRALE DE LARCHITECTURE DE RFRENCE DE LA BSU......... 18 4.1 4.2 4.3 Aspects prendre en compte ....................................................................... 18 Vue des diffrentes couches......................................................................... 18 Roadmap vers larchitecture de rfrence SOA........................................... 19

PARTIE PRATIQUE ................................................................................................. 24 5.1 5.2 5.3 Prsentation du jeu PMS et de son environnement ...................................... 24 Analyse actuelle de la structure ................................................................... 26 Modifications de la structure envisages ..................................................... 26 5.3.1 Architecture cible ............................................................................... 26

Table des matires 5.3.2 Consquences et avantages de la nouvelle architecture .................... 27 5.3.3 Services mtiers .................................................................................. 29 5.4 Dfinitions de cas dutilisations et rgles mtiers pour le module PMS Core .............................................................................................................. 30 5.4.1 Cas dutilisations ................................................................................ 30 5.4.2 Rgles mtiers ..................................................................................... 33 5.5 Choix des composants tiers pour un dveloppement du projet sous .NET ............................................................................................................. 37 5.5.1 LINQ to SQL ....................................................................................... 38 5.5.2 Windows Communication Framework ............................................... 40 5.5.3 Logging ............................................................................................... 41 5.5.4 ASP .NET et Web Forms .................................................................... 42 5.5.5 jQuery ................................................................................................. 43 5.6 Implmentation ............................................................................................ 45 5.6.1 PMS Core ........................................................................................... 45 5.6.2 PMS Administration ........................................................................... 52 5.6.3 Dploiement ........................................................................................ 54 5.7 6 Tests ............................................................................................................. 55

RSULTATS PRATIQUES OBTENUS ET VALUATION ............................................. 56 6.1.1 Prsentation de linterface PMS Administration ............................... 56 6.1.2 Prsentation de PMS Core ................................................................. 58 6.1.3 Avantages et dsavantages de la nouvelle architecture ..................... 58 6.2 Diffrences avec les attentes thoriques ...................................................... 58

CONCLUSION ......................................................................................................... 60 7.1 7.2 Conclusion finale ......................................................................................... 60 Conclusions personnelles ............................................................................. 61

Table des matires 8 RESSOURCES ......................................................................................................... 62

ANNEXE A ....................................................................................................................... 64 ANNEXE B ....................................................................................................................... 67

Table des illustrations

Table des illustrations


FIGURE 1 : BNFICES DUNE SOA [MARKS/BELL 2006, P.134] ................................................................ 11 FIGURE 2: ARCHITECTURE DE RFRENCE SOA [OASIS 2006] ................................................................. 13 FIGURE 3 : APPLICATION N-TIER COUCHE DACCS AUX DONNES [ROS 2003] ....................................... 16 FIGURE 4 : ARCHITECTURE DE RFRENCE DE LENTREPRISE IPT [IPT 2010] ............................................. 18 FIGURE 5 : LES 6 DOMAINES DFINIS PAR BEA [BEA 2005]....................................................................... 20 FIGURE 6 : ARCHITECTURE DE RFRENCE TABLIE POUR PMS TOP .......................................................... 25 FIGURE 7 : NOUVELLE ARCHITECTURE POUR LE JEU PMS .......................................................................... 27 FIGURE 8 : TYPES DE SERVICES DANS LA NOUVELLE ARCHITECTURE.......................................................... 29 FIGURE 9 : CAS DUTILISATION POUR LE MODULE PMS CORE .................................................................... 30 FIGURE 10: INTGRATION DES TECHNOLOGIES DANS LARCHITECTURE ..................................................... 37 FIGURE 11 : LES DIFFRENTES IMPLMENTATIONS DE LINQ ...................................................................... 38 FIGURE 12: RLE DE LINQ TO SQL DANS LA NOUVELLE ARCHITECTURE .................................................. 39 FIGURE 13 : EXEMPLE DE LAPPEL DE LOPRATION NEXTPERIOD SUR LE SERVICE PMS CORE ................. 40 FIGURE 14 : STRUCTURE ET FONCTIONNEMENT DUNE WEB FORM ............................................................ 43 FIGURE 15 : MCHANISME DE PULL ............................................................................................................ 44 FIGURE 16 : STRUCTURE DU PROJET PMS CORE ......................................................................................... 45 FIGURE 17: COMPOSANTS DU ENDPOINT .................................................................................................... 47 FIGURE 18 : INTERFACE UTILISATEUR PMS ADMINISTRATION ................................................................... 52 FIGURE 19: ENVIRONNEMENT BSU ACTUEL ............................................................................................... 54 FIGURE 20 : LA VUE PRIODES ................................................................................................................... 56 FIGURE 21 : LA VUE RPARATION DE COURS .............................................................................................. 57 FIGURE 22 : LA VUE LOGS .......................................................................................................................... 57

Abrviations

Abrviations

BSU PMS SOA MVC SOAP XML HTTP WSDL DAO POO CRUD AJAX TCP JVM BLL DAL IT UML DOM URL BR SQL WCF LINQ

Brsenspiel der Schweizer Universitten Portfolio Management Simulation Service Oriented Architecture Model- View - Controller Simple Object Access Protocol Extensible Markup Language Hypertext Transfer Protocol Web Services Description Language Data Access Object Programmation orient objets Create-read-update-delete Asynchronous JavaScript and XML Transmission Control Protocol Java Virtual Machine Business Logic Layer Data Access Layer Information Technology Unified Modeling Language Document Object Model Uniform Resource Locator Business Rule Structured Query Language Windows Communication Framework Language Integrated Query

Introduction

1
1.1.1

Introduction
Problmatique

Le prsent travail va trouver une utilit dans le cadre du jeu Portfolio Management Simulation (PMS) de lassociation Brsenspiel der Schweizer Universitten (BSU). Il sagit dune simulation boursire destine aux tudiants des hautes coles suisses. Lorganisation de ce jeu repose sur du travail de marketing, de finances et dinformatique. Lassociation BSU et forme dune quipe dtudiants denviron 8 personnes qui fournissent leurs comptences dans les domaines cits prcdemment. Les interactions entre ces domaines sont nombreuses. Lquipe de gestion par exemple dfinit les nouveauts du jeu que lquipe dinformatique doit implmenter. Lquipe de marketing demande des statistiques et des changements pour rendre le site plus populaire. Lensemble de linfrastructure informatique de la BSU est ainsi trs sollicit. Outre la maintenance, il faut galement garantir la prennit du jeu chaque anne en offrant de nouvelles fonctionnalits, en amliorant le support aux joueurs et en offrant une qualit grandissante de jeu. Pour ce faire, lamlioration du systme informatique rgissant le jeu et ladministration qui y est lie est un besoin non ngligeable. Cette amlioration passe par la mise en place dune nouvelle architecture. Laccs aux donnes doit par ailleurs tre lun des points-cls de larchitecture. Larchitecture Service Oriented Architecture (SOA) ainsi que le mapping relationnel-objet font parler deux depuis quelques annes. Ce travail souhaite vrifier la possibilit dune intgration de ces principes dans le systme informatique de la BSU en vue de dfinir une nouvelle architecture. 1.1.2 Objectifs

Le prsent travail sarticule autour dune partie thorique et dune partie pratique. Il aura pour objectif damener des rponses aux questions scientifiques suivantes daprs ces parties : Partie thorique Quentend-ton par une architecture du systme dinformation (SI) ? Quelle est lutilit dune architecture structure et planifie ?

Introduction Quels sont les apports de la SOA ? Comment relier le code et les donnes dans une application ?

Partie pratique Quelles sont les exigences pour le calcul du jeu PMS ? Quelle est larchitecture du systme PMS ? Comment intgrer le mapping relationnel-objet avec la technologie .NET dans le cadre dun projet ? Quest-ce que la nouvelle architecture apporte de plus par rapport lancienne ?

Ce travail veut galement proposer une nouvelle architecture au jeu PMS. La recherche et la mise en place de cette nouvelle architecture permettra de rpondre aux questions prcdentes. Une partie de limplmentation de cette architecture sera galement ralise dans le cadre de ce travail en dveloppant le module PMS Core. Ce module sert calculer et mettre jour les portefeuilles des joueurs lissue de chaque journe de jeu. Le dveloppement et ltablissement de larchitecture de rfrence saxera autour dune architecture de type SOA. Cette architecture soriente en gnral vers les grandes entreprises en raison de son cot et de sa complexit. Mais ce travail veut galement dmontrer quen adoptant certains principes de bases de ce type darchitecture, il peut en rsulter un systme stable et volutif. Limplmentation du module et de la nouvelle architecture sappuiera sur les technologies .NET dj utiliss dans le jeu ainsi que sur de nouvelles technologies qui seront expliques plus loin dans ce travail. La premire partie de ce travail dfinit la notion darchitecture de systme dinformation. Le type SOA sera particulirement analys et mnera la dfinition et ltude de la mise en place dune architecture de rfrence SOA. Reprenant ces points, lutilit dune architecture structure et planifie sera dmontre. La deuxime partie prsente le mapping relationnel-objet, son utilit dans la nouvelle architecture ainsi que la technologie qui sera choisie parmi les nombreuses disposition. La troisime partie sera ddie la modlisation de larchitecture cible de la BSU et enfin la dernire partie entrera au cur de limplmentation de PMS Core.

Introduction 1.1.3 Dmarche utilise

La lecture et ltude de textes pertinents lis ces thmes fourniront une base de connaissances sur laquelle sappuyer. Pour rpondre aux questions formules dans le chapitre prcdent, une dmarche empirique sera adopte mais appuye par des mthodes dductives. Lide est de partir de connaissances gnrales pour dvelopper des connaissances plus spcifiques en saidant dexprimentations.

Architecture de SI

Architecture de SI

Ce chapitre va au travers de la littrature et une rflexion personnelle essayer de rpondre aux questions suivantes : Quentend-ton par une architecture du systme dinformation (SI) ? Quelle est lutilit dune architecture structure et planifie ? Quelles sont les apports de larchitecture oriente services (SOA) ? Comment relier le code et les donnes dans une application ?

La recherche dune rponse ces questions va permettre de poser une base thorique indispensable pour la comprhension et llaboration de la future architecture du jeu Portfolio Management Simulation (PMS). 2.1 Dfinition et analyse dune architecture du systme dinformation (SI) Pour aboutir une dfinition dune architecture SI, il faut au pralable dfinir le terme darchitecture ainsi que la notion de systme dinformation. Une architecture de manire gnrale peut tre dfinie de la manire suivante : Larchitecture est lensemble de dcisions significatives propos de lorganisation dun systme informatique. [Bass al. 2003] La dfinition dun systme dinformation est la suivante : Un systme dinformation est un ensemble organis de ressources (matriel, logiciel, donnes et procdures) qui permet de regrouper, classifier, de traiter et de diffuser de linformation sur un phnomne donn. [Wikipedia 2010] Une architecture de systme dinformation doit donc dfinir des afin dimplmenter et de comprendre un systme qui pour tche de grer linformation de la manire la plus flexible possible. Les motivations pouvant mener adopter une telle architecture sont les suivantes : Simplification des processus mtiers grce une dcouverte et une limination de la redondance dans les processus mtiers. Augmentation des capacits dintgration de lentreprise grce une meilleure consolidation et transmission des donnes. Larchitecture pousse adopter des standards pour le partage des donnes.

Architecture de SI -

10

Migration plus rapide grce une structure simplifie avec absence de redondance.

Dans le cas de la BSU, le systme dinformation doit remplir plusieurs fonctions : Collecter des informations o Exemples : cours des titres, paiements des joueurs, effectues par les joueurs,...) Mmoriser les informations et galement mmoriser les informations passes o Exemples : stockage dans la base de donnes des transactions des joueurs, stockage dans la base de donnes des cours historiques Traiter les informations o Exemples : calcul des portefeuilles des joueurs, mise jour dans la base de donnes, gnrer des listes de rsultats Transmettre les informations o Exemples : mise disposition des rsultats aux joueurs, informations aux gestionnaires du jeu de ltat des paiements Le systme dinformation de la BSU remplit donc dj bon nombre des fonctions que lon retrouve dans la majorit des systmes dinformations. Larchitecture du systme dinformation de la BSU nest pas encore clairement tablie. Il en rsulte ainsi des difficults dvolution, des problmes de qualit dans les diffrentes fonctions ainsi quune complexit vitable malgr un jeu que lon peut qualifier de fonctionnel. Le prochain point vise dcouvrir un type darchitecture de systme dinformation qui peut permettre de rsoudre ces points ngatifs du systme actuel. 2.2 Aperu de larchitecture de type SOA transactions

Le terme SOA signifie architecture orient services. La dfinition suivante peut tre donne : SOA est une architecture mtier conceptuel o les fonctionnalits mtiers, ou la logique de lapplication, est mise disposition aux utilisateurs SOA ou aux utilisateurs, en tant que services rutilisables et partags dans un environnement informatique. Les services dans une SOA sont les modules dune fonctionnalit de lapplication avec des interfaces exposes et qui sont invoques par messages. [Marks/Bell 2006]

Architecture de SI

11

Ce type darchitecture suit des principes de modlisation modernes. Quelquun de ces principes sont les suivants : Larchitecture doit reposer sur le concept doffre et de demande de services. Les composants doivent pouvoir communiquer entre eux de manire asynchrone et doivent tre coupls faiblement. Larchitecture doit tre dcoupe en plusieurs couches o Note : Larchitecture n-couches la plus connue est probablement la modle-vue-contrleur (MVC) o lon trouve les couches prsentation, mtier et donnes. Ces principes doivent permettre de rendre le systme flexible pour sadapter la stratgie de la socit. Cette flexibilit dcoule du fait que les services sont rutilisables grce une interface standardis, une facilit dintgration accrue pour une complexit plus faible. Outre sa flexibilit, les bnfices de la SOA peuvent tre nombreux comme le montre la Figure 1. Lagilit mtier permet la SOA de sadapter rapidement son environnement mtier en maintenant des services salignant aux demandes clientes. Une rduction des cots est atteinte par une meilleure rutilisation des services existants ainsi quune meilleure maintenance grce une consolidation des applications par des services rutilisables. Cette rduction des cots en conjonction avec une satisfaction du client amne lentreprise accroitre ses revenues. Les fusions et acquisitions (M&A Mergers and Acquisitions) se passent plus facilement grce une intgration facilite par la SOA.

Agilit mtier

Rduction des cots

Accroissement revenues

Flexibilit IT

M&A plus rapide

Satisfaction du client

Plus rapidement vers le march

Plus de productivit

Rutilisation des services

Figure 1 : Bnfices dune SOA [Marks/Bell 2006, p.134]

Architecture de SI

12

Lapplication compose rsultant de lassemblage de ces services est mise disposition des utilisateurs. Dans une architecture SOA, les services se doivent de disposer dune interface standard pour accder aux fonctionnalits logicielles quelles proposent. Lutilisation de services web est donc frquente. Un service web possde les caractristiques suivantes : Couplage faible grce une communication par message Linterface du service est standard et auto-descriptive

Ces proprits font que les services web peuvent interagir entre eux et fournissent une description de leurs fonctionnalits et la faon dy accder. Les services web les plus utilises sont de type Simple Object Access Protocol (SOAP) over HTTP. La spcification SOAP dfinit : Les rgles de traitement du message SOAP Les fonctionnalits et modules SOAP Les rgles qui dfinissent une liaison un sous-protocole utilis pour changer les messages SOAP entre les nuds SOAP La structure du message SOAP

Le standard Extensible Markup Language (XML) est utilis pour dfinir ces proprits de SOAP. Plusieurs mthodes de transport existent mais la plus utilise est videmment le protocole HTTP (ou HTTPS). La solution SOAP sera la technologie retenue dans ce travail toutefois dautres alternatives intressantes existent tels que le trs connu Common Request Object Broker Architecture (CORBA). Le standard Web Service Description Language (WSDL) est fortement associ aux services web et notamment au standard SOAP. Il confre au service son ct autodescriptif. Lassociation de ces standards a donn lieu aux services web WS-*, appels aussi services de deuxime gnration. On les dfinit selon le type darchitecture SOA. La supervision des standards SOAP et WSDL est la charge du W3C. Lorganisation WS-I publie entre autre des profils afin dassurer et damliorer linteroprabilit entre les dveloppements de services web.

Architecture de SI

13

Le standard Universal Description Discovery and Integration (UDDI), annuaire de services bass sur XML a galement une place importante dans la SOA. Publi par OASIS, il permet la dcouverte des services web. Les informations donnes permettent de connatre ladresse utiliser pour atteindre le service, les fonctionnalits offertes, les responsables du service et dautres informations utiles. Windows serveur inclus par dfaut un serveur UDDI mais ils existent des alternatives commerciales et open source notamment Apache JUDDI, BEA Aqualogic Service Registry, Novell UDDI Server, 2.3 Dfinition dun modle de rfrence SOA et conception dune architecture de rfrence SOA Le modle de rfrence SOA a t spcifi par lOASIS dans sa publication Reference Model for Service Oriented Architecture 1.0 [OASIS 2006]. Cette organisation pense que la grande attention porte aux SOA a men trop de dfinitions divergentes. Le but est donc de fournir un modle gnrique de modlisation dune SOA. Ce modle de rfrence est donc une abstraction de toutes les SOA visant donner des dfinitions communes toutes les SOA. Ce modle de rfrence fait abstraction des technologies et des implmentations.

Figure 2: Architecture de rfrence SOA [OASIS 2006] Larchitecture de rfrence SOA (cf. Figure 2) est une spcification fonctionnelle avec laquelle on peut implmenter une SOA. Larchitecture de rfrence va donc se baser sur les dfinitions du modle de rfrence SOA. Larchitecture de rfrence peut galement

Architecture de SI

14

tre dfinie comme larchitecture cible idale atteindre. Elle permettra ainsi de dfinir une roadmap partant de larchitecture actuelle la future architecture. LOpenGroup fournit un blueprint pour la conception et lvaluation de SOA dans sa publication SOA Reference Architecture [The Open Group 2009]. Llaboration dune architecture de rfrence SOA doit idalement se faire en suivant les standards proposs auparavant. Le modle de rfrence propos par lOpenGroup peut sadapter nimporte quel type de socit. Il est ainsi possible par raison de cots de supprimer une couche. 2.4 Utilit dune architecture structure et planifie

De nos jours, la stratgie dune entreprise est de plus en plus complexe et est sujette de nombreux changements. Ces changements peuvent tre dus un repositionnement face aux concurrents, une volont de rduction des cots, et bien dautres facteurs amenant lentreprise revoir sa stratgie. Le systme dinformation doit ragir face ces changements en sadaptant la stratgie. Les cots et le temps ncessaires cette adaptation sont des facteurs cruciaux pour lentreprise. Ds lors la prsence dune architecture structure et planifie dans le systme dinformation de lentreprise est importante pour mener bien ces adaptations. Une architecture structure et planifie peut amener les avantages suivants : Systme flexible sadaptant lenvironnement mtier Gestion du systme dinformation plus efficace grce une structure permettant une meilleure allocation des ressources humaines et matrielles. Augmentation de la consistance des informations grce une reprsentation standardise de linformation Intgration et partage de linformation facilite

Prsentation du mapping relationnel-objet

15

Prsentation du mapping relationnel-objet

Par une recherche thorique, ce chapitre se veut de rpondre aux questions suivantes : 3.1 Quapporte le mapping relationnel-objet ? Dfinition

Le mapping relationnel-objet est une technique permettant de transformer dun modle lautre les modles objets et relationnels. Pour cela une correspondance est tabli entre le modle relationnel et le modle objet, do le terme de mapping. Les bases de donnes ne peuvent comporter que des types scalaires bien dfinis et des chanes de caractres. Un type scalaire est un type de variable scalaire, une variable scalaire tant une variable qui ne peut contenir quune valeur atomique. Les types les plus connues sont par exemple String, Char, Integer, Float ou encore Double. Cette structure nest malheureusement pas idale lorsquil y a utilisation de programmation orient objet. En effet les objets contiennent souvent des valeurs non scalaires. Le programmeur doit donc effectuer de laborieuses transformations afin de sauver ses objets dans la base de donnes. Ces transformations peuvent tre en parties automatises grce au mapping relationnelobjet, le programmeur se restreignant configurer les correspondances. Ainsi le programmeur peut lire, modifier et crer des objets sans se soucier de la base de donnes. Il va galement de soi que le code ncessaire la gestion des donnes se rduit drastiquement et la complexit avec. 3.2 Rle dans larchitecture de type SOA

Dans une architecture n-couche, par exemple de type SOA, une couche importante est celle de laccs aux donnes (cf. Figure 3). Cette couche doit offrir la possibilit de manipuler dune manire flexible les enregistrements de la base de donnes. Cette couche comportera en gnral une classe, classe dite Data Access Object (DAO), correspondante chaque table de la base de donnes. Des mthodes sont prsentes crer, lire, modifier et supprimer un enregistrement. On parle dinterface CRUD (Create, Read, Update, Delete).

Prsentation du mapping relationnel-objet

16

Figure 3 : Application n-tier Couche daccs aux donnes [Ros 2003] Le mapping relationnel-objet nest pas directement li aux SOA. Cette couche daccs aux donnes peut trs bien se passer de cette technologie. Mais comme expliqu auparavant, cette technologie permet de diminuer le code et la complexit, le programmeur ne traitant que des objets. Elle trouve donc un rle apportant des gains de temps et de cots. Par ailleurs, ils existent des outils de persistance offrant la mapping relationnel-objet. Ils ont lavantage de proposer galement un fort dcouplage avec la base de donnes en plus des nombreuses fonctionnalits offertes tels que la mise en cache, la gestion de la concurrence, etc. Ce dcouplage rentre dans le concept de la SOA. 3.3 Outils de mapping relationnel-objet existants

De nombreux outils existent sur le march en version open source ou commerciale. Ces outils proposent des fonctionnalits communes mais aussi des fonctionnalits propres chacun de ces outils. Les fonctionnalits suivantes sont en gnral demandes par une majorit de programmeurs : Utilisation de lhritage et du polymorphisme : Il faut profiter de la POO pour donner une structure aux entits (ex : hirarchie) Grer les transactions, agrgations et groupement : Prsentes dans SQL, elles se doivent de ltre galement dans le mapping relationnel-objet. Grer les diffrents types de relation : Une relation 1-n sera ainsi reprsente dans une classe DAO par un tableau. Ces fonctionnalits apparaissent comme indispensables pour que le mapping relationnel-objet napporte pas plus de dsavantages quavantages. De nombreuses

Prsentation du mapping relationnel-objet

17

autres fonctionnalits sont en gnral fournies. Les critres dadoption dun outil dpendront du besoin de larchitecture. Pour le cas de la SOA, il est ainsi important de considrer dautres fonctionnalits : Les objets doivent pouvoir tre convertis sous forme de message . La srialisation le permet en transformant lobjet sous forme de chaine de caractre dans un format standard. Les objets doivent pouvoir tre stocks sous diffrents formats donc diffrents support de stockage (SQL, XML, ) Parmi de bons outils de mapping relationnel-objet pour .NET, on peut citer : LINQ to SQL NHibernate ADO.NET Entity Framework DataObjects.NET ObjectMapper.NET

Les technologies Microsoft, LINQ to SQL et ADO.NET Entity Framework, permet doffrir rapidement un accs aux donnes aux applications. ADO.NET Entity Framework a toutefois lavantage de ne pas tre dpendant du schma relationnel en programmant son propre modle conceptuel. Il est possible en quelque sorte de dfinir plus librement le mapping quavec la technologie LINQ to SQL. NHibernate est un produit open source sous licence LGPL (Lesser GNU Public Licence). Il offre pratiquement autant de fonctionnalits que ADO.NET Entity Framework et constitue un bon choix pour les programmeurs ayant dj connaissance de sa version en Java, Hibernate. DataObjects.NET et ObjectMapper.NET sont des solutions commerciales qui mettent en avant une performance accrue ainsi quune approche plus programmatique que leurs concurrents gratuits pour une gestion du mapping relationnel-objet plus avance.

Structure gnrale de larchitecture de rfrence de la BSU

18

Structure gnrale de larchitecture de rfrence de la BSU

4.1

Aspects prendre en compte

La dfinition dune architecture de rfrence (cf. chapitre 2.3) pour la BSU devra prendre en compte les ressources et du temps disposition pour mettre en place la nouvelle architecture. Lassociation disposant de moyens faibles et de temps limit, il est primordial dadopter une architecture qui pourra tre maintenue long terme. La SOA devra apporter : Flexibilit et rapidit quant lvolution du jeu PMS Administration de la BSU facilite. Intgration de nouveau modules dadministration et modifications des actuelles dans les meilleurs dlais. Ces objectifs devront tre remplis en choisissant une architecture de rfrence respectant au mieux le modle de rfrence SOA (cf. chapitre 2.3). 4.2 Vue des diffrentes couches

De nombreuses architectures de rfrences existent dj. Larchitecture qui a t choisie dans le cadre de ce travail (cf. Figure 4) a t labore par lentreprise IPT [ipt 2010] et propos par Mr. Stefan Hsemann.

Figure 4 : Architecture de rfrence de lentreprise IPT [ipt 2010]

Structure gnrale de larchitecture de rfrence de la BSU

19

La couche donne est compose de base de donnes relationnelle et de datawarehouses qui contiennent les donnes ncessaires aux exigences mtiers de lentreprise. La couche daccs aux donnes permet daccder ces donnes et leur offrir un moyen daccs standard et unique. Cet accs peut soit tre rutilisable grce lutilisation de services de donnes ou soit tre priv si le besoin en est. La logique mtier est contenue dans la couche logique mtier. Il sagit dune couche importante permettant de sparer la logique des donnes et de la couche prsentation. Les composants de cette couche sont les suivants : Services mtiers : Ils fournissent des lments logiques rutilisables Logique mtier prive : Il sagit dimplmentation de logique spcifique une application Business Rule Engine : Ce composant permet de modifier de la logique mtier. Il excute des rgles mtiers externalise du code. Dans la couche intgration, le composant ESB (Entreprise Service Bus) est un intergiciel permettant lintgration dapplications htrognes. Pour offrir des processus rels la couche prsentation, il faut assembler certains services et les intgrer. La couche dintgration sen charge avec un composant appel moteur dorchestration. Ce composant utilise en gnral le langage BPEL (Business Process Execution Language) dfini comme standard et utilisant un langage driv du XML. Finalement la couche prsentation offre une interface aux utilisateurs sous la forme dune application web ou dun portail via un serveur web. La couche client dfinit les applications utilises pour accder la couche de prsentation telle quun navigateur web. Le client peut aussi utiliser une application client riche. Il sagit dapplications traditionnelles qui se connecteront en gnral directement aux services mtiers 4.3 Roadmap vers larchitecture de rfrence SOA

La roadmap SOA est un plan unique du systme dinformation de lentreprise qui est dfini itrativement et incrmentalement au fur et mesure de lavancement. La maturit de la roadmap doit voluer conjointement avec la maturit de la SOA. Par ailleurs elle doit galement tenir compte de lenvironnement global en distinguant les 6

Structure gnrale de larchitecture de rfrence de la BSU

20

domaines lis entre eux (cf. Figure 5 : Les 6 domaines dfinis par BEA [BEA 2005]). La roadmap dfinit une ligne du temps transparent et flexible pour accomplir les objectifs de la SOA. Des tests de qualits sont galement effectus chaque tape.

Figure 5 : Les 6 domaines dfinis par BEA [BEA 2005] Construction de la roadmap selon les tapes dfinies dans le livre blanc de BEA Systems [BEA 2005] : 1. Planification de la SOA La SOA est organise et dfinie. Les limites et lenvironnement sont tablis. La SOA est galement justifie et sa capacit remplir les besoins actuelles et futurs de lentreprise est dmontre. 2. Evaluation de la maturit de la SOA Identification des fonctionnalits offertes par la SOA. Analyse de ltat actuel de la SOA par lquipe actuel. 3. Vision future de la SOA Dfinition en quipe de ltat futur dsir de la SOA. 4. Dfinition de la roadmap SOA En se basant sur les 3 phases prcdentes, une analyse des objectifs de la SOA est accomplie et des timelines sont dfinies pour y parvenir. Les objectifs court terme sont dtailles et les objectifs plus long terme sont dcrits plus

Structure gnrale de larchitecture de rfrence de la BSU sommairement afin quils puissent encore sadapter lexprience qui sera acquise par la suite. Analyse tat actuel Dfinition tat futur

21

Dcouverte

Roadmap

Ces phases peuvent tre appliques la BSU de la manire suivante : Dcouverte Le kick-off de la BSU permet chaque anne de runir les parties prenantes de linformatique et de la gestion. Il permet de comprendre la vision informatique, ltat actuel et les besoins. Ce rendez-vous annuel permet daugmenter progressivement le degr de maturit de larchitecture du systme dinformation. Cette phase de la SOA peut donc tre mise en place facilement. Il sagira ainsi de : Dfinir les comptences de la SOA Identifier les limites et la lalignement avec de nouvelles ides IT. Montrer lalignement avec dactuelles et futures ides de gestion Dmontrer lutilit de la SOA

Analyse de ltat actuel A ce stade, les moyens et services de la BSU pouvant servir la SOA doivent tre identifis. Il peut sagir de projets existant pouvant servir de base la SOA. Un exemple sommaire de ltat actuel de la BSU en dpartageant les domaines pourrait tre le suivant :

Structure gnrale de larchitecture de rfrence de la BSU Stratgie et processus mtier Stratgies : - Objectif datteinte dun nombre de joueurs minimum pour la session de jeu - Offre de nouvelles fonctionnalits pour maintenir lattractivit du jeu Processus mtiers : Dfinition du nouveau jeu Publicit : mailing, affiches, agents Configuration du jeu Gestion des paiements des joueurs Etablissement des gagnants et rcompense Sondage Architecture

22

La BSU utilise pour certains de ces projets une architecture MVC. Le standard XML est dj utilis dans plusieurs projets. Cots Les cots inhrents au systme dinformation actuel de la BSU est quasi nul. Toutefois grce au sponsoring la BSU possde des moyens qui normalement seraient sujets des cots tels que les machines virtuelles par exemple. Blocs de constructions Technologies : .NET, SQL, XML Services : Important de cours, calcul de jeu, configuration du jeu Outils : Datawarehouse, outils de sauvegarde Processus : Mise en place dune nouvelle session de jeu, calcul des portefeuilles, clture du jeu Projets et applications Applications existantes : calcul de jeu, PMS Quotes, PMS Configuration Projets prvus : PMS Payments, PMS Core, PMS Administration

Structure gnrale de larchitecture de rfrence de la BSU Organisation et gouvernance Organisation et hirarchie actuelle de la BSU :

23

Vorstand

IT

Gestion

Dfinition de ltat futur Mise en place des modules PMS Core et PMS Administration pour la prochaine session de jeu. Intgration des modules PMS Importation et Configuration la SOA moyen terme. Justification par le fait que toutes ces applications sont des applications composes partir de services communs. Ces applications correspondent galement aux processus mtiers de la BSU. Dfinition des services partages : rcupration des infos dun joueur, rcupration du classement dun joueur, modification dun portefeuille,

Dfinition de la roadmap SOA Objectifs court-terme :

Dfinition dune architecture SOA Implmentation PMS Core et PMS

Administration

Objectifs moyen-terme : PMS Configuration

Intgration des modules PMS Importation et

Partie pratique

24

Partie pratique

Les rponses aux questions de la partie pratiques seront amenes dans ce chapitre. Elles se fonderont sur les apports thoriques des chapitres prcdents ainsi que par lexprimentation dcoulant de limplmentation de la nouvelle architecture. Les questions sont les suivantes : Quelles sont les exigences pour le calcul du jeu PMS ? Quelle est larchitecture du systme PMS ? Comment intgrer le mapping relationnel-objet avec la technologie .NET dans le cadre dun projet ? 5.1 Quest-ce que la nouvelle architecture apporte de plus par rapport lancienne ? Prsentation du jeu PMS et de son environnement

Lassociation BSU a organis depuis sa cration en 1991 plusieurs jeux boursiers pour les tudiants des universits et hautes coles suisses. Actuellement lassociation ne propose plus que le jeu PMS (Portfolio Management Simulation). Ce jeu permet aux participants de grer sur une priode dfinie un portefeuille virtuel. Les titres ngociables sont choisis davance et sont de nature diversifie : actions, obligations, options, devises,.. Pour participer les membres BSU paient une cotisation annuelle. Pour grer tous ces aspects du jeu de manire efficace, il est important pour les membres du comit de la BSU dutiliser un systme dinformation adquat. Une restructuration du systme avait t prvue dans le cadre du projet PMS Top. Lide tait de dcomposer chaque partie du jeu en sous-projet et ensuite dinterconnecter le tout. Sous-projets de PMS Top : PMS Requirements and Test : Dfinition des exigences, Modlisation du systme PMS, documentation PMS Administration : Gestion du jeu PMS. Ce module rassemble PMS Configuration et PMS Core PMS Configuration : Gestion des paramtres du jeu, des membres et des diffrentes instances du jeu

Partie pratique

25

PMS Core : Calcul des portefeuilles et classement. Modification des cours manuellement. PMS Quotes : Importation des cours depuis une source externe et criture dans la base de donnes PMS Environment : Mise en place dun environnement de dveloppement, test et production PMS Web : Site Internet faisant office dinterface de gestion des portefeuilles pour les membres BSU. Actuellement certains projets ont t mens bien, dautres sont en cours de dveloppement et dautres en suspens. Le projet PMS a donn plus de transparence au systme dinformation, de nouvelles fonctionnalits et une meilleure qualit de jeu. Une architecture de rfrence a galement t dfinie dans le cadre du projet PMS Top (cf. Figure 6.

Figure 6 : Architecture de rfrence tablie pour PMS Top

Cette architecture de rfrence reprsente bien ltat actuel ce qui signifie que le projet PMS Top a bien atteint son objectif au niveau architectural.

Partie pratique 5.2 Analyse actuelle de la structure

26

Le projet PMS Top a notamment t lanc pour faire face diffrents problmes techniques : Difficult de configuration de jeu Lenteur de calcul des portefeuilles Problmes dimportation Vieilles technologies prsentes Pas de gestion commune des multiples instances du jeu Pas denvironnement de dveloppement et de test Gestion des connexions des membres sur le site dsute Manque dinnovation

Si de nombreux problmes sont rsolus, dautres sont encore prsents tels que la lenteur du calcul des portefeuilles, la prsence de veilles technologies et le manque dinnovation. Il est donc intressant de se pencher sur les causes qui ont rendus difficile la rsolution de ces problmes. Au sein de lassociation BSU, une moyenne de cinq programmeurs bnvoles sont en charge de relever les dfis rencontrs par lvolution du jeu PMS chaque anne. Les ressources humaines sont donc moindres sachant que lquipe IT ne peut travailler que occasionnellement pour le jeu PMS. Chaque module possde entre autre ses spcificits dimplmentation et ds lors il est difficile de modifier un module cr par un autre dveloppeur. Labsence de code partag au sein de ces projets rend la tche du programmeur compliqu, ce dernier nayant aucune base sur laquelle sappuyer. 5.3 Modifications de la structure envisages

Afin damener une solution aux problmes cits auparavant, il est utile denvisager une volution de la structure actuelle. Cest pourquoi ce travail souhaite proposer une nouvelle architecture. Pour ce faire, cette dernire sappuiera sur larchitecture de rfrence propose dans le chapitre 4.2. 5.3.1 Architecture cible

Larchitecture cible est clairement simplifie par rapport larchitecture de rfrence pour rpondre aux exigences de la BSU sans toutefois apporter une complexit inutile. Grce aux nombreux outils fournis par le framework .NET, le temps dimplmentation

Partie pratique

27

est limit. Les choix des outils et technologies qui seront utiliss seront expliqus au chapitre 5.5. Les couches intgration et orchestration ont t retires pour l'architecture cible (cf. Figure 7) car elles ne correspondent pas aux besoins du jeu PMS mme long terme.

Figure 7 : Nouvelle architecture pour le jeu PMS 5.3.2 Consquences et avantages de la nouvelle architecture

La nouvelle architecture cible (cf Figure 7) amne de nombreux avantages concrets pour le jeu PMS. Cration rapide dun nouveau module en se servant de services existants, un module tant un lment du systme. Mise jour facilit dun service en cas de bug, modification de la logique, migration vers une nouvelle technologie Support de donnes interchangeable Couche de prsentation unique permettant dafficher rapidement de nouveaux types de donnes ou de la modifier sans crainte de modifier la logique Transparence de larchitecture : accs identique tous les services (standard) Indpendant du langage de programmation. Un programme en Java exploitant des services web PMS peut tre crit par exemple.

Partie pratique

28

Par ailleurs un changement de rle intervient dans certains projets de PMS Top (cf. chapitre 5.1). Ce travail a pour but dimplmenter les projets PMS Core et Administration selon larchitecture dfinie (cf. Figure 7). Les changements majeurs dans PMS Top sont les suivants : PMS Core a dsormais la responsabilit de publier les services communiquant avec la couche de donnes. Une partie de PMS Administration est dj prsente grce la possibilit de rutilisation de librairies existantes dans PMS Configuration. Ces librairies seront tendue afin doffrir une meilleure abstraction et des services web exposeront les fonctionnalits. Une partie de la logique pourra galement tre reprise de PMS Configuration pour crer les services mtiers car une couche daccs aux donnes est dj prsente. PMS Administration consommera les services de PMS Core afin doffrir des vues de gestion (changement priode, lancement calcul, correction du cours dun titre). La majorit du travail rsidera donc dans limplmentation de PMS Core. Les rgles de calculs seront revues et une abstraction suffisante sera cre afin de laisser la libert de crer de nouvelles rgles de calculs de portefeuille ou de classement. Ce travail permettra galement de rsoudre des problmes dans la logique de calcul rencontre lors de la dernire session de jeu. PMS Administration ne regroupe donc plus PMS Core et PMS Configuration mais reprsente un nouveau projet dans PMS Top charg doffrir une interface de gestion pour le calcul du jeu.

Partie pratique 5.3.3 Services mtiers

29

Diffrentes types de services seront construits. Les types les plus communs suivant la classification du livre de Erl [Erl 2007]. Services entits Ce service se base sur les entites mtiers. Il fournit en gnral les oprations create-read-delete-update (CRUD). Il sagit dun service hautement rutilisable. Services de tche Ce service mtier est associ une tche parent ou un processus. La rutilisabilit tend tre moindre. Services utilitaires Certains services nont pas besoin dune logique associe un modle mtier ou un processus. Il fournir des fonctionnalits rutilisables et utilitaires. Cette classification est utile dans le cadre de ce travail car diffrents types de services sont mis en place (cf. Figure 8).

Services de tche

Services utilitaires

CalculService nextGamePeriod prevGamePeriod nextWebPeriod prevWebPeriod -

CoreUtil

backupDB restoreDB

Services entits

QuotesService

getQuotesForPeriod updateQuote

Figure 8 : Types de services dans la nouvelle architecture

Partie pratique 5.4 Dfinitions de cas dutilisations et rgles mtiers pour le module PMS Core

30

Le langage Unified Modeling Language (UML) est utilis afin de spcifier le processus de calculs des portefeuilles et des classements. Des cas dutilisations dcrivent les exigences fonctionnelles de PMS Core. Les rgles mtiers dfinissent la prise de dcisions dans la logique mtier. 5.4.1 Cas dutilisations

Cette partie dcrit les fonctionnalits du module PMS Core. Toutes ces fonctionnalits sont accessibles depuis ladministration web. La plupart de ces cas dutilisations ont dj t dfinis dans le cadre du travail dElira Shehu [Shehu 2008]. Ce nouveau diagramme (cf. Figure 9) doit tre vu comme une mise jour de ce dernier correspondant au module PMS Core implment et mis en place dans le cadre de ce travail.

Figure 9 : Cas dutilisation pour le module PMS Core

Partie pratique 5.4.1.1 Descriptions des cas dutilisations

31

Une brve description accompagne chaque cas dutilisation de la Figure 9 pour un souci de clart. UC7 : Avance dune priode le calcul des portefeuilles des joueurs UC32 : Recule jusqu une priode choisie le calcul des portefeuilles des joueurs UC4 : Permet de corriger dventuelles erreurs de cours due une importation errone dans une priode choisie UC33 : Avance dune priode sur le site. Il sagit de la priode dans laquelle les joueurs peuvent effectuer des transactions. UC34 : Recule dune priode sur le site. Il sagit de la priode dans laquelle les joueurs peuvent effectuer des transactions UC28 : Effectue les transactions des joueurs en passant les ordres dachat ou de vente UC29 : Calcule les intrts dus entre deux priodes aux comptes des joueurs UC30 : Mets jour les diffrentes listes de classements UC31 : Mets jour le compte des joueurs en crditant les intrts et en dbitant/crditant les gains/pertes des joueurs. UC32 : Avance une priode spcifique le calcul du portefeuille d'un joueur 5.4.1.2 Spcification du cas dutilisation UC7 (Avance dune priode de calcul des portefeuilles des joueurs) Une description plus complte et structure accompagne gnralement les cas dutilisations pour amliorer leur comprhension. Le cas dutilisation UC7 (cf. Figure 9) qui est lune des fonctionnalits les plus importantes du jeu est spcifi ci-dessous. Objectif : Cette fonctionnalit permet de calculer ltat du portefeuille des joueurs, ltat du compte en banque des joueurs ainsi que de mettre jour les listes de classements pour la priode suivante. Acteur : Ladministrateur du jeu Prconditions : Ladministrateur utilise une interface disposant de cette fonctionnalit offerte par PMS Core

Partie pratique La priode actuelle est infrieure ou gal la dernire priode du jeu Le jeu a t initialis par PMS Configuration Limportation des cours sest effectue correctement

32

Scnario principal : 1. Le cas dutilisation commence quand ladministrateur veut faire calculer une priode de jeu. 2. Ladministrateur choisi le type de jeu. 3. PMS Core affiche les dtails sur ltat du jeu choisi. 4. Ladministrateur clique sur le bouton calculer priode . 5. Si des nouveaux portefeuilles sont prsents, ces derniers sont actualiss la priode actuelle. o INCLUDE [UC32 Avance une priode spcifique le calcul du portefeuille d'un joueur] 6. PMS Core calcule la priode pendant le calcule PMS Core affiche des informations sur lavancement du calcule o INCLUDE [UC28 Effectuer les transactions] o INCLUDE [UC29 Calculer les intrts des joueurs] o INCLUDE [UC30 Mettre jour les classements] o INCLUDE [UC31 Mettre jour le compte des joueurs] 7. PMS Core affiche linformation que le calcule est termin avec succs. Des statistiques sur le calcule sont affichs (dure du calcule, nombre de transactions pris en compte, nombre de joueurs calculs etc.) 8. Le cas dutilisation se termine ici Scnario alternatif 6a problme durant le calcul : Condition de branchement : un problme surgit durant le calcul de la priode 6a1 PMS Core napplique pas les modifications sur la base de donnes 6a2 PMS Core affiche un message derreur qui permet didentifier la raison de lerreur. 6a3 Ladministrateur analyse lerreur. 6a4 Le cas dutilisation se termine ici. Scnario alternatif 6b calcul de plusieurs priodes :

Partie pratique

33

Condition de branchement : L'administrateur choisit de calculer plusieurs priodes 6b1 L'administrateur choisit une autre priode calculer que celle par dfaut (Priode actuelle + 1). 6b2 Le scnario 6 est rpt jusqu' atteindre la priode souhait Postconditions en cas de succs : La mise jour des comptes en banque, des portefeuilles et des listes de classement sest faite sans erreur La priode de calcul est avance

Postconditions en cas dchec: La mise jour des comptes en banque, des portefeuilles et des listes de classement na pu seffectuer La priode de calcul nest pas avance Les transactions ne sont pas calcules

Rgles de gestion : Si des transactions lies des titres dont le cours utilis pour le calcul est faux, ladministrateur doit corriger les erreurs de cours (UC5) et rutiliser la prsente fonctionnalit. Point dextension : Aucun point dextension 5.4.2 Rgles mtiers

La prise de dcisions consistantes pour une entreprise dpend de faits et rgles consistantes et de haute qualit qui sont mises disposition preneurs de dcision et des systmes. Ces faits et rgles sont connues sous le nom de rgles mtiers. [Von Halle 2006]. Des rgles mtiers ont ainsi t dfinies pour PMS Core afin de dfinir des rgles de calculs pour les portefeuilles des joueurs. Elles sont dune grande aide dans la spcification et la gouvernance de projets en dcrivant des comportements prcis en dtails. Elles font galement office dexcellentes documentations pour les projets grce leur clart. Les diffrentes entres des rgles mtiers sont lues de la faon suivante :

Partie pratique

34

Nom : Il donne une ide globale du sujet de la rgle. Il est en gnrale clair et concis.

Identifiant : Il permet de rfrencer la rgle afin de la citer dans dautres rgles ou den faire rfrence dans un document externe.

Description : Elle donne une description prcise de la rgle. Si la rgle est change, il est capital de mettre jour ce champ et dajouter le champ rvision pour indiquer la date et lauteur du changement en question.

Exemple : Pour mieux comprendre la rgle et viter dventuels mauvaise interprtation, un exemple vient appuyer la description.

Rgles lies : Permet de rfrencer les rgles ayant un impact sur la rgle

Les rgles mtiers de lensemble de rgles Effectuer les transactions sont prsentes ci-aprs afin daider le lecteur dans leur lecture et interprtation.

Nom Identifiant Description

Options Eurex BR1 Si le prix dune option Eurex est de 1 centime, il nest pas possible de lacheter. La transaction nest dans ce cas pas marque comme calcul afin que PMS Web puisse informer le joueur du refus de la transaction.

Exemple

Si une option FESX tombe un prix de 0.01 et quun achat est effectu, lachat est annul.

Rgles lies

Nom Identifiant Description

Nombre de titres maximum par catgorie BR2 Un pourcentage maximum de titres dune mme catgorie est dfini pour le portefeuille. Tout achat de titres dans cette catgorie est plafonn ce pourcentage.

Partie pratique Exemple

35 Si le pourcentage maximum pour la catgorie options eurex est de 5%, les options eurex existantes du portefeuille atteignent 5'000 CHF et que la valeur totale du portefeuille est de 100'000 CHF, aucune option eurex supplmentaire ne pourra tre achete.

Rgles lies

Nom Identifiant Description

Crdit BR3 Lachat de titre ne peut amener la valeur du portefeuille dpasser le solde en banque disponible ajout au montant du crdit accord.

Exemple

Si le crdit accord est de 2000 CHF et le solde en banque de 10'000 CHF, il nest pas possible dacheter pour plus de 12000 CHF

Rgles lies

Nom Identifiant Description

Calcul des frais de courtage BR4 Les frais de courtage sont calculs selon un pourcentage dfini. Un minimum et un maximum de frais de courtage sont dfinis

Exemple

Si une transaction a pour montant 10'000 et que le pourcentage de courtage est de 2%, les frais de courtages sont de 200 CHF.

Rgles lies

Nom Identifiant Description

Calcul du cot de lachat dun titre BR5 Le calcul seffectue par la multiplication du nombre de contrats souhaits pour un titre par la grandeur du contrat et par le cours du titre la fermeture du march suivant lachat du titre. Les frais de courtages y sont galement ajouts. Une option Eurex un cours de 1 centime ne peut tre achete (BR1)

Exemple

Si un joueur achte 10 contrats dune option ABB avec une grandeur de contrat de 10 et un cours pour loption la fermeture de 2 CHF, le

Partie pratique prix dachat sera de 200 CHF (10*10*2) plus les frais de courtages. Rgles lies BR4, BR1

36

Nom Identifiant Description

Calcul du revenu dcoulant de la vente dun titre BR6 Le calcul seffectue par la multiplication du nombre de contrats vendre pour un titre par la grandeur du contrat et par le cours du titre la fermeture du march suivant lachat du titre. Les frais de courtages y sont dduits.

Exemple

Si un joueur vend 10 contrats dune option ABB avec une grandeur de contrat de 10 et un cours pour loption la fermeture de 2 CHF, le revenu sera de 200 CHF (10*10*2) moins les frais de courtages. Le systme ne permet toutefois pas de calculer le gain ou la perte effectue en calculant la diffrence entre le prix dachat et vente du titre.

Rgles lies

BR4

On remarquera que ces rgles sont atomiques (ne se dcomposent pas) et cohsives. Ces critres permettent de dfinir les rgles plus facilement. Latomicit par ailleurs permet daugmenter la rutilisabilit de ces rgles.

La dfinition de ces rgles devrait apporter une meilleure comprhension du fonctionnement du jeu pour toutes les parties prenantes en clarifiant le processus plutt complexe du calcul des portefeuilles. Les rgles dfinies dans lAnnexe A contiennent certaines contraintes pour le jeu qui ne sont parfois pas videntes car ntant pas en phase avec la ralit pour des raisons techniques et de temps dimplmentation. Une personne non avertie peut ainsi prendre connaissances des spcificits du calcul au sein de PMS Core.

Partie pratique 5.5

37

Choix des composants tiers pour un dveloppement du projet sous .NET

Les composants tiers ont t choisis selon plusieurs critres : Remplissent des besoins dune architecture de type SOA Permettent de diminuer la taille du code Offrent une maintenance facilite Garantissent leur utilisation long terme (continuit) Sous licence Open Source ou gratuites

La Figure 10 permet de visualiser les diffrents composants tiers utiliss et quelle place ils occupent dans larchitecture (cf. chapitre 5.3.1). Chacun de ces composants fera lobjet dune explication dans les sous-chapitres suivants et la raison de son choix sera argumente.

Figure 10: Intgration des technologies dans larchitecture

Partie pratique 5.5.1 LINQ to SQL

38

Ce produit de Microsoft apparu dans le Framework 3.5 permet de crer un pont entre la programmation orient-objets et les donnes relationnels. Offrant une syntaxe intuitive, cette solution permet de manipuler des donnes sous formes dobjets. Grce son abstraction (cf. Figure 11), il est possible de manipuler diffrents types de donnes quil sagisse de collections dobjets, denregistrements de bases de donnes ou encore de donnes XML.

LINQ to OBJECTS

LINQ to ADO.NET

LINQ to XML

LINQ to SQL

LINQ to Dataset

LINQ to Entities

Figure 11 : Les diffrentes implmentations de LINQ

Limplmentation LINQ to SQL est choisie dans ce projet pour sa stabilit et sa simplicit. Ce choix simpose galement pour rester dans la continuit des autres projets PMS qui ont choisis LINQ. LINQ to SQL va permettre limplmentation de la couche daccs aux donnes (cf. Figure 12). Cette couche est labstraction de la persistance objets. Les couches suprieures de lapplication pourront ainsi manipuler les donnes de manire transparente sans se soucier de la persistance objets.

Partie pratique Client

39

DTO Objects

CalculService BLL Business Logic Layer

DAL Data Access Layer IDALFacade


- CRUD operations

LINQ to SQL

PMS DB Figure 12: Rle de LINQ to SQL dans la nouvelle architecture

Les objets provenant de LINQ to SQL sont uniquement manipules dans CalculService. Une projection vers des objets simplifis, les Data Transfer Objects (DTO), est effectue afin daugmenter le dcouplage et doffrir des objets simples manipuler du ct client.

Le passage de ces objets entre les diffrentes couches dconnecte les objets de leur contexte de donnes. Cest dire que LINQ to SQL nest plus en mesure de suivre les modifications de lobjet pour les rpercuter sur la base de donnes. Il est donc ncessaire dindiquer LINQ quil doit rattacher les objets au contexte. Un autre but de cet attachement est de permettre LINQ deffectuer un test de concurrence. Ainsi une exception sera gnre si lentre a t modifie entre temps,

Partie pratique 5.5.2 Windows Communication Framework

40

Il a t choisi dans la nouvelle architecture PMS de dcoupler la couche client de la couche mtier. Il est donc ncessaire de mettre en place une interface standard proposant les fonctionnalits de la couche mtier la couche client. Le moyen de communication a privilgier est videmment le service web communiquant par HTTP et SOAP. Ce travail tant soucieux de lvolution de larchitecture et des besoins futurs, la technologie Windows Communication Framework (WCF) de Microsoft a t choisie. Ce framework de communication permet de communiquer aisment entre diffrents composants applicatifs. Il runifie galement une majorit de moyens de communications tels que TCP binaire, HTTP et SOAP, COM+, MSMQ pour ne citer que les plus importants. Cette forte abstraction permet de choisir librement le moyen de communication souhaite, appel Binding dans WCF. Il est galement noter, pour se rendre compte de la puissance de ce framework, quil est possible dimplmenter son propre Binding. Le Binding choisit dans ce travail se nomme WSDualHttpBinding. Ce moyen de communication offre des services scuriss permettant aux services ainsi quaux clients denvoyer et de recevoir des messages. On scarte donc du traditionnel service web appelant un service et recevant de manire synchrone une rponse. Ce Binding permet de crer des services asynchrones (cf. exemple de la Figure 13) car le service peut lui aussi appeler des fonctions du ct client. Cette possibilit permettra dans ce travail dappeler des oprations du service coteuses en temps, tel que le calcul des portefeuilles pour une certaine priode, de manire asynchrone. Le client peut ainsi tre notifi de lavancement de la tche ainsi que de lissue du calcul et garde la main durant lexcution du calcul rendant inutile une attente de rponse de la part du service. Service web PMS Core
Etat avancement Oprations Etat avancement
nextPeriod prevPeriod

Appel de nextPeriod

Client

Rsultat / Fin

Figure 13 : Exemple de lappel de lopration nextPeriod sur le service PMS Core

Partie pratique

41

La scurit de ces services est galement prendre compte. Les services du PMS vont oprer dans un environnement semi-scuris tant donn quils ne seront pas accessibles en dehors de leur domaine. Un niveau de scurit minimum est donc requis sur ces services. WCF propose un nombre incroyable de types dauthentification. Lauthentification peut se faire au niveau de la couche de transport (exemple : authentification basic HTTP) ou par message (exemple : authentification Windows). Le type de Binding choisi, WSDualHttpBinding, nous contraint choisir parmi les types dauthentification par message. Lauthentification seffectuera par cryptage asymtrique laide de certificats en fournissant au service web une identification par nom dutilisateur et mot de passe. 5.5.3 Logging

Le logging est un suivi des vnements dune application sous forme denregistrements sur divers supports. Au fur et mesure de lvolution de la SOA, les erreurs peuvent tre de plus en plus difficiles dceler. Il faut dterminer dans quelle application et sur quelle couche sest produite lerreur. Les erreurs gnres doivent donc tre inscrites sur un support adquat et offrir des informations pertinentes aidant situer lerreur. Un outil de logging pour les composants applicatifs dans une SOA est ainsi

indispensable. Ces outils offrent des fonctionnalits simples dutilisation pour inscrire des vnements sur un support souhait. Le plus connu est probablement Log4j pour Java permettant dinscrire des vnements selon le niveau de gravit des erreurs. Ces vnements peuvent ensuite, grce des rgles et lemplacement, tre envoys sur le support le plus adquat. Les supports les plus utiliss sont le journal et la sortie sur console. Mais dans un environnement SOA, il peut tre intressant de centraliser ces informations sur une mme machine. Loutil le permet galement grce son nombreux choix de supports. Log4j est voqu dans ce travail par le fait que la plupart des outils de logging pour .NET sont des clones de ce fameux outil. Log4net, tant un de ces clones, convient parfaitement dans le cadre de ce travail. Il permet de configurer aisment avec un fichier XML lensemble du processus de logging. Linscription dvnements se fait simplement avec un appel dun singleton dans la classe souhaite et lappel de la fonction log.

Partie pratique Exemple dutilisation:


//Au dbut de la class, instanciation private static readonly ILog logger = LogManager.GetLogger(typeof(Init)); //Inscription dune information utile au dbogguage logger.Debug("Initialisation de lapplication");

42

Les diffrents niveaux de log sont les suivants : Debug : Information utile au dbogage de lapplication Info : Niveau permettant dafficher diffrentes informations relatives au droulement de lapplication. Warn : Erreur de faible gravit. Lapplication peut continuer sexcuter sans problmes Error : Erreur important. Lapplication peut continuer mais lerreur peut affecter le comportement de lapplication. Fatal : Lapplication ne peut plus continuer, lerreur tant trop critique.

Lutilisation de ces diffrents niveaux peut lgrement diffrer selon le dveloppeur ou lquipe de dveloppement. Lide la plus intressante dans une approche SOA serait denvoyer les informations un service web afin de centraliser les donnes. Une solution plus simple crivant des journaux sur un dossier partag en rseau a t privilgie. 5.5.4 ASP .NET et Web Forms

ASP.NET dsigne les technologies de programmation orientes Web offertes par Microsoft dans son framework .NET. Contrairement lancienne technologie Active Server Page (ASP), il est dsormais possible dutiliser nimporte quel langage support par le Common Language Runtime (CLR), autrement dit le cur de la machine virtuelle du framework .NET. Le CLR dans son fonctionnement peut tre compare la Java Virtual Machine (JVM) de Java. Les Web Forms est une des technologies prsentes dans ASP.NET. Ils permettent de programmer des pages web qui permettent de renvoyer aux utilisateurs une interface web dans leur navigateur. La logique des pages est implmente du ct serveur, dans un fichier appel Code-Behind avec une extension aspx.cs (cf. Figure 14).

Partie pratique

43

Figure 14 : Structure et fonctionnement dune Web Form

Cette technologie sappuie essentiellement sur un modle de programmation vnementielle. Il est ainsi possible de lier des vnements survenant du ct client ou serveur du code ct serveur de manire transparente, le programmeur nayant nullement se soucier de a manire dont se fait cette liaison. Les Web Forms simplifient aussi la conservation de ltat des formulaires et de ses composants. Une alternative trs intressant aurait t ASP.NET MVC. Ce framework utilise le paradigme de programmation modle-vue-contrleur (MVC). Les Web Forms et ASP.NET MVC sont deux approches diffrentes faisant lobjet souvent de grands dbats pour savoir lequel est la meilleure. Les Web Forms ont t retenues dans ce travail pour un souci de continuit avec dautres projets du PMS.

5.5.5

jQuery

La librairie JavaScript jQuery est utilise dans ce travail. jQuery est une librairie qui vie simplifier des tches essentielles dans linteraction du langage JavaScript avec le code HTML. Elle offre une compatibilit avec une majorit des navigateurs. Les fonctionnalits les plus intressantes sont les suivantes :

Parcours et manipulation du Document Objet Model (DOM) Gestion des vnements Animations Communication Asynchronous JavaScript and XML (AJAX)

Partie pratique La dernire fonctionnalit, lutilisation de la technologie AJAX, est la plus utile dans le cadre de ce travail. Ajax reprsente une approche utilisant les technologies web modernes communes tous les navigateurs. La combinaison de ces technologies permet de mettre jour dynamiquement une page web sans devoir procder un nouveau chargement de la page.

44

Ajax permet notamment, par le biais de lobjet XMLHttpRequest, de communiquer de manire asynchrone avec le serveur pour envoyer et recevoir des donnes et ainsi mettre jour la page web. Cette fonctionnalit permet de remplacer le contraignant rafraichissement de lensemble de la page impos par les Web Forms.

Une application web possde certains dsavantages par rapport une application classique. Le serveur ne peut par exemple pas envoyer des donnes supplmentaires une page web suite son chargement dans le navigateur du client. Cette fonctionnalit est toutefois utile si une tche sexcute du ct serveur et que lon souhaite informer le client de lavancement. En supposant quune page web affiche ltat de lavancement, le client a besoin de la rafraichir constamment pour connaitre la progression de la tche. La communication asynchrone permet de palier ce problme. Il est possible dutiliser un mcanisme de pull (cf. Figure 15). Le pull consiste la page web de demander au serveur une certaine frquence et via une communication asynchrone le nouvel tat. PMS PMS Core Services Administration Session
progression
Mises jour

Navigateur web Page web


jQuery

Figure 15 : Mchanisme de pull Lutilisation de ce mcanisme dans ce travail permet dafficher lavancement du calcul des portefeuilles des joueurs lutilisateur du systme. La progression nest videmment pas parfaitement en temps rel mais permet den donner lillusion lutilisateur.

Partie pratique 5.6


5.6.1

45

Implmentation
PMS Core

Le projet PMS Core est un projet .NET en ligne de commande se chargeant de publier des services offrant diffrentes oprations ncessaires au jeu PMS dont notamment le calcul des portefeuilles des joueurs. Ces diffrentes oprations comportent la gestion des priodes jeu, la correction des cours pour les titres ngociables ainsi que diffrentes oprations utilitaires tels que la sauvegarde et restauration de la base de donnes en cas de problme. La figure Figure 16 prsente la structure du projet.

Figure 16 : Structure du projet PMS Core PMS Core est dcompos en deux projets. Le principal contenant la logique et les services sappellent PMS Core Services. Le projet PMS Core Web soccupe uniquement de lancer le service dans le serveur IIS.

Partie pratique

46

Une brve description des fichiers du projet PMS Core Services les plus importants est donne ci-dessous : Init.cs : Se charge de linitialisation et de la publication du service PlayerContext.cs : Permet de stocker les informations relatives un joueur qui seront utilises durant le processus de calcul Log4net_config.xml : Contient la configuration du logging pour log4net CalculEngine.cs : Contient la logique pour le calcul dune priode du jeu. Fichiers WSServices : Contient les oprations des services publis. Pour linstant uniqment CalculService est publi. Fichiers PlayerPortfolioOperation : Contient une parte du processus du calcul du portfeuille pour un joueur. UpdateBuyOperation se charge ainsi de lexcution des transactions dachat de titres dun joueur. Fichiers ChangeTracker : Soccupe de stocker les changements effectuer sur la base de donnes. Ce systme permet dviter de trop nombreuses interactions avec la base de donnes, coteuses en performance. Fichiers DbBackup : Fournissent les utilitaires ncessaires la sauvegarde et restauration de la base donnes. Fichiers DTO : Classes correspondant aux objets DTO (cf. chapitre 5.5.1).

Une analyse de limplmentation des parties les plus importantes est effectue dans les sous-chapitres suivants. 5.6.1.1 Initialisation du service web

Le projet nutilisant pas le serveur Internet Information Services (IIS), lutilisation de la classe ServiceHost est ncessaire pour configurer et publier le service. Uri baseAddress = new Uri("http://localhost:5280/PMSCore"); using (ServiceHost host = new ServiceHost(typeof(CalculService), baseAddress)) { // Enable metadata publishing. ServiceMetadataBehavior smb = new ServiceMetadataBehavior();

Partie pratique smb.HttpGetEnabled = true; smb.MetadataExporter.PolicyVersion = PolicyVersion.Policy15; //host.Description.Behaviors.Add(smb); // Open the service host. Listen for messages host.Open(); logger.Info("The service is ready at " + baseAddress);

47

Console.WriteLine("The service is ready at {0}", baseAddress); Console.WriteLine("Press <Enter> to stop the service."); Console.ReadLine(); // Close the service host. host.Close(); return 0; }

Un service expose un endpoint (cf. Figure 17). Le endpoint est le point daccs au service depuis lextrieur. Il se compose : Dune adresse : ladresse de publication du service sous la forme dune URL Dun Binding : du moyen de communication (cf. chapitre 5.5.2) Dun contrat : dfinit ce que le endpoint communique. Il sagit concrtement de linterface de du service publier.

Figure 17: Composants du Endpoint

Partie pratique Ladresse est dfinie dans le constructeur de la classe ServiceHost. Uri baseAddress = new Uri("http://localhost:5280/PMSCore"); using (ServiceHost host = new ServiceHost(typeof(CalculService), baseAddress))

48

Il est noter que ladresse dfinie doit tre libre et que le systme doit autoriser le programme rserver cette adresse. Le binding ainsi que le contrat sont dfinies dans le fichier de configuration de lapplication.

<service behaviorConfiguration="PMSCalcul.CalculServiceBehavior" name="PMSCalcul.CalculService"> <endpoint binding="wsDualHttpBinding" contract="PMSCalcul.ICalculInterface" /> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>

Suite la configuration le service est publi par la mthode open(). host.Open();

Pour viter que le programme se termine, ce dernier se met en attente dune saisie dans la console. Console.ReadLine();

Si une saisie se produit, le programme peut se terminer. Il termine alors proprement la communication du service web : host.Close();

5.6.1.2

Implmentation du contrat

Le contrat du service web est implment avec une interface. Lattribut ServiceContract permet de la dfinir comme contrat et de lui spcifier un espace de noms, un mode de

Partie pratique

49

session ainsi que le contract de retour. Le contrat de retour (CallbackContrat) permet de dfinir des oprations qui peuvent tre appeles du ct client. Le binding vu prcdemment, WSDualHttpBinding, permet daccomplir cela. Lattribut OperationContrat dfinit le contrat de lopration. La proprit isOneWay permet de crer une opration asynchrone. Le client naura ainsi pas besoin dattendre de rponse du service web. Ce dernier pourra lui envoyer la rponse de manire asynchrone grce au contrat de retour car les mthodes dfinies dans ce contrat seront implmentes chez le client. namespace PMSCalcul { [ServiceContract( Name = "CalculService", Namespace = "http://www.unifr.ch/bsu", CallbackContract = typeof(ICalculCallback), SessionMode = SessionMode.Required)] interface ICalculInterface { [OperationContract(IsOneWay = true)] void nextGamePeriod(int period);

5.6.1.3

Implmentation dune opration asynchrone

Comme vu dans le chapitre 5.6.2.1, il est possible de dfinir une opration comme asynchrone. Il alors intressant de voir comment sera implment la mthode en question. public void nextGamePeriod(int period) { callback = OperationContext.Current.GetCallbackChannel<ICalculCallback >(); //begin calculation CalculEngine engine = new CalculEngine(callback); engine.nextGamePeriod(2, 2); System.Diagnostics.Debug.WriteLine("Begin computation next game period"); }

Partie pratique

50

Linterface du callback est rcupre et passe la classe se chargeant du calcul du jeu. On saperoit quil ny a pas de rponse fournie. A la suite du calcul du jeu, il sera alors possible de notifier le client de la fin des calculs (la variable ws_Callback correspondant callback fournie la classe CalculEngine) : _wsCallback.signalEnd("success");

5.6.1.4

Implmentation de la fonction davancement dune priode

Cette fonctionnalit est la plus longue et importante du projet PMSCalcul car elle soccupe de mettre jour : Les portefeuilles des joueurs selon leurs transactions effectues Le compte en banque de chaque joueur en tenant compte des intrts et des gains ou profits ralises sur les transactions. La liste de rsultat pour chaque type de classement

La premire tape consiste rcuprer les paramtres du jeu et calculer le nombre de jours entre la priode actuelle et la prochaine priode. public void nextGamePeriod(int periode, int spielId) { Console.WriteLine("Starting computation for the period {0}", periode); //------------load common settings CommonObjects.BsuSpiel spiel = BLL.BLLFacade.getSpiel(spielId); BLL.BLLFacade.setCurrentSpiel(spiel); loadCommonSettings(spiel); //------------get nb periods between last period and now int periodInterval = getDiffPeriods(2, 5);

Il faut ensuite calculer un un les portefeuilles des joueurs. Le calcul des oprations sur le portefeuille dun joueur a t ajout dans un pool de threads. Le pool de threads est une file de processus o sexcute simultanment un nombre maximum de processus. Il nest malheureusement pas possible dutiliser cette puissance dans ce travail car cela impliquerait de modifier toute la couche daccs aux donnes pour y intgrer des

Partie pratique

51

mcanismes de synchronisation. Cette implmentation a t faite de cette manire titre didactique. Chaque opration sur le portefeuille correspond une classe prenant comme arguments dans son constructeur les variables player et playerContext. List<Entities.Spieler> players = BLL.BLLFacade.getAllSpieler(spiel, "asc"); int threadCount = 0; ManualResetEvent finished = new ManualResetEvent(false); int nbPlayers = players.Count; PlayerPortfolioCalculation[] calcArray = new PlayerPortfolioCalculation[nbPlayers]; int i=0; foreach (Entities.Spieler player in players) { Interlocked.Increment(ref threadCount); ThreadPool.QueueUserWorkItem(delegate { PlayerContext playerContext = new PlayerContext(); playerContext.CommonSettings = commonSettings; playerContext.PeriodInterval = periodInterval; playerContext.Spiel = spiel; playerContext.CurrentPeriod = periode; PlayerPortfolioCalculation ppCalc = new PlayerPortfolioCalculation(player,playerContext); calcArray[i] = ppCalc; ppCalc.ThreadPoolCallback(i); i++; Thread.Sleep(100); _wsCallback.signalProgress(nbPlayers); if (Interlocked.Decrement(ref threadCount) == 0) { finished.Set(); }

//interests UpdateBankInterestOperation bkIntOp = new UpdateBankInterestOperation();

Partie pratique bkIntOp.updatePlayerPortfolio(player, playerContext);

52

5.6.2

PMS Administration

Le projet PMS Administration est un projet web ASP.NET. Il sagit de linterface utilisateur (cf. Figure 18) pour contrler le calcul du jeu. Les interactions avec PMS Core ne se font que via des services web. Lanalyse de limplmentation se limite galement aux aspects les plus importants et nouveaux dans les projets PMS.

Figure 18 : Interface utilisateur PMS Administration

5.6.2.1

Configuration et implmentation du contrat de retour pour PMS Core

Lutilisation doprations asynchrones dans PMS Core ncessite une configuration du ct client. Cette configuration met en place galement un endpoint permettant PMS Core datteindre les oprations dfinies dans le contrat de retour. <bindings> <wsDualHttpBinding> <binding name="WsDualHttpBinding" clientBaseAddress="http://localhost:5281/PMSCalculClient/"> </binding> </wsDualHttpBinding> </bindings>

Partie pratique

53

Le code ncessaire lutilisation du service PMS Core est automatiquement gnr grce lutilitaire svcutil. Loutil gnre le fichier CalculService.cs quil suffit dajouter au projet. svcutil http://localhost:5280/PMSCalcul

Linstanciation se fait galement facilement. CalculServiceClient calculService = new CalculServiceClient(new InstanceContext(new Callback(Session)));

Il est toutefois ncessaire de fournir linstance de la classe implmentant les mthodes du contrat de retour cr dans PMS Core. Il sagit dans ce projet de la classe Callback. Cette classe a pour interface CalculServiceCallback qui a t automatiquement gnre par svcutil. public class Callback : CalculServiceCallback { private HttpSessionState _Session; private static int nbCalculated = 0; public Callback(HttpSessionState Session) { _Session = Session; } public void signalEnd(string status) { _Session["status"] = status; }

Partie pratique 5.6.3 Dploiement

54

Le dploiement des applications PMS Administration et PMS Core (cf. Annexe B pour la procdure) se font sur les serveurs virtuels BSU mises disposition par le service informatique de luniversit de Fribourg (SIUF). Actuellement la BSU dispose de 3 serveurs virtuels :

Serveur base de donnes: Contient le serveur SQL Server pour le stockage des donnes du jeu PMS.

Serveur web : Contient le serveur web IIS publiant les applications PMS Administration, PMS Administration, PMS Portal ainsi que le datawarehouse.

Serveur dintgration et test : Contient les outils dintgration continue ainsi que lapplication PMS Core.

Le schma ci-dessous (cf. Figure 19) prsente le nouvel environnement BSU. Les applications PMS Core et PMS Administration sont dployes sur le serveur web.

Figure 19: Environnement BSU actuel

Partie pratique 5.7 Tests

55

Les tests de changements de priode ont t mens en utilisant des donnes des annes prcdentes. Pour sassurer que la qualit nest pas infrieure lancien programme crit en Microsoft Access, il a t dcid de comparer les rsultats du calcul en partant dun mme tat. En ce qui concerne, les fonctionnalits secondaires, celle-ci sont plus facilement vrifiable au niveau fonctionnelle. Lensemble de ces fonctionnalits sera par ailleurs teste dans une phase prcdente au jeu par lensemble de lquipe BSU.

Rsultats pratiques obtenus et valuation

56

6
6.1.1

Rsultats pratiques obtenus et valuation


Prsentation de linterface PMS Administration

Ce travail a permis de mettre en place le projet PMS Administration qui permet de grer une partie des processus du jeu dont notamment le calcul des portefeuilles. Cette application se prsente sous la forme dune interface web allge et intuitive. Il est possible de changer facilement le type de jeu grce une liste sous le menu (cf. Figure 20). La vue Priodes (cf. Figure 20) permet de passer dune priode une autre du jeu. On distingue la priode du jeu et la priode web. La priode jeu est la priode qui est actuellement calcule c'est--dire la priode dans laquelle les portefeuilles sont jour. La priode web est la priode dans laquelle les joueurs peuvent passer des transactions. Cette distinction permet deffectuer le calcul des portefeuilles indpendamment des transactions. Lopration, avancer dune priode de jeu, qui ncessite plus de temps saccomplir est accompagne dune barre de progression pour afficher lavancement de la tche.

Figure 20 : La vue Priodes La vue Correction de cours (cf. Figure 21) permet quant elle de modifier les cours qui ont t imports par le module dimportation PMS Quotes. Cette fonctionnalit permet de corriger facilement quelques petites erreurs dimportation qui auraient pu survenir.

Rsultats pratiques obtenus et valuation

57

Figure 21 : La vue Rparation de cours La vue Logs (cf. Figure 22) permet de crer un emplacement unique de visualisation des logs. Lutilisateur peut ainsi visualiser les diffrents messages provenant des modules de larchitecture SOA.

Figure 22 : La vue Logs La vue Configuration nest dans un premier temps pas utilise. Elle servira terme modifier les paramtres de configurations de certains services de PMS Core.

Rsultats pratiques obtenus et valuation 6.1.2 Prsentation de PMS Core

58

Ce travail a permis d'implmenter la plupart des cas d'utilisation dfinies dans le chapitre 5.4.1). Le cas d'utilisation UC 32 et le scnario alternatif 6b du cas d'utilisation UC 27 n'ont toutefois pas t implments pour des raisons de temps. Le projet permet toutefois d'ajouter facilement de nouveaux services et l'implmentation de ces fonctionnalits pourra se faire rapidement dans le futur. 6.1.3 Avantages et dsavantages de la nouvelle architecture

La nouvelle architecture grce au dcouplage entre la couche mtier et la couche vue permet une rutilisabilit des services ainsi quune extensibilit simplifie. Les nouvelles fonctionnalits peuvent tre facilement implmentes en intgrant la logique mtier dans PMS Core en se servant de la logique existante. Les services peuvent ensuite tre consomms o lon veut, que cela soit dans PMS Administration ou dans un programme indpendant. La nouvelle solution PMS Administration permet dsormais de grer les deux types de jeu utiliss chaque anne dans la BSU laide dune seule interface. Les autres types de jeu peuvent tre facilement configurs et implments dans la solution actuelle. Linterface web permet de se connecter depuis chez soi pour effectuer des tches sur le jeu PMS. La scurit est galement augmente car les services mtiers, grce au dcouplage, peuvent tre isols sur un autre serveur que le serveur web. La communication entre les vues et les services est par ailleurs parfaitement scurise. Lexcution asynchrone de tches permet de ne pas bloquer lensemble du systme pour une seule tche. Si lon trouve beaucoup davantages dans la nouvelle architecture, il ny a pas pour moins des dsavantages. Le temps dimplmentation est plus long du au dcouplage ncessaire et aux nombreuses technologies matriser. 6.2 Diffrences avec les attentes thoriques

Les technologies et modles en thorie donnent souvent une impression de facilit dimplmentation. Malheureusement il nest pas toujours ais de transposer cette thorie dans la pratique si lon tient compte des dlais, des obstacles techniques ou encore du nombre de technologies matriser. Ds lors il est intressant de relever les aspects

Rsultats pratiques obtenus et valuation

59

ayant pos le plus de problmes. Il est noter que les diffrences entre la pratique et la thorie qui suivent concernent ce travail et de ce fait ne sont pas retenir comme des vrits. Ces diffrences peuvent sexpliquer selon diffrents facteurs lies lenvironnement de ce travail. Les diffrents problmes rencontrs qui nont pas t parfaitement anticipes sont galement abords. Le dcouplage entre la couche mtier et la couche vue sest fait avec plus defforts que prvu. Les objets LINQ nont pas pu tre directement srialiser pour transiter sur le canal de communication des services web. Leur structure est probablement trop complexe pour tre srialise proprement. Ainsi des objets dits Data Transfer Object ont t utiliss (cf. chapitre 5.5.1). Il sagit ainsi dune diffrence par rapport aux attentes mme si les DTO sont galement conseills dans de nombreuses architectures. Il a en rsult un temps dimplmentation plus consquent car les objets doivent tre converties de DTO LINQ et rciproquement. Malgr la prsence de plus en plus forte de documentation au sein de la BSU, certaines applications manquent encore de documentation sur leur fonctionnement. La migration du systme de calcul des portefeuilles vers PMS Administration et PMS Core a ainsi ncessit dapprhender parfaitement le fonctionnement du logiciel Access dans laquelle fonctionnait lancienne application. Les rgles mtiers et les spcifications de cas dutilisation abordes dans ce travail (cf. chapitre 5.4) sont dexcellents outils pour faire face ces problmes dans le futur. Le dploiement ne sest pas fait sans difficults galement. Il a fallu tenir compte de lenvironnement actuel. Les serveurs virtuels fonctionnent avec le systme dexploitation Microsoft Windows Server 2003. Il sagit dun systme qui ne connaissait pas encore ces technologies. Le dploiement a donc ncessit beaucoup de configuration notamment au niveau scurit avec trs peu de documentation disposition. Les systmes plus rcents disposent en effet doutils permettant de configurer plus rapidement ces aspects. En ce qui concerne encore le dploiement des applications, une configuration pour chaque environnement aurait t souhaitable. Il est actuellement ncessaire dadapter ou de vrifier la configuration de lenvironnement de dveloppement sur lenvironnement de production. Lutilisation doutils dintgration continue serait une excellente solution pour rsoudre ce problme.

Conclusion

60

7
7.1

Conclusion
Conclusion finale

Une rponse aux questions amenes en introduction a t apporte tout au long de ce travail. Une dfinition et explication dune architecture du systme dinformation a t donne (cf. chapitre 2.1) en sappuyant sur de la littrature. Se poser la question de lutilit dune architecture structure et planifie (cf. chapitre 2.2) a permis daboutir une architecture particulire, larchitecture oriente services. Les apports de la SOA sur un plan thorique et pratique ont t mis en avant sur la base de lexprience et des connaissances assimiles (cf. chapitres 2.3 et 2.4). Finalement lintrt sest port sur la liaison entre le code et les donnes (cf. chapitre 3 ). On a vu que lutilisation dune couche daccs aux donnes permet dobtenir cette liaison et que des outils tel que LINQ to SQL permettent de mettre en place plus facilement cette couche. Finalement des questions relatives au projet dvelopp ont t abordes dans la partie pratique. Larchitecture du jeu PMS a t construite (cf. chapitre 5.3) sur la base de larchitecture de rfrence SOA propose dans la partie thorique. Les exigences pour le calcul du jeu PMS ont t dfinies (cf. chapitre 5.4) sous la forme de cas dutilisations et par des rgles mtiers. Lutilisation de LINQ to SQL a t privilgie dans le projet PMS Core et son intgration avec le projet a t aborde de manire concrte (cf. chapitre 5.5). Finalement les apports de la nouvelle architecture du jeu PMS par rapport lancienne ont t relevs (cf. chapitre 6.1.3). La recherche de rponses ces questions a permis de se plonger dans lunivers de la SOA. Le travail sest focalis pleinement sur le sujet de ce travail en mettant en place une architecture de type SOA dans le cadre dun projet pour lassociation BSU.

Conclusion 7.2 Conclusions personnelles

61

Ce travail a permis par le biais de lapprentissage du modle SOA ainsi que du mapping relationnel-objet dimplmenter les projets PMS Core et PMS Administration. Il a galement relev limportance de tenir compte de larchitecture actuelle pour dfinir une nouvelle architecture. Comme vu dans le chapitre prcdent, le travail est souvent plus important que celui promis thoriquement. Il faut ainsi tablir une architecture qui pourra tre atteinte de manire itrative depuis larchitecture actuelle. Des mthodes agiles, non abordes dans ce travail, sont de ce fait et mon avis indispensable lors de projets identiques avec une taille plus consquente. Une des leons que jai tire de ce travail est galement de rester raliste face aux objectifs. Les exigences de larchitecture sont parfois fixes non en fonction des besoins mais en fonction de la beaut de larchitecture. La SOA est videmment trs la mode actuellement et on est tent daccomplir parfaitement ce modle. Ladquation avec le contexte est pourtant plus importante et il suffit parfois de ne retenir que les points les plus intressants (best practices) de certains modles ou technologies. Une tendance remarque est dopposer deux dentre eux alors quil est souvent possible de les intgrer ensemble et de tirer partie de leur complmentarit.

Ressources

62

Ressources

[Ambler 2009] Ambler, Scott : Business Rules, http://www.agilemodeling.com/artifacts/businessRule.htm, dernier accs 15.12.2010. [Ballinger 2003] Ballinger, Keith : .NET Web Services: Architecture and Implementation, Addison Wesley, 2003 [Bass et al. 2003] Bass, Len; Paul, Clements; Rick Kazman: Software Architecture in Practice, Addison-Wesley, 2003 [BEA 2005] BEA : Domain Model for SOA, http://www.soablueprint.com/yahoo_site_admin/assets/docs/BEA_SOA_Domains_WP. 290214359.pdf, dernier accs : 15.12.2010. [Benett 2006] Benett, Stephen : Building Your SOA Roadmap, http://soa.syscon.com/node/183946, dernier accs: 15.12.2010. [Bieberstein et al. 2008] Bieberstein, Norbert; Laird, Robert G.; Jones, Dr. Keith; Mitra, Tilak : Executing SOA: A Practical Guide for the Service-Oriented Architect, IBM Press, 2008 [Erl 2005] Erl, Thomas : Service-Oriented Architecture: Concepts, Technology and Design, Indiana, Prenctice Hall, 2005 [Erl 2007] Erl, Thomas : SOA : Principles of Service Design, Indiana, Prenctice Hall, 2007 [Gartner 2003] Gartner: Service oriented architecture scenario, http://www.gartner.com/DisplayDocument?doc_cd=114358, dernier accs: 15.12.2010. [Grenier/Moine 2003] Grenier, Claude ; Moine, Camille : Construire le systme dinformation de lentreprise. Paris, Foucher, 2003. [Hamilton/Miles 2006] Hamilton, Kim; Miles, Russell : Learning UML 2.0, OReilly, 2006 [Hsemann 2009] Hsemann, Stefan : Systmes dinformation I. Universit de Fribourg, Suisse, 2009. [Hsemann 2009] Hsemann, Stefan : Systmes dinformation II. Universit de Fribourg, Suisse, 2009.

Ressources

63

[IBM 2007] IBM : Design an SOA solution using a reference architecture, http://www.ibm.com/developerworks/library/ar-archtemp/, dernier accs: 15.12.2010. [ipt 2010] Innovation Process Technology (ipt): SOA Referenzarchitektur und Technologien, documentation du cours SOA in a Day, Zug, Janvier 2010 [Krafzig et al. 2004] Krafzig, Dick; Banke, Karl, Slama Dirk : Entreprise SOA: Service-Oriented Architecture Best Practices, Indiana, Prenctice Hall, 2004 [Marks/Bell 2006] Marks A., Eric, Bell, Michael : Service-Oriented Architecture: A planning and Implementation Guide for Business and Technology, 2006 [Newcomer/Lomow 2004] Newcomer, Eric; Lomow, Greg : Understanding SOA with Web Services, Upper Sadle River, Pearson Education, 2004 [OASIS 2006] OASIS : Reference Model for Service Oriented Architecture 1.0, http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf, accs: 15.12.2010. [Ros 2003] Ros, Sbastien : Mapping objet-relationnel, Couche daccs aux donnes et Frameworks de persistance, http://www.dotnetguru.org/articles/Persistance/livreblanc/ormapping.htm, dernier accs : 15.12.2010 [Short 2002] Short, Scott : Building XML Web Services for the .NET Platform, Microsoft, 2002 [Shehu 2008] Shehu, Elira: Analyse dun systme informatique et extension de celui-ci par de nouvelles fonctionnalits, Travail de sminaire, 2008 [The Open Group 2009] Open Group : SOA Reference Architecture, https://www.opengroup.org/projects/ssoa-ref-arch/uploads/40/19713/soa-ra-public050609.pdf, dernier accs: 15.12.2010. [Von Halle 2006] Von Halle, Barbara: Business Rules Applied: Building Better Systems Using the Business Rules Approach, 2006 [Wikipedia 2010] Wikipedia : Software Architecture, http://en.wikipedia.org/wiki/Software_architecture#cite_note-DSA2-0, dernier accs : 15.12.2010. dernier

Annexe A

64

Annexe A
Cette annexe regroupe les rgles mtiers qui nont pas t prsentes dans le chapitre 5.4.2. Ensemble de rgles Calculer les intrts dues aux joueurs Nom Identifiant Description Calcul de lintrt du un joueur BR7 Le calcul seffectue par lutilisation dun taux dintrt annuel diffrent selon que lavoir en banque soit positif ou ngatif. Ce taux dintrt annuel est converti en taux pour une priode en jours correspondante au nombre de jours entre la priode calculer et la priode actuelle. Ce taux est ensuite multipli par le montant de lavoir en banque du joueur pour donner lintrt en faveur de la banque si le compte est ngatif ou en faveur du joueur dans le cas contraire. Exemple Si lavoir en banque du joueur est de 10'000 CHF, lintrt annuel est de 0.5% et le nombre de jours entre les deux priodes de 3, les intrts crditer sur le compte du joueur seront de 10000*(0.005/360*3) soit 41 centimes. Rgles lies /

Ensemble de rgles Mise jour des classements Nom Identifiant Description Calcul de la performance journalire BR8 La diffrence entre le patrimoine actuelle (avoir en banque + valeur du portefeuille) et celui de la dernire priode est calcule et divise par le patrimoine de la dernire priode. Exemple Si le patrimoine de la priode 2 est de 12'000 et celui de la priode 1 de 10'000, la performance journalire est de (12000-10'000)/10'000 soit 20%. Rgles lies /

Annexe A

65

Nom Identifiant Description

Calcul de la performance totale BR9 La performance totale est la performance effectue entre la premire priode et la priode actuelle. Elle est calcule de la faon suivante : Patrimoine actuelle du joueur / avoir en banque avant le jeu 1.

Exemple

Si le patrimoine actuel est de 11'000, lavoir en banque initiale de 10'000, la performance totale est de (11000/10'000)-1 soit 10%.

Rgles lies

Nom Identifiant Description

Calcul de la performance journalire moyenne BR10 La performance journalire moyenne est calcule en effectuant la moyenne de toutes les performances journalires en incluant celle de la priode actuelle

Exemple Rgles lies

/ /

Nom Identifiant Description

Calcul du risque BR11 Lcart type des performances journalires est calcul pour obtenir le risque. Il sagit donc de la calculer la variance et den calculer la racine.

Exemple

Soit une performance journalire moyenne de 10% calcule sur deux performances journalires de 9% et 11%. Le risque est de srqt([(910)^2+(11-10)^2]/2) soit 1.4.

Rgles lies

BR10, BR9

66

Nom Identifiant Description

Calcul du Sharp Ratio BR12 Le Sharp Ratio est un indicateur de rentabilit. Il permet de quantifier la rentabilit du portefeuille par rapport au risque qui a t pris. Cet indicateur se base sur un rfrentiel de comparaison tant en gnral un taux de placement sans risque. Sharp Ratio = (performance totale annuelle taux sans risque) / risque

Exemple

Si la performance annuelle totale est de 10%, le taux sans risque de 1.5% et le risque de 1.4, le Sharp Ratio est alors de 0.06.

Rgles lies

BR10, BR9

Annexe B

67

Annexe B
Cette annexe explique le processus pour la mise en place de lenvironnement de dveloppement et pour le dploiement des applications PMS Core et PMS Administration. Mise en place de lenvironnement de dveloppement sur une machine de dveloppement local Pr-requis : Serveur Microsoft IIS (Internet Information Services) Microsoft Visual Studio 2008 Plugin Visual Studio AnkhSVN Dsactivation de lUAC (User Account Control) pour autoriser les services web

Importation des projets Configurer le repository svn://diuf-svn.unifr.ch/huesemann-bsu dans VisualStudio Faire un checkout des projets PMS Core et PMS Administration ainsi que des modules CommonObjects, DAL, BLL et Entities. Sassurer que les modules sont bien configurs comme rfrences et dpendances du projet PMS Core Configuration du serveur de production Installer les certificats X.509 BSUServer et BSUClient sur le serveur Crer un pool dans IIS utilisant le compte Administrateur Utiliser ce pool pour les projets PMS Core et Administration

Dploiement des projets Utiliser la fonction Publier le projet pour dployer les projets sur le serveur via un dossier mont en rseau Configurer dans les fichiers Web.config les paramtres qui diffrent pour lenvironnement de production.