Vous êtes sur la page 1sur 85

Institut Supérieur Du Génie Appliqué

Projet de fin d’études


Pour l’obtention du titre :
Ingénieur en Informatique
Option : Ingénierie Logiciel et Multimédia
Sous le thème :
ETUDE ET DEVLOPPEMENT D’UNE
PLATEFORME DE TAXATION POUR
LA TELEPHONIE SUR IP

Réalisé par : Jury :


Hassani Mohamed M. Mourad Raji
Benyadi Mourad M. Laalej Mohamed
M. Driss Bouzidi

Encadré par :
M. Bouzidi Driss
Mme Fadwa lahrach

Option : Ingénierie Logiciel et Multimédia Année universitaire : 2010 - 2011


Etudes et développement d’une plateforme pour la téléphonie sur IP
Etudes et développement d’une plateforme pour la téléphonie sur IP

Dédicace

A mes très chers parents,


Aucun mot ne pourra exprimer mes sentiments envers vous.

A mes chères sœurs,


A mes chers frères,
Je ne sais comment vous remercier pour tout ce que vous avez fait pour moi.

A toute ma famille.
A tous mes chers amis d’Azrou,
A mes chers amis de l’école,
A mes très chers frères et amis de la ville de Rabat,
Pour tout le soutien que vous m’avez offert, je vous dis MERCI.

A tous ceux qui m’aiment.


A tous les musulmans à travers le monde, je dédie ce travail…

Hassani Mohamed
Etudes et développement d’une plateforme pour la téléphonie sur IP

Dédicace

A mes très chers parents,


Aucun mot ne pourra exprimer mes sentiments envers vous.

A mes chères sœurs,


A mes chers frères,
Je ne sais comment vous remercier pour tout ce que vous avez fait pour moi.

A toute ma famille.
A tous mes chers amis de Berkane,
A mes chers amis de l’école,
A mes très chers frères et amis de la ville de Rabat,
Pour tout le soutien que vous m’avez offert, je vous dis MERCI.

A tous ceux qui m’aiment.


A tous les musulmans à travers le monde, je dédie ce travail…

Benyadi Mourad
Etudes et développement d’une plateforme pour la téléphonie sur IP

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.

Ainsi, nous exprimons notre profonde gratitude et tenons à remercier tout le personnel
d’INTELCOM et plus précisément l’équipe d’étude et développement, pour leur soutien et
pour leur générosité considérable quant à l’offre de l’information.

Nous tenons à exprimer nos gratitudes à Mlle Fadwa Lahrach, notre encadrante à
l’entreprise, qui nous a proposé un sujet très intéressant.

Nos remerciements les plus sincères vont à M. Bouzidi Driss, notre encadrant à l’IGA,
pour les conseils qu’elle nous a prodigué, son judicieux encadrement ainsi que son assistance
pour la rédaction du rapport.

Nos remerciements s’adressent également à M. Mourad Raji, M. Mohamed Baidada,


Mlle Fadwa el Idrissi pour avoir été toujours à l’écoute, et pour leurs conseils et
éclaircissements.

Que messieurs les membres de jury trouvent ici l’expression de nos reconnaissances
pour avoir accepté de juger notre travail.

Que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement de ce
travail trouvent l’expression de nos remerciements les plus chaleureux.

Projet de fin d’études 2010 - 2011 0


Etudes et développement d’une plateforme pour la téléphonie sur IP

Résumé

Ce rapport est le fruit du travail que nous avons réalisé dans le cadre de notre projet de
fin d’étude au sein de la société Intelcom. Ce projet avait pour objectif d’étudier et développer
une plateforme de taxation pour la téléphonie sur IP.

Ce projet assure la gestion comptable et le contrôle des appels téléphoniques. Elle


permet un suivi intelligent de tous les appels – qu'il s'agisse de téléphonie classique ou de
téléphonie internet (VoIP) – passés sur le réseau de l'entreprise. Ce suivi se fait par la
génération des rapports et des factures pour chaque niveau choisi par l’utilisateur.

Pour le développement du projet, nous avons suivi le cycle de développement en Y


(2TUP).

Pour la modélisation du système, nous avons utilisé le langage UML.

La réalisation du projet est basée sur les nouvelles technologies du Web. En effet, nous
avons eu recours à plusieurs Frameworks traitant plusieurs aspects du développement sous la
plate-forme J2EE. Nous avons donc utilisé le Framework Struts pour la présentation Web, le
Framework JasperReports pour l’édition des rapports.

Le présent rapport permet de présenter les différentes étapes par lesquelles nous
sommes passés afin de réaliser le travail qui nous a été confié.

Projet de fin d’études 2010 - 2011 1


Etudes et développement d’une plateforme pour la téléphonie sur IP

Sommaire

Liste des abréviations…………………..………………………………………………………………..4


Liste des figures.………………………………………………………………………………………...5
Liste des tables….…………………………………………………….…………………………………6
Introduction ...…….……………………………………………………………………………………..7
Chapitre 1 : Contexte général du projet…..………………………………………………………….8
Introduction……………………………………………………………………………………..9
1 Présentation de l’entreprise.............................................................................................................9
1.1 INTELCOM............................................................................................................................9
1.2 Organisation d’INTELCOM...................................................................................................9
1.3 Services du Groupe SATEC.................................................................................................10
2 Présentation du projet...................................................................................................................12
1.1 Cadre général du projet.........................................................................................................12
2.1 Objectifs du projet................................................................................................................12
3 Généralités sur La téléphonie sur IP et la taxation........................................................................14
3.1 Historique de la téléphonie sur IP :.......................................................................................14
3.2 La téléphonie sur IP :............................................................................................................14
3.3 Réseaux en concurrence :......................................................................................................14
3.3.1 Le réseau TCP/IP ou Internet :..........................................................................................15
3.3.2 Le réseau RTC :................................................................................................................15
3.3.3 Le réseau RNIS :...............................................................................................................15
3.4 Différentes architectures de téléphonie sur IP :.....................................................................16
3.4.1 Micro-ordinateurs à micro-ordinateurs :...........................................................................16
3.4.2 Micro-ordinateur à poste téléphonique :............................................................................16
3.4.3 Postes téléphoniques à Postes téléphoniques :..................................................................17
3.5 La taxation et la téléphonie sur IP :.......................................................................................17
4 Conduite du projet........................................................................................................................19
4.1 Processus de développement.................................................................................................19
4.2 Planification du projet...........................................................................................................20
Conclusion……………………………………………………………………………………..21
Chapitre 2 : Étude fonctionnelle du projet………………………………………………………….22
Introduction……………………………………………………………………………………23
1 Capture des besoins fonctionnels..................................................................................................23
1.1 Analyse comparative des solutions.......................................................................................23
1.2 Etude de l’existant :..............................................................................................................25
1.3 Services attendus de la plateforme de taxation......................................................................27
1.4 Méthode de calcul du cout d’appel.......................................................................................28
2 Analyse.........................................................................................................................................32
2.1 Elaboration des cas d’utilisation...........................................................................................32

Projet de fin d’études 2010 - 2011 2


Etudes et développement d’une plateforme pour la téléphonie sur IP

2.2 Construction des diagrammes de séquences:........................................................................33


2.3 Analyse du comportement des entités dégagées :..................................................................36
Conclusion…………………………………………………………………………………….37
Chapitre 3 : Étude technique du projet …………………………………………………………….39
Introduction……………………………………………………………………………………40
1 Technologie J2EE.........................................................................................................................40
1.1 Architecture J2EE.................................................................................................................41
1.2 Composants de base de J2EE................................................................................................42
2 Architecture logicielle du système................................................................................................44
2.3 Objectif technique de l’architecture de la plateforme de taxation.........................................44
2.4 Architecture logicielle de Taxation :.....................................................................................45
3 Les Frameworks :.........................................................................................................................48
3.1 Le Framework SPRING :......................................................................................................48
3.2 Le Framework Struts:...........................................................................................................49
3.3 Le Framework Jasper report :...............................................................................................50
Conclusion……………………………………………………………………………………..51
Chapitre 4 : Conception et mise en œuvre du projet……………………………………………….52
Introduction…………………………………………………………………………………....53
1 Conception....................................................................................................................................53
1.1 Conception préliminaire........................................................................................................53
1.1.1 Enumération des vues de l’application..............................................................................53
1.2 Conception détaillé :.............................................................................................................55
2.1.1 Le diagramme des classes :...............................................................................................56
2.1.2 Le schéma relationnel.......................................................................................................58
2 Mise en œuvre..............................................................................................................................60
2.1 Mapping objet/relationnel :...................................................................................................60
2.2 Implémentation des IHM......................................................................................................60
Conclusion..................................................................................................................................63
Conclusion et perspectives……………………………………………………………………………..64
Bibliographie............................................................................................................ …………………..65
Annexe 1 : Le processus 2TUP…………...............................................................................................66
Annexe 2 : UML……………………………………………………………………………………….68
Annexe 3 : Cahier de charges.................................................................................................................69
Annexe 4 : Conception détaillée…..…………………………………………………………………...73
Annexe 5 : Schéma relationnel………………………………………………...………………………77

Projet de fin d’études 2010 - 2011 3


Etudes et développement d’une plateforme pour la téléphonie sur IP

Liste des abréviations


Abréviation Désignation
2TUP Two Track Unified Process
ASP Active Server Pages
IHM Interface Homme Machine
JSP Java Server Page
L'Agence Nationale de Réglementation des
ANRT
Télécommunications
BMP Bean Managed Persistance
CDR Call Detail Records
CMP Container Managed Persistance
EJB Entreprise Java Bean
GPL General Public License
HTML Hypertext Markup Language
IAM  Itissalat al-Maghreb
IP Internet Protocole
J2EE Java Enterprise Edition
LAN local area network
Mbone Multicast Backbone
MySQL My Structured Query Language
OMG Object Management Group
OMT Object Modeling Technique
OOSE Object Oriented Software Engineering
OSS Open-source software
PBX Private branch exchange
PC Personnel Computer
QoS La qualité de service ,
RUP Rational UnifiedProcess
SGBD Systèmes de Gestion de Bases de Données
TIC Technologies de l'information et de la communication
ToIP Téléphony over IP
UML Unified Modelling Language
VoIP La téléphonie sur IP
XML eXtensible Markup Language

Projet de fin d’études 2010 - 2011 4


Etudes et développement d’une plateforme pour la téléphonie sur IP

Liste des figures

Figure 1 : l’organigramme d’Intelcom......................................................................................10


Figure 2 : Les activités d’intelcom............................................................................................11
Figure 3 : La téléphonie sur IP de PC à PC...............................................................................16
Figure 4 : La téléphonie sur IP de PC à téléphone....................................................................16
Figure 5 : la téléphonie sur IP de téléphone à téléphone...........................................................17
Figure 6 : diagramme de ressource du projet............................................................................21
Figure 7 : diagramme de gantt..................................................................................................21
Figure 8: l’architecture de la solution de facturation Phonex One............................................26
Figure 9 : Diagramme des cas d’utilisation...............................................................................33
Figure 10 : Diagramme de séquences de la génération des rapports........................................34
Figure 11 : Diagramme de séquences du paramétrage de la plateforme...................................35
Figure 12 : Diagramme de séquences de la gestion des utilisateurs.........................................35
Figure 13: Diagramme de séquences de la génération de rapports par l’employé....................36
Figure 14 : l’architecture J2EE.................................................................................................41
Figure 15 : objectifs techniques de l’architecture logicielle de la plateforme de taxation........44
Figure 16 : architecture de la plateforme de taxation en couches............................................46
Figure 17 : Architecture MVC II..............................................................................................50
Figure 18 : Les étapes de création du rapport par JasperReports..............................................51
Figure 19 : Diagramme des classes du module de gestion de factures.....................................56
Figure 20 : Diagramme des classes du module de gestion des tarifs........................................57
Figure 21: Diagramme des classes du module de gestion des dépenses et rapports.................58
Figure 22 : Schéma relationnel du module de gestion des dépenses et rapports......................59
Figure 23 : Interface de l’administration...................................................................................61
Figure 24 : Interface de l’ajout et suppression d’un utilisateur.................................................62
Figure 25 : Interface de l’ajout d’un tarif : choix d’opérateur..................................................62
Figure 26 : Interface de l’ajout d’un tarif : Information sur tarif..............................................63
Figure 27 : Interface de l’ajout d’un tarif : Information sur la date spéciale............................63
Figure 28 : Le processus 2Tup..................................................................................................66
Figure 11-1. : Situation de la conception détaillée dans 2TUP……………………………….74
Figure 11-2. : Micro-processus de conception détaillée…………………………………….. 75

Projet de fin d’études 2010 - 2011 5


Etudes et développement d’une plateforme pour la téléphonie sur IP

Liste des tables

Table 1: Etude comparative des cycles de développement.......................................................20


Table 2 : les taches du projet.....................................................................................................20
Table 3 : comparatif des solutions de facturation.....................................................................25
Table 4 : Les tarifs de l’abonnement classique.........................................................................29
Table 5 : les tarifs de l’offre préférence Groupe.......................................................................29
Table 6 : les tarifs de l’offre préférence Groupe.......................................................................30
Table 7: les tarifs de l’offre préférence International vers fixe.................................................30
Table 8 : les tarifs de l’offre préférence International vers mobile...........................................31
Table 9 : objectifs techniques de l’architecture logicielle de la plateforme de taxation...........45
Table 10 : Les IHM pertinents de la plateforme de taxation.....................................................55

Projet de fin d’études 2010 - 2011 6


Etudes et développement d’une plateforme pour la téléphonie sur IP

INTRODUCTION

La téléphonie sur IP (ou VoIP pour Voix sur IP) est un mode de téléphonie utilisant le
protocole de télécommunications créé pour Internet (IP pour Internet Protocol). La voix est
numérisée puis acheminée sous forme de paquets comme n'importe quelles autres données.
Ainsi, l'évolution à la baisse du prix de la bande passante offre de réelles économies à
l'entreprise. De plus, avec une solution IP-PBX les appels à l'intérieur de l'entreprise sont
gratuits de fait. 
En bref, l'augmentation des débits Internet et les économies réalisées sur la facture
télécom suscitent l'engouement des entreprises, donc en attendant sa vulgarisation il faut
penser à des techniques de facturation et mesure de trafic pour réglementer l’accès au réseau,
et garantir aux utilisateurs une qualité de service acceptable.
C’est dans cette optique que s’inscrit ce projet. En effet, Le but est d’étudier et
développer une plateforme de taxation pour la téléphonie sur IP qui collecte les informations
sur les appels à partir d’une base de données, les traite, les analyse, puis les affiche sous des
formats bien présentés à l’administrateur et aux utilisateurs.
Le présent rapport décrira dans le premier chapitre l’organisme au sein duquel nous
avons effectué notre projet de fin d’études ‘Intelcom’, ses services et son organisation. Et
après des généralités de la téléphonie sur IP nous introduisons le cadre général, les objectifs
de notre projet, la démarche que nous avons adoptée et la planification.
Le deuxième chapitre, comporte l’étude fonctionnelle du projet qui se compose de
deux étapes, une étape de capture des besoins fonctionnel et une étape d’analyse. La première
comporte une analyse comparative des solutions ; une étude de l’existant et les services
attendus de la plateforme .La deuxième comporte l’élaboration du diagramme statique ;
dynamique du projet et par la fin une analyse du comportement des entités dégagées.
Le troisième chapitre, présente la technologie J2EE adoptée pour la plateforme de
taxation. De plus, une explication de l’architecture logicielle caractérisant l’application.
Ensuite, une exposition des Frameworks Open Source choisi pour le développement.
Et pour le quatrième chapitre, c’est la partie restante du processus suivi qui se
compose de la conception préliminaire, la conception détaillée et à la fin la mise en œuvre du
projet.

Projet de fin d’études 2010 - 2011 7


Chapitre 1 : Contexte général du projet

Chapitre 1 :
Contexte général du projet

Dans ce chapitre, nous présentons l’organisme au sein


duquel nous avons effectué notre projet de fin d’études
Intelcom, ses services et son organisation. Et Après des
généralités de la téléphonie sur IP nous introduisons le cadre
général, les objectifs de notre projet, la démarche que nous
avons adoptée et la planification.

Projet de fin d’études 2010 - 2011 8


Chapitre 1 : Contexte général du projet

Introduction
Comme nous l’avons indiqué auparavant, notre projet s’est déroulé au sein d’Intelcom,
dont le fonctionnement est axé autour de plusieurs activités, et se base sur un système
d’information mature.

1 Présentation de l’entreprise
1.1 INTELCOM

INTELCOM appartient au Groupe SATEC: une société multinationale espagnole


d’intégration de solutions technologiques, spécialisée dans les services avancés liés aux
nouvelles Technologies de l’Information. Elle a privilégié depuis 1987 la collaboration avec
ses clients à travers l’innovation dans les processus, les ressources et les technologies,
contribuant ainsi au changement, à la productivité et à la compétitivité dans leur activité.

Les principes qui régissent ses actions sont les suivants : une base technologique
solide et la haute qualification du personnel, combinées à une gestion experte des
fournisseurs, en veillant constamment à la qualité du produit ou du service, à une innovation
permanente, à une longue expérience dans la mise en place de solutions chez plus d’un millier
de clients et à une relation privilégiée avec ses partenaires technologiques, toujours tournés
vers le client et avec l’engagement ferme d’offrir des solutions et des services innovateurs
adaptés à ses besoins spécifiques.

L’effectif de la société s’élève actuellement à plus de 1200 personnes. Société à capital


espagnol, Groupe SATEC est aujourd’hui un groupe d’entreprises international activement
présent dans sept pays.

En complément de son activité principale, le groupe SATEC détient à 100% une


entreprise de fourniture de solutions spécifiques, dénommée InterHost et spécifiquement
spécialisée dans le domaine des solutions d’ingénierie de centres de données et d’hébergement
de systèmes d’information.

1.2 Organisation d’INTELCOM

Projet de fin d’études 2010 - 2011 9


Chapitre 1 : Contexte général du projet

Figure 1 : l’organigramme d’Intelcom

1.3 Services du Groupe SATEC

Groupe SATEC dispose d’une grande gamme de Solutions et de Services TIC qui
couvrent les besoins du Client, recueillent et analysent leurs exigences pour leur
développement, leur mise en place et leur maintenance ultérieures. Cette expérience a
également servi à offrir des solutions et des services spécifiques aux secteurs
d’activité suivants:

 Administrations Publiques
 Opérateurs de Télécommunications
 Santé
 Industrie
 Banque
 Assurances

Les services de Groupe SATEC sont basés sur une architecture modulaire, extensible
et ouverte qui permet de s’adapter aux divers besoins de ses clients.

Projet de fin d’études 2010 - 2011 10


Chapitre 1 : Contexte général du projet

L’éventail de services de Groupe SATEC comprend différents modules qui permettent


d’adapter l’offre de la société aux besoins réels de ses clients. L’illustration suivante résume
l’éventail de services de Groupe SATEC:

Figure 2 : Les activités d’intelcom

Projet de fin d’études 2010 - 2011 11


Chapitre 1 : Contexte général du projet

2 Présentation du projet
1.1 Cadre général du projet

Le monde numérique actuel présente de nouveaux défis et de nouvelles opportunités


pour les grandes sociétés, situation dont ont tiré parti les opérateurs de télécommunications
pour offrir de nouveaux services à leurs clients, aussi bien sur le plan national
qu’international, pour se fusionner ou réaliser de nouvelles acquisitions leur permettant
d’offrir un portefeuille complet de services basés sur la convergence voix-données.

Le besoin continu du secteur de se réinventer fait que l’innovation constitue la clé de


la croissance rentable et durable des opérateurs de télécommunications, laquelle est basée sur
le processus de transformation des idées en processus métier substantiellement plus efficaces
et différenciateurs.

Groupe SATEC dispose d’une gamme de solutions et de services spécifiquement


adaptés aux opérateurs de télécommunications, conçus pour aider leurs clients à faire face aux
défis actuels et à venir, tels que par exemple :

 Développements sur mesure


 Solutions de Gestion et OSS
 Sécurité
 Services mobiles

Groupe SATEC possède dans les domaines des réseaux, systèmes, sécurité et
développement, elle se trouve dans des conditions privilégiées pour aborder des solutions de
gestion et OSS. Les principaux domaines développés par la Société sont :

 Gestion de réseaux, systèmes et services


 Gestion des évènements et des incidents
 Gestion des performances
 Systèmes d’approvisionnement
 Inventaire
 Médiation et facturation ; émission de données de facturation, analyse de logs,
agrégation de flux, systèmes de prépaiement, etc.
C’est dans ce dernier domaine de Médiation et facturation que nous avons effectué notre
stage de fin d’études.

1.2 Objectifs du projet

Notre projet de fin d’études, effectué au sein la société Intelcom consiste à étudier et
développer une plateforme de taxation pour la téléphonie sur IP, en termes d’architecture et
application. Les fonctionnalités de cette application sont :
 Générer des factures et rapports,
 Permettre la réduction des frais de la communication,
 Sensibilisation de l’employé.

Projet de fin d’études 2010 - 2011 12


Chapitre 1 : Contexte général du projet

La facturation sera basée sur les résultats des appels enregistrés par un outil de Cisco
appelé ‘ Call manager’ dans une base de données.
Il s’agit dans un premier temps d’étudier les concepts fondamentaux (aspects, normes
et constructeurs) sur lesquels repose la téléphonie sur IP. Ainsi d’étudier les méthodes de
calcul des coûts des appels par les opérateurs et analyser les tarifs disponibles.
Après cette première étape, on débutera le développement de l’application web suivant
les étapes, les méthodes et processus étudiées dans notre formation en ingénierie logiciel et
Multimédia à l’IGA.

Projet de fin d’études 2010 - 2011 13


Chapitre 1 : Contexte général du projet

3 Généralités sur La téléphonie sur IP et la


taxation
31 Historique de la téléphonie sur IP :
C’est au début des années 80 que sont apparues les applications temps réel sur les
LANs. Les réseaux disposaient alors d’une bonne bande passante (réseau Ethernet à 10
Mbit/s) et les stations de travail avaient une bonne puissance de traitement de l’information,
ce qui a permis l’échange des flux audio, vidéo, etc.
Mais le développement des applications de voix et vidéo sur Internet a explosé avec la
naissance du Mbone (Multicast Backbone). Il s’agit d’un réseau de diffusion multipoint créé à
l’origine pour un besoin interne de l’IETF5qui désirait pouvoir diffuser en visioconférence ses
réunions afin de pouvoir joindre ses correspondants empêchés de se déplacer. La technique
Mbone fut conçue au Xerox Parc6 puis adoptée par l’IETF en mi-1992. Il s’agit en fait d’un
réseau superposé au réseau Internet classique où les paquets multicasts ont encapsulés dans
des paquets IP classiques, puis traités dans des routeurs capables de les exploiter. Ce réseau
était techniquement nécessaire pour éviter de saturer le réseau classique en envoyant autant de
flux audio/vidéo (gourmands en bande passante) que de destinataires : la solution consistait à
regrouper les flux qui empruntent une même route puis à les expanser dans des routeurs
“multicast” au fur et à mesure que les routes divergent pour joindre le destinataire final.
Une autre composante non moins essentielle de la naissance de la téléphonie sur IP fut
le développement de codeur bas débit. Ces codeurs se classent en trois grandes classes suivant
les techniques de codage utilisées :

 techniques temporelles
 techniques paramétriques
 techniques par analyse et synthèse.

Beaucoup de logiciel de téléphonie ont été créés, mais c’est l’émergence des serveurs
d’accès entre les réseaux IP et le réseau téléphonique commuté qui a réellement propulsé la
téléphonie sur IP et a attiré l’attention des opérateurs de part et d’autre.

32 La téléphonie sur IP :

La téléphonie sur IP (ou VoIP pour Voix sur IP) est un mode de téléphonie utilisant le
protocole de télécommunications créé pour Internet (IP pour Internet Protocol). La voix est
numérisée puis acheminée sous forme de paquets comme n'importe quelles autres données. 
Pourquoi migrer vers une solution de téléphonie IP ? L'augmentation des débits Internet et les
économies réalisées sur la facture télécom suscitent l'engouement des entreprises. Sécurité,
infrastructure ou coût réel sont des paramètres à prendre en compte avant de bouger. 

33 Réseaux en concurrence :

L’utilisation simple et croissante du protocole IP dans les réseaux est devenue question
cruciale pour le monde des télécommunications. L’intégration de la voix et données sur ces

Projet de fin d’études 2010 - 2011 14


Chapitre 1 : Contexte général du projet

réseaux est aujourd’hui la grande occupation des opérateurs dans ce domaine. Pour cela il faut
tout d’abord savoir les caractéristiques des réseaux qui vont coopérer entre eux pour le projet
de la téléphonie sur IP.

1.1 Le réseau TCP/IP ou Internet :

Le réseau régi par le protocole TCP/IP (Transport Control Protocol / Internet


Protocol) est le réseau Internet qui a pour but l’interconnexion de réseaux sur une base
planétaire, cette technologie issue des années 1970, interconnecte aujourd’hui plusieurs
millions de réseaux divers : Ethernet, X25, FR, FDDI, etc.
Le réseau TCP/IP est constitué par des protocoles de base qui offrent les services de
base du transfert des données :
- Transport de datagrammes : service élémentaire de la commutation de paquets.
- Transport de messages sécurisés : service orienté connexion permettant d'acheminer
des données en garantissant leur intégrité.
Il y a plusieurs applications standards bâties sur cette technologie de base : courrier
électronique, transfert de fichier, etc.

1.2 Le réseau RTC :

Le réseau public de téléphonie, utilise une paire de cuivre comme support physique et
était historiquement utilisé pour fournir des services de voix analogique. Il essaye aujourd’hui
d’intégrer les technologies numériques autorisant de nouveaux services (Le RNIS).
Le réseau d’accès téléphonique comme le réseau de transport longue distance associé
restent aujourd’hui des réseaux dédiés basés sur la commutation de circuits (TDM). Ils
possèdent de nombreuses interconnexions afin de gérer les communications internationales,
fixe vers mobile ou encore d’un opérateur à un autre pour une même communication.
Pour suivre le développement des télécommunications, plusieurs opérateurs ont
développé des infrastructures pour offrir des services voix à leurs clients. Parallèlement, ces
mêmes opérateurs ont étendu leurs offres de services afin de proposer à leurs clients,
majoritairement des entreprises, le transport de données. Ces offres ont donc amené les
opérateurs du marché (voix/données) à développer des réseaux convergents de type paquets,
afin d’optimiser leur infrastructure.

1.3 Le réseau RNIS :

Le RNIS (Réseau Numérique à Intégration de Services), connu au Maroc sous le nom


commercial donné par Maroc Télécoms Marnis, est défini comme suit par le Livre Rouge de
l’UIT-T: « Un réseau Numérique à Intégration de Services est un réseau développé en général
à partir d'un réseau téléphonique numérisé, qui autorise une connectivité numérique de bout
en bout assurant une large palette de services, vocaux ou non, auxquels les usagers ont accès
par un ensemble limité d'interfaces polyvalentes ».

Projet de fin d’études 2010 - 2011 15


Chapitre 1 : Contexte général du projet

Marnis, c'est l'utilisation combinée de deux types de canaux de transmission appelés


canal B (Bearer Channel) pour le transfert de données en mode commutation de circuit, et
canal D (Data Channel) pour la signalisation et le transfert de données en mode commutation
de paquets. Il est également possible d’utiliser le canal D pour accéder au réseau de
communication de paquets Maghrepac. Le nombre des canaux B et le débit du canal D
dépendent du type d'accès. On distingue deux types d'accès :l’accès de base et l’accès
primaire.

34 Différentes architectures de téléphonie sur IP :


3.4.1 Micro-ordinateurs à micro-ordinateurs :

Figure 3 : La téléphonie sur IP de PC à PC.

L’architecture PC to PC est la solution la moins chère mais aussi la plus facile à mettre
en œuvre. Elle est surtout destinée aux utilisateurs occasionnels et ne nécessite pas de matériel
particulier : carte son Full Duplex, un casque et un micro. Les logiciels quant à eux sont très
disponibles. Pour ce qui est du coût, vous ne payez que votre connexion à Internet et ceci
quelle que soit la distance à laquelle vous appelé tout en sachant que les deux correspondants
paient.

Projet de fin d’études 2010 - 2011 16


Chapitre 1 : Contexte général du projet

3.4.2 Micro-ordinateur à poste téléphonique :

Figure 4 : La téléphonie sur IP de PC à téléphone.

Le PC à téléphone consiste à appeler un téléphone depuis un ordinateur. C’est


actuellement la technique la plus utilisée et la plus simple à mettre en œuvre. Mais il faut
savoir que ce n’est pas toujours rentable. En effet, qui dit téléphone, dit réseau téléphonique.
Vous êtes alors obligé de payer pour la portion correspondant à la distance entre le POP local
de votre correspondant ( “Point of Presence” : Endroit où converge le réseau téléphonique et
l’Internet.) et votre correspondant. Cette solution s’applique donc surtout à ceux qui appellent
souvent à l’étranger et plus particulièrement aux Etats-Unis ou au Canada car il existe des
offres de VoIP pour appeler vers ces pays.
Pour appeler un téléphone à travers son ordinateur, on a besoin d’un micro et
d’écouteurs, ainsi qu’une connexion à Internet. On peut ainsi utiliser son téléphone avec la
seule contrainte de lancer un programme.
Cependant, cette formule est peu intéressante si on appelle en local ou même en
national et parfois les tarifs sont supérieurs à ceux des opérateurs téléphoniques classiques. On
doit en plus dans la plupart des cas ouvrir un compte prépayé chez l’opérateur de VoIP. En
revanche, du fait du faible coût des communications locales en Amérique du Nord, certains
opérateurs de VoIP offrent les communications vers les Etats-Unis et le Canada.

3.4.3 Postes téléphoniques à Postes téléphoniques :

Figure 5 : la téléphonie sur IP de téléphone à téléphone.

Projet de fin d’études 2010 - 2011 17


Chapitre 1 : Contexte général du projet

Le phone to phone est l’application ultime de la téléphonie IP. En effet, à partir de cet
instant, l’ordinateur est totalement oublié. On utilise un téléphone comme à la maison ou au
bureau et avec la même simplicité. Evidemment, cette solution est d’abord réservée aux
entreprises car celles-ci bénéficient du haut débit et des infrastructures très adaptées.
Pour utiliser cette solution, il faut donc un réseau haut débit d’un opérateur et des
téléphones IP. Une autre solution consiste à sacrifier un peu de qualité et de passer par
Internet via des IAP (Internet Access Provider), qui est un réseau beaucoup plus lent mais
universel dans le sens où on peut pratiquement joindre n’importe quel ordinateur ou téléphone
IP partout dans le monde.

35 La taxation et la téléphonie sur IP :

Indépendamment des aspects liés aux tarifs pratiqués tant dans le domaine de la
téléphonie traditionnelle que dans celui de l'utilisation d'Internet, il y a quelques raisons
objectives pour que les communications sur IP soient en principe moins coûteuses que les
communications sur le réseau téléphonique commuté classique.
La première raison est inhérente à la mise en œuvre de la transmission de la voix par
paquets qui, par nature, utilise mieux les liaisons de télécommunications (tout au moins au-
delà des liaisons terminales de raccordement de l'utilisateur) que la technique de commutation
de circuits qui dédie un circuit de bout en bout à chaque communication téléphonique sans
tenir compte des temps morts de la conversation.
De plus, pour la téléphonie sur IP, pour s'accommoder des différents maillons de la
chaîne côté utilisateur (rapidité des modems notamment, dans le cas de l'utilisation de micro-
ordinateurs), on pratique une compression de l'information numérique qui fait passer la voix
numérisée du débit standard de 64 kbit/s à un débit de moins de 10 kbit/s, d'où là encore une
meilleure utilisation des liaisons.
Ces deux raisons sont à nuancer par le phénomène de baisse constante des coûts de
transmission notamment sur fibre optique.
Une troisième raison concerne la nature des équipements mis en œuvre : il s'agit, dans le
cas de la voix sur IP, d'équipements (serveurs, routeurs…) en synergie avec les équipements
du monde de la microinformatique et qui, de ce fait, bénéficient des mêmes évolutions de
coûts que ce domaine. On aboutit ainsi à la mise en œuvre d'équipements moins sophistiqués
(un routeur est beaucoup moins rapide qu'un commutateur de circuits) et moins coûteux (mais
aussi avec des fonctionnalités plus rudimentaires) que les commutateurs qui interviennent
dans les réseaux de télécommunications.

Enfin, en corollaire de cette conception différente des équipements, on est conduit dans le
cas de la téléphonie sur IP à accepter des fonctionnalités différentes de celles de la téléphonie
classique, notamment en termes de qualité de service.

Projet de fin d’études 2010 - 2011 18


Chapitre 1 : Contexte général du projet

4 Conduite du projet 
4.1 Processus de développement

Le processus de développement adopté est le processus en Y ou Two Track Unified


Process (2TUP). Ce processus itératif et incrémental, dérive du « Unified Process », mais il
consacre plus d’importance pour les aspects techniques auxquels il réserve toute une branche
de son cycle. Cet intérêt a pour but de réduire le risque technologique.
Y ne se contente pas des risques technologiques, mais il assure aussi une gestion des
risques de toute nature. Pour plus de détail concernant le cycle en Y se reporter à l’annexe 1.
Le choix du cycle en Y est justifié par ses propriétés confirmées et par le besoin
exprimé par La plateforme de taxation en termes de fonctionnalités et des technologies à
utiliser. Néanmoins, une étude comparative entre le cycle en Y et d’autres cycles de
développement s’impose afin d’en choisir celui qui est le plus adapté. L’étude a prouvé la
puissance du cycle en Y et elle a démontré qu’il est approprié au projet. (Autres informations
sur 2Tup dans l’ANNEXE 1)
Cette comparaison porte sur trois processus de développements les plus populaires et
les plus utilisés :

 le processus RUP (Rational Unified Process).


 le cycle en V.
 le cycle en Y.

La table 1 suivante est un récapitulatif de l’étude comparative réalisée.

Les aspects critiques, du projet étudié, méritent d’être résolus avec plus de souplesse.
Parmi ces points, la multitude des fonctionnalités exprimées, l’utilisation des plus nouvelles
technologies, le respect du temps réservé à l’élaboration du projet, etc. Pour éviter cette
immensité des risques, nous nous somme concentré sur l’élaboration d’une première version
du projet n’ayant que les fonctionnalités principales. Ensuite, nous ajoutions les fonctions les
plus indispensables au fur et à mesure. Ceci étant établi par une méthode itérative et
incrémentale.

Pour esquiver les risques des nouveautés technologiques, nous explorions les solutions
offertes pour s’y adapter et pour surpasser les surprises qui peuvent en survenir. Le modèle
d’implémentation donc tire de grands profits des solutions offertes par les technologies
étudiées.

D’après la table 1, seul Y propose un intérêt vif pour la gestion de la complexité


technique. Les deux autres n’y attachent pas grande attention. En effet, RUP propose plutôt un

Projet de fin d’études 2010 - 2011 19


Chapitre 1 : Contexte général du projet

cadre complet pour la conduite de projet, mais n’attache pas trop d’importance pour le
développement lui-même. Le cycle en V quant à lui, permet de maîtriser le développement à
travers les vérifications à la fin des phases, mais il n’offre toujours pas de gestion de la
complexité technique.

Il s’avère donc incontestablement que c’est effectivement 2TUP qui est le plus
approprié au projet étudié.

Processus Description Avantages Inconvénients


RUP RUP est à la fois une Propose des modèles de -Coûteux à personnaliser
documents, et des
méthodologie de conduite -Très axé processus, au
canevas pour des projets
et de développement de détriment du
types
projets et un outil prêt à développement : peu de
l’emploi place pour le code et la
technologie
V Chaque phase en amont Préparation des phases de -Obligation de définir la
de la production du vérification au moment totalité des besoins au
logiciel prépare la phase de l’Analyse et de la départ
correspondante de
Conception -Validation fonctionnelle
vérification en aval de la
tardive
production du logiciel
2TUP S’articule autour de Fait une large place à la Ne propose pas de
l’architecture technologie et à la documents types
gestion du risque
Table 1: Etude comparative des cycles de développement.

4.2 Planification du projet 

La planification du projet est parmi les phases d'avant-projet. Elle consiste à prévoir le
déroulement du projet tout au long des phases constituant le cycle de développement. Grâce
aux réunions tenues avec notre encadrante au sein de l’organisme d’accueil, nous avons été
éclairés sur les différentes étapes du projet ainsi que leur séquencement.

Le tableau et le diagramme suivants présente le planning des étapes du déroulement de


notre projet :

Liste des taches :

Nom Date de début Date de fin


Recherche de documentation 14/03/11 26/03/11
Rédaction d'un rapport sur la téléphonie IP 14/03/11 15/03/11
Analyse de la solution Phonex One 15/03/11 29/03/11

Projet de fin d’études 2010 - 2011 20


Chapitre 1 : Contexte général du projet

Analyse et Conception de la plateforme 29/03/11 28/05/11


Etudes fonctionnel et étude technique du projet 29/03/11 30/04/11
Conception 29/04/11 28/05/11
Développement des algorithmes de calcul des coûts des 30/05/11 11/06/11
appels
Développement de l'interface graphique 13/06/11 23/06/11
Déploiement et tests au niveau du réseau TOIP 23/06/11 01/07/11
Réalisation des documents techniques 13/06/11 02/07/11
Rédaction du mémoire de Fin d'études 14/03/11 02/07/11
Table 2 : les taches du projet

Ressource :

Figure 6 : diagramme de ressource du projet

Diagramme de Gantt :

Figure 7 : diagramme de gantt

Conclusion :
Dans ce chapitre, nous avons présenté les services et son organisation d’intelcom
comme première partie.
La présentation du but du projet est la seconde partie de ce chapitre suivie de la
description du processus de développement 2TUP que nous avons adopté pour le
développement de la plateforme de taxation pour la téléphonie sur IP. A base de ce processus

Projet de fin d’études 2010 - 2011 21


Chapitre 1 : Contexte général du projet

que nous avons établi un planning de travail afin de bien maîtriser les ressources allouées au
projet.
Le chapitre suivant est consacré à l’étude fonctionnelle du projet.

Projet de fin d’études 2010 - 2011 22


Chapitre 2: Etude fonctionnelle du projet

Chapitre 2 :
Étude fonctionnelle du projet

Dans ce chapitre, nous présentons l’étude


fonctionnelle du projet qui se compose de deux étapes, une
étape de capture des besoins fonctionnel et une étape
d’analyse.
La première comporte une analyse comparative des
solutions ; une étude de l’existant et les services attendus de
la plateforme  .
La deuxième comporte l’élaboration du diagramme
statique ; dynamique du projet et par la fin une analyse du
comportement des entités dégagées.

Projet de fin d’études 2010 - 2011 23


Chapitre 2: Etude fonctionnelle du projet

Introduction :
Lors de cette phase nous avons effectué une étude des besoins des utilisateurs du
système à développer. Ces besoins ont été identifiés lors des réunions tenues avec notre
encadrante. Cette première phase du cycle de développement avait comme livrables, le cahier
des charges.
Dans le présent chapitre nous présentons la synthèse de ce livrable.

1 Capture des besoins fonctionnels


1.1 Analyse comparative des solutions

Le tableau a pour objectif d'étudier différents outils pour la mise en œuvre d'une
solution de taxation, afin de retenir celui qui conviendrait le mieux aux besoins de l’entreprise
Intelcom.

Chaque logiciel est étudié ou expérimenté en ligne (démonstrations en ligne). Les


informations deviennent une connaissance retranscrite dans le tableau.

Les possibilités d’utilisation de ce tableau sont nombreuses. Elle permet entre autres
d’avoir une vue de l’ensemble des outils de taxation pour la ToIP présents sur le marché et
donc de rester au fait des dernières avancées technologiques dans ce domaine.

Dans le point qui suit, les solutions de taxation vont être présentées en fonction de
certains critères clés. Cette présentation permettra de connaître rapidement les outils adéquats
en fonctions des attentes, des besoins et des contraintes de l’entreprise.

Le tableau comparatif :
Nom Asterisell Freeside Asterisk2Billing PHONEX ONE

Développé par Auteurs Freeside internet ArezquiBela_d EVERCOM


Services, Inc. "Areski"
Licence GPL AGPL AGPL Payante
Configuration -Asterisk 1.2.24 + -Microsoft SQL
- Serveur WEB - Perl , version 5.8.4
requise 1.4.0 ou Asterisk Server 2005/2008
HTTP minimum
-Apache 2 éditions standard
- PHP 5.0 ou Apache-Apache , SSL -PostgreSQL 8 ou 5 et Enterprise
supérieur (PHP 4.0 hautement MySQL ou eXPress
n'est pas supporté); recommandé) -PHP 5 -MicrosoftInternet
Information
- support GD activé -PostgreSQL
Server (IIS) 5.0
en PHP; ouMySQL (v4.1 ou
-ASP.NET
ultérieure, v5
- MySQL SGBD
recommandé)
- serveur
AsteriskVoIP

Projet de fin d’études 2010 - 2011 24


Chapitre 2: Etude fonctionnelle du projet

Gestion des dépenses :


Gérer les dépenses Oui Non Non Oui
à tous les niveaux
Gérer les dépenses Oui Oui Non Oui
par employé
Gérer les dépenses Oui Non Non Oui
par département

Gestion des rapports :


générer des Oui Oui Oui Oui
rapports faciles
à exploiter
Etablir des Non Non Oui Oui
rapports coûts
en plusieurs
devises
Etablir des Oui Non Non Oui
rapports ne
comportant que
les informations
requises

Gestion des requêtes:


Déterminer les Oui Oui Non Oui
données requises

Les requêtes Oui Oui Non Oui


peuvent être
personnalisées
Les requêtes Oui Oui Non Oui
peuvent être
exportées

Contrôle de trafic :
contrôler la Non Non Oui Oui
charge de trafic
de chaque
employé
contrôler la Non Non Non Oui
charge de trafic
de chaque ligne
extérieure

Journalisation:
Journalisation Oui Oui Oui Oui
des événements
Journalisation Oui Non Non Oui
pour
l’administration
du système

Gestion des tarifs


Planification des Oui Oui Oui Oui

Projet de fin d’études 2010 - 2011 25


Chapitre 2: Etude fonctionnelle du projet

tarifs
Mise à jour des Oui Oui Oui Oui
tarifs

Bilan :
D’après la comparaison précédente on constate que la solution payante PHONEX ONE
est la solution qui répond aux critères attendue. Donc l’analyse de cette solution sera l’étape
Table 3 : comparatif des solutions de facturation suivante, à fin de mettre en
œuvre une nouvelle solution
de taxation pour la téléphonie sur IP.

1.2 Etude de l’existant:

PhonEX™ ONE est une solution web conçue pour la gestion comptable et le contrôle
des appels téléphoniques. Elle permet un suivi de tous les appels – qu'il s'agisse de téléphonie
classique ou de téléphonie internet (VoIP) – passés sur le réseau d'entreprise.
Apres une analyse les points forts de PHONEX ONE sont:

 Base de données reposant sur le standard Microsoft SQL 2005


 Système basé sur une architecture évolutive, supportant un nombre illimité de sites et
d’extensions
 Modularité permettant l’intégration d’installations hétérogènes de PBX
 Garde le journal d’utilisation sur le système et son administration
 Moniteur système, fournissant en ligne les informations tels que: la collecte des tickets
des différentes sources, leur traitement et les modifications dans le système
 Rapports supportant les fonctionnalités drill-down, pour la visualisation hiérarchique
de l’entreprise en un rapport
 Sécurité : limitation à l’accès et aux fonctions sur base utilisateur ou de groupe
d’utilisateurs.

 L’Architecture de la solution de facturation:

Projet de fin d’études 2010 - 2011 26


Chapitre 2: Etude fonctionnelle du projet

Figure 8: l’architecture de la solution de facturation Phonex One

Il s’agit ici d’une architecture deux tiers, la machines serveur comporte et les
applications de traitement tels le Call Manager et le système de facturation, et le serveur de
base de données SQL Server.
Le Call Manager Interagit avec la base de données CDR pour y enregistrer les
informations sur les appels.
Le système PhonEX ONE consiste en 3 applicatifs de base:
Un serveur base de données SQL,
Un serveur Applications
Un serveur WEB.

PhonEX ONE peut être installé sur un ou plusieurs serveurs séparés (mode Cluster).

Le paragraphe suivant décrit brièvement certains aspects de la configuration matérielle


des serveurs :

Serveur Unique :
La configuration à Serveur Unique intègre les 3 applicatifs en un seul serveur.
Serveurs Multiples :

Serveur Base de Données

Projet de fin d’études 2010 - 2011 27


Chapitre 2: Etude fonctionnelle du projet

 Dual Processor Pentium IV avec minimum 3 GHz vitesse processeur


 Windows 2003 Server ou Windows 2008 Server
 Microsoft SQL Server 2005/2008 éditions standard et Enterprise (non fournis avec
PhonEX One) ou eXPress (fourni)

Serveur Web
 Windows 2003 Server ou Windows 2008 Server
 Microsoft Internet Information Server (IIS) 5.0
 ASP.NET
 Microsoft Internet Explorer

Client PC WEB
PhonEX ONE requiert Microsoft Internet Explorer 6.0 et supérieure, avec une résolution
d’affichage recommandée de 1024x768.

La configuration à Serveur Multiple consiste à ce que chaque applicatif de base soit un


repris par un serveur dédicacé: un serveur WEB, un serveur APPLICATION, et un serveur
Base de Données SQL.

1.3 Services attendus de la plateforme de taxation

L’analyse de l’existant nous a permis de faire sortir les fonctionnalités nécessaires et


importantes de notre plateforme de taxation. Ainsi nous avons pu élaborer un cahier de
charges où nous avons précisé ces services.
La plateforme de taxation doit permettre de :
 gérer les dépenses téléphoniques à tous les niveaux, à la fois par employé et par
département ;
 générer des rapports faciles à exploiter, ne comportant que les informations
requises;
 établir des rapports et des relevés de coûts en plusieurs devises ;
 contrôler la charge de trafic de chaque employé et de la ligne extérieure ;
 repérer toute utilisation abusive du téléphone, notamment les appels longs et
coûteux ;
 réduire les dépenses téléphoniques en sensibilisant le personnel à une
utilisation efficace du téléphone.

L’aspect fonctionnel de la plateforme


 La solution web offre une fonctionnalité totale avec tous les navigateurs web,
que ce soit de l'intérieur ou de l'extérieur de l'organisation
 Architecture système prend en charge un nombre infini de sites et d'employés

Projet de fin d’études 2010 - 2011 28


Chapitre 2: Etude fonctionnelle du projet

 la modularité optimisée pour divers types d'installation pour offrir toute la


souplesse requise pour les réseaux centralisés ou répartis, avec un traitement
optimal pour chaque site.
 Prise en charge de la base de données MySQL et utilisation avancée de la
technologie J2EE
 Journalisation des événements pour les journaux système de suivi et
administration du système
 Moniteur système pour afficher des informations en ligne sur : collecte des
enregistrements de données d'appel (CDR, Call Data Record) à partir de
différentes sources de données, état de traitement des CDR et autres
changements survenus dans le système
 Définition du niveau de détail des rapports – affiche les différentes hiérarchies
de l'entreprise dans un rapport unique
 Sécurité optimisée pour limiter l'accès à certaines options et commandes en
fonction de l'utilisateur et de l'appartenance à un groupe
 Contrôle d'accès, journalisation des attaques système, algorithmes complexes
de génération de mots de passe et pour offrir une protection totale contre les
hackers

Fonctionnalités liées à la génération des requêtes :

Cette option assurera les fonctionnalités suivantes:

 Compiler un nombre infini de rapports personnalisés.


 L’utilisateur peut déterminer les données requises,
 L’utilisateur peut sélectionner la façon dont elles doivent être triées et
globalisées,
 Les requêtes personnalisées peuvent être enregistrées pour un usage ultérieur.
 l'utilisateur peut exporter des informations vers n'importe quel système
extérieur, au format de son choix.

1.4 Méthode de calcul du cout d’appel

Nous avons fait une étude sur les tarifs fixe qui a pour objectif de trouver la méthode
de calcul du coût de chaque appel téléphonique, pour cela nous avons commencé par l’analyse
du document récapulatif des tarifs de la téléphonie Fixe des opérateurs au Maroc publié par
L'Agence Nationale de Réglementation des Télécommunications, ANRT.

Il existe plusieurs services pour chaque opérateur, et qui sont séparés en services pour
les particuliers et pour les professionnels ou entreprises. Donc on s’intéresse à étudier que les
tarifs des services pour les professionnels et des services des entreprises. Parmi ses services on
cite Pour l’opérateur Itissalat al-Maghreb , IAM :

o Abonnement Classique 
o des offres  pour Entreprises et professionnels
Abonnement classique :

Description de l’offre :

Projet de fin d’études 2010 - 2011 29


Chapitre 2: Etude fonctionnelle du projet

Tarifs préférentiels pour les communications à destination des postes fixes et


mobiles (IAM et Méditel) de l’entreprise.
 Plage horaire unique.
 Abonnement mensuel plafonné à 100 lignes, soit 2000 DH HT ;
 La facturation s’effectue en tarif unique
 Non compatible avec l’offre Famille et Amis.
 Tarification à la première minute indivisible, puis paliers de 30 secondes.

Table 4 : Les tarifs de l’abonnement classique

Offres pour Entreprises et professionnels :

 Offre : préférence Groupe.


Description de l’offre :
Tarifs préférentiels pour les communications à destination des postes fixes et
mobiles (IAM et Méditel) de l’entreprise.

 Plage horaire unique.


 Abonnement mensuel plafonné à 100 lignes, soit 2000 DH HT ;
 La facturation s’effectue en tarif unique
 Non compatible avec l’offre Famille et Amis.
 Tarification à la première minute indivisible, puis paliers de 30 secondes.

Table 5 : les tarifs de l’offre préférence Groupe.

 Offre : Préférence Mobile.

Projet de fin d’études 2010 - 2011 30


Chapitre 2: Etude fonctionnelle du projet

Description de l’offre :
Tarifs préférentiels pour les communications à destination des mobiles IAM et
Méditel.
 Plage horaire unique.
 Abonnement mensuel plafonné à 100 lignes, soit 2000 DH HT ;
 La facturation s’effectue en tarif unique ;
 Tarification à la première minute indivisible, puis paliers de 30 secondes.
 Non compatible avec l’offre Famille et Amis.
 Compatible mais non cumulable avec l’offre Préférence Groupe.

Table 6 : les tarifs de l’offre préférence Groupe.

 Offre : préférence international.


Description de l’offre :
 Abonnement mensuel plafonné à 100 lignes, soit 2000 DH HT ;
 Abonnement mensuel :
o Ligne analogique : 20 DH HT

o Accès de base MARNIS : 2*20 DH HT

o Accès primaire MARNIS : 30*20 DH HT

 La tarification se fait en première Minute indivisible puis par paliers de 30 secondes.


 Tarifs des communications en DH HT / mn :
 Les réductions vers les terminaisons fixes :

Table 7: les tarifs de l’offre préférence International vers fixe.

Projet de fin d’études 2010 - 2011 31


Chapitre 2: Etude fonctionnelle du projet

 Les réductions vers les terminaisons Mobiles

Table 8 : les tarifs de l’offre préférence International vers mobile.

Bilan de l’étude :
D’après cette étude il existe de différents tarifs donc notre application doit supporter la
variation des tarifs. Pour cela on a ajouté des champs nécessaires dans le module de gestion
des tarifs.
Et concernant le calcul des coûts des appels, nous avons pris en considération une plage
horaire unique parce que d’après la liste des offres professionnelles d’IAM, la plage horaire
est unique.
La formule de calcul s’effectue comme suit :
Coût d’appel = (Le coût de la première minute indivisible) + (la somme des coûts des
paliers de secondes désignés dans le tarif actuel).
Le tarif actuel peut être un tarif réduit ou normal (plein tarif) selon le tarif activé.

Projet de fin d’études 2010 - 2011 32


Chapitre 2: Etude fonctionnelle du projet

4 Analyse
L’analyse a pour objectif l’identification des différentes entités qui interagiront avec
le système. Ces entités seront regroupées par la suite sous forme de rôles dont chacun englobe
un ensemble d’entités. Le résultat de cette analyse sera modélisé en utilisant le formalisme
UML (voir Annexe 2) par les diagrammes suivants : diagramme des cas d’utilisation et
diagramme de séquences.

2.1 Elaboration des cas d’utilisation

Dans ce paragraphe, nous allons dégager l’ensemble des cas d’utilisation du système.
Ce seront toutes les manipulations que les différents utilisateurs effectuent en interagissant
avec le système. Afin d’y parachever, nous allons suivre la démarche suivante :

 Définir les acteurs du système


 Lister les cas d’utilisation
 Construire Le diagramme des cas d’utilisation

Les acteurs principaux du système sont les personnes qui utilisent les fonctions
principales du système. Dans le cas de Taxation, ce sont les acteurs : Administrateur,
employé et administrateur de base donnée.

La liste des cas d’utilisation en bref et comme suit :

Afficher les informations


Générer le rapport
Gérer la requête
Lire les données traitées
Lire les données traitées
Paramétrer le système
Sauvegarder les données
Sauvegarder les paramètres
Traiter les données

Le diagramme des cas d’utilisation :

Projet de fin d’études 2010 - 2011 33


Chapitre 2: Etude fonctionnelle du projet

Figure 9 : Diagramme des cas d’utilisation

2.2 Construction des diagrammes de séquences:

Puisque la plateforme de taxation se constitue de plusieurs modules différents nous


avons choisi d’illustrer 4 différentes interactions les plus importantes.
Ainsi pour compléter la description par le diagramme de séquence relatif au cas
d’utilisation étudié.

Génération de rapports par l’administrateur :


La génération des rapports peut-être fait par l’administrateur. Cette opération inclue la
création d’une requête personnalisée par l’administrateur. Et après la création de la requête le
système entame le traitement des données selon les choix de l’utilisateur.
Ces interactions sont modélisées dans le diagramme suivant :

Projet de fin d’études 2010 - 2011 34


Chapitre 2: Etude fonctionnelle du projet

Figure 10 : Diagramme de séquences de la génération des rapports

Paramétrage de la plateforme :
Le paramétrage de la plateforme se fait par l’administrateur. Et après la confirmation du
paramétrage le système se charge automatiquement de l’enregistrement des paramètres
comme le montre le diagramme suivant :

Figure 11 : Diagramme de séquences du paramétrage de la plateforme

La gestion des utilisateurs :

Projet de fin d’études 2010 - 2011 35


Chapitre 2: Etude fonctionnelle du projet

Cette gestion se fait par l’administrateur seulement. Voici une partie de cette gestion qui
permet juste la consultation des utilisateurs ajoutés précédemment par l’administrateur aussi :

Figure 12 : Diagramme de séquences de la gestion des utilisateurs

Génération de rapports par l’employé :


La génération des rapports peut être faite par l’employé. Cette opération inclue toute des
opérations comme celle du premier diagramme de séquence pour l’administrateur.
Ces interactions sont modélisées dans le diagramme suivant :

Projet de fin d’études 2010 - 2011 36


Chapitre 2: Etude fonctionnelle du projet

Figure 13: Diagramme de séquences de la génération de rapports par l’employé

2.3 Analyse du comportement des entités dégagées :

Dans ce paragraphe nous présentons le comportement des entités sous forme de règles
de gestion qui aide à la construction du diagramme de classe en se basant aussi aux étapes
précédentes de l’analyse.
Les règles de gestion sont réparties selon les modules de la plateforme de
taxation comme suit :

Module de gestion des Tarifs :

 Chaque opérateur est défini par un Identificateur, code et sa description.


 Chaque opérateur a une date et heure de la dernière mise à jour.
 L’administrateur peut définir pour chaque opérateur un tarif y incluant des dates
spéciales telles que congés, jours fériés.
 Chaque tarif à une date début et date de fin ainsi que le type de tarif peut être.

Module de gestion des dépenses:

 Chaque budget et un Identificateur, date début, date fin, budget de base,


additions, solde précèdent, utilisation, alarme dépasse, budget total, solde,
pourcentage utilisation.

Projet de fin d’études 2010 - 2011 37


Chapitre 2: Etude fonctionnelle du projet

 Le budget est lié à chaque appareils afin de gérer les dépenses téléphoniques à
tous les niveaux, à la fois par employé et par département.
 Tous les budgets (courants et anciens) pour tous les appareils sont enregistrés
pour un seul mois. De plus, chaque ligne contiendra des informations sur les
paramètres du budget (Alarme dépassé le budget, etc.) et le reste du budget.
 Chaque utilisation abusive du téléphone est repéré, notamment les appels longs
et coûteux ;
 Réduction des dépenses téléphoniques se fait en affichant une alerte après
dépassement du budget total.
 Chaque appareil et Identifier par un Identificateur, un numéro est utilisé par un
employé.
 Chaque employé a un Identificateur, nom, prénom, titre, adresse, email.
 Chaque employé peut avoir plusieurs répertoires personnels du numéro.
 Chaque employé a un supérieur.
 Chaque employé à une date début et de fin de son affectation à un département.
 Chaque département a un Identificateur, code, description, niveau.
 Chaque département a au moins un compte.
 Chaque département a un site.
 Chaque site a un Identificateur, nom, code.
 Chaque compte est lié à un enregistrement des détails sur un appel (CDR).
 Chaque compte a un Identificateur, nom compte, budget, indice Site.
 Chaque CDR a un Identificateur, numéro appareil, num appareil2, cdr date, cdr
heur et min, cdr second, num compose, cout PBX, cout appel, numcdr , compte,
indice site, id appareil, operateur, id appel, code destination.
 Chaque CDR a un type destination.
 Chaque type destination a un Identificateur, code et sa description.
 Chaque CDR et lié à un seul CDRcisco.

Module de gestion des Factures :

 Chaque factures a un Identificateur, date début, date fin, indicesite, état de


vérification et état ajustement cout.
 Chaque facture peut avoir plusieurs Ligne facture, et détails facture.
 Chaque facture a un type.
 Chaque type facture a un identificateur, code operateur, typefacture, indice site,
format facture.
 Chaque type facture à plusieurs factures et elle peut avoir plusieurs types ligne.
 Chaque type ligne a un identificateur et code ligne.
 Chaque type ligne peut avoir plusieurs ligne facture.
 Chaque ligne facture a un identificateur date début, date fin, cout, duration et
numéro appels.
 Chaque ligne facture à un type ligne.
 Chaque ligne facture peut avoir plusieurs détails facture et une facture.
 Chaque détails facture à un identificateur, CDRID, date appel, temps appel, cout,
duration, numéro appelé.
 Chaque détail facture à un type ligne et facture.

Conclusion :

Projet de fin d’études 2010 - 2011 38


Chapitre 2: Etude fonctionnelle du projet

Au cours de ce chapitre, nous avons présenté les différentes fonctionnalités auxquelles


doit répondre le système de gestion de la formation. Cela nous a permis par la suite
d’identifier les différentes entités composant l’environnement d’interactions du système, à
savoir : les acteurs humains, les acteurs systèmes et les interactions entre ces derniers.

Le résultat de cette étude est le diagramme de la classe présentée dans le troisième


chapitre conception et mise en œuvre.
Le chapitre suivant est consacré à l’étude technique du projet suite au processus suivie.

Projet de fin d’études 2010 - 2011 39


Chapitre 3: Etude technique du projet

Chapitre 3 :
Etude technique du projet

Dans ce chapitre, nous présentons la technologie


J2EE adoptée pour la plateforme de taxation. De plus, nous
expliquons l’architecture logicielle caractérisant
l’application. Ensuite, nous exposons les Frameworks Open
Source choisi pour le développement.
Chapitre 4: Conception et mise en œuvre du projet

Introduction:

Nous présentons dans ce chapitre les principales étapes de la branche technique


comme suit :
L’étape capture des besoins techniques recense toutes les contraintes sur les choix de
dimensionnement et la conception du système. Les outils sélectionnés ainsi que la prise en
compte des contraintes d’intégration avec l’existant. Cette étape permet de définir le modèle
d’analyse technique. Le rôle de ce dernier est d’établir les couches logicielles et y spécifie les
activités techniques attendues.
L’étape conception générique définit ensuite les composants nécessaires à la
construction de l’architecture technique. Cette conception est complètement indépendante des
aspects fonctionnels. Elle permet de générer le modèle de conception technique ou design
pattern (aspect qui sera développé ultérieurement) qui définit les Frameworks. Ces derniers,
délivrant les services techniques, assurent la réponse aux exigences opérationnelles du
système. (Autres informations sur 2Tup dans l’ANNEXE 1)

1 Technologie J2EE

La technologie Java 2 Entreprise Edition (J2EE) définit la norme de développement des


applications d’entreprise distribuées et multi tiers. Elle permet de simplifier les applications
d’entreprise en se basant sur des composants modulaires normalisés. Ceci étant, en fournissant
un ensemble complet de services et en gérant automatiquement un grand nombre de détails
sur le comportement des applications.

J2EE est composée de plusieurs technologies qui sont regroupées en trois catégories :
composant, service et communication [wwwJAVASUN].

 Technologies de type composant

Les technologies de type composant sont utilisées par les développeurs afin de créer des
composants logiciels d’une application d’entreprise notamment l’interface utilisateur et la
logique métier. Elles permettent de développer des modules réutilisables qui peuvent être
intégrés dans d’autres applications. De plus, elles sont supportées par les services
d’infrastructures de la plate-forme J2EE qui simplifie le développement des applications.
Elles permettent, aussi, d’adapter les composants aux besoins des ressources de
l’environnement dans lequel ils sont déployés [wwwJAVASUN].

 Technologies de type service

Etant donné que la plupart des applications d’entreprise ont besoin d’accéder aux
systèmes d’information d’entreprise, la plate-forme J2EE offre un ensemble de services tels
que l’accès aux bases de données (JDBC), le service de désignation (JNDI), les transactions et
les services de Messagerie.

Projet de fin d’études 2010 - 2011 41


Chapitre 4: Conception et mise en œuvre du projet

 Technologies de type communication

La plate-forme J2EE fournit un ensemble de technologies, permettant la


communication entre clients et serveurs et entre les objets qui collaborent dans les différents
serveurs. Comme l’exemple des connecteurs aux systèmes d’information existants et
l’invocation des méthodes distantes à travers le standard OMG-CORBA.

1.1 Architecture J2EE

C’est une architecture soutenue par SUN® MICROSYSTEMS qui définit et fournit le
modèle de programmation multi tiers basé sur l’architecture des composants. Avec ce modèle,
des applications légères peuvent interagir facilement avec le système d’information et les
composants implantant la logique d’entreprise sur des serveurs d’applications. L’architecture
J2EE consiste en trois parties :

 Components : les composants qui prennent en charge la présentation et la logique


métier.
 Containers : fournit un contexte aux composants.
 Connectors : fournit l’accès aux sources de données de l’entreprise.
Cet environnement supporte trois types de composants d’applications, dont les définitions
seront présentées par la suite :

 applets.
 servlets (incluant JSP).
 Enterprise JavaBeans (EJB).

La figure suivante illustre les trois parties constituant l’architecture J2EE. Le noyau de
serveur «J2EE Server Core » est un environnement de serveur d’application qui fournit les
services de gestion de ressources et de transactions [wwwTHOMAS].

Figure 14 : l’architecture J2EE

1.2 Composants de base de J2EE

Projet de fin d’études 2010 - 2011 42


Chapitre 4: Conception et mise en œuvre du projet

Comme c’est mentionné, l’architecture J2EE est composée de plusieurs technologies


qui sont regroupées en trois catégories : composant, service et communication. Détaillons ces
composants de base de J2EE.

 Entreprise Java Beans

C’est un modèle de composant logiciel réutilisable spécifié par


SUN®MICROSYSTEMS en collaboration avec des industriels. Il est destiné au
développement et au déploiement d’applications établies en fonction du modèle multi tiers. Il
permet aux concepteurs d’applications de bénéficier des avantages de Java et notamment de
l’indépendance vis-à-vis de la plateforme.

L’idée est de programmer une seule fois de petits composants logiciels, de les utiliser
et les réutiliser n’importe où [wwwREDBOOKIBM]. La spécification des EJB définit deux
types de composants : les Session Beans, qui ne vivent que le temps de leurs activités et qui
sont en permanence en interaction avec l’utilisateur. Par contre, les EntityBeans, sont
persistants être présentent des données issues d’une base de données. Les Session Beans sont
de deux types:

 Stateless Session Beans: sont des objets qui se comportent comme des composants
serveurs et exécutent des actions à distance. Ces objets ne gardent aucune notion d’état
entre deux invocations [PATZER00]. Ils reçoivent des requêtes provenant de
différents clients et l’ordre des requêtes n’influe pas sur leur exécution.
 Statefull Session Beans: reprennent les fonctionnalités d’invocation à distance des
Stateless Session Beans, mais ajoutent la capacité de conserver un état propre à chaque
client, d’une invocation à une autre.

Les EntityBeans sont de deux types :

 Container Managed Persistance (CMP) : la persistance de l’objet est gérée


automatiquement par le serveur.
 Bean Managed Persistance (BMP) : la persistance de l’objet est gérée manuellement
par le bean lui-même. Ce deuxième type des Entity Beans demande un grand effort du
développement de la part du programmeur vu qu’il doit contrôler la persistance de
l’objet [wwwREDBOOKIBM].

 Servlets

Une Servlet Java est un programme Java qui se branche sur un serveur Web. Il est possible
d’étendre un serveur Web pour qu’il héberge des Servlets par le biais d’un moteur de Servlets.
La technologie des Servlets s’avère en fait plus adaptée à répondre aux requêtes de
l’utilisateur en invoquant des méthodes sur des EJB, puis en redirigeant la requête HTTP vers
des pages HTML ou JSP qui afficheront le résultat de la requête. Les Servlets sont donc
utilisées principalement comme un «centre d’aiguillage» qui interprète et dirige le flot de
requêtes de l’utilisateur vers les composants EJB et renvoie à l’utilisateur les pages Web
adéquates [IBMBOOK].

Projet de fin d’études 2010 - 2011 43


Chapitre 4: Conception et mise en œuvre du projet

 Java Server Pages

Les JSP permettent de séparer efficacement le codage HTML de la logique applicative


des pages Web. Ils sont utilisés pour accéder à des composants réutilisables, tels que des
Servlets, des JavaBeans et des applications compatibles avec le langage Java [IBMBOOK].

Après cette présentation de la plate-forme J2EE, nous allons présenter l’architecture


logicielle du système étudié, ainsi que les contraintes qu’elle subit, en passant par une
définition de la notion d’architecture logicielle.

Projet de fin d’études 2010 - 2011 44


Chapitre 4: Conception et mise en œuvre du projet

5 Architecture logicielle du système

Une architecture logicielle exprime un schéma d’organisation structurel fondamental


pour les systèmes logiciels. Elle fournit un jeu de sous-systèmes prédéfinis, spécifie leurs
responsabilités, et elle inclut les rôles et les instructions générales pour organiser les relations
entre eux [wwwASTONS]. Ainsi, sans une bonne architecture, un système d’information est
difficile à comprendre, prédire, gérer et optimiser. Les buts d’une architecture sont :

 la compréhension du système étudié en définissant ses limites.


 La gestion de la croissance du système.

2.1 Objectif technique de l’architecture de la plateforme de taxation

L’architecture logicielle de La plateforme de taxation répond à un certain nombre de buts et


contraintes en terme de sécurité, de disponibilité et de maintenance. Le choix d’une
architecture logicielle constitue une étape technologique primordiale. En effet, il faut définir
les grands objectifs techniques de la future architecture, c’est-à-dire de bien prendre en
compte l’ensemble des forces qui vont s’exercer sur le futur système ainsi que la puissance de
chacune d’entre elles [wwwASTONA].
La figure suivante présente les objectifs techniques de l’architecture logicielle de la
plateforme de taxation.

L’évolutivité

La Plateforme de taxation
Réutilisabilité Disponibilité

Sécurité

Figure 15 : objectifs techniques de l’architecture logicielle de la plateforme de taxation

Projet de fin d’études 2010 - 2011 45


Chapitre 4: Conception et mise en œuvre du projet

Le tableau suivant fournit plus de détail concernant les objectifs techniques de la


plateforme de taxation :

Objectif Description
Disponibilité Il doit être en permanence à la
disposition de ses utilisateurs.

Sécurité La plateforme de taxation doit


assurer un système de sécurité
permettant d’accéder aux
fonctionnalités du système selon
les droits de l’utilisateur, en plus de
la gestion des autorisations et des
authentifications.

Réutilisation Il doit inclure la possibilité de


réutiliser les modules du système.

Evolutivité Il doit permettre d’étendre le


système.

Table 9 : objectifs techniques de l’architecture logicielle de la plateforme de taxation

2.2 Architecture logicielle de Taxation :

Parmi les différentes façons de structurer une architecture, la mieux comprise et


maîtrisée en informatique est l’approche par couches [wwwASTONA]. Une couche (Layer en
anglais) est une division logique, horizontale d’un système qui fournit une abstraction
particulière du système aux couches supérieures [wwwASTONS].
Chaque couche possède des responsabilités spécifiques. Dans une structuration par
couches, les couches inférieures prennent en charge des rôles qui offrent un fonctionnement
de base pour les couches supérieures, permettant par la suite d’abstraire l’implémentation de
ces services basiques.
Ainsi, nous avons adopté un découpage en couches. Une telle architecture permet
également d’obtenir un niveau poussé de réutilisation en adoptant les solutions trouvées aux
problèmes ayant un fonctionnement similaire. Cette exploitation est prise en compte pour
chaque couche de l’architecture. La figure suivante résume le découpage adopté :

Projet de fin d’études 2010 - 2011 46


Chapitre 4: Conception et mise en œuvre du projet

Présentation

Application

Domaine

Persistance

Figure 16 : architecture de la plateforme de taxation en couches.

Couche Présentation
Cette couche est adoptée principalement pour gérer l’aspect visuel des applications et
pour gérer les interactions avec les utilisateurs. Chargée de dessiner les fenêtres et les autres
composants graphiques, elle intercepte les événements et appelle la couche Application. De
plus, elle vérifie les autorisations des utilisateurs auprès du service de sécurité. Les rôles de la
couche Présentation sont comme suit :
 gestion du domaine de l’écran.
 affichage des pages Web.
 gestion de l’interaction avec l’utilisateur.
 validation syntaxique.
La couche Présentation établit deux relations avec la couche Application :
 demandes de contenu à la couche Application pour affichage et édition.
 ordres de traitement à la couche Application pour création, mise à jour, suppression,
etc.
Couche Application
Son but principal est de fournir des services spécifiques à la couche Présentation. Ces
services correspondent aux règles du métier définies lors de la phase d’analyse. Elle prend en
charge les aspects de contrôle des cas d’utilisation. C’est concrètement dans cette couche que
l’on voit les cas d’utilisation issus de la partie analyse. Les rôles de la couche Application sont
les suivants :
 Services spécifiques au domaine.

Projet de fin d’études 2010 - 2011 47


Chapitre 4: Conception et mise en œuvre du projet

 Services externes.
 Contrôle des cas d’utilisation.
Couche Domaine
Cette couche est concentrée sur le métier de l’application, c’est-à-dire les règles
métiers, sémantiques et logiques. C’est l’espace où réside le modèle du domaine. Sa charge
principale consiste à garantir la validation sémantique de l’information métier. Les rôles de la
couche Domaine sont résumés ainsi :
 Comportement métier.
 Validation sémantique.
Elle échange l’état des composants entités métiers avec la couche Persistance.
Couche Persistance
Cette couche est certainement l’une des plus importantes. C’est ici que l’on trouve les
fonctionnalités de base qui permettent de créer, rechercher et supprimer des entités métier
dans le respect des propriétés transactionnelles. C’est également dans cette couche que les
mécanismes de conversion objet/relationnel peuvent prendre place. Le rôle de la couche
Persistance est défini comme suit :
 Assurer les services basiques de création, lecture, mise à jour et suppression.
 Permettre la conversion Objet/Relationnel.
Ainsi, l’architecture choisie est basée sur la logique des couches. Chaque couche
fournit aux autres couches des services et utilise les services des autres. Dans ce qui suit, nous
allons présenter les Frameworks utilisés au cours du développement.

Projet de fin d’études 2010 - 2011 48


Chapitre 4: Conception et mise en œuvre du projet

6 Les Frameworks :
Un Framework capitalise l’expertise nécessaire en matière de programmation pour
résoudre une certaine classe de problème. Les programmeurs réutilisent les Frameworks pour
profiter de cette expertise sans avoir à résoudre le problème. Un Framework aide les
développeurs à fournir des solutions pour un problème et à mieux les maintenir. Il fournit une
infrastructure bien conçue et bien pensée. Ainsi, lorsque des nouvelles parties sont créées,
elles peuvent être ajoutées avec un impact minimal sur les autres parties du Framework.
Un Framework sert, non seulement, à réaliser une application plus rapidement, mais
permet d’obtenir des applications de structures semblables. Ceci permet de simplifier
considérablement leur maintenance [GHJV95]. Un Framework possède les caractéristiques
suivantes :
 Un Framework est composé de multiple classes ou composants chacun d’eux propose
une abstraction d’un concept particulier.
 Le Framework définit comment ces abstractions collaborent ensemble pour résoudre
un problème.
Un bon Framework doit fournir un comportement générique qui peut être utilisé par
plusieurs types d’applications. La notion de Framework est généralement liée à l’Open
Source. En effet, c’est un logiciel livré avec son code source et offre un droit d’utilisation, de
copie et de modification. Les produits Open Source sont régis par des licences. La plus
célèbre entre elles est la GPL (General Public License) de la fondation GNU [wwwFSF]. Le
choix d’utiliser les Frameworks Open Source est justifié par plusieurs raisons :
La première est sans doute financière, les Frameworks Open Source sont gratuits. La
deuxième est technique ; le code source des Frameworks et des logiciels Open Source étant
disponible : un développeur peut comprendre le fonctionnement des Frameworks pour
corriger ses bugs ou encore procéder à des évolutions.
Le fait qu’un Framework soit Open Source ne signifie pas qu’il soit de mauvaise
qualité, au contraire beaucoup de meneurs des projets Open Source sont des personnes très
compétentes qui s’investissent par défi technique et pour la reconnaissance de leurs pairs.
D’autres arguments plus marketing laissent entendre que les Frameworks Open Source
sont plus stables et que le respect des standards et la qualité du support sont meilleurs. Ces
avantages ont cependant un prix, la documentation associée aux projets Open Source est
souvent très succincte, donc lors du choix d’une solution Open Source il faut tenir compte des
critères suivants:
 niveau d’intégration des standards.
 maturité.
 facilité d’utilisation.
 documentation.
L’utilisation des Frameworks est indispensable pour le développement réussi de la
plateforme de taxation pour la téléphonie sur IP. Par la suite, Nous allons présenter les
différents Frameworks Open Source utilisés.

Projet de fin d’études 2010 - 2011 49


Chapitre 4: Conception et mise en œuvre du projet

31 Le Framework SPRING :

SPRING est un conteneur dit « léger », c'est-à-dire une infrastructure similaire à un


serveur d'application J2EE. Il prend donc en charge la création d'objets et la mise en relation
d'objets par l'intermédiaire d'un fichier de configuration qui décrit les objets à fabriquer et les
relations de dépendances entre ces objets.
Le gros avantage par rapport aux serveurs d'application est qu'avec SPRING, les classes
n'ont pas besoin d'implémenter une quelconque interface pour être prises en charge par le
framework (au contraire des serveurs d'applications J2EE et des EJBs). C'est en ce sens que
SPRING est qualifié de conteneur « léger ».

Outre SPRING propose tout un ensemble d'abstractions permettant de gérer entre


autres:

 Le mode transactionnel
 L'appel d'EJBs
 La création d'EJBs
 La persistance d'objets
 La création d'une interface Web
 L'appel et la création de WebServices [wwwEgoSpring]

Ce framework, grâce à sa couche d’abstraction, ne concurrence pas d’autres frameworks


dans une couche spécifique d’un modèle architectural Modèle-Vue-Contrôleur mais s’avère
un frameworkmulti-couches pouvant s’insérer au niveau de toutes les couches ; modèle, vue
et contrôleur. Ainsi il permet d’intégrer  Struts pour la couche présentation.

36 Le Framework Struts:

Le frameworkStruts 2 repose sur une déclaration de l'architecture sous forme de fichiers


XML ou avec des annotations Java localisées dans les fichiers des classes d'actions. Struts 2
est un framework orienté actions. Les actions sont décomposées en trois rôles. Premièrement,
les actions jouent le rôle le plus important du framework en encapsulant le traitement et le
travail à réaliser par le service. Deuxièmement, les actions permettent de manipuler
automatiquement les données des requêtes lors des transferts. Troisièmement, le framework
détermine quel résultat doit être retourné et la vue à afficher en réponse à un traitement. Les
actions Struts 2 implémentent des objets JavaBeans (classes Java simples) pour chaque groupe
de données envoyées dans la requête. Chaque paramètre de la requête est déclaré dans la
classe d'action avec un nom identique pour réaliser automatiquement le mapping des valeurs.
La finalité d'une action étant de retourner une chaîne de caractères permettant de sélectionner
le résultat à afficher.

Pour résumer, Struts 2 repose donc sur le modèle de conception de type MVC II comme il
est expliqué dans le schéma suivant. Il permet un développement plus rapide, plus souple et
résout plusieurs problèmes de conception en fournissant les services suivants :

 Un système évolué de gestion du routage ou navigation


 Un système de validation de formulaires et d'entrées, simple à mettre en œuvre

Projet de fin d’études 2010 - 2011 50


Chapitre 4: Conception et mise en œuvre du projet

 Un système puissant de plug-ins ou d'extensions (pour les graphiques, sources de


données...)
 La gestion de l'internationalisation pour le développement de sites multilingues
 Le support de la technologie Ajax
 Un outil de débogage en standard
 Une bibliothèque puissante de balises[wwwJlafosseStruts]

Figure 17 : Architecture MVC II

37 Le Framework Jasper report :

JasperReports (version 1.1.0) est un outil (librairie) Open Source puissant utilisé pour la
génération d'états. Il permet de créer des rapports à partir de fichiers XML. Le résultat peut
être affiché à l'écran, imprimé ou stocké dans des fichiers au format PDF, HTML, XLS, CSV
ou XML.
JasperReports est entièrement développé en Java et peut être intégré dans une gamme
très variée d'applications Java (y compris les applications J2EE). Son objectif principal est de
fournir un moyen simple et flexible pour la génération de documents. [ATOLBOOK]
La création de rapports avec JasperReports se déroule généralement en 4 étapes :
• l'obtention d'un fichier modèle XML (à l'aide d'éditeurs graphiques comme iReport ou
Open Reports Designer)
• la construction du rapport à partir du modèle
• le remplissage des différents champs du rapport avec les données en provenance de
divers sources (bases de données, classes Java, ...)
• l'exportation du résultat dans plusieurs formats possibles (PDF, HTML, ...).

Projet de fin d’études 2010 - 2011 51


Chapitre 4: Conception et mise en œuvre du projet

Figure 18 : Les étapes de création du rapport par JasperReports

Conclusion :

Au cours de ce chapitre, nous avons définis les besoins techniques technique de la


plateforme de taxation en présentant la technologie utilisée dans le développement. Cela nous
a permis par la suite d’entamer la deuxième étape du processus de développement 2Tup afin
d’identifier les différentes entités composant l’architecture logiciel du système.
Le chapitre suivant est consacré à la présentation de la phase de conception et mise en
œuvre du système de taxation, et donc nous allons passer de l’étude technique du système à la
branche conception-analyse selon le processus de développement suivi. (Autres informations
sur 2Tup dans l’ANNEXE 1)

Projet de fin d’études 2010 - 2011 52


Conclusion et perspective

Chapitre 4 :
Conception et mise en œuvre du projet

Dans ce chapitre, nous présentons la partie restante du


processus suivi qui se compose de la conception
préliminaire, la conception détaillée et par la fin la mise en
œuvre du projet

Projet de fin d’études 2010 - 2011 53


Chapitre 4: Conception et mise en œuvre du projet

Introduction
Après la détermination des besoins fonctionnels et non fonctionnels et la spécification
des besoins de l’application, nous sommes passés, dans ce dernier chapitre à la conception du
projet et sa réalisation. Notre étude se base sur le formalisme UML (voir Annexe 2) en utilisant
la méthode 2TUP, dans un premier temps, nous présenterons la conception préliminaire de la
solution proposée, ensuite, nous passerons à une conception détaillée du projet en tenant
compte des contraintes fonctionnelles et technologiques rencontrées. Et par la fin on passera à
la mise en œuvre du projet.

1 Conception
1.1 Conception préliminaire 
La conception préliminaire consiste en la fusion des études fonctionnelle et technique. Il
convient de :
 Passer de l’analyse objet à la conception ;
 Intégrer les fonctions métier et applicatives du système dans l’architecture
technique ;
 Adapter la conception générique aux spécifications fournies par l’analyse.
La conception préliminaire s’appuie sur les points de vue de spécification fonctionnelle
et structurelle de l’analyse, mais également sur les frameworks de la conception technique.
Le choix judicieux de ces frameworks allège le travail et permet de focaliser sur les vues
de l’application.

1.1.1 Enumération des vues de l’application


Cette étape consiste en la capture des interfaces Homme Machine qui définissent les
interfaces à travers lesquelles l’utilisateur communique avec les différents composants de la
plateforme de taxation.
Voici la liste des IHM pertinents de la plateforme :

Vue IHM Description

Tableau de C’est la page d’accueil de la plateforme, permet à l’utilisateur le résumé et rapport sur les
bord dépenses par département, ainsi la navigation rapide vers les autres fonctionnalités de la
plateforme

Projet de fin d’études 2010 - 2011 54


Chapitre 4: Conception et mise en œuvre du projet

Rapports L’interface principale du module de gestion des rapports qui permet à l’utilisateur de générer des
rapports soit prédéfinis soit personnalisé sur :

 Les appels ;

 Les appareils téléphoniques ;

 Les employés ;

 Les budgets.

Cette interface facilite aussi la génération des rapports sans créer une nouvelle requête par les
rapports prédéfinis comme:

 Seuil dépassés

 Hit-parade de poste

 Hit-parade des destinations

 Appareils non définis

 Activité mensuelle de l'organisation

 Comptes détaillés

 Compte synthèse

 Distribution des budgets par département

 Distribution des budgets par Poste

 Activité mensuelles par département

Facturation L’interface principale du module de gestion des factures qui permet à l’utilisateur de créer des
factures :

 soit prédéfinis du mois actuel ou du mois précèdent

 soit personnalisé du site ou bien du département en indiquant la date de début et la date


de fin de la facture souhaité.

C’est le formulaire de création de facture qui permet cette personnalisation.

Ainsi cette interface présente un accès rapide vers : la liste de factures, la facture avec un total
plus élevé et la facture avec un total plus bas.

Projet de fin d’études 2010 - 2011 55


Chapitre 4: Conception et mise en œuvre du projet

Administration Cette interface est dédiée à l’administrateur de la plateforme, elle permet de gérer les profils, les
sites, les départements, les appareils ou les répertoires en donnant les liens vers les pages
suivantes :

 Créer / supprimer un utilisateur : page de création ou suppression d’utilisateur ;

 Liste des utilisateurs ;

 Créer / supprimer un employé : page de création ou suppression ;

 Liste des utilisateurs ;

 Créer / supprimer un Site ;

 Liste des sites ;

 Créer / supprimer un département ;

 Liste des départements ;

 Créer / supprimer un appareil ;

 Liste des appareils;

 Créer / supprimer un contact ;

 Liste des contacts;

Tarifs Cette interface est dédiée à l’administrateur de la plateforme, elle permet de gérer les opérateurs et
ses tarifs.

Cette page mène à la page de :

 Création d’un nouvel opérateur ;

 La liste des opérateurs ;

 Création d’un nouveau tarif;

 Modification de tarif

Permet aussi d’appliquer un tarif par un formulaire de deux parties :

 Parti opérateur : permet de désigner l’opérateur par une liste déroulante et déterminer la
date de mise à jour ;

 Partie tarif : permet d’ajouter l’information sur le tarif suivante : le type, date de début,
date de fin, l’état de la 1ere minute (indivisible ou divisible),le cout en minute, la duré du
tranche .

o Si le tarif est réduit, un formulaire, contient l’information sur la date spéciale,


doit être rempli par l’administrateur

Table 10 : Les IHM pertinents de la plateforme de taxation

1.2 Conception détaillé :


Nous arrivons maintenant à la phase ultime de modélisation du système. Après la
modélisation de besoins puis l’organisation de la structure de la solution, la conception détaillée
consiste à construire et documenter précisément les classes, les interfaces, les tables et les
méthodes qui constituent le codage de la solution.

Projet de fin d’études 2010 - 2011 56


Chapitre 4: Conception et mise en œuvre du projet

Durant cette étape nous avons appliqué le micro-processus de conception logique pour
bâtir une conception objet avec UML et pour transformer un modèle objet en modèle
relationnel. (Voir l’Annexe 4)
2.1.1 Le diagramme des classes :
On a élaboré le diagramme des classes pour chaque module suite à l’étude fonctionnelle
où nous avons décomposé la plateforme de taxation en trois principaux modules comme suit :

Module de gestion de factures :

Figure 19 : Diagramme des classes du module de gestion de factures

Module de gestion des tarifs :

Projet de fin d’études 2010 - 2011 57


Chapitre 4: Conception et mise en œuvre du projet

Figure 20 : Diagramme des classes du module de gestion des tarifs

Module de gestion des dépenses et rapports

Projet de fin d’études 2010 - 2011 58


Chapitre 4: Conception et mise en œuvre du projet

2.1.2 Le schéma relationnel


Après avoir conçu les attributs des classes on a comme résultat le schéma relationnel de
la base de données de la plateforme de taxation. Donc ce résultat est générer à partir le
diagramme des classes précèdent en utilisant l’outil Rational Rose.
La figure suivante représente le schéma relationnel pour le module des dépenses et
rapports. (Les schémas des autres modules dans Annexe 5)

Projet de fin d’études 2010 - 2011 59


Chapitre 4: Conception et mise en œuvre du projet

Figure 22 : Schéma relationnel du module de gestion des dépenses et rapports

Projet de fin d’études 2010 - 2011 60


Chapitre 4: Conception et mise en œuvre du projet

2 Mise en œuvre 
La mise en place de l’architecture technique et le choix des outils de travail présentés dans
les chapitres précédents, nous ont permis de mettre en place l’architecture applicative de la
plateforme de taxation pour la téléphonie sur IP. L’implémentation de cette architecture est le
fruit de la phase de réalisation.
La phase des tests permet de vérifier la validité du système, avant d’entamer la phase
d’intégration avec les autres modules de la plateforme.
Dans cette partie du rapport, nous présenterons les deux phases suivantes :
 Mapping objet / relationnel
 Implémentation des IHM

2.1 Mapping objet/relationnel :


Durant cette étape les classes Bean sont implémentées sous JAVA en éditant les fichiers
XML d’ Hibernate.
Pour une classe Bean donnée il existe une table correspondante dans la base de données,
les tables d’associations (ou les tables de jointure), pour réaliser le mapping il faut éditer deux
fichiers XML:
 Hibernate.cf.xml : ficher de configuration
 Nom_de_la_classe.hbm.xml : fichier de mapping du Bean.

2.2 Implémentation des IHM


Cette étape présente la fonctionnalité de la plateforme de taxation par des vues systèmes.
Et seules les interfaces les plus pertinentes sont présentées avec une explication comme suit :
 Interface de l’Administration :
Cette interface est dédiée à l’administrateur de la plateforme, elle permet de gérer les
profils, les sites, les départements, les appareils ou les répertoires en donnant les liens vers les
pages suivantes :
 Créer / supprimer un utilisateur : page de  Créer / supprimer un département ;
création ou suppression d’utilisateur ;
 Liste des départements ;
 Liste des utilisateurs ;
 Créer / supprimer un appareil ;
 Créer / supprimer un employé : page de
création ou suppression ;  Liste des appareils;

 Liste des utilisateurs ;  Créer / supprimer un contact ;

 Créer / supprimer un Site ;  Liste des contacts;

 Liste des sites ;

Projet de fin d’études 2010 - 2011 61


Chapitre 4: Conception et mise en œuvre du projet

Figure 23 : Interface de l’administration

 L’ajout d’un nouvel utilisateur/ ou la suppression :


Dans cette interface l’administrateur peut ajouter ou supprimer un utilisateur en saisissant les
informations nécessaire dans le formulaire comme le montre la figure suivante.

Projet de fin d’études 2010 - 2011 62


Chapitre 4: Conception et mise en œuvre du projet

Figure 24 : Interface de l’ajout et suppression d’un utilisateur

 Ajout d’un nouveau tarif :


Cette interface est dédiée à l’administrateur de la plateforme, elle permet de gérer les opérateurs et ses tarifs.

Figure 25 : Interface de l’ajout d’un tarif : choix d’opérateur

Projet de fin d’études 2010 - 2011 63


Chapitre 4: Conception et mise en œuvre du projet

Figure 26 : Interface de l’ajout d’un tarif : Information sur tarif

Figure 27 : Interface de l’ajout d’un tarif : Information sur la date spéciale

Vu le nombre important des interfaces dans l’application web nous avons choisi de
présenter juste ces interfaces précédents.
Conclusion
Au cours de ce dernier chapitre, nous avons définis l’aspect conceptuel de la plateforme
de taxation. Cela nous a permis par la suite d’entamer les étapes de la réalisation de la branche
conception- réalisation du processus de développement 2Tup afin de finaliser le projet.

Projet de fin d’études 2010 - 2011 64


Conclusion et perspective

Conclusion et Perspectives
Durant toute la période de notre formation en ingénierie logiciel et multimédia au sein
de l’Institut Supérieure du Génie Appliqué on a eu l’opportunité d’acquérir des connaissances
au niveau technique, analytique et relationnel, grâce à une direction qui veille sur la qualité de
l’enseignement au sein de cette grande école et aux professeurs qui nous ont fait partager leurs
connaissances sans modération, ce qui a augmenté nos connaissances et nous a aidé à
comprendre les rouages d’un secteur très exigeant.

Pour compléter notre cursus, on a réalisé un projet de fin d’études au sein d’Inteclom, un
stage plongé au cœur de la réalité du monde professionnel, qui nous a permis de s’initier au
métier, et de préparer activement notre insertion professionnelle.

Grâce à un environnement favorable pour le travail et un encadrement encourageant et


permanent qui nous a permis de savoir travailler en équipe et on a pu réaliser notre projet de fin
d’études suivant le processus de développement en Y méthodique et organisé.

En effet, ce projet fut une étape très importante pour notre cycle de formation du fait
qu’il a été une opportunité très intéressante et bénéfique pour la mise en pratique des
connaissances théoriques déjà acquises. Ainsi d’avoir plus d’information sur le domaine de la
télécommunication.

Les difficultés majeures que nous avons rencontrées durant ce projet résident
essentiellement dans l’utilisation des nouveaux Frameworks de la génération des rapports.

Enfin, nous précisons que la conception effectuée garantira l’extensibilité de la


plateforme développé et permettra à Intelcom d’ajouter d’autres services pour réponde aux
futurs besoins. Par exemple, le système peut être doté d’un module de la collecte des
informations sur les appels, issue de plusieurs équipements de la téléphonie sur IP.

Projet de fin d’études 2010 - 2011 65


Bibliographie

Bibliographie :

[IBMBOOK] Cours AD65F, WebSphere Application Server – Advanced Edition and EJB, formation
IBM.

[ATOLBOOK] Présentation de l'outil de reporting «JasperReports », par ATOL Conseils et


Développements

[UMLBOOK] UML 2 en actionDe l’analyse des besoins à la conception J2EE .3e édition . Pascal
Roques • Franck Vallée.

- Mémoire de Projet de Fin d’Études : Conception et réalisation d’un serveur de


change de devises en libre servicepour Wincor Nixdorf, par Najib SAFIR

Webographie 

[wwwASTONA]http://elisa.aston.fr
Jérôme LOUVEL, Guide d’architecture.

[wwwASTONS] http://elisa.aston.fr
Jérôme LOUVEL, Guide des standards.

[wwwEgoSpring] http://ego.developpez.com/spring/
Introduction au framework Spring Par Erik Gollot.

[wwwFSF]http://www.fsf.org/
Définition des différentes licences relatives aux produits Open
Source.

[wwwJAVASUN] http://Java.sun.com/J2EE/white/j2ee_guide.pdf
Simplified Guide to the J2EE, Sun Microsystems.

[wwwJlafosseStruts] http://jlafosse.developpez.com/livres/java/struts2/presentation/
Struts 2 - Le framework de développement d'applications Java EE , Par Jérôme Lafosse

[wwwREDBOOKIBM] http://www.redbooks.ibm.com
Projet de fin d’études 2010 - 2011 66
Annexes 1

Servlet/JSP/EJB, Design and Implementation Guide for IBM


WebSphere Application Servers.

[wwwTHOMA]http://www.psgroup.com
A. THOMAS, Java 2 Platforme Entreprise Edition

Projet de fin d’études 2010 - 2011 67


Annexes 1

Annexe 1
Le processus 2TUP :
Le processus 2TUP (TwoTrackUnifiedProcess) est un processus unifié. Il gère la
complexité technologique en donnant part à la technologie dans son processus de
développement.
Le 2TUP propose un cycle de développement qui dissocie les aspects techniques des
aspects fonctionnels et propose une étude parallèle des deux branches : fonctionnelle (étude de
l’application) et la technique (étude de l’implémentation). Illustré sur la figure suivante, le
processus 2TUP s’articule autour de trois phases :
· Une branche technique
· Une branche fonctionnelle
· Et une branche de conception réalisation.
La figure suivante détaille les étapes de développement des trois branches du
processus 2TUP.

Figure 28 : Le processus 2Tup

1.1 Branche fonctionnelle


Les principales étapes de la branche fonctionnelle se présentent comme suit :
L’étape capture des besoins fonctionnels produit le modèle des besoins focalisé sur le
métier des utilisateurs. Elle qualifie, au plus tôt le risque de produire un système inadapté aux
utilisateurs. Cette phase a pour objectif de définir :

Projet de fin d’études 2010 - 2011 68


Annexes 1

· La frontière fonctionnelle entre le système considéré comme une boite noire et


son environnement, c’est le niveau contexte.
· Les activités attendues des différents utilisateurs par rapport au système
toujours envisagé comme une boite noire, c’est le niveau cas d’utilisation.
L’étape d’analyse consiste à étudier précisément les spécifications fonctionnelles de manière à
obtenir une idée de ce que va réaliser le système en terme de métier.

1.2 Branche technique


Les principales étapes de la branche technique se présentent comme suit :
L’étape capture des besoins techniques recense toutes les contraintes sur les choix de
dimensionnement et la conception du système. Les outils et le matériel sélectionnés ainsi que
la prise en compte des contraintes d’intégration avec l’existant (pré requis d’architecture
technique). Cette étape permet de définir le modèle d’analyse technique. Le rôle de ce dernier
est d’établir les couches logicielles et y spécifie les activités techniques attendues.
L’étape conception générique définit ensuite les composants nécessaires à la
construction de l’architecture technique. Cette conception est complètement indépendante des
aspects fonctionnels. Elle permet de générer le modèle de conception technique ou design
pattern (aspect qui sera développé ultérieurement) qui définit les Frameworks. Ces derniers,
délivrant les services techniques, assurent la réponse aux exigences opérationnelles du
système.
1.3 Branche conception - réalisation
Les principales étapes de cette branche se présentent comme suit :
L’étape conception préliminaire est une étape délicate, car elle intègre le modèle
d’analyse fonctionnelle dans l’architecture technique de manière à tracer la cartographie des
composants du système à développer. Cette étape permet de produire le modèle de conception
système. Ce dernier organise le système en composants, délivrant les services techniques et
fonctionnels. Ce modèle regroupe les informations des branches technique et fonctionnelle.
L’étape conception détaillée permet d’étudier comment réaliser chaque composant.
Cette étape produit le modèle de conception des composants. Ce modèle fournit l’image prête
à fabriquer du système complet.
C’est dans l’étape de codage que s’effectue la production des composants et les tests
des unités de code au fur et à mesure de leur réalisation.
L’étape de recette consiste à valider les fonctionnalités du système développé.

Projet de fin d’études 2010 - 2011 69


Annexes 2

Annexe 2
UML
UML (en anglais Unified Modeling Language, « langage de modélisation unifié ») est
un langage graphique de modélisation des données et des traitements. C'est une formalisation
très aboutie et non propriétaire de la modélisation objet utilisée en génie logiciel. L'OMG
travaille actuellement sur la version UML 2.1.
Il est l'accomplissement de la fusion des précédents langages de modélisation objet
Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et
Ivar Jacobson. UML est un standard défini par l'OMG (Object Management Group).
Le modèle UML est composé de 13 types de diagrammes (9 en UML 1.3). UML
n'étant pas une méthode, leur utilisation est laissée à l'appréciation de chacun, même si le
diagramme de classes est généralement considéré comme l'élément central d'UML. De même,
on peut se contenter de modéliser seulement partiellement un système, par exemple certaines
parties critiques.
UML se décompose en plusieurs sous-ensembles
- Les vues : Les vues sont les observables du système. Elles décrivent le système d'un
point de vue donné, qui peut être organisationnel, dynamique, temporel, architectural,
géographique, logique, etc. En combinant toutes ces vues il est possible de définir (ou
retrouver) le système complet.
- Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci décrivent
le contenu des vues, qui sont des notions abstraites. Les diagrammes peuvent faire partie de
plusieurs vues.
- Les modèles d'élément : Les modèles d'élément sont les briques des diagrammes
UML, ces modèles sont utilisés dans plusieurs types de diagramme. Exemple d'élément : cas
d'utilisation (CU ou cadut'), classe, association, etc.
Annexes 3

Annexe 3 :
Cahier de charges
CAHIER DE CHARGES
1 OBJECTIF DU PROJET
3 On souhaite de mettre en place et déployer une solution web pour la Taxation de la téléphonie
IP de l’entreprise Intelcom.

4 La solution assurera la gestion comptable et le contrôle des appels téléphoniques. Elle permet
un suivi intelligent de tous les appels – qu'il s'agisse de téléphonie classique ou de téléphonie internet (VoIP) –
passés sur le réseau de l'entreprise.

2 CADRE TECHNIQUE DU PROJET


2.1 Maîtrise d’œuvre, organisation, suivi du projet
L’entreprise assurera la fourniture des matériels et des logiciels, l'ensemble de l’installation et des
connexions, sous sa maîtrise d'œuvre unique dans le cadre d'une obligation de résultats et de conseil.

L’entreprise assurera le pilotage et la coordination de l'opération. Il sera responsable de la bonne et


totale fonctionnalité du produit, et de la cohérence de l'ensemble. Il établira en concertation avec le Chef de
projet taxation et le Service Informatique le planning prévisionnel. Celui-ci comportera toutes les phases du projet
:

 Commande et livraison du serveur


 Spécifications transmises au Service Informatique les autres matériels (micros, imprimantes, …)
 Installation du SGBD sur le serveur et des autres logiciels système éventuels, ainsi que du
serveur WEB si un logiciel de ce type est utilisé
 Installation du progiciel de Gestion Electronique de Documents et des autres logiciels
nécessaires sur le serveur
 Paramétrage de l'application
 Création des scripts de sauvegarde et autres scripts d'exploitation
 Installation des logiciels sur quelques postes de travail avec paramétrage des postes et des
imprimantes.
 Tests
 Test de la sauvegarde/restauration
 Installation et test de la télémaintenance
Démarrage

3 Plateforme de taxation
Aspects fonctionnels

Fonctionnalités de La solution:
Annexes 3

 La solution web offre une fonctionnalité totale avec tous les navigateurs web, que ce
soit de l'intérieur ou de l'extérieur de l'organisation
 Architecture système prend en charge un nombre infini de sites et d'employés

 la modularité optimisée pour divers types d'installation pour offrir toute la souplesse
requise pour les réseaux centralisés ou répartis, avec un traitement optimal pour
chaque site.
 Prise en charge de la base de données MySQL et utilisation avancée de la technologie
J2EE
 Journalisation des événements pour les journaux système de suivi et administration du
système
 Moniteur système pour afficher des informations en ligne sur : collecte des
enregistrements de données d'appel (CDR, Call Data Record) à partir de différentes
sources de données, état de traitement des CDR et autres changements survenus dans
le système
 Définition du niveau de détail des rapports – affiche les différentes hiérarchies de
l'entreprise dans un rapport unique
 Sécurité optimisée pour limiter l'accès à certaines options et commandes en fonction
de l'utilisateur et de l'appartenance à un groupe
 Contrôle d'accès, journalisation des attaques système, algorithmes complexes de
génération de mots de passe et pour offrir une protection totale contre les hackers

Le système doit permettre :

 gérer les dépenses téléphoniques à tous les niveaux, à la fois par employé et par
département ;
 générer des rapports faciles à exploiter, ne comportant que les informations requises ;
 établir des rapports et des relevés de coûts en plusieurs devises ;
 contrôler la charge de trafic de chaque employé et de la ligne extérieure ;
 repérer toute utilisation abusive du téléphone, notamment les appels longs et coûteux;
 réduire les dépenses téléphoniques en sensibilisant le personnel à une utilisation
efficace du téléphone ;

Fonctionnalités liées à la génération des requêtes :

Cette option assurera les fonctionnalités suivantes:

 Compiler un nombre infini de rapports personnalisés.


 L’utilisateur peut déterminer les données requises,
 L’utilisateur peut sélectionner la façon dont elles doivent être triées et globalisées,
 Les requêtes personnalisées peuvent être enregistrées pour un usage ultérieur.

Projet de fin d’études 2010 - 2011 72


Annexes 3

 l'utilisateur peut exporter des informations vers n'importe quel système extérieur,
au format de son choix.

4 LOGICIEL
5 Nous installerons le logiciel de Taxation pour la téléphonie IP sur le serveur ainsi que les
autres logiciels nécessaires. Nous procéderons au paramétrage de ces logiciels. Une personne du Service
Informatique suivra cette installation pour en comprendre l'architecture.

5 SECURITE
Sécurité d'accès et confidentialité

Les droits d'accès au système par les différents utilisateurs concernés sont définis et gérés par un
"Administrateur".
L’accès au paramétrage sera sécurisé avec un mot de passe particulier.
L'Administrateur définit pour chaque utilisateur :
• Son profil,
• Ses droits d'accès (lecture seule, mises à jour, éditions, suppressions, …),
• Son domaine d'intervention (fonctions du logiciel autorisées).
La reconnaissance de l'utilisateur par le système doit être mise en pratique par la saisie d'un code et
d'un mot de passe associé.
Les mots de passe associés aux utilisateurs devront être conformes aux recommandations suivantes :
 Ils doivent être de longueur minimale de 6 caractères,
 Etre modifiables par les utilisateurs,
 Les codes triviaux doivent être interdits,
 La durée de vie doit être contrôlée et limitée,
 Les anciens mots de passe ne sont pas réutilisables.
Une fois connecté, si l'utilisateur ne fait aucune action sur son poste pendant un laps de temps,
éventuellement paramétrable, le système procédera à une déconnexion automatique.
Sauvegardes

Le serveur utilisera le système de sauvegarde centralisé . L’entreprise rédigera les scripts de sauvegarde et
de restauration ainsi que le paramétrage des sauvegardes quotidiennes.

Projet de fin d’études 2010 - 2011 73


Annexes 3

6 CONSERVATION DES DONNEES


L’entreprise proposera une solution qui permette la conservation des données en ligne pendant un
temps suffisamment long pour assurer une exploitation normale du système. Il indiquera clairement la
durée qu'il préconise en fonction de laquelle le serveur aura été dimensionné.

7 LICENCES
L’entreprise devra remettre l'original de toutes les licences relatives aux logiciels qu'il aura fourni :
• Système d'exploitation du serveur
• SGBD
• Droit de connexion au serveur pour les postes de travail
• Progiciel de Gestion Electronique de Documents
• Autres logiciels utilisés

8 PRESENTATION DE LA SOLUTION
6 La solution comprendra une prestation globale incluant :

• Le logiciel
• Les prestations associées
L’installation et le paramétrage.

Projet de fin d’études 2010 - 2011 74


Annexes 4

Annexe 4 :
Conception détaillée
Objectifs du chapitre
Nous arrivons maintenant à la phase ultime de modélisation avec UML. Après la modélisation
des besoins puis l’organisation de la structure de la solution, la conception détaillée consiste à
construire et à documenter précisément les classes, les interfaces, les tables et les méthodes
qui constituent le codage de la solution. Il s’agit de :
 comprendre le rôle d’UML pour la conception détaillée ;
 savoir appliquer le micro-processus utilisé pour bâtir une conception objet avec UML ;
 apprendre à construire une solution pour : la couche de présentation, la couche
d’application et la couche métier distribuée dont l’EAI ;
 savoir transformer un modèle objet en modèle relationnel.
Quand intervient la conception détaillée?
La conception détaillée est une activité qui s’inscrit dans l’organisation définie par la
conception préliminaire. Le modèle logique y est particulièrement important dans la mesure
où c’est en conception détaillée que l’on génère le plus gros volume d’informations. Il est
ainsi possible de confier les catégories à des personnes différentes, qui pourront travailler
indépendamment les unes des autres. La conception détaillée s’appuie donc sur les catégories
de conception organisées à la fois suivant les frameworks techniques et les regroupements
propres au métier. Les concepteurs construisent alors les classes, les vues d’IHM, les
interfaces, les tables et les méthodes qui vont donner une image « prête à coder » de la
solution.
En dernier lieu, il convient de préciser le contenu des sous-systèmes de manière à compléter la
configuration logicielle. Le niveau d’abstraction visé par l’étape de conception détaillée est la
conception des composants. Il s’agit d’avoir une idée la plus précise possible pour la
fabrication et l’assemblage des sous-systèmes de configuration logicielle.
La conception détaillée précède la phase de codage. À ce niveau, toutes les questions relatives
à l’agencement et aux détails de la solution doivent être modélisées. Ainsi, les interrogations
restantes concernent exclusivement la bonne utilisation des langages et des outils de
développement.
Annexes 4

Figure 11-1. : Situation de la conception détaillée dans 2TUP

Éléments mis en jeu

 Micro-processus de conception logique, modèle logique,


 propriétés de conception d’une classe, d’un attribut, d’une association et d’une
opération,
 design patterns : État, Itérateur, Curseur, Stratégie, Observateur, Référence futée,
 couches de présentation, de l’application, de métier distribué et de stockagedes
données,
 IHM, distribution RMI, passage d’un modèle objet à un modèle relationnel,
 modèle d’exploitation consolidé et modèle de configuration logicielle détaillée.
Le micro-processus de conception logique
Le micro-processus de conception logique concerne la définition des classes à implémenter.
C’est donc une activité centrée sur le modèle logique, qui combine les diagrammes UML
suivants :
 principalement les diagrammes de classes pour préciser la structure des classes de
développement,
 mais aussi les diagrammes d’interactions pour préciser les communications entre
objets,
 et les diagrammes d’activité pour exprimer les algorithmes des méthodes.
Enfin, il est possible de recourir à du pseudo-code pour les algorithmes les plus complexes. Il
s’agit en fait d’esquisser le code des méthodes à développer.
En l’occurrence, nous utilisons une formulation proche de Java. Le micro-processus consiste
en une itération des cinq activités représentées à la figure 11-2.

Projet de fin d’études 2010 - 2011 76


Annexes 4

Figure 11-2. : Micro-processus de conception détaillée

 Concevoir les classes consiste à transformer des concepts provenant de l’analyse,


tels que les métaclasses ou les classes à états parallèles, en techniques disponibles
avec les langages et les outils de développement.
 Concevoir les associations définit la façon d’exploiter chaque association et les
techniques qui seront employées dans le codage.
 Concevoir les attributs nécessite essentiellement d’identifier les structuresde
données, les itérations et d’autres types complexes permettant de représenterles
attributs d’analyse avec le langage utilisé.
 Concevoir les opérations permet de déterminer le contenu des méthodes
complexes et d’identifier en cascade de nouvelles classes et opérations dans la
catégorie.
 Valider le modèle constitue la phase de décision du cycle itératif. Sortir de ce
cycle signifie que le modèle donne l’image prête à coder de ses composants de
configuration logicielle.
Nous allons étudier tour à tour ces activités, puis voir leur application sur les différentes
couches du système SIVEx.
Concevoir les classes
Les classes qui proviennent de l’analyse ne sont pas toujours conformes aux
possibilités du langage d’implémentation. Dans certains cas, une analyse orientée objet est
réalisée dans un langage non objet. La transformation des classes en codage est alors
particulièrement importante pour conserver la trace du passage de l’analyse au code. Java
offre bien entendu une transformation beaucoup plus directe. Certaines formes telles que les
méta-classes, les états ou les héritages multiples sont cependant tolérées par les analystes mais

Projet de fin d’études 2010 - 2011 77


Annexes 4

inconnues de Java. Concevoir les classes consiste tout d’abord à expliciter comment ces
concepts devront être traduits dans le code.
Concevoir les classes, c’est aussi en introduire de nouvelles soit pour prendre en charge des
responsabilités purement techniques, soit pour décharger une classe d’analyse de certains de
ces aspects techniques. Les liens qui rattachent ces classes entre elles doivent le plus souvent
correspondre à des designpatterns. On trouvera à terme des classes comme des « fabriques »,
des« archiveurs », des « traceurs », des « vérificateurs de cohérence », etc.
Concevoir les classes, c’est enfin redistribuer les messages et les événements du modèle
dynamique sur les différentes couches de conception – nous verrons notamment comment
réaliser la conception orientée objet des messages identifiés dans les interfaces EAI. Il est
probable en effet que ces concepts vus de manière abstraite par l’analyste ne correspondent
plus aux principes de conception. Pour les systèmes 3-tiers, nous pensons plus
particulièrement à la redistribution des échanges entre les couches métier et application. Ces
échanges s’appuyant sur les capacités d’un réseau physique doivent faire l’objet
d’optimisations. Dans cette optique, il convient que les diagrammes d’états soient retravaillés
au niveau de la conception. [UMLBOOK]

Projet de fin d’études 2010 - 2011 78


Annexes 5

Annexe 5
Schéma Relationnel : Gestion de factures
Annexes 5

Schéma Relationnel : Gestion de tarifs

Projet de fin d’études 2010 - 2011 80