rapport-de-stage14.pdf

Appréciations de l’encadrant

MR Hammouda Bahri

(Arabsoft)

Appréciations de l’encadrant

MR Hammouda Bahri

(Arabsoft)

Remerciements ous

souhaitons adresser nos remerciements aux personnes qui nous ont apporté leur aide et qui ont contribué à la réalisation de notre projet. Nous remercions tout d’abord Monsieur Hammouda Bahri pour ses conseils, son soutien et pour nous avoir encadrés tout au long du projet. Nos vifs remerc remerciem iemen ents ts vont vont égalemen égalementt aux membres membres de jury jury pour nous avoir avoir accordé accordé leur leur attention. Finalement, nous sommes reconnaissants à tous nos collègues pour leur soutien pendant la réalisation de notre travail.

N

Table des matières Introduction générale

1

1 Cadre général du pro jet 1.1 Cadre du travail . . . . . . . . . . . . 1.2 Présentation de l’organisme d’acceuil 1.3 Présentation du sujet . . . . . . . . . 1.4 Méthodo odologie et formalismes adoptés

. . . .

2 2 2 3 3

2 Etude théorique 2.1 La Bourse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Etude et analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 5 6

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 Analyse et spécification des besoins 3.1 identification des acteurs . . . . . . . . . . . . . . . . . . . . . . 3.2 Etude des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . 3.2.2 Les bes besoins non fonctionnels . . . . . . . . . . . . . . . . 3.3 Spéc pécification des bes besoins . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . 3.3. 3.3.1. 1.11 Diag Diagra ramm mmee de respo espons nsab ablle de fact factur urat atio ionn . . . 3.3.1.2 Diagramme de l’adm adminis nistrate ateur . . . . . . . . . 3.3.1.3 Diagramme de client . . . . . . . . . . . . . . . 3.3.2 Diagrammes de séquence . . . . . . . . . . . . . . . . . . 3.3. 3.3.2. 2.11 Diag Diagra ramm mmee de séqu séquen ence ce "s’ "s’auth authen enti tifie fierr" . . . . 3.3. 3.3.2. 2.22 Diag Diagra ramm mmee de séqu séquen ence ce "ajou "ajoutter cli client ent" . . . . 3.3. 3.3.2. 2.33 Diag Diagra ramm mmee de séqu séquen ence ce "lan "lance cerr la fact factur urat atio ion" n" 3.3. 3.3.2. 2.44 Diag Diagra ramm mmee de séqu séquen ence ce "pas "passe serr récl réclam amat atio ion" n" . 3.3. 3.3.2. 2.55 Diag Diagra ramm mmee de séqu séquen ence ce "év "évalue aluerr serv servic ice" e" . . . 4 Conception 4.1 Conception globale . . . . . . . . . . . . 4.1.1 Vue physique . . . . . . . . . . . 4.1.2 Vue logique . . . . . . . . . . . . 4.2 Conception détaillée . . . . . . . . . . . 4.2.1 diagramme de classes . . . . . . . 4.2.2 Conception de la base de données 4.2.3 Les diagrammes de séquence . . . 3

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

8 8 8 9 10 10 10 10 11 12 13 13 14 16 18 19

. . . . . . .

20 20 20 21 22 23 24 25

4.2. 4.2.3. 3.11 4.2. 4.2.3. 3.22

Diag Diagra ramm mmee de séqu séquen ence ce ajout ajouter er clie cliennt . . . . . . . . . . . . . . 26 Diag Diagra ramm mmee de séqu séquen ence ce lanc lancer er la fact factur urat atio ionn . . . . . . . . . . 27

5 Réalisation 5.1 Environnement du travail . . . . . . . . . . . 5.1.1 Environnement matériel . . . . . . . . 5.1.2 Environnement logiciel . . . . . . . . . 5.2 Travail réalisé . . . . . . . . . . . . . . . . . . 5.2.1 Espace ace comm ommun à tous ous les utilisateurs 5.2.2 Espace client . . . . . . . . . . . . . . 5.2.3 Espace agent de facturation . . . . . . 5.2.4 espace administrateur . . . . . . . . . 5.2.5 Chronogramme . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

29 29 29 29 30 30 31 36 39 41

Conclusion et perspectives

43

Netographie

44

Table des figures 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

cas d’utilisation responsable de facturation . cas d’utilisation administrateur . . . . . . . cas d’utilisation client . . . . . . . . . . . . . diagramme séquence authentification . . . . diagramme séquence ajout d’un client . . . . diagramme séquence facturation . . . . . . . diagramme séquence passer une réclamation diagramme séquence évaluer service . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

11 12 13 14 15 17 18 19

4.1 4.2 4.3 4.4 4.5 4.6

architecture 3 tiers php . . . . . . . . . . . . . le modèle MVC . . . . . . . . . . . . . . . . . diagramme de classes . . . . . . . . . . . . . . modèle de la base de données . . . . . . . . . Diagramme de séquence ajout d’un client . . . Diagramme de séquence lancer la facturation .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

21 22 23 24 26 28

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13

page connexion . . . . . . . . . . . page d’acceuil client . . . . . . . . . menu client . . . . . . . . . . . . . page reclamation . . . . . . . . . . page infos . . . . . . . . . . . . . . consulter facture . . . . . . . . . . page d’acceuil agent de facturation menu agent de facturation . . . . . page facturation . . . . . . . . . . . page ajout client . . . . . . . . . . menu administrateur . . . . . . . . page tableau de bord . . . . . . . . chronogramme . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

31 32 33 34 35 35 36 37 38 39 40 41 41

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

Introduction générale Dans les deux dernières décennies, nous avons remarqué une utilisation de plus en plus commune des hautes technologies dans le domaine financier. Ce secteur a tendance à numériser ses informations et exploiter les capacités et la rapidité qu’offrent ces techniques. La Bourse, élément du marché financier qui joue un rôle économique essentiel dans les économies modernes, vise à mettre les technologies en son service.Ainsi, ils utilisent des supercalculateurs pour assurer un système de négociation informatisé, des sites web et des applications pour mettre en disponibilité des clients les informations en temps réel, etc. Les Bourses ont des factures qui doivent être livrées aux clients pour qu’ils leur payent. Ces factures contiennent diverses commissions. Certaines bourses cherchent à procurer un outil pour gérer la facturation des commissions versées à leur profit. C’est dans ce cadre que se situe notre stage qui vise à concevoir et développer un outil de gestion commerciale de facturation des commissions pour la bourse des valeurs de Tunis et ceci au sein de la société informatique "Arabsoft". Notre site assurera une facilité d’utilisation grâce à son interface il permettra à son utilisateur de générer les factures, les envoyer aux clients et poursuivre l’activité grâce aux statistiques illustrées par un tableau de bord. Le présent rapport décrit les différentes étapes de la réalisation de cette application. Nous commencerons par introduire le cadre général du projet. En deuxième lieu, nous présenterons l’étude théorique que nous avons amenée à propos du sujet. L’analyse des besoins fonctionnels et non fonctionnels ainsi que la spécification de ces besoins via les méthodes semi-formelles feront l’objet de troisième chapitre. Le quatrième chapitre décrit la conception de l’application sur deux niveaux : une conception générale et une conception détaillée. Quant au cinquième chapitre, il sera consacré à l’étape de réalisation, en décrivant tout d’abord l’environnement matériel et logiciel puis en montrant les interfaces associées aux diverses fonctionnalités. Finalement, nous clôturons ce rapport par une conclusion qui rappellera le contexte de notre travail et tracera ses perspectives d’amélioration.

1

Chapitre 1 Cadre général du projet e chapitre

a pour objectif de placer notre projet dans son contexte général soit l’organisme d’accueil, la problématique posée et le sujet à traiter. Nous commencerons par fixer le cadre du travail et présenter l’organisme d’accueil. Ensuite, nous décririons la problématique du sujet ainsi que le travail demandé.

C

1.1

Cadre du travail

Ce stage s’inscrit dans le cadre d’un stage d’été. Il s’agit d’un stage d’immersion en entreprise. Notre stage a été effectué au sein d’une société de services et d’ingénierie en informatique (SSII) "Arabsoft".

1.2

Présentation de l’organisme d’acceuil

ARAB SOFT est une société à responsabilité limitée, créée en 1985, sise à Tunis et représentée par deux agences situées à Sousse et à Djerba. ARAB SOFT compte 130 employés dont 115 concepteurs, développeurs et formateurs. La société ARAB SOFT a connu une croissance rapide dès sa première année d’existence qui l’a propulsé au rang de leader national en ingénierie de software anticipant ainsi l’évolution inévitable de l’ensemble du marché. C’est une SSII [1] ( Société de services et d’ingénierie en informatique) c’est-à-dire une société experte dans le domaine des nouvelles technologies et de l’informatique englobe plusieurs métiers (conseil, conception et réalisation d’outils, maintenance ou encore formation) et a pour objectif principal d’accompagner une société cliente dans la réalisation d’un projet. La SSII a réalisé plusieurs logiciels, notamment dans la gestion des RH, comptabilité financière, gestion hôtelière, gestion de maintenance assistée par ordinateur, gestion commerciale, etc. En tout Arabsoft a prés de 46000 clients. Elle compte parmi ses clients la BCT, ONAS, SNIT, l’ATB et Tunisair. Ces

2

ENSI

CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

organismes ont fait confiance aux compétences d’Arabsoft pour élaborer leurs ERP. L’organisme se caractérise par son savoir-faire dans : — L’étude, conception et développement des logiciels sectoriels spécifiques. — Le développement des logiciels standards — Le développement des sites web dynamiques — La formation sur les logiciels conçus et distribués

1.3

Présentation du sujet

De jour en jour, et avec un rythme accéléré, les établissements régissant dans le secteur financier cherchent à numériser ses informations et automatiser leurs tâches quotidiennes. Dans ce cadre, la société "Arabsoft" décide de réaliser pour la bourse de valeurs de Tunis (BVMT) un système de gestion commerciale de facturation des commissions. Ceci donnera plus de fiabilité et de rapidité à cette activité. L’outil présentera en premier lieu le service de facturation et en deuxième lieu il offrira aux utilisateurs les informations et services relatives à la facturation et qui correspondent à sa catégorie.

1.4

Méthodologie et formalismes adoptés

Dans le développement de ce système, nous allons adopter le modèle incrémental qui consiste à développer l’application en étendant progressivement ses fonctionnalités. Nous avons opté pour ce choix du fait des caractéristiques que possède ce processus de développement : — il est itératif — chaque développement est moins complexe — les intégrations sont progressives Le langage de modélisation employé pour ce projet est l’UML [2]. Il est né de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des années 90 : OMT, Booch et OOSE. Les auteurs ont voulu faire d’UML un langage graphique qui permet de représenter et de communiquer les divers aspects d’un système d’information. Aux graphiques sont bien sûr associés des textes qui expliquent leur contenu. UML [3] est donc un métalangage, car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage du projet. UML est devenu un standard incontournable en matière de modélisation par objet.

stage d’immersion en entreprise

3

ENSI

CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

Conclusion Dans ce chapitre introductif, nous avons présenté l’organisme d’accueil ainsi que le projet à réaliser. En fait, nous avons maintenant une idée sur le contexte du sujet et nous passerons ainsi à une étape primordiale dans la compréhension du projet, c’est la partie de l’étude de l’existant et l’étude théorique.


4

Chapitre 2 Etude théorique ous présentons

dans ce chapitre une étude de l’existant et les solutions proposées. Nous nous introduisions aussi des éléments de compréhension de quelques concepts de base utiles à ce projet.

N 2.1

La Bourse

La Bourse [4] peut se définir comme le lieu où les investisseurs achètent et vendent des titres de capital ou de créance émises par les entreprises, l’état et les collectivités locales.. La Bourse assure le lien essentiel entre les agents économiques qui cherchent à placer leur épargne(ménage, investisseurs individuels ou institutionnels) et les sociétés en quête de financements assurant leur croissance et développement. C’est le rôle économique essentiel de la Bourse dans les économies modernes. La Bourse de Tunis ou "BVMT" pour Bourse des valeurs mobilières de Tunis est une bourse de valeurs. Elle s’agit donc d’un lieu où s’échangent les valeurs mobilières (actions, obligations, titre de créance négociable, etc.). Les ressources de la Bourse proviennent des commissions soient : — commissions sur les négociations boursières (CNB) : elles sont payées par les intermédiaires acheteur et vendeur intervenant dans des transactions boursières portant sur les titres de capital ou de créance appartenant ou non à la cote de la Bourse. — commission d’admission à la cote de la Bourse : elle est acquittée lors de leur introduction en bourse par les organismes émetteurs au profit de la BVMT. — commission de séjour à la cote de Bourse : la commission annuelle de séjour est acquité par les sociétés cotées au profit de BVMT. — commission sur les enregistrements boursiers (CEB) : elles sont payées par le vendeur et l’acheteur de titre pour les opérations qui ne donnent pas lieu à une négociation sur le 5

ENSI

CHAPITRE 2. ETUDE THÉORIQUE marché et qui sont enregistrées par la BVMT.

2.2

Etude et analyse de l’existant

Avant de se plonger dans la réalisation de notre projet, nous avons consulté et testé des solutions déjà existant en matière de gestion commerciale et plus précisément de facturation qui constitue le sujet de ce stage. En effet la gestion commerciale [5] permet de « piloter » une entreprise en donnant les indices qui permettent aux dirigeants de prendre les bons choix stratégiques.Aujourd’hui pour avoir un système de gestion commerciale efficace, il est nécessaire de passer par un bon logiciel informatique. Dans toutes ces solutions le service facturation se présente comme un module. Il en existe aussi des logiciels restreints à la facturation. Ces logiciels sont disponibles sous deux formes : — application desktop — en ligne à travers un site ou une application web Ces solutions sont toutes payantes avec certaines qui offrent une période d’essai gratuit. Le logiciel de facturation en ligne "Zervant" est utilisable pour au moins un abonnement qui coûte 7 euros ou équivalents par mois. Cet abonnement est pour un seul utilisateur et il est limité à trois factures par mois. Le logiciel assez réputé "sage" à son compte peut coûter 600 dinars tunisiens et l’utilisateur est amené à subir une formation pour pouvoir l’utiliser. Cette complexité et ce coût parfois élevé rendent indispensable la mise en place d’un système spécifique pour la facturation qui était un module intégré dans la gestion commerciale. Aussi, les logiciels disponibles gèrent les factures d’achat et de vente dont les entreprises ont besoin mais ne prennent pas en charge la facturation des commissions qui est un besoin particulier pour la bourse. Nous avons remarqué que ces solutions sont destinées à être utilisées seulement par l’agent de facturation et pour juste créer une facture et l’envoyer, ceci à travers le remplissage de champ d’un formulaire pour chaque facture et non pas en se fondant sur un fichier résumant les actions à facturer. Ainsi, elles ne permettant pas l’administration et le contrôle de ce service facturation et aussi n’assurent pas un espace pour les clients qui vont recevoir ses factures. À la lumière de ces constatations, nous avons opté à implémenter un site avec une interface conviviale qui est utilisable par tous les concernés par ce service qui est la facturation. Ainsi, trois espaces existeront : un espace pour le client, un autre pour l’agent de facturation et un dernier pour l’administrateur. La génération et l’envoi des factures par notre système se feront automatiquement si le fichier en entrée respecte les exigences du système en matière de format et de contenu. stage d’immersion en entreprise

6

ENSI

CHAPITRE 2. ETUDE THÉORIQUE

Conclusion Nous avons présenté dans ce chapitre une idée sur l’application et ses origines ainsi que les solutions existantes. Ceci nous a mené à opter à une solution telle que décrite dans le dernier paragraphe. Une étude plus approfondie sera présentée dans les prochains chapitres.


7

Chapitre 3 Analyse et spécification des besoins ette

étape étant la première dans le cycle de développement du projet, elle est considérée très importante. En effet, c’est durant cette phase que les besoins de l’utilisateur sont identifiés et précisés. Dans ce chapitre nous allons représenter d’une façon détaillée les besoins fonctionnels et les besoins non fonctionnels de notre système ainsi que la spécification illustrée par les diagrammes de cas d’utilisation et les diagrammes de séquences.

C

3.1

identification des acteurs

Notre système est en interaction avec divers acteurs. Ils peuvent être des clients, l’administrateur ou l’gent de facturation. Les services offerts sont différents selon l’acteur. — l’administrateur : c’est le super utilisateur, ayant le plus haut degré d’accès, il peut se servir et contrôler l’intégralité des services offerts. — l’agent de facturation : c’est un principal utilisateur de notre système, il a accès seulement aux fonctionnalités relatives à la génération et envoi des factures. — le client : un espace sera destiné aux clients où chacun d’eux pourra consulter des informations relatives à ses factures ainsi qu’évaluer le service.

3.2

Etude des besoins

Dans cette section nous analysons les besoins qui sont classés en deux catégories : besoins fonctionnels et besoins non fonctionnels. Les besoins fonctionnels décrivent à quoi sert le système. Tandis que les besoins nons fonctionnels représentent les contraintes auxquelles le système doit répondre afin de garantir un bon déroulement.

8

ENSI 3.2.1

CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS Les besoins fonctionnels

Les besoins fonctionnels servent à déterminer les fonctionnalités et services offerts par le système pour chaque acteur.

Les fonctionnalités de point de vue administrateur — Lancer le processus de facturation : notre système permet à l’administrateur d’effectuer la facturation en lançant le processus débutant avec l’analyse de fichier en entrées et finissant par l’envoi des factures. — Ajouter client : l’administrateur peut à tout moment ajouter un client ceci peut être aussi engendré par le fait d’absence d’un client cité dans le fichier en entrée. — Consulter tableau de bord : afin d’assurer une bonne vision de l’activité de facturation. Notre système doit permettre à l’administrateur de retrouver dans un tableau de bord des diagrammes illustrant la situation de service. — S’authentifier : c’est une fonctionnalité primordiale car elle permet de identifier l’utilisateur et ainsi lui assurer les services qui lui sont permises.

Les fonctionnalités de point de vue client Le client bénéficie des fonctionnalités suivantes : — Consulter des informations relatives à ses factures : à travers un espace dédié à chaque client, il peut retrouver le nombre de factures rédigées dans son compte. Ainsi que visualiser la dernière facture qui lui a été envoyé, en plus de ses coordonnées (nom client, type, adresse). — Passer une réclamation : notre système permet au client s’il a une réclamation à propos d’une facture ou autre de l’envoyer à l’administrateur via email. — Évaluer le service : le système doit assurer le confort des clients et assurer leur satisfaction, pour cela, le site propose aux utilisateurs d’évaluer le service facturation offert par le système. — S’authentifier : c’est une fonctionnalité primordiale car elle permet d’identifier l’utilisateur et ainsi lui assurer les services qui lui sont permis.

Les fonctionnalités de point de vue agent (responsable) de facturation L’agent responsable d’effectuer la facturation sera en utilisation quotidienne de notre système. Ce dernier lui donne la possibilité de : — Lancer la facturation : ce service permet l’agent de générer et envoyer les factures correspondant aux commissions décrites par le fichier en entrée. stage d’immersion en entreprise

9

ENSI

CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

— Ajouter client : une autre fonctionnalité que le système doit assurer à l’agent de facturation est d’ajouter un client ceci lui permet d’inclure des nouveaux clients à tout moment ceci peut être engendré par le fait d’absence d’un client mentionné dans le fichier en entrée. 3.2.2

Les besoins non fonctionnels

Notre système doit assurer les besoins non fonctionnels suivants : — Le site doit présenter une interface ergonomique et convivale afin d’attirer les utilisateurs et garantir la facilité de manipulation des fonctions offertes. — Son fonctionnement doit être fiable et la réponse doit être rapide. — Le système garantit une certaine sécurité grâce à un système d’authentification qui limite les droits d’accès. — La compatibilité avec les navigateurs populaires (Chrome, Firefox, Opera et Internet Explorer)

3.3

Spécification des besoins

À travers cette section, nous tenons à clarifier les fonctionnalités assurées par notre système. Nous emploierons les diagrammes de cas d’utilisation et les diagrammes de séquence. 3.3.1

Diagrammes de cas d’utilisation

Ces sont des vues externes du système. Ils servent à modéliser l’interaction des acteurs avec le système qui est vu dans ce contexte comme une boîte noire. Le diagramme cas d’utilisation peut être accompagné de descriptions textuelles qui décrivent le déroulement de l’interaction acteur-système pour certaines actions. Afin de bien visualiser les cas d’utilisation de chaque acteur. Nous avons fait sorte que chacun des acteurs a un diagramme qui illustre ses cas d’utilisation du système.

3.3.1.1 Diagramme de responsable de facturation La figure ci-dessous présente les services offerts par le site au agent(responsable) de facturation. Une fois authentifié, il lui est possible d’ajouter un client ou de lancer le processus de facturation.


10

ENSI


Figure 3.1

– cas d’utilisation responsable de facturation

3.3.1.2 Diagramme de l’administrateur Le diagramme de la figure 3.2 montre les interactions possibles entre le système et l’administrateur. Après authentification„ l’administrateur peut tout comme l’agent de facturation ajouter un client ou lancer le processus de facturation.Mais il peut aussi faire le suivi de l’activité de facturation en recueillant des indicateurs relatifs à partir des charts de tableau de bord.


11

ENSI


Figure 3.2

– cas d’utilisation administrateur

3.3.1.3 Diagramme de client Comme nous pouvons le visualiser sur la figure suivante, le client a droit à divers services dans notre site.S’il est authentifié, il peut consulter des informations relatives à ses factures, donner son avis à propos de service de facturation en l’évaluant et enfin passer une reclamation qui sera reçue par l’administrateur de site.


12

ENSI


Figure 3.3

3.3.2

– cas d’utilisation client

Diagrammes de séquence

Après avoir décrit les différents cas d’utilisation de chaque acteur, nous donnerons dans cette section une description détaillé de déroulement de certaines interactions grâce aux diagrammes de séquence.

3.3.2.1 Diagramme de séquence "s’authentifier" L’authentification [6] est la procédure qui consiste pour un système informatique à vérifier l’identité d’une entité (personne, ordinateur,etc.) afin d’autoriser son accès aux systèmes,réseaux et applications. Pour pouvoir accéder aux services qui lui sont offerts par notre site, l’utilisateur (client, administrateur ou agent) est amené à s’authentifier. Pour cela il doit entrer son login et son mot de passe. Le système effectue une vérification. S’il est authentifié avec succès il gagne accès aux fonctionnalités. En cas d’échec, le formulaire de connexion est affiché de nouveau pour lui permettre de taper son login et mot de passe. stage d’immersion en entreprise

13

ENSI


Figure 3.4

– diagramme séquence authentification

3.3.2.2 Diagramme de séquence "ajouter client" Afin d’effectuer l’opération d’ajout d’un client, il faut que l’administrateur ou l’agent de facturation s’authentifie. Une fois identifié avec succès, il peut choisir le service « ajouter client ». Ainsi un formulaire sera affiché et l’utilisateur le remplit avec les informations du client et l’envoie. Le système vérifie la validité des champs et l’absence de client. Dans ce cas, il effectue l’opération d’ajout. Le terme utilisateur dans le diagramme désigne l’administrateur ou l’agent de facturation.


14

ENSI


Figure 3.5


– diagramme séquence ajout d’un client

15

ENSI


3.3.2.3 Diagramme de séquence "lancer la facturation" C’est le service principal pour lequel a été conçue le système. La fonctionnalité "facturation" est accessible à l’agent de facturation ainsi qu’à l’administrateur après authentification. L’opération démarre avec le choix d’un fichier en entrée qui doit être valide en matière d’extension et respectant le formatage employé dans le traitement. Si le fichier contient des commissions non déjà facturées il sera traité. le résultat final consiste en l’envoi d’un mail aux clients concernés avec en pièce jointe une facture résumant leurs commissions. On désigne par utilisateur dans le diagramme de la figure ci-dessous l’agent de facturation ou l’administrateur.


16

ENSI


Figure 3.6


– diagramme séquence facturation

17

ENSI


3.3.2.4 Diagramme de séquence "passer réclamation" Pour assurer un contact avec les clients et la satisfaction de ces derniers, notre système offre aux clients la possibilité de passer une réclamation le message sera transmis à l’administrateur de site via mail. Le diagramme de séquence ci-dessous illustre le déroulement de cette interaction client-système.

Figure 3.7

– diagramme séquence passer une réclamation


18

ENSI


3.3.2.5 Diagramme de séquence "évaluer service" Veillant sur la satisfaction des clients de notre service, notre système permet aux clients d’évaluer le service de facturation duquel il bénéficie et qu’assure notre site. Cette évaluation alimente un score de satisfaction client qui est ensuite visible à l’administrateur du site. Le système d’évaluation employée est celui des cinq étoiles. Ce système est un des plus communément utilisé sur le net.

Figure 3.8

– diagramme séquence évaluer service

Conclusion Dans ce chapitre nous avons identifié les différents utilisateurs ainsi que le rôle de chacun. Puis, à l’aide des diagrammes des cas d’utilisation et les diagrammes de séquences nous avons pu classer les services offerts par acteur et modéliser l’interaction des utilisateurs avec le système pour divers cas d’utilisation. Ce chapitre est primordial pour la conception que nous détaillerons dans la prochaine partie. stage d’immersion en entreprise

19

Chapitre 4 Conception près

l’élaboration de la spécification des différents services de notre site, la prochaine étape consiste en la mise en place d’une conception bien claire des différents services. Ainsi dans cette partie, nous fixerons l’architecture de notre application et nous présentons la conception globale dans ses deux vues physique et logique. La conception détaillée fera le sujet d’une deuxième section dans cette partie conception.

A

4.1 4.1.1

Conception globale Vue physique

Notre système est structuré selon l’architecture 3 tiers alors le site est réparti en trois éléments ayant des rôles bien défini : — client dit "léger" dans la mesure où il n’assume aucune fonction de traitement en opposition avec l’architecture 2 tiers (modèle client-serveur). il correspond dans notre cas au "navigateur web". — serveur d’applications qui prend en charge les traitements répondant aux requêtes du client. Ces opérations peuvent éventuellement faire appel à des données situées dans la base de données. — serveur de base de données chargé de ramener les données nécessaires pour traiter la requête provenant de client mais aussi de conserver les données.

20

ENSI

CHAPITRE 4. CONCEPTION

Dans la figure suivante, on illustre ce que nous avons précisé précédemment en montrant l’architecture 3 tiers avec l’emploi du PHP.

Figure 4.1

4.1.2

– architecture 3 tiers php

Vue logique

Nous avons choisi le patron de conception MVC (Modèle-Vue-Contrôleur). Le framework Symfony2 nous a permis d’implementer selon ce découpage qui est très répandu dans le développement web. Ceci est dû au fait qu’il sépare les couches selon leur logique propre en modèle, vue et contrôleur. Voyons de plus prés les éléments de cette architecture.

le contrôleur : il a pour rôle de prendre en entrée les requêtes http provenant d’utilisateur du site et génerer des réponses à ces requêtes. Pour réaliser ce rôle, il demande au modèle les données, les analyse, prend des décisions et renvoie le texte à afficher à la vue. Le contrôleur contient exclusivement du PHP. Notre sytème se base sur deux contrôleurs. Le premier étant le contrôleur principal facturationcontroller qui gère les différents services offerts par le site et la navigation dans ce dernier. Le deuxième contrôleur est nommé securitycontroller. Il est réservé à la securité de site et à la gestion des utilisateurs. le modèle : il est chargé de gérer les données du site. En accédant à la base des données de données, il récupère les informations nécessaires à la réponse et les organise pour qu’elles peuvent ensuite être exploitées par le contrôleur qui les reçoit. la vue : son rôle est l’affichage des pages qui ne sont que des réponses aux requêtes d’utilisateur. Elle est initiée par le contrôleur. Avec Symfony, les vues sont définies par des fichiers stage d’immersion en entreprise

21

ENSI


twig(moteur de templates PHP). Elle reçoit les résultats de traitement effectué par le contrôleur et prend en charge l’affichage de ces résultats sous forme de pages HTML interprétables par le client (navigateur web). À travers la figure suivante nous illustrons le modèle MVC.

Figure 4.2

4.2

– le modèle MVC

Conception détaillée

Dans cette section, nous détaillerons d’avantage la conception de notre système. Ainsi, nous définirons notre base de données et détaillerons les interactions avec le système à travers les diagrammes de séquence. Nous présenterons aussi le diagramme de classes de l’application.


22

ENSI 4.2.1

CHAPITRE 4. CONCEPTION diagramme de classes

Figure 4.3

– diagramme de classes

Pour traiter les requêtes utilisateurs, nous avons besoin des contrôleurs qui héritent de la classe Controller. Leur rôle est de retourner une réponse en exécutant l’action correspondant à la requête. Ce sont eux qui gèrent le logique métier de l’application. La classe Utilisateur est une entité implémentant l’interface UserInterface ainsi elle définit un fournisseur d’utilisateurs pour notre application Symfony. Cette entité permet de mapper ses instances (utilisateurs) avec la base de données et plus exactement la table utilisateur. FPDF et PHPMailer sont deux classes stage d’immersion en entreprise

23

ENSI


externes dont s’en sert le contrôleur pour générer les factures en PDF et les envoyer par la suite. Compte à Contact et ContactType ils permettent ensemble d’implémenter un formulaire Symfony avec validation. Ce formulaire est utilisé pour passer les réclamations. 4.2.2

Conception de la base de données

Notre site stocke les données dans une base de données relationnel appelée "gcf_commission". Afin de montrer la structure de notre base de données et décrire les relations entre ses différentes entités, nous présentons le modèle entité-relation illustré par la figure ci-dessous.

Figure 4.4


– modèle de la base de données

24

ENSI


Pour permettre la facturation à l’agent de facturation ainsi qu’à l’administrateur, on utilise cinq tables qui sont liées entre elles par différentes relations qui seront détaillées par la suite Les tables com_ctb_rus_daily et com_det_ctb stockent les commissions issues de fichier en entrée. Quant aux tables com_facture et com_det_facture, elles enregistrent respectivement l’entête et le détail des factures. La table client à son tour sert à stocker les clients pour lesquels on génère les factures. . Entre ces tables existent les liaisons suivantes : — le client possède 0 ou plusieurs factures. Une facture appartient à un et un seul client. — une facture contient une ou plusieurs commissions. Ces commissions se trouvent dans une et une seule facture. — un client est mentionné dans 0 ou plusieurs commissions. Une commission (détail commission) est propre à un et un seul client. Pour permettre aux clients de se connecter et utiliser les services qui lui sont offerts on utilise une table utilisateur. Les tables client et utilisateur sont liés par une liaison du type 1 : 1 Les clients, utilisateurs de site, peuvent évaluer le service facturation offert par le système. Cette évaluation alimente un indicateur affiché dans le tableau de bord de l’administrateur. Les évaluations sont stockées grâce à la table rating. Entre utilisateur et rating il y a une liaison de type un à plusieurs. L’utilisateur peut évaluer 0 ou plusieurs fois. Une évaluation est effectuée par un et un seul utilisateur. 4.2.3

Les diagrammes de séquence

Nous détaillerons dans cette section par les diagrammes de séquence, régissant cette fois les objets, le déroulement et les éventualités des cas d’utilisation ajouter client et lancer la facturation.


25

ENSI


4.2.3.1 Diagramme de séquence ajouter client

Figure 4.5

– Diagramme de séquence ajout d’un client

Ce diagramme présente les détails de l’interaction entre l’utilisateur et le système dans ses composants intervenant lors d’ajouts d’un client. L’utilisateur, authentifié avec succès comme l’agent de facturation ou l’administrateur, a accès au service ajouter client. S’il choisit ce service, une instance de facturationcontroller est créé. Recevant la requête d’utilisateur elle lance l’action ajout client. Ceci engendre le renvoi de la page d’ajout client affichant ainsi un formulaire à remplir. Ensuite, l’utilisateur est tenu de remplir ce formulaire et soumettre. Envoyé, les informations sont vérifiés pour tester si tous les champs sont non vides et valides. Si tous les champs sont corrects, l’existence de client est testé par le contrôleur. S’il est inexistant, le client est inséré dans la table client résultant l’affichage d’une notification par l’interface et ensuite un stage d’immersion en entreprise

26

ENSI


utilisateur correspondant au client est créé et inséré dans la table utilisateur. Sinon, un message informant de l’existence de client est renvoyé.

4.2.3.2 Diagramme de séquence lancer la facturation Tout comme l’ajout du client, le service de facturation est accessible seulement par l’agent de facturation et l’administrateur. Après authentification et s’ils choisissent le service facturation, une instance de facturationcontroller est créé. La requête d’utilisateur fait appel à l’action facturationAction du contrôleur. En réponse, la vue facturation est transmise à l’interface qui affichera un formulaire permettant le choix du fichier source de facturation par l’utilisateur. Après choix de fichier et soumission, le contrôleur teste la validité du fichier(format, etc.). S’il n’est pas valide une erreur est signalé sinon le fichier est parcouru et on teste la redondance des commissions. Si le fichier comporte des nouvelles commissions à facturer, elles sont enregistrés dans la table com det Ctb et la ligne entête et à son tour stocké dans com Ctb rus daily. Par la suite démarre la génération des factures client par client pour les clients ayant des commissions non facturées mentionnées dans le fichier source. chaque facture générée est envoyée comme pièce jointe dans un mail vers le client correspondant. L’adresse est issue de ligne correspondant au client dans la table client. Ainsi pour assurer le bon fonctionnement et avant de débuter la génération des factures l’existence des clients mentionnés dans le fichier est testé et si un client est inexistant le processus est terminé signalant l’inexistence d’un client et demandant de rajouter ce client pour pouvoir générer les factures à partir de fichiers choisis. À la fin du traitement une vue résumant l’opération est renvoyée à l’interface. Ainsi l’utilisateur visualisera des messages décrivant le déroulement de processus. Le diagramme ci-dessous illustre l’opération de facturation.


27

ENSI


Figure 4.6

– Diagramme de séquence lancer la facturation


28

Chapitre 5 Réalisation ans

les précédents chapitres, nous avons suivi les étapes de développement de notre application en démarrant de l’étude théorique à la mise en place d’une conception détaillée. Suivant cette logique, ce chapitre concernera l’aspect implémentation et développement. Nous débuterons par présenter l’environnement du travail. Ensuite, nous illustrerons la réalisation de notre travail par des imprimés-écrans. Nous terminerons par citer les difficultés rencontrées et présenter un chronogramme décrivant les étapes de mise en oeuvre de l’application.

D

5.1

Environnement du travail

Dans cette section nous décrivons l’environnement matériel et logiciel que nous avons utilisé pour arriver à réaliser notre projet. 5.1.1

Environnement matériel

Tout au long de ce travail, nous nous sommes servi d’un PC ayant les caractéristiques suivantes : — Marque : Lenovo — Processeur : Core i5 — Mémoire : 4 GO de RAM — Disque Dur : 1 TO — Système d’exploitation : Windows 8.1 5.1.2

Environnement logiciel

Éditeur de rapport : Pour rédiger ce rapport, nous avons employé Latex. Un langage de description qui permet 29

ENSI

CHAPITRE 5. RÉALISATION

d’obtenir des documents dont la mise en page est professionnelle étant destinée aux documents scientifiques. WampServer : WampServer est une plate-forme de développement Web sous Windows pour des applications Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP et d’une base de données MySQL. Il possède également PHPMyAdmin pour gérer plus facilement les bases de données. version :2.5 FPDF : FPDF est une classe PHP qui permet de générer des fichiers PDF en pur PHP. Le F de FPDF signifie Free : vous êtes libre de l’utiliser et de la modifier comme vous le souhaitez. Nous avons apprécié dans FPDF : — sa simplicité d’utilisation et d’intégration — sa documentation qui est bien illustrée par des exemples de démonstration. — FPDF ne nécessite aucune extension — peut produire des documents dans de nombreuses langues autres que le français

FusionCharts suite XT : Il s’agit d’une bibliothèque de cartographie Javascript qui est l’une des plus anciennes étant sortie pour la première fois en 2002. La version que nous utilisons est la version 3.7.1 qui a apparu cette année. Cette solution de cartographie englobe plus de 90 types de graphiques et 1000 types de cartes. Elle accepte des données sous forme JSON ou XML et donne des rendus qui sont adaptés à la fois au web et au mobile.

5.2

Travail réalisé

Dans ce qui suit, nous présenterons notre site et les interfaces qui assurent les fonctionnalités de notre système. Ainsi, nous montrerons les diverses pages de notre site par des captures accompagnés d’une brève description chacune. 5.2.1

Espace commun à tous les utilisateurs

page connexion : Il s’agit de la première étape emmenant vers l’utilisation des services offerts par le site. à travers le remplissage de formulaire de connexion et la soumission, l’identité d’utilisateur est déterminée (client, agent de facturation ou administrateur) s’il est authentifié avec succès sinon l’erreur est lui est signalé. stage d’immersion en entreprise

30

ENSI


Figure 5.1

5.2.2

– page connexion

Espace client

page d’acceuil client : Une fois authentifié, le client est redirigé vers la page d’accueil, elle lui permet d’accéder aux services qui lui sont offerts par le site.ces services apparaissent dans le menu en appuyant sur le bouton accédé aux services. Le client peut aussi évaluer le service de facturation de Bvmt et ainsi donner plus de vision aux dirigeants.


31

ENSI


Figure 5.2

– page d’acceuil client

menu client : la page indique un menu réservé aux clients qui leur permet de choisir entre passer une réclamation ou consulter des informations relatives à ses factures. Ce menu offre aussi la possibilité de se déconnecter.


32

ENSI


Figure 5.3

– menu client

page reclamation : Cette page offre le service de reclamation au client. Il n’a qu’à remplir les champs par son nom et son mail, un sujet pour sa réclamation et le message qu’il voudrait transmettre. Si ces champs sont valides le message est transmis par mail à l’administrateur du site. Le client a la possibilité de revenir vers la page d’accueil en cliquant sur le logo de la bourse de Tunis et de changer de service en appuyant sur changer de service pour réafficher le menu des services.


33

ENSI


Figure 5.4

– page reclamation

page infos : C’est une deuxième page consacrée aux clients. Elle présente au client ses informations telles que présente dans le service de facturation de BVMT. Aussi elle donne le nombre de factures envoyées par le système au client et lui donne la possibilité de consulter la dernière facture reçue dans le navigateur en PDF s’il en existe une.


34

ENSI


Figure 5.5

– page infos

Ci-dessous une capture montrant une facture visualisée dans le navigateur "Firefox"

Figure 5.6


– consulter facture 35

ENSI 5.2.3

CHAPITRE 5. RÉALISATION Espace agent de facturation

page accueil : Après authentification, l’agent de facturation se trouve sur la page d’accueil. le principal élément dans cette page est le bouton "Accéder aux services". En cliquant là-dessus le menu réservé à l’agent de facturation apparaît.

Figure 5.7

– page d’acceuil agent de facturation

menu agent de facturation : Le menu de l’agent de facturation offre deux services : "Facturation" permettant de lancer la facturation à partir d’un fichier plain txt en entrée et "Ajout client" pour ajouter un client éventuellement si on a besoin pour achever la facturation. Il lui offre aussi la possibilité de se déconnecter s’il n’a plus à utiliser le site.


36

ENSI


Figure 5.8

– menu agent de facturation

page facturation : Via cette page, l’agent lance le processus de facturation. il choisit le fichier plain qui sera source pour le processus de facturation et l’envoie en cliquant sur upload. Si le format et le formatage de fichier sont valides le processus se lancera. sinon, l’erreur sera signalée à l’agent. l’erreur peut provenir du fait que le format est invalide. Mais durant le processus de facturation d’autres sources d’erreurs apparaissent par exemple un client mentionné dans le fichier qui n’existe pas encore dans la base des clients de service. Face à cette erreur le processus s’arrête en demandant de rajouter le client. Si l’agent a besoin de changer de service il peut utiliser le bouton changer de service qui réaffiche le menu qui lui est réservé. Pour revenir à l’accueil, il n’a qu’à cliquer sur le logo de BVMT.


37

ENSI


Figure 5.9

– page facturation

page ajout client : À tout moment, l’agent peut à travers cette page ajouter un client. Pour cela, il introduit le code du client, son nom, son adresse, son adresse électronique et matricule fiscale. Il choisit aussi par une liste déroulante le type de client. Après avoir terminé il appuie sur ajouter client pour envoyer ses données. Le système valide ses données. Si le client n’existe pas il est ajouté engendrant aussi la création d’un utilisateur. Si une erreur existe concernant un champ ou le client est déjà existant. l’agent verra un message d’erreur relative au problème s’afficher.


38

ENSI


Figure 5.10

5.2.4

– page ajout client

espace administrateur

menu administrateur : L’administrateur partage avec l’agent de facturation les services facturation et ajout client et ait en plus un tableau de bord qu’il peut consulter pour évaluer le rendement de service de facturation en visualisant les diagrammes figurant dans la page. il est possible pour lui de se déconnecter en appuyant à partir de menu sur déconnexion.


39

ENSI


Figure 5.11

– menu administrateur

page tableau de bord : Cette page est spécifique à l’administrateur. Elle lui donne une idée sur le service et lui permet ainsi de prendre plus facilement les décisions. Le tableau de bord figure trois diagrammes : le premier montrant les cinq clients avec le plus de commissions facturées, le deuxième donne la distribution des commissions facturées selon le type, et le dernier présente le score de satisfaction client en se basant sur les évaluations effectuées par les clients.


40

ENSI


Figure 5.12

5.2.5

– page tableau de bord

Chronogramme

Il est nécessaire de donner le chronogramme qui décrit la répartition de tâches et ainsi le déroulement du projet. Le projet a duré un peu plus qu’un mois et demi . Par ce diagramme présent dans la figure ci-dessous on donne une vue d’ensemble sur la répartition dans le temps de travail demandé.

Figure 5.13


– chronogramme

41

ENSI


Conclusion Au cours de ce chapitre, nous avons décrit l’environnement matériel et logiciel autour duquel nous avons construit notre application et élaboré ce rapport. Ensuite, nous avons donné un aperçu sur le travail réalisé à l’aide de captures d’écran des interfaces de l’application en expliquant brièvement l’utilité de chacun. Nous clôturons par un chapitre consacré à une conclusion et des perspectives relatives à notre projet.


42

Conclusion et perspectives ous

sommes parvenus, en finalité de ce projet, à réaliser un site web dynamique qui couvre et facilite la tâche de facturation des commissions pour la Bourse de Tunis. Cet outil est accessible pour les clients, l’agent de facturation et l’administrateur. Chacun a son propre espace et des fonctionnalités qu’il peut s’en servir. Pour arriver à ce résultat, nous avons débuté par une présentation du projet et de son cadre. Ensuite, et après une étude théorique , nous avons précisé les besoins et les contraintes concernant l’application. Ces besoins sont mis en évidence dans la conception. Enfin nous avons passé à la réalisation. Durant cette étape, nous avons traduit la modélisation effectuée lors de conception en une implémentation moyennant différentes technologies. Nous tenons à souligner que travailler sur ce projet a été une expérience enrichissante dans deux niveaux. Il nous a permis d’explorer la vie professionnelle et voir comment sont réparties les tâches et comment sont gérés les projets au sein des SSII. D’autre part, il nous a permis d’approfondir les connaissances acquises tout au long de notre cursus universitaire notamment en matière d’analyse et conception orientée objet, conception des base de données et système de gestion de base de données et enfin la programmation web. Nous avons découvert aussi des nouvelles solutions technologiques. Afin de les utiliser, nous avons passé par la recherche et la documentation qui en la suivant nous avons pu s’en sortir dans la plupart des situations. Notre travail a encore des perspectives d’amélioration nous pouvons par exemple intégrer cette solution dans le site de la Bourse de Tunis. Aussi nous pouvons améliorer le service en rajoutant la fonctionnalité de payement en ligne. Ainsi le client pourra payer les factures qu’il reçoit de la part du système en consultant son espace dans le site.

N

43

rapport-de-stage14.pdf

Recommend Documents