MemoirePFE Abdelkayoum DERFOUFI - Naoual LAMZIRA

Royaume du Maroc
Université Mohammed Premier

Ecole Nationale des Sciences Appliquées Oujda
Filière Génie Informatique
Mémoire de Projet de fin d’Etudes

Présenté en vue d’obtenir
Le diplôme d’Ingénieur d’Etat
Spécialité : Génie Informatique
Option : Qualité Logiciel
N° : GI25/2016
Sujet :
Mise en place du module de gestion des stocks bobines et conception

d’une partie de la vente du système d’information des voyageurs de
l’ONCF.
Soutenu le : 14/07/2016
Présenté par : Encadré par :

DERFOUFI Abdelkayoum M. MEZOUARI Jihad (Algo Consulting)
LAMZIRA Naoual Mme. ROUBI Sarra (ENSAO)
Membres du jury:
M. BELKASSMI Mohammed Ghaouth
Mme. ROUBI Sarra
M. SABER Mohammed
Année universitaire : 2015/2016

Rapport PFE ENSAO : 2015/2016 2
‫… إلى من جاال كل المستشفيات بحثا عن‬. ‫الى من سهرا الليالي امال في تهدئة وجع واخماد صراخ‬
‫دائي‬
‫ حين أدخلوني غرفة العمليات‬،‫ الى من بات يناجي‬.… ‫الى من ذرفت الدموع‬
‫… الى من ابرحاني ضربا حين اشتكتني احدى‬. ‫الى من علماني ان طريق العلم بدايته المدرسة‬
‫المدرسات‬
‫ الى معنى الحب والحنان والتفاني‬... ‫الى من تكبدا عناء تربيتي‬
‫ اهدي هذا العمل‬... ‫… اليكما يا سر نجاحي‬. ‫الى من بوجودهما اكتسبت قوة الجد واالجتهاد‬
.‫ والداي‬،‫… رب ارحمهما كما ربياني صغيرا‬. ‫ احبكما‬... ‫ شكرا ثم شكرا‬،‫شكرا‬
Dear brother and sister, there is no time to write you poetry, I will let your
children do that for you. However, thank you for being such an amazing brother
and an adorable sister all those past years.
To Ms. Sarra, Mr. Saber, Mr. Belkasmi, the big boss Mr. Bouchentouf and all my 127
teachers, I learned so much from you ...Thank you.
To my friends, my best supporters, Thank you for always being there for me, I am
so grateful to you.
To myself, enjoy life !
Abdelkayoum

A mon symbole de bonté, ma source inépuisable de tendresse et de prières, mon exemple
de dévouement qui n’a jamais cessé de m’encourager, à celle qui a pu tout sacrifier pour
moi, à celle qu’aucune dédicace ne saura être assez éloquente pour exprimer tout ce
qu’elle me doit, je dédie ce travail, en témoignage de mon profond amour et respect, à
ma très chère mère.
A celui qui a tant fait de sacrifices pour mon éducation et ma formation, celui qui a
toujours été à mes côtés pour me soutenir, celui qui a inlassablement fourni des efforts
jour et nuit pour mon bien être, à celui que j’aime, j’estime et je respecte, je dédie ce
travail à mon père.
A mon père spirituel, mon exemple et ma source d’inspiration, mon très cher oncle
Belqassem, je dédie ce travail.
A ceux pour qui j’ai toujours porté amour, attachement et affection, et pour qui je
souhaite une très bonne réussite, je dédie ce travail à mes chères petits frères
Mohammed et Ilyasse.
A ma famille qui m’aime et qui m’a toujours encouragé je dédie ce travail.
A tous mes très chères amies et chers amis, je dédie ce travail.
A tous les gens qui m’aiment et qui ont contribué de près ou

de loin à mon succès, je leur dédie ce travail
en leur souhaitant une vie pleine
de bonheur et de réussite.
Naoual

Remerciements
Il nous est agréable de nous acquitter d’une dette de reconnaissance auprès de

toutes les personnes, dont l’intervention au cours de ce projet, a favorisé son
aboutissement.
Merci à M. BOUCHENTOUF Toumi, le chef de filière, pour son aide, et sa
forte énergie pendant les trois années durant lesquelles il nous a inculqué la culture des
nouvelles technologies de l’information et de la bonne communication.
Nous remercions également M. MEZOUARI Jihad notre encadrant chez Algo
Consulting Group, pour ses conseils et directives pertinents qui nous ont appuyé
considérablement dans notre démarche.
Nous tenons à remercier infiniment notre adorable encadrante Mme ROUBI
Sarra professeur à l’Ecole Nationale des Sciences Appliquées d’Oujda pour sa
disponibilité, ses remarques constructives, ses précieux conseils et directives.
Nous profitons de l’occasion pour remercier le cadre professoral de l’ENSAO,
pour la formation prodigieuse qu’ils nous ont prodiguée.
Nous tenons à exprimer notre gratitude aux membres du Jury d’avoir acceptés
d’enrichir notre travail par leurs remarques.
Que tous ceux qui nous ont aidés, de près ou de loin, trouvent ici l’expression
de nos sentiments les meilleurs.

Résumé
Ce présent document fructifie l’ensemble de nos travaux apportés dans le cadre

de notre projet de fin d’études, durant lequel nous avons contribué à la mise en œuvre
d’un module de gestion des stocks bobines qui sont des rouleaux de papier qui sert à
l’impression des billets de voyages pour le projet SIV, ainsi que d’élaborer une
conception exhaustive de la partie vente des billets de voyage et des cartes
d’abonnement. En effet, le projet SIV est un système qui gère les services offerts par
l’ONCF à sa clientèle.
Pour la réalisation du projet, nous avons suivi les mêmes étapes pour chacune
des parties du projet. La première partie était consacrée à la partie de gestion des stocks
bobines. La deuxième partie était au tour de la conception de la vente des billets de
voyages et des cartes d’abonnement. Pour la partie réalisation, elle comporte en
premier lieu l’étude et l’analyse fonctionnelle, en second lieu ; la mise en œuvre et
enfin la dernière étape comportant la livraison.
L’élaboration du projet « SIV » a suivi une méthodologie de gestion de projet
agile SCRUM avec un cycle de développement semi-itératif et incrémental. Le projet
a été mis en œuvre en utilisant le langage « C# » et la technologie « WPF » du
Framework « .NET », en adoptant le patron de conception « MVVM » et une
architecture SOA, qui se base sur des web services.
Mots Clés : LGV, SIV, ONCF, WPF, MVVM, SOA.

Abstract
The present document synthesizes our work provided as a part of our project
of end of study, during which we were asked to implement a coil inventory
management module and to elaborate an exhaustive conception of sale of travel tickets
and passes part, for the SIV project. Indeed, the SIV project is a system that manages
the services offered by ONCF to its customers.
To achieve this project, we followed a number of steps for the two parts. The
coil inventory management module part and the exhaustive conception of sale of travel
tickets and passes part. We studied and analyzed the specification, implement those
specifications and finally we made delivery to the customer.
SIV project was realized using the language “C#”, the technology “WPF” of
the Framework “.NET” adopting the design pattern “MVVM” and the architecture
“SOA”, following the methodology SCRUM which is very suite to the nature of our
project.
Key words: SIV, ONCF, WPF, MVVM, SOA.

‫ملخص‬
‫تمثل هذه الوثيقة تقريرا لمشروع تخرجنا الذي انجزناه‪ .‬حيث ساهمنا بتصميم و تطوير وحدة تسيير‬
‫مستودع الملفات اللولبية الخاصة بتذاكر المسافرين بالمكتب الوطني للسكك الحديدية‪ ،‬و أيضا تصميم بعض‬
‫االضافات الخاصة ببيع التذاكر و بطائق انخراط المسافرين‪ .‬هذه الوحدة تندرج ضمن النظام المعلوماتي الجديد‬
‫لهذا المكتب‪ ،‬الذي سيمكنه من حل مجموعة من التحديات التي يواجهها النظام الحالي ‪ .SABIL‬الجل تحقيق‬
‫هذا المشروع‪ ،‬قمنا باتباع نفس المراحل الجل قسمي المشروع معا؛ القسم االول خصص لتسيير مستودع الملفات‬
‫اللولبية‪ ،‬والقسم الثاني خصص لتصميم بعض االضافات الخاصة ببيع التذاكر وبطائق انخراط المسافرين‪ .‬فيما‬
‫يخص مراحل تنزيل المشروع‪ ،‬قمنا في بادئ االمر بدراسة السياق العام للمشروع‪ ،‬ما تم انجازه من طرف فريق‬
‫الشركة ومختلف ادوات التطوير المعلوماتية‪ .‬فيما بعد قمنا بدراسة وتصميم وظائف هذه الوحدة‪ .‬فيما يلي تم‬
‫تطوير هذه الوظائف و دمجها في النظام الذي يتم تطويره ‪ ،SIV‬و اخيرا اختبار و تصحيح االخطاء‪ .‬اتبع اعداد‬
‫‪ SIV‬كمنهجية لتسيير المشارييع ‪ Scrum‬و ذلك بدورات تزايدية و نصف تزايدية‪ C# ،‬كلغة للتطوير‬
‫المعلوماتي ‪ WPF،‬اداة من طرف ‪ Microsoft‬و ‪ MVVM‬كنمط للتصميم و اخيرا ‪ SOA‬كهندسة تكنولوجية‬
‫للمشروع‪.‬‬
‫‪Rapport PFE ENSAO : 2015/2016‬‬ ‫‪8‬‬

Liste des abréviations
Abréviation Désignation
SIV Système d’information des voyageurs
M1 Module 1
XP eXtreme Programing
SOA Architecture orientée services
MVVM Modèle vue vue-modèle
TFS Team Foundation Server
ONCF Office national des chemins de fer
LGV Ligne à grande vitesse
BC Bon de commande
BL Bon de livraison
SA Scénario alternatif
WPF Windows Presentation Foundation
IIS Internet Information Services
UI User Interface
XAML eXtensible Application Markup Language
DTO Data Transfert Object
SGC Solution pour la gestion des courriers
SGF Solution de gestion de workflow

Liste des figures
Figure 1 : Schéma représentatif des modules du projet SIV ................................ 21

Figure 2 : Processus de développement itératif [2] ............................................... 25
Figure 3 : Diagramme de cas d'utilisation gestion des stocks bobines backOffice
.................................................................................................................................... 30
Figure 4 : Diagramme de cas d'utilisation gestion des stocks bobines frontOffice
.................................................................................................................................... 31
Figure 5 : Diagramme d'activité des états d'une commande ................................ 32
Figure 6 : Diagramme d'activité d'une opération service..................................... 33
Figure 7 : Diagramme de séquence cas d'une commande .................................... 35
Figure 8 : Diagramme de séquence pour une prise de service ............................. 36
Figure 9 : Diagramme de classes - Gestion des stocks bobines ............................ 37
Figure 10 : Architecture du projet SIV [3] ............................................................ 39
Figure 11 : Architecture MVVM [7] ....................................................................... 40
Figure 12 : Interface de gestion des commandes ................................................... 45
Figure 13 : Interface de suivi de la consommation des bobines ........................... 46
Figure 14 : pop-up prise de service ......................................................................... 47
Figure 15 : Pop-up changement de bobine ............................................................. 47
Figure 16 : Pop-up de fin de service ....................................................................... 48
Figure 17 : illustration du filtre de recherche ........................................................ 49
Figure 18 : interface illustrant l'alerte de changement de bobine ....................... 50
Figure 20 : Diagramme de cas d'utilisation Complément M1 - Vente des billets
de voyage et des cartes d'abonnement .................................................................... 56
Figure 21 : Diagramme de cas d'utilisation Complément M1 Vente des billets de
voyage ........................................................................................................................ 57
Figure 22 : Diagramme de cas d'utilisation Complément M1 - Vente guichet
grand groupe ............................................................................................................. 58
Figure 23 : Diagramme de classes pour la partie backOffice............................... 59
Figure 24 : Diagramme de classes pour le voyage grands groupes...................... 61
Figure 25 : Diagramme de séquence pour la consultation des
commandes/livraisons .............................................................................................. 76
Figure 26 : Diagramme de séquence pour la consultation de la consommation
des bobines ................................................................................................................ 77
Figure 27 : Diagramme de séquence pour le changement de bobine .................. 78
Figure 28 : Diagramme de séquence pour la fin de service .................................. 79
Figure 29 : Diagramme de classes vente des tickets de quais ............................... 80
Figure 30 : Diagramme de classes chèque cadeau ................................................. 81
Figure 31 : Diagramme de classes pour une contravention.................................. 83
Figure 32 : Pop-up commander des bobines .......................................................... 84
Figure 33 : Pop-up modifier une commande ......................................................... 84
Figure 34 : Pop-up confirmation de livraison ........................................................ 85

Figure 35 : Pop-up état de la commande non livrée .............................................. 85
Figure 36 : Pop-up état de la commande livrée ..................................................... 86
Figure 37 : interface consulter la consommation par établissement niveau 1 .... 86
Figure 38 : interface consulter la consommation par établissement niveau 2 .... 87
Figure 39 : interface consulter la consommation par gare niveau 1.................... 87
Figure 40 : Interface consulter la consommation par gare niveau 2 ................... 88
Figure 41 : Interface consulter la consommation par poste de vente .................. 88
Figure 42 : Illustration du processus de la commande ......................................... 89
Figure 43 : Prise de service ...................................................................................... 90
Figure 44 : Illustration de changement de bobine ................................................. 90
Figure 45 : Illustration de fin de service................................................................. 91
Figure 46 : L'ensemble des billets imprimées durant le service d'un vendeur ... 91

Liste des tableaux
Tableau 1 : Tableau comparatif entre le système actuel SABIL et le SIV [13] .............. 20
Tableau 2 : Tableau représentatif des retours de l'ONCF sur le module 1 du SIV ....... 22
Tableau 3 : Comparaison entre les différents cycles de vie [1] ........................................ 24
Tableau 4 : Tableau des retours ONCF Vente .................................................................. 54
Tableau 5 : Tableau des services prévus pour la partie backOffice ................................ 59
Tableau 6 : Services conçus pour l'émission des billets de voyage .................................. 60
Tableau 7 : Service conçus pour la vente guichet - Grand groupe .................................. 61
Tableau 8 : Tableau de spécification des commandes des bobines.................................. 69
Tableau 9 : Tableau de spécification des livraisons des bobines ..................................... 70
Tableau 10 : Tableau de spécification consultation de la consommation des bobines... 71
Tableau 11 : Tableau de spécification prise de service ..................................................... 72
Tableau 12 : Tableau de spécification fin de service......................................................... 73
Tableau 13: Services conçus pour la vente des tickets de quais....................................... 81
Tableau 14 : services conçus pour l'envoi des chèques cadeaux ...................................... 82
Tableau 15 : Services conçus pour le paiement des contraventions ................................ 83

Table des matières
Introduction générale .......................................................................................................... 15
Chapitre I : Contexte général ............................................................................................. 17
I. Présentation de l’organisme d’accueil ................................................................... 18
1.1. Présentation d’Algo Consulting Group.......................................................... 18
1.2. Présentation de l’ONCF : Le client ................................................................ 19
1.3. Présentation d’Omnidata : Organisme validateur ....................................... 19
II. Présentation du projet SIV ................................................................................. 20
2.1. Approche générale sur le projet SIV .............................................................. 20
2.2. Contexte du Complément M1 du projet SIV................................................. 22
III. Pilotage et conduite du projet SIV ..................................................................... 23
3.1. Gestion de projet : Scrum ............................................................................... 23
3.2. Cycle de développement : Semi-itératif et incrémental ................................ 24
Chapitre II : Gestion des stocks bobines............................................................................ 27
I. Etude et analyse fonctionnelle du projet ................................................................ 28
1.1. Cahier de charges............................................................................................. 28
1.2. Conception comportementale ......................................................................... 29
1.3. Conception structurelle ................................................................................... 34
II. Mise en œuvre du projet ...................................................................................... 38
2.1. Architecture du projet : Design Pattern MVVM .......................................... 38
2.2. Technologies et outils utilisés .......................................................................... 41
2.3. Réalisation ........................................................................................................ 44
2.4. Livraison ........................................................................................................... 48
Chapitre III : Vente des billets de voyage et des cartes d’abonnement .......................... 52
I. Etude et Analyse fonctionnelle ................................................................................ 53
1.1. Etude de l’existant............................................................................................ 53
1.2. Cahier de charges............................................................................................. 54
II. Mise en œuvre....................................................................................................... 55
2.1. Conception comportementale ......................................................................... 55
2.2. Conception structurelle ................................................................................... 58
2.3. Livraison ........................................................................................................... 62
Conclusion générale ............................................................................................................. 64
Webliographie ...................................................................................................................... 66
Annexes ................................................................................................................................. 67

Annexe A : Détails des spécifications fonctionnelles gestion stocks bobines .............. 68
Annexe B : Détails de la saisie de la bobine de prise/fin de service et du changement
de bobine ........................................................................................................................... 74
Annexe C : Détails de la conception structurelle .......................................................... 76
Annexe D : Détails des réalisations – Gestion des stocks bobines ............................... 84
Annexe E : Détails des scénarios métier ........................................................................ 89

Introduction générale
L’entreprise est une entité économique financièrement indépendante réunissant

des moyens de production en vue de créer des biens et services pour la satisfaction de
sa clientèle et la réalisation d’un profit. Sa croissance passe par une organisation établie
sur des bases bien définies et des objectifs clairement fixés, tenant compte de son
environnement et de la gestion rigoureuse de ses différentes fonctions.
L’une des principales fonctions d’une entreprise disposant d’un stock est la fonction
APPROVISIONNEMENT. Elle regroupe les opérations d’achat et de stockage des
produits et permet à l’entreprise d’avoir une bonne politique de gestion des achats, lui
assurant des produits à moindre coût et de bonne qualité.
Ceci est possible grâce à une gestion conséquente de stocks qui suppose l’existence
continue des produits en stock pour la satisfaction de la clientèle.
Quelle que soit son activité, sa taille et son organisation, l’entreprise a toujours
des stocks à gérer. A en croire Thierry LAVALLE, les stocks peuvent représenter 20
à 60% des actifs de l’entreprise. Ils engendrent un besoin important d’investissement
et immobilisent la trésorerie qui pourrait être consacrée au développement d’activités
rentables pour l’entreprise.
Il s’avère donc impérieux que les chefs d’entreprise mettent en place une meilleure
organisation pour une bonne gestion de leurs stocks. Mais malheureusement, les
difficultés trouvées lors de l’utilisation des outils mis en place pour la gestion des
stocks conduit à une mauvaise gestion des stocks.
L’ONCF n’est pas en marge de ces difficultés liées à la gestion des stocks et
en particulier les stocks bobines qui représentent des rouleaux de papier qui sert à
l’impression des billets de voyages. En effet, le projet SIV qui gère les services offerts
par l’ONCF à sa clientèle ne comporte pas cette gestion de stock. L’importance de ses
stocks bobines, ainsi que les besoins exprimés par l’ONCF en ce qui concerne le suivi
de la consommation des bobines ont inscrit notre projet de fin d’études effectué au sein
d’Algo Consulting Group dans le cadre de la ‘Mise en place du module de gestion
des stocks bobines du système d’information des voyageurs de l’ONCF’.

Pour mieux retracer les étapes et les objectifs de notre projet, le présent
mémoire est scindé en les parties suivantes :
Dans un premier lieu nous allons présenter l’entreprise accueillante, Algo

Consulting Group Rabat. Par la suite nous allons présenter le contexte métier du projet
SIV. Nous finirons cette partie par les méthodologies et les outils utilisés pour
l’élaboration du projet SIV.
En deuxième lieu, nous allons aborder la première partie de notre projet qui
concerne la gestion des stocks bobines, où nous allons détailler l’analyse fonctionnelle
du projet et sa mise en œuvre.
En troisième lieu, nous allons présenter la deuxième partie qui concerne la

vente des billets de voyage et des cartes d’abonnement, où nous allons étaler l’analyse
fonctionnelle et la conception détaillée de cette partie.
En dernier lieu, nous allons clôturer notre mémoire et présenter les références
Webographies, ainsi que les annexes représentant des informations complémentaires
sur les différents éléments traités dans le rapport.

Chapitre I : Contexte général
L’objectif de cette partie est de situer le stage de fin d’étude par rapport à
l’environnement global dans lequel le stage a été effectué. Nous présenterons
l’organisme d’accueil ensuite nous développerons le cadre général du projet SIV, en
évoquant les méthodologies utilisée tout au long de la période de notre projet.

I. Présentation de l’organisme d’accueil
1.1. Présentation d’Algo Consulting Group
Inspirée du mot « algorithme », Algo Consulting Group est une société
internationale de conseil en solutions informatiques. Créée en octobre 2007 et
domiciliée à Rabat, Algo travaille en sous-traitance avec Microsoft Nord d’Afrique
et East Méditerranée dans les projets stratégiques de leurs plus grands clients dans
la région.
Algo Consulting Group accompagne ses clients dans l’optimisation de leurs

performances organisationnelles grâce aux méthodes prouvées et perfectionnées à
travers l’expérience et l’expertise qu’offrent ses consultants, et ceux en se basant
sur les nouvelles technologies de l’information. Ainsi, l’équipe Algo, grâce à son
innovation, son engagement et son excellence technique, conçoit et met en œuvre
les meilleures des solutions technologiques adaptées à ses clients, afin de leur
donner un ample aperçu sur leur organisation, de contribuer à la résolution de leurs
problématiques inhérentes à la concrétisation de leurs missions et de les aider à
accroître leur performance.
Pôles d’activités :
Algo Consulting Group suggère de nombreux services à ses clients à savoir :
 Conseil et accompagnement en :
- Architecture et planification des systèmes d’entreprise
- Transformation et réalisation des projets informatiques
- Gouvernance des projets IT à travers les méthodologies modernes
- Audit et alignement stratégique de la technologie avec les
objectifs métiers
 Architecture, gestion de projet et développement d’applications
métier
- Gestion des cycles de vie des applications métier
- Atelier des développements sur TFS
- Etude et définition de la Roadmap des applications métier
- Modélisation SOA

 Optimisation de l’infrastructure
- Automatisation et optimisation du poste de travail
- Conception et consolidation des serveurs par la virtualisation
- Optimisation et solution de supervision et de gestion des
configurations
 Productivité et gestion de l’information
- Conception et développement de portails collaboratifs
d’entreprise
- Architecture et design des solutions de communication unifiées
 Solutions d’entreprise
- SGC solution pour la gestion des courriers
- SGF solution de gestion des Workflow
- eBanking solution des services bancaires à domicile
 Développement
- Conception et développement d’applications Web : Site web
interactifs, applications intranet/extranet
- Conception et déploiement de solutions : e-business, e-commerce,
e-gouvernement
1.2. Présentation de l’ONCF : Le client

L’Office national des chemins de fer (ONCF) est un établissement public
marocain chargé de l'exploitation du réseau ferroviaire du pays sous forme d'une
entreprise publique à caractère commercial et industriel avec autonomie financière,
il est créé en 1963 et placé sous la tutelle du ministère de l'équipement et du
transport.
1.3. Présentation d’Omnidata : Organisme validateur

Omnidata est née en 1989. Vingt ans après sa création, la société est considérée
aujourd'hui comme le fleuron du secteur des technologies de l'information au
Maroc. Omnidata a réussi, au fil de ces années, à consolider son leadership avec
une démarche de développement progressive des métiers des technologies de
l'information et une recherche permanente de valeur ajoutée. Elle est passée, ainsi,
de la distribution et support de produits au développement de systèmes spécifiques

puis à l’intégration de progiciels. L'année 2006 a marqué un tournant dans la vie de
l'entreprise à travers l’opération de fusion avec la société de service informatique et
d'ingénierie Cap'Info, autre leader des TI au Maroc. Premier fournisseur Marocain
en systèmes d'information, Omnidata est particulièrement active dans le secteur
public, le secteur financier et les télécommunications.
Rôle :
L’équipe Omnidata s’occupe de :
 La rédaction des spécifications exprimées par l’ONCF

 Validation de la conception réalisée par l’équipe LGV d’Algo
 Validation des livrables par rapport aux spécifications
II. Présentation du projet SIV

2.1. Approche générale sur le projet SIV
Le système de ventes à l’ONCF a subi plusieurs transitions, pour faciliter la

vente et adapter le système selon les besoins du service offert à la clientèle ONCF.
Le passage du billet en carton, aux appareils PZ9, à son premier logiciel SEAB vers
son système de vente actuel SABIL et aussi « Personnel Data Assistantes PDA »
pour les contrôleurs. SABIL a permis l’automatisation des services offerts par
l’ONCF mais a prouvé des faiblesses, pour y remédier l’ONCF a pensé à la mise
en place du Système d’Information des Voyageurs. Ci-dessous un tableau
comparatif entre quelques fonctionnalités dans le système actuel SABIL et le
nouveau SIV :
SABIL (système actuel) SIV

Un billet est comptabilisé mais non Billet émis (SMS, email)
émis
Pas de synchronisation du système Synchronisation du système avec
avec l’imprimante l’imprimante
Codage en dure Système générique
Tableau 1 : Tableau comparatif entre le système actuel SABIL et le SIV [13]

De plus le SIV a permis l’intégration des nouveaux services offerts par l’ONCF à
sa clientèle et plus précisément le LGV Tanger-Casablanca qui permettra
d’effectuer le trajet entre les deux métropoles en 2h10min au lieu de 5h45min.
La mise en œuvre du projet SIV est prévue selon plusieurs modules, le premier
module (module M1) étant une application desktop basé sur les services web, Le
deuxième (module M2) étant une version web et le troisième étant une version
mobile. Le schéma ci-dessous illustre les différents modules du projet :
Figure 1 : Schéma représentatif des modules du projet SIV
La livraison du premier module est effectuée, il reprend les services offerts

actuellement par le système SABIL tel que :
 La vente des billets de voyage.

 La vente des cartes d’abonnements.
 L’émission des billets.
Après avoir tester l’application il y avait des retours client (ONCF) qui concernent
la gestion des stocks bobines, la vente des billets de voyage et des cartes
d’abonnement sous-titre de complément M1.

2.2. Contexte du Complément M1 du projet SIV
Le projet SIV est mise en œuvre selon plusieurs modules, après avoir livré le
module M1, à notre arrivé il y avait des retours de la part de l’ONCF selon le tableau
ci-dessous :
Exigences Retour ONCF

Gestion stocks bobines Ces exigences ne sont pas
traitées
Vente des cartes d’abonnement Paramétrer une promotion ou
évolution sur les cartes
Vente des billets de voyage Emettre un billet via un canal de
distribution (SMS, EMAIL…)
Vente des billets de voyage pour un voyage Vendre un billet de voyage pour
grand group un groupe de personnes
Tableau 2 : Tableau représentatif des retours de l'ONCF sur le module 1 du SIV
Ces retours seront traités en complément du module M1 du SIV durant notre

période de stage au sein de l’entreprise. Ce complément traitera deux sous modules
très important :
Gestion stocks bobines :
Ce complément concerne la gestion des stocks bobines, ce sont des roulons de

papier permettant l’impression des billets de voyages. Cette gestion permettra un
suivi régulier des stocks bobines sur trois niveaux :
 Etablissement : représente les établissements responsables de l’ensemble

des gares au Maroc, il y a deux, établissement du nord regroupe les gares
d’Oujda à Rabat centre-ville et établissement du sud regroupe les gares de
Casablanca au sud du Maroc.
 Gares : représente l’ensemble des gares du pays.
 Postes de vente : représente les différents guichets de vente des billets de
voyage.

Vente :
Ce complément concerne les services offerts par l’ONCF à sa clientèle et plus

particulièrement les services de vente des billets de voyage et des cartes
d’abonnement :
 Au niveau de la vente des cartes d’abonnement, il envisage de pouvoir

appliquer des promotions ou des évolutions sur les prix de vente des cartes
d’abonnements.
 Au niveau de la vente des billets de voyage, il envisage de pouvoir émettre
le billet par SMS ou email ainsi que de vendre des billets de voyage pour un
groupe de plus de vingt-cinq personnes.
III. Pilotage et conduite du projet SIV

3.1. Gestion de projet : Scrum
Après avoir intégré l’équipe LGV et les éclaircissements fournis par les
membres de l’équipe pendant les réunions, nous étions menés à adopter la
méthodologie « Scrum » pour la gestion de projet, par ce que nous avons eu besoin
d’une méthode intégrant à la fois une possibilité de réponse très adapté vis-à-vis du
client, réactive, et s’adaptant aussi à notre contexte d’équipe. Alors « Scrum » nous
parait la solution idéale pour produire des applications puisque dans les
méthodologies traditionnelles, le développeur répond aux besoins exprimés par le
chef de projet qui « détient le savoir » et la prise de décision. Il se considère comme
un exécutant, ce qui n’est nullement le cas dans notre projet. En effet, si le cahier
de charge reçu était incomplet et regroupait un ensemble d’incohérences, ceci
imposerait une communication continuelle avec le product owner et une validation
fréquente des incréments.
Ainsi, au lieu de fixer les objectifs lointains, le mieux serait de procéder par
étapes, c’est-à-dire fixer des objectifs à court terme et de commencer le
développement sans perdre de temps. Chaque fois que cet objectif est atteint, nous
passons au suivant et ainsi de suite jusqu’à ce que le but ultime soit atteint.
Ceci nous a permis de construire une certaine agilité au niveau de notre projet,
et aussi la mise en place de certaines valeurs agiles comme :

 Favoriser les individus et les interactions plutôt que les processus et les outils
 Avoir un produit qui fonctionne plutôt qu’une documentation exhaustive
 Collaborer avec le client plutôt que la contractualiser les relations
 Accepter le changement plutôt que la conformité aux plans
Pour toutes les raisons citées précédemment « Scrum » y répond et nous a permis
aussi d’avoir une bonne réactivité et une flexibilité aux changements des exigences.
3.2. Cycle de développement : Semi-itératif et incrémental

Toutes les méthodes agiles débutent par des phases séquentielles, courtes mais
bien réelles, d’exploration, d’architecture et de planning. Un usage totalement
itératif de ces méthodes n’est cependant pas exclu mais ne peut s’appliquer qu’à
de très petits projets.
Semi-itératif Itératif Séquentiel

complet
Besoins Peu clairs, instables, Stables mais Clairs et
mouvants certaines stables
exigences sont
floues
Planning/Délai Impératif de mise en > 6 mois < 5 mois
production rapide
Charges du projet Conseillé si > 400 JH Conseillé si > Déconseillé
Obligatoire si > 1500 400 JH si > 400 JH
JH
Risques Risques élevés Risques élevés Peu de
techniquement et sur le risques
fonctionnellement fonctionnel et
le technique de
l’application
Disponibilité du Très forte implication Forte Faible
client du client tout au long implication du implication
du projet client tout au du client
long du projet
Tableau 3 : Comparaison entre les différents cycles de vie [1]

Afin de pouvoir prendre une décision réfléchie, nous avons comparé les
différents types de cycle de vie existants. Le cycle de vie séquentiel a représenté
une grande incohérence avec nos besoins en vue de sa rigidité et la nécessité d’avoir
des exigences stables et clairs, ce qui n’est nullement notre cas. Le cycle itératif
complet ressemble au cycle semi-itératif sur plusieurs niveaux mais nécessite aussi
un certain degré de stabilité des exigences. Le cycle semi itératif, quant à lui, donne
plus de flexibilité sur la revue et la modification des exigences. La validation des
exigences se fait fréquemment et si nécessaire la conception doit être refaite à
chaque début d’itération. Dans notre cas, par fois nous avons trouvé quelques
difficultés en ce qui concerne les allers retours réguliers vers le client, mais vers la
fin le client a pu comprendre la nécessité et la complexité des exigences exprimées,
du point de vu métier.
Les livraisons sont faites chaque deux semaines le vendredi matin avant la
revue d’équipe qui se fait l’après-midi. Il y a des livraisons partielles, chaque mi-
sprint pour avoir un suivi régulier de l’état d’avancement de la réalisation.
Durant la phase de construction, chaque itération est passée par le processus

ci-dessous :
Figure 2 : Processus de développement itératif [2]

Les avantages de ce cycle sont :
 La possibilité de mettre en production au fur et à mesure de la production.

 Une visibilité fréquente sur l’avancement.
 La réduction des risques techniques en amont.
Conclusion
Dans ce chapitre nous avons présenté l’organisme d’accueil dans lequel nous
avons effectué notre stage de fin d’études, puis nous avons introduit le contexte du
projet sur lequel nous avons travaillé, tout en expliquant les méthodologies et la
planification adoptée. La partie qui suit sera consacrée à notre première réalisation
durant notre stage.

Chapitre II : Gestion des stocks
bobines
Notre stage de fin d’étude a connu deux réalisations principales. La première
concerne le Complément M1 – Gestion des stocks bobines, il comprend la conception
et la réalisation. La deuxième concerne le Complément M1 – Vente des billets de
voyage et des cartes d’abonnement, il comprend la conception. Cette partie sera
consacrée à notre première réalisation durant notre stage de fin d’étude, nous allons
l’étaler sur deux volets :
 Le premier volet présente l’étude et l’analyse fonctionnelle du projet.

 Le deuxième volet présente la mise en œuvre du projet.

Etant un binôme pour réaliser le projet nous avons opté pour nous organiser la
méthode XP. Les principes de cette méthode ne sont pas nouveaux, ils existent dans
l’industrie du logiciel depuis des dizaines d’années et dans les méthodes de
management depuis encore plus longtemps. En effet, il s’agit de la communication, la
simplicité, le feed-back, le courage et le respect. Pour nous, nous avons utilisé les
pratiques suivantes :
 La communication : via les tests croisés que nous élaborons à chaque

livraison et lorsqu’on a une contrainte ou les spécifications nécessitent plus
de détails.
 La simplicité : nous cherchons toujours la façon la plus simple pour arriver
aux résultats.
 Le courage : Parfois, nous avons jeté le code pour produire un meilleur ou
essayer une nouvelle façon de faire.
I. Etude et analyse fonctionnelle du projet

1.1. Cahier de charges
Après avoir étudier le module M1 du projet SIV et l’ensemble des retours
fournit par l’ONCF (voir Annexe A) en vue d’une gestion des stock bobines, qui
n’existe pas dans le système SIV, nous avons pu élaborer le cahier de charges
suivant :
 BackOffice : à ce niveau, il faut avoir une partie du système qui permettra aux
administrateurs fonctionnels de :
o Commander des bobines.
o Confirmer la livraison des bobines.
o Consulter l’ensemble des commandes existants
o Consulter la consommation des bobines.
 FrontOffice : à ce niveau il faudra une partie permettant d’avoir un suivi des
vendeurs au niveau des différents guichet, ce niveau permettra à un vendeur
de :
o Saisir la bobine de prise de service.
o Saisir la bobine de fin de service.
o Changer la bobine.

Pour la saisie de la bobine, il s’agit de la saisie d’un numéro de série imprimé
au verso du billet de voyage, pour avoir plus de détail voire l’annexe B.
Notre étude nous a permis aussi d’identifier l’ensemble des entités externes
(utilisateur humain, dispositif matériel ou autre système) qui vont interagir avec
notre système qui permettra la gestion des stocks des bobines. Ils sont de deux
natures administratives différentes :
 Les administrateurs fonctionnels ou chefs de gares : ce sont les seuls qui

s’occuperons de la partie BackOffice (commander des bobines, confirmer la
livraison, consulter les commandes et consulter la consommation des bobines).
 Les vendeurs : ce sont les seuls qui s’occuperons de la partie FrontOffice (saisir
la bobine de prise de service, saisir la bobine de fin de service et changer la
bobine).
Tous ces résultats nous ont menés à avoir une idée approfondie de ce que demande
le client et de concevoir le système. Pour avoir plus de détails sur les scénarios
métier des deux parties Front et Backoffice Consulter l’annexe
1.2. Conception comportementale

Ce titre nous permettra d’entamer deux volets dans la conception
comportementale, cette conception permet de détailler le comportement de notre
système. Le premier volet sert à identifier l’ensemble des séquences d’actions
réalisées par le système et produisant un résultat observable intéressant pour un
utilisateur particulier. Le deuxième détaillera l’état du système selon chaque action
effectuée par l’utilisateur.
Volet 1 : Identification des cas d’utilisation
Les cas d’utilisation du Complément M1 – Gestion des stocks bobines se

différencie selon les spécifications métier en deux grandes parties, une partie de
gestion des stocks bobines backOffice et une partie frontOffice :
Partie gestion des stocks bobines backOffice :
Le diagramme de cas d’utilisation suivant présente les principales actions du

Complément M1 du SIV qui concerne la commande des bobines, la confirmation

de livraison, la consultation des commandes et le suivi de la consommation des
bobines c’est-à-dire la partie backOffice du Complément M1 – Gestion des stock
bobines :
Figure 3 : Diagramme de cas d'utilisation gestion des stocks bobines backOffice
Un utilisateur et plus particulièrement un administrateur fonctionnel chez

ONCF pourra :
 Commander des bobines

 Modifier une commande
 Confirmer la livraison des bobines
 Rechercher les commandes ou livraison
 Consulter l’ensemble des commandes et livraisons

 Consulter la consommation d’un établissement
 Consulter la consommation d’une gare
 Consulter la consommation d’un poste de vente
Ces tâches nécessitent l’authentification de l’utilisateur dans le système et avoir

les droits pour accéder à ces éléments.
Partie gestion des stocks bobines frontOffice :
Le diagramme de cas d’utilisation suivant présente les principales actions du

Complément M1 du SIV qui concerne la prise de service, la fin de service et le
changement des bobines c’est-à-dire la partie frontOffice du Complément M1 –
Gestion des stocks bobines :
Figure 4 : Diagramme de cas d'utilisation gestion des stocks bobines frontOffice
Un utilisateur et plus particulièrement un vendeur de billets pourra :
 Effectuer la prise de service

 Effectuer la fin de service
 Changer la bobine
Volet 2 : Diagramme d’activité
Après avoir étudier les spécifications fournis par l’ONCF, nous avons trouvé
plusieurs scénarios d’exception, pour avoir une idée plus claire nous avons élaborer
les diagrammes d’activités selon les cas d’utilisation qui sont plus compliqués et
provoquant plusieurs exceptions.

Diagramme d’activité des états d’une commande
Le diagramme d’activité dans la figure qui suit, représente les étapes d’une
commande, en partant de la saisie de la saisie d’une commande et arrivant à la
confirmation de livraison, suivi de la création des bobines commandées.
Figure 5 : Diagramme d'activité des états d'une commande
Le diagramme ci-dessus présente les états d’une commande dès son

déclenchement jusqu’à sa confirmation par un administrateur fonctionnel. Une
commande passe séquentiellement par les états suivants :
 Un administrateur fonctionnel commande des bobines

 Le système vérifie les références qui font l’objet de la commande, s’il y a
chevauchement des références ou si les références font l’objet d’une autre
commande le système demande une correction des références. Lorsque les
entrées sont correctes dès la première fois, nous passons à l’étape suivante.
 Le système enregistre les données de la commande

 Lorsque les bobines sont reçues, un administrateur fonctionnel confirme la
livraison. Le système enregistre les données de livraison et crée les bobines
qui font l’objet de la commande qui vient d’être confirmée.
Diagramme d’activité d’une opération service
Le diagramme d’activité suivant présente une opération service, il s’agit de

l’une des trois opérations : une prise de service, un changement de bobine ou une
fin de service. On note que ce traitement s’effectue deux fois lors d’un changement
de bobine.
Figure 6 : Diagramme d'activité d'une opération service
Le diagramme ci-dessus représente le séquencement des états du système lors

d’une opération service. Nous allons détailler ses états dans ce qui suit :

 A son arrivé le vendeur imprime un billet de prise de service.
 Saisi le numéro de série de la bobine au niveau de l’application.
 Si la référence saisi est celle imprimée, le vendeur passe à la vente, si non
une alerte est affichée pour corriger les informations saisies, si le vendeur
corrige les informations ou valide l’opération, il passe à la vente.
1.3. Conception structurelle

Dans cette partie nous allons entamer la conception structurelle qui permettra
de détailler les séquences de messages échangés entre les différents composants du
système. Nous allons traiter deux volets de cette conception, le premier volet
concerne les diagrammes de séquences, à ce niveau nous allons présenter le
diagramme de séquences qui concerne le séquencement des messages pour
effectuer une commande pour la partie backOffice, la prise de service dans la partie
frontOffice. La suite des diagrammes de séquences fait l’objet de l’annexe C. Le
deuxième volet représentera le diagramme de classe.
Diagramme de séquence d’une commande
Le diagramme de séquence qui suit présente les séquences de messages

échangés pour effectuer une commande :

Figure 7 : Diagramme de séquence cas d'une commande
Le diagramme de séquence (figure : 9) illustre la commande et la livraison des

bobines par ce qu’il y a un lien fort entre la commande et la livraison des bobines.
 Administrateur fonctionnel : présente un responsable de l’établissement

central de l’ONCF qui parmi ses missions il peut effectuer des commandes
des bobines.
 Interface WPF : présente l’interface pour la saisie du bon de commande.
 Commande : présente la commande effectuée par l’utilisateur selon les
critères saisit par ce dernier au niveau de l’interface utilisateur.
 Livraison : présente la confirmation de livraison après vérification du stock
physique et l’obtention des bobines commandées.
 Bobine : présente les bobines reçu et existant au niveau du stock.
 Système : présente le système SIV.

Diagramme de séquence pour la prise de service
Le diagramme de séquences ci-dessous présente la séquence des messages

échangés pour effectuer une prise de service.
Figure 8 : Diagramme de séquence pour une prise de service

Pour pouvoir effectuer une prise de service par un vendeur, l’interaction des
éléments suivants est nécessaire :
 Vendeur : présente le vendeur qui vient d’entamer son travail.

 Interface WPF : présente l’interface de prise de service.
 Système : le système SIV notamment les services web.
 Popup wpf : présente une vérification de la référence saisie par le vendeur
avec celle de la bobine actuelle.
Diagramme de classes
Après avoir extrait à partir des diagrammes de séquences, les éléments qui
répondent aux cas d’utilisation, nous avons élaborer le diagramme de séquence
suivant :
Figure 9 : Diagramme de classes - Gestion des stocks bobines

II. Mise en œuvre du projet
2.1. Architecture du projet : Design Pattern MVVM
L’architecture présentée ici est c’elle adoptée par l’équipe développement chez
Algo pour la réalisation du projet SIV. En effet il s’agit d’une architecture client-
serveur. La vision de cette architecture est d’avoir un produit évolutif, rapidement
adaptable et maintenable. L’architecture la plus adaptée et qui a permis d’arriver à
ces résultats est l’architecture SOA, qui se base sur la notion des services.
Service :
Un service est une fonction encapsulée dans un composant que l’on peut
interroger à l’aide d’une requête composée d’un ou plusieurs paramètres et
fournissant une ou plusieurs réponses. Idéalement chaque service doit être
indépendant des autres afin de garantir sa réutilisabilité et son interopérabilité.
Un service est une entité de traitement qui respecte un ensemble de caractéristiques

dont les plus importants :
- Description : Consistant à décrire les paramètres d’entrée du service et le

format et le type des données retournées. Le principal format de description
de services est WSDL, normalisé par le W3C.
- Large Granularité : Les opérations proposées par un service encapsulent
plusieurs fonctions et opèrent sur un périmètre de données large au
contraire de la notion de composant technique.
- Localisable : Avant d’appeler un service, il faudra le trouver.
- Couplage faible : Les services sont connectés aux clients et autres services
via des standards. Ces standards assurent le découplage, c'est-à-dire la
réduction des dépendances. Ces standards sont des documents XML
comme dans les web services.

Service Oriented Architecture :
Il n’existe pas à proprement parler de spécifications officiels d’une architecture

SOA, néanmoins les principales notions fédératrices ne changent pas : la notion du
service, la description, la publication, la découverte (objet du premier titre de cette
section).
En ce qui concerne le projet SIV, l’architecture SOA est implémentée comme suit:
Figure 10 : Architecture du projet SIV [3]
Le projet SIV se décompose en cinq couches principales :
 La couche client UI : l’interface de présentation et la logique de

présentation qui respectera le patron de conception MVVM
 La couche client comportant :
- Les entités métier côté client : composé des objets métiers partie client
- Le contrat : contient une signature du service
- Le proxy : constitue un tube de communication avec la couche métier
 La couche métier comportant :
- Les entités métier côté métier : composé des objets métier partie métier
- Le contrat : contient une signature du service

- Le manager : constitue un canal de communication avec la couche
accès aux données
 La couche accès aux données comportant :
- Le framework EntityFramework de persistance
- L’interface : contient la signature des services
- Le dépôt (Repository) : contient l’implémentation du service
 La couche donnée : Utilisant le SGBD SQL server.
Patron de conception MVVM :
Dans la série des design patterns, il existe MVVM (Model View ViewModel,
ce qui veut dire Modèle Vue Vue-Modèle en français). Ce pattern a spécialement
été conçu pour améliorer la séparation entre les données et la vue qui les affichent.
Le lien entre la vue et le modèle de données est fait par des mécanismes de binding.
Le binding est un mécanisme qui permet de faire des liaisons entre des données de
manière dynamiques. Ce qui veut dire que si A et B sont liés, le fait de modifier A
va être répercuté sur B et inversement.
Architecture MVVM :
La figure ci-dessous représente l’architecture interne du patron de conception

MVVM :
Figure 11 : Architecture MVVM [7]

Voyons de plus près ce que contient MVVM :
- Modèle : le modèle contient les données. Généralement, ces données

proviennent d’une base de données ou d’un service externe comme un
API.
- Vue : la vue correspond à ce qui est affiché. La vue contient les différents
composants graphiques (boutons, liens, listes) ainsi que le texte.
- Vue-Modèle : ce composant fait le lien entre le modèle et la vue. Il
s’occupe de gérer les liaisons de données et les éventuelles conversions.
C’est ici qu’intervient le binding.
2.2. Technologies et outils utilisés
 Visual Studio 2015 [4] :
Microsoft Visual Studio 2015 est une suite d'outils permettant de créer des
logiciels, qui couvre la phase de planification, la conception de l'interface
utilisateur, par le codage, le test, le débogage, l'analyse de la qualité et de la
performance du code, le déploiement sur les clients et la collecte de la télémétrie
sur l'utilisation. Ces outils sont conçus pour fonctionner ensemble avec la meilleure
intégration possible et sont tous exposés via l'environnement de développement
intégré (IDE) de Visual Studio.
 SQL server Management Studio 2012 [5] :
SSMS est une application utilisée pour la configuration, la gestion et

l’administration de tous les composants dans Microsoft SQL Server. L’outil
comprend deux éditeurs de script et des outils graphiques pour interagir avec les
objets et les fonctionnalités du serveur.
 TFS [5] :
Team Foundation Server est une forge logicielle éditée par Microsoft
permettant la gestion des sources, la gestion des builds, le suivi des éléments de
travail, la planification, la gestion de projet et l’analyse des performances. Il a pour

but d’augmenter la productivité des développeurs, lesquels doivent utiliser la suite
visual studio system.
 Telerik :
Bibliothèque payante, qui offre des outils de développement riches pour les
applications web, mobiles, desktop.
 WPF [11] :
Windows Presentation Foundation est un système de présentation nouvelle

génération qui génère des applications clientes windows. Le cœur de WPF est un
moteur de rendu vectoriel et indépendant de toute résolution, crée pour tirer parti
du matériel graphique moderne. WPF étend le cœur avec un jeu complet de
fonctionnalités de développement d'applications qui incluent Extensible
Application Markup Language (XAML), des contrôles, la liaison de données et la
disposition ainsi que des graphiques 2-D et 3-D, l'animation, les styles, les modèles,
les documents, les médias, le texte et la typographie. WPF est inclus dans le
Microsoft .NET Framework, vous pouvez donc générer des applications intégrant
d'autres éléments de la bibliothèque de classes .NET Framework.
 XAML [11] :
C’est un langage déclaratif développé pour les besoins des systèmes

d’exploitation de Microsoft, Windows Vista, Windows 7 et Windows 8 et qui
permet la description de données structurées. Ainsi qu’il permet de construire des
interfaces riches dans WPF.
 WCF [12] :
Windows Communication Foundation est la nouvelle couche de communication

du framework .NET 3.0. Cette couche a été créée afin d’unifier les différents
modèles d’écritures d’applications ‘communicantes’.
Afin que les applications puissent communiquer, il faut qu’un certain nombre de
contraintes soient respectées :
- Définir les méthodes exposées par le serveur ;
- Définir les types de données transmissibles entre applications ;

- Définir l’ABC de la communication :
 A pour Adresse : définit l’adresse du serveur qui expose le service
 B pour Binding : définit la façon dont le service sera exposé.
 C pour Contrat : définit le contrat que le service remplit
 Linq [10] :
Une requête est une expression qui récupère des données d'une source de
données. En général, les requêtes sont exprimées dans un langage de requête
spécialisé. Au fil du temps, différents langages ont été développés pour les divers
types de sources de données, par exemple, SQL pour les bases de données
relationnelles et XQuery pour le XML. Par conséquent, les développeurs ont dû
apprendre un nouveau langage de requête pour chaque type de source de données
ou format de données qu'ils doivent prendre en charge. LINQ simplifie cette
situation en proposant un modèle cohérent qui permet d'utiliser des données de
types de sources et de formats divers. Dans une requête LINQ, vous travaillez
toujours avec des objets. Vous utilisez les mêmes modèles de codage de base pour
interroger et transformer des données en documents XML, en bases de données
SQL, en groupes de données ADO.NET, en collections .NET et en tout autre format
pour lesquels un fournisseur LINQ est disponible.
 Entity Framework [9] :
Entity Framework est un mappeur objet/relationnel qui permet aux
développeurs .NET d'utiliser des données relationnelles à l'aide d'objets spécifiques
au domaine. Il rend inutile la plupart du code d'accès aux données que les
développeurs doivent généralement écrire.
 MEF [8] :
Le Managed Extensibility Framwork simplifie la création d’applications
extensibles. MEF propose une solution simple au problème d’extensibilité lors de
l’exécution. Jusqu’à présent, les applications voulant implémenter un modèle de
plugins devaient créer leur propre infrastructure. Ces plugins étaient souvent
spécifiques à l’application et ne pouvaient donc être réutilisés dans d’autres
applications.
- MEF fournit une approche standard, dans laquelle l’application hôte s’expose
elle-même et consomme des modules externes. De par leur nature, les modules

ou extensions peuvent être réutilisés dans différentes applications. Toutefois,
une extension pourra être utilisée de façon spécifique par chaque application.
Les extensions peuvent également dépendre les unes des autres et MEF
s’assurera qu’elles soient connectées entre elles dans le bon ordre ;
- MEF offre plusieurs approches de découverte afin que l’application localise
et charge les extensions disponibles ;
- MEF permet d’ajouter des informations supplémentaires (métadonnées) aux
extensions, facilitant ainsi le filtrage et la recherche.
2.3. Réalisation
Dans ce qui suit nous allons entamer nos réalisations pour le Complément M1
- Gestion stocks bobines. Nous avons utilisé Scrum pour la gestion de projet et un
cycle de vie semi-itératif et incrémental. Pour brancher nos réalisations avec
l’existant, nous avons essayé d’élaborer une conception qui n’influence pas cet
existant en tant que base.
Cette partie s’est étaler sur trois itérations, les deux premières itérations sont
de deux sprints chacune et la troisième d’un seul sprint, chaque sprint est d’une
durée de deux semaines. Nous allons présenter nos réalisations selon chaque
itération.
Itération 1 : Préparation de l’environnement
Le travail effectué lors de cette itération avait pour objectif l’étude de l’existant
de la conception globale du projet SIV, la montée en compétence et en autonomie
du développement en suivant l’architecture du projet SIV, ainsi que la conception
du complément M1 – Gestion des stocks bobines. Pour ce faire nous avons pris le
temps de se documenter, d’étudier l’architecture du projet SIV, étudier la
conception des éléments en relation avec ce Complément et de faire des premiers
essaies d’implémentation, ceci nous a permis d’avoir une idée plus précise des
différents composants du SIV et la communication entre ses éléments.
L’étude de l’existant consiste à connaitre tous les éléments du projet SIV, à

savoir le côté fonctionnel de l’application, son architecture ainsi que les
technologies utilisées pour la mise en œuvre de ces éléments.

Cette itération nous a pris une période de deux sprints ouvrables, vue la
complexité et la diversité des composants du projet SIV, ainsi que le défi d’intégrer
notre conception dans l’existant. Il s’agit de la première itération.
Itération 2 : mise en œuvre
Nous avons consacré cette partie à la mise en œuvre du Complément M1 –
Gestion des stocks bobines. Cette itération nous a pris une période de deux sprints
ouvrables c’est la deuxième itération.Nous avons pu répondre aux exigences et
livrer à temps le produit. Nos réalisations s’énumèrent comme suit :
Partie backOffice :
Un administrateur fonctionnel pourra :
1) Gérer les commandes effectuées (effectuer une commande, confirmer une
livraison et consulter l’état de la commande), comme montre la figure ci-
dessous :
Figure 12 : Interface de gestion des commandes
L’interface contient un :
 Bouton Rechercher : sert à consulter les commandes.

 Bouton Ajouter bon de commande : sert à créer une commande.
 Bouton avec signe + : sert à confirmer une livraison.
 Bouton avec signe stylo : sert à modifier une commande.
 Bouton avec signe de consultation : consulter l’état de la commande.

Nous avons consacré l’annexe D partie backOffice aux détails des réalisations
effectuées pour la gestion des commandes. Par ce que l’interface dans la figure 14
regroupe plusieurs réalisations et chacun des boutons décrits ci-dessus renvoi vers
un résultat précis.
2) Suivre les détails de consommation des bobines, ces détails sont regroupés dans
l’interface suivante :
Figure 13 : Interface de suivi de la consommation des bobines
Cette interface permet la consultation de la consommation sur trois niveaux :
 Etablissement, gare, poste de vente et par vendeur.

 Gare, poste de vente et vendeur.
 Poste de vente et vendeur.
Nous avons consacré l’annexe D partie frontOffice aux détails des réalisations
effectuées pour la consultation de la consommation des bobines. Par ce que
l’interface ci-dessus regroupe plusieurs réalisations.

Partie frontOffice :
Un vendeur pourra :
1) Mentionner sa prise de service, ceci via l’impression d’un billet de prise de

service qui se fait à partir du pop-up dans la figure suivante :
Figure 14 : pop-up prise de service
2) Changer la bobine d’impression des billets, en imprimant un billet de

changement de bobine ceci via le pop-up suivant :
Figure 15 : Pop-up changement de bobine

3) Terminer son service, en imprimant un billet de fin de service via le pop-up de
fin de service :
Figure 16 : Pop-up de fin de service
2.4. Livraison
Pour la mise en œuvre du Complément M1 – Gestion des stocks bobines du
SIV il y avait plusieurs allers-retours selon chaque phase de réalisation durant
chaque sprint.
Pour la première livraison, nous avons élaboré la partie de gestion de
commandes, nous avons livré l’application à l’équipe de tests qui nous a remonté
des anomalies à savoir : un utilisateur peut livrer une commande avec une date de
livraison inférieure à la date de commande et de limiter le nombre d’affichage
lorsque nous effectuons une recherche des commandes.
La deuxième livraison comportait la correction des anomalies de la parie
gestion de commandes remontées précédemment et ainsi que livraison de
l’intégration de la partie consultation de la consommation des bobines. L’équipe de
tests déroule les tests de non régression ainsi que les tests unitaires pour la nouvelle
partie. L’équipe nous a remonté des anomalies qui feront l’objet de correction dans
le sprint suivant.
La dernière livraison pour l’équipe de tests contenait la correction des
anomalies précédentes ainsi que l’intégration de la partie responsable de la gestion
de la prise de services.

Enfin de ce sprint et après avoir corriger les anomalies et les tests effectués le
produit comportant toutes les fonctionnalités est livré à Omnidata. Le produit était
validé respectant toutes les fonctionnalités et contraintes exigées par le client, mais
il y avait des retours à propos de l’interface de la consultation de la consommation
des bobines.
La dernière livraison, contenait une refonte de l’interface de la consommation
des bobines ainsi que la partie changement des bobines et la fin de service.
Après avoir tester les résultats par les testeurs d’Algo, nous avons livré à
Omnidata ces résultats et l’application complète après ajout du module de gestion
du stock bobines.
Notre réalisation est validée de la part d’Omnidata et est livré au client pour
avoir ses retours.
Contraintes
Pour cette partie de la réalisation nous avons trouvé deux contraintes majeures.
La première lorsque l’utilisateur consulte les commandes il aura toujours la totalité
des commandes enregistrées, ce qui a causé des problèmes de performances et de
temps de réponse. La deuxième lors du changement d’une bobine, il faudra
contrôler ce changement par des conditions bien précises. Il s’agit de la troisième
itération et est durée pendant un sprint.
Solutions :
Nous avons pu répondre à ces contraintes par deux solutions selon chaque
contrainte :
Solution pour la contrainte de consultation :
Vue les contraintes citées avant, nous avons prévu un filtre de recherche pour
pouvoir contrôler la recherche selon le choix utilisateur.
Figure 17 : illustration du filtre de recherche

Le filtre de contrôle pour la recherche propose comme options :
 En cours : permet de consulter les commandes courantes.

 Livrée : permet de consulter les commandes livrées.
 Toutes les commandes : permet de consulter l’ensemble des
commandes.
Solution pour la contrainte de changement de bobine :
Vu le problème cité avant nous avons prévu un contrôle lors du changement de

bobine. Ceci n’est permis que dans les cas suivants :
 Le changement de bobine est possible quand l’alerte illustrée dans la figure :

28 informe le vendeur que le nombre de billet restants au niveau d’une bobine
est inférieur à un nombre paramétrable par un administrateur fonctionnel.
 Le changement de bobine est obligatoire dès qu’il reste un seul billet au niveau
de la bobine.
Figure 18 : interface illustrant l'alerte de changement de bobine

Conclusion
Dans cette partie nous avons présenté notre étude et analyse du projet, en
partant du cahier de charges arrivant vers la conception structurelle. Puis, nous avons
étaler notre mise en œuvre du projet en détaillant l’architecture du projet SIV, ainsi
que l’ensemble des livraisons élaborées. La partie suivante concernera notre deuxième
réalisation durant notre stage de fin d’étude.

Chapitre III : Vente des billets de
voyage et des cartes d’abonnement
Notre stage de fin d’étude a connu deux réalisations principales. La première
concerne le Complément M1 – Gestion des stocks bobines, il comprend la conception
et la réalisation. La deuxième concerne le Complément M1 – Vente des billets de
voyage et des cartes d’abonnement, il comprend la conception. Cette partie sera
consacrée à notre deuxième réalisation durant notre stage de fin d’étude, nous allons
l’étaler sur deux volets :
 Le premier volet présente l’étude et l’analyse fonctionnelle.

 Le deuxième volet présente la mise en œuvre.

Etant un binôme pour réaliser le projet nous avons opté pour nous organiser la
méthode XP. Les principes de cette méthode ne sont pas nouveaux, ils existent dans
l’industrie du logiciel depuis des dizaines d’années et dans les méthodes de
management depuis encore plus longtemps. En effet, il s’agit de la communication, la
simplicité, le feed-back, le courage et le respect. Pour nous, nous avons utilisé les
pratiques suivantes :
 La communication : via les tests croisés que nous élaborons à chaque

livraison et lorsqu’on a une contrainte ou les spécifications nécessitent plus
de détails.
 La simplicité : nous cherchons toujours la façon la plus simple pour arriver
aux résultats.
 Le courage : Parfois, nous avons jeté le code pour produire un meilleur ou
essayer une nouvelle façon de faire.
I. Etude et Analyse fonctionnelle

1.1. Etude de l’existant
Comme nous avons présenté dans la partie présentation du projet SIV, la mise
en œuvre de ce projet est prévue selon trois modules (le module M1, le module M2
et le module M3) (voir Figure 19). Le module M1 qui est une application desktop
qui permet de gérer l’ensemble des services offerts par l’ONCF à sa clientèle. Ce
module est livré et est en phase des retours clients, il est constitué de deux volets :
 BackOffice, ce volet concerne les administrateurs fonctionnels chez l’ONCF

et permet de gérer l’ensemble des services offerts par l’ONCF à sa clientèle
tels que :
° les tarif : permet une gestion des tarif proposés par l’ONCF (exemple : tarif
CHABAB, COUCHETTE …).
° les carte d’abonnement : permet une gestion des cartes d’abonnements (ajout,
suppression, affectation des cartes au clients, rejet de cartes…).
 FrontOffice, ce volet concerne les vendeurs au niveau des guichets dans les
gares, ou des guichets alternatifs nommés poste de vente que chacun est affecté
à une gare et permet de :

o Vendre des billets de voyages selon les critères fourni par le voyageur
(Exemple : première classe, à côté des vitres et prise électrique).
o Vendre les cartes d’abonnements.
o Vente de billets petits groups (nombre de voyageurs inférieur à 25
personnes).
1.2. Cahier de charges

Après avoir étudier le module M1 du projet SIV et l’ensemble des retours fourni
par l’ONCF à propos de la Vente comme illustre le tableau suivant :
Exigences Retour ONCF

Vente des cartes Paramétrer une promotion ou
évolution sur les cartes
Vente des billets de voyage Emettre un billet via un canal de
distribution (SMS, EMAIL…)
Vente des billets de voyage pour un voyage Vendre un billet de voyage pour
grand group un groupe de personnes
Tableau 4 : Tableau des retours ONCF Vente
Nous avons étudié l’existant dans la version actuelle du projet SIV pour ces
éléments de la Vente, cette étude nous a permis d’élaborer le cahier de charge
suivant :
 BackOffice : à ce niveau, il faut avoir une partie du système qui permettra aux
administrateurs fonctionnels de :
o Paramétrer une offre promotionnelle sur les prix des cartes
d’abonnement.
o Appliquer la promotion sur les prix des cartes d’abonnement.
o Annuler la promotion sur les prix des cartes d’abonnement.
o Paramétrer une évolution sur les prix des cartes d’abonnement.
o Appliquer l’évolution sur les prix des cartes.
 FrontOffice : à ce niveau il faudra une partie offrant plus d’options pour la
vente des billets de voyage, ce niveau permettra à un vendeur de :

o Emettre un billet acheter sur un autre canal (Distributeur de Tickets
Automatique, achat d’un billet en ligne) par SMS ou email. Appliquer
l’évolution sur les prix des cartes d’abonnement
o Vendre un billet avec un tarif pour client fidèle.
o Percevoir le paiement d’une contravention suite à un accident au bord
du train.
o Effectuer la vente d’un voyage grand groupe (groupe de plus de 25
personne).
o Annuler une demande de voyage grand groupe.
o Modifier la taille d’un type de groupe (petit groupe, moyen groupe et
grand groupe).
II. Mise en œuvre

Dans ce qui suit nous allons entamer nos réalisations pour le Complément M1 -
Gestion stocks bobines. Nous avons utilisé Scrum pour la gestion de projet et un cycle
de vie semi-itératif et incrémental. Pour brancher nos réalisations avec l’existant, nous
avons essayé d’élaborer une conception qui n’influence pas cet existant en tant que
base.
Cette partie s’est étaler sur une itération de deux sprints, chaque sprint est d’une
durée de deux semaines. Ses résultats sont par rapport la conception du Complément
M1 – Vente des billets de voyage et des cartes d’abonnement. Nous avons livré la
conception que nous avons prévu pour ce complément et est en phase de validation par
les analystes Omnidata.
2.1. Conception comportementale

Les cas d’utilisation du Complément M1 – Vente des billets de voyage et des
cartes d’abonnement se différencie selon les spécifications métier en deux grandes
parties, une partie backOffice et une partie frontOffice :
Partie backOffice :
Actuellement le projet SIV permet une vente de cartes d’abonnement avec des
prix fixes. Le diagramme de cas d’utilisation suivant présente les principales actions

du Complément M1 du SIV qui concerne la configuration d’une promotion ou une
évolution sur les prix des cartes d’abonnement :
Figure 20 : Diagramme de cas d'utilisation Complément M1 - Vente des billets de

voyage et des cartes d'abonnement
Un utilisateur et plus particulièrement un administrateur fonctionnel chez

ONCF pourra :
 Paramétrer une offre promotionnelle sur les prix des cartes d’abonnement.
 Appliquer la promotion sur les prix des cartes d’abonnement.
 Annuler la promotion sur les prix des cartes d’abonnement.
 Paramétrer une évolution sur les prix des cartes d’abonnement.
 Appliquer l’évolution sur les prix des cartes d’abonnement.
Ces tâches nécessitent l’authentification de l’utilisateur dans le système et avoir

les droits pour accéder à ces éléments.
Partie frontOffice :
Pour cette partie du Complément M1 – Vente des billets de voyage et des cartes
d’abonnement, nous avons trois volets principaux. Le premier volet concerne la
partie vente guichet - émission des billets, le deuxième est à propos de la vente
guichet – Grand groupe et le troisième est par rapport du paramétrage de la vente

des types de groupes. Nos études nous ont permis d’élaborer les diagrammes de cas
d’utilisation suivants :
Partie vente guichet – Complément :
Le diagramme de cas d’utilisation dans la figure ci-dessous représente les

actions à ajouter pour la vente au niveau des guichets :
Figure 21 : Diagramme de cas d'utilisation Complément M1 Vente des billets de

voyage
Un Vendeur pourra :
 Effectuer la vente d’un billet avec un tarif pour adhérent au programme de

fidélité
 Emettre un billet matérialisé acheté sur un canal à distance Consulter la
consommation d’un poste de vente
 Vendre un ticket de quai
 Percevoir le paiement d’une contravention suite à un incident à bord
 Emettre un chèque cadeau
Ces tâches nécessitent une authentification pour avoir l’accès à l’ensemble de

ces fonctionnalités.

Partie Vente Guichet –Grands groupes
L’existant du projet SIV pour cette partie est de vendre des billets petits (de
6 à 10 personnes) et moyens (de 11 à 24 personnes) groupes. Le diagramme de cas
d’utilisation suivant présente les fonctionnalités ajoutées par l’ONCF au
complément M1 du SIV concernant la vente guichet d’un grand groupe (plus de 25
personnes) :
Figure 22 : Diagramme de cas d'utilisation Complément M1 - Vente guichet grand

groupe
Un Vendeur pourra :
 Effectuer la vente d’un voyage grand groupe

 Ajouter des voyageurs à un grand groupe
 Supprimer des voyageurs d’un voyage grand groupe
 Annuler une demande de voyage grand groupe
Ces tâches nécessitent une authentification de la part du vendeur pour pouvoir

accéder à ces éléments.
2.2. Conception structurelle

Pour cette partie nous allons présenter l’ensemble des classes que nous avons
prévus pour le Complément M1 – vente des billets de voyages et des cartes
d’abonnement. C’est la partie la plus sensible dans cette phase de conception, par
qu’il nous a fallu élaborer une conception en se basant sur l’existant et sans affecter
ce dernier. Le grand défi est de pouvoir intégrer notre conception dans l’existant en

l’utilisant et sans l’affecter. Les diagrammes de classes que nous avons élaborés se
distinguent selon deux volets, le volet backOffice et le volet frontOffice.
Volet backOffice :
Pour la partie backOffice, en ce qui concerne le paramétrage des promotions et
des évolutions nous avons élaborer le diagramme de classes suivant :
Figure 23 : Diagramme de classes pour la partie backOffice

Les classes PrixCarte et Carte sont des classes existantes dans le projet SIV.
Les classes Promotion et Augmentation sont les classes que nous avons prévus pour
cette partie du complément. La classe Augmentation représente une Evolution.
Ainsi que nous avons prévu l’ensemble des services présentés dans le tableau
suivant :
Promotion/Evolution - Compléments
Cas d’utilisation Services
AddPromotion(Promotion promotion)
Paramétrer une offre AppliquerPromotionSurPrixCarte(Promotion
promotionnelle sur les cartes promotion, List<PrixCarte> prixCarte)
d’abonnement GetPeriodePromotionnelle()
AddEvolution(Augmentation augmentation)
Appliquer une évolution AppliquerEvolutionSurPrixCarte(Augmentation
tarifaire sur le prix des cartes augmentation, List<PrixCarte> prixCarte)
d’abonnement GetEvolutionPrixCarte()
Tableau 5 : Tableau des services prévus pour la partie backOffice

Volet frontOffice :
Cette partie contient deux volets élémentaires, le volet vente guichet –

Complément qui concerne l’émission d’un billet et le volet vente guichet – Grands
groupes. Nous allons présenter le détail des diagrammes de classes prévus pour les
deux volets, ainsi que les services conçus pour chacun de ces volets.
Volet vente guichet – Emission des billets de voyage :
Pour cette partie, après avoir étudier les éléments qui existent. Nous sommes
arrivés à trouver l’ensemble des classes intervenant dans le système existant. Et
nous avons détecter qu’il faut concevoir les services permettant de mettre en œuvre
ce complément. Les services que nous avons élaborés se trouvent dans le tableau
suivant :
Emission des billets de voyage - Complément

EmettreBillet(DossierVoyageDTO
dossiervoyagedto)
Emettre un billet de voyage par GetCanalDistributionByPosteVente(int
SMS ou email posteVenteID)
Tableau 6 : Services conçus pour l'émission des billets de voyage
Volet vente guichet – Grands groupes :
Pour ce volet l’existant est de vendre des billets de voyage petits (de 6 à 10
personnes) et moyens (de 11 à 24 personnes) groupes. Les retours client pour cette
partie était de pouvoir effectuer une vente de billets de voyage pour un grand groupe
c’est-à-dire plus de 25 personnes.
Nous avons élaboré le diagramme de classe représenté dans la figure qui suit pour
la vente des billets grands groupes (25 personnes et plus) :

Figure 24 : Diagramme de classes pour le voyage grands groupes
Les classes StatutDemande et HistoriqueDemande sont les classes que nous
avons conçus pour le voyage Grands groupes. Les classes TypeGroupe, Groupe,
ClientIndividuel, DossierVoyage et Utilisateur sont les classes existantes.
La classe TypeGroupe représente l’énumération petits groupes et moyens groupes,
nous avons ajouté un nouveau type qui est grands groupes.
Pour les services de ce Complément, le tableau suivant illustre l’ensemble des
services à mettre en place :
Vente guichet – Compléments
GetTTLGroupe(int CanalDistribution, int
Effectuer la vente d’un TypeCommande, int DelaiId)
voyage grand groupe GetDossierVoyageGrandGroupe()
Ajouter des voyageurs à
un grand groupe UpdateDossierVoyageGrandGroupe(DossierVoyage
Supprimer des dossiervoyage, StatutDemande statutdemande)
voyageurs d’un voyage EmettreAnnulationGroupe(String email, string
grand groupe htmlString)
Annuler une demande de
voyage grand groupe
Tableau 7 : Service conçus pour la vente guichet - Grand groupe

2.3. Livraison
Comme nous avons détaillé dans la partie contexte général, Omnidata est
l’organisme qui joue le rôle de validateur et d’intermédiaire entre la société Algo et
le client l’ONCF. De plus, le module de gestion des ventes de cartes d’adhésion et
de tickets est volumineux avec beaucoup de cas différents. C’est pourquoi il nous a
fallu un moyen unique pour communiquer avec ce validateur compréhensible par
les deux intervenants. Ce moyen est un dossier de conception détaillé contenant
l’ensemble des diagrammes UML exhaustifs que nous avons élaboré dans cette
deuxième partie de notre stage et même dans la première partie.
L’ensemble des livrables de cette partie se résument comme suit :
 Les diagrammes des cas d’utilisations : décrivant l’ensemble des

fonctionnalités et auteurs de l’application.
 Les diagrammes d’activités : détaillant chaque use case pour définir les
activités servant à réaliser la fonctionnalité.
 Les diagrammes de séquences : élaboré pour expliquer le cheminement des
messages et le séquencement de la logique métier d’un point de vue plutôt
technique.
 Les diagrammes de classes : pour brancher la partie de traitement de ces
nouvelles fonctionnalités à l’application et son architecture existante.
 Les services à implémenter : lister pour chaque scénario et fonctionnalité
l’ensemble des services que nous avons jugé optimal à l’aboutissement de
l’application.
Il faut noter que cette partie est livrée aux analystes d’Omnidata, et que nous
sommes en attentes des retours pour pouvoir implémenter ces éléments et intégrer
cette partie au projet SIV.

Conclusion
Dans cette partie, nous avons présenté la deuxième partie de nos réalisations
durant notre stage de fin d’études. Nous avons effectué une étude et analyse
fonctionnelle, puis nous avons entamer la mise en œuvre. A ce niveau nous avons livré
une conception exhaustive du Complément M1 vente aux analystes Omnidata.

Conclusion générale
SIV vient comme solution au besoin de produire un nouveau système de distribution

de l’offre voyageurs qui permet de mettre en œuvre la stratégie commerciale de
l’ONCF. Notre projet de fin d’étude répond au besoin d’implémentation du
complément M1 du système SIV qui concerne la partie gestion des stocks bobines,
ainsi que la partie vente des billets de voyage et des cartes d’abonnement.
La mise en œuvre de notre solution requiert une bonne compréhension du

contexte pour appréhender ses notions fonctionnelles. Une analyse approfondie du
système fut donc indispensable au début de ce projet de fin d’études. Au terme de cette
analyse, les connaissances nécessaires sur les enjeux de la solution ont pu être
acquises.
Notre mission durant ce stage de fin d’étude au sein de la société Algo

Consulting Group Rabat contenait deux volets. Le premier consistait à étudier,
concevoir et mettre en œuvre le Complément M1 - Gestion des stocks bobines qui
permet de commander, confirmer la livraison et consulter la consommation des
bobines sur trois niveaux (établissements, gares, postes de vente), ainsi que la gestion
de prise et de fin de service par les vendeurs au niveau des postes de vente.
Le deuxième était à propos de la conception détaillé du Complément M1 – Vente des
billets de voyage et des cartes d’abonnement.
D’abord, nous avons commencé par l’analyse des besoins et la détection de la

problématique, qui nous a amené à concevoir une solution permettant de gérer les
stocks bobines en évitant les régressions au niveau du code existant, ainsi que
l’architecture adoptée pour la mise en œuvre du projet SIV.
Avant de commencer la mise en œuvre de la solution, nous avons suivi une

autoformation sur les différentes notions et éléments du projet SIV, en couvrant ainsi
les différentes couches traitées. Ensuite nous avons ciblé notre apprentissage dans les
parties pertinentes pour notre projet.

La méthode de travail suivie tout au long de ce projet est l’une des méthodes
agiles, qui est Scrum. Cette méthode, qui favorise la modularisation d’un projet et son
découpage en itérations, s’est avéré la plus adaptée à la nature de notre projet SIV.
En effet, les objectifs fixés pour la solution ont été atteints, pour la partie
gestion des stocks bobines, nous avons pu livrer un produit valide et qui répond aux
exigences de l’ONCF. Ainsi que pour la partie vente des billets de voyage et des cartes
d’abonnement nous avons livré une conception détaillée des exigences aux analystes
d’Omnidata. Cependant, nous avons confronté plusieurs difficultés pour parvenir à ces
résultats. D’une part l’architecture adoptée pour la réalisation du projet SIV, il s’agit
de l’architecture SOA connue pour être complexe. Et d’autre part l’aspect maintenance
de la solution a rendu l’étape conception plus complexe. Ainsi que notre grand défi
qui est l’intégration des nouveaux éléments dans le projet existant sans avoir des
régressions.
SIV est un grand projet où les besoins ne sont pas encore totalement saturés, il
faudrait donc continuer à implémenter les fonctionnalités manquantes. Nous
souhaitons ajouter des graphes au niveau de la consultation de la consommation des
bobines, l’affectation des bobines aux vendeurs et notifier les responsables des
ruptures de stocks. Ainsi que l’implémentation de la partie vente des billets de voyages
et des cartes d’abonnement.
Au terme de ce travail, ce stage a été pour nous une expérience professionnelle

enrichissante sur tous les niveaux. Ce projet nous a apporté une grande satisfaction et
des connaissances que nous pourrions certainement faire valoir par la suite. Ce travail
nous a permis de faire évoluer nos compétences en communication, en travail en
équipe et en coordination avec les différentes équipes.

Webliographie
[1] Amélioration et mise à niveau de l'application IdéoRequeteur de reporting qui

s’inscrivent dans le cadre de la suite IdéoSanté {Document PDF} (tableau 2)
[2] Amélioration et mise à niveau de l'application IdéoRequeteur de reporting qui

s’inscrivent dans le cadre de la suite IdéoSanté {Document PDF} (figure 3)
[3] Formation Algo Consulting Group (figure 10)
[4] https://msdn.microsoft.com/fr-fr/library/dn762121.aspx (25/05/2016)
[5] https://www.microsoft.com/fr-fr/download/details.aspx?id=29062 (25/05/2016)
[6] https://www.visualstudio.com/fr-fr/products/tfs-overview-vs.aspx (25/05/2016)
[7] http://www.editions-eni.fr/livres/mvvm-maitrisez-vos-developpements-net-wpf-
silverlight-windows-phone/.5bb0ab6a2e4cf310d840b02f565b9164.html {extrait du
livre MVVM maîtrisez vos développements .NET} (27/05/2016)
[8] https://msdn.microsoft.com/fr-fr/library/dd460648(v=vs.110).aspx (20/07/2016)
[9] https://msdn.microsoft.com/fr-fr/data/ef.aspx (29/05/2016)
[10] https://msdn.microsoft.com/fr-fr/library/bb397906.aspx (29/05/2016)
[11] https://msdn.microsoft.com/fr-fr/library/aa970268%28v=vs.100%29.aspx
(29/05/2016)
[12] http://vincentlaine.developpez.com/tuto/dotnet/wcf/ (29/06/2016)
[13] Document de spécification de l’ONCF

Annexes
Annexe A : Détails des spécifications fonctionnelles
Annexe B : Détails de la saisie de la bobine de prise/fin de service et

de changement de bobines
Annexe C : Détails de la conception structurelle
Annexe D : Détails des réalisations – Gestion des stocks bobines

Annexe A : Détails des spécifications fonctionnelles
gestion stocks bobines
Cet annexe consiste à détailler les spécifications fonctionnelles exprimées par
l’ONCF.
Spécification : Commande des bobines et consultation
Le tableau ci-dessous décrit en détails les acteurs, les scénarios ainsi que les
règles de gestion pour effectuer une commande :
Commander des bobines
Description Un utilisateur habilité saisit les Bons de commande des bobines à

adresser au fournisseur.
Acteurs
 Utilisateur habilité
Entrées
 Référence bobine
 Nom du fournisseur
Sorties
 Bon de commande avec références des Bobines
enregistrées
Scenario 1. L’utilisateur saisit les références des bobines à commander.

nominal
2. L’utilisateur saisit le nom du fournisseur.
3. Le système enregistre le bon de commande et les

références des bobines.

Règles de RG1 : l’utilisateur peut consulter les bons de commande des
gestion bobines avec leur statut livrée ou en cours.
RG2 : le système affecte un numéro à chaque bon de commande.
Tableau 8 : Tableau de spécification des commandes des bobines
Spécification : Livraison des bobines et consultation
Le tableau ci-dessous décrit en détails les acteurs, les scénarios ainsi que les règles
de gestion pour confirmer une livraison des bobines ainsi que la consultation des
commandes :
Saisir et affecter une bobine
Description Un utilisateur habilité effectue la recherche du BC et saisit les

BL correspondants du fournisseur.
Acteurs
Entrées
 N° du BC
 Référence bobine commençant et quantité
 La date de livraison
Sorties
 Bon de livraison avec références des Bobines
enregistrées à l’entrée
Scenario 1. L’utilisateur saisi le N° du BC

nominal 2. L’utilisateur saisie la Référence bobine commençant
quantité
3. L’utilisateur saisie La date de livraison
4. Le système enregistre le bon de livraison et les
références des bobines.

Règles de RG1 : l’utilisateur peut consulter les bons de commande et les
gestion bons de livraison des bobines avec leur statut livrée ou en cours.
RG2 : le système affecte un numéro à chaque bon de livraison

en plus du numéro de BL saisie
RG3 : chaque bon de livraison saisi et validé donne

automatiquement la création de la séquence correspondante au
stock central des bobine
Tableau 9 : Tableau de spécification des livraisons des bobines
Spécification : consultation de la consommation des bobines
Le tableau ci-dessous décrit en détails les acteurs, les scénarios ainsi que les
règles de gestion pour la consultation de la consommation des bobines sur trois
niveaux : établissement, gare, poste de vente.
Consulter la consommation des bobines
Description L’administrateur peut consulter la consommation des bobines

selon plusieurs critères.
Acteurs
Entrées
 Etablissement
 Gare (facultatif)
 Poste de vente (facultatif)
Sorties
 Consommation des bobines selon les critères choisis
Scenario 1. L’utilisateur choisit un établissement et lance la recherche

nominal (SA1, SA2).
2. Le système affiche la consommation des bobines affectées à

l’établissement choisi, par gare et par poste de vente.

Scenario SA1 : En choisissant un établissement, le système remonte la
alternatifs liste de gares affectées à cet établissement. L’utilisateur peut
choisir une gare et lancer la recherche. Dans ce cas, le système
affiche la consommation des bobines affectées à la gare choisie
par poste de vente.
SA2 : En choisissant une gare, le système remonte la liste de
postes de vente affectés à cette gare. L’utilisateur peut choisir
un poste de vente et lancer la recherche. Dans ce cas, le système
affiche la consommation des bobines affectées au poste de
vente choisi.
Tableau 10 : Tableau de spécification consultation de la consommation des bobines
Spécification : Saisie de la bobine au démarrage de la session
de gestion pour la saisie de la bobine au démarrage de la session d’un vendeur :
Saisir la bobine au démarrage de la session
Description Au démarrage de sa session le vendeur doit saisir la référence

de la bobine qu'il va utiliser lors de sa session, et le numéro
d'utilisation : check point indiquant l'utilisation de la bobine, qui
est un numéro imprimé sur la bobine.
Acteurs
 Vendeur
Entrées
 Année
 Numéro d’utilisation
 Date et heure d’ouverture de session (du système)

Sorties
 Bobines reliées à la session en cours
Scenario 1. Le système récupère la liste des bobines affectées au

nominal poste de vente, et les affiche dans une liste
2. L’utilisateur choisit la bobine.
3. L’utilisateur saisit l’année et le check point, puis valide

les informations saisies.
4. Le système vérifie que la bobine avec la référence est

affectée au poste de vente.
5. Le système enregistre les informations et lie la bobine à

la session du vendeur connecté.

alternatifs
poste de vente, et les amorties du stock globale des
bobines affectés aux vendeurs par la même gare.
Tableau 11 : Tableau de spécification prise de service
Spécification : Saisie de la bobine à la fin de session
de gestion pour la saisie de la bobine à la fin de la session d’un vendeur :
Saisir la bobine à la fin de session
Description A la fin de la session, le guichetier saisit la dernière référence

du check point.
Acteurs
 Vendeur
Entrées

 Année
 Numéro d’utilisation
 Date et heure de fin de session
Sorties
 Données de fin de session enregistrées.
Scenario 1. Le système récupère la référence de la bobine liée à la

nominal session en cours, et l’affiche dans le champ indiqué.
2. L’utilisateur saisit l’année et le check point, puis valide

les informations saisies.
3. Le système enregistre les informations de fin de session,

et imprime un billet de fin de session.

alternatifs poste de vente, et les amorties du stock globale des
bobines affectés aux vendeurs par la même gare à la fin
des sessions de vente.
2. La gare peut visualiser l’ensemble des stocks des

bobines affectées aux vendeurs et non amortie et
l’inverse
Tableau 12 : Tableau de spécification fin de service

Annexe B : Détails de la saisie de la bobine de prise/fin de
service et du changement de bobine
Cet annexe contiendra les détails de la saisie de la bobine de prise, fin de
service et du changement de bobine, ainsi que les détails du processus dans le cas
réel.
Définition :
- Bobine : ou bobine thermique, est une cartouche de papier thermique pour

l’impression des billets de voyage. Elle est caractérisée par des numéros pré-
imprimés au verso du papier selon la structure suivante :
A B C
 A : Année : 2 caractères
 B : Numéro de la bobine : 5 caractères
 C : Numéro du billet : 4 caractères
Chaque bobine comporte 2500 billets numérotés
Selon cette structure de numérotation, ces bobines constituent donc un support de

titre de transport à l’instar des billets manuels.
Prise de service :
Lors de son arrivé, un vendeur doit déclarer sa prise de service. Ceci en imprimant un
billet de prise de service, cette impression est faite dès sa première authentification au
système et il renseigne le numéro de série au verso du billet imprimé au niveau du
système.

Fin de service :
Lorsque le vendeur termine son service, avant de quitter l’application, le vendeur

déclare sa fin de service en imprimant un billet de fin de service et renseigne le numéro
de série au verso du billet au niveau de l’application, puis quitte le système.
Changement de bobine :
Lors d’un changement de bobine, le vendeur imprime un billet à partir de la bobine

actuelle, saisi le numéro de série qui est au verso du billet au niveau de l’application
et enlève cette bobine. Puis installe la nouvelle bobine, imprime un billet de
changement de bobine et saisi le numéro de série qui est au verso du billet au niveau
de l’application.
Important : il faut noter que l’ensemble des billets de prise/fin de service et

changement de bobine sont rendu au chef de division à la fin de la journée.

Annexe C : Détails de la conception structurelle
Gestion des stocks bobines
Nous allons détaillés dans la suite de cette partie de l’annexe l’ensemble des
diagrammes de séquences extraient des cas d’utilisations du module de gestion des
stocks bobines.
Partie consultation des commandes/livraisons
Le diagramme de séquence ci-dessous présente la séquence des messages traités

pour pouvoir consulter les commandes ou les livraisons :
Figure 25 : Diagramme de séquence pour la consultation des

commandes/livraisons
Ce diagramme de séquence est général pour la consultation des

commandes/livraisons.
 Administrateur fonctionnel : présente un responsable de l’établissement

central de l’ONCF qui peut consulter les commandes/livraisons effectuées.
 Vue WPF : présente la vue permettant d’effectuer cette consultation.
 VueModel : présente la vue-model associée à la vue.
 Système : présente le système SIV et plus particulièrement les services web.

Partie consultation de la consommation des bobines
Le diagramme de séquence ci-dessous présente la séquence des messages traités

pour pouvoir consulter la consommation des bobines :
Figure 26 : Diagramme de séquence pour la consultation de la consommation des

bobines
Pour avoir les statistiques de la consommation des bobines sur les trois niveaux
(établissement, gare, poste de vente), l’interaction des éléments décrites ci-dessous est
nécessaire :
 Administrateur fonctionnel : présente tous les personnes ayant le droit de

consulter la consommation des bobines.
 Vue WPF : la vue permettant de construire le résultat et le présenter.
 Vue WPF : présente la vue permettant d’effectuer cette consultation.
 Système : le système SIV et plus particulièrement les services web.
Partie prise/fin de service :
Cette partie se divise en trois volets indispensables : le volet prise de service, le

volet changement de bobine et enfin le volet fin de service. Le volet prise de service
est traité dans la partie réalisation du Complément M1 – Gestion des stocks bobines.
Dans cette annexe nous allons détailler le changement de bobine et la fin de service.

Changement de bobine :
Dans le cas où la bobine est consommée il est nécessaire de changer la bobine

pour pouvoir imprimer les tickets. Le diagramme de séquence ci-dessous illustre la
séquence de messages échangés entre les différents composants du système pour le
changement de bobine :
Figure 27 : Diagramme de séquence pour le changement de bobine
Pour changer une bobine, l’ensemble des éléments suivant interagies entre eux :


Fin de service :
Au niveau de la fin de service, la séquence de messages suivante est échangée

entre les différents éléments du système :
Figure 28 : Diagramme de séquence pour la fin de service
Pour marquer la fin de service d’un vendeur, les éléments décrit ci-dessous
interagies entre eux :


Vente des billets de voyage et des cartes d’abonnement
Pour la suite de cette partie nous allons détailler la suite des diagrammes des
classes pour la vente des tickets de quais et l’envoi des chèques cadeaux, ainsi que le
paiement d’une contravention au bord du train :
Tickets de quais :
La figure ci-dessous représente notre conception pour le Complément M1 –

vente des billets de voyage et des cartes d’abonnement, partie vente des tickets de
quais :
Figure 29 : Diagramme de classes vente des tickets de quais
La classe TicketQuai est la classe que nous avons prévu pour cette partie du
complément. La classe ModePaiement est une classe du package paramétrage général
appartient aux réalisations du module M1 du SIV.
Le principe des tickets de quais, est qu’il s’agit d’un billet imprimer par une personne
à chaque visite de la gare dès l’entrée.

Les services conçus pour la mise en œuvre de cette partie du complément sont dans le
tableau qui suit :
Ticket quais - Complément

Cas d’utilisation Service
GetMontantTicketQuai()
Vente des tickets de quais AddTicketQuai(TicketQuai ticketquai)
Tableau 13: Services conçus pour la vente des tickets de quais
Chèque cadeau :
La figure ci-dessous représente notre conception pour le Complément M1 –

vente des billets de voyage et des cartes d’abonnement, partie envoi des chèques
cadeau :
Figure 30 : Diagramme de classes chèque cadeau
La classe ChequeCadeau est la classe que nous avons prévu pour cette partie
du complément. La classe ClentIndividuel est une classe du package client qui
appartient aux réalisations du module M1 du SIV.
Le principe d’envoi des chèque cadeau est lorsqu’un client devient un client fidèle ou
lors d’un voyage dépasse une somme bien précise, l’ONCF prévoit de lui fournir des
chèques cadeaux pour le fidéliser.

Les services qui concernent la mise en œuvre de l’envoi des chèques cadeaux pour
fidéliser les clients sont dans le tableau suivant :
Chèque cadeau - Complément

AddChequeCadeau(ChequeCadeau chequecadeau)
EmettreChequeCadeau(string email, string
htmlString)
Vente des tickets de quais
Tableau 14 : services conçus pour l'envoi des chèques cadeaux
Vente guichet – Complément contravention :
Définition : une contravention est un accident qui arrive au bord du train mais qui
produits des dégâts matériels (vitre cassée, chaise endommagée …).
Conception :
Pour ce volet nous allons présenter le diagramme de classes pour le paiement

d’une contravention, l’envoie des chèque cadeaux et la vente des tickets de quais
sont détailler dans l’annexe C. Pour les contraventions nous avons élaborer la
conception suivante :

Figure 31 : Diagramme de classes pour une contravention
Les classes que nous avons prévus pour ce complément sont :
 La classe Contravention
 La classe Contrevenant
Ces classes communiquent avec des classes existantes dans des packages (ce sont
des dossiers regroupant des classes qui appartiennent au même domaine) différents,
le package Habilitation, Paramétrage général et Plan transport.
Les services présentés dans le tableau ci-dessous sont ceux que nous avons prévus
pour la mise en œuvre de cette partie du complément :
Contravention - Complément
Payer une contravention au AddContrevenant(Contrevenant contrevenant)
bord du train AddContravention(Contravention contravention)
Tableau 15 : Services conçus pour le paiement des contraventions

Annexe D : Détails des réalisations – Gestion des stocks bobines
Partie backOffice :
Cette partie contient plusieurs composants et permet de :
1) Commander des bobines, ceci est possible via l’interface suivante :
Figure 32 : Pop-up commander des bobines
2) Modifier une commande à l’aide de l’interface dans la figure 33 :
Figure 33 : Pop-up modifier une commande

3) Confirmer la livraison d’une commande. L’interface ci-dessous illustre le pop-
up de confirmation :
Figure 34 : Pop-up confirmation de livraison
4) Consulter la commande en détail via le pop-up de consultation de l’état de la

commande figure suivante :
Figure 35 : Pop-up état de la commande non livrée

La figure ci-dessous représente le cas de consultation de la commande si cette
dernière est livrée :
Figure 36 : Pop-up état de la commande livrée
5) Consulter la consommation des bobines par établissement, cette partie contient

deux niveaux comme illustre les figures ci-dessous :
Figure 37 : interface consulter la consommation par établissement niveau 1

En cliquant sur le bouton au niveau de la colonne action nous avons le pop-up
suivant :
Figure 38 : interface consulter la consommation par établissement niveau 2
6) Consulter la consommation par gare, le résultat est illustré dans la figure

suivante :
Figure 39 : interface consulter la consommation par gare niveau 1

En cliquant sur le bouton au niveau de la colonne action nous avons le deuxième
niveau :
Figure 40 : Interface consulter la consommation par gare niveau 2
7) Consulter la consommation par poste de vente, le résultat est le suivant :
Figure 41 : Interface consulter la consommation par poste de vente

Annexe E : Détails des scénarios métier
Dans cette partie des annexes nous allons décrire en détails les scénarios métier
à savoir, la commande des bobines, qui concerne les administrateurs des gares et la
partie des vendeurs qui concerne la prise, changement de bobine et la fin de service.
Commande des bobines :
Un administrateur lorsqu’il détecte une rupture de stock des bobines, il effectue

une commande.
Lorsqu’il reçoit la livraison, il compare la commande avec ce qui est livrée si la

commande et la livraison sont correspondantes l’administrateur confirme la livraison.
Si la commande et la livraison ne sont pas correspondantes, l’administrateur rejette la
livraison.
La figure ci-dessous résume le processus de la commande :
Figure 42 : Illustration du processus de la commande

Partie de prise/fin de service et changement de bobine :
Dans un premier temps le vendeur imprime un billet de prise de service à partir

de la bobine courante.
Figure 43 : Prise de service
Lorsque l’alerte de changement de bobine est affichée, le vendeur doit changer

la bobine courante. Pour se faire, il doit imprimer un billet de changement à partir de
la bobine actuelle, puis installe la nouvelle bobine, imprime un autre billet de
changement de bobine à partir de la nouvelle. Voici une illustration :
Figure 44 : Illustration de changement de bobine
Vers la fin de son service, le vendeur imprime un billet de fin de service. La figure ci-
dessous est une illustration de fin de service :

Figure 45 : Illustration de fin de service
Avant de quitter son poste, le vendeur doit remettre les quatre billets à son responsable.
Ces billets représentent une preuve du service du vendeur et permettent de garder la
trace des bobines consommées.
Figure 46 : L'ensemble des billets imprimées durant le service d'un vendeur
Il faut noter que s’il n’y a pas de changement de bobine durant le service d’un vendeur,
ce dernier doit remettre au responsable deux billets seulement. Le premier de prise de
service et le deuxième de fin de service.

MemoirePFE Abdelkayoum DERFOUFI - Naoual LAMZIRA

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MemoirePFE Abdelkayoum DERFOUFI - Naoual LAMZIRA

Transféré par

Droits d'auteur :

Formats disponibles

Royaume du Maroc

Université Mohammed Premier

Mémoire de Projet de fin d’Etudes

Mise en place du module de gestion des stocks bobines et conception

Présenté par : Encadré par :

Année universitaire : 2015/2016

‫ الى معنى الحب والحنان والتفاني‬... ‫الى من تكبدا عناء تربيتي‬

.‫ والداي‬،‫… رب ارحمهما كما ربياني صغيرا‬. ‫ احبكما‬... ‫ شكرا ثم شكرا‬،‫شكرا‬

To myself, enjoy life !

Rapport PFE ENSAO : 2015/2016 3

A ma famille qui m’aime et qui m’a toujours encouragé je dédie ce travail.

A tous mes très chères amies et chers amis, je dédie ce travail.

A tous les gens qui m’aiment et qui ont contribué de près ou

Rapport PFE ENSAO : 2015/2016 4

Il nous est agréable de nous acquitter d’une dette de reconnaissance auprès de

Rapport PFE ENSAO : 2015/2016 5

Ce présent document fructifie l’ensemble de nos travaux apportés dans le cadre

Mots Clés : LGV, SIV, ONCF, WPF, MVVM, SOA.

Rapport PFE ENSAO : 2015/2016 6

Key words: SIV, ONCF, WPF, MVVM, SOA.

Rapport PFE ENSAO : 2015/2016 7

‫‪Rapport PFE ENSAO : 2015/2016‬‬ ‫‪8‬‬

Rapport PFE ENSAO : 2015/2016 9

Figure 1 : Schéma représentatif des modules du projet SIV ................................ 21

Rapport PFE ENSAO : 2015/2016 10

Rapport PFE ENSAO : 2015/2016 11

Rapport PFE ENSAO : 2015/2016 12

Rapport PFE ENSAO : 2015/2016 13

Rapport PFE ENSAO : 2015/2016 14

L’entreprise est une entité économique financièrement indépendante réunissant

Rapport PFE ENSAO : 2015/2016 15

Dans un premier lieu nous allons présenter l’entreprise accueillante, Algo

En troisième lieu, nous allons présenter la deuxième partie qui concerne la

Rapport PFE ENSAO : 2015/2016 16

Rapport PFE ENSAO : 2015/2016 17

Algo Consulting Group accompagne ses clients dans l’optimisation de leurs

Algo Consulting Group suggère de nombreux services à ses clients à savoir :

Rapport PFE ENSAO : 2015/2016 18

1.2. Présentation de l’ONCF : Le client

1.3. Présentation d’Omnidata : Organisme validateur

Rapport PFE ENSAO : 2015/2016 19

L’équipe Omnidata s’occupe de :

 La rédaction des spécifications exprimées par l’ONCF

II. Présentation du projet SIV

Le système de ventes à l’ONCF a subi plusieurs transitions, pour faciliter la

SABIL (système actuel) SIV

Rapport PFE ENSAO : 2015/2016 20

Figure 1 : Schéma représentatif des modules du projet SIV

La livraison du premier module est effectuée, il reprend les services offerts

 La vente des billets de voyage.

Rapport PFE ENSAO : 2015/2016 21

Exigences Retour ONCF

Ces retours seront traités en complément du module M1 du SIV durant notre

Ce complément concerne la gestion des stocks bobines, ce sont des roulons de

 Etablissement : représente les établissements responsables de l’ensemble

Rapport PFE ENSAO : 2015/2016 22

Ce complément concerne les services offerts par l’ONCF à sa clientèle et plus

 Au niveau de la vente des cartes d’abonnement, il envisage de pouvoir

III. Pilotage et conduite du projet SIV

Rapport PFE ENSAO : 2015/2016 23

3.2. Cycle de développement : Semi-itératif et incrémental

Semi-itératif Itératif Séquentiel

Rapport PFE ENSAO : 2015/2016 24