Rapport Final

Institut Supérieur Du Génie Appliqué

Projet de fin d’étudesPour l’obtention du titre :

Ingénieur en InformatiqueOption : 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 : Hassani Mohamed

Benyadi Mourad

Encadré par :M. Bouzidi Driss

Mme Fadwa lahrach

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

Jury :M. Mourad Raji

M. Laalej Mohamed

M. Driss Bouzidi

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


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

0


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

1


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é.


2


Sommaire

Liste des abréviations…………………..………………………………………………………………..4Liste des figures.………………………………………………………………………………………...5Liste des tables….…………………………………………………….…………………………………6Introduction ...…….……………………………………………………………………………………..7Chapitre 1 : Contexte général du projet…..………………………………………………………….8

Introduction……………………………………………………………………………………..91 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……………………………………………………………………………………..21Chapitre 2 : Étude fonctionnelle du projet………………………………………………………….22

Introduction……………………………………………………………………………………231 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


3


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

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

Conclusion…………………………………………………………………………………….37Chapitre 3 : Étude technique du projet …………………………………………………………….39

Introduction……………………………………………………………………………………401 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……………………………………………………………………………………..51Chapitre 4 : Conception et mise en œuvre du projet……………………………………………….52

Introduction…………………………………………………………………………………....531 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..................................................................................................................................63Conclusion et perspectives……………………………………………………………………………..64Bibliographie............................................................................................................ …………………..65Annexe 1 : Le processus 2TUP…………...............................................................................................66Annexe 2 : UML……………………………………………………………………………………….68Annexe 3 : Cahier de charges.................................................................................................................69Annexe 4 : Conception détaillée…..…………………………………………………………………...73Annexe 5 : Schéma relationnel………………………………………………...………………………77


4


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

ANRTL'Agence Nationale de Réglementation des 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


5


Liste des figures

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


6


Liste des tables

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


7


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.


8

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.

Chapitre 1 :

Contexte général du projet

9


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’entreprise1.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


10


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.


http://www.intelcom.groupesatec.com/fr-ma/nuestraactividad/sectoresdeactividad/Paginas/Seguros.aspx

http://www.intelcom.groupesatec.com/fr-ma/nuestraactividad/sectoresdeactividad/Paginas/Banca.aspx

http://www.intelcom.groupesatec.com/fr-ma/nuestraactividad/sectoresdeactividad/Paginas/Industria.aspx

http://www.intelcom.groupesatec.com/fr-ma/nuestraactividad/sectoresdeactividad/Paginas/Sanidad.aspx

http://www.intelcom.groupesatec.com/fr-ma/nuestraactividad/sectoresdeactividad/Paginas/OperadorasdeTelecomunicaciones.aspx

http://www.intelcom.groupesatec.com/fr-ma/nuestraactividad/sectoresdeactividad/Paginas/AdministracionesPublicas1.aspx

11


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


12


2 Présentation du projet1.4 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.5 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é.


13


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.


14


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 réseaux est aujourd’hui la grande occupation des opérateurs dans ce domaine. Pour cela il faut


15


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.

3.3.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.

3.3.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.

3.3.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 ».

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


16


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.


17


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 :


18


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

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


19


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.


20


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 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.


21


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

Processus Description Avantages InconvénientsRUP RUP est à la fois une

méthodologie de conduite et de développement de projets et un outil prêt à l’emploi

Propose des modèles de documents, et des canevas pour des projets types

-Coûteux à personnaliser-Très axé processus, au détriment du développement : peu de place pour le code et la technologie

V Chaque phase en amont de la production du logiciel prépare la phase correspondante de vérification en aval de laproduction du logiciel

Préparation des phases de vérification au moment de l’Analyse et de laConception

-Obligation de définir la totalité des besoins au départ-Validation fonctionnelle tardive

2TUP S’articule autour de l’architecture

Fait une large place à la technologie et à la gestion du risque

Ne propose pas de documents types

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 finRecherche de documentation 14/03/11 26/03/11Rédaction d'un rapport sur la téléphonie IP 14/03/11 15/03/11Analyse de la solution Phonex One 15/03/11 29/03/11Analyse et Conception de la plateforme 29/03/11 28/05/11Etudes fonctionnel et étude technique du projet 29/03/11 30/04/11Conception 29/04/11 28/05/11Développement des algorithmes de calcul des coûts des appels

30/05/11 11/06/11

Développement de l'interface graphique 13/06/11 23/06/11Déploiement et tests au niveau du réseau TOIP 23/06/11 01/07/11Réalisation des documents techniques 13/06/11 02/07/11Rédaction du mémoire de Fin d'études 14/03/11 02/07/11

Table 2 : les taches du projet


22


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 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.


Chapitre 2 :

Étude fonctionnelle du projet

23

Chapitre 2: Etude 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.

24


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 fonctionnels1.6 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 Services, Inc.

ArezquiBela_d �"Areski"

EVERCOM

Licence GPL AGPL AGPL Payante

Configuration requise

- Serveur WEB HTTP- PHP 5.0 ou supérieur (PHP 4.0 n'est pas supporté);- support GD activé en PHP;- MySQL SGBD- serveur AsteriskVoIP

- Perl , version 5.8.4 minimumApache-Apache , SSL hautement recommandé) -PostgreSQL ouMySQL (v4.1 ou ultérieure, v5 recommandé)

-Asterisk 1.2.24 + 1.4.0 ou Asterisk-Apache 2-PostgreSQL 8 ou 5 MySQL-PHP 5

-Microsoft SQL Server 2005/2008 éditions standard et Enterpriseou eXPress-MicrosoftInternet Information Server (IIS) 5.0-ASP.NET

Gestion des dépenses :Gérer les dépenses à tous les niveaux

Oui Non Non Oui

Gérer les dépenses par employé

Oui Oui Non Oui

Gérer les dépenses par département

Oui Non Non Oui


25


Gestion des rapports :générer des rapports faciles à exploiter

Oui Oui Oui Oui

Etablir des rapports coûts en plusieurs devises

Non Non Oui Oui

Etablir des rapports ne comportant que les informations requises

Oui Non Non Oui

Gestion des requêtes:Déterminer les données requises

Oui Oui Non Oui

Les requêtes peuvent être personnalisées

Oui Oui Non Oui

Les requêtes peuvent être exportées

Oui Oui Non Oui

Contrôle de trafic :contrôler la charge de trafic de chaque employé

Non Non Oui Oui

contrôler la charge de trafic de chaque ligne extérieure

Non Non Non Oui

Journalisation:Journalisation des événements

Oui Oui Oui Oui

Journalisation pour l’administration du système

Oui Non Non Oui

Gestion des tarifsPlanification des tarifs

Oui Oui Oui Oui

Mise à jour des tarifs

Oui Oui Oui Oui

Bilan :

Projet de fin d’études 2010 - 2011Table 3 : comparatif des solutions de facturation

26


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 suivante, à fin de mettre en œuvre une nouvelle solution de taxation pour la téléphonie sur IP.

1.7 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:


27


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


28


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.8 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


29


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.9 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 :


30


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.



La facturation s’effectue en tarif unique



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

Offre : Préférence Mobile.


31


Description de l’offre :

Tarifs préférentiels pour les communications à destination des mobiles IAM et Méditel.



La facturation s’effectue en tarif unique ;



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 :

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.


32


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 :

Le tarif actuel peut être un tarif réduit ou normal (plein tarif) selon le tarif activé.


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).

33


2 AnalyseL’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 informationsGénérer le rapportGérer la requêteLire les données traitéesLire les données traitéesParamétrer le systèmeSauvegarder les donnéesSauvegarder les paramètresTraiter les données

Le diagramme des cas d’utilisation :


34


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 :


35


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 :


36


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

La gestion des utilisateurs :

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 :


37


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.

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.


38


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 :

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


39


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.


Chapitre 3: Etude technique du projet

Dans ce chapitre, nous présentons la technologieJ2EE 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 3 :

Etude technique du projet

41

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.


42


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


43


1.2 Composants de base de J2EE

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


44


requêtes de l’utilisateur vers les composants EJB et renvoie à l’utilisateur les pages Web adéquates [IBMBOOK].

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.


45

La Plateforme de taxation

L’évolutivité

Sécurité


2 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.3 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.


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

Réutilisabilité Disponibilité

46


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

Objectif DescriptionDisponibilité 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.4 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é :


47

Application

Domaine

Persistance

Présentation


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.


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

48


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.


49


3 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.


50


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.

32 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 Un système puissant de plug-ins ou d'extensions (pour les graphiques, sources de

données...)


51


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

33 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, ...).


52


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)


53

Conclusion et perspective


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

Chapitre 4 :

Conception et mise en œuvre du projet

54


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 Conception1.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 bord

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


55


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.


56


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 ;


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.


57


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 :


58


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

Module de gestion des dépenses et rapports


59


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)


60


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


61


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éation ou suppression d’utilisateur ;


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


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;


62


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.


63


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


64


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.


65

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.


66

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 dechange de devises en libre servicepour Wincor Nixdorf, par Najib SAFIR

Webographie

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

[wwwASTONS] http://elisa.aston.frJé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 OpenSource.

[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.comServlet/JSP/EJB, Design and Implementation Guide for IBMWebSphere Application Servers.

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


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 :


68

Annexes 1

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 :

· 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é.


Annexes 2

Annexe 2UML

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 PROJETOn souhaite de mettre en place et déployer une solution web pour la Taxation de la téléphonie IP de

l’entreprise Intelcom.

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 PROJET2.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 taxationAspects fonctionnels

Fonctionnalités de La solution:

71

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.

72

Annexes 3


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

4 LOGICIELNous 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 SECURITESé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.

73

Annexes 3


6 CONSERVATION DES DONNEESL’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 LICENCESL’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 SOLUTIONLa solution comprendra une prestation globale incluant :

• Le logiciel

• Les prestations associées

L’installation et le paramétrage.

Annexes 4

Annexe 4 : Conception détailléeObjectifs 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.

75

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.


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


77

Annexes 4

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 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]


Annexes 5

Annexe 5

Schéma Relationnel : Gestion de factures

79

Annexes 5

Schéma Relationnel : Gestion de tarifs
