RAPPORT De Mémoire de Fin d’Etudes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Analyse

35

3.1

Introduction .

.

.

.

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Découpage en catégories .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Dépendance entre les catégories . . . . . . . . . . . . . . . . . . . . . 36

3.3 Développement du modèle statique

. . . . . . . . . . . . . . . . . . . . . . . 36

3.3.1 Modèle structurel de la catégorie Client

. . . . . . . . . . . . . . . . . 37

3.3.2 Modèle structurel de la catégorie Ordre . . . . . . . . . . . . . . . . . 38

3.3.3 Modèle structurel de la catégorie Exécution . . . . . . . . . . . . . . . 39

3.3.4 Modèle structurel de la catégorie Liquidité

. . . . . . . . . . . . . . . 40

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

TABLE DES MATIÈRES

Page V

3.4 Développement du modèle dynamique . . . . . . . . . . . . . . . . . . . . . . 41

3.4.1 Cas d’utilisation : Gérer les ordres . . . . . . . . . . . . . . . . . . . . 41

3.4.2 Cas d’utilisation : Gérer l’exécution manuelle . . . . . . . . . . . . . . 45

3.5 Conclusion .

.

.

.

.

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Conception

48

4.1

Introduction .

.

.

.

.

.

4.2 Conception générique .

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2.1

Framework techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2.2 Les patrons de conception . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 Conception préliminaire

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.1 Conception du modèle logique . . . . . . . . . . . . . . . . . . . . . . 52

4.3.2 Conception de la structure de présentation

. . . . . . . . . . . . . . . 54

4.4 Conception détaillée

4.5 Conclusion . .

. .

.

.

.

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5 Réalisation

65

5.1

Introduction .

.

.

.

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Environnement matériel et logiciel

. . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.1 Environnement matériel

. . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3 Travail réalisé . .

.

.

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3.1

Préparation du projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3.2

Interfaces Homme/Machine . . . . . . . . . . . . . . . . . . . . . . . 68

5.3.3 L’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3.4 Module de gestion des valeurs . . . . . . . . . . . . . . . . . . . . . . 69

5.3.5 Module de gestion des contrats . . . . . . . . . . . . . . . . . . . . . . 69

5.3.6 Module de gestion des clients

. . . . . . . . . . . . . . . . . . . . . . 70

5.3.7 Module de gestion des ordres

. . . . . . . . . . . . . . . . . . . . . . 71

5.3.8 Exécution mannuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3.9 Module de gestion des liquidités . . . . . . . . . . . . . . . . . . . . . 73

5.4 Conclusion . .

. .

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

TABLE DES MATIÈRES

Conclusion générale

Page VI

76

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

Table des figures

1.1 Logo de « CybEx Solutions » . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.2 Architecture en couches .

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Pattrons utilisés en conception dirigée par le modèle.

. . . . . . . . . . . . . . 12

1.4 Processus 2TUP .

.

.

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Capture des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Diagramme de cas d’utilisation globale

. . . . . . . . . . . . . . . . . . . . . 21

2.3 Diagramme de cas d’utilisation « gérer les référentiels » . . . . . . . . . . . . . 22

2.4 Diagramme de cas d’utilisation « Gérer les rôles » . . . . . . . . . . . . . . . . 23

2.5 Diagramme de cas d’utilisation « gérer les ordres et l’éxecution manuelle » . . 24

2.6 Diagramme d’activités éxecution manuelle . . . . . . . . . . . . . . . . . . . . 29

2.7 Capture des besoins techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.8 Architecture DDDD .

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.9 Architecture logicielle du WCF . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 L’analyse .

.

.

.

.

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Découpage en catégories .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3 Dépendance entre les catégories

. . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Diagramme de classe préliminaire de la catégorie client . . . . . . . . . . . . . 37

3.5 Diagramme de classe préliminaire de la catégorie ordre . . . . . . . . . . . . . 38

3.6 Diagramme de classe préliminaire de la catégorie Exécution . . . . . . . . . . 39

3.7 Diagramme de classe préliminaire de la catégorie Exécution . . . . . . . . . . 40

3.8 Diagrammede séquence ajout d’un ordre . . . . . . . . . . . . . . . . . . . . . 43

3.9 Diagramme de communication VerifierStock . . . . . . . . . . . . . . . . . . . 44

VII

TABLE DES FIGURES

Page VIII

3.10 Diagramme de séquence exécution manuelle . . . . . . . . . . . . . . . . . . . 46

4.1 Conception . .

. .

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Design Pattern « Specification » . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Les différents blocs du Design Pattern «MVVM » . . . . . . . . . . . . . . . . 51

4.4 Rôles des différents composants du Design Pattern «MVVM» . . . . . . . . . 52

4.5 Architecture du système de gestion d’un intermédiaire en bourse.

. . . . . . . 53

4.6 Maquette du formulaire d’ajout d’ordre

. . . . . . . . . . . . . . . . . . . . . 55

4.7 Maquette du formulaire de virement interne . . . . . . . . . . . . . . . . . . . 55

4.8 Maquette d’exécution manuelle

. . . . . . . . . . . . . . . . . . . . . . . . . 56

4.9 Diagramme de classe «ClientBoundedContext» . . . . . . . . . . . . . . . . . 57

4.10 Diagramme de classe «OrdreBoundedContext» . . . . . . . . . . . . . . . . . 59

4.11 Diagramme de classe «ExecutionBoundedContext» . . . . . . . . . . . . . . . 61

4.12 Diagramme de classe «LiquiditeBoundedContext» . . . . . . . . . . . . . . . 63

5.1 Réalisation . .

. .

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Authentification .

.

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3 Module Valeurs .

. .

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4 Module Contrats

. .

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.5 Module Client . .

. .

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.6 Affectation dans un Groupe

. . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.7 Tableau de bord . .

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.8 Carnet d’ordres .

.

.

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.9 Formulaire d’ajout d’un ordre

. . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.10 L’execution mannuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.11 Saisie de Liquidité

5.12 Ordre de Payement

.

.

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.13 Import Excel

. .

. .

. .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

Liste des tableaux

1.1 Synthèse des processus de développement

. . . . . . . . . . . . . . . . . . . . 13

2.1 Cas d’utilisation .

.

.

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Contraintes non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Choix techniques .

.

.

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Tableau descriptif des classes de ClientBoundedContext . . . . . . . . . . . . . 58

4.3 Tableau descriptif des classes de OrdreBoundedContext . . . . . . . . . . . . . 60

4.4 Tableau descriptif des classes de ExecutionBoundedContext

. . . . . . . . . . 62

4.5 Tableau descriptif des classes de LiquiditeBoundedContext . . . . . . . . . . . 64

5.1 Environnement matériel .

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

IX

Introduction g´en´erale

Depuis sa création, la bourse n’a cessé d’avoir un rôle majeur dans l’équilibre économique des pays. Considérée comme un lieu de rencontre entre les émetteurs des titres capitaux et les investisseurs, la bourse constitue un marché de valeurs caractérisé par la diversité de l’offre. Néomoins, elle présente aussi bien des taux élevés de perte que de porfit.

À l’origine, la bourse était un marché supposé ouvert à quiconque souhaitant vendre ou acheter des valeurs mobilières. Cependant, afin d’assurer un meilleur contrôle sur le marché, la création d’un organisme officiel pour homologuer les contrats d’achat ou de vente est devenue une nécessité. C’est ainsi que les agents autorisés à exercer en bourse furent limitées à certaines catégories d’opérateurs, ce sont les sociétés d’intermédiation en bourse. En effet, un particulier ne peut plus intervenir directement sur le marché, mais il doit obligatoirement transmettre ses ordres à un intermédiaire financier.

En Tunisie, la profession de l’intermédiation en bourse est soumise à une réglementation stricte régie par la loi 94 - 117 du 14 novembre 1994 et le décret 99 - 2478 du 1er novembre 1999 portant statut des intermédiaires en bourse qui déterminent les opérations permises, telles que l’exclusivité de la négociation et l’enregistrement en bourse des valeurs mobilières et des produits financiers, la gestion individuelle ou collective des valeurs mobilières, la gestion des portefeuilles et le conseil financer. Ainsi, une bonne gestion des sociétés d’intermédiation en bourse nécessite un système d’information robuste, fiable et conforme à la loi, pour pouvoir traiter, transporter et diffuser une quantité énorme d’informations et de données sensibles.

C’est dans ce contexte que s’inscrit ce Projet de Fin d’Etudes qui consiste à une contribution à la mise en place d’un système de gestion d’un intermédiaire en bourse et plus particulièrement au développement du volet Back Office.

Le présent manuscrit s’articule autour de cinq chapitres, Le premier consiste à introduire le cadre général du projet à travers une étude préliminaire qui consiste à présenter les termes clés du projet et ce, par une introduction au monde de la bourse, une exposition des concepts de

Domaine Driven Design ainsi qu’une présentation du processus de développement utilisé. Le second chapitre expose les besoins fonctionnels et techniques afin de donner un appui au quatrième chapitre qui décrit la phase d’analyse. Le cinquième chapitre traite la conception de la solution. Enfin le dernier chapitre illustre le résultat obtenu.

Chapitre 1

´Etude pr´eliminaire

1.1

Introduction

Ce premier chapitre sert, dans une première partie, à présenter l’environnement du stage de fin d’étude et ce, par un aperçu sur le domaine d’activité de la société accueillante «CybEx solutions», ainsi qu’une brève exposition des produits et services offerts par cette dernière.

La seconde partie s’intéresse à la définition des éléments nécessaires pour entamer notre travail, notamment les divers concepts introduits par le domaine de la bourse, le principe de conception suivit, ainsi que la méthode de développement adoptée.

La troisième et la dernière partie s’intéresse à poser la problématique du projet à travers une étude, puis une critique de l’existant afin d’en tirer les solutions adéquates.

1.2 Présentation de l’organisme d’accueil

L’organisme d’accueil est une entreprise tunisienne exerçant dans développement des solutions financières.

le domaine de

FIGURE 1.1 – Logo de « CybEx Solutions »

1.2.1 Aperçu

CybEx est une société de services et de développement des solutions Front Office, Middle Office et Back Office pour les métiers de bourse. Bâtit sur le savoir et le savoir-faire des professionnels des métiers de la bourse, bénéficiant d’une solide expérience dans le domaine financier.

3

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 4

Outre les missions de conseil, l’audit et la consultation auprès des banques et des intermédiaires en bourse, CybEx offre des solutions expertes et innovantes pour les intermédiaires en bourse, les banques, les sociétés de gestion et les établissements financiers spécialisés.

1.2.2 Produits de CybEx Solutions

CybEx Solutions offre un ensemble de produits particulièrement adaptés aux besoins des sociétés d’intermédiation en bourse aussi que pour leurs clients et partenaires. Ces solutions peuvent être défalquées en deux catégories, des solutions client adressés effectivement aux clients de l’intermédiaire en bourse et des solutions Pro dédiées aux professionnels de l’intermédiaire à savoir les négociateurs, les commerciaux et les agents de Back Office.

• Solutions Clients :

Dans ce volet, « CybEx Solutions» offre une panoplie de solutions parmi lesquelles ou peut citer :

« CybEx Mobile Trading » qui est une solution mobile permettant la consultation du marché

boursier Tunisien et le passage d’ordres en temps réel à travers un Smartphone.

« CybExETrade » qui est une solution web, permettant la réception, en temps réel, du flux boursier complet (meilleures limites, profondeur, intraday, quantités, cours, limites, news, etc.), ainsi que la gestion complète d’un carnet d’ordres. Le client pourra ainsi envoyer, modifier et annuler ses ordres d’achat et de vente.

« CybExPluvalue et Impôt » qui est une solution web du type Application Intenet Riche, permettant au client à travers un accès sécurisé sur internet, mais également à l’intermédiaire en bourse, de calculer la Plus-value réalisée pour une période donnée ainsi que le montant exacte des impôts à déclarer.

• Solutions Pro :

Dans ce context, « CybEx Solutions» offre une ensemble de solutions parmi lesquelles ou peut citer :

« CybExMarketFeed » qui est une solution de consultation assurant l’acheminement, aux opérateurs du marché, de l’ensemble des flux nécessaires à l’exercice de leur activité et à l’optimisation de leur processus de prise de décisions. Le serveur CybEx MARKET FEED garantie à l’intermédiaire l’autonomie et la disponibilité de l’ensemble des données du marché et ce à toutes heures. Cette solution est destinée aux professionnels de la bourse comme aux négociateurs ou les analystes financiers œuvrant au sein d’un réseau d’entreprise (LAN/VPN).

« CybEx OMS » est une solution à travers laquelle, CybEx fut la première société à avoir passé avec succès les tests de validation de la BVMT et du CMF de son logiciel CybEx

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 5

OMS® (Order Management System) et ce en Janvier 2009. CybEx OMS s’adresse à tous ceux qui souhaitent sécuriser la gestion et l’envoi de leurs ordres en temps réel selon des règles et des contraintes prédéfinies.

« CybEx CEA » qui est une solution de Gestion efficace et optimisée des Comptes Epargnes Actions. CybEx CEA permet la (i) consultation de la liste détaillées des clients CEA, (ii) détermination des clients qui ont des soldes critiques, (iii) détermination et transfert des droits, (iv) détermination et transfert des dividendes, (v) Détermination et transfert des plus-values réalisées, (vi) transfert multiple des plus-values réalisées par PF ou par Ligne.

1.3 La bourse et les marchés financiers

1.3.1 Définition

La bourse est le lieu ou les investisseurs peuvent acheter et vendre des titres de capital ou de créance émisent par l’état des entreprises, ou même des collectivités locales. Son rôle principal est d’assurer la liquidité des titres détenus par les investisseurs. Cette liquidité permet aux émetteurs de se procurer des fonds pour financer leur croissance en faisant appel au public.A ce titre, la bourse constitue l’une des sources principales du financement de l’économie.

La bourse des valeurs mobilières de Tunis (BVMT) [5] gère le marché Tunisien des valeurs mobilières par : • l’admission de nouveaux titres à la cote de la bourse. • l’organisation des échanges et la cotation des titres dans les meilleures conditions d’égalité,

de sécurité et de transparence.

• la diffusion des informations boursières.

1.3.2 Les valeurs mobilières

Les valeurs mobilières sont des titres négociables et interchangeables, ils peuvent être cotés en bourse ou non. Les deux grandes catégories de valeurs mobilières sont les actions et les obligations,mais il en existe d’autres, telles que les options, les bons de souscription et les Warrants.

Les actions

Les actions [6] sont des titres de propriété d’une société. Chaque action représente une fraction du capital de cette entreprise. La possession d’actions donne des droits à leur détenteur auprès

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 6

de l’entreprise concernée ; droits liés au statut de copropriétaire de l’entreprise et qui s’exercent proportionnellement au nombre d’actions détenues.

Les obligations

En cas de besoin de financement, la bourse constitue pour les entreprises, privées ou publiques, une alternative au crédit bancaire. Dans ce cas, l’entreprise émet des titres de créance appelés obligations[6].

Chaque obligation représente une fraction d’un emprunt émise par l’entreprise sur le marché boursier. Le porteur de l’obligation devient donc créancier de l’entreprise.

Le porteur d’obligation, court un risque inférieur au porteur d’action, car l’obligation lui assure des garanties de rémunération et de remboursement. En revanche, le porteur d’obligation ne joue pas des mêmes droits que le porteur d’action : il ne bénéficie ni du droit sur les bénéfices, ni du droit de gestion ou du droit de vote. Les obligations sont rémunérées en fonction d’un taux d’intérêt sur la valeur faciale. Ce taux est fixé par voie contractuelle dès l’émission du titre de créance.

1.3.3 Ordre de bourse

Un ordre de bourse est un ordre passé par une personne physique ou morale à son intermédiaire pour acheter ou vendre en bourse. Cet ordre comporte obligatoirement : • Le sens de l’opération : achat ou vente. • La nature des titres : code ISIN 1de la valeur. • Le nombre de titres : quantité. • Le client. • La validité : jour, révocation ou à date déterminée. • Les conditions de prix :à tout prix , à cours limité ou autres modalités.

1.3.4 La validité des ordres

Les ordres sur la bourse Tunisienne peuvent avoir différentes options de validité tel que : • La validité jour : l’ordre transmis n’est valable que pour la séance du jour. Non exécuté à

l’issue d’une séance, il est échu et nécessite la saisie d’un nouvel ordre.

• La validité révocation : l’ordre ainsi libellé, aura pour échéance le dernier jour de l’année

boursière en cours.

• La validité date : le choix d’une date fixe est possible.

1. International Securities Identification Number

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 7

1.3.5 Les conditions de prix des ordres

Il existe différentes conditions sur le prix d’un ordre :

Ordre à cours limité

Ce type de modalité est à la fois le plus simple. Il traduit le prix maximal qu’accepte de payer un acheteur ou le prix minimal qu’exige un vendeur. En cours de séance, ces ordres restent inscrits en carnet jusqu’à ce qu’une contrepartie accepte ces conditions. Il permet de maîtriser le prix d’exécution et donc de se protéger contre les fluctuations de cours. Son exécution peut être partielle.

Ordre à tout prix (ATP)

Il s’agit d’un ordre sans limite de prix spécifié. Au moment de l’ouverture, ce type d’ordre est prioritaire sur tous les autres types d’ordres et peut faire l’objet d’une exécution partielle. Cet ordre ne permet pas de maîtriser le cours d’exécution.

Ordre à la meilleure limite

Il s’agit d’un ordre sans limite de prix spécifié. En arrivant sur le marché : • A l’ouverture, il est transformé en ordre limité au cours d’ouverture. Il est exécuté en fonction des soldes disponibles du carnet d’ordres après prise en compte des ordres au marché et des ordres à cours limité.

• En cours de séance, l’ordre est positionné au prix de la meilleure offre en attente (pour un achat) ou de la meilleure demande (pour une vente). En cas d’exécution partielle, la quantité restante se transforme en ordre à cours limité au cours d’exécution.

Ordre à seuil de déclenchement (Stop Limit)

Il permet à un investisseur de se porter acheteur ou vendeur à partir d’un cours déterminé par le seuil de déclenchement. Il comporte une limite à partir de laquelle il se transforme en ordre « à tout prix ». Ce type d’ordre ne permet pas de maîtriser le prix d’exécution.

Ordre à plage de déclenchement (Stop Loss)

Ce type d’ordre permet de se porter acheteur ou vendeur à partir d’un cours déterminé par le seuil de déclenchement, tout en se fixant une limite maximale pour un ordre d’achat ou minimale pour un ordre de vente. Il permet la maîtrise du prix d’exécution et permet de se protéger contre d’éventuels renversements de tendance.

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 8

Ordre au cours d’ouverture

Ordre réservé aux valeurs les plus liquides donnant accès à une phase de cotation spécifique entre 9h00 et 10h00. Il ne peut être assorti que d’une validité « jour ». Il permet de connaître par avance le cours d’exécution, sous réserve de cotation de la valeur et d’existence de quantité suffisante.

1.3.6 Les types de client

La bouse Tunisienne prend en charge les types de client suivant : • Libre de nationalité Tunisienne. • Géré de nationalité Tunisienne. • Teneur de marché. • Compte propre. • Libre de nationalité étrangère. • Géré de nationalité étrangère. • Compte OPCVM 2.

1.3.7 Liquidité

La liquidité [7] est la capacité et la rapidité avec laquelle il est possible d’acheter ou de vendre un actif ou un passif sur le marché sans que les prix du support n’en soient fortement affectés.

1.3.8 Portefeuille boursier

Le portefeuille boursier est la représentation de l’ensemble des titres sur lesquels un agent économique a investi sur le marché financier.

1.3.9 Ordre de paiement

Un ordre de paiement [7] est une instruction donnée par un client à son teneur de compte, de mettre une somme d’argent à la disposition d’un bénéficiaire.

2. Organisme de Placement Collectif en Valeurs Mobilières

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 9

Remarque

Vue la délicatesse des différentes notions définies dans ce qui précède, il serait difficile à un développeur de côtoyer le domaine de la bourse dans un temps réduit pour y proposer des solutions. Dans ce sens, il serait fort intéressant de chercher à simplifier la tâche de l’informaticien d’une part et du financier d’autre part lors de la réalisation du logiciel où l’intervention de ces deux experts est indispensable.

La partie suivante introduit une méthode de conception simplificatrice et générique, qui à notre avis adéquate pour notre travail.

1.4 Domain Driven Design

Domain Driven Design [1], noté en litérature DDD, ou conception pilotée par le domaine est une approche basée sur un ensemble de principes et de modèles, qui combine les bonnes pratiques de conception et d’implémentation pour permettre aux développeurs logiciels de créer et concevoir des applications performantes pour des domaines métiers complexes et délicats à apprendre

La conception pilotée par le domaine n’impose aucune technologie, ni méthodologie mais elle donne la priorité au domaine métier face aux aspects techniques pour diriger le développement.

1.4.1 Besoin de comprendre le domaine métier

Afin de concevoir un logiciel qui répond aux besoins des utilisateurs, il est primordial de comprendre le domaine métier dans lequel le système va opérer.

Une bonne connaissance du domaine consiste à la création d’un modèle représentatif en faisant travailler les spécialistes informatiques avec des experts métier. Cette étape est nécessaire et indispensable pour aboutir à un logiciel qui reflète le domaine.

En pratique, cette approche se heurte à quelques difficultés dues à des problèmes de communication. Chaque membre du projet à savoir développeur, architecte, chef de projet ou expert métier est inscrit dans un domaine propre à lui. Chacun possède son propre jargon et ses propres termes qui peuvent être incompréhensibles par les autres membres.

Afin de remédier a ce problème, la DDD propose d’établir un langage commun, appelé «Ubiquitous Language» ou langage omniprésent, qui rassemble tous les termes et mots clés, et qui sera utilisé tout le long du processus de développement du logiciel.

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 10

1.4.2 Le langage omniprésent «Ubiquitous language»

L’un des principes de base de la DDD, est l’établissement d’un langage commun entre les différents intervenants dans le processus de développement.

Pour éviter l’incompréhension entre développeurs, architectes et experts métier, ce langage introduit donc des concepts techniques, architecturals et métiers intégrés ensemble afin que les contraintes soient prises en compte aussi bien par les spécialistes métiers que par les développeurs afin de produire un logiciel robuste qui répond aux besoins des utilisateurs.

1.4.3 Concevoir le modèle métier

Selon Eric Evans le fondateur du la DDD, un modèle du domaine, n’est pas un diagramme particulier mais c’est l’idée qu’on cherche à dévoiler à travers. Il ne représente pas forcément la connaissance contenue dans le cerveau d’un professionnel du domaine mais, une abstraction rigoureusement sélective et organisée de cette connaissance.

Afin de concevoir un modèle de domaine le processus peut s’effectuer à travers des ateliers de travail «workshops» qui réunissent des spécialistes métiers, architectes et développeurs en considérant le langage omniprésent comme colonne vertébrale du modèle à réaliser.

Il est important d’impliquer les développeurs et les experts techniques dans le processus d’établissement du modèle afin d’aboutir à un modèle qui puisse être exprimé convenablement dans les phases de conception et d’implémentation.

les développeurs apportent le "feedback" nécessaire pour s’assurer que le modèle porposé par expert métier peut être implémentable en logiciel.

1.4.4 Conception dirigée par le modèle

L’obtention d’un bon modèle qui reflète les concepts de domaine métier et qui représente précisément les besoins des utilisateurs est extrêmement important, mais un échec dans la phase de transformation du modèle de domaine en code peut mener à un logiciel de qualité discutable.

Le passage du modèle de domaine à l’implémentation est souvent délicate.

Afin de donner un support solide à la conception et pour remédier aux problèmes d’architecture, la DDD introduit un ensemble de concepts dans le langage commun. Ces notions doivent être assimilées par les développeurs, les architectes et les spécialistes métiers.

1.4.4.1 Architecture en couches

Le Domain Driven Design renforce le paradigme d’architecture en couches et propose une architecture composée de quatre couches séparées dont chacune est cohérente et ne dépend

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 11

que de la couche inférieure afin de fournir un couplage faible entre elles. Toute la logique du domaine métier est donc encapsulée dans une seule couche ce que, en résulte une coucheapplicative fine responsable de stocker l’état de l’interface utilisateur et de communiquer avec la couche domaine

De plus une couche technique « infrastructure transverse » dénuée de toute logique métier, qui a pour rôle de fournir un support solide à l’application dans laquelle seront disponibles toutes les fonctionnalités facilitant la gestion des journaux d’exécution (logs),la sécurité, la gestion de cache etc., ce qui améliore la robustesse et les performances de l’application (cache, montée en charge, gestion des threads, etc.).

FIGURE 1.2 – Architecture en couches

1.4.4.2 Les Entités (Entities)

Une entité est un objet ayant une identité unique qui reste constante tout au long du cycle de vie de l’application.

1.4.4.3 Les objets valeurs (ValueObject)

Les objets-valeurs viennent complémenter les entités. Ils découlent de deux concepts importants : ne pas avoir d’identité et être partageable par plusieurs modules métiers.

1.4.4.4 Les Services

Un service définit une opération ou une activité bien déterminée qui n’appartient à aucun objet du modèle. Ces opérations touchent plusieurs objets et assurent la coordination entre eux.

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 12

1.4.4.5 Les Agrégats (Aggregates)

Un agrégat est un ensemble d’objets liés entre eux par une relation logique et formant une seule unité. Il fait la séparation entre ces objets internes et les objets externes. Chaque agrégat est défini par une seule racine, qui doit être une entité et est le seul objet accessible de l’extérieur contenant les références des différents objets de l’agrégat.

1.4.4.6 Les Fabriques

Les fabriques (Factories) sont utilisées pour la création d’objets complexes dont on doit savoir la structure interne et les règles appliquées en respectant le principe d’encapsulation des objets. Ils sont très utiles dans la création des agrégats.

1.4.4.7 Les entrepôts (Repositories)

L’Entrepôt ont pour rôle de conserver des références vers des objets. Quand un objet est créé, il peut être sauvegardé dans l’Entrepôt, et y être récupéré ultérieurement en cas de besoin. Ils peuvent être un intermédiaire entre les objets du domaine et l’infrastructure.

FIGURE 1.3 – Pattrons utilisés en conception dirigée par le modèle.

Le diagramme [1] de la figure1.2 montre les différents pattrons utilisés en conception dirigée par le modèle et des relations qui existent entre eux.

MIMITA Walid

Mémoire de Fin d’Etudes ENSI 2013

CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Page 13

1.4.5 Les apports du Domain Driven Design

Le Domain Driven Design, n’impose aucun formalisme, ni méthode pour comprendre et acquérir le domaine. Il insiste simplement sur l’importance d’une communication continue entre tous les membres du projet en utilisant un langage partagé et unifier tout au long du projet.

De point de vue architecture, la concentration du métier dans une seule couche rend le code plus maintenable et évolutif. Un autre point important est l’isolation du code métier. Ceci facilite le développement des tests unitaires qui permettent ainsi de contrô