Université de Fribourg, Suisse Département d'informatique
Bachelor en informatique
M
ISE EN PLACE D’
UNE ARCHITECTURE DE TYPE SOA POUR UN PROJET INFORMATIQUETravail de bachelor
Büschi Mathias Chemin des écoliers 8
1163 Etoy
Dr. Stefan Hüsemann
Janvier 2011
A
BSTRACTLa recherche de solutions visant à faciliter l’intégration entre de nombreuses
applications hétérogènes est de nos jours nécessaires dans un monde où la complexité des systèmes d’informations ne cesse de croître. L’architecture orientée services (SOA) est l’un des modèles intéressants permettant de faire face à cette problématique.
Ce travail vise dans une première partie à mettre en exergue les concepts qui entourent la SOA en y apportant une description suffisante afin d’aborder par la suite les aspects architecturaux de la SOA. Le mapping relationnel-objet, permettant de relier le modèle relationnel d’une base de données à un modèle objet, sera abordé sous un angle
théorique et pratique en vue de son intégration dans la SOA. s
Enfin les connaissances assimilées dans la première partie seront utilisées pour élaborer une architecture SOA dans le cadre de l’association Börsenspiel der Schweizer
Universitäten (BSU). L’implémentation d’une partie de l’architecture sera effectuée. Il s‘agira de la partie de calcul des portefeuilles des joueurs pour le jeu Portfolio
Management Simulation (PMS). Une des volontés de ce travail sera d’amener au système d’informations (SI) de la BSU une capacité à s’aligner plus facilement avec les processus de l’association.
M
OTS-
CLÉSBSU, PMS, association, bourse, architecture, SOA, système, information, portefeuille, UML, .NET, persistance, mapping, relationnel-objet
Table des matières
Table des matières
1 INTRODUCTION ... 6
1.1.1 Problématique ... 6
1.1.2 Objectifs ... 6
1.1.3 Démarche utilisée ... 8
2 ARCHITECTURE DE SI ... 9
2.1 Définition et analyse d’une architecture du système d’information (SI) ... 9
2.2 Aperçu de l’architecture de type SOA ... 10
2.3 Définition d’un modèle de référence SOA et conception d’une architecture de référence SOA ... 13
2.4 Utilité d’une architecture structurée et planifiée ... 14
3 PRÉSENTATION DU MAPPING RELATIONNEL-OBJET ... 15
3.1 Définition ... 15
3.2 Rôle dans l’architecture de type SOA ... 15
3.3 Outils de mapping relationnel-objet existants ... 16
4 STRUCTURE GÉNÉRALE DE L’ARCHITECTURE DE RÉFÉRENCE DE LA BSU ... 18
4.1 Aspects à prendre en compte ... 18
4.2 Vue des différentes couches ... 18
4.3 Roadmap vers l’architecture de référence SOA ... 19
5 PARTIE PRATIQUE ... 24
5.1 Présentation du jeu PMS et de son environnement ... 24
5.2 Analyse actuelle de la structure ... 26
5.3 Modifications de la structure envisagées ... 26
5.3.1 Architecture cible ... 26
Table des matières
5.3.2 Conséquences et avantages de la nouvelle architecture ... 27
5.3.3 Services métiers ... 29
5.4 Définitions de cas d’utilisations et règles métiers pour le module PMS Core ... 30
5.4.1 Cas d’utilisations ... 30
5.4.2 Règles métiers ... 33
5.5 Choix des composants tiers pour un développement 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 Implémentation ... 45
5.6.1 PMS Core ... 45
5.6.2 PMS Administration ... 52
5.6.3 Déploiement ... 54
5.7 Tests ... 55
6 RÉSULTATS PRATIQUES OBTENUS ET ÉVALUATION ... 56
6.1.1 Présentation de l’interface PMS Administration ... 56
6.1.2 Présentation de PMS Core ... 58
6.1.3 Avantages et désavantages de la nouvelle architecture ... 58
6.2 Différences avec les attentes théoriques ... 58
7 CONCLUSION ... 60
7.1 Conclusion finale ... 60
7.2 Conclusions personnelles ... 61
Table des matières
8 RESSOURCES ... 62 ANNEXE A ... 64 ANNEXE B ... 67
Table des illustrations
Table des illustrations
FIGURE 1:BÉNÉFICES D’UNE SOA[MARKS/BELL 2006, P.134] ... 11
FIGURE 2:ARCHITECTURE DE RÉFÉRENCE SOA[OASIS2006] ... 13
FIGURE 3:APPLICATION N-TIER –COUCHE D’ACCÈS AUX DONNÉES [ROS 2003] ... 16
FIGURE 4:ARCHITECTURE DE RÉFÉRENCE DE L’ENTREPRISE IPT[IPT 2010] ... 18
FIGURE 5:LES 6 DOMAINES DÉFINIS PAR BEA[BEA2005] ... 20
FIGURE 6:ARCHITECTURE DE RÉFÉRENCE ÉTABLIE POUR PMSTOP ... 25
FIGURE 7:NOUVELLE ARCHITECTURE POUR LE JEU PMS ... 27
FIGURE 8:TYPES DE SERVICES DANS LA NOUVELLE ARCHITECTURE ... 29
FIGURE 9:CAS D’UTILISATION POUR LE MODULE PMSCORE ... 30
FIGURE 10:INTÉGRATION DES TECHNOLOGIES DANS L‘ARCHITECTURE ... 37
FIGURE 11:LES DIFFÉRENTES IMPLÉMENTATIONS DE LINQ ... 38
FIGURE 12:RÔLE DE LINQ TO SQL DANS LA NOUVELLE ARCHITECTURE ... 39
FIGURE 13:EXEMPLE DE L’APPEL DE L’OPÉRATION NEXTPERIOD SUR LE SERVICE PMSCORE ... 40
FIGURE 14:STRUCTURE ET FONCTIONNEMENT D’UNE WEB FORM ... 43
FIGURE 15:MÉCHANISME DE PULL ... 44
FIGURE 16:STRUCTURE DU PROJET PMSCORE ... 45
FIGURE 17:COMPOSANTS DU ENDPOINT ... 47
FIGURE 18:INTERFACE UTILISATEUR PMSADMINISTRATION ... 52
FIGURE 19:ENVIRONNEMENT BSU ACTUEL ... 54
FIGURE 20:LA VUE PÉRIODES ... 56
FIGURE 21:LA VUE RÉPARATION DE COURS ... 57
FIGURE 22:LA VUE LOGS ... 57
Abréviations
Abréviations
BSU Börsenspiel der Schweizer Universitäten
PMS Portfolio Management Simulation
SOA Service Oriented Architecture
MVC Model- View - Controller
SOAP Simple Object Access Protocol
XML Extensible Markup Language
HTTP Hypertext Transfer Protocol
WSDL Web Services Description Language
DAO Data Access Object
POO Programmation orienté objets
CRUD Create-read-update-delete
AJAX Asynchronous JavaScript and XML
TCP Transmission Control Protocol
JVM Java Virtual Machine
BLL Business Logic Layer
DAL Data Access Layer
IT Information Technology
UML Unified Modeling Language
DOM Document Object Model
URL Uniform Resource Locator
BR Business Rule
SQL Structured Query Language
WCF Windows Communication Framework
LINQ Language Integrated Query
Introduction 6
1 Introduction
1.1.1 Problématique
Le présent travail va trouver une utilité dans le cadre du jeu Portfolio Management Simulation (PMS) de l’association Börsenspiel der Schweizer Universitäten (BSU). Il s’agit d’une simulation boursière destinée aux étudiants des hautes écoles suisses.
L’organisation de ce jeu repose sur du travail de marketing, de finances et d’informatique. L’association BSU et formée d’une équipe d’étudiants d’environ 8 personnes qui fournissent leurs compétences dans les domaines cités précédemment.
Les interactions entre ces domaines sont nombreuses. L’équipe de gestion par exemple définit les nouveautés du jeu que l’équipe d’informatique doit implémenter. L’équipe de marketing demande des statistiques et des changements pour rendre le site plus populaire.
L’ensemble de l’infrastructure informatique de la BSU est ainsi très sollicité. Outre la maintenance, il faut également garantir la pérennité du jeu chaque année en offrant de nouvelles fonctionnalités, en améliorant le support aux joueurs et en offrant une qualité grandissante de jeu. Pour ce faire, l’amélioration du système informatique régissant le jeu et l’administration qui y est liée est un besoin non négligeable.
Cette amélioration passe par la mise en place d’une nouvelle architecture. L’accès aux données doit par ailleurs être l’un des points-clés de l’architecture. L’architecture Service Oriented Architecture (SOA) ainsi que le mapping relationnel-objet font parler d’eux depuis quelques années. Ce travail souhaite vérifier la possibilité d’une intégration de ces principes dans le système informatique de la BSU en vue de définir une nouvelle architecture.
1.1.2 Objectifs
Le présent travail s’articule autour d’une partie théorique et d’une partie pratique. Il aura pour objectif d’amener des réponses aux questions scientifiques suivantes d’après ces parties :
Partie théorique
- Qu’entend-ton par une architecture du système d’information (SI) ? - Quelle est l’utilité d’une architecture structurée et planifiée ?
Introduction 7 - Quels sont les apports de la SOA ?
- Comment relier le code et les données dans une application ? Partie pratique
- Quelles sont les exigences pour le calcul du jeu PMS ? - Quelle est l’architecture du système PMS ?
- Comment intégrer le mapping relationnel-objet avec la technologie .NET dans le cadre d’un projet ?
- Qu’est-ce que la nouvelle architecture apporte de plus par rapport à l’ancienne ? Ce travail veut également proposer une nouvelle architecture au jeu PMS. La recherche et la mise en place de cette nouvelle architecture permettra de répondre aux questions précédentes. Une partie de l’implémentation de cette architecture sera également réalisée dans le cadre de ce travail en développant le module PMS Core. Ce module sert à calculer et à mettre à jour les portefeuilles des joueurs à l’issue de chaque journée de jeu.
Le développement et l’établissement de l’architecture de référence s’axera autour d’une architecture de type SOA. Cette architecture s’oriente en général vers les grandes entreprises en raison de son coût et de sa complexité. Mais ce travail veut également démontrer qu’en adoptant certains principes de bases de ce type d’architecture, il peut en résulter un système stable et évolutif.
L’implémentation du module et de la nouvelle architecture s’appuiera sur les technologies .NET déjà utilisés dans le jeu ainsi que sur de nouvelles technologies qui seront expliquées plus loin dans ce travail.
La première partie de ce travail définit la notion d’architecture de système d’information. Le type SOA sera particulièrement analysé et mènera à la définition et à l’étude de la mise en place d’une architecture de référence SOA. Reprenant ces points, l’utilité d’une architecture structurée et planifiée sera démontrée. La deuxième partie présente le mapping relationnel-objet, son utilité dans la nouvelle architecture ainsi que la technologie qui sera choisie parmi les nombreuses à disposition. La troisième partie sera dédiée à la modélisation de l’architecture cible de la BSU et enfin la dernière partie entrera au cœur de l’implémentation de PMS Core.
Introduction 8 1.1.3 Démarche utilisée
La lecture et l’étude de textes pertinents liés à ces thèmes fourniront une base de connaissances sur laquelle s’appuyer. Pour répondre aux questions formulées dans le chapitre précédent, une démarche empirique sera adoptée mais appuyée par des méthodes déductives. L’idée est de partir de connaissances générales pour développer des connaissances plus spécifiques en s’aidant d’expérimentations.
Architecture de SI 9
2 Architecture de SI
Ce chapitre va au travers de la littérature et une réflexion personnelle essayer de répondre aux questions suivantes :
- Qu’entend-ton par une architecture du système d’information (SI) ? - Quelle est l’utilité d’une architecture structurée et planifiée ? - Quelles sont les apports de l’architecture orientée services (SOA) ? - Comment relier le code et les données dans une application ?
La recherche d’une réponse à ces questions va permettre de poser une base théorique indispensable pour la compréhension et l’élaboration de la future architecture du jeu Portfolio Management Simulation (PMS).
2.1 Définition et analyse d’une architecture du système d’information (SI)
Pour aboutir à une définition d’une architecture SI, il faut au préalable définir le terme d’architecture ainsi que la notion de système d’information.
Une architecture de manière générale peut être définie de la manière suivante :
L’architecture est l’ensemble de décisions significatives à propos de l’organisation d’un système informatique. [Bass al. 2003]
La définition d’un système d’information est la suivante :
Un système d’information est un ensemble organisé de ressources (matériel, logiciel, données et procédures) qui permet de regrouper, classifier, de traiter et de diffuser de l’information sur un phénomène donné. [Wikipedia 2010]
Une architecture de système d’information doit donc définir des afin d’implémenter et de comprendre un système qui pour tâche de gérer l’information de la manière la plus flexible possible.
Les motivations pouvant mener à adopter une telle architecture sont les suivantes : - Simplification des processus métiers grâce à une découverte et une élimination
de la redondance dans les processus métiers.
- Augmentation des capacités d’intégration de l’entreprise grâce à une meilleure consolidation et transmission des données. L’architecture pousse à adopter des standards pour le partage des données.
Architecture de SI 10 - Migration plus rapide grâce à une structure simplifiée avec absence de
redondance.
Dans le cas de la BSU, le système d’information doit remplir plusieurs fonctions : - Collecter des informations
o Exemples : cours des titres, paiements des joueurs, transactions effectuées par les joueurs,...)
- Mémoriser les informations et également mémoriser les informations passées o Exemples : stockage dans la base de données des transactions des
joueurs, stockage dans la base de données des cours historiques - Traiter les informations
o Exemples : calcul des portefeuilles des joueurs, mise à jour dans la base de données, générer des listes de résultats
- Transmettre les informations
o Exemples : mise à disposition des résultats aux joueurs, informations aux gestionnaires du jeu de l’état des paiements
Le système d’information de la BSU remplit donc déjà bon nombre des fonctions que l’on retrouve dans la majorité des systèmes d’informations.
L’architecture du système d’information de la BSU n’est pas encore clairement établie.
Il en résulte ainsi des difficultés d’évolution, des problèmes de qualité dans les différentes fonctions ainsi qu’une complexité évitable malgré un jeu que l’on peut qualifier de fonctionnel.
Le prochain point vise à découvrir un type d’architecture de système d’information qui peut permettre de résoudre ces points négatifs du système actuel.
2.2 Aperçu de l’architecture de type SOA
Le terme SOA signifie architecture orienté services. La définition suivante peut être donnée :
SOA est une architecture métier conceptuel où les fonctionnalités métiers, ou la logique de l’application, est mise à disposition aux utilisateurs SOA ou aux utilisateurs, en tant que services réutilisables et partagés dans un environnement informatique. Les services dans une SOA sont les modules d’une fonctionnalité de l’application avec des interfaces exposées et qui sont invoquées par messages. [Marks/Bell 2006]
Architecture de SI 11 Ce type d’architecture suit des principes de modélisation modernes. Quelqu’un de ces principes sont les suivants :
- L’architecture doit reposer sur le concept d’offre et de demande de services.
- Les composants doivent pouvoir communiquer entre eux de manière asynchrone et doivent être couplés faiblement.
- L’architecture doit être découpée en plusieurs couches
o Note : L’architecture n-couches la plus connue est probablement la modèle-vue-contrôleur (MVC) où l’on trouve les couches présentation, métier et données.
Ces principes doivent permettre de rendre le système flexible pour s’adapter à la stratégie de la société. Cette flexibilité découle du fait que les services sont réutilisables grâce à une interface standardisé, une facilité d’intégration accrue pour une complexité plus faible.
Outre sa flexibilité, les bénéfices de la SOA peuvent être nombreux comme le montre la Figure 1. L’agilité métier permet à la SOA de s’adapter rapidement à son environnement métier en maintenant des services s’alignant aux demandes clientes. Une réduction des coûts est atteinte par une meilleure réutilisation des services existants ainsi qu’une meilleure maintenance grâce à une consolidation des applications par des services réutilisables. Cette réduction des coûts en conjonction avec une satisfaction du client amène l’entreprise à accroitre ses revenues. Les fusions et acquisitions (M&A – Mergers and Acquisitions) se passent plus facilement grâce à une intégration facilitée par la SOA.
Figure 1 : Bénéfices d’une SOA [Marks/Bell 2006, p.134]
Agilité métier
Réduction des coûts
Accroissement revenues
Flexibilité IT
M&A plus rapide
Satisfaction du client
Plus rapidement vers le marché
Réutilisation des services Plus de
productivité
Architecture de SI 12 L’application composée résultant de l’assemblage de ces services est mise à disposition des utilisateurs.
Dans une architecture SOA, les services se doivent de disposer d’une interface standard pour accéder aux fonctionnalités logicielles qu’elles proposent. L’utilisation de services web est donc fréquente. Un service web possède les caractéristiques suivantes :
- Couplage faible grâce à une communication par message - L’interface du service est standard et auto-descriptive
Ces propriétés font que les services web peuvent interagir entre eux et fournissent une description de leurs fonctionnalités et la façon d’y accéder.
Les services web les plus utilisées sont de type Simple Object Access Protocol (SOAP) over HTTP. La spécification SOAP définit :
- Les règles de traitement du message SOAP - Les fonctionnalités et modules SOAP
- Les règles qui définissent une liaison à un sous-protocole utilisé pour échanger les messages SOAP entre les nœuds SOAP
- La structure du message SOAP
Le standard Extensible Markup Language (XML) est utilisé pour définir ces propriétés de SOAP.
Plusieurs méthodes de transport existent mais la plus utilisée est évidemment le protocole HTTP (ou HTTPS).
La solution SOAP sera la technologie retenue dans ce travail toutefois d’autres alternatives intéressantes existent tels que le très 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 confère au service son côté auto- descriptif.
L’association de ces standards a donné lieu aux services web WS-*, appelés aussi services de deuxième génération. On les définit selon le type d’architecture SOA. La supervision des standards SOAP et WSDL est la charge du W3C. L’organisation WS-I publie entre autre des profils afin d’assurer et d’améliorer l’interopérabilité entre les développements de services web.
Architecture de SI 13 Le standard Universal Description Discovery and Integration (UDDI), annuaire de services basés sur XML a également une place importante dans la SOA. Publié par OASIS, il permet la découverte des services web. Les informations données permettent de connaître l’adresse à utiliser pour atteindre le service, les fonctionnalités offertes, les responsables du service et d’autres informations utiles. Windows serveur inclus par défaut un serveur UDDI mais ils existent des alternatives commerciales et open source notamment Apache JUDDI, BEA Aqualogic Service Registry, Novell UDDI Server,…
2.3 Définition d’un modèle de référence SOA et conception d’une architecture de référence SOA
Le modèle de référence SOA a été spécifié par l’OASIS dans sa publication Reference Model for Service Oriented Architecture 1.0 [OASIS 2006]. Cette organisation pense que la grande attention portée aux SOA a mené à trop de définitions divergentes. Le but est donc de fournir un modèle générique de modélisation d’une SOA. Ce modèle de référence est donc une abstraction de toutes les SOA visant à donner des définitions communes à toutes les SOA. Ce modèle de référence fait abstraction des technologies et des implémentations.
Figure 2: Architecture de référence SOA [OASIS 2006]
L‘architecture de référence SOA (cf. Figure 2) est une spécification fonctionnelle avec laquelle on peut implémenter une SOA. L’architecture de référence va donc se baser sur les définitions du modèle de référence SOA. L’architecture de référence peut également
Architecture de SI 14 être définie comme l’architecture cible idéale à atteindre. Elle permettra ainsi de définir une roadmap partant de l’architecture actuelle à la future architecture. L’OpenGroup fournit un blueprint pour la conception et l’évaluation de SOA dans sa publication SOA Reference Architecture [The Open Group 2009].
L’élaboration d’une architecture de référence SOA doit idéalement se faire en suivant les standards proposés auparavant. Le modèle de référence proposé par l’OpenGroup peut s’adapter à n’importe quel type de société. Il est ainsi possible par raison de coûts de supprimer une couche.
2.4 Utilité d’une architecture structurée et planifiée
De nos jours, la stratégie d’une 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 réduction des coûts, et bien d’autres facteurs amenant l’entreprise à revoir sa stratégie. Le système d’information doit réagir face à ces changements en s’adaptant à la stratégie. Les coûts et le temps nécessaires à cette adaptation sont des facteurs cruciaux pour l’entreprise. Dès lors la présence d’une architecture structurée et planifiée dans le système d’information de l’entreprise est importante pour mener à bien ces adaptations.
Une architecture structurée et planifiée peut amener les avantages suivants : - Système flexible s’adaptant à l’environnement métier
- Gestion du système d’information plus efficace grâce à une structure permettant une meilleure allocation des ressources humaines et matérielles.
- Augmentation de la consistance des informations grâce à une représentation standardisée de l’information
- Intégration et partage de l’information facilitée
Présentation du mapping relationnel-objet 15
3 Présentation du mapping relationnel-objet
Par une recherche théorique, ce chapitre se veut de répondre aux questions suivantes : - Qu’apporte le mapping relationnel-objet ?
3.1 Définition
Le mapping relationnel-objet est une technique permettant de transformer d’un modèle à l’autre les modèles objets et relationnels. Pour cela une correspondance est établi entre le modèle relationnel et le modèle objet, d’où le terme de mapping.
Les bases de données ne peuvent comporter que des types scalaires bien définis et des chaînes de caractères. Un type scalaire est un type de variable scalaire, une variable scalaire étant une variable qui ne peut contenir qu’une valeur atomique. Les types les plus connues sont par exemple String, Char, Integer, Float ou encore Double. Cette structure n’est malheureusement pas idéale lorsqu’il 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 données.
Ces transformations peuvent être en parties automatisées grâce au mapping relationnel- objet, le programmeur se restreignant à configurer les correspondances. Ainsi le programmeur peut lire, modifier et créer des objets sans se soucier de la base de données. Il va également de soi que le code nécessaire à la gestion des données se réduit drastiquement et la complexité avec.
3.2 Rôle dans l’architecture de type SOA
Dans une architecture n-couche, par exemple de type SOA, une couche importante est celle de l’accès aux données (cf. Figure 3). Cette couche doit offrir la possibilité de manipuler d’une manière flexible les enregistrements de la base de données. Cette couche comportera en général une classe, classe dite Data Access Object (DAO), correspondante à chaque table de la base de données. Des méthodes sont présentes créer, lire, modifier et supprimer un enregistrement. On parle d’interface CRUD (Create, Read, Update, Delete).
Présentation du mapping relationnel-objet 16
Figure 3 : Application n-tier – Couche d’accès aux données [Ros 2003]
Le mapping relationnel-objet n’est pas directement lié aux SOA. Cette couche d’accès aux données peut très 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 rôle apportant des gains de temps et de coûts. Par ailleurs, ils existent des outils de persistance offrant la mapping relationnel-objet. Ils ont l’avantage de proposer également un fort découplage avec la base de données en plus des nombreuses fonctionnalités offertes tels que la mise en cache, la gestion de la concurrence, etc. Ce découplage 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 fonctionnalités communes mais aussi des fonctionnalités propres à chacun de ces outils. Les fonctionnalités suivantes sont en général demandées par une majorité de programmeurs :
- Utilisation de l’héritage et du polymorphisme : Il faut profiter de la POO pour donner une structure aux entités (ex : hiérarchie)
- Gérer les transactions, agrégations et groupement : Présentes dans SQL, elles se doivent de l’être également dans le mapping relationnel-objet.
- Gérer les différents types de relation : Une relation 1-n sera ainsi représentée dans une classe DAO par un tableau.
Ces fonctionnalités apparaissent comme indispensables pour que le mapping relationnel-objet n’apporte pas plus de désavantages qu’avantages. De nombreuses
Présentation du mapping relationnel-objet 17 autres fonctionnalités sont en général fournies. Les critères d’adoption d’un outil dépendront du besoin de l’architecture.
Pour le cas de la SOA, il est ainsi important de considérer d’autres fonctionnalités : - Les objets doivent pouvoir être convertis sous forme de « message ». La
sérialisation le permet en transformant l’objet sous forme de chaine de caractère dans un format standard.
- Les objets doivent pouvoir être stockés sous différents formats donc différents 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 d’offrir rapidement un accès aux données aux applications. ADO.NET Entity Framework a toutefois l’avantage de ne pas être dépendant du schéma relationnel en programmant son propre modèle conceptuel. Il est possible en quelque sorte de définir plus librement le mapping qu’avec la technologie LINQ to SQL.
NHibernate est un produit open source sous licence LGPL (Lesser GNU Public Licence). Il offre pratiquement autant de fonctionnalités que ADO.NET Entity Framework et constitue un bon choix pour les programmeurs ayant déjà connaissance de sa version en Java, Hibernate.
DataObjects.NET et ObjectMapper.NET sont des solutions commerciales qui mettent en avant une performance accrue ainsi qu’une approche plus programmatique que leurs concurrents gratuits pour une gestion du mapping relationnel-objet plus avancée.
Structure générale de l’architecture de référence de la BSU 18
4 Structure générale de l’architecture de référence de la BSU
4.1 Aspects à prendre en compte
La définition d’une architecture de référence (cf. chapitre 2.3) pour la BSU devra prendre en compte les ressources et du temps à disposition pour mettre en place la nouvelle architecture. L’association disposant de moyens faibles et de temps limité, il est primordial d’adopter une architecture qui pourra être maintenue à long terme. La SOA devra apporter :
- Flexibilité et rapidité quant à l’évolution du jeu PMS
- Administration de la BSU facilitée. Intégration de nouveau modules d’administration et modifications des actuelles dans les meilleurs délais.
Ces objectifs devront être remplis en choisissant une architecture de référence respectant au mieux le modèle de référence SOA (cf. chapitre 2.3).
4.2 Vue des différentes couches
De nombreuses architectures de références existent déjà. L’architecture qui a été choisie dans le cadre de ce travail (cf. Figure 4) a été élaborée par l’entreprise IPT [ipt 2010] et proposé par Mr. Stefan Hüsemann.
Figure 4 : Architecture de référence de l’entreprise IPT [ipt 2010]
Structure générale de l’architecture de référence de la BSU 19 La couche donnée est composée de base de données relationnelle et de datawarehouses qui contiennent les données nécessaires aux exigences métiers de l’entreprise.
La couche d’accès aux données permet d’accéder à ces données et à leur offrir un moyen d’accès standard et unique. Cet accès peut soit être réutilisable grâce à l’utilisation de services de données ou soit être privé si le besoin en est.
La logique métier est contenue dans la couche logique métier. Il s’agit d’une couche importante permettant de séparer la logique des données et de la couche présentation.
Les composants de cette couche sont les suivants :
- Services métiers : Ils fournissent des éléments logiques réutilisables
- Logique métier privée : Il s’agit d’implémentation de logique spécifique à une application
- Business Rule Engine : Ce composant permet de modifier de la logique métier.
Il exécute des règles métiers externalisée du code.
Dans la couche intégration, le composant ESB (Entreprise Service Bus) est un intergiciel permettant l’intégration d’applications hétérogènes.
Pour offrir des processus réels à la couche présentation, il faut assembler certains services et les intégrer. La couche d’intégration s’en charge avec un composant appelé moteur d’orchestration. Ce composant utilise en général le langage BPEL (Business Process Execution Language) défini comme standard et utilisant un langage dérivé du XML.
Finalement la couche présentation offre une interface aux utilisateurs sous la forme d’une application web ou d’un portail via un serveur web.
La couche client définit les applications utilisées pour accéder à la couche de présentation telle qu’un navigateur web. Le client peut aussi utiliser une application client riche. Il s’agit d’applications traditionnelles qui se connecteront en général directement aux services métiers
4.3 Roadmap vers l’architecture de référence SOA
La roadmap SOA est un plan unique du système d’information de l’entreprise qui est défini itérativement et incrémentalement au fur et à mesure de l’avancement.
La maturité de la roadmap doit évoluer conjointement avec la maturité de la SOA. Par ailleurs elle doit également tenir compte de l’environnement global en distinguant les 6
Structure générale de l’architecture de référence de la BSU 20 domaines liés entre eux (cf. Figure 5 : Les 6 domaines définis par BEA [BEA 2005]).
La roadmap définit une ligne du temps transparent et flexible pour accomplir les objectifs de la SOA. Des tests de qualités sont également effectués à chaque étape.
Figure 5 : Les 6 domaines définis par BEA [BEA 2005]
Construction de la roadmap selon les étapes définies dans le livre blanc de BEA Systems[BEA 2005] :
1. Planification de la SOA
La SOA est organisée et définie. Les limites et l’environnement sont établis. La SOA est également justifiée et sa capacité à remplir les besoins actuelles et futurs de l’entreprise est démontrée.
2. Evaluation de la maturité de la SOA
Identification des fonctionnalités offertes par la SOA. Analyse de l’état actuel de la SOA par l’équipe actuel.
3. Vision future de la SOA
Définition en équipe de l’état futur désiré de la SOA.
4. Définition de la roadmap SOA
En se basant sur les 3 phases précédentes, une analyse des objectifs de la SOA est accomplie et des timelines sont définies pour y parvenir. Les objectifs à court terme sont détaillées et les objectifs à plus long terme sont décrits plus
Structure générale de l’architecture de référence de la BSU 21 sommairement afin qu’ils puissent encore s’adapter à l’expérience qui sera acquise par la suite.
Ces phases peuvent être appliquées à la BSU de la manière suivante : Découverte
Le kick-off de la BSU permet chaque année de réunir les parties prenantes de
l’informatique et de la gestion. Il permet de comprendre la vision informatique, l’état actuel et les besoins. Ce rendez-vous annuel permet d’augmenter progressivement le degré de maturité de l’architecture du système d’information. Cette phase de la SOA peut donc être mise en place facilement. Il s’agira ainsi de :
- Définir les compétences de la SOA
- Identifier les limites et la l’alignement avec de nouvelles idées IT.
- Montrer l’alignement avec d’actuelles et futures idées de gestion - Démontrer l’utilité de la SOA
Analyse de l’état actuel
A ce stade, les moyens et services de la BSU pouvant servir à la SOA doivent être identifiés. Il peut s’agir de projets existant pouvant servir de base à la SOA.
Un exemple sommaire de l’état actuel de la BSU en départageant les domaines pourrait être le suivant :
Découverte Analyse état actuel
Définition état
futur Roadmap
Structure générale de l’architecture de référence de la BSU 22 Stratégie et processus métier
Stratégies :
- Objectif d’atteinte d’un nombre de joueurs minimum pour la session de jeu - Offre de nouvelles fonctionnalités pour maintenir l’attractivité du jeu Processus métiers :
Définition du nouveau jeu
Publicité : mailing, affiches, agents Configuration du jeu
Gestion des paiements des joueurs
Etablissement des gagnants et récompense Sondage
Architecture
La BSU utilise pour certains de ces projets une architecture MVC. Le standard XML est déjà utilisé dans plusieurs projets.
Coûts
Les coûts inhérents au système d’information actuel de la BSU est quasi nul.
Toutefois grâce au sponsoring la BSU possède des moyens qui normalement seraient sujets à des coûts 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 d’une nouvelle session de jeu, calcul des portefeuilles, clôture du jeu
Projets et applications
Applications existantes : calcul de jeu, PMS Quotes, PMS Configuration Projets prévus : PMS Payments, PMS Core, PMS Administration
Structure générale de l’architecture de référence de la BSU 23 Organisation et gouvernance
Organisation et hiérarchie actuelle de la BSU :
Définition de l’état futur
Mise en place des modules PMS Core et PMS Administration pour la prochaine session de jeu. Intégration des modules PMS Importation et Configuration à la SOA à moyen terme. Justification par le fait que toutes ces applications sont des applications
composées à partir de services communs. Ces applications correspondent également aux processus métiers de la BSU. Définition des services partagées : récupération des infos d’un joueur, récupération du classement d’un joueur, modification d’un portefeuille, …
Définition de la roadmap SOA
Objectifs court-terme : Définition d’une architecture SOA Implémentation PMS Core et PMS Administration
Objectifs moyen-terme : Intégration des modules PMS Importation et PMS Configuration
Vorstand
IT Gestion
Partie pratique 24
5 Partie pratique
Les réponses aux questions de la partie pratiques seront amenées dans ce chapitre. Elles se fonderont sur les apports théoriques des chapitres précédents ainsi que par l’expérimentation découlant de l’implémentation de la nouvelle architecture.
Les questions sont les suivantes :
- Quelles sont les exigences pour le calcul du jeu PMS ? - Quelle est l’architecture du système PMS ?
- Comment intégrer le mapping relationnel-objet avec la technologie .NET dans le cadre d’un projet ?
- Qu’est-ce que la nouvelle architecture apporte de plus par rapport à l’ancienne ? 5.1 Présentation du jeu PMS et de son environnement
L’association BSU a organisé depuis sa création en 1991 plusieurs jeux boursiers pour les étudiants des universités et hautes écoles suisses. Actuellement l’association ne propose plus que le jeu PMS (Portfolio Management Simulation). Ce jeu permet aux participants de gérer sur une période définie un portefeuille virtuel. Les titres négociables sont choisis d’avance et sont de nature diversifiée : actions, obligations, options, devises,.. Pour participer les membres BSU paient une cotisation annuelle.
Pour gérer tous ces aspects du jeu de manière efficace, il est important pour les membres du comité de la BSU d’utiliser un système d’information adéquat.
Une restructuration du système avait été prévue dans le cadre du projet PMS Top.
L’idée était de décomposer chaque partie du jeu en sous-projet et ensuite d’interconnecter le tout.
Sous-projets de PMS Top :
PMS Requirements and Test : Définition des exigences, Modélisation du système PMS, documentation
PMS Administration : Gestion du jeu PMS. Ce module rassemble PMS Configuration et PMS Core
PMS Configuration : Gestion des paramètres du jeu, des membres et des différentes 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 données
PMS Environment : Mise en place d’un environnement de développement, test et production
PMS Web : Site Internet faisant office d’interface de gestion des portefeuilles pour les membres BSU.
Actuellement certains projets ont été menés à bien, d’autres sont en cours de développement et d’autres en suspens. Le projet PMS a donné plus de transparence au système d’information, de nouvelles fonctionnalités et une meilleure qualité de jeu.
Une architecture de référence a également été définie dans le cadre du projet PMS Top (cf. Figure 6.
Figure 6 : Architecture de référence établie pour PMS Top
Cette architecture de référence représente bien l’état actuel ce qui signifie que le projet PMS Top a bien atteint son objectif au niveau architectural.
Partie pratique 26 5.2 Analyse actuelle de la structure
Le projet PMS Top a notamment été lancé pour faire face à différents problèmes techniques :
- Difficulté de configuration de jeu - Lenteur de calcul des portefeuilles - Problèmes d’importation
- Vieilles technologies présentes
- Pas de gestion commune des multiples instances du jeu - Pas d’environnement de développement et de test - Gestion des connexions des membres sur le site désuète - Manque d’innovation
Si de nombreux problèmes sont résolus, d’autres sont encore présents tels que la lenteur du calcul des portefeuilles, la présence de veilles technologies et le manque d’innovation. Il est donc intéressant de se pencher sur les causes qui ont rendus difficile la résolution de ces problèmes.
Au sein de l’association BSU, une moyenne de cinq programmeurs bénévoles sont en charge de relever les défis rencontrés par l’évolution du jeu PMS chaque année. Les ressources humaines sont donc moindres sachant que l’équipe IT ne peut travailler que occasionnellement pour le jeu PMS. Chaque module possède entre autre ses spécificités d’implémentation et dès lors il est difficile de modifier un module créé par un autre développeur. L’absence de code partagé au sein de ces projets rend la tâche du programmeur compliqué, ce dernier n’ayant aucune base sur laquelle s’appuyer.
5.3 Modifications de la structure envisagées
Afin d’amener une solution aux problèmes cités auparavant, il est utile d’envisager une évolution de la structure actuelle. C’est pourquoi ce travail souhaite proposer une nouvelle architecture. Pour ce faire, cette dernière s’appuiera sur l’architecture de référence proposée dans le chapitre 4.2.
5.3.1 Architecture cible
L’architecture cible est clairement simplifiée par rapport à l’architecture de référence pour répondre aux exigences de la BSU sans toutefois apporter une complexité inutile.
Grâce aux nombreux outils fournis par le framework .NET, le temps d’implémentation
Partie pratique 27 est limité. Les choix des outils et technologies qui seront utilisés seront expliqués au chapitre 5.5.
Les couches intégration et orchestration ont été retirées pour l'architecture cible (cf.
Figure 7) car elles ne correspondent pas aux besoins du jeu PMS même à long terme.
Figure 7 : Nouvelle architecture pour le jeu PMS
5.3.2 Conséquences et avantages de la nouvelle architecture
La nouvelle architecture cible (cf Figure 7) amène de nombreux avantages concrets pour le jeu PMS.
- Création rapide d’un nouveau module en se servant de services existants, un module étant un élément du système.
- Mise à jour facilité d’un service en cas de bug, modification de la logique, migration vers une nouvelle technologie
- Support de données interchangeable
- Couche de présentation unique permettant d’afficher rapidement de nouveaux types de données ou de la modifier sans crainte de modifier la logique
- Transparence de l’architecture : accès identique à tous les services (standard) - Indépendant 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 rôle intervient dans certains projets de PMS Top (cf.
chapitre 5.1). Ce travail a pour but d’implémenter les projets PMS Core et Administration selon l’architecture définie (cf. Figure 7). Les changements majeurs dans PMS Top sont les suivants :
- PMS Core a désormais la responsabilité de publier les services communiquant avec la couche de données.
- Une partie de PMS Administration est déjà présente grâce à la possibilité de réutilisation de librairies existantes dans PMS Configuration. Ces librairies seront étendue afin d’offrir une meilleure abstraction et des services web exposeront les fonctionnalités. Une partie de la logique pourra également être reprise de PMS Configuration pour créer les services métiers car une couche d’accès aux données est déjà présente.
- PMS Administration consommera les services de PMS Core afin d’offrir des vues de gestion (changement période, lancement calcul, correction du cours d’un titre).
- La majorité du travail résidera donc dans l’implémentation de PMS Core. Les règles de calculs seront revues et une abstraction suffisante sera créée afin de laisser la liberté de créer de nouvelles règles de calculs de portefeuille ou de classement. Ce travail permettra également de résoudre des problèmes dans la logique de calcul rencontrée lors de la dernière session de jeu.
PMS Administration ne regroupe donc plus PMS Core et PMS Configuration mais représente un nouveau projet dans PMS Top chargé d’offrir une interface de gestion pour le calcul du jeu.
Partie pratique 29 5.3.3 Services métiers
Différentes types de services seront construits. Les types les plus communs suivant la classification du livre de Erl [Erl 2007].
- Services entités
Ce service se base sur les entitées métiers. Il fournit en général les opérations create-read-delete-update (CRUD). Il s’agit d’un service hautement réutilisable.
- Services de tâche
Ce service métier est associé à une tâche parent ou un processus. La réutilisabilité tend à être moindre.
- Services utilitaires
Certains services n’ont pas besoin d’une logique associée à un modèle métier ou un processus. Il fournir des fonctionnalités réutilisables et utilitaires.
Cette classification est utile dans le cadre de ce travail car différents types de services sont mis en place (cf. Figure 8).
Figure 8 : Types de services dans la nouvelle architecture
CalculService
Services de tâche
- nextGamePeriod
- prevGamePeriod
- nextWebPeriod
- prevWebPeriod
CoreUtil
Services utilitaires
- backupDB
- restoreDB
QuotesService
Services entités
- getQuotesForPeriod - updateQuote
Partie pratique 30 5.4 Définitions de cas d’utilisations et règles métiers pour le
module PMS Core
Le langage Unified Modeling Language (UML) est utilisé afin de spécifier le processus de calculs des portefeuilles et des classements. Des cas d’utilisations décrivent les exigences fonctionnelles de PMS Core. Les règles métiers définissent la prise de décisions dans la logique métier.
5.4.1 Cas d’utilisations
Cette partie décrit les fonctionnalités du module PMS Core. Toutes ces fonctionnalités sont accessibles depuis l’administration web. La plupart de ces cas d’utilisations ont déjà été définis dans le cadre du travail d’Elira Shehu [Shehu 2008]. Ce nouveau diagramme (cf. Figure 9) doit être vu comme une mise à jour de ce dernier correspondant au module PMS Core implémenté et mis en place dans le cadre de ce travail.
Figure 9 : Cas d’utilisation pour le module PMS Core
Partie pratique 31 5.4.1.1 Descriptions des cas d’utilisations
Une brève description accompagne chaque cas d’utilisation de la Figure 9 pour un souci de clarté.
UC7 : Avance d’une période le calcul des portefeuilles des joueurs
UC32 : Recule jusqu’à une période choisie le calcul des portefeuilles des joueurs
UC4 : Permet de corriger d’éventuelles erreurs de cours due à une importation erronée dans une période choisie
UC33 : Avance d’une période sur le site. Il s’agit de la période dans laquelle les joueurs peuvent effectuer des transactions.
UC34 : Recule d’une période sur le site. Il s’agit de la période dans laquelle les joueurs peuvent effectuer des transactions
UC28 : Effectue les transactions des joueurs en passant les ordres d’achat ou de vente UC29 : Calcule les intérêts dus entre deux périodes aux comptes des joueurs
UC30 : Mets à jour les différentes listes de classements
UC31 : Mets à jour le compte des joueurs en créditant les intérêts et en débitant/créditant les gains/pertes des joueurs.
UC32 : Avance à une période spécifique le calcul du portefeuille d'un joueur
5.4.1.2 Spécification du cas d’utilisation UC7 (Avance d’une période de calcul des portefeuilles des joueurs)
Une description plus complète et structurée accompagne généralement les cas d’utilisations pour améliorer leur compréhension. Le cas d’utilisation UC7 (cf. Figure 9) qui est l’une des fonctionnalités les plus importantes du jeu est spécifié ci-dessous.
Objectif : Cette fonctionnalité permet de calculer l’état du portefeuille des joueurs, l’état du compte en banque des joueurs ainsi que de mettre à jour les listes de classements pour la période suivante.
Acteur : L’administrateur du jeu Préconditions :
- L’administrateur utilise une interface disposant de cette fonctionnalité offerte par PMS Core
Partie pratique 32 - La période actuelle est inférieure ou égal à la dernière période du jeu
- Le jeu a été initialisé par PMS Configuration
- L’importation des cours s’est effectuée correctement Scénario principal :
1. Le cas d’utilisation commence quand l’administrateur veut faire calculer une période de jeu.
2. L’administrateur choisi le type de jeu.
3. PMS Core affiche les détails sur l’état du jeu choisi.
4. L’administrateur clique sur le bouton « calculer période ».
5. Si des nouveaux portefeuilles sont présents, ces derniers sont actualisés à la période actuelle.
o INCLUDE [UC32 Avance à une période spécifique le calcul du portefeuille d'un joueur]
6. PMS Core calcule la période – pendant le calcule PMS Core affiche des informations sur l’avancement du calcule
o INCLUDE [UC28 Effectuer les transactions]
o INCLUDE [UC29 Calculer les intérêts des joueurs]
o INCLUDE [UC30 Mettre à jour les classements]
o INCLUDE [UC31 Mettre à jour le compte des joueurs]
7. PMS Core affiche l’information que le calcule est terminé avec succès. Des statistiques sur le calcule sont affichés (durée du calcule, nombre de transactions pris en compte, nombre de joueurs calculés etc.)
8. Le cas d’utilisation se termine ici
Scénario alternatif 6a – problème durant le calcul :
Condition de branchement : un problème surgit durant le calcul de la période 6a1 PMS Core n’applique pas les modifications sur la base de données
6a2 PMS Core affiche un message d’erreur qui permet d’identifier la raison de l’erreur.
6a3 L’administrateur analyse l’erreur.
6a4 Le cas d’utilisation se termine ici.
Scénario alternatif 6b – calcul de plusieurs périodes :
Partie pratique 33 Condition de branchement : L'administrateur choisit de calculer plusieurs périodes
6b1 L'administrateur choisit une autre période à calculer que celle par défaut (Période actuelle + 1).
6b2 Le scénario 6 est répété jusqu'à atteindre la période souhaité Postconditions en cas de succès :
- La mise à jour des comptes en banque, des portefeuilles et des listes de classement s’est faite sans erreur
- La période de calcul est avancée Postconditions en cas d’échec:
- La mise à jour des comptes en banque, des portefeuilles et des listes de classement n’a pu s’effectuer
- La période de calcul n’est pas avancée - Les transactions ne sont pas calculées Règles de gestion :
- Si des transactions liées à des titres dont le cours utilisé pour le calcul est faux, l’administrateur doit corriger les erreurs de cours (UC5) et réutiliser la présente fonctionnalité.
Point d’extension : Aucun point d’extension
5.4.2 Règles métiers
La prise de décisions consistantes pour une entreprise dépend de faits et règles consistantes et de haute qualité qui sont mises à disposition preneurs de décision et des systèmes. Ces faits et règles sont connues sous le nom de règles métiers. [Von Halle 2006].
Des règles métiers ont ainsi été définies pour PMS Core afin de définir des règles de calculs pour les portefeuilles des joueurs. Elles sont d’une grande aide dans la spécification et la gouvernance de projets en décrivant des comportements précis en détails. Elles font également office d’excellentes documentations pour les projets grâce à leur clarté.
Les différentes entrées des règles métiers sont lues de la façon suivante :
Partie pratique 34
Nom : Il donne une idée globale du sujet de la règle. Il est en générale clair et concis.
Identifiant : Il permet de référencer la règle afin de la citer dans d’autres règles ou d’en faire référence dans un document externe.
Description : Elle donne une description précise de la règle. Si la règle est changée, il est capital de mettre à jour ce champ et d’ajouter le champ révision pour indiquer la date et l’auteur du changement en question.
Exemple : Pour mieux comprendre la règle et éviter d’éventuels mauvaise interprétation, un exemple vient appuyer la description.
Règles liées : Permet de référencer les règles ayant un impact sur la règle
Les règles métiers de l’ensemble de règles « Effectuer les transactions » sont présentées ci-après afin d’aider le lecteur dans leur lecture et interprétation.
Nom Options Eurex
Identifiant BR1
Description Si le prix d’une option Eurex est de 1 centime, il n’est pas possible de l’acheter. La transaction n’est dans ce cas pas marquée 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 qu’un achat est effectué, l’achat est annulé.
Règles liées /
Nom Nombre de titres maximum par catégorie Identifiant BR2
Description Un pourcentage maximum de titres d’une même catégorie est défini pour le portefeuille. Tout achat de titres dans cette catégorie est plafonné à ce pourcentage.
Partie pratique 35 Exemple Si le pourcentage maximum pour la catégorie 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 supplémentaire ne pourra être achetée.
Règles liées /
Nom Crédit
Identifiant BR3
Description L’achat de titre ne peut amener la valeur du portefeuille à dépasser le solde en banque disponible ajouté au montant du crédit accordé.
Exemple Si le crédit accordé est de 2000 CHF et le solde en banque de 10'000 CHF, il n’est pas possible d’acheter pour plus de 12000 CHF
Règles liées /
Nom Calcul des frais de courtage Identifiant BR4
Description Les frais de courtage sont calculés selon un pourcentage défini. Un minimum et un maximum de frais de courtage sont définis
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.
Règles liées /
Nom Calcul du coût de l’achat d’un titre Identifiant BR5
Description Le calcul s’effectue par la multiplication du nombre de contrats
souhaités pour un titre par la grandeur du contrat et par le cours du titre à la fermeture du marché suivant l’achat du titre. Les frais de courtages y sont également ajoutés. Une option Eurex à un cours de 1 centime ne peut être achetée (BR1)
Exemple Si un joueur achète 10 contrats d’une option ABB avec une grandeur de contrat de 10 et un cours pour l’option à la fermeture de 2 CHF, le
Partie pratique 36 prix d’achat sera de 200 CHF (10*10*2) plus les frais de courtages.
Règles liées BR4, BR1
Nom Calcul du revenu découlant de la vente d’un titre Identifiant BR6
Description Le calcul s’effectue 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 l’achat du titre. Les frais de courtages y sont déduits.
Exemple Si un joueur vend 10 contrats d’une option ABB avec une grandeur de contrat de 10 et un cours pour l’option à la fermeture de 2 CHF, le revenu sera de 200 CHF (10*10*2) moins les frais de courtages. Le système ne permet toutefois pas de calculer le gain ou la perte effectuée en calculant la différence entre le prix d’achat et vente du titre.
Règles liées BR4
On remarquera que ces règles sont atomiques (ne se décomposent pas) et cohésives. Ces critères permettent de définir les règles plus facilement. L’atomicité par ailleurs permet d’augmenter la réutilisabilité de ces règles.
La définition de ces règles devrait apporter une meilleure compréhension du
fonctionnement du jeu pour toutes les parties prenantes en clarifiant le processus plutôt complexe du calcul des portefeuilles. Les règles définies dans l’Annexe A contiennent certaines contraintes pour le jeu qui ne sont parfois pas évidentes car n’étant pas en phase avec la réalité pour des raisons techniques et de temps d’implémentation. Une personne non avertie peut ainsi prendre connaissances des spécificités du calcul au sein de PMS Core.
Partie pratique 37 5.5 Choix des composants tiers pour un développement du projet
sous .NET
Les composants tiers ont été choisis selon plusieurs critères : - Remplissent des besoins d’une architecture de type SOA - Permettent de diminuer la taille du code
- Offrent une maintenance facilitée
- Garantissent leur utilisation à long terme (continuité) - Sous licence Open Source ou gratuites
La Figure 10 permet de visualiser les différents composants tiers utilisés et quelle place ils occupent dans l’architecture (cf. chapitre 5.3.1). Chacun de ces composants fera l’objet d’une explication dans les sous-chapitres suivants et la raison de son choix sera argumentée.
Figure 10: Intégration des technologies dans l‘architecture
Partie pratique 38 5.5.1 LINQ to SQL
Ce produit de Microsoft apparu dans le Framework 3.5 permet de créer un pont entre la programmation orienté-objets et les données relationnels. Offrant une syntaxe intuitive, cette solution permet de manipuler des données sous formes d’objets. Grâce à son abstraction (cf. Figure 11), il est possible de manipuler différents types de données qu’il s’agisse de collections d’objets, d’enregistrements de bases de données ou encore de données XML.
Figure 11 : Les différentes implémentations de LINQ
L’implémentation LINQ to SQL est choisie dans ce projet pour sa stabilité et sa
simplicité. Ce choix s’impose également pour rester dans la continuité des autres projets PMS qui ont choisis LINQ.
LINQ to SQL va permettre l’implémentation de la couche d’accès aux données (cf.
Figure 12). Cette couche est l’abstraction de la persistance objets. Les couches supérieures de l’application pourront ainsi manipuler les données de manière transparente sans se soucier de la persistance objets.
LINQ to OBJECTS LINQ to ADO.NET LINQ to XML
LINQ to SQL LINQ to Dataset LINQ to Entities
Partie pratique 39
Figure 12: Rôle de LINQ to SQL dans la nouvelle architecture
Les objets provenant de LINQ to SQL sont uniquement manipulées dans CalculService.
Une projection vers des objets simplifiés, les Data Transfer Objects (DTO), est
effectuée afin d’augmenter le découplage et d’offrir des objets simples à manipuler du côté client.
Le passage de ces objets entre les différentes couches déconnecte les objets de leur contexte de données. C’est à dire que LINQ to SQL n’est plus en mesure de suivre les modifications de l’objet pour les répercuter sur la base de données. Il est donc
nécessaire d’indiquer à LINQ qu’il doit rattacher les objets au contexte. Un autre but de cet attachement est de permettre à LINQ d’effectuer un test de concurrence. Ainsi une exception sera générée si l’entrée a été modifiée entre temps,
PMS DB CalculService
LINQ to SQL DAL – Data Access Layer
IDALFacade
- CRUD operations
DTO Objects Client
BLL – Business Logic Layer
Partie pratique 40 5.5.2 Windows Communication Framework
Il a été choisi dans la nouvelle architecture PMS de découpler la couche client de la couche métier. Il est donc nécessaire de mettre en place une interface standard proposant les fonctionnalités de la couche métier à la couche client. Le moyen de communication a privilégier est évidemment le service web communiquant par HTTP et SOAP. Ce travail étant soucieux de l’évolution de l’architecture et des besoins futurs, la technologie Windows Communication Framework (WCF) de Microsoft a été choisie.
Ce framework de communication permet de communiquer aisément entre différents composants applicatifs. Il réunifie é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 souhaitée, appelé Binding dans WCF. Il est également à noter, pour se rendre compte de la puissance de ce framework, qu’il est possible d’implémenter son propre Binding.
Le Binding choisit dans ce travail se nomme WSDualHttpBinding. Ce moyen de communication offre des services sécurisés permettant aux services ainsi qu’aux clients d’envoyer et de recevoir des messages. On s’écarte donc du traditionnel service web appelant un service et recevant de manière synchrone une réponse. Ce Binding permet de créer des services asynchrones (cf. exemple de la Figure 13) car le service peut lui aussi appeler des fonctions du côté client. Cette possibilité permettra dans ce travail d’appeler des opérations du service coûteuses en temps, tel que le calcul des
portefeuilles pour une certaine période, de manière asynchrone. Le client peut ainsi être notifié de l’avancement de la tâche ainsi que de l’issue du calcul et garde la main durant l’exécution du calcul rendant inutile une attente de réponse de la part du service.
Figure 13 : Exemple de l’appel de l’opération nextPeriod sur le service PMS Core Client
Service web PMS Core
Opérations nextPeriod prevPeriod
…
Appel de nextPeriod Etat avancement Etat avancement
… Résultat / Fin
